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