How to design test Cases using scenario method

Let's get to the bottom of this. The basic concept of the scene method.

By using the scene to describe the function point of the system or the business process, thus improving the test effect. Scenario law typically consists of basic and alternate streams, starting with a process that describes the process that is determined by the path that passes through, traversing all the basic and alternate streams to complete the scene.

Why the scene method can describe the whole event so clearly. Because, today's system is basically the event to trigger the control process. Such as: we apply for a project, we need to submit the approval documents, and then by the department manager for approval, after approval by the general manager to final approval, if the department manager audit does not pass, the direct return. The scenario is formed when each event is triggered. The event flow is formed by the different triggering sequences and processing results of the same event. This series of processes we use the scene method can be clearly described clearly.

The diagram below shows an example of the basic situation of the longest-seen scene in the web.

　　

In this diagram, there is a basic stream and four alternate streams.

Each of the possible paths through the use case can identify different use case scenarios. Starting with the basic flow and then combining the basic and alternate streams, you can determine the following use case scenarios:

Scenario 1 Basic Flow

Scenario 2 Basic Stream Alternative stream 1

Scenario 3 Basic Stream Alternative stream 1 alternative stream 2

Scenario 4 basic Stream Alternative Stream 3

Scenario 5 Basic Stream Alternative Stream 3 alternative stream 1

Scenario 6 basic Stream Alternative Stream 3 alternative stream 1 Alternate stream 2

Scenario 7 Basic Stream Alternative Stream 4

Scenario 8 basic Stream Alternative Stream 3 alternative stream 4

From the example above, we can see how the scenario is determined using the basic and alternate streams.

Basic flow: Using a straight black line, is the simplest path through the use case (no error, the program starts directly to the end)

Alternate streams: In different colors, an alternate stream may start from the base stream, execute under a specific condition, and then rejoin the base stream, or it may originate from another alternate stream, or terminate the use case, not in the underlying stream; (various error cases)

The following is the basic design step 1 of the scenario method. According to the description, the basic flow of the program and the alternative Flow 2 are described. Different scenario 3 is generated based on the basic stream and each alternative stream. Generate the appropriate test case 4 for each scenario. Re-review all of the generated test cases, remove redundant test cases, and determine test data values for each test case after the test case is determined

All right. Some basic concepts and design methods of scene method are discussed. Presumably, we've got some understanding. Let me give you a simple example to explain. Here, I don't have an example of a popular ATM online. I'm combining the things I've encountered in previous projects. Design a simple example to illustrate the next.

There is an example of online shopping, users enter an online shopping site for shopping, purchase items, online purchase, then need to use account login, login success, to pay the transaction, after the successful transaction, the purchase order, the completion of the entire shopping process.

The first step is to identify the basic and alternate flows:

Basic flow	Log in to the online shopping site, select items, log in to account, pay for transactions, generate an order form
Alternate Stream 1	Account does not exist
Alternate Stream 2	Incorrect account or password
Alternate Stream 3	Insufficient user account balance
Alternate Stream 4	User Account no Money
Alternate Stream X	User exits the system

The second step is to determine the scenario based on the basic flow and the alternate flow:

Scenario 1-Successful shopping	Basic flow
Scenario 2-account does not exist	Basic flow	Alternate Stream 1
Scenario 3-Incorrect account or password	Basic flow	Alternate Stream 2
Scenario 4-Insufficient user account balance	Basic flow	Alternate Stream 3
Scenario 5-User Account no money	Basic flow	Alternate Stream 4

The third step is to design the use case

A test case needs to be identified for each scenario. You can use matrices or decision tables to identify and manage test cases.

The following shows a common format in which the rows represent the individual test cases, and the columns represent the information for the test case.

In this case, for each test case, there is a test case ID, a condition (or description), all the data elements involved in the test case (as input or already in the database), and the expected results.

The

constructs the matrix by starting with the data elements needed to determine the execution of the use case scenario. Then, for each scenario, at least determine the test cases that contain the appropriate conditions that are required to perform the scenario. For example, in the matrix below, V (valid) is used to indicate that the condition must be VALID (valid) to perform the basic stream, and I (invalid) is used to indicate that the desired alternate stream will be activated under this condition. The use of "N/a" (not applicable) in the following table indicates that this condition does not apply to test cases.

Test case ID	Scene/Condition	Account	Password	User account balance	Expected results
1	Scenario 1: Successful Shopping	V	V	V	Successful shopping
2	Scenario 2: Account does not exist	I	N/A	N/A	Prompt account does not exist
3	Scenario 3: Incorrect account or password (account number is correct, password is incorrect)	V	I	N/A	Prompt for account or password error, return to basic stream step 3
4	Scenario 3: Account or password error (account error, password correct)	V	I	N/A	Prompt for account or password error, return to basic stream step 3
5	Scenario 4: Insufficient user account balance	V	V	I	Prompt account balance Insufficient please recharge
6	Scenario 5: User account has no money	V	V	I	Prompt account balance please recharge

The fourth step is to design the data and fill the data into the use case table above.

Expected result td> successfully shopping, account balance reduced by 200 Yuan

test case ID	scene/Condition	account	password	user account balance
1	Scenario 1: Successful shopping	Sue	1s2	$
2	Scene 2: Account does not exist	Jim	N/a	n /A	prompt account does not exist
3	scene 3: Wrong account or password (account number is correct, password is incorrect)	Sun	1234ZXC	N/A	prompt account or password error, return to basic stream step 3
4	Scene 3: Account or password error (account error, password is	Suns	123456	N/A	prompt account or password error, return to basic stream step 3
5 /td>	Scenario 4: Insufficient user account balance	Van	1v2	1	prompt account balance not enough please recharge
6	Scenario 5: User Account no money	Tom	12ZXCDD	0	prompt account balance please recharge

The test cases written above are only part of the test case for shopping. Other test cases that are required.

We can add and expand it after we finish writing, and achieve better coverage.

The scene method is introduced here. It is estimated that everyone knows it. I hope that this will help us a lot.