Business path coverage method for 3.7-box test method

First, the scene method

Scene method is the scene that simulates the user operating software, it is mainly used to test the business process of the system. When we get a test task, we do not first focus on the boundary value of a control, whether the equivalence class satisfies the requirements, but rather first focus on its main functions and whether the business process is implemented correctly, which requires the use of scenario method to complete the test. When there is no problem with the business process testing, that is, the main function of the software is not a problem, we focus on the boundary value, equivalence class and other aspects of the control test.

In the smoke test, the scene method was used to test the test.

1.1 Important concepts in the scene method

(1) Basic flow: An operation path that is implemented according to the correct business process (that is, simulating the correct operation flow);

(2) alternate flow : The process (so, the operating procedure that simulates the error) that causes the program to appear wrong.

For everyone to cut a picture, you can refer to:

Basic design steps of 1.2 scene method

(1) According to the description, describe the basic flow of the program and the various alternative flows;

(2) generate different scenarios according to the basic flow and various alternative flows;

(3) The corresponding test cases are generated for each scene.

Case:

Using scenario method to design the ATM machine withdrawal function test Case

Step one : According to the description, describe the basic flow of the program and the various alternative flows;

Step two : generate different scenarios based on the basic stream and each alternate stream

Step three : generate the appropriate test cases for each scenario, for example :

You can try to write a better test case, after that, I will write to you some or upload a better use case, I think it is OK \ (^o^)/~

Second, the state diagram

To show you the state Diagram Conversion Act example: Currency converter

2.1.1 Case Demo

Enter the renminbi amount, select the country you want to convert, and then enter the exchange rate to calculate the equivalent currency amount for the renminbi you entered.

The user's actions might be:

Enter RMB amount , select Country , Enter exchange rate , click on the "Calculate" button;

Select Country , input exchange rate , enter RMB amount , click on the "Calculate" button;

Enter renminbi amount , Select Country , click the "Clear" button ...

2.1.2 two important concepts

1, the state of the software

The situation at which the software runs at a certain point

For example:

(1) Just start in "idle" state;

(2) After entering RMB amount into "RMB amount has been entered" status;

(3) When all input is completed correctly, click "Calculate" button, the program should be in "show equivalent amount" status;

(4) When the "clear" button is clicked, it is cleared.

2, the input action

User actions to the software

For example:

(1) Enter RMB amount

(2) Click on a Country radio button

(3) Click "Calculate" button

2.2 state transition diagram Method

Find out all the state of the software and all the input actions that cause these states to change, and then use the graphical method to connect the related input actions and States together, and simulate the user's operation and sequence flow.

The core of 2.2.1 state transition diagram method

(1) Status of all software

(2) All input actions that cause a change in state

2.2.2 Steps to use the state transition diagram method

(1) Find out all the input actions of the program,

and numbered each individual action that the user is able to enter into the software;

(2) Find out all the status of the program,

It can be assumed that each input action of the user will change the state of the program, if it is not possible to determine whether it is an independent state, you can first assume "yes"

(3) Find out what action will cause the state to occur, draw a state transition diagram (usually this is a repetitive process);

(4) connect the associated actions and states to design test cases.

Example :

Analysis of Currency Converter program using state transition diagram method

Step one: Find out all the input actions of the program and make the numbering;

Step two: Find out all the status of the program

It can be assumed that each action entered by the user causes the state of the program to change.

1. Idle state after system startup

2. RMB amount entered status

3. States have chosen state

4. Country selected, exchange rate entered status

5. RMB amount has been entered, the state has been selected

6. All input Completed status

7. Show equivalent amount status

8. Error prompt Status

(1) RMB not entered or input error;

(2) Country not selected error ;

(3) The exchange rate is not entered or entered incorrectly.

9. Clear Status

The purge state is considered an idle state and can be

Exit Status

Step three: Find out what action will cause what state to occur, draw a state transition diagram (typically this is a recurring process)

The first 1 rounds, loading all possible inputs separately into the idle state of the system under test, to get a new state

The first 2 rounds, all possible inputs are loaded separately into each state obtained in the previous step, and then the new state is obtained.

3 rounds,1. find the main action and state first

3 rounds,2. find secondary actions and states first

4 rounds,1. find the main action and state first

4 rounds,2. find secondary actions and statuses first

Section 5 round

Step four: According to the state transition diagram, the associated actions and states, design test cases

(1) Write the main operation first (the function is more important or the user action is more frequent action), and then write the secondary operation.

(2) To reduce the number of test cases, a test case is best written along a path to the state transition diagram.

And so on, write all the test cases ...

Finally, we summarize the small knowledge points of the state transition chart method:

(1) Each state is accessed at least once. No matter what method, each state must be tested.

(2) test the most common state transitions that appear to be most commonly seen. It is possible to understand which operations are more common and more important by communicating with customers and developers according to the product specification.

(3) The most uncommon branch between test states. These branches are most easily overlooked by product designers and programmers.

(4) Test all error states and their return values. The error is not handled correctly, the error message is incorrect, etc. is often the case.

Business path coverage method for 3.7-box test method