Backend Server Validation
-
Upload
zhang-yu-tao -
Category
Documents
-
view
157 -
download
0
Transcript of Backend Server Validation
Backend Server ValidationZhang Yu Tao
May 20, 2015
Backend Server Validation - Automation
Background IntroductionPurpose IntroductionStructure ViewSolution PrincipleRoles in codeLinux/Windows checkpointQ&A
Background IntroductionXXX Cloud Services are designed for supporting critical application workloads . When a customer order a new server in the data centers, we need to validate that it has been provisioned successfully and the server configuration (OS, storage, platform, management, orchestration, software, hardware information and more) are correct as ordered in the portal. This is not only vital for test teams but also for other teams. It costs enormous manpower on carrying out these repeated testing.
This E2E validation solution is aiming at doing this job automatically and wisely with its expandability, flexibility and ease of use based on various technologies.
We hope it can benefits different teams that perform provisioning test /backend validation in Labs or DCs and aim to publish this as a tool to be used for Automatic Server Provisioning Validation purpose by all teams.
Purpose Introduction• Saving time and human cost
Since all jobs can be implemented in an automatic way, it does not need too much human interaction. Regardless some maintenance work, we can quickly do the order, provision and validation work.
• Reliability and Steadiness
Since this is a complicated process involving a vast number of checkpoints that need validation for each Linux and WIN server, AT do it constantly along with the same codes, testing data and checkpoints which making sure the results are accurate.
• Continuity
Technically under the circumstance that it is stable and we have enough resources in the DCs, it can be run 24*7 without manual intervention.
• Currently, we cover two scenarios
1. [Order a server in xxx portal / xxx API] > [check provision status of xxx portal] > [Verify the server ordered is implemented correctly in data center ]
2. [Get an existing server reservation of xxx portal] > [check provision status of xxx portal] > [Verify the server ordered is implemented correctly in data center ]
Purpose Introduction
Structure View
Data Base
Win Jump
Station A
Linux Jump
Station A
Backend Win
Server A
Backend Linux
Server A
SikuliX v1.1.0
Secure Shell Tunnel PuTTY v0.6
Use CMD to query information of Backend server
More Information:• Developed Java• Deployed by Maven• Executed by ATester
Test Computer Group
Secure Shell Tunnel PuTTY v0.6
Use SQL to query information of Portal’s server order
DB Jump Station A
Test computer
A
Provisioned Servers
Xxx API Server
Use API to query information of Portal’s server order
Openstack APIs
3rd Tool required:• IBM STAF
deployed
Automation Test Case (which is in charge of acquiring and comparing server’s information.)
Windows Automation solution
Solution PrincipleE2E for Linux server:
1. Environment: xxx DB, xxx API, Local test machine, Linux jump station, servers in data centers
2. Communication: • Local test machine - portal: we use restful client to call existing APIs of portal, and use ODBC to contact DB of portal• Local test machine - server of Data Center: We use Putty to build SSH tunnel to map server of data center from
Linux jump station to local test machine.
3. Validation Approach: • use Secure Shell command to control the server of data center and then we can get/update information of that
server.• Store the information in local test machine and use that to compare with the information of server that we got
from xxx DB.
Solution PrincipleE2E for Windows server:
1. Environment: xxx DB, xxx API, Local test machine, Linux jump station, servers in data centers
2. Communication: • Local test machine - portal: we use restful client to call existing APIs of portal, and use ODBC to contact DB of portal• Local test machine - server of data center:
a. We use SikuliX to remote access jump station and then jump to the server of Data Center.b. Once remote desktop is connected, we use RDPClip.exe to send/get information.
3. Validation Approach: • Copy BAT file (windows cmd line, powershell cmd line) to the server of Data Center and then we can get/update
server of data center.• Store the information in local test machine and use that to compare with the information of server that we got
from Portal’s DB.
Roles in code• Class for storing information of server of Portal:
ServerInfoBean: use to store all information of Linux/windows server
• Class for getting information of server of Portal :ServerOrder: it has methods to get information of server of portal and will store all the information in above class “ServerInfoBean”.Some Methods:o createServer: Place a server order in Portal.o waitForProvisionCompleted: Wait for that server order is provisioned in Portal.o getLatestServerInfo: get the latest information of server of Portal.
Roles in code• Class for storing information of server of Data Center:
1. RealLinuxServerInfoBean: use to store all information of Linux server. (such as cpu, memory, ip, timezone, swap size … )2. RealWinServerInfoBean: use to store all information of Windows server.
• Class for getting information of server of Data Center:RealServerInspector: it has methods to get information of server of Data Center and will store all the information in above two classes “RealLinuxServerInfoBean” and “RealWinServerInfoBean”.Some Methods:o connectToLinuxServer: connect to linux server.o setupSSLTunnelInLocal: bulid the tunnel in local Env.o tourLinuxCPU: get the cpu info from linux server.o connectToWinServerThroughWinJumpStation: connect to windows servero tourWindAllInfo:get all information what we need to check
JUnit Test Case
ServerOrder
ServerInfoBean
RealServerInspector
RealWinServer
InfoBean
RealLinuxServer
InfoBean
Checkpoint
Roles in code• Class for translating terminology of OS/software/..between Portal and Data
Center:ElemenntNamingOfServerTranslator: use to translate term between Portal and Data Center.
• Class for writing test case:JUnit test case: use normal Junit test case to call above classes to cover test flow.
Covered Checkpoint
Q&A