3. Client/Server Testing in Different Layers:
3.1. Testing on the Client Side—Graphic User Interface Testing:
3.1.1 The complexity for Graphic User Interface Testing is due to:
a. Cross-platform nature: The same GUI objects may be required to run transparently (provide a consistent interface across platforms, with the cross-platform nature unknown to the user) on different hardware and software platforms
b. Event-driven nature: GUI-base applications have increased testing requirements because they are in an event-driven environment where user actions are events that determine the application’s behavior. Because the number of available user actions is very high, the number of logical paths in the supporting program code is also very high.
c. The mouse, as an alternate method of input, also raises some problems. It is necessary to assure that the application handles both mouse input and keyboard input correctly.
d. The GUI testing also requires testing for the existence of a file that provides supporting data/information for text objects. The application must be sensitive to the existence, or nonexistence.
e. In many cases, GUI testing also involves the testing of the function that allows end-users to customize GUI objects. Many GUI development tools give the users the ability to define their own GUI objects. The ability to do this requires the underlying application to be able to recognize and process events related to these custom objects.
3.1.2 GUI testing techniques: Many traditional software testing techniques can be used in GUI testing.
a. Review techniques such as walkthroughs and inspections [8]. These human testing procedures have been found to be very effective in the prevention and early correction of errors. It has been documented that two-thirds of all of the errors in finished information systems are the results of logic flaws rather than poor coding [9]. Preventive testing approaches, such as walkthroughs and inspections can eliminate the majority of these analysis and design errors before they go through to the production system.
b. Data validation techniques: Some of the most serious errors in software systems have been the result of inadequate or missing input validation procedures. Software testing has powerful data validation procedures in the form of the Black Box techniques of Equivalence Partitioning, Boundary Analysis, and Error Guessing. These techniques are also very useful in GUI testing.
c. Scenario testing: It is a system-level Black Box approach that also assure good White Box logic-level coverage for Client/Server systems.
d. The decision logic table (DLT): DLT represents an external view of the functional specification that can be used to supplement scenario testing from a logic-coverage perspective. In DLTs, each logical condition in the specification becomes a control path in the finished system. Each rule in the table describes a specific instance of a pathway that must be implemented. Hence, test cases based on the rules in a DLT provide adequate coverage of the module’s logic independent of its coded implementation.
In addition to these traditional testing techniques, a number of companies have begun producing structured capture/playback testing tools that address the unique properties of GUIs. The difference between traditional capture/playback and structured capture/playback paradigm is that capture/playback occurs at an external level. It records input as keystrokes or mouse actions and output as screen images that are saved and compared against inputs and output images of subsequent tasks.
Structured capture/playback is based on an internal view of external activities. The application program’s interactions with the GUI are recorded as internal ‘events” that can be saved as “scripts” written in some certain language.
3.2 Testing on the Server Side---Application Testing:
There are several situations that scripts can be designed to invoke during several tests: load testing, volume tests, stress tests, performance tests, and data-recovery tests.
3.2.1 Client/Server loading tests:
Client/Server systems must undergo two types of testing: single-user-functional-based testing and multiuser loading testing.
Multiuser loading testing is the best method to gauge Client/Server performance. It is necessary in order to determine the suitability of application server, database server, and web server performance. Because multiuser load test requires emulating a situation in which multiple clients access a single server application, it is almost impossible to be done without automation.
For the Client/Server load testing, some common objectives include:
· Measuring the length of time to complete an entire task
· Discovering which hardware/software configuration provides optimal performance
· Tuning database queries for optimal response
· Capturing Mean-Time-To-Failure as a measure of reliability
· Measuring system capacity to handle loads without performance degradation
· Identifying performance bottlenecks
Based on the test objectives, a set of performance measurements should be described. Typical measurements include:
· End-to-end response time
· Network response time
· GUI response time
· Server response time
· Middleware response time