Advertisements
In any real world scenario, not all users will do the same transaction. In order to simulate the same, the Performance Analyst must determine the mix of transactions/mix of browsers for every test that needs to be conducted. For ex: Some of your clients may be using IE and some may be using Mozilla
You need to have the data of % of usage. [Which you should collect during Requirement Collection]
| Type Of Browser | Transaction Name | % Of User |
| Mozilla | Search | 20 |
| IE | Search | 50 |
| Opera | Search | 30 |
Similarly, the transactions itself can be divided based on the Percentage of usage of that application
| Transaction Name | % Of Users |
| Login Search | 60 |
| Login Add Users | 20 |
| Login Delete Users | 20 |
4. Methodology for Tool selection
There are a number of Performance testing tools available in the market .The following are some of the considerations for selecting a Performance testing tool
- Look at the budget for the tool
- Look for the types of possible licensing available
- Understand the technologies that are used by your Client in the Application under test and the Protocols that you need the tool to support. Also look for future usage
- Evaluate the tools that support the protocols desired
- Check for ease of scripting, reporting features, Monitors, root level diagnosis abilities etc. This will help you estimate the time required for the tests and for reporting.
5. Considerations while scripting those transactions
When our performance test design calls for a replay of thousand's or million's of users, it is very likely that the data should be random or diversified across the different simulated transactions. It should be easy to assume that all the users in the world don't exchange the same data. We are all unique, different and dynamic. Thus, for our load testing to simulate the real-world, the scripts must support the dynamic and varied parameterization of data values in the script and not just use hard-coded values.
Let's talk about the two known ways of making the data random/dynamic
- Parameterization
- Correlation
Parameterization: It is automatic replacement of hard coded data query values in a test script, so that different scripts can use different data. For instance if multiple virtual users login with the same ID, it does not simulate a real world scenario. So, we parameterize the 'Login ID 'with different values for every iteration.
For ex:
| Iteration | Virtual User | Login ID |
| 1 | 1 | Dave |
| 2 | 2 | Smith |
| 3 | 3 | Nancy |
Correlation: Correlation is reuse of data values as a test script is executed. For ex: �Consider a User goes to an online shopping center opens the product search page and does a query for the colors of Shirts available in a particular brand ('Brand1Shirts') The value of 'Brand1 Shirts' is assigned to the parameter searchStr, and posted: "query.aspx? str=searchStr"
Query returns 3 different brands of Shirts that user can choose the results of the query are saved into a parameter table:
| Colour | Product ID |
| Sky Blue | 12349 |
| Peach | 12560 |
| Light Pink | 12785 |
User chooses a Color randomly from the list of items returned. The value (say) '12560' is selected from the product table and saved in the productID parameter.
Now when 1000 users run the same transaction, you cannot have the same value for the ProductID. Also for different brands of shirts that the user searches there could number of ProductID's on the screen. In these situations we should correlate the data dynamically.
Why should we be using dynamic data while scripting? How does it matter?
There is a technical root reason that your load testing should include dynamic data values. When a system retrieves data from the database, copies of that data are saved in memory on different components throughout the system.
This can happen at many layers within the architecture of the system, from individual hard drives, storage controllers, in the operating system kernel and in the various buffer managers in the application's software. If you don't use dynamic data to continuously query for new data, the load test will not accurately flush the cache buffers throughout the system; and thus the system may seem to respond with faster than in the real world.
What next? �
My upcoming articles will talk about
- Creating test environments for different types of Performance tests
- How to Conduct different types of performance tests
- Some Common terminologies used while conducting Performance testing
- Some specific tools in Performance testing and their capabilities
- Analyzing different bottlenecks
