Client/Server - Functional testing
need to write specific scripts that synchronize two clients to make requests of
the same records in your server's database(s) at the same time. Your goal is to
encounter faulty read/write locks, software deadlocks, or other concurrency
problems. See "Code for concurrency test example" on page 389 for an
example of a test that demonstrates the necessary 4Test coding techniques.
conditions that might be reached by large numbers of transactions. The next
sections describe this kind of testing.
a large number of times does not break the software. For example, stress
testing discovers a failure to release resources. This is no different than stress
testing for a non-distributed application, but as with functional testing, you
need to discover whether the application functions properly with a remote
server under stress conditions. You can do this type of stress testing with a
single client.
of times. Usually, the 4Test code looks like this:
application operations that allocate significant amounts of memory (to see if
they release that memory). One simple form of stress testing is to set up your
functional tests to repeat indefinitely and then run them night and day over a
two- to four-day period.
not break the server or client software. For example, load testing discovers
deadlocks and problems with queues. SilkTest's unique architecture provides
built-in load testing. You can implement your functional tests using multi-
application techniques and then, after completing functional testing on a
single machine, you can run them on multiple targets. Unlike simulated load
testing tools, SilkTest allows you to create a real-life scenario that can
determine the actual impact of multi-machine operation on your application,
the server, the network, and all related elements.
called stress testing in the client/server environment) and volume.
the heaviest demand that would be generated at peak user times--for
example, credit card verification between noon and 1 PM on Christmas Eve.