background image
<< Client/Server Testing - The Acquire function | Client/Server Testing - Incremental functional test design >>
Client/Server Testing - Reporting distributed results
<< Client/Server Testing - The Acquire function | Client/Server Testing - Incremental functional test design >>
372
User's Guide
21 I
MPLEMENTING
C
LIENT
/S
ERVER
T
ESTING
Reporting distributed results
Example
Suppose you are running a distributed test on eight machines
using eight 4Test threads. Assume that the application you are testing
accesses a database, but can support only three simultaneous users. The
following code uses a semaphore to handle this situation:
SEMAPHORE DBUsers = 3
...
Acquire (DBUsers)
access database
Release (DBUsers)
The declaration of the semaphore is global; each thread contains the code to
acquire and release the semaphore. The initial value of three ensures that no
more than three threads will ever be executing the database access code
simultaneously.
How 4Test handles
script deadlock
It is possible for a multi-threaded 4Test script to reach a state in which
competing threads block one another, so that the script cannot continue. This
is called script deadlock.
When the 4Test runtime environment detects deadlock, it raises an exception
and halts the deadlocked script.
For example, the following script will never exit successfully:
share INTEGER iIndex1 = 0
share INTEGER iIndex2 = 0
main ()
parallel
access iIndex1
Sleep (1)
access iIndex2
Print ("Accessed iIndex1 and iIndex2")
access iIndex2
Sleep (1)
access iIndex1
Print ("Accessed iIndex2 and iIndex1")
Reporting distributed results
You can view test results in each of several formats, depending on the kind of
information you need from the report. Each format sorts the results data
differently, as follows: