Design and common methods of test case documents

Principles for writing test case documents

1. Of use cases Clarity
   Clear description .
   Result only .
2. Of use cases Representative
   It can represent and cover all kinds of reasonable and unreasonable .
   It can represent and cover all kinds of legal and illegal .
   Can represent and cover all kinds of boundaries and cross-border .
3. The result of the use case Decidability
   That is to say, the correctness of test execution results can be determined .
   Each test case should have the corresponding expected results .

Black box test method

1. Equivalence class division – Classify the test conditions ：
   Equivalence class division ： Put all the possible input data , That is, the input field of the program is divided into several parts （ A subset of ） Equivalence class , Then select a few representative data from each subset / Equivalence classes as test cases .
   It is mainly divided into effective equivalence classes （ positive , No mistake. ） Invalid equivalence class （ negative , Throw an error )
   Case study ： Wechat sends red envelope ：0.01——200
   analysis ：
   1： To test the function of normal transmission ： Effective equivalence class ：0.01-200
   2： To test exception sending , Close to the user's use scenario ： Invalid equivalence class ：1、 Less than 0.01 2、 Greater than 200：0-200.01
   The above is the equivalence classification
   3： When there are too many tests , Choose the combined boundary value method ： Exactly equal to / Greater than / Values less than the range , As test data
   Tap hidden needs ：
   1： The red envelope amount must be a number
   2： Red envelope input cannot exceed two decimal places
   3： The red envelope amount cannot be blank
   4： The red envelope amount cannot be negative and 0

The test case ： Equivalent valid class
Use case design description Test data Cover equivalence class （ The main points of ： Effective equivalence classes cover as many effective equivalence classes as possible with one use case ）
The selection of invalid equivalence classes is opposite to that of valid equivalence classes （ A column covers only one ）

Case summary ： WeChat Lucky Money , Email registration

2. Boundary value analysis – Test for critical conditions （ This kind of method is often used in combination with the equivalence class division )：
   The principle is to take values on the boundary of conditions or ranges , According to the specific situation , Take respectively equal to 、 a little bigger than 、 Slightly less than the condition or range value .
   It's mainly ： Two point method , Three point method , Four point method
   Common boundary value situations ：
   The cursor is at the top left of the screen 、 The bottom right position ;
   The first and last lines of the report ;（ Two point method ）
   The first and last of the array elements ;（ Two point method ）
   The second part of the cycle 0 Time , First and penultimate 2 Time 、 Count down for the first time （ Four point method ）

3. A false assumption – Based on empirical intuition, the calculation is wrong ：
   According to intuition or Experience Speculate on various errors that may exist in the program , Thus there are Write targeted test cases to check these errors .
   Higher requirements for the ability of testers .
   characteristic ：
   Highly subjective
   Compared with the test set generated by other methods , Easier to find defects

4. Cause and effect diagram – A combination of multiple test conditions ：
   Cause and effect diagrams are suitable for combinations with various input conditions , And there is a certain restrictive relationship between various conditions
   The advantages of cause and effect diagram ∶
   1. The combination of input conditions is fully considered , Sufficient coverage of the combination .2. Ultimately, each use case covers multiple input scenarios , It is helpful to improve the test efficiency .
   3. During the design process , The constraints between input conditions are considered , Avoid invalid use cases , The effectiveness of use cases is high .
   4. Be able to get the expected output of each test item at the same time
   shortcoming ∶
   1. When there are many inputs of the tested characteristics , The scale of the decision table will be very large .
   2. The constraints between inputs cannot effectively distinguish whether the input really needs to be combined , It will cause the input that does not need combination test to be combined , Thus producing use case redundancy .

5. Scene analysis – Design different scenarios according to business processes ：
   Scenario analysis is applicable to many process branches , The logic is more complicated , Conditions 、 There are many functional requirements under special circumstances .
   You can use the flow chart to sort out the flow lines and test them one by one , If the development is not provided, you need to paint by yourself , If provided, it can generally be found in the requirements specification .

6. Output domain coverage ： Overwrite all outputs , Regardless of input
   There are valid and invalid rules for visible parameters in the requirements interface , Unlimited input conditions , There are output constraints , We need to push the input backward from the output according to the business ,
   1. Ask the developer or find out all the output results according to the code
   2. Check whether the written test case covers all the output results , If there are test cases that are not covered, supplement the test cases
   3. Backward deduce the test case steps and test data according to the output results

7. Input domain coverage ： Overwrite all inputs , Regardless of the output , Related to equivalent class boundary value method

8. Anomaly analysis ： When testing, we must test the abnormal conditions （ Abnormal operation 、 Analyze the faults caused by software and hardware defects ）, power failure , Abnormal condition of network disconnection , Design test cases based on this .
   Mainly for testing the system Fault tolerance 、 Fault recovery capability To test .
   Simply put, it means that the system breaks down artificially , Then check the fault recovery capability of the system .
   On the other hand , Abnormal test for the system （ Did you do something you shouldn't do ） Also through anomaly analysis and other means .

9. Exploratory testing ： most , No requirements, no use cases , Information is not complete , Pit , Or test according to your own experience , Try to test the system function

10. State migration

11. Orthogonal experiment

12. Decision table