Interface test point coverage
Write catalog title here
1. Input parameter verification
1. Parameter input parameter type verification The
input parameter type is consistent with the interface document.
2. Parameter required verification.
Required fields are not empty or null.
3. Parameter length
a, database length recorded by the interface document
b, field length required by the requirement document
4. Parameter value range
a, enumeration value, need to be calibrated Verify each enumeration value. In particular, when different enumerated values correspond to different scenarios,
b. There is a limited range, and boundary values can be used to design test cases. If the value of the password length is 6-12, you need to determine the upper point 6, 12, the away point 5, 13, and any inner point 9.
5. Parameter validity verification
If the input parameter type of the phone number is string, but in the case of string, it must meet the rules of the number of digits and segment number of the phone number itself, otherwise it is an invalid parameter value. Another example is the frame number. Although the input satisfies the length of 17 digits, it is not a correct frame number in reality and can also be judged as invalid.
6. Parameter default value verification
Some parameters need to have default values in the requirements document or user function usage habits. If pagesize and current are not passed when turning pages, a default value should be given to him according to usage habits or needs. Another example is the version details. If the participant is not passed, he should default to the latest version.
7. Multi-parameters
need to be judged according to the specific system framework. If the framework can automatically filter, you don't need to consider it. If the system accepts extra parameters, you need to make limit exception requests when requesting.
8. Fewer parameters
Non-required parameters can be omitted, and mandatory parameters will not be transmitted and an error will be returned.
2. Result verification
1. Normal return result verification The
return parameter is consistent with the interface document. The parameter value conforms to the business scenario.
2. Abnormal return result verification
Throws friendly prompts for abnormal situations.
3. Database data verification The
corresponding changes to the database corresponding tables and fields.
4. Generated file verification
There are downloaded files to be verified.
Three, interface logic
1. Business process
Branch coverage—scene coverage The
design flowchart is designed according to the branches in the figure, and different branches have different scenarios
2. State transition
Design state transition diagram, design different interface use cases according to different state transitions
Fourth, the processing of abnormal data
1. Repeat submission
2. The processing flow of abnormal data generated in the abnormal process; such as interface timeout, interface exception, whether the process continues to execute after the interface request fails, and how to deal with the data after the failure;
Five, interface security
Text input box sql injection and xss attack
token (the interface has no token value, it should report an error)
header (delete the information inside, it should report an error)
unique identification code (the mobile terminal will have)