[Original] "Scenario Method" for Test Case Design

[Original] Test Case Design: "Scenario Method"

The scenario design test case is mainly used in the event trigger process. When an event is triggered, a corresponding scenario flow is formed, with different event triggers, different sequences, and different processing results, to form a series

Event stream result. This method is very helpful when designing test cases!

Therefore, it is very important to design the test case in the RUP scenario! In actual application, the following requirements should be met:

Test cases should be compiled for each use case scenario.

The use case scenario should be determined by describing the path of the use case. This process traverses all the basic and alternative flows from the start to the end of the use case.

Each different path in the use case reflects the basic stream and alternative stream, which are expressed by arrows. The basic stream is represented by a straight black line, which is the simplest path of the use case. Each alternative stream starts from the basic stream. Then, the alternative stream is executed under a specific condition. The alternative stream may be added to the basic stream again (alternative stream 1 and 3), and may also originate from another alternative stream (alternative stream 2 ), or terminate the use case instead of joining a stream again (optional stream 2 and 4 ).

Use Case event stream example

Follow the possible path of each use case to determine different use case scenarios. Starting from the basic stream and then combining the basic stream with the alternative stream, you can determine the following use cases:

Scenario 1	Basic stream
Scenario 2	Basic stream	Alternate stream 1
Scenario 3	Basic stream	Alternate stream 1	Alternate stream 2
Scenario 4	Basic stream	Alternate Stream 3
Scenario 5	Basic stream	Alternate Stream 3	Alternate stream 1
Scenario 6	Basic stream	Alternate Stream 3	Alternate stream 1	Alternate stream 2
Scenario 7	Basic stream	Alternate stream 4
Scenario 8	Basic stream	Alternate Stream 3	Alternate stream 4

NOTE: For the sake of convenience, scenario 5, 6, and 8 only describe the loop execution once indicated by alternative stream 3.

The test case generated for each scenario is completed by determining a specific condition, which will lead to the execution of a specific case scenario.

For example, assume that the scenario described has the following requirements for alternative stream 3:

"This event flow occurs if the amount of USD entered in step 2 'input withdrawal amount' exceeds the current account balance. The system will display a warning message, and then re-join the basic stream, and then perform the above step 2 'enter withdrawal amount 'again, then the bank customer can enter a new withdrawal amount ."

Accordingly, you can start to determine the test case to be used to execute alternative stream 3:

Test Case ID	Scenario	Condition	Expected results
TC x	Scenario 4	Step 2-Withdrawal amount> account balance	Add the basic stream again in step 2.
Tc Y	Scenario 4	Step 2-Withdrawal amount <account balance	Do not execute alternative stream 3, execute basic stream
TC Z	Scenario 4	Step 2-Withdrawal amount = Account Balance	Do not execute alternative stream 3, execute basic stream

Note: The test cases shown above are very simple because no additional information is provided. Test cases are rarely so simple.

The following is a more practical example of a test case generated by the test case.

Example:

The main character and use case of an ATM machine.

The following table shows the basic flows and some alternate flows for the withdrawal use case:

	The beginning of this case is that the ATM is in the ready state. Prepare for withdrawal-the customer inserts the bank card into the ATM host. Verify that the bank card-ATM machine reads the account code from the bank card's magnetic stripe and checks whether it is a bank card that can be received. Enter the pin-ATM and ask the customer to enter the PIN code (4 digits) Verify account code and pin-verify account code and pin to determine whether the account is valid and whether the entered pin is correct for the account. For this event stream, the account is valid and the pin is correct for this account. ATM options-various options available on the local machine for ATM display. In this event stream, bank customers usually select "withdrawal ". Enter the amount-the amount to be extracted from the ATM. For this event stream, the customer needs to select the default amount ($10, $20, $50 or $100 ). Authorization-ATM initiates the verification process by sending the card ID, pin, amount, and account information to the banking system as a transaction. For this event stream, the banking system is online and replies to the authorization request, approves the withdrawal process, and updates the account balance accordingly. Cash is provided. Return bank card-bank card is returned. Receipt-print the receipt and provide it to the customer. The ATM also updates internal records accordingly. At the end of the use case, the ATM is back to the ready state.
