This is background research into current saturation test tools that work over HTTP. This domain is suited to E2E testing, but generally excludes any client side stuff, as the client doesn't need to scale that much. For test purposes, I would setup the tool on the same host as the webserver, so results on different test scenarios are more reliably comparable.
I'm writing this, as today I wrote another test runner to be able to send API requests in bulk; and think this is misplaced effort.

Requirements for the tools:

  • can talk HTTPS
  • can authenticate self at start of script (via a login request; or HTTP auth, if essential)
  • will understand full range of HTTP response codes
  • can send each HTTP verb [1]
  • provides control on request population
  • provides summaries of results
  • ideally has basic support for JSON and XML parsing, to be able to understand inline error codes from API that aren't REST [2]
  • can be linked into a CI
  • can do floods of requests, not singular ones


[1] I am being careful with GUI on this point. If I am using cURL, I can type a short string for the verb, and may use anything. In a GUI, I will be pressing a button, and there may only be “GET” or “POST” as options.

[2] Not my work obviously. Adding “does this match the documentation” tests to third party API is never a bad thing. It doesn't take long with correct tooling, and will save much more time debugging integrations. Most of the vendors I'm talking to after 2013 have a REST API not a random RPC API or webscraping.