1. Definition and classification of software problems
1. Classification of software problems
a. software error
b. software defect
c. software faut
d. software faiure
definition:
(1) software error: refers to the software life cycle Undesirable or unacceptable human error, the result of which will lead to software defects.
Points of concern: human error
(2) software defects: those undesirable or unacceptable deviations in the software (programs, data, documents).
Points of concern: deficiencies or incomplete areas
Generally, software defects can exist when one of the following five conditions is met.
a. The software does not achieve the functions specified in the product manual.
b. The software has an error that will not occur as specified in the product manual.
c. The software function is beyond the scope specified in the product manual.
d. The software does not reach the target that the product specification does not indicate but should be achieved.
e. The software testers think that the software is difficult to understand, difficult to use, slow to run, and end users think it is not easy to use.
(3) Software failure: Refers to the undesirable or unacceptable internal state that occurs during the operation of the software. If there is no appropriate measure (fault tolerance or exception handling mechanism) to deal with it in time, software failure will occur.
Concern: internal state
(4) software failure: refers to an undesirable or unacceptable result of external behavior when the software is running.
Focus: Outcome of external behavior2
. Software failure mechanism
Software error——>Software defect——>Software failure——>Software failure
Software error is a kind of human error. A software error must produce one or more software defects.
When a software defect is activated, a software fault occurs.
The same software defect is activated under different conditions, which may cause different software failures.
If software failures are not handled in time using fault tolerance, it will inevitably lead to software failures.
The same software failure may produce different software failures under different conditions.
3. Causes of software errors and defects The
main reason is the inconsistency between the developed software, the requirements specification and the software design specification, and the failure to achieve the goal of potential users' needs in the realization of the software.
2. Software error tracking and management
1. Defect and error severity and priority
a. Severity level
severe: system crash, data loss, data destruction.
More serious: operational errors, wrong results, missing functions.
General: minor issues, typos.
Recommendation: Does not affect the use of flaws or better realization.
b. Priority
Highest priority: Repair immediately and stop further testing.
Second highest priority: must be fixed before the product is released.
Medium priority: It should be fixed before the product is released.
Lowest priority: It may be fixed, but it can be released.
2. Software error tracking management
Description of bug information
a.Bug record information
Test software name
Test version number
Name of test
test event
test software and hardware configuration environment
found that the wrong type of software
error severity level
detailed steps
necessary reference
test annotation
b.Bug processing information
processing Name of
processing time of
the processing steps
of the current state of the error log
3. software error Description of status
a. New information (New): the newly reported software bug (Bug) in the test.
b. Open: The error has been confirmed and assigned to the relevant developers for processing.
c. Fixed (Fixed): The error has been corrected by the developer and is waiting for the tester to verify.
④ Decined: Senior testers or developers believe that it is not a mistake and refuse to modify the bug.
⑤ Deferred: This error will not be fixed in the current version, but will be fixed in the next version.
⑥ Close (Cosed): The error has been fixed and verified.
4. Error management process
step: the
first step: the tester submits new error information and enters it into the error information database of the error tracking management system (such as TD), and the error state is set to the initial state "New".
Step 2: Senior testers verify errors and deal with them accordingly.
① If the confirmation is an error, assign it to the corresponding developer and set the error status to "Open".
② If the senior tester believes that the "error" in the "New" status is not an error, then they refuse to modify and set the error status to "Decined".
Step 3: The developer queries all errors with the status "Open", and handles the errors as follows:
① If the developer believes that the error with the "Open" status is not an error, then refuse to modify and set the error status to "Decined" .
② If it is an error, fix it and set the error status to "Fixed".
③ If it is an unsolvable error, leave a text description and keep the error status as "Open".
④ If you need to postpone the resolution of the error, leave a text description and set the error status to "Deferred".
Note: For unresolved and postponed errors, the developer cannot decide by himself, and generally requires some kind of meeting (review meeting) to pass before approval.
Step 4: The tester queries all errors with the status "Fixed", verifies whether these errors have been resolved, and does the following treatment:
① If the problem is resolved, set the error status to "Cosed".
② If the problem is not solved, set the error status to "Open" again.
5. Error process management principles
① In order to ensure the correctness of error handling, testers with extensive testing experience are required to verify whether the errors found are real errors and whether the written test steps are accurate and can be repeated.
②The processing information should be kept for each error processing, including processing name, time, processing method, processing opinion, bug status, etc.
③Rejection or postponement of handling errors cannot be unilaterally decided by the programmer, but should be jointly decided by the project manager, test manager and design manager.
④After the error is repaired, it must be verified by the tester who reported the error, and the error can be closed after confirming that it has been fixed.
⑤Strengthen the communication between testers and programmers. For errors in the "Deferred" state, they need to exchange opinions to avoid the real errors being missed. For some errors that cannot be repeated, you can ask testers to add detailed test steps and methods, as well as necessary test cases.
I recommend a software testing group here, QQ;642830685 . The group will share software testing resources, test interview questions and testing industry information from time to time. You can actively exchange technology in the group. In addition, there are technical experts to answer for you. problem. After reading, remember to give me a like, your likes are my inexhaustible motivation to update the article. Refill, refill!
After reading