The purpose and principle of software testing
The relationship between software testing and software confidence
Most people's current understanding of the purpose of software testing is based on the testing arguments of two scholars, Glen Myers and Hetzel.
Glen Myers believes that software testing is the process of executing a software program in order to find bugs;
Hetzel believes that testing is a process of building confidence in software, testing is a positive behavior to evaluate the quality or capability of software or systems, and it is a measure of software quality;
Two sides of software testing:
<1 tests to verify that the program works properly;
<2 tests to prove that the program does not work properly;
Test idea:
<1 The design of test cases is divided into positive and negative, which are divided into verification main success field and verification extension scenario;
<2 The execution of tests is combined with a rigorous test case execution process and flexible exploratory test execution;
<3 Focus on finding software errors in the early stage of the test, and focus on verifying the normal use of the software in the middle and later stages;
<4 Unit testing focuses on the program doing the right thing, while integration testing and system testing focus on the program's errors
<5 Automated testing mainly focuses on verifying the correct behavior of the program, while manual testing focuses on finding the wrong behavior of the software;
Verification and Validation of Software Testing
The purpose of software testing can be understood in terms of verification and validation:
Verification: At each stage of the software life cycle, check whether the product of the current stage meets the specification definition of the previous stage;
Confirmation: At each stage of the software life cycle, check whether the work products at the end of each stage meet the specifications and requirements defined in the requirements document at the beginning of the software life cycle;
principles of software testing
Good enough
Test input and output should be properly weighed. Insufficient testing is irresponsible for quality, but too much testing will result in a waste of resources.
With the input of the test, the output of the test basically increases, but when the test is invested in a certain proportion, the test effect will not be significantly enhanced.
Zero defect is the ideal pursuit, and Good enough is the pursuit of display. Do not blindly pursue the best test effect and invest too much testing resources. The testing investment should be considered according to the actual requirements of the project and the quality requirements of the product.
Appropriately adding other quality assurance methods, such as code review, peer review, requirements review, design review, etc., can effectively reduce the dependence on testing, and ensure that software defects are discovered as early as possible, thereby reducing the overall cost of quality.
Pareto Principle
The 80-20 principle in testing means that 80% of the bugs can be found and corrected in the analysis, design, and review stages, and the remaining 16% need to be discovered through systematic software testing. Bugs can only be exposed during prolonged use by the user.
Test as early as possible
The earlier a bug is found, the less expensive it is to fix it; the later a bug is found, the more expensive it is to fix the software.
Put more tests where there are more errors
The accumulation of software defects is usually caused by the development status of the programmer at the stage of the defect occurrence or the responsibility of the code scope in which the defect occurs.
assimilation effect
The longer testers stay on the same project, the more likely they are to overlook obvious problems.
After working with developers on a project for a long time, testers are more likely to be influenced by the developers' views on the software and become more likely to agree with the developers' views.
The more familiar the tester is with the software, the easier it is to overlook some seemingly minor problems.
continuous testing
Continue testing, and try to avoid testing arbitrarily.