Automated Testing Tools
11.4 TEST TOOL TOUCHPOINT PARADIGMS
There are only two touchpoint paradigms that underlie the large number of avail- able test tool products. A test tool touchpoint is the location of a test tool probe, either hardware or software, in the computer under test in order to measure some specifi c operational aspect of this test computer. The situation is similar to the small number of software development paradigms we found in Chapter 2 for a large number of software development methods. If we understand these two touchpoint paradigms, we can quickly understand and anticipate how a particular test tool will be used.
11.4.1 Touchpoint Paradigm for Functional Test Tools The fi rst touchpoint paradigm is used by functional testing tools. The goal of this paradigm is to directly operate a computer as if the end-user was performing the actions from his or her chair. Terms frequently used to describe this operation are
“autopilot” and “robot mode.” It is a little strange for a programmer or end-user to observe this tool paradigm in action for the fi rst time: the screen is changing, the cursor is moving, menu entries are selected, data fi elds are being typed in … with nobody sitting in front of the computer. In order to succeed at this autopilot operation, the test tool must be able to record and play back actions from the key- board, the mouse, and the computer monitor. These touchpoints are collectively referred to as “foreground” touchpoints because their actions are observable by the end-user. Figure 11.2 illustrates the location of the touchpoints for functional test tools.
The functional touchpoint paradigm is implemented by tool software that runs on the same computer as the AUT. This one-to-one relationship between the tool computer and the test computer is necessary because the tool software must directly “observe” the interactions on the keyboard, mouse, and screen. This also represents a computer resource testing constraint. If you want to do functional testing for one business transaction at a time, you need one computer. If you want to do functional testing for two business transactions at the same time, you need two computers. If you want to do functional testing for 20 business transac- tions at the same time, you need 20 computers. There are no economies of scale.
Figure 11.3 illustrates this AUT–test tool computer relationship for functional testing.
Functional test tool touchpoints (foreground to end-user)
Mouse Screen
Keyboard
Figure 11.2 Touchpoint paradigam for functional test tools
11.4 Test Tool Touchpoint Paradigms 165
11.4.2 Touchpoint Paradigm for Performance Test Tools The second touchpoint paradigm is used by performance testing tools. The goal of this paradigm is to capture the messages and message timing passed between client computers and server computers that are all contributors to the AUT. The basis of this paradigm is the client/server computing architecture popularized in the early 1980s and made pervasive by the Internet. The client/server computing architecture distrib- utes the computing workload from the end-user’s computer to one or more specialized server computers. As an end-user operates the AUT, messages are periodically sent back and forth between the end-user’s client computer and one or more server com- puters elsewhere in a network. The nature of the messages is determined by the com- munication protocol. The total response time of an application is the sum of the pro- cessing times on all involved computers plus the sum of all communication times.
The performance touchpoint is referred to as a “background” touchpoint because its action is not observable by the end-user. Figure 11.4 illustrates the location of the touchpoint for performance test tools.
Functional test tool touchpoints (foreground to end-user)
Functional test tool executes here
AUT executes here
Figure 11.3 Computer necessary to execute functional tests
Networks
Performance test tool touchpoints (background to end-user)
Figure 11.4 Touchpoint paradigm for performance test tools
The performance touchpoint paradigm is implemented by tool soft ware that runs on a different computer than the one used to run the AUT. This makes the tool computer independent of the number of network- connected computers running the AUT. In this case, the tool software “observes”
the interactions among the application computers by watching the network traffic. Theoretically, one performance tool computer could record and play back an infinite number of client computer sessions to a very large number of servers. In reality, each client computer playback tool session re- quires a small but measurable amount of tool computer memory. So the practical upper limit of the number of client computer sessions that one performance tool computer can support is in the range of 500 to a few thou- sand, depending on the tool vendor’s design and available tool server memory.
This paradigm becomes even more attractive when you realize that once the recording session has been completed, zero client computers are required for the performance tool to play back the script and measure the workload on the server(s). There are definitely testing resource economies of scale here.
Figure 11.5 illustrates this AUT–test tool computer relationship for performance testing.
The really good news for testers is that the two touchpoint paradigms do not confl ict. Both touchpoint paradigms can be invoked by using functional test tools and performance test tools at the same testing time in the same testing environment.
Figure 11.6 illustrates how this dual paradigm can work.
Performance test tool executes here
...
Server(s) running the AUT
Intended end-users
of the AUT Could be
100s Could be
1,000s
Computers required for performance test playback
Computersnot required for performance test playback
Performance test tool touchpoint
Figure 11.5 Computer(s) necessary to execute performance tests
11.4 Test Tool Touchpoint Paradigms 167