The software testing phase includes unit testing, integration testing, system testing and acceptance testing.
Once a defect is found in the unit test phase, it is easy to modify; and if a defect is found in the system test or acceptance test phase, the tester needs to report it to the developer through the defect management tool. In order for the developer to quickly and accurately locate the defect, the test Personnel need to accurately write the version where the problem was found, the steps that generated the error, and the content of the defect in the defect report (sometimes screenshots or log information need to be attached).
The developer finds the line of code where the problem is located through the defect report and repairs it, recompiles it and then retests it to the tester. If the test passes, close the defect repair process, otherwise describe the problem and let the developer modify it again.
This process is very time-consuming and labor-intensive. It can be seen that unit testing is very effective in software development.
However, unit testing is not a panacea. Defects in business logic are difficult to be found in the unit testing phase, and can only be verified in the system testing or acceptance testing phase.
In the days when I just graduated, unit testing was often to run the main function in the program (such as the main() function in C language), and verify it in a semi-manual way by printing statements or monitoring the value of variables, but this method is used It was discarded when it was finished and could not be well preserved.
With the advent of the XUnit framework and code scanning tools, unit testing has become easier and unit testing code can be reused. With the emergence of Agile and DevOps, iterations have become more and more frequent, and the reuse of unit test codes and code scanning tools has become more and more frequent, especially with the introduction of TDD (Test Driver Developed, Test Driven Development) , Unit testing is getting more and more attention.
For a piece of product code, the unit test code that needs to be matched may be several times or dozens of times the code itself. This is why many people know the importance of unit testing, but because of time constraints, they ignore the unit testing phase.
My suggestion is that products can be divided into the following five categories.
1. Internet products of To C.
2. Internet products of To B.
3. Traditional non-embedded software products, such as ERP, finance, CRM, management and other software products.
4. Traditional embedded software products.
5. Security-level software products, such as some financial, medical, aviation, and aerospace software products.
For products of category 1, 2 and some of category 3, the number of unit tests can be reduced, and the number of interface tests can be increased by using a spindle test model or a honeycomb test model.
The pyramid test model is adopted for the 3rd and 4th types of products, and the test coverage satisfies the branch coverage, condition/branch coverage and path coverage as far as possible, while for the embedded products, the control flow coverage also needs to be considered.
A pyramid test model is adopted for category 5 products, and the test coverage satisfies branch coverage, condition/branch coverage, and path coverage as far as possible, and MC/DC must be considered for key modules.
Finally : The complete software testing video tutorial below has been organized and uploaded, and friends who need it can get it by themselves [Guaranteed 100% free]
Acquisition of complete set of information
