标签:
-Test note of “Essential Software Test Design”
2015-08-31
12.1 What are Use Cases?
12.2 Use cases
12.2.1 Example: Use Case – Withdraw Money
12.3 The Model – Compiling the Flow Graph
12.4 Creating Base Test Cases
12.4.1 List All Scenarios
TO DESCRIBE THE requirements on a system, a technique is often used which is called use cases.
Use cases are a step-by-step description of a flow, where an actor interact with a system. An actor may be one of a number of different user types, the system itself, or other external systems.
The commonest flow – normal use – is called the main flow (also called the normal flow or Happy Path) and variations of this are termed alternative flows.
The overarching work procedure is this:
Let us go back to the example of an ATM machine. A simple use case may look like this:
Assumptions:
Actors
H-1. The use case begins when the customer inserts the card.
H-2. The ATM verifies the card and requests the PIN number.
H-3. The customer types in the correct PIN (4 digits).
H-4. The ATM verifies the PIN and asks the customer to type in an amount.
H-5. The customer types in the amount (100-2000 SEK manually or by using the multiple choice keys).
H-6. The ATM verifies that the amount is available in the customer’s account and ejects the card, the money and the receipt, and registers the transaction in the customer’s account.
H-7. The customer takes the card, the money and the receipt.
H-8. The ATM returns to standby mode.
H-9. End of use case.
Results
The customer has carried out a successful withdrawal of money.
The customer’s account is updated with the transaction.
Alternative flow – A1 Invalid card
A1-1. At step H-1, the customer inserts an invalid card.
A1-2. The ATM aborts the transaction and the card is ejected.
Alternative flow – A2 Wrong PIN
A2-1. At step H-3, the customer types in the wrong PIN.
A2-2. The ATM registers an incorrect PIN and asks the user to try again.
A2-3. The use case continues with step H-3.
Alternative flow – A3 Wrong PIN, 3 times
A3-1. At step H-3, the customer types in the wrong PIN three times in a row.
A3-2. The ATM swallows the card and the transaction is aborted.
A3-3. End of use case.
Alternative flow – A4 Incorrect input of amount
A4-1. At step H-5, the customer makes an incorrect entry (not divisible by a hundred, funds are not in the account, exceeds permitted maximum withdrawal…)
A4-2. The ATM disallows the entered amount and asks the user to try again.
A4-3. The use case continues with step H-5.
Alternative flow – A5 Customer does not take the money
A5-1. At step H-7, the customer takes the card, but not the money or the receipt within 20 seconds.
A5-2. The ATM leaves the receipt hanging out of the machine and retracts the money, places it in a separate container and writes the amount, account number and cause of defect into a defect log.
A5-3. The use case continues with step H-8.
Alternative flow – A6 The customer’s bank is not on-line (other than Handelsbanken)
A6-1. At step H-6, the ATM cannot verify whether the amount is available in the customer’s account. A message shows that contact with the customer’s bank is being established and the card is ejected.
A6-2. The use case continues with step H-8.
Alternative flow – A7 Customer aborts the withdrawal
A7-1. At all times in the Main flow, apart from steps H-6 and H-7, the customer can choose to abort the transaction
A7-2. The ATM aborts the transaction and ejects the card, and no withdrawal is recorded on the customer’s account.
A7-3. The use case continues with step H-8.
If there is not one already, you compile a flow diagram based on the use case.
Figure 12.1: Activity diagram of the flow in the use case «Withdraw Money». We have a starting point but several different end points, with different results.
To cover the graph, we generate base test cases for the different flows at hand
标签:
原文地址:http://www.cnblogs.com/Ming8006/p/4773163.html