Load testing requirements template

Here we want to briefly describe the reasons for executing our load test. Definitions is an optional section which provides a place where we can spell out acronyms, or define terms which may have special meanings for this particular test. This section is important for describing the foundational concepts of our load test. Here are a few examples of standard test types which we might select:.

In the description area, you can additionally elaborate on the testing framework utilized e. Here are some examples of failure criteria:. Subheadings under this section can be variable and dependent upon your particular test scenario and needs. To give a few examples, this would include such things as a description of any API being tested; relevant hosting environment considerations; or front-end descriptions if the target application is a website. It is entirely possible for some or all of this information to be opaque from the perspective of the load test, and in that situation the environment description may be intentionally vague.

Another item to discuss here might be server instance sizes, types, and numbers used to generate loads. A description is fine as we of course do not want to include actual values of credentials in the document. Are users being newly registered for this test? These are questions we want to answer here in our documentation. In this section we can describe all of our data collection and reporting methods. For example, we would list the Azure Metrics dashboard, AWS Cloud Watch metrics, and log files as data sources for a hypothetical test.

Particularly with RedLine13 tests, we make available a cross-server JMeter report dashboard which provides very detailed metrics and useful graphs. Here is an example of one of those graphs:. How many users would we have in an ideal world? This is why, before you begin creating a load test, you must first research your current API usage. He goes onto explain that you want to start by asking simple questions for simple answers. When in doubt, these are the most realistic and accurate answers.

This is a great starting off point to understand your realistic traffic. He goes onto suggest that you can also kick off your API load testing with your API production logs as a way to replay your most realistic use cases. Between these two examples, you should be able to recognize not only what kind of traffic is typical, but also which endpoints are creating this traffic. As you get started with your load testing, SmartBear has the tools you need to ensure that your APIs perform flawlessly under various traffic conditions.

Load Testing Strategies. What Is Distributed Load Testing? Load Testing vs. Stress Testing vs. Performance Testing.