Realistic Performance Testing | Practical Performance Scenario |

Realistic Performance Testing is one of the challenges for the overall project team. Performance Testing of any application or system has two primary objectives:

To find out the capacity of the system at the desired load
To find out the performance bottleneck which restricts the system to achieve the expected load.

Considering the above-mentioned two main goals, a performance tester designs the performance test strategy, approach and tool. All the performance testing tools follow the SEA pattern which means:

Scripting (Design)
Execution (Workload Modelling and Test Execution)
Analysis (Result)

SEA Pattern

The way of implementation of the SEA could be different for the different tools but the fundamental concept will be the same for all. To fulfil the objectives of the performance test, these tools simulate the behaviour of real-world users. The keyword here is a real-world user. The way of scripting and workload modelling plays a vital role to make a real-world performance test scenario. A performance test would be more realistic if it has the below items.

1. Real User Behaviour

In performance testing, the design of the test script reflects the behaviour of the real user. A test script comprises the steps which a user follows in the real world. A real user cannot be restricted to choose a particular option available on the website. He can click any link, input any character, jump to any tab, take his own time to read the page content, fill in the details etc. To simulate real user behaviour in performance testing, there are five important aspects which need to keep in mind while creating a test script:

Random Navigation: If there are 1000 users accessing a web application, it is not mandatory that all of them use the application for the same purpose. For example, a banking application can be used by users either to transfer funds, check their balances, add beneficiaries, download statements and many more. Each of these navigations should be recorded as a separate script. One more question may arise here, does a performance tester need to script all the real user flow available on the website? The answer is No; the performance tester needs to identify the critical business flow on the basis of expected user load and responsiveness. For example, 80% of users check their bank balance after login irrespective of the purpose they are logged in. Hence it is a critical business transaction because the request for account balance enquiry is hitting more than other requests. Another example of a critical business transaction in terms of responsiveness is that an intrabank fund transfer should be completed within 3 seconds.
Random Input: An application can have thousands of visitors or registered customers. Different people log in with different user names and passwords, search for different products, enter different shipping and permanent addresses etc. To simulate this behaviour, parameterization helps a lot in the test script. The parameter file should have a list of users and associated test data during the load test. In an ideal scenario, the number of unique test data should be equal to or more than the expected number of iterations in the test.
Random Selections: All the customers on a website do not have the same navigation flow. Once the users enter the application, their selections are different (from a dropdown, radio buttons, checkboxes etc). For example, if two users are searching for a flight from Mumbai to New Delhi and a list of flights appears then in the real-world situation they are free to choose any flight from the given list. The selection will be at their convenience. To simulate this aspect of real user behaviour, correlation is helpful. You can capture all the suitable values via correlation or regex and pass a random value from the captured values.
Random Think Time: It is a normal behaviour of a real user to stay on a web page for some time to read the content, fill in the information etc. This behaviour leads to a delay between two successive requests in the test script. For example, the real user launches an online retail application (Home Page Transaction) and then he enters the username and password and clicks on login (Login Transaction). So the user has to stay at the homepage until he inserts the credentials and clicks the login button. This staying time denotes User Think Time. A user does the same behaviour on all the pages. The only difference is the type of activity will be different. But, surely he will spend a significant time on each web page. This Think Time is not constant for all the users. Because in the real world, each user has his own typing or reading speed. A random Think Time adds a realness to the script.
Browser Simulation: Performance Testing tools do not have a real browser, although they simulate a real browser by adding browser details in the request header, by enabling cache and storing cookies etc. A real web browser has a cache feature to reduce traffic over the Internet. It also reduces the usage of network bandwidth which makes faster communication between clients and servers. Similarly, cookies are text files. The client’s computer stores cookies with various client information like search interests. By default, each request is considered as a new request. Once a cookie is added to the response from the servlet and it is stored in the cache of the browser then it is sent along with the next request. Thus, the server recognizes the user as the old user. These options can be enabled or disabled as per end-user behaviour or application configuration to simulate a real browser in the script.

2. Real-World Load

After the completion of the script by considering the real user behaviour, another important aspect of a realistic performance test is to simulate the real-world load patterns. The real-world scenario preparation comes under workload modelling (or execution) which includes:

Transaction Rate: Identify the user load in peak and average hours and prepare the scenarios which simulate the real-world load. Load Test, Stress Test and other performance test simulates the defined transaction rates or user loads
Geographical Location: The Internet is spread-out all over the world. It is good practice to identify the geographical location from where high traffic is coming to the website. In case 60% to 80% traffic reaches the application from a particular region then deploy the Load Generators to that location or use a WAN simulator to simulate the users.
Bandwidth: Though few users are from the same location, there are possibilities that their Bandwidths are different. Keep this point in mind while generating the user load onto the system. Various performance testing tool has the option to set the required bandwidth during the test execution.
Transaction Type: Each business transaction has its own percentage of accessibility rate (refer to the previous example). Hence identify the load percentage of each business functionality and design the workload accordingly.

Conclusion: Realistic Performance Testing

Performance Testing is the only testing where the objective of the testing is fulfilled in an artistic way. An art of simulating real-world scenarios, an art of simulating real-user behaviour, an art of analysing the results, an art of bottleneck finding and at last, an art of giving the assurance to the client that the application will not fail due to performance issues. Hence overall performance testing is based on the realistic concept that a performance tester simulates.