Appendix A. Use-Case Definition Example

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.

Figure A-1. Sample use-case definition

Please see the following for an explanation of the template contents:

Use Case 1

Each use case should have a meaningful name such as “Bill Payment” in the example.

PageViews

This is a calculated value based on the number of web page view per use case step where this is relevant.

Step

The order that this step occurs in the use case.

Section

There are three options available:

Init

Whether this use case step is to occur only once at the start of a performance test.

Body

Whether this use case step is to be iterated during performance test execution.

End

Whether this use case step is to be executed only once at the end of a performance test.

Action

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”).

Timing name

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”).

Step test data (as appropriate)

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.

Source

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.

Filename

The name of an external data file if this contains the test data required.

Range

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).

Volume required

The number of unique test data items required (e.g., step 1 requires 2,500 unique sets of login credentials).

Step SLA

Whether there is a service level associated with this use case step. Typically a maximum response time.

Post-step think time

If any delay or pause should occur before execution of the next use case step.

Page view

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.