2. Backend Server Validation -
Automation
Background Introduction
Purpose Introduction
Structure View
Solution Principle
Roles in code
Linux/Windows checkpoint
Q&A
3. Background Introduction
XXX 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.
4. 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.
5. • 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
6. 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
Provisione
d 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
7. Solution Principle
E2E 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.
8. Solution Principle
E2E 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.
9. 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.
10. 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 server
o tourWindAllInfo:get all information what we need to check
