Testing Siebel eBusiness Applications > Automating Load Tests >

Best Practices for Load Testing

This section outlines some best practices that should be considered when developing and executing load tests on your Siebel applications. The following best practices are provided:

• Preserve Environment During Recording and Running Load Tests
• Preserve List States During Recording and Running Load Tests
• Make Scenarios and Transaction Definitions Granular
• Eliminate Message Bar Traffic from Transactions
• Preserve a Base State for Iterative Actions
• Make Iterative Actions Self-Sufficient
• Reset the SWE Count for Iterative Actions
• Avoid Concurrency Errors in Update Operations
• Stabilize Response Time Before Terminating Test
• Parameterize User Key Fields, Dates, and Time Zones
• Make Data Value Parameters User-Specific
• Make Sure User Role and Position Are Compatible

In addition to these tips, you should also read and understand Execute Performance Tests.

Preserve Environment During Recording and Running Load Tests

Make sure that the environment when running a load test is in the same state as it was when the test was recorded. Changes to the operating environment might require tests to be rerecorded.

Preserve List States During Recording and Running Load Tests

A Siebel application that contains a list applet can return one or more records in response to a query. It can also return zero records. Both of these can be expected outcomes. When conducting load tests on a Siebel application that contains a list applet, make sure that the expected state of the list (either with records or without records) is the same during the recording session as it will be during the execution of the test. Failure to do so will result in a test error. If necessary, you can add a record before recording the test.

Make Scenarios and Transaction Definitions Granular

Where possible, break scenarios into several smaller scenarios to focus the tests. Make sure transaction definitions are granular enough to be able to pinpoint performance issues to specific GUI actions.

Eliminate Message Bar Traffic from Transactions

Eliminate HTTP traffic related to the message bar from transactions. Put message bar requests into your script outside of transaction blocks. Put one message bar request into your test script after every 120 seconds of wait time.

Preserve a Base State for Iterative Actions

When setting up repeatable or iterative actions, make sure to leave the application in a base state from where the next iteration can pick up and complete successfully. Home page is a good example of such a base state.

It is also important to maintain the number of rows displayed in a list applet, or the number of controls displayed in a form applet. If Show More is clicked during the test, then Show Less must also be clicked before the end of the test.

Make Iterative Actions Self-Sufficient

An iterative action has to be self-sufficient in that all the correlations have to originate and end within the action. Values for correlated variables should not come from a previous action (which may or may not be iterative).

Reset the SWE Count for Iterative Actions

At the beginning of each iterative action, make sure that you reset the SWE Count to the SWEC value of the first request in the iteration.

Avoid Concurrency Errors in Update Operations

In tests that involve update operations, make sure you are using different virtual users or make sure the same virtual user accesses different records to avoid concurrency errors.

Stabilize Response Time Before Terminating Test

When running a load test, wait for the response time to stabilize before stopping the load test.

Parameterize User Key Fields, Dates, and Time Zones

Make sure that user key fields are parameterized. Dates should be parameterized, especially variable dates (such as today's date or tomorrow's date). Time zones should also be parameterized. If you do not parameterize time zone values, your script will fail for virtual users who are not set up to use the time zone in which the test was recorded.

Make Data Value Parameters User-Specific

Set up your data value parameters to be specific for each virtual user (for example, User1 logs in and searches for Contact1 while User2 logs in and searches for Contact2). Each virtual user should have its own subset of the data in the database.

Make Sure User Role and Position Are Compatible

Siebel applications restrict a user's ability to perform actions based on the roles and positions associated with the user. Make sure that the roles and positions of the users are compatible and allow the user to perform the required actions.