In this part of the API Testing Series, we review a tool called LoadView, a combination monitoring and load testing tool. Here's a closer look at LoadView, its feature set, who might use it, and the current price models.
LoadView is a combination monitoring and load testing tool. Load testing and monitoring go hand in hand, but this being an API testing series, I'll mainly focus on load testing. Load and monitoring tool usage is varied. If your company has a DevOps role, that may be the main user because of its familiarity with and access to other monitoring tools. Otherwise, this tool will most likely be used by a combination of people in testing and development roles.
You have three main options applicable for creating a new load test in LoadView as seen in Figure 1.
Figure 1. Here you can see the three different options for creating a new load test. These options are for reaching different goals, and perhaps reaching the different people you have in mind. The HTTP option is good for people who are comfortable with API testing. Real Browser Load Test and Multi-Step Browser Load Test are for people uncomfortable with small amounts of code or for those who want easy recording of a scenario in the User Interface.
The first option is HTTP/S GET/POST requests, which is usually what you see in most traditional API testing tools. Using this option gives you the ability to craft individual calls to a service endpoint, create assertions based on the response, and then string endpoint calls together through variable usage to create API testing scenarios. The second option is a Real Browser Load Test. This option allows you to load test a single page by performing a full page download and then assessing how long that takes based on configuration options, such as the number of virtual users, how much time should lapse before each virtual user is in use, and how long the test should take in total for all virtual users to be active. The third option facilitates users doing performance tests (or user scenarios) that cross multiple web pages.
Here is an example using the Real Browser Load Test option of LoadView. You'll be presented with a set of test configuration options as seen in Figure 2 once you select Real Browser Load Test and click the Continue button.
Figure 2. Once you decide what type of load test to create, you'll be presented with a set of relevant configuration options. Here you can see configuration for a Real Browser Load Test, which includes content validation choices, authentication options, and other configuration options.
People who have worked with API testing before will find the content validation section particularly familiar. This is a simplified way to assert that certain things are present when the page download occurs; for example, the word "Prime" on the Amazon home page. After naming your test device in the next screen, you'll go to a page where you can design the virtual load to run on this web page.
The virtual load applied in your test is dependent on several variables: the execution plan (Figure 3), zone configuration (Figure 4), and virtual user distribution and calibration (Figure 5). Loosely, the execution plan defines how many virtual users should hit a web page, at what interval, and for how long. Zone configuration allows you to specify from which cloud the users originate. Third, virtual user distribution and calibration allows you to see the cost affect of your test configuration.
Figure 3. The Execution plan allows you to configure the virtual load against a web page. In this example, one user will access a page initially, three new users will access the page each minute for the next 3 minutes, and once all virtual users have accessed the page, they'll remain active for five minutes.
Figure 4. The effect of web traffic can vary, depending on what part of the world that traffic originates. Zone configuration allows you to configure your virtual users to originate from clouds that are relevant to your business. You can also select multiple clouds, and distribute your virtual user load across the clouds.
Figure 5. Each load or performance test you design and run is using resources of a server in the cloud, which means that every test has an approximate cost to run. The virtual user distribution and calibration section in each load test device will allow you to see the cost of a test before you click Run.
Once you have run your test, you'll have access to information about the effect that virtual load has on your web page, including the execution plan, average response time, and load injector server load (Figure 6). Your test will take between 10 minutes and one hour to begin depending on the resources available at the time. Once your test begins, you'll see these graphs update in real time as your test progresses. Once the test competes, you'll see that the number of virtual users will quickly reduce to zero. Once the test is finished, you'll receive an email with a link to the test's results and a PDF summary of those results.
Figure 6. Here you can see the load injector server load for the sample test. In this graph, you can see that server load is distributed unevenly between two U.S. East servers. If you were to configure your test to run from multiple clouds, you would see that reflected in this graph along with CPU usage by cloud.
Pricing for LoadView Monitor begins at $9.99 per month. When you sign up initially, you'll have a $20 credit to your account to use when designing and running your first test. After this, the cost of each test will be displayed in the calibration tool based on the cloud resources your test will consume while running.