The purpose of this article is to succinctly complete the writing and maintenance of an interface test case design, which requires everyone's joint efforts and continuous improvement. There are deficiencies and problems that will be exposed in actual use in the future. I hope you will publish them in time for updates documentation.
1. Use case design process:
Rome wasn't built in a day, and use cases weren't done all at once; writing test cases is as much a step-by-step process as perfecting the code itself.
First of all , you must familiarize yourself with the requirements specification and interface design documents, understand the specific usage scenarios of each interface, and understand the performance indicators of the software.
Second , design interface test cases: At the beginning of the coding phase, testers design interface test cases according to the requirements specification and interface design document.
Then , code review: After the development is completed and the coding is completed, under the condition of sufficient time, code review should be carried out. On the one hand, it is to check whether the functional logic of the developed code is correct, and on the other hand, the interface test cases are supplemented by reviewing the developed code.
Finally , after the use case is completed, with the increase in the understanding of the system and the continuous improvement of the accuracy of the use case, the test case needs to be reviewed regularly. Once the test requirements change, the test case must be re-maintained.
Second, the interface test case conception structure:
Stage 1: Development is coding, testing to get requirements documents and interface design documents:
1. Basic functional test (business test):
According to the translation of requirements documents and interface design documents, it is necessary to understand business process rules and usage scenarios of each interface, and design use cases that conform to business logic and interface usage scenarios.
2. Boundary analysis test:
On the basis of basic functions, start to consider the influence of interface input and output parameters. It mainly adopts equivalence class division and boundary value analysis methods.
l Override all required parameters
l Combining optional parameters
l Whether or not the parameter is present, or null
l The order, number, and type of parameters
l The size of the parameter type value, the range of the input value
l The length of the parameter string, Null-max-max+1
l parameter contains special characters
3. Parameter combination test:
On the basis of boundary analysis, various combinations of input conditions and the mutual restriction relationship between input conditions are considered. Mainly use the cause and effect diagram method for use case design.
4. Abnormal situation test:
Whether the interface implementation handles the exceptions. Although the input parameters of the interface are legal, exceptions will also occur in the interface implementation, because the internal exception is not necessarily caused by the input data, but may be caused by other logic. The program needs to handle any exception. For example, an interface needs to log in to obtain the session first. If the interface is called directly, a corresponding prompt should be given.
5. Power level test:
To put it simply, it is time to test for the situation of continuous and repeated submission, especially the scene involving transaction amount, it is necessary to verify how the software handles it.
6. Concurrent testing:
When two or more users operate the same scene at the same time, it may lead to resource contention, deadlock and other phenomena.
7. Transactional testing:
A business process contains multiple operation steps. If an operation fails, the entire operation needs to be rolled back. Or call the reverse interface of the previous step to cancel the operation.
8. Test when large data volume
When the amount of data in the database is large (millions), test the efficiency of adding, deleting, modifying and querying the DB.
9. Environmental anomaly test
When the associated system is down, timed out, or unresponsive, the interface returns the correct prompt, the business logic is correct, and there is no transactional inconsistency.
Stage 2: The development is completed and the coding is completed. Under the condition that the testing time is sufficient, the developed code needs to be code reviewed
1. Review whether the actual business logic of the developed code is correct
2. Implicit condition test:
Conduct a code review to check for implicit default conditions in your code. For example: the getRecommendArticleList interface in the F project, the default query in the code returns 4 records (as shown in the figure below), but it is not mentioned in the interface documentation. If you don't review the code and develop it and don't tell us, this situation will definitely leak Measurement.
3. SQL test:
For the interface that needs to perform database operations, check the relevant sql to verify the correctness of the sql. As shown in the figure below, the filtering conditions of sql are generally more than what the development tells us, so viewing sql for verification is the safest way, and it is especially necessary to design a combination of conditions for verification:
Three, test process verification points:
1. The interface returns data
a) Whether the hierarchical relationship of the returned json data is consistent with the document
b) Numerical type data: especially the amount, whether negative numbers and decimals are converted to json and output correctly
c) The data returned by the interface is consistent with the interface documentation
d) The data returned by the interface is consistent with the database
e) The data returned by the interface conforms to the business logic (such as the transfer function, deducting money from one account, and adding the corresponding amount in the other)
f) For lists, it should be based on the request parameters, and it should also verify whether the length of the list is consistent with the expected value
g) Negative test cases, should verify that ERROR INFO matches actual
2. Database
a) The consistency between the incoming data of the interface and the data inserted into the DB:
b) When a front-end operation involves multiple tables in the back-end DB, each table must be checked for data correctness.
3. Security level:
a) When the data returned by the back-end interface to the front-end contains sensitive information (such as name, ID number, card number, mobile phone number, encrypted password, etc.), it cannot be transmitted in plain text and needs to be encrypted.
b) Logging in the background requires that sensitive information cannot be typed out, or desensitized with asterisks and typed out, specifically:
1) ID number, user password (including encrypted), user mobile phone number, user name, bank card number
2) When the ID number desensitization field is birthday, the birthday cannot be printed in the log
4. Performance level:
a) Interface response time: The time for the interface to process data is also a point of concern for testing. Involving the internal is the optimization of algorithms and codes
b) Interface data packet size: The size of the data packet transmitted by the interface also needs to be paid attention to, especially the interface returned to the front end, and the data packet size of different interfaces needs to be limited.
c) Concurrency carrying capacity: The interface can carry the concurrency in the contract when multiple users are concurrent.