Stratified testing divided into a lonely?
Layered testing has been popular for many years. Without layering, I would be embarrassed to say that I am a professional tester. Internet companies are very happy with this, and they have developed one test architecture and one test platform. However. . .
The ideal is always full, but the reality is always the backbone. A lot of manpower and material resources have been invested in unit testing and server-side testing, and a lot of integration testing must be invested in order to maintain the last line of defense. How did the implementation become a problem that has troubled testers for a long time? Layered testing is really divided into lonely?
What is layered testing?
Layered testing: In different time periods, different teams or teams use different test cases to test different focuses of the product. The first thing we see about a system/product is the UI layer, which is the appearance or the whole. These are the top layers. The top layer depends on the service layer below, which is the interface or module. The bottom layer is the unit. This unit is a function or method. According to these three layers, different time periods are selected, and testing performed by different teams and different test cases is called layered testing.
Unit testing
Unit testing is a test for a unit of code (usually a class/method). The value of unit testing is that it can provide the fastest feedback and verify the logical unit during the development process.
Interface (Service/API) testing
Interface testing is a test for business interfaces, mainly testing whether the internal interface function implementation is complete. For example, whether the main business flow can be passed through, whether exception handling is correct, verification when the data is empty, etc.
The main value of interface testing is that the interface definition is relatively stable, unlike the interface or underlying code that changes frequently, so interface testing is easier to write and the maintenance cost of use cases is relatively low. Preparing tests at the interface level is relatively cost-effective.
Integration (UI) testing
Integration testing verifies the correctness of product functions from the user's perspective, tests the end-to-end process, and adds user scenarios and data to verify the entire business flow. Integration testing has the highest business value. It verifies a complete process. However, because it needs to verify the complete process, the cost of environment deployment, use case preparation and implementation is high, and it is not easy to implement.
Hierarchical testing model
Test the ice cream model
Currently, most of the time is spent on UI testing, including UI page elements + functions. 80% of the testing time is spent on UI testing. Insufficient investment in unit testing and interface testing has led to the pressure of testing being placed in the UI testing stage. On the one hand, all parties need to submit tests before they can be carried out. The start time is late and the testing time is tight; on the other hand, there are many exceptions. Scenarios cannot be constructed and testing is insufficient, resulting in missed tests. But this is also the approach adopted by most of our teams.
Test the pyramid model
Google’s automated layering investment proportion is: unit testing (Unit): accounting for 70%; interface testing (Service/API): accounting for 20%; integration testing (UI): accounting for 10%; this is our ideal Test the model. The benefits of this model are self-evident, but because this model requires developers to have high testing capabilities, this model is often difficult to promote in some teams where testing and development are completely separated and in teams with weak development capabilities.
Therefore, based on the current popular microservice architecture in China, a test rugby model is proposed : there are relatively few unit tests; the focus of testing is on interface-level testing, and a high degree of automation is advocated; UI-level testing can be relatively small few.
At present, most Internet projects use the microservice model. Most of the ways of communication between services are through various interfaces. Interfaces are the core of microservice model projects and products. Increase the proportion of interface testing and move the testing to the left, so that testing can intervene early and find problems; the higher the level, the higher the cost of finding and solving problems.
What happened at the buyer’s show?
There are always differences between sellers' shows and buyers' shows. Our idea is to use the pyramid model to implement hierarchical testing. However, in the actual project operation process, when the deadline comes, developers rush to test and test in a hurry. When we go online at the right time, we still need to talk about unit testing, interface testing, and automated testing.
The most common complaint I hear is: I understand everything, but I can’t do it!
So the pyramid model became the ice cream model.
But is this the fault of layered testing? !
Is it possible to do stress layered testing without a deadline? Can it be guaranteed that 0 bugs will go online?
The difference between a buyer's show and a seller's show lies in oneself. Only if one has a model figure can one reverse the gap, one's own cultivation: concepts, systems, talents, and automation maturity.
Do！How？
To get rid of redundant and heavy testing and improve the efficiency and quality of testing, the advantages of layered testing are still obvious:
Reduce costs: Testing is shifted to the left, problems are discovered and solved as early as possible, and development and modification costs are reduced;
Layered testing: When designing and executing test cases, it is more targeted, thinking more clearly, and reducing missed scenarios;
Focused testing: different stages Pay attention to differences, conduct key tests, and implement layer-by-layer protection to reduce leaks and improve quality.
Improvement of business and skills: Strengthening the understanding of business and code in development and testing can better expand and extend skills.
The situation of each project is different. It is obviously difficult to reach the end with one trick. The test model is just a model, and application is the last word. The coverage and access control of unit tests and interface tests must also be adapted to the current conditions. During the practice process, they must be continuously adjusted to adapt to the current status and development of the project, so as to deliver faster and better results.
In the process of practical exploration of every project, you will encounter problems of one kind or another. Only by persisting and believing can you find a bright road!
The following are supporting learning materials. For those who are doing [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!
Software testing interview applet
A software test question bank that has been used by millions of people! ! ! Who is who knows! ! ! The most comprehensive interview test mini program on the Internet, you can use your mobile phone to answer questions, take the subway, bus, and roll it up!
Covers the following interview question sections:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. Web, app, interface automation, 7. Performance testing, 8. Programming basics, 9. HR interview questions, 10. Open test questions, 11. Security testing, 12. Computer basics
How to obtain documents:
This document should be the most comprehensive and complete preparation warehouse for friends who want to engage in [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!
