Due to the volumes of data required and the need to apply load to all parts of the system, test data is critical for performance testing. Ordinarily this would factor in the expected concurrent number of users on the application, performing a specific number of transactions within a set duration.
This article explores the key data types and elements that should be considered when analysing and designing the data requirements.
To understand the data requirements required to execute a performance test we need to consider the following key questions.
- What types of data will we need? For example, static/reference, transactional or bulk data?
- What volume of data will we need?
- How will the data be obtained? Will it be restored from a backup?
When asking the above questions, one should also consider how we are going to create the data items and how we can make sure they are in the system to enable the performance test to run successfully?
What types of data do we need?
1. Reference Data (sometimes known as Static data)
Reference data is data that must exist on the database prior to test execution as it will be referenced by the transactions executed against the database during testing. A couple of examples are brokers details and valid banks. Outline all the reference data that will be required to support the testing.
2. Transactional Data (sometimes known as Dynamic data)
Transactional data is the data that virtual users will enter to simulate user actions. Typically, this includes data typed by the user in the application, without necessarily requiring this data to already exist in the system i.e. parameterised details of transactions that are to be executed during testing. For example, a purchase transaction would need the card data of the buyer, the card number, and the buyer’s details. Outline all the transactional data that will be required as parameter data for scripts.
3. Bulk Data
Bulk data is data that must exist on the database but is unchanged throughout testing. For example, data that is not functionally necessary to the test, but which allows the performance test to run against a more realistic system. This could be historical data, despite the fact the test itself makes no use of it, this data is often used to create realistic searching on an application. An example of this would be a customer search function that would typically require the total number of customers setup, or populated from the production environment into the test environment. Outline all the bulk data that will be required to support the testing. Generally, this data will not need to be refreshed between tests.
How much data do we need i.e. volumes etc.?
Outline all the volumes of data items specified above and include any constraints the items may have. For instance, are they unique? i.e. If we want to test the retrieval process of invoices, we will require 200,000 unique invoices within the system.
How will it be provided?
Outline any of the below methods that will be used in the provision of the data.
- A backup/restore approach
- Database refresh approach
- Loading of data approach if it is not as simple as a restore process
- Any other approaches to be taken.
In conclusion it is important that all the above test data requirements are specified and considered prior to a performance test being executed. To see how SQA Consulting may assist your company in performance testing your applications, please contact us
