Web Services have been known for years, but have become popular once agile and DevOps took off. There’s simply a perfect fit in the development approach – rather than engage in long development processes of full features, small components are developed and are packaged in an API. These can later be used in future development cycles.
Nevertheless, also newly-developed API are doomed to be changed in future iterations for various reasons.
In terms of performance testing, this translates to the need to continuously load test your API, WSDL, and REST code. So where does one start? Ideally – by downloading and reading this eBook – Load Testing Buyer’s Guide, but if you’re just interested in the “Nutshell” version, here are five tips to handle this testing goal efficiently.
1- Build one test for each API
Start with the basics and create a test for each API.
With WebLOAD you can test all types of APIs, whether they are REST or SOAP. Building an API request in WebLOAD can be done in 2 ways: Using Wizard or via Recording.
You can record the API using an application that uses the API or using one of the API testings tools such as Postman, Boomerang, Advanced REST client, etc. WebLOAD can record your API request, simply by recording your HTTP/HTTPS traffic.
In many cases you’ll be using 3rd party tools and APIs. Whether you are using an open source integrated in your application or you remotely use 3rd party API – you need to load test these APIs as well to make sure they adhere to your requirements.
2- Enter validations into your load test
Your API receives parameters and returns values. Therefore, you should build tests with many different parameters to validate the various responses.
Using WebLOAD’s Parameterization Manager you can feed different values and hold different responses to be validated easily.
It is quite easy to validate simple values. But in cases where the request or the response are XML or JSON, it may be tricky to deal with its structures. In such cases, use WebLOAD’s XML and JSON parsers, which converts the structures to simple structures, making validation easy.
3- Define Performance Goals for your API
It’s probably easier to define in advance the number of users that will work with the system and the expected response time for a specific user transaction. But it’s more tricky to define how many times your API will be executed in your running application or what is as reasonable response time. Is 10ms is a good number for response time? 50 ms? 100 ms? This is a tricky question. The suggestions below may help.
- It is always good to ask experienced people who know the application well. This can be, for example, system architects, who designed the system.
- You can compare the results to another, similar APIs and try to extrapolate what should be the response time for your newly written API.
- If you run performance tests continuously, you’ll be able to identify regression in the response time and draw conclusions.
4- Test a sequence of APIs (a.k.a ‘transaction’)
Often, certain activities in your application contains several APIs executed sequentially. Besides load testing each API on its own, it’s a good practice to test the entire activity when it is ready. This will achieve two things:
- You’ll learn about the response time of the entire activity.
- You’ll identify new bugs.
5- Link your test to your continuous integration environment
Load testing your APIs will not be complete without automation and integrating your tests into your continuous integration environment. In most cases you may have tests per each check-in, daily tests or weekly tests. Load tests are much longer than unit tests, so it would not be effective to run them all every check-in. But selecting the important ones for the nightly build and all of them for the weekly build, will do the job.