Senior driver takes you around - Test Case

One 、 The test case - Templates

remarks ： The format of the steps should follow the rules of importing Zen

Two 、 The test case - principle

• Clarity ： Whether the description of the test case itself is clear , Whether there is ambiguity ;
• Enforceability ： Is the execution efficiency of test cases considered , Often the steps in the test case are repeated , Use case verification point 、 The expected result is clear ;
• integrity ： Is the structure of use case design clear 、 reasonable , Whether it is conducive to high efficiency PRD Requirements are covered ;
• correctness ： Whether it has fully complied with PRD Requirements , unambiguous ;
• Robustness, ： Whether there are enough invalid equivalent use cases ;

3、 ... and 、 The test case - Title Structure ：        structure ：【 edition - modular - channel 】 page , modular , The function point _ scene

• page 、 modular 、 The structure of the same level of function points is divided by the same latitude . Like the level page 、 Functional modules of the same level 、 Components of the same grade ;
• page ： Refers to the specific page of the tested business system ： Such as the landing page 、 home page 、 Fill in page ;
• modular ： Refers to the block under the tested page , Such as ： Such as the popular activity module under the offer list page 、 Coupon center module, etc ;
• The function point ： It refers to the sub function nodes under the business module , Is the minimum function point
• scene ： Refers to specific verification points

       for example ：
          【9.9-MKT-PC】 Offer list page , Hot events , Production line tab_ When there is no production line
          【9.9-MKT-PC】 Offer list page , Hot events , Production line tab_ When there is a production line
          【9.9-MKT-PC】 Offer list page , Hot events , Production line tab_ When there are multiple production lines
          【9.9-MKT-PC】 Offer list page , Hot events , Production line tab_ Click ticket

Four 、 The test case - Granularity division      4.1、 Basic principle of use case granularity ： Divide by the smallest functional module , To ensure the enforceability of use cases 、 coverage , The granularity requirements for writing use cases in the specification are as follows ：

• technological process
  • The normal flow of a function , Write a test case ;
  • Multiple abnormal processes in a function , Multiple test cases should be written separately ;
• function
  • Different entrances for the same function , The logic is the same , You can combine and write a test case ;
  • Different entrances for the same function , Logic is different from page presentation , Write multiple test cases ;
  • According to equivalence class , Effective equivalence class 、 Invalid equivalence class , Write a use case for multiple scenarios in each category ;
• Interface
  • Normal scene
  • Abnormal scenario , Write multiple use cases for multiple exception scenarios
• data
  • Different data preparation for the same function , Write multiple test cases ;
  • Divide according to the boundary value , Create multiple scenario use cases
• UI
  • The overall layout UI, Write a test case
  • Module area UI, Write multiple test cases
• channel
  • H5 and WEB No matter the same or different scenes , Multiple records should be prepared by channels

5、 ... and 、 The test case - Scene design

6、 ... and 、 The test case - Common design methods
1、 Division of equivalence class
　　 Is to divide the test scope into several disjoint subsets , Their union is complete , Select several representative values from each subset as test cases .
         About to test the input in the process 、 Output 、 Operation is similar Content grouping , Select representative content from each group as test cases , Divide into valid equivalence classes and invalid equivalence classes

         for example ： Test whether a user name is legal , The user name is defined as ：8 A character consisting of digits .
         We can draw the molecular set first ： Empty user name ,1-7 Digit number ,8 Digit number ,9 Digits or more , The digital . Then select from each subset Several representative values ：
　　
Invalid equivalence class
         Empty user name ：“”      
　　 1-7 Digit number ："234"      
　　 9 Digits or more ："1234567890"     
　　 The digital ："abc&!!!"                 
Effective equivalence class
        8 Digit number ："00000000"     
　　
    Convert to test cases ：
    After establishing the equivalence class , The equivalence class table can be established , List all the equivalence class input conditions ： Effective equivalence class 、 Invalid equivalence class , Then, the test cases are designed according to the following three principles ：
    1） Specify a unique number for each equivalence class ;
    2） Design a new test case , Make it cover as many effective equivalence classes as possible , Repeat this step , Until all valid equivalence classes are covered ;
    3） Design a new test case , Make it cover only one invalid equivalent class that has not been covered , Repeat this step , Until all invalid equivalence classes are covered .

2、 Boundary value analysis
       Selected test cases , Should be exactly equal to 、 Just bigger than 、 Just less than the boundary value , for example , For the interval min,max Value , Test cases can be recorded as min,min+,max,max-.
　　
       for example , Assume X Integers ,10≤X≤100, that X The boundary value that should be taken in the test is ：9,10,11,99,100,101.
　    notes ： It's just boundary values , If it is a complete test , In addition to boundary values , A normal value is also required , namely 12-98 Any value between .

3、 Wrong guess
　　 Miscalculation refers to ： When testing a program , People can infer from experience or intuition that there may be various errors in the program , So as to write a method to check these error test cases .
　　 This method has no fixed form , Rely on experience and intuition , A lot of times , We all use it unconsciously .

If the input conditions need to consider the combination , Cause and effect diagram method and decision table method can be used
4、 Decision table method
       Policy table based testing , It is the most rigorous test method in functional testing , It is conducive to logical judgment of complex scenes , The results are obtained by exhaustive conditions , Then optimize and merge the results , Finally, we get a strategy table with clear judgment .
　　 The method is suitable for ：
       Logical judgment of complex scenes , The results are obtained by exhaustive conditions , Then optimize and merge the results , You will get a clearly judged strategy table .
　　
for example , A company's classification criteria for customers are as follows ： The amount of each order placed by the customer is 1000 Yuan of above （ contain 1000 element ）, Reputable , Order setting “ first ” sign ;
Generate decision table

simplify , Merge similar rules or the same actions .（ Two or more rules have the same action , And if there is a very similar relationship between condition items, they can be merged .）

Test cases obtained   ：
Good reputation , Order at 1000 above , Order setting “ first ” sign ;
Order at 1000 Yuan of the following , It is impossible to judge whether the credit is good , Order setting “ normal ” sign ;
Bad reputation , Whether the order is in 1000 Yuan of the following , Order setting “ normal ” sign ;
　　
5、 Cause and effect diagram
Graphically represent various combinations of inputs , Write a decision table , So as to design the corresponding test cases .
Test of parameter configuration class , Use cases can be screened by combining orthogonal test method
Reduce the number of use cases , Cover input combinations with as few use cases as possible .

Orthogonal table is a table generated according to certain rules .
A system with clear business processes , Scenario method can be used to design test cases
Different trigger sequences and processing results of the same event form an event flow , Describe the situation when the event is triggered , It is helpful for the test designer to design test cases , At the same time, it also makes the test cases easier to understand and execute .
For the combination of stateful migration and logical function path , Consider using the function diagram method .
Function diagram consists of state transition diagram and Boolean function . The state transition diagram is described by state and transition , A status indicates where the data is entered （ Or time ）, Migration indicates a change in state , At the same time, it depends on the logical functions represented by the decision table or cause and effect diagram
Against the logic of the program , Check the logical coverage of the designed test cases , If the required coverage standards are not met , Sufficient test cases should be added .