Web interface testing can in fact be identical to the functional test, but the measured object is an interface, the interface interaction without it; so the procedure of Example design is versatile.
Commonly used test method is as follows:
1, equivalence partitioning method
2, boundary value analysis
3, cause determination method of FIG.
4, scene analysis
17.4.1 Interface test case design concerns
1, the type of interface protocol (http or https ...).
2. The method of interface request (get / post ...).
3, parameters are required.
4, whether there is a correlation between the parameters.
5, the parameter value range.
6, business rules.
17.4.2 Interface test case design ideas
1) Priority - for all interfaces.
1, exposed interfaces, because usually this interface will give third-party calls.
2, the internal system calls for the core functions of the interface.
3, for internal non-core functions of the system call interface.
2) priority - for a single interface.
1, with a positive test cases priority, followed by reverse cases (usually, non-absolute) with.
2, meets the prerequisites> default parameter value of the parameter whether it carries> Required parameter> whether there is correlation between the parameter> parameter data type restrictions> parameter data type itself limits the range of data values.
17.4.3 Test Case Design Analysis Interface
In general, the interface design test cases need to consider the following aspects:
1 , meets the prerequisites
Some interfaces need to meet the pre-conditions before they can successfully retrieve data. Common need to login Token.
Reverse Use Case:
For the precondition is satisfied (assuming the condition of n), 0 ~ n pieces designed use cases.
2 , whether the carrying value of the default parameters.
Forward use cases:
Parameters with default values is not filled, the reference does not pass, the required parameters are correctly completed and there is "normal" value, do not fill other, a case design.
3 , business rules and functional requirements.
Here the actual situation, the parameters described in conjunction with the interface, the n may be designed with a forward and reverse with Example Example
4 , parameters are required.
Reverse Use Case:
For each required parameter, the parameter values are reverse with the embodiment of a design space.
5 , whether there is a correlation between the parameters.
There is a relationship of mutual restraint between each other some parameters.
Reverse Use Case:
The actual situation, it may be necessary to design 0 ~ n pieces use cases.
6 , the parameter data type restrictions.
Reverse Use Case:
Example parameter values with the inverse of an incorrect type is designed for each parameter.
7 , the data type of the parameter itself limits the range of data values.
Forward use cases:
For all parameters, the design parameters a value for each parameter in the data range of the maximum forward use cases.
Reverse Use Case:
For each parameter (assuming n) of the parameter value of n for each design parameter is beyond the maximum data range using the reverse case.
For each parameter (assuming n) of the parameter values of the design parameters for each of n data range are less than the minimum reverse use cases.
Full consideration the above aspects, it can be done basically cover the following aspects:
Main flow test: a main flow of the normal function of the check.
Branch test: normal branch check function.
Abnormal flow test: parity fault tolerance anomaly.