Performance Testing Life Cycle
The PTLC is the systematic, repeatable process every performance engineer follows — from initial feasibility analysis through final reporting. Mastering these 9 stages is essential for delivering reliable, data-driven performance results on any project.
Phase 1–3: Planning
POC validates tool feasibility, NFR gathers requirements from production logs or BA teams, and the Test Plan creates the project roadmap.
Phase 4–6: Preparation
Workload Model sizes the load mathematically, Scripting records & enhances VUGen scripts, and Test Data is staged from DBAs.
Phase 7–9: Execution
Scenarios are designed in Controller, results are analyzed in LRA, and final reports with recommendations are delivered to stakeholders.
The 9 Stages at a Glance
The Performance Testing Life Cycle (PTLC) is also referred to as your "Roles and Responsibilities" or the "Process you follow in a Performance Testing Project." In interviews, this is one of the most frequently asked questions. Below is the complete sequence:
Stage 1: Proof of Concept (POC)
Goal: Verify tool compatibility, protocol feasibility, and estimate project labor hours before the engagement begins.
As part of POC, you will try to understand the application architecture — what kind of application is this, which technology was used to develop it, which communication mechanism was used, and the overall complexity of the application.
You will try to identify which tool is compatible for this application. If it is LoadRunner, you determine which protocol is compatible — whether it requires single or multiple protocols.
As part of POC, you record simple business scenarios, execute them with minimal users, and report the response times to the client.
What the Client Learns from POC
POC Checklist
Understand Architecture
Identify technology stack, communication protocols (HTTP, FTP, SMTP), and application tiers (web server, app server, database server).
Identify Tool & Protocol
Determine which tool (LoadRunner, JMeter, etc.) and which protocol (Web HTTP/HTML, Citrix ICA, SAP, Web Services, etc.) to use.
Record Simple Scenarios
Record basic business flows in VUGen, execute with 1-2 users, and validate that the script replays successfully.
Report to Client
Present initial response times, confirm tool feasibility, provide labor hour estimates, and protocol bundle recommendations.
Stage 2: NFR — Non-Functional Requirements Gathering
Goal: Define critical transactions, user volumes, baseline SLAs, and hardware threshold metrics.
The NFR document is prepared with help from BA (Business Analyst) people or the project team. It contains CBTs (Critical Business Transactions), peak hours, half-peak hours (low load), expected average response times, number of transactions per hour, and hardware threshold statistics like CPU, Memory, Heap, and Swapping.
You also gather what kind of tests to perform: availability, serviceability, scalability, recoverability, baseline, benchmark, failover, abnormality & spike tests.
After preparing the NFR document, it must be approved by the project team, architects, infrastructure team, network team, and stakeholders.
NFR Gathering Approaches — 3 Scenarios
"What is your approach to gather NFR, if the client doesn't know anything about performance testing?"
Scenario 1: Application is Already in Production
Get the production log files for 1 year of historical data using site analytical tools or Splunk. From this data, identify:
Key Mapping: Visitors → Number of Users | Page Views → Number of Transactions | JSP/ASP Pages → CBTs | IP Address → Region
Note: When SLAs (Service Level Agreements) are not available for expected response times, you must conduct a baseline test to establish them.
Scenario 2: Not in Production, But Has Competitors
Use network traffic utilities such as www.alexa.com to get competitor statistics. From competitor data, identify NFRs including:
Scenario 3: Not in Production & No Competitors
Understand the Core Business of the application and convert the core business to online business. By converting, identify users, transactions, CBTs, and regions. Then conduct a baseline test to derive SLAs.
Worked Example — Questions to BA:
| Question | Answer | Derivation |
|---|---|---|
| How many customers in core business? | 1.3 Million | Total customer base |
| How many register for online services? | 10% | 130,000 registered users |
| How many are active users? | 10% | 13,000 active users |
| How many are daily users? | 30% | 3,900 daily users |
| What are peak hours? | 4 hours | 3,900 users in 4 hours |
Based on these statistics, the number of concurrent users and transactions per hour are derived to build the workload model.
Stage 3: Test Plan & Strategy
Goal: Document the complete roadmap including objectives, scope, entry/exit criteria, risks, and deliverables.
The Test Plan is a roadmap of your test. It is the single most important planning document that guides the entire performance testing engagement. Every stakeholder should review and approve this document before testing begins.
Test Plan Contents
Objectives & Scope
Clearly defined test objectives, items in scope, and items out of scope for the engagement.
Procedures & Approach
Step-by-step testing procedures, test approach, CBTs, types of testing, and monitoring strategy.
Architecture & Environment
Application architecture diagrams, tool architecture, environment details, and infrastructure specifications.
Test Data & CBTs
Test data requirements, Critical Business Transactions list, and data management strategy.
Roles & Deliverables
Team roles & responsibilities, project deliverables timeline, and risk mitigation plans.
Entry & Exit Criteria
Prerequisites that must be met before testing (entry) and expected statistics targets (exit).
Entry Criteria
Whenever the pre-requisites are satisfied, that is called Entry Criteria. Testing cannot begin until all entry criteria are met.
Exit Criteria
Whenever derived statistics meet expected statistics, that can be considered as Exit Criteria. Testing is considered complete.
Note: The Test Strategy describes the approach & procedure of the test. It is often a section within the Test Plan or a separate companion document.
Stage 4: Workload Model
Goal: Build the mathematical model that sizes iterations, concurrent users, pacing, and think times.
The Workload Model is the "heart of all the documents" which guides you on "How to test that application" and "What to test in that application."
Workload Model Contains
Inputs
Use Cases
Business scenarios from the NFR document
Types of Testing
Load, stress, endurance, spike requirements
Number of Users
Concurrent user count from NFR data
Outputs
Pacing
Calculated delay between iterations to control TPH
Think Time
Realistic user delay between page actions
Transaction Mix
Percentage distribution of each business flow
Key Insight: While preparing the Workload Model, you must consider Pacing & Think Time calculations to generate the "Anticipated Load." The workload model will assist you to design the controller scenario accurately.
Stage 5: Scripting & Enhancements
Goal: Record scripts in VUGen, apply correlations, parameterization, and verification points.
Protocol is a set of rules governing communication between client and server. Selecting the right protocol is fundamental — the Protocol Adviser (available from LR 9.5) can help, but in realistic environments you must understand the communication mechanism & architecture by contacting the development team.
Famous Protocols in Current Market
Web (HTTP/HTML)
Most famous protocol. Use when the application uses HTTP protocol for web-based applications.
Web Services
For applications using APIs, web services, XMLs, JSONs, or RESTful services.
Citrix ICA
When the application is published in a Citrix environment, use the Citrix ICA protocol.
RTE Protocol
For Unix-based, cursor-based, or mainframe applications, use the Remote Terminal Emulator protocol.
SAP Family
For applications developed in ECC, NetWeaver, and DynaPro Portal — SAP Web or SAP GUI protocols.
Ajax TruClient
Measures response times including both server-side and browser-side rendering (JavaScript execution).
Key Enhancement Activities
Correlation
Handle dynamic values from server responses. Use web_reg_save_param() with LB/RB to capture and substitute dynamic session IDs, tokens, etc.
Parameterization
Replace hard-coded values with dynamic data files. Values entered through keyboard should be parameterized — script should contain no hard-coded values.
Verification Points
Use web_reg_find() for text checks and web_image_check() for image verification to validate page content during replay.
Transaction Markers
Place lr_start_transaction() and lr_end_transaction() around business actions to measure individual operation response times.
Stage 6: Test Data Management
Goal: Secure test credentials, stage databases via restoration points, and manage reusable vs non-reusable data.
Usually you will get test data from DBAs. While developing the script itself, you must prepare a Test Data Requirement Sheet that documents what data is needed for every use case, how much test data is required, and which data is reusable vs non-reusable.
Sometimes you can generate test data using the LR script itself. For example, you can create usernames and passwords if the signup functionality is available. If the functionality is not available, you must request the DBA to provide it.
Data Restoration Approaches
Restoration Point
When test data is not reusable, request the DBA to create a database restoration point. Once the test is completed, the DBA changes the DB to the previous restoration point so data is available for the next test.
Database Flashback
Alternatively, request the DBA to take a flashback of the database. After test completion, flashback the database or load the previous database instance to restore test data.
Passing Data Between Scripts
Two Actions in One Script
Create two actions in one script. Capture the value (e.g., purchase order number) from the 1st action and pass it into the 2nd action.
Data Staging
Execute the first script in Controller to generate values. Write them to a local file, then load the file into the second script before actual test execution.
VTS (Virtual Table Server)
A centralized repository tool that enables sharing of test data and parameters between LoadRunner VUsers during test execution. Acts as a shared data store.
Stage 7: Scenario Design & Execution
Goal: Configure Controller scenarios, assign load generators, set schedules, and execute tests.
The Controller (extension: .lrs) is where you design and run performance test scenarios. You choose between Manual Scenario and Goal-Oriented Scenario based on your requirements.
Manual Scenario Checklist
Choose Manual Scenario
Select manual mode for full control
Push Scripts
Add scripts into the Controller
Configure Schedule
Set ramp up, duration, ramp down
Assign LGs & RTS
Connect load generators and set runtime settings
Goal-Oriented Scenario Checklist
Define Goal
Set target (TPS, hits/sec, response time)
Set User Range
Provide min/max virtual users
Distribute Load
Allocate load percentages per script
Configure Notifications
Alert if goal cannot be reached
Stage 8: Result Analysis
Goal: Open results in Analyzer (.lra), identify bottlenecks, and correlate metrics across graphs.
The Analyzer file extension is .lra. It provides comprehensive tools for analyzing test results, identifying patterns, and diagnosing performance bottlenecks. The key features include:
Cross Results
Compare two .lrr files as part of benchmarking tests to identify performance differences between builds.
Graphs & Properties
Add/delete graphs, exclude/include think time, and generate percentage response time views.
Raw Data & Legend
Pull raw data for architecture teams and use legend/scale to interpret graph measurements correctly.
Granularity: The time difference between two saturation points. Minimum granularity for Throughput and Hits per Second is 5 seconds. For all remaining graphs, it is 1 second.
Stage 9: Reporting & Recommendation
Goal: Compile test findings into actionable reports with performance data, bottleneck analysis, and improvement recommendations.
The final stage of the PTLC involves creating comprehensive reports that summarize all test results and provide actionable recommendations for the development, architecture, and infrastructure teams.
Report Contents
Best Practice: Report only the 90th percentile response time to the client — 90% of transactions complete within this limit. Based on client requirements, you can also generate 80%, 85%, or 95% percentiles.
Common Interview Questions — PTLC
Q: Describe your roles and responsibilities in your current project.
Walk through all 9 stages of the PTLC. Start with POC (understanding architecture), then NFR gathering (working with BA team), Test Plan creation, Workload Modeling, Scripting in VUGen, Test Data management, Scenario execution in Controller, Analysis in Analyzer, and final Reporting.
Q: What is your approach if the client doesn't know anything about performance testing?
Follow the 3 scenarios: (1) If app is in production, use Splunk/analytics for historical data. (2) If not in production but has competitors, use tools like Alexa for competitor stats. (3) If no production and no competitors, convert core business to online and derive users from BA interviews.
Q: What is the Workload Model and why is it important?
It is the "heart of all documents." It contains CBTs, business flows, transaction counts, types of testing, and load distribution. It uses pacing & think time calculations to generate anticipated load and directly drives scenario design in the Controller.
Q: How do you pass values from one script to another?
Three approaches: (1) Create two actions in one script and pass via correlation. (2) Data Staging — run first script, write values to file, load into second script. (3) VTS (Virtual Table Server) — centralized repository shared between VUsers during execution.