As we’ve covered in previous posts, performance testing is different from functional testing, and therefore requires different criteria when setting goals, creating test plans, and evaluating results.
Often times, the degree of complexity in the workflow of a functional test is not required to create a meaningful performance test scenarios. The focus is not on what is working (or not), but how the load affects the system under test.
Still, there are several aspects that can play a crucial role when generating load, which necessarily require a certain complexity in performance testing scenarios.
- For example, this is true of credentials in the workflow. If the user needs to have an account in the system in order to perform performance-critical tasks, then an authentication process needs to be taken into account and modeled in the test itself.
- Another inherently complex case is that of time sensitive tokens which need to be passed via requests, in order to retrieve resources from the system. Failing to include these tokens in the performance test would likely give errors that would render the test invalid.
- You may have a scenario in which you need to retrieve information from a request, and pass it to a different request. In the case of an e-commerce website, for example, you may want to follow a shopping item from the time it is browsed, reviewed, put into the cart and eventually checked-out. If multiple items can be randomly picked, it is important that the subsequent requests are consistent with the data they are using.
Here’s why Nouvola DiveCloud is a truly disruptive solution for complex performance tests like the examples described above. Rather than pouring countless hours into writing and maintaining cumbersome scripts, Nouvola DiveCloud enables users to efficiently create complex tests in a clean UI-based solution, where data can be extracted (via regular expressions) from different data sources, such as URL’s parameters, requests body, headers, and files. The data can then be shared among all the requests via variables. Variables can also have static values, or represent a predefined method.
So, for example, if there is an authentication process, the user name and password can be tied together with tokens and other parameters involved in the handshake between the client and the server.
Domains can be passed as variables, or a shopping item can be passed to the check-out process.
And if you want to randomize some of these values, so that for instance, Virtual Users pick different products to put in the cart, that can also be saved in a variable, and passed it to the future requests.