Location>code7788 >text

Talking about interface test case design specifications

Popularity：695 ℃/2024-11-07 21:21:35

1. Adoption verification:

All required fields are passed in according to the interface documentation and the field values are in the correct range and are expected to return the correct result.

2. Parameter validation (forward/reverse):

  1. Required parameters: for each required parameter, design a test case where the parameter is null and the interface error message returns the correct one.
  2. Non-required parameters: design a use case where all non-required parameters are passed in as values, and if the non-required parameters (type, range) are incorrect, is there a reasonable hint?
  3. Parameter value range: the value of the parameter is within/out of the parameter value range specified in the interface document
  4. Length boundary value: conforms to the length range, the length boundary value, more than the length boundary value of the type: conforms to the parameter type, does not conform to the parameter type (arrays, strings, positive numbers, negative numbers, integers, decimals, decimal places, Chinese, English, special symbols)
  5. Special values: null, null, "null", "", " ", 0, values with spaces before and after, special symbols, etc.
  6. Parameters that do not exist in the interface documentation: interfaces passing parameters that do not exist in the documentation will not be exceptions
  7. Parameters passed in the interface are overridden: the same key is passed repeatedly, but the value is different
  8. Incorrect format of incoming parameters: non-json, fewer brackets
  9. Number of parameters: if you accept a list type parameter, if the list size is not qualified then pass a very large list, if the list size is regulated then you need to test the boundary value of the list size; whether the interface can return data correctly;

PS: the back-end code will generally have a special code to deal with the interface into the parameter checksum, you can check the R & D code to help improve the efficiency of the interface parameter checksum test, such as the java project.

The interface entry parameter size needs to be within [1 -3]:

3. Parameter combination:

Very often, parameters in interfaces have multiple values to fulfill different business logic, and when such parameters >1, a parameter combination scenario occurs. For example, parameter A can be passed [1, 2, 3].

Parameter B can be passed ["first", "second", "third"].

  1. Existing combinations: return information is correct
  2. Non-existent combinations: error messages are understandable and error codes are correct
  3. Number of parameters in a parameter combination: if multiple parameters are combined, whether random combinations of any number of parameters are allowed (e.g., 2-parameter combinations, 3-parameter combinations, no passes)

4. Interface prerequisite validation:
Whether prerequisites are met:

  1. token (invalid token/incorrect token format/incorrect token type, logged out logged into another account)
  2. headers (e.g. Content-Type: application/json; charset=utf-8, not filled)

5. The interface returns correct information and status codes, etc:

  1. Status code is correct.
  2. No ambiguity in the error message (add: call the add interface once and then call the add interface again, delete: call the delete interface once and then call the delete interface)
  3. The structure of the returned data is correct
  4. The return data field value is of the correct type

6. Data operation correctness validation:

If the interface is to operate data-related, you need to check whether the flow of data and persistence is completed correctly, generally check whether MySQL and Redis have the corresponding CUD operations can be

7. Concurrency:

That is, to do performance testing of the interface to verify that the concurrency capacity meets expectations

8. Interface permissions/security:

  1. Permission control: when the excuse that only users with specific permissions can operate, validate the processing logic of users with different permissions
  2. Idempotent checksums: packet-capture tools intercept requests and modify sensitive word breaks
  3. Transaction/lock verification: simultaneous operation of the same data modification operation, give the correct information
  4. Parameters are not plaintext: whether the parameters are encrypted and whether the encryption rules are easy to decipher
  5. Password complexity: password security rules, password complexity checking

9. Weak network verification:

Whether the interface can respond normally under a weak network

 

<Previous