1. What is interface testing?
Interface testing is testing that tests the interfaces between system components. Interfaces are primarily used to detect interaction points between external systems and internal subsystems. The focus of the tests is to check the data exchange, transmission, control and management processes, and the mutual logical dependencies between the systems.
2. Why do interface tests?
In the history of Taobao system, functional testing and performance testing first appeared, followed by automated testing. But today, Taobao's architecture is no longer the traditional MVC structure, and the system is developing in a distributed, business-centric, and highly available direction. Today's system architectures are complex, with many interfaces between systems. Traditional functional testing, performance testing and automated testing can no longer meet the needs of system development, and a more effective, practical and sustainable testing method is urgently needed.
Interface testing is generated under this demand. First of all, with the continuous increase of system complexity, the test cost of traditional test methods increases sharply, and the test efficiency drops sharply (according to the data model, a bottom-level bug can cause about 8 top-level bugs, and a bottom-level bug can easily cause the entire network downtime. On the contrary, when the complexity of the system increases, interface testing can provide a low-cost, high-efficiency solution.
Secondly, the interface test is different from the traditional unit test, it is a comprehensive, efficient and continuous test of the system interface from the user's point of view.
Finally, interface testing is automated and continuous integration, which is why interface testing can be the root of low-cost, high-yield.
In short, interface testing is the best solution driven by the inherent requirements of high-complexity system quality and low-cost economic benefits. Interface testing is a complete system, including functional testing and performance testing.
3. The process of interface testing
According to previous practical experience, interface testing can be divided into the following steps: requirements analysis and design review, test framework and technology selection, test plan formulation, test environment construction, test case design and review, test implementation and execution, continuous integration. Next, each step will be described in detail.
1. Requirements analysis and design review
Almost all software activities start with requirements analysis, as does interface testing. At this stage, we have two tasks: first, fully understand the requirements and ensure that everyone has the same understanding of the requirements; second, try to find out the problems in the requirements themselves.
After the requirements analysis, enter the system design phase. System design should not be the sole responsibility of the system designer or developer. As an interface tester, you should be able to provide some solutions or suggestions for system design from the perspective of testing, optimize the design, and improve the testability of the system.
2. Test framework and technology selection
After the system design review, all the technologies needed to implement the system should have been selected. At this stage, interface testers need to choose their own testing framework and technologies to be used according to the system design. Of course, this is not necessary. If the technical framework of the project you are testing is similar to the technical framework of the project you have tested before, you can use the previous testing framework and technology, or make some adjustments on this basis. If the project being tested uses a different technical architecture, then it is necessary to carefully consider how to choose the appropriate testing framework and technology.
The choice of interface framework and technology has many factors. The principle is to choose the framework and technology that best meet your testing needs, and try to make your project members familiar with it. There is no need to choose a tool with many functions but complicated and difficult to understand just to improve the technical content of the test.
3. Formulation of test plan
Test planning for interface testing is basically similar to functional testing. At this stage, it is necessary to clarify which test resources are available, how to allocate test resources, what needs to be done during the entire test process, and what should be done at each point in time. The most important and most overlooked point is risk assessment. While it is impossible for us to identify all risks, we can identify most potential risks and manage them empirically. Good risk management is a reflection of the maturity of a software team.
4. Construction of test environment
After the test framework and technology selection is complete, the test environment can be built. A typical process for building an environment in UI testing might be as follows: First, you will build a base project for UI testing and design a good structure for the project. In this project, you will import the test framework and dependencies of your choice, prepare the necessary configuration files for these frameworks and dependencies, and link this project with the project of the system to be tested in some form (usually a project dependency) linked. In this environment, it is possible to run and pass a basic test.
5. Design and review of test cases
The test case design of the interface is to design the test with the interface as the unit. During the design process, we focus on the possible input parameters of the interface and what are the expected output results. Of course, when necessary, the performance of the interface and the expected pressure should also be considered. During this process, it is very important to prioritize the different tests, which will guide you which tests should be completed first and which tests can be delayed when testing resources are insufficient. That is to say, when the test resources are sufficient, the test can also be completed according to the priority. In this way, once a certain risk occurs, it is basically guaranteed that the high-priority work has been completed and there will be no panic.
After the test case design is completed, it needs to be reviewed, and the results of the review should be recorded in some form as the final plan for test implementation. The evaluation is best attended by the following personnel: demand side, design side, development side, functional testing side, interface testing side and their direct supervisors. Different roles will consider test design from different angles, so test design will be greatly improved in this process.
6. Test Implementation and Execution
Once the design is finalized and reviewed, testing the implementation is relatively straightforward. Nothing means that a test case is implemented and run through a programming language.
In the process of test implementation, it may be found that the test design is not perfect, or because of changes in requirements, new test cases need to be added. No matter what the reason is, in the process of implementing the test, once there is a perfect place, it should be recorded immediately, so as to ensure the integrity of the test more effectively.
In this process, we should also make test reports (including daily reports and final reports), so that the whole team can grasp the quality of the project in time, so that different roles can arrange the work correctly.
7. Continuous integration
Continuous integration is an important technical means for interface testing to realize fully automated regression testing. To put it simply, continuous integration is to continuously run the written test code and use version control technology to make the test code always test the latest version of the system interface.
When the interface test reaches this stage, our goal is to keep the test code running continuously to ensure that when the test code fails, the problem can be located and solved in time. While developers maintain the system, we also maintain our test code based on the results of continuous integration.
Finally, it is important to note that while the steps mentioned above are the norms that our interface testers follow, unlike other tests such as functional testing, interface testing needs to be done concurrently with development. We should be involved when the project starts, and the testing is basically completed when the coding is completed. Every step in the middle is also closely related to development. Therefore, our interface test engineers are also called test development engineers, we need both testing knowledge and coding ability.
8. Quality Evaluation Standards
Whether the interface coverage meets the requirements.
1) All externally called interfaces must have corresponding test cases, and the coverage rate must reach more than 95%.
2) The coverage rate of all internally used interface test cases involving the main functions of the product should be above 90%.
3) For all interfaces used internally and involving secondary functions, the coverage rate of the test code will increase with the increase of the complexity and importance of the interface.
Test whether the verification of the interface business rules in the test case is complete.
1) The test case should cover the main business rules of the interface. The main business rules of the interface are the main functions of the interface, which affect the business implementation and call status of the interface.
If you publish a treasure, then publish a brand new, second-hand, auction, idle treasure, etc. is the main function.
2) The test case should cover the common business rules of the interface. Or an example of posting a baby, 80% of the sellers will add pictures, want links, etc. According to the description. this business
The rule will not affect the normal call of the interface. But it will affect the user's usage habits. Therefore, the test case must include a link to the image and a validation of the desired link in the description field.
3) Parameter validation should cover validation of boundary values and parameter-specific business rules. Many interfaces have certain restrictions on their parameters, for example, field lengths are limited to .
For test cases where the length of this field is 4, 5.
Whether to cover the dependency tests between interfaces in the test case. For example, in an association test for an added interface, other associations should be called with the return value of the added interface as a parameter.
For example, modify and delete interfaces, and verify that they can be called and successfully called.
The degree of impact of legacy bugs on the system:
1) Frequently called interfaces must not contain bugs related to the main business rules and common business rules, and the bug legacy rate of the secondary business rules should be below 0.2%.
2) Interfaces that are not frequently called cannot contain bugs in major business rules. The bug omission rate of common business rules is less than 2%, and the bug omission rate of minor business rules is less than 5%.
Whether the test case is consistent with the test code.
Whether the test case can be continuously regressed.
Whether the tested interface meets the standard of the caller, and whether the caller can use the interface to develop the application designed by the product design specification.