Skip to content

Latest commit

 

History

History
102 lines (79 loc) · 3.58 KB

api-loadtest-gen.md

File metadata and controls

102 lines (79 loc) · 3.58 KB

This page describes the different ways to generate API load test code.

## Swagger JMeter generation

The benefit sought from generating JMeter code from API specs is to remove the time needed to create test scripts through automation.

When both client code and associated scripts are generated immediately (after a github hook detects a relevant commit), ALL elements of an API can be evaluated together:

  • Documentation
  • expected output
  • client script code making API calls
  • client test code emulating client calls in performance tests (mini benchmarks)
  • server code which respond to API calls
  • data
  • service virtualization
## Authorization test cases
  • Authentication ID assignment (on a web page UI)
  • Password retrieval/reset
  • Availability
  • Allotment selection
  • Billing
## Life-cycle test cases
  • Authentication initial request from client and token return to client
  • Authentication key expiration handling
  • Authentication token reuse
  • Authentication token refresh
## Atomic data command cases The basic processing of data consists of:
  1. POST a new item
  2. GET that same item (while it's in cache)
  3. PUT change to the item
  4. DELETE

Other REST commands:

  • HEAD
  • OPTIONS
  • PATCH
## Qualitative test cases

What automated scripts have not been evaluating are qualitative aspects such as:

  • Whether model names reflect good names for classes, methods, fields, static values, etc.
  • Whether the model hierarchy is consistent across various components.
  • Whether attributes formats are appropriate to the data represented.
## Variations

  • upgrade/version APIs or move between environments, geographies, datacenters, and the cloud.

  • metering, SLA,

  • Allotment exceeded handling

  • Martin Fowler, in his 2013 blog article, notes the 3 levels in Leonard Richardson's Maturity Model (RMM), where level 3 is called hypermedia controls, provides discoverability by making a REST protocol response more self-documenting by including follow-on requests, such as:

<appointment>
 <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
 <patient id = "jsmith"/>
 <link rel = "/linkrels/appointment/cancel"
       uri = "/slots/1234/appointment"/>
 <link rel = "/linkrels/appointment/addTest"
       uri = "/slots/1234/appointment/tests"/>
 <link rel = "self"
       uri = "/slots/1234/appointment"/>
 <link rel = "/linkrels/appointment/changeTime"
       uri = "/doctors/mjones/slots?date=20100104@status=open"/>
 <link rel = "/linkrels/appointment/updateContactInfo"
       uri = "/patients/jsmith/contactInfo"/>
 <link rel = "/linkrels/help"
       uri = "/help/appointment"/>
</appointment>

One benefit of the response providing hypermedia controls is that the server can change its URI scheme without breaking clients because clients use the URI defined in the previous response, not months or years ago at time of design.

## References