Alternate stream 1-invalid bank card	In basic flow step 2-verify the bank card. If the card is invalid, the card is returned and a message is sent.
Alternative stream 2-no cash in the ATM	In basic flow step 5-the ATM option is unavailable if there is no cash in the ATM.
Alternative Stream 3-insufficient cash in the ATM	In basic flow step 6, enter the amount. If the amount in the ATM is less than the requested amount, an appropriate message is displayed, in step 6, add the basic stream to the input amount.
4-pin error of alternate stream	In basic flow step 4-verify the account and pin, the customer has three chances to enter the pin. If the PIN is entered incorrectly, the ATM will display the appropriate message. If there is still an input opportunity, the event stream rejoins the basic stream at Step 3-enter the pin. If the PIN code entered in the last attempt is still incorrect, the card will be retained by the ATM and the ATM will return to the ready state. This case is terminated.
Alternate Stream 5-account does not exist	In basic flow step 4-verify the account and pin. If the code returned by the banking system indicates that the account cannot be found or withdrawal from the account is prohibited, then, the ATM displays the appropriate message and adds the basic stream to the bank card in Step 9.
Alternate stream 6-insufficient account amount	In basic flow step 7-authorization, the banking system returns code indicating that the account balance is less than the amount entered in the basic flow step 6-input amount, the ATM displays the appropriate message and adds the basic stream to step 6-Enter the amount.
Alternate Stream 7-Maximum Daily withdrawal amount	In basic flow step 7-authorization, the Code returned by the banking system indicates that, including this withdrawal request, the client has or will exceed the maximum amount allowed to be extracted within 24 hours, then, the ATM displays the appropriate message and adds the basic stream to step 6-input amount.
Alternate stream X-record Error	If the record cannot be updated in basic flow step 10-receipt, the ATM enters "safe mode" and all functions are suspended in this mode. At the same time, an appropriate warning message is sent to the banking system indicating that the ATM has been suspended.
Alternate stream y-exit	The customer can terminate the transaction (exit) at any time ). The transaction ends, and the bank card exits.
Alternative stream Z-"Climbing"	ATM contains a large number of sensors to monitor various functions, such as power detectors, pressure gauges at different doors and entrances and exits, and Action detectors. If a sensor is activated at any time, the alarm signal is sent to the police and the ATM enters "safe mode". In this mode, all functions are suspended, wait until appropriate restart/re-initialization measures are taken.
In the first iteration, based on the iteration plan, we need to verify that the withdrawal case has been correctly implemented. At this time, the entire use case has not been implemented. Only the following event stream is implemented: Basic stream-extract preset amount (USD 10, USD 20, USD 50, USD 100) Alternative stream 2-no cash in the ATM Alternative Stream 3-insufficient cash in the ATM 4-pin error of alternate stream Alternate Stream 5-account does not exist/account type error Alternate stream 6-insufficient account amount

The following scenarios can be generated from this use case:

Scenario 1: Successful withdrawals	Basic stream
Scenario 2: no cash in the ATM	Basic stream	Alternate stream 2
Scenario 3: insufficient ATM cash	Basic stream	Alternate Stream 3
Scenario 4-Incorrect pin (there is still a chance to enter)	Basic stream	Alternate stream 4
Scenario 5-Incorrect pin (no input opportunities)	Basic stream	Alternate stream 4
Scenario 6: account does not exist/account type error	Basic stream	Alternate Stream 5
Scenario 7: insufficient account balance	Basic stream	Alternate stream 6

NOTE: For the sake of convenience, the cycle and loop combination in the alternative stream 3 and 6 (scenario 3 and 7) are not included in the table above.

Test cases must be determined for each of the seven scenarios. You can use a matrix or a decision table to determine and manage test cases. The following shows a common format, where each row represents each test case, and each column represents the information of the test case. In this example, for each test case, there is a test case id, condition (or description), all data elements involved in the test case (as input or already exist in the Database) and expected results.

Build a matrix by determining the data elements required for the execution case scenario. Then, for each scenario, at least determine the test cases that contain the appropriate conditions required for the execution scenario. For example, in the following matrix, V (valid) is used to indicate that this condition must be valid (valid) before the basic stream can be executed, and I (invalid) indicates that the required alternate stream will be activated under this condition. The "N/A" (not applicable) used in the following table indicates that this condition is not applicable to test cases.

