What is a Performance Test Script?
Performance Test Script is a programming code specific to performance testing to automate real-world user behaviour. This code contains the user actions performed by a real user on an application. Such scripts are developed with the help of performance testing tools like LoadRunner, JMeter, NeoLoad etc.
Purpose of Performance Test Script:
The main purpose of the performance test script is to simulate the behaviour of a real-world user. The virtual users or threads use a performance test script and generate the desired load on the server. Some of the scripts like Java MQ trigger the messages to test the middleware application.
Accountability:
Performance Test Analyst or Engineer (designation may vary as per company policy) develops the test scripts after getting a detailed understanding of Performance Test Scenarios from the Performance Test Plan. The Performance Test Lead has a responsibility to verify the developed script against the performance test scenarios.
Approach:
A performance tester needs to read out the Performance Test Plan before going to start the scripting work. He needs to understand all the scenarios documented in the test plan and verify all the transaction flows manually. If he finds any functional issues then he should highlight those issues to the developer team. Once all the scenarios are verified manually then there could be two possible situations to build the script. These situations are related to the environment.
1. Scripting in the Performance Test environment:
If the performance test environment is ready then it is a good practice to use it for scripting purposes. The biggest advantage to prepare the script in a dedicated performance test environment is that the script can be finalized in the same environment and there is no need to validate the script later. When a performance tester develops the scripts in another environment then script validation must be carried out in the performance test environment. In addition to this, a performance tester is more confident about the success of the test script when the scripting and execution occur in the same environment.
2. Scripting in other than Performance Test environment:
It is a generic scenario to provide another (development or functional testing) environment to create the performance test script. There could be many reasons like the performance test environment is not ready or another project is using the shared environment, empty DB etc. To perform the scripting in another environment is not that much worse approach because a performance tester can complete the scripting work in any environment and later on verify the scripts in the performance test environment. But script validation is a must before going to start the actual test.
A performance tester may face a script failure issue due to the difference between the functional testing environment code version on which scripting was done; and the performance testing environment code version on which test execution will be conducted. Also, there might be some differences in the configuration of the functional testing environment and performance testing environment. But the good part is that an experienced performance tester can easily resolve these issues during the script validation phase. He uses a stable and functional tested code version to validate all the scripts in the performance test environment. Such an approach has the following advantages:
- It saves an ample amount of time
- This approach allows parallel working with the functional team.
- Initial functional bug identification
- Lower the end-time delivery pressure etc.
What are the basic steps of script creation?
Script creation has some basic steps which are:
- Protocol Identification (Not for All Tools): For creating a script a performance tester should know the technology in which the application is built-up so that supported protocol can be selected. If the application is built-up using multiple technologies then a performance tester needs to select the multi-protocol recording option to prepare the correct script. Protocol Identification is a basic feature of the LoadRunner tool only, JMeter does not require this step.
- Script Recording: Performance Testing Tools help to complete 70%-80% of scripting work by just recording the user steps (transaction flows). This is the biggest advantage of a performance testing tool. It saves a performance tester from writing the manual code. Yes; it is also true that he needs to write some custom code as and when required, but those are simple logic.
- Script Enhancement: After the recording and generation of the script, the next phase is script enhancement. Performance testing tools only record the flow and generate the script in a raw form which means without correlation, parameterization, etc. Script enhancement helps to add some custom logic, basic parameters and dynamic value handling functions etc. in the script. The script enhancement covers the following steps:
- Parameterization: Parameter helps to replace hard-coded values from the script with test data. Basically, user input fields like user name, password, product name etc. require parameterization.
- Add / Edit Transactions: A transaction binds multiple requests available on a page. The transaction helps to capture the response time and errors for a particular request.
- Add Think Time: Think time is a delay between two transactions. In the real world, users take a certain amount of time to read the content of the page, to fill a form etc. Think time simulates the same. Think time makes a scenario more realistic.
- Add Rendezvous Points: To perform simultaneous action rendezvous point can be added. A rendezvous point creates an intense user load on the server.
- Add Logic: Sometimes, there is a need to insert programming logic to add, repeat or skip the transactions on the basis on given conditions. Such scenarios can be created by adding “if/else condition”, “for loop”, “while loop” etc.
- Dynamic Value Identification and Handling: It is also called a Correlation. The simple definition of correlation is “To identify the dynamic value returned by the server and replace that value with a variable”. That variable is called a correlation variable (LoadRunner) or RegEx variable (JMeter). The correlation process partially comes under script enhancement and partially under script debugging.
- Response Check: This is a good practice to validate the server response. In LoadRunner, it is called “Content check”. The content check contains both Text Check as well as Image Check. On the other hand, JMeter uses assertions to validate the correctness of the response.
- Script Replay / Debug: Once the script enhancement is done then the script needs to be replayed to ensure whether the script is working fine or not. If the error comes at any step or the script does not perform as per the business flow then it requires debugging. During the debugging phase, check the respective logs/response and identify the root cause of the error. In most cases, dynamic value (correlation) is the primary cause of script failure. In some cases, the script runs successfully without any error but data is not updated in the backend like a product not submitted, order not placed, DB data not modified etc. Hence it is recommended to verify the result in the backend as well.
Once the performance tester completes the scripting work, it must be verified by a performance test lead.
Deliverable:
The main deliverable of this phase is a runnable Performance Test script for all the business scenarios defined in the performance test plan.
Example:
Where is PerfMate? Now, he will help to understand the performance test scripting phase practically:
PerfMate needs to create 7 scripts which are finalized in the test planning phase. PerfMate assigns this work to 2 performance testers of his team. Firstly, he provides knowledge of the scenarios to them and then performance testers start to prepare the scripts. They record and enhance the script using a Performance Testing tool. PerfMate’s team uses a functional test environment for scripting purposes because the performance test environment is not ready yet.
Through this, they saved time and completed the scripting work without any delay. After getting the performance test environment, they validate all the scripts as well as test data. Now, all the performance test scripts are in ready to test state:
| Role | Script Name | Transactions | Total Transactions |
|---|---|---|---|
| Admin | adm_seller_request | 1. Home Page 2. Login 3. Admin Task 4. Seller Request 5. Click Request 6. Approve/Reject 7. Logout | 7 |
| Admin | adm_product_request | 1. Home Page 2. Login 3. Admin Task 4. Seller Request 5. Click Request 6. Approve/Reject 7. Logout | 7 |
| Seller | slr_add_product | 1. Home Page 2. Login 3. Product Tab 4. Add Product 5. Add Product Details 6. Submit for approval 7. Logout | 7 |
| Seller | slr_delete_product | 1. Home Page 2. Login 3. Product Tab 4. Delete the Product 5. Choose a Product 6. Delete 7. Logout | 7 |
| Buyer | byr_buy_product | 1. Home Page 2. Login 3. Search for Product 4. Add to cart 5. Checkout 6. Order Summary 7. Payment 8. Logout | 8 |
| Buyer | byr_cancel_order | 1. Home Page 2. Login 3. Order History 4. Select Order 5. Cancel Order 6. Logout | 6 |
| Call Center | cce_register_complain | 1. Home Page 2. Login 3. Complain Tab 4. New Complain 5. Add Details 6. Submit 7. Logout | 7 |