Preface
This chapter mainly introduces the basic knowledge of software defects
1. Software defects
1. Definition
- Software defects refer to the problems that exist in the software (programs, data, documents) that do not meet user needs, and the specific manifestations are as follows:
1) The software does not meet the functions indicated in the requirements specifications
2) The software has errors that the requirements specifications indicate will not occur
3) The functions of the software exceed the scope specified in the requirements specifications
4) The software does not meet the requirements specifications although not specified Goals that should be achieved
5) The software testers think the software is difficult to understand, not easy to use, slow to run, or the end user thinks it is not good
2. The manifestation of defects
1. Functions and features are not implemented or partially implemented
2. Unreasonable design, unclear functions, unclear logic or contradictions
3. Actual results and expected results are different
4. Performance indicators required by specifications are not met
5. Operation errors, Crash, interruption, messy interface
6. Incorrect data, insufficient precision, incomplete or inconsistent format
7. Other problems that users cannot accept, such as long access time, unsightly interface
8. Other problems with hardware or software
3. The status of the software defect
4. Classification of the severity of software defects
5. Priority of software testing
6. Software defect classification
2. Defect report
- The description of software defects is the basic part of software defect reports, and simple, accurate and professional terms should be used to describe defects. Otherwise, it will be ambiguous, may mislead developers, affect the efficiency of developers, and also affect the reputation of testers themselves. It is very important to report defects accurately.
1. Note for reporting defects
1. Try to ensure that the defect can be reproduced : If the submitted defect cannot be reproduced, it will affect the efficiency of the developer
2. Concise, accurate, and complete : When submitting defect reports, testers should think about problems from the perspective of developers, and ensure that developers can quickly locate problems without ambiguity in understanding
3. Only write one defect in a defect report
- the reason
1) Inconvenient distribution: For example, there are two defects in the defect report, which belong to different developers. Who should be assigned to?
2) Inconvenient verification: For example, there are 2 defects in a defect report, defect 1 has been resolved, defect 2 has not been resolved, then should this defect report be closed?
2. Defect writing specifications
- 1) Writing requirements
1. The title is concise and the essential information of the defect is provided. Avoid using vague words, such as: "function interrupted, function is incorrect, behavior does not work", etc. Specific text should be used to describe the symptoms of the defect
2. The steps of reproduction should be detailed and numbered with numbers
3. The actual results should clearly describe the results after recurrence
4. List the expected results
5. Provide accessories
6. Provide severity attributes and attributes that other companies need to fill in
- Note: To avoid some common mistakes
1) Avoid using emotional language and emphasizing punctuation
2) Avoid using vague words
3) Avoid using language that you think is humorous, just describe the problem directly
4) Avoid submitting uncertain defects;
- 2) Defect report display
- 3) Defect handling process
3. Defect tracking
The newly submitted defect is in the "new" state. After it is confirmed to be valid, it becomes the "open" state. The developer changes to the "fixed" state. At this time, the tester needs regression testing. If the verification problem is solved, the state is " Resolved", if the problem still exists, the status is "open"; if the developer task this defect can be postponed and modified, the status is "postponed"; note that at this time, it must be discussed and determined by the relevant project personnel before it can be postponed, otherwise the status is Continue to "open"
4. Defect density (understand)
- The basic defect measurement is **measured by the number of defects per thousand lines of code (pcs/KLOC)**. It is called defect density, and its measurement unit is defects/KLOC. The defect density of a program can be calculated according to the following steps:
1) Cumulative total number of defects found at each stage of the development process.
2) Count the number of newly developed and modified lines of code in the program.
3) Calculate the number of defects per thousand lines=1000*total number of defects/number of code lines .
For example,
a 296,000-line source program has 145 defects in total, and the defect density is:
defect density = 1000*145/296000=0.49 pieces/KLOC.