After two weeks of interface testing, it was the first time I was responsible for the interface testing.
The process of carrying out interface automation testing is as follows: 1. Clarify requirements, understand the specific meaning of each interface and the functions to be implemented in general 2. Design interface automation use case architecture 3. Write use cases
Clear requirements: First of all, we should understand what functions the front end needs to implement from the overall function, and clarify the business logic. Then compare the interface to understand the meaning of the interface. In this process, there are some differences between the front-end implementation and the actual parameter transfer of the interface. In the end, it takes time to familiarize yourself with the interface requirements (such as each parameter transfer, whether the parameter transfer is hard-coded or obtained from other interfaces, return Which interfaces can the value act on, I spent a lot of time on these to understand, and I need to find a better way!!!)
Use case architecture design: This is to plan the association between interfaces and interfaces according to the requirements, plan the execution order of some single interfaces, and plan which interfaces can be mocked (in fact, I have not encountered this scene); the overall purpose: 1 . If there is no single interface associated with it, you can design it first. 2. If you need an interface with associated data, you need to plan the execution sequence. Design the source of the parameters of the interface to come from an interface and get it directly from the database (it can be designed to be obtained from the database. Try to get it from the database as much as possible, this method saves time and trouble), or set it as a global variable 3. Pay attention to the problem of the base environment: if there are new and delete operations, then perform the new creation first, and the subsequent editing and other operations are performed on the newly created data, and finally Then perform the delete operation (it is best to directly operate the database to delete the operation, because the interface may have the problem of incomplete deletion); when editing the existing data, it is best to back it up first, and restore it after the operation. Affects the data of the original database table (I haven't tried the backup and restore operation yet, the platform does not support it) 4. The realization of data parameterization (the csv function of jmeter), the parameters of the same interface are passed circularly
Write use cases: After designing the use case architecture, you can write use cases. Use cases are divided into positive and abnormal use cases, which can cover key use cases (for example, when performing parameter reliability tests, abnormal use cases only need to consider null values, parameter types, and parameter lengths). , an empty string); fill in the request header, parameter transfer, and verification for a single use case. There are quite a few pitfalls in this area. For example, there may be problems with the documents provided by the development, and the interface has been changed and not synchronized. You can use postman or browse Packet capture analysis, query database table