A script that was recorded with the Silk Performer Recorder provides a good starting point for a load test. However, such
a raw script usually has two main downsides: It will not produce realistic results and it will not be particularly robust.
It is likely to cause errors during replay.
To make your scripts as robust as possible, it is recommended to customize them before you start a load test. When customizing
your script, consider the following:
-
Appropriate test data: Most applications require appropriate test data. Make sure to customize your script in a way that makes virtual users employ
appropriate user names with correct access rights. If your virtual users execute transactions concurrently, you will probably
need to define different user IDs.
-
Dynamic content: Often, the content of an application is dynamic, like link names that change, items being no longer available, products
in a web shop being out of stock, and so on. Also, real users usually pursue different paths through an application. A recorded
script, however, only contains one specific path. The path may also vary based on time, user, or other conditions.
-
Not available applications: When you start your load test, the application under test might not be available, not yet ready, or a database connection
is not yet established. Make sure that your script handles these circumstances appropriately.
-
Timing issues: Some BDL functions use default timeout settings that might not be appropriate for your testing scenario. Adjust these timeout
settings to fit your specific needs and to avoid errors.
-
Concurrency issues: Controlling concurrence issues also helps to avoid errors. Your database might be able to respond to only a few virtual
users concurrently. Controlling concurrency also helps to make behavior of virtual users more realistic: Real users usually
perform one specific task not all at the same time but in a staggered manner. The serialization, synchronization, and rendezvous
functionalities of Silk Performer allow you to precisely control the desired behavior of your virtual users.
To make your script even more robust, also consider the following error scenarios. Reflect about how your virtual users are
supposed to act when an error occurs. The virtual users can …
-
skip the remaining part of a transaction: This action might be appropriate when a virtual user attempts to buy an item in a web shop that is not in stock at that
time. The virtual user could skip that particular transaction and continue with executing the next transaction. Such a behavior
can be achieved with a return statement.
-
stop the load test: This action might be appropriate when a database connection cannot be established and the application under test cannot
be used without this connection. In such a case, continuing the load test would not be possible. Such a behavior can be achieved
with a halt statement.
-
handle an error and continue executing the transaction: This might be useful when a virtual user enters a wrong password on a login page. If the script could handle such a login
error, the virtual user could attempt to login with a different password and might be able to continue executing the rest
of the transaction. Such a behavior can be achieved with error-handling functions.