 |
|
|
| INFORMATION |
| Published : |
May 25, 2007 |
| Length : |
12 |
| Type : |
White Paper |
|
| |
|
|
| Overview : |
|
This guide provides tips and tricks for HP LoadRunner software configuration, scripting, and execution. It is a conglomerate of lessons learned by HP LoadRunner power user Opral Wisham, including unique code as well as code collected from other testers. This guide is intended to help testers just learning to use HP LoadRunner, as well as to provide new best practices for those who have used HP LoadRunner for many years. Click below to download the guide now. |
|
 |
 |
| |
| View All Items By This Company |
| Browse Related Categories : |
Application Performance Management, C++, Performance Testing, Quality Assurance, Scripting, Software Testing, Web Development, Web Service Management, Web Services |
|
|
|
|
Implementing a successful performance testing program Before you release any new application into production, you must perform extensive capacity and performance validation (CPV) testing. This guide is intended to help new users and seasoned professionals learn new ways to design and implement successful load testing initiatives using HP LoadRunner.
Performance testing processes can be divided into four phases: the initial performance testing request, preparation for testing, script development and execution, and test analysis.
The following sections of this document describe some of the steps and best practices to follow when designing and conducting an effective performance test program. Formulating a high-level test plan The performance testing team should begin by defining a high-level test plan that describes the timeline for all testing efforts, including what types of tests will be performed (e.g., online and infrastructure stress and load tests, batch performance tests, etc.). The plan should also indicate how the performance testing team will interact with the development, deployment and/or support groups within the enterprise. When possible, it helps to use the actual names and titles of resources when explaining the interaction.
The testing team should describe what the tests are intended to measure and/or report. It is important to clarify all terminology that may be at risk of being misunderstood (e.g., “Transaction’s Response Time” may refer to the time it takes to hit the “enter” button and get a result from the system, or it could indicate the time it takes to perform a function that requires some human intervention). Some metrics for web applications will have different definitions from traditional online and batch applications, like average hits/second, web server throughput, etc.
The following checklist can be used when defining the steps of a comprehensive performance testing process:
1. List all testing milestones and deliverables for every phase of the project, including the pilot, code freeze and production phases. 2. Create a comprehensive production physical architecture diagram that shows a very low level of detail, including how each component will be connected. 3. List all hardware and software requirements for the tests. 4. Determine all database data volume requirements. 5. Define all performance objectives. 6. Identify all performance benchmarks, if available. 7. Identify the total number of expected users. 8. Specify the minimum and maximum number of concurrent users. 9. Select five business scenarios (manual scripts), plus actions within each scenario that should be measured (transactions). 10. Determine the user load mix. 11. Define acceptable average response times per transaction. 12. Define the average hits/second or number of transactions within one hour. 13. Define throughput, if applicable. 14. Identify any concurrent batch processes that are running. 15. Identify all lead, technical and functional contact personnel.
The following sections will provide examples that will help the performance testing team streamline the processes of scripting, building scenarios, data handling, test execution and test scheduling.
Tips for scripting Defining the directory structure and naming conventions It is important to establish formal procedures for creating directory structures and establishing naming conventions.
Recording scripts Whenever possible, the performance testing team should use HP LoadRunner’s automatic recording options. This method provides the most efficient way to record scripts for load testing most web-based applications.
Creating dynamic scripts through correlation and parameterization The performance testing team can use correlation to retrieve a value before it is needed in a preceding statement, enabling the server to dynamically generate the unknown value. The team can use parameterization when the values are known and they are not available prior to executing the statement.
Below is a parameterization example:
1. Parameterize, Source, Currency, Business Unit and Account, using a file. Select next row should be “same as Business Unit.” Business Unit Select next row should be “sequential” or “random,” depending on the duration or number of iterations. 2. Parameterize date as “date/time,” using %m/%d/%Y 3. Parameterize Amount as a random number from 1 to 10,000. 4. Parameterize Accounting Period as “date/time,” using %m 5. Parameterize the URL using a file. This will reduce the script changes required when the URL does change.
Correlation and parameterization are keys to creating a dynamic, data-driven test.
|
|
|
|
 |
|