Excerpt from the art of software testing (I)

Chapter 2 psychology and economics of software testing Conclusion 2.4 When reading the next part of this book, remember the following three important test principles: • software testing is performed to detect errors Program . • A good test case has a high possibility of discovering an undiscovered error. • A successful test case can discover an undiscovered error. Chapter 2CodeInspection, inspection and review Some testers found that the manual method is more effective than the computer-based method for certain types of errors, while for other error types, the computer-based method is more effective. This means that code check/walk-through is complementary to computer-based testing. If either of them is missing, the error check efficiency will be reduced. 3.3 Error List for code check Conclusion 3.7 This chapter discusses a form of testing that software developers typically do not consider-manual testing. Most people think that because the program is written for machine execution, the machine should also test the program. This idea is problematic. The manual testing method is very effective in exposing errors. In fact, most software projects should use the following manual testing methods: • Use the Error List for code checks. • Check the group code. • Desktop check. • Peer review. Chapter 1 design of Test Cases
In general, the most efficient of all methods is random input testing. Chapter 1 of this book proves that black-box and white-box tests are usually impossible, but it is also recommended that you combine these two testing elements to form a reasonable testing strategy.
The test method to be discussed in this chapter is as follows: black box testing, white box testing, equivalence classification, statement coverage, Boundary Value Analysis, determination coverage, cause/failure analysis, condition coverage, multiple conditions coverage, we recommend that you first use the black box testing method to design test cases., then, use the white box test method as needed to design complementary test cases. The following describes the famous white box testing method. 4.1 white-box testing) 4.1.1 logic-coverage testing) Decision coverage or branch coverage is a stronger logic coverage criterion than decision coverage. The criterion is condition coverage. In general, for a program that contains only one condition, the simplest test criterion is to design a sufficient number of test cases for implementation: (1) execute all the results of each judgment at least once; (2) call all program portals (such as entry points or on units) at least once to ensure that all statements are executed at least once. 4.1.2 Equivalence partitioning) One way to determine this subset is to realize that a carefully selected test case should have two other features: 1. strictly control the increase of test cases and reduce the number of other test cases that must be designed to meet certain daily standards for rational testing. 2. It covers most other possible test cases. That is to say, it will tell us which errors will be discovered and which will be missed if this specific input set is used or not used. There are two steps to design a test case using the equivalence division method: (1) determining the equivalence class; (2) generating a test case. 4.1.4 boundary-value analysis) Experience has proved that, compared with other test cases without boundary conditions, the test cases with boundary conditions considered have a higher test return rate. The so-called Boundary Condition refers to the states in the input and output equivalence classes that happen to be in the boundary, exceed the boundary, or below the boundary. Therefore, the important difference between the Boundary Value Analysis Method and the equivalent division is that the boundary value analysis is in the state of equivalent division boundary or near the boundary. That is, most of the 42 test cases represent common errors that may be made during the development of the program. However, if we adopt a random generation or special test case design method, most of these errors are not checked out. If used correctly, boundary value analysis is one of the most effective test case design methods. 4.1.5 cause (cause-effect graphing) One weakness of Boundary Value Analysis and equivalence division is that the combination of input conditions is not analyzed. The reason helps you select an efficient test case set in a systematic way. It also has an extra advantage, that is, it can point out the integrity and ambiguity of the Specification Description. 4. 2 error guessing)
Incorrect guess is primarily an intuitive informal process, so it is difficult to describe the procedure of this method. The basic idea is to list possible errors or error-prone situations, and then write test cases based on the list. 4.3 Test Strategy The test case design methods discussed in this chapter can be combined into an overall strategy. The reason for the combination is clear. Each method can provide a specific set of useful test cases, but it cannot provide a complete set of test cases separately. The policy of a combination is as follows: 1. If the Specification Description contains In case of a combination of input conditions, we should first use the Causal Analysis Method . 2. In Use the Boundary Value Analysis Method in all circumstances . Remember that this is an analysis of the input and output boundaries. Boundary Value Analysis can generate a series of complementary test conditions. However, as described in the "causal analysis" section, most or even all of the conditions can be integrated into the causal analysis. 3. Should be Determine valid and invalid equivalence classes for Input and Output To supplement the test cases confirmed above if necessary. 4. Use More test cases are added by Error Prediction Technology . 5. For the above test case set check procedures Logical structure. Use of decision coverage, condition coverage, Criterion for determining/condition overwriting or multi-condition overwriting (the final one is the most complete) . If the coverage criteria are not met by the test cases identified in the previous four steps, and meeting the criteria is not impossible (the combination of certain conditions may be impossible due to the nature of the Program ), A sufficient number of test cases are added to meet the coverage criteria. Chapter 4 module (unit) Testing
5.1 Test Case Design
In general, the model test is for white box testing. The above specification description is not suitable for the causal analysis method (no set of input conditions that can be distinguished by the ability to check the combination ), therefore, the boundary value analysis method is used. 5.2 incremental test During the execution of the module test, we have two main considerations: first, we have discussed how to design an effective test case set. Second, assemble the module into a working program.