13.0 the orthogonal method
13.1 define
Maximize test coverage with minimum test cases
13.2 Basic Definitions
Level: If the input parameter is sufficient, no indicates the power level
13.3 Procedure
1. Requirements analysis
2. Identify factors and levels
3. Determine the orthogonal table
4. Write test cases according to the orthogonal table. A data is a test case
14. The scene
Draw the flow chart
14.1 define
Scenario method, is flow chart method, using flow chart to describe the user’s use scenario, and then through the flow chart path to design test cases
14.2 Case Ordering take-out
14.3 Test phase of use
Integration testing
The system test
The acceptance test
14.4 Procedure
1. Requirements analysis
2. Draw flow charts
3. Design test cases according to each path of the flow chart
15. False speculation
15.1 define
Analyze with experience and wisdom to predict possible errors in the program
15.2 Application Scenarios
Products of the same type
The task is tight
16. Summary of test case methods
1. Input functions are provided, but there is no combinatorial relation equivalence class between functions
2. Input has boundaries, such as length boundaries
3. Multiple input, multiple output, a combination of inputs and outputs, judgment table, causal diagram
4. Highest coverage with the smallest test cases, orthogonal tables
5. Combination test scenario method between multiple functions
6. False speculation is further supplemented
17. Software defects
17.1 define
Any problems (errors, anomalies, etc.) in the process of software use are called software defects or bugs for short
Order completed -----> Pay 10 90 yuan total = 90 total = 9 --> Pay successful delivery ID --------> Query unit price num = 10Copy the code17.2 Criteria for determining software defects
17.2.1 The software does not realize the functions specified in the requirement specification
17.2.2 The software has errors specified in the requirements specification that should not occur
17.2.3 The software implements functions beyond those specified in the requirements specification
17.2.4 The software does not implement functions that are not specified in the requirements document but should be implemented
17.2.5 Poor user experience, unattractive interface, easy to use, etc
17.3 Causes of software Defects
17.3.1 coding
Error code
17.3.2 Running the System
Software defects caused by faults in the software or hardware system
17.3.3 Design Issues
Errors or defects appear in the design document
17.3.4 Requirements Phase
Description of requirements is ambiguous
17.3.5 The software itself is complex
17.4 Core Content of Software Defects (Key)
| The title | Describe basic information about software defects, such as (user name 5 digits, only 3 digits are displayed) |
|---|---|
| precondition | Describe the underlying conditions for which defects arise |
| Repetition steps | The execution steps in the test case |
| The actual results | The system gives an error in executing the test case execution steps |
| The expected results | Design the expected results in the test case with reference to the requirements specification |
| The attachment | Bug screenshots or error logs help locate bugs |
17.5 Basic Elements of defects (key points)
17.5.1 ID
The only
17.5.2 module:
According to the product specific division, payment module, order module, etc
17.5.3 Defect status
| type | instructions |
|---|---|
| new | new |
| open | Open the |
| fix | Have to repair |
| postpone | delay |
| reject | Refused to |
| close | Shut down |
| reopen | To open the |
17.5.4 Severity of defects
Measure the damage of a bug technically
| instructions | level | type |
|---|---|---|
| deadly | 5 | critical |
| Very high | 4 | major |
| high | 3 | medium |
| In the | 2 | minor |
| low | 1 | tiny |
17.5.5 Priority of defects
The priority of defect handling
| type | level |
|---|---|
| emergency | 5 |
| Very high | 4 |
| high | 3 |
| In the | 2 |
| low | 1 |
17.5.6 Category of defects
The function error
UI error
Compatibility error
Ease of use
improvements
17.6 Submit Precautions for Defects
1. Uniqueness: a defect only needs to be submitted once
2. Ensure reproducibility,
3. The normative
Descriptions need to be accurate and accurate in detail
17.7 Defect Tracking process
17.7.1 scenario
Test new ——> Develop open——> Develop Fix —-> Test close
Test new — — — — — — — — > development open — — — — — — — > development fix — — — — — — — — – > test reopen
Test new ——-> development open ——-> development
Test new ——-> Develop Open——–> Develop Reject