What is a Performance Test Script?
Performance testing-specific programming language called Performance Test Script is used to automate actual user behavior. The user activities made by a genuine user on an application are recorded in this code. Performance testing technologies like LoadRunner, JMeter, NeoLoad, etc. are used to create these scripts.
Purpose of Performance Test Script:
The major goal of the performance test script is to mimic real-world user activity. A performance test script is used by the virtual users or threads to simulate the necessary server load. To test the middleware application, some scripts, like Java MQ, send messages.
Accountability:
After thoroughly comprehending the Performance Test Scenarios from the Performance Test Plan, the test scripts are developed by a Performance Test Analyst or Engineer (designation may vary depending on corporate policy). The produced script must be checked against the performance test scenarios by the performance test lead.
Approach:
Before beginning the scripting process, a performance tester must study the Performance Test Plan. He must comprehend each scenario listed in the test plan and personally check each transaction flow. If he discovers any functional problems, he should bring them to the programming team’s attention. There may be two scenarios to develop the script from once all the possibilities have been personally checked. These circumstances have to do with the environment.
1.Scripting in the Performance Test environment:
It is a recommended practice to use the performance test environment for scripting when it is available. The ability to finalize the script in the same environment eliminates the requirement for script validation, which is the main benefit of creating the script in a specific performance test environment. Script validation must be done in the performance test environment if a performance tester produces the scripts in a different environment. Additionally, when scripting and execution take place in the same environment, performance testers are more confident in the script’s success.
2. Scripting in other than Performance Test environment:
Giving the performance test script creator access to another environment (for development or functional testing) is a common circumstance. There might be a number of causes, such as an empty database, the performance test environment not being ready, or another project utilizing the shared environment. Because a performance tester may finish the scripting work in any environment and then validate the scripts in the performance test environment, performing the scripting in another environment is not always a bad option. But before beginning the real test, the script must be validated.
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, a performance tester may have a script failure issue. The configurations of the functional testing environment and the performance testing environment may also differ somewhat. The good news is that these problems may be quickly fixed at the script validation stage by a skilled performance tester. In order to validate all the scripts in the performance test environment, he employs a stable and functionally validated code version. The following benefits of such a strategy:
- 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?
- Protocol Identification (Not for All Tools): In order to choose a supported protocol while writing a script, a performance tester has to be aware of the technology on which the application is based. A performance tester must choose the multi-protocol recording option to create the proper script if the application was created utilizing various technologies. JMeter does not need this step; protocol identification is merely a fundamental function of the LoadRunner tool.
- By just capturing the user steps (transaction flows), performance testing tools may finish 70%–80% of the programming effort. The main benefit of a performance testing tool is this. It eliminates the need for manual code writing by performance testers. Yes; it’s also true that he occasionally needs to develop bespoke code, but such pieces of reasoning are straightforward.
- The next stage is script improvement, which comes after recording and script creation. Tools for performance testing merely capture the flow and provide the script in raw form, that is, without correlation, parameterization, etc. Enhancing the script with custom logic, fundamental parameters, and dynamic value handling procedures, among other things, is helpful. The following stages are covered by the script enhancement:
- With parameterization, test data may be used to replace scripted variables that are hard-coded. In general, parameterization is necessary for user input fields such as user name, password, product name, etc.
- Transactions can be added to or edited, and they serve to bind various requests on a page. The transaction makes it easier to record the failures and response times for a specific request.
- Add Think Time: The lag time between two transactions is known as think time. In the actual world, consumers spend some time reading the page’s content, filling out a form, etc. The same simulates in thought time. A scene is more realistic when you consider time.
- Add Rendezvous Points: A rendezvous point may be added to accomplish synchronous action. An agreed-upon meeting place puts a heavy user strain on the server.
- Add Logic: Programming logic may occasionally be inserted to add, repeat, or skip transactions based on predetermined criteria. By including “if/else condition,” “for loop,” “while loop,” etc., one may design such scenarios.
- Identification and handling of dynamic values: Another name for it is correlation. “To identify the dynamic value returned by the server and replace that value with a variable” is the shorthand definition of correlation. In LoadRunner and JMeter, this variable is known as a correlation variable or a regex variable. The correlation process is divided into two categories: script debugging and script augmentation.
- Script Replay / Debug: After script improvement, the script must be replayed to see if it is still functioning properly. Debugging is necessary if an error occurs at any stage or if the script does not operate in accordance with the business flow. Examine the relevant logs and responses during the debugging process to pinpoint the error’s primary cause. Dynamic value (correlation) is typically the main reason for script failure. When this happens, the data in the backend is not changed, such as when a product is not submitted, an order is not placed, the database is not updated, etc. Therefore, it is advised to further check the results on the backend.
Deliverable:
A runnable Performance Test script for each of the business scenarios listed in the performance test strategy is the major output of this phase.
Example:
| 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 |
