Add LoadRunner performance test scripts for 5 business-critical scenarios#758
Add LoadRunner performance test scripts for 5 business-critical scenarios#758devin-ai-integration[bot] wants to merge 1 commit into
Conversation
- Performance_Test_Scenarios_AppTimesheet.xlsx: 5 business-critical scenarios with detailed step-by-step user actions, API calls, parameters, correlations, and validations - SC01_Login_Dashboard: User login & dashboard load (T01-T03) - SC02_Client_Management: Client CRUD operations (T04-T06) - SC03_Work_Entry_Creation: Work entry logging & verification (T07-T09) - SC04_Report_Generation: Report viewing & CSV/PDF export (T10-T13) - SC05_End_to_End_Flow: Full business path login→client→entry→report (T14-T24) Each script includes: - Transaction boundaries (lr_start/end_transaction) - Parameterized test data (CSV files with 10 rows each) - Dynamic correlation (web_reg_save_param_json for IDs) - Realistic think times (3-5s between actions) - Text checks (web_reg_find for response validation) - Error handling with LR_FAIL on failures - Runtime settings (.usr files with pacing, logging, browser emulation)
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| lr_eval_string("{P_UserEmail}"), http_status); | ||
|
|
||
| // Set x-user-email header for all subsequent API calls | ||
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
There was a problem hiding this comment.
🔴 web_add_header only sets auth header for one request, causing all subsequent requests to fail with 401
web_add_header at line 130 adds the x-user-email header to only the next HTTP request. In LoadRunner, web_add_header is a single-shot function — the header is consumed by the immediately following request and removed. Here, the header is consumed by Dashboard_Get_Clients (line 147), so Dashboard_Get_WorkEntries (line 162) is sent without the x-user-email header. The backend authenticateUser middleware (backend/src/middleware/auth.js:7-8) returns 401 when the header is missing, causing T03_Dashboard_Load to always fail. Should use web_add_auto_header to persist the header for all subsequent requests.
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); | |
| web_add_auto_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
Was this helpful? React with 👍 or 👎 to provide feedback.
| int http_status; | ||
|
|
||
| // Ensure auth header is set for this iteration | ||
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
There was a problem hiding this comment.
🔴 web_add_header only sets auth header for one request, causing T05 and T06 to fail with 401
web_add_header at line 29 adds the x-user-email header only to the next request (Navigate_Clients at line 40). All subsequent requests — Create_Client (T05, line 85) and Verify_Client_List (T06, line 147) — are sent without the auth header. The backend's authenticateUser middleware (backend/src/middleware/auth.js:7-8) returns 401 for requests missing x-user-email, so T05 and T06 always fail. Should use web_add_auto_header.
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); | |
| web_add_auto_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
Was this helpful? React with 👍 or 👎 to provide feedback.
| int http_status; | ||
|
|
||
| // Ensure auth header is set | ||
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
There was a problem hiding this comment.
🔴 web_add_header only sets auth header for one request, causing 4 subsequent requests to fail with 401
web_add_header at line 29 adds the x-user-email header only to the next request (Navigate_WorkEntries at line 40). The subsequent requests — Fetch_Clients_Dropdown (line 72), Create_WorkEntry (T08, line 100), and Verify_WorkEntry_List (T09, line 164) — all lack the auth header and will receive 401 from the backend's authenticateUser middleware (backend/src/middleware/auth.js:7-8). Should use web_add_auto_header.
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); | |
| web_add_auto_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
Was this helpful? React with 👍 or 👎 to provide feedback.
| int download_size; | ||
|
|
||
| // Ensure auth header is set | ||
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
There was a problem hiding this comment.
🔴 web_add_header only sets auth header for one request, causing T11-T13 to fail with 401
web_add_header at line 29 adds the x-user-email header only to the next request (Navigate_Reports_Clients at line 40). Subsequent requests — Load_Client_Report (T11, line 91), Export_CSV (T12, line 134), and Export_PDF (T13, line 173) — all lack the auth header and will receive 401. Should use web_add_auto_header.
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); | |
| web_add_auto_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
Was this helpful? React with 👍 or 👎 to provide feedback.
| lr_end_transaction("T15_E2E_Login", LR_AUTO); | ||
|
|
||
| // Set auth header for all subsequent requests | ||
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
There was a problem hiding this comment.
🔴 web_add_header only sets auth header for one request, breaking the entire E2E flow after the first dashboard call
web_add_header at line 105 adds the x-user-email header only to the next request (E2E_Dashboard_Clients at line 125). The second request in T16 (E2E_Dashboard_WorkEntries, line 137) and all subsequent requests (T17 through T24) are sent without the auth header. Since the backend requires x-user-email for all authenticated endpoints (backend/src/middleware/auth.js:7-8), the E2E flow always fails at the work-entries request within T16. Should use web_add_auto_header.
| web_add_header("x-user-email", lr_eval_string("{P_UserEmail}")); | |
| web_add_auto_header("x-user-email", lr_eval_string("{P_UserEmail}")); |
Was this helpful? React with 👍 or 👎 to provide feedback.
| web_custom_request("Init_WorkEntry_1", | ||
| "URL=http://localhost:3001/api/work-entries", | ||
| "Method=POST", | ||
| "Resource=0", | ||
| "RecContentType=application/json", | ||
| "Mode=HTTP", | ||
| "EncType=application/json", | ||
| "Body={\"clientId\": {C_ClientId}," | ||
| "\"hours\": 8.5," | ||
| "\"description\": \"Backend development\"," | ||
| "\"date\": \"2026-05-12\"}", | ||
| LAST); | ||
|
|
||
| web_custom_request("Init_WorkEntry_2", | ||
| "URL=http://localhost:3001/api/work-entries", | ||
| "Method=POST", | ||
| "Resource=0", | ||
| "RecContentType=application/json", | ||
| "Mode=HTTP", | ||
| "EncType=application/json", | ||
| "Body={\"clientId\": {C_ClientId}," | ||
| "\"hours\": 4.0," | ||
| "\"description\": \"Code review\"," | ||
| "\"date\": \"2026-05-11\"}", | ||
| LAST); | ||
|
|
||
| web_custom_request("Init_WorkEntry_3", | ||
| "URL=http://localhost:3001/api/work-entries", | ||
| "Method=POST", | ||
| "Resource=0", | ||
| "RecContentType=application/json", | ||
| "Mode=HTTP", | ||
| "EncType=application/json", | ||
| "Body={\"clientId\": {C_ClientId}," | ||
| "\"hours\": 3.5," | ||
| "\"description\": \"Testing\"," | ||
| "\"date\": \"2026-05-10\"}", | ||
| LAST); |
There was a problem hiding this comment.
🟡 No HTTP status validation for precondition work entry creation requests
Three work entry creation requests (Init_WorkEntry_1 through Init_WorkEntry_3, lines 85-122) have no HTTP status code checks. If any of these POST requests fail (e.g., due to a server error or validation failure), the script silently proceeds to the Action section. The subsequent report generation in SC04_Report_Generation/Action.c would then operate on incomplete data — the comment at line 125 claims "3 work entries created (16.0h total)" but this is unverified. The T11 report validation would pass with wrong data since totalHours and workEntries fields still exist in the response even with 0 entries.
Prompt for agents
In SC04_Report_Generation/vuser_init.c, the three work entry creation requests (Init_WorkEntry_1, Init_WorkEntry_2, Init_WorkEntry_3) at lines 85-122 do not check the HTTP response status codes after each POST request. If any of these requests fail, the script proceeds silently with incomplete test data. Add http_status checks after each web_custom_request call, similar to the pattern used for client creation at lines 69-74. For each work entry creation, call web_get_int_property(HTTP_INFO_RETURN_CODE), check if it equals 201, and return -1 with an error message if it does not.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Adds 5 LoadRunner VuGen performance test scripts covering the application's business-critical workflows, along with an Excel scenario document detailing every user click, data entry, API call, and expected response.
Files added (30 total):
vuser_init.c,Action.c,vuser_end.c,.usr,params/users.datvuser_init.c,Action.c,vuser_end.c,.usr,params/users.dat,params/clients.datvuser_init.c,Action.c,vuser_end.c,.usr,params/users.dat,params/workentries.datvuser_init.c,Action.c,vuser_end.c,.usr,params/users.datvuser_init.c,Action.c,vuser_end.c,.usr,params/users.dat,params/clients.dat,params/workentries.datEach script includes:
lr_start_transaction/lr_end_transaction)web_reg_save_param_jsonfor client IDs, entry IDs, report totals)web_reg_findfor response validation)LR_FAILon failures.usrfiles with pacing, logging, browser emulation)Excel document (
Performance_Test_Scenarios_AppTimesheet.xlsx) contains 8 sheets:2-6. Detailed step-by-step sheets per scenario (12 columns each)
No application code was modified. Scripts are designed for LoadRunner VuGen and do not require execution.
Review & Testing Checklist for Human
Action.cto confirm transaction names match the Excel scenario steps.dat) contain realistic, properly formatted test dataC_ClientId,C_EntryId,C_TotalHours) are correctly extracted and reused/api/auth/login,/api/clients,/api/work-entries,/api/reports)Notes
.usrfiles use a simplified XML format for runtime settings — actual LoadRunner projects may require additional configurationlocalhost:3001(backend) andlocalhost:5173(frontend) — update base URLs as needed for your test environmentLink to Devin session: https://partner-workshops.devinenterprise.com/sessions/3ba787261d1b41d488dde3292a5bed1c