DSSI has developed and regularly uses a Regression Test Tool to speed delivery and improve the quality of custom developed web-based applications. The W3eb Enterprise Regression Test (WERT) allows DSSI to rapidly build, test, deploy and maintain complex web-based applications for our customers. This same tool, used in conjunction with our testing department, enables us to provide independent testing to any customer across a wide range of web-based applications.

The ability to document test steps, expected responses, and actual execution of a sequence of test procedures within one integrated environment facilitates rapid development, ensures quality, and reduces overall cost. Once operational test procedures are created within the tool, it creates and can replay test scenarios which automate the generation of Unit, Integration, Regression and ATP documentation. Use of this tool ensures that as a web-based application is developed, modified or enhanced, it still correctly performs all previously tested functions.

Beyond testing for proper function, the W3eb Enterprise Regression Test also has the capability to stress test an application. By replaying test scenarios from several hosts at once, the tester simulates multiple online users while measuring request-to-response times.
     
 

Functional High-Level Overview

The mission of the Virtual Tester is to perform product testing on web-based (browser/http/ejb) applications. The system captures (records) a sequence of requests and responses via a built-in proxy when a system is first tested. Later, these recorded requests can be replayed to the web-based application and its responses can be compared against the originally recorded responses. The W3eb Enterprise Regression Test is separated into two major functional components: the Client and a distributable Server. The Server and Client components communicate via standard TCP utilizing XML as the transfer data format. The Server is implemented using Java and is cross platform compatible. The Client is implemented as a Windows native application.

  
       
 

Client

The Client implements a proxy that is used to intercept the requests from a browser to a web-based application and the responses coming back. It records this information as testing personnel exercise the target web-based application. The Client then sends this recorded scenario to one or more hosts running the Server.

Later, when the host(s) replay the recorded scenario, the Client receives the new results returned from the host(s) (where the responses have been compared), and presents this as a report. The Client has a multitude of other responsibilities. These include, but are not limited to:

  • Ability to view and edit all project, test, procedure or request/response data.
  • Tracking project, test, procedure, step, and request/response hierarchies.
  • Repository for keeping notes, overviews, requirements and other text for each test, procedure, or step.
  • Facilities for user specification of hosts (computers running the server piece).
  • Facilities for specifying commands to run on hosts.
  • Ability to specify variables for variable substitution and variable forwarding. This is in support of dynamic fields that change from one web session to the next.
  • Print or generate a test procedure document based on defined test steps. Output to MSWord.
  
     
  Server

The Server is responsible for replaying a recorded session and executing specified system commands. It does this by receiving session XML from the Client, which specifies all operations to be performed. A set of system commands can be defined for execution within each procedure. The Server runs the specified system commands for the test procedure (which can be specified to be run on another host), sends out the recorded http requests and then evaluates the responses against the originally recorded responses. The Server then generates a report and sends it back to the Client. System commands are typically used to setup a database in preparation for a test run of a web-application that utilizes the database and also to provide a mechanism for running or simulating server side processes.
The Server is also responsible for proper variable substitution and variable forwarding as defined by the XML provided to it by the Client. Variable substitution allows different values to be used in subsequent tests than were used originally. An example of the need for substitution might be login names. When playing back a scenario for repeatability testing, it is often desirable to specify a different login name than what was recorded during the original test.

Variable forwarding is the ability handle portions of a web response that are different each time you make the request. If a request results in a web page response that contains a generated value that must be used in subsequent requests, this can be specified as a variable and the Server will dynamically set this variable from each response and use it in subsequent requests. Additionally, if a test exercises a web page that generates a unique number, such as a page hit counter, changes of that field can be set to be ignored.