Plan and Design Tests in LoadRunner

When designing and planning tests,the target is to simulate real-world tests that can provide reliable data so as to provide informed decisions around the business.So that Real world tests design will prove the system to meet larger realistic objectives. The following are the considerations when designing tests:

• Real world design tests are more inclusive of non-computerized dependencies like humans, other systems interacting with the application etc.
• Realistic test design will be based on real operations and data, and does not rely on mechanistic procedures.
• Realistic test design will be more credible for the project and will enhance the value of performance testing
• Component-level performance tests are integral part of real-world testing, and not the end goal.
• Real world test design can be more costly and time consuming but they provide more accuracy for the business and stakeholders. Extrapolation of performance results from non realistic tests can be inaccurate as the system scope increases.

Identify Metrics of Interest
When identified, captured, and reported correctly, metrics provide information about how your application’s performance compares to your desired performance characteristics. In addition, metrics can help you identify problem areas and bottlenecks within your application.
Using the desired performance characteristics identified in step 1, identify metrics to be captured that focus on measuring performance and identifying bottlenecks in the system.
When identifying metrics, use either specific desired characteristics or indicators that are directly or indirectly related to those . The following table presents an example of a metric corresponding to the performance objectives identified in step 1.
Metric Accepted level
Request execution time Must not exceed 8 seconds

Throughput 100 or more requests / second
% process time Must not exceed 75%
Memory available 25% of total RAM

Considerations

• Although it may seem like a commonsense practice, it is important to verify that system clocks are synchronized on all of the machines from which resource data will be collected. Doing so can save you significant time, and prevent you from having to dispose of the data entirely and repeat the tests after synchronizing the system clocks.
• Involve the developers and administrators in the process of determining which metrics are likely to add value and which method best integrates the capturing of those metrics into the test.
• Collecting metrics frequently produces very large volumes of data. While it is tempting to reduce the amount of data, always exercise caution when using data reduction techniques as valuable data can be lost when reducing data.

Scenarios

Key user scenarios for the application typically surface during the process of identifying the desired performance characteristics of the application (Step 1). If this is not the case for your test project, you will need to explicitly determine the usage scenarios that are the most valuable to script. {For more information, see How To: Identify Key Usage Scenarios for Performance Testing.} To create test scripts from the identified or selected scenarios, most performance testers follow an approach similar to the following:

1. Identify the activities or steps involved in each of the scenarios; for example, the “Place an Order” scenario for an e-commerce application may include the following activities:

• a.Log on to the application.
• b.Browse a product catalog.
• c.Select a product.
• d.Place order, and so on.

For each activity or step, consider and design the data associated with that step. A method is to use a table similar to the one below:Only after you have detailed the individual steps can you effectively and efficiently create a test script to emulate the necessary requests against the application to accomplish the scenario {For more information, see How To: Implement Workload Models in VSTS 2005}.

Considerations

• If the request accepts parameters, ensure that the parameter data is populated properly with random and/or unique data to avoid any server-side caching.
• If the tool does not do so automatically, you will likely want to add a wrapper around the requests in the test script in order to measure the request response time.
• Beware of allowing your tools to influence your test design. Better tests almost always result from designing tests on the assumption that they can be executed and then adapting the test or the tool when that assumption is proven false, rather than by not designing particular tests based on the assumption that you do not have access to a tool to execute the test.
• It is generally worth taking the time to make the script match your designed test, rather than changing the designed test to save scripting time.
• Significant value can be gained from evaluating the data collected from executed tests in order to test or validate script development.
• Once a test has been implemented using a tool, it’s a good idea to double check that the test matches the test design. If they don’t match, it’s generally worth the effort to make them match by modifying one (or both) items and communicating the modification with the team.

Related Topics:

• Identifying Performance Acceptance Criteria
• Types of Performacne Testing
• Why software performance Testing Required
• when do Testing Completes