WLM Concept

5. Identify Unique Test Data

Unfortunately, identifying selected scenario’s all possible navigation paths doesn’t provide all the information required to successfully simulate them in a performance test. Several bits of information is still required to accurately simulate the workload model and preparing the required test data is one of them. You can never achieve accurate test results with improper or inefficient test data. One can develop an initial idea about the required test data by getting answers of the following queries:

• While navigating through a specific path, how much time a user spend on a page?
• Which conditions force the user to alter the navigation path?
• What input data should be required for a specific path?

Following table will show you an example of unique input data for browsing product catalog scenarios of an E-commerce application

You will also require a greater amount of test data and you need to keep an eye on the data base state if you wish to effectively run the test. Following are the few considerations which should be followed while executing a performance test where multiple navigation paths are tested for identified scenarios:

• Make sure that you have all the required test data as you will need more test data when you are testing scenarios with all navigation paths.
• Avoid using same test data for multiple users as it will produce invalid results.
• Periodically test the database status during the test execution and make sure it’s not overloaded.
• Include some invalid test data as well to simulate the real users’ behavior because users sometimes provide invalid values as well.

6. Relative Load Distribution Across Identified Scenarios

Main step is to figure out the distribution of all the identified scenarios in your workload model. It’s quite obvious that in any application few scenarios are executed more frequently as compared to others. Moreover, for some applications’ scenarios the execution also depends on relative time. For example, for an online billing application where bill payments are made only during first week of the month, the administrator will be using the application mainly for accounts updating and importing billing information etc. So you need to figure out which AUT scenarios will be executed at what time and what will be their execution percentage in the overall workload. Following techniques could be helpful in identifying relative distribution of your identified scenarios:

• Check out the server log files to identify users’ trends on application if it is in the production environment.
• Consult with the sales and marketing teams to figure out which features they believe will be mostly used.
• You can also interview the existing and potential clients to find out in which features they are most interested.
• In case none of the above mentioned approaches work then use your experience and intuitions to get the answers of your questions.

For example for an e-commerce application, the identified scenarios distribution could be as follows:

7. Identify Target Load Levels

One last step involved in workload model completion after performing all the above mentioned activities is to identify the normal and peak load levels of every selected scenario to test the application for expected and peak load conditions. Mainly depending upon the application you need to identify the monthly, weekly, daily and hourly average load targets for every selected scenario. You need to know the following information in order to identify the target load levels for an application:

• What are the current and expected normal and peak user requests level?
• What are the application key test scenarios?
• What is the distribution of user requests on the identified scenarios?
• What are the navigation paths for all the scenarios along with relative utilization of every scenario?

Following table will summarize what kind of information you need while identifying the target load levels for any scenarios

Pages: 1 2 3