Many development projects delay the testing process for as long as possible in the development lifecycle, sometimes until the final activities prior to application deployment. The many types of testing activities include unit testing, system testing, and regression testing. All of these activities share the objective of producing a high-quality application that satisfies user requirements. Delaying testing activities until the end of the project is risky, and in many situations, it can cause projects to fail, go over budget, and miss their deadlines. Incorporating the testing activities into all development phases is becoming a preferred method for reducing project risk and enabling projects to succeed.
Final Exam C/S-Test provides an opportunity to automate the testing process and build a standard testing framework for all phases of the application development cycle. Final Exam C/S-Test supports automated testing of three-tier client/server applications in heterogeneous environments. The tool lets users build custom test scripts, test client platforms across a TCP/IP network, simulate various loads, and examine application code.
The tool offers an intuitive Windows-based interface with pulldown menus, command buttons, and extensive help facilities. A File menu option allows manipulation of test script files. A Record menu option enables the record process that captures keystrokes to be started and stopped. A Replay menu option gives users sophisticated control over the replay process, including step control, evaluation control, and view manipulation. An Option menu option enables global and script defaults to be manipulated, and a Network menu option allows testing in a distributed environment.
The testing tool is accompanied by both an online and a printed tutorial to support a quick start. Product specialists are also available by phone to talk new users through the tool.
Test script default values can be modified prior to replaying a script. A series of scripts can be recorded and archived to support an integrated testing strategy. Figure 1 shows a script that is generated when the Microsoft Notepad application is used while a record session is active.
Final Exam C/S-Test lets users compare expected results to actual results. The session record feature or a capture utility defines the expected results, which can be compared to actual results using the following verification methods supported by the product:
During testing, users will, of course, encounter application problems. These problems can be handled asynchronously. The Exception handling function traps exceptions such as General Protection Faults (GPF) and division by zero. A report of problems encountered during testing is produced.
Some degree of abstraction exists in the test scripts, which can support some application-level changes without requiring a change to the script. In some cases, scripts can be modified with minor changes to support application-level changes. One example is manually changing the name of a data field or output file.
TML programs can be nested, and one TML program can consist of many modules. A TML script consists of a combination of statements and declarations, as shown in the following simple program:
is // TML: Testing Sample
message = "Test Started"
print "!!!!!" message "!!!!!"
//
// testing statements
//
message = "Test Ended"
print "-----" message "-----"
Like the C programming language, TML supports sophisticated storage classes, including constants, datatypes, global variables, and arrays. It also supports C-like arithmetic, operator precedence, Boolean operations, string operations, and increment operations. Extensive programming constructs are supported by TML. Repeat logic commands include "do," "for," and "while." Conditional constructs and related commands include "if," "continue," "break," "exit," and "return."
TML is packaged with a rich set of functions similar to those contained in the standard C library. TML also supports extended functions such as RemoteCallerName and SendMessageToTML that are specific to the testing tool. GUI functions correspond to controls such as Windows, Child window controls, Buttons, Edit boxes, Menus, List boxes, Combo list boxes, Scroll bars, and Scroll bar controls. The verification functions are Compare, CompareFile, GetText, GUICompare, WaitCompare, and WaitGUICompare. TML also supports user-defined functions and passed arguments.
User Access Routines (UAR) support calls to third-party code from within a TML script without the need to relink. UAR enables functions to be written in any language, and it permits testing of elements, modules, hardware device interaction, database access, and data structures. UAR routines are executed as a call to an .exe file created by UAR Builder. They also accept arguments and return values to TML variables.
The basic approach for distributed testing is to select a platform to act as the testing server, and then to identify clients through IP addresses. TCP/IP and winsock.dll are required by C/S-Test Net Server. Test scripts are executed on every remote client platform involved in the test through a TML command.
Testing in the distributed environment can involve simulating different numbers of users and various loads. It is also possible to test database concurrency, deadlock situations, and live-lock situations. Communication between client platforms can be synchronous and asynchronous. Generated reports can be used to analyze the results of tests, which can be scheduled during non-peak times.
According to Hal Shields, product specialist for Final Exam products, the tool suite will be expanded through email enablement, built-in defect tracking, integration with monitoring and system management tools, and support for a Unix environment.
