Test Case Design Whitepaper--Scenario design methodology

Test Case Design Whitepaper--Scenario design methodology
Author:vince Source: Http://blog.csdn.net/vincetest

I. Introduction to the methodology

Today's software is almost always using event triggering to control the process, the event triggered when the scene is formed, and the same event different trigger sequence and processing results to form an event stream. This idea of software design can also be introduced into the software testing, can be more vivid picture of the event triggered when the scene, the test designer to design test cases, while making test cases easier to understand and execute.

Basic and alternate streams: as shown in the following illustration, each path through a use case is represented by a basic stream and an alternate stream, and the straight black line represents the basic flow, which is the simplest path through the use case. Alternative streams are expressed in different colors, and an alternate stream may start from the base stream, execute under a specific condition, and then rejoin the base stream (such as alternate streams 1 and 3), or it may originate from another alternative stream (such as alternative stream 2) or terminate the use case without re-joining a stream (such as alternate streams 2 and 4).

two. Combat Drills

1. Example Description

The diagram below shows the flow diagram for the ATM example.

2. Scene Design: The resulting scenario is shown in the following table.

Table 3-8 Scene Design

Successful withdrawal of scene	Basic flow
No cash in scene 2--ATM	Basic flow	Alternate Stream 2
Insufficient cash in scene 3--ATM	Basic flow	Alternate Stream 3
Scene 4--pin error (and input opportunity)	Basic flow	Alternate Stream 4
Scene 5--pin error (no more input opportunities)	Basic flow	Alternate Stream 4
Scenario 6--account Not present/Wrong account type	Basic flow	Alternate Stream 5
Scenario 7--account balance Insufficient	Basic flow	Alternate Stream 6

Note: For convenience, loops in alternate streams 3 and 6 (scenes 3 and 7) and loop combinations are not included in the table above.

3. Use case design

For each of these 7 scenarios, you need to determine the test case. 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 example, 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.

Table 3-9 test Case tables

TC (test case) ID number	Scene/Condition	PIN	Account	Enter (or select) the amount	Carrying Amount	The amount in the ATM	Expected results
CW1	Scenario 1: Successful withdrawals	V	V	V	V	V	Successful withdrawals
CW2	No cash in scene 2:ATM	V	V	V	V	I	Withdrawal option not available, end of use case
CW3	Insufficient cash in scene 3:ATM	V	V	V	V	I	Warning message, return to basic stream step 6, enter amount
CW4	Scene 4:pin wrong (there are more than one chance to enter)	I	V	N/A	V	V	Warning message, return to basic stream step 4, enter PIN
CW5	Scene 4:pin error (one more chance to enter)	I	V	N/A	V	V	Warning message, return to basic stream step 4, enter PIN
CW6	Scene 4:pin error (no more input opportunities)	I	V	N/A	V	V	Warning message, card retention, use case end

4. Data design

Once all the test cases have been identified, the use cases should be reviewed and validated to ensure that they are accurate and moderate, and that redundant or equivalent test cases are canceled.

Once the test case is approved, the actual data values can be determined (in the test Case implementation matrix) and the test data is set, as shown in table 3-10.

Table 3-10 test Case tables

TC (test case) ID number	Scene/Condition	PIN	Account	Enter (or select) the amount (Yuan)	Book Amount (yuan)	Amount in ATM (yuan)	Expected results
CW1	Scenario 1: Successful withdrawals	4987	809-498	50.00	500.00	2 000	Successful withdrawals. Account balance is updated to 450.00
CW2	No cash in scene 2:ATM	4987	809-498	100.00	500.00	0.00	Withdrawal option not available, end of use case
CW3	Insufficient cash in scene 3:ATM	4987	809-498	100.00	500.00	70.00	Warning message, return to basic stream step 6, enter amount
CW4	Scene 4:pin wrong (there are more than one chance to enter)	4978	809-498	N/A	500.00	2 000	Warning message, return to basic stream step 4, enter pin
CW5	Scene 4:pin error (one more chance to enter)	4978	809-498	N/A	500.00	2 000	Warning message, return to basic stream step 4, enter pin
CW6	Scene 4:pin error (no more input opportunities)	4978	809-498	N/A	500.00	2 000	Warning message, card retention, use case end

Related articles:

I. Test case Design Whitepaper--basic concepts of test cases

Second, test case design white paper--equivalence class partitioning method

Iii. test Case Design Whitepaper--Boundary value analysis method

Iv. test Case Design White paper--error-guessing method

V. Test Case Design White paper--Causality diagram method

Six, test case design white paper--decision table driven analysis method

Vii. test Case Design White paper--Orthogonal experiment Design method

Eight, test case design white paper--Function Diagram Analysis method

Nine, the test case design white paper--Scene design Party hair

X. Test Case Design Whitepaper--Comprehensive strategy for test case design