TC (test case) ID	Scenario/Condition	Pin	Account	Input amount (Or the selected amount)	Account amount	Amount in the ATM	Expected results
Cw1.	Scenario 1: Successful withdrawals	V	V	V	V	V	Successful withdrawal.
Cw2.	Scenario 2: no cash in the ATM	V	V	V	V	I	Withdrawal option unavailable, use case ended
Cw3.	Scenario 3: insufficient ATM cash	V	V	V	V	I	Warning Message, return basic flow step 6-input amount
Cw4.	Scenario 4-pin error (more than one input opportunity)	I	V	N/	V	V	Warning Message, return to basic flow step 4, enter the pin
Cw5.	Scenario 4-Incorrect pin (another opportunity to input)	I	V	N/	V	V	Warning Message, return to basic flow step 4, enter the pin
Cw6.	Scenario 4-Incorrect pin (no input opportunities)	I	V	N/	V	V	Warning Message, reserved, end of use case

In the preceding matrix, six test cases are executed in four scenarios. For the basic flow, the preceding test case CW1 is called a positive test case. It is always executed along the basic stream path of the use case without any deviation. A full test of the basic flow must include negative test cases to ensure that the basic flow is executed only when the conditions are met. These negative test cases are represented by cw2 to 6 (shadow cells indicate that alternative streams need to be executed under such conditions ). Although cw2 to 6 are negative test cases for basic streams, they are positive test cases relative to alternative streams 2 to 4. In addition, each of these alternative flows has at least one negative test case (CW1-basic flow ).

It is not sufficient to have only one positive test case and one negative test case in each scenario. Scenario 4 is such an example. To fully test scenario 4-pin errors, at least three positive test cases are required (to activate scenario 4 ):

• Incorrect PIN entered, but there is still an opportunity to enter it. This alternate stream rejoins step 3 in the basic stream-enter the pin.
• If an incorrect pin is entered and there is no chance to enter it, the alternate stream retains the bank card and terminates the use case.
• The "correct" pin is entered during the last input. The alternative stream is added to the basic stream in step 5-input amount.

Note: In the preceding matrix, no actual value is required for the condition (data. One advantage of creating a test case matrix in this way is that it is easy to see what testing conditions are. Because you only need to check V and I (or the shadow cells used here), this method also makes it easy to determine whether sufficient test cases have been determined. From the table above, we can find that there are several conditions that do not have shadow cells, which indicates that the test cases are incomplete, for example, scenario 6-nonexistent account/account types are incorrect and scenario 7-test cases are missing if the account balance is insufficient.

Once all test cases are identified, they should be reviewed and verified to ensure they are accurate and moderate, and redundant or equivalent test cases should be removed.

Once the test case is approved, you can determine the actual data value (in the test case implementation matrix) and set the test data

TC (test case) ID	Scenario/Condition	Pin	Account	Input amount (Or the selected amount)	Account amount	Amount in the ATM	Expected results
Cw1.	Scenario 1: Successful withdrawals	4987	809-498	50.00	500.00	2,000	Successful withdrawal. Account Balance updated to 450.00
Cw2.	Scenario 2: no cash in the ATM	4987	809-498	100.00	500.00	0.00	Withdrawal option unavailable, use case ended
Cw3.	Scenario 3: insufficient ATM cash	4987	809-498	100.00	500.00	70.00	Warning Message, return basic flow step 6-input amount
Cw4.	Scenario 4-pin error (more than one input opportunity)	4978	809-498	N/	500.00	2,000	Warning Message, return to basic flow step 4, enter the pin
Cw5.	Scenario 4-Incorrect pin (another opportunity to input)	4978	809-498	N/	500.00	2,000	Warning Message, return to basic flow step 4, enter the pin
Cw6.	Scenario 4-Incorrect pin (no input opportunities)	4978	809-498	N/	500.00	2,000	Warning Message, reserved, end of use case

 

The above test cases are only part of the test cases that need to be used to verify the withdrawal case in this iteration. Of course, in the actual withdrawal process, test cases also need to be improved from the perspective of functions, performance, and security!