This appendix contains an example use-case definition taken from a real performance testing project. Figure A-1 demonstrates the sort of detail you should provide for each use case to be included in your performance test. The example is based on a spreadsheet template that I have developed to capture use case information.
Ideally, you should create a similar template entry for each use case that will be part of your performance testing engagement.
Please see the following for an explanation of the template contents:
Each use case should have a meaningful name such as “Bill Payment” in the example.
This is a calculated value based on the number of web page view per use case step where this is relevant.
The order that this step occurs in the use case.
There are three options available:
Whether this use case step is to occur only once at the start of a performance test.
Whether this use case step is to be iterated during performance test execution.
Whether this use case step is to be executed only once at the end of a performance test.
A description of the user action required for this use case step (e.g., step 1 requires the user to “Enter online banking number, an Internet password, and then click Continue”).
A label to identify the use case step during performance test execution and analysis (e.g., the timing name for step 1 is “Login Step 1”).
It is a common for use case steps to require data entry. This section of the template attempts to capture information about any test data that may be required.
The origin of the test data. This could be an external data file as indicated against step 1. Alternatively, it could simply be a hardcoded value or provided by the Client UI as indicated for the other use case steps.
The name of an external data file if this contains the test data required.
Any limits on the upper or lower value of the test data required (e.g., the requirement may be for a range of values between 1 and 100).
The number of unique test data items required (e.g., step 1 requires 2,500 unique sets of login credentials).
Whether there is a service level associated with this use case step. Typically a maximum response time.
If any delay or pause should occur before execution of the next use case step.
Whether this use case step results in one or more web page views. A useful thing to know when creating a load model if one of your performance targets is based on a certain number of page views per second.
18.116.50.87