Client/Server Testing Configurations

The processes that participate in a client/server testing scenario are logically associated with three different computers:

System A runs Silk Test Classic, which processes test scripts and sends application commands to the agent.
System B runs the client application and the agent, which submits the application commands to the client application.
System C runs the server software, which reacts to requests submitted by the client application.

The following sections describe different hardware/software configurations that can support Silk Test Classic testing.

Configuration 1

Machine 1 shows the software configuration you would have when testing a stand-alone application. Machine 2 shows Silk Test Classic and a client/server application with all of your software running on one machine. This configuration allows you to do all types of functional testing other than testing the behavior of the connection between a client and a remote server.

$image\fig1_cs_intro.gif$

During your initial test development phase, you can reduce your hardware needs by making two (and possibly all) of these systems the same. If you write tests for an application running on the same system as Silk Test Classic, you can implement the tests without consideration of any of the issues of remote testing. You can then expand your testing program incrementally to take your testing into each new phase.

Configuration 2

A testing configuration in which the client application runs on the same machine as Silk Test Classic and the server application runs on a separate machine.

Note: In this configuration, as with Machine 2 in Configuration 1, there is no communication between Silk Test Classic and the server. This means that you must manage the work of starting and initializing the server database manually. For some kinds of testing this is appropriate.

$image\fig2_cs_intro.gif$

This configuration lets you test the remote client-to-server connection and is appropriate for many stress tests. It allows you to do volume load testing from the point of view of the client application, but not the server.

Configuration 3

Multiple copies of the client application running on separate machines, with Silk Test Classic driving the client application by means of the agent process on each client machine, and the client application driving the server application. This is just the multi-client version of the previous configuration. You could run a fourth instance of the client application on the Silk Test Classic machine. The actual number of client machines used is your choice.

$image\fig3_cs_intro.gif$

This configuration is appropriate for load testing and configuration testing if you have no need to automatically manipulate the server. You must have at least two clients to test concurrency and mutual-exclusion functionality.

Configuration 4

Once you are running Silk Test Classic, it makes sense to have your script initialize your server automatically. Configuration 4 uses the same hardware configuration as Configuration 3, but Silk Test Classic is also driving the server directly. This figure shows Silk Test Classic using an agent on the server machine to drive the server’s GUI (the lower connecting arrow); this approach can be used to start the server’s database and sometimes can be used to initialize it to a base state. The upper arrow shows Silk Test Classic using SQL commands to directly manipulate the server database; use this approach when using the agent is not sufficient. After starting the database with the agent, use SQL commands to initialize it to a base state. The SQL commands are submitted by means of Silk Test Classic’s database functions, which do not require the services of the agent.

$image\fig4_cs_intro.gif$

Configuration 4 is the most complete testing configuration. It requires the database tester. You can use it for all types of Silk Test Classic testing, including volume load testing of the server, peak load testing, and performance testing.

The special features that allow Silk Test Classic to provide rigorous testing for client/ server applications are the following:

Automatic control of multiple applications.
Multithreading for automatic control of concurrent applications.
Reporting results by thread ID.
Testing across networks using a variety of protocols.

The added value that the database tester provides for the client/server environment is direct database access from the test script.