Preface
After browsing the blog for a while, I found that the series of tutorials on software testing are relatively messy, and no one has sorted out a complete set of knowledge, so I sorted out the information I found, and some personal opinions, and made this set from scratch. Start learning software testing articles
This series will be divided into three stages
Basics
Transition
Automated Testing
Fundamentals (01): Definition of bug level
When doing software testing, the main thing is testing. We have to figure out who we are working with——Find bug
Although finding bugs is a bit general for the position of software testing, for newcomers, there must be an exact definition, which is tentatively designated as "bug finding"
1. So what is a bug?
We can classify bugs by type
(1) Classified according to priority.
(2) Classification based on severity.
2. Main content
Priority classification
According to priority classification criteria
Definition of priority:Refers to the impact of a BUG on the company relative to other BUGs, and the timeliness of resolution.
Level "urgent", for example:
(1) The system cannot work
(2) The test cannot continue to work normally
(3) Special circumstances: such as important customers (item importance)
Level "high", for example:
(1) Demand problem
(2) The realization does not match the demand
(3) Debugging code appears
(4) Functional error
(5) Correlation error
(6) Inconsistent front and rear modules
(7) Link error
(8) Degree of particularity and low performance
(9) Security issues caused by procedures
Note: All errors related to data flow are defaulted to high priority
Level "medium", for example:
(1) The page format is wrong
(2) Compatibility issues
(3) Check error
(4) Picture error
(5) Copywriting errors
(6) Low program performance
(7) Lack of fault tolerance processing
(8) Low functional ease of use
(9) Configuration issues
Note: All errors involved in the text are defaulted to medium priority
Level "low", for example:
(1) Legacy issues
(2) Technical problems cannot be realized temporarily
(3) Reasonable suggestions
Severity classification
Definition of severity:Refers to the impact, risk and visibility of a BUG on users.
Classification standard
Level "urgent", for example:
(1) Error that the program cannot run
(2) Errors where the test cannot be executed
The level is "very high", for example:
(1) Link error
(2) Inconsistent modules before and after
(3) Demand issues
(4) The realization does not meet the requirements
(5) Debugging code appears
(6) Functional error
(7) Low program performance
(8) Security issues caused by procedures
Level "high", for example:
(1) The page format is wrong
(2) Copywriting errors
(3) Picture error
(4) Compatibility error
(5) Check error
Level "medium", for example:
(1) Correlation error
(2) Configuration issues
(3) Low functional ease of use
Level "low", for example:
(1) Reasonable suggestions
(2) Remaining issues
(3) Technical problems cannot be realized temporarily
Precautions
- Some errors can be divided into multiple levels, but the general standard is based on this, and the number of levels can be determined after specific analysis of specific problems.
- For the accuracy of the number of errors, only one error is recorded in each BUG report submitted by the tester
- If there is a problem with similar errors in each module, submit it as a record of multiple modules, that is, you need to submit multiple identical error records instead of one record.
3. Regulations on specifying misclassification
Copywriting error
(1) Wrong text appears
(2) Typos
Picture error
(1) There is an error in the picture address
(2) The picture cannot be displayed normally
(3) The page is missing pictures
Link error
The last thing I want to say is, if you want to communicate and learn, you can come to my big family to chat, click and enter the password: CSDN
has a large gift package for sending it.
