FROM USE CASES TO TEST CASES

FROM USE CASES TO TEST CASES

-Test note of “Essential Software Test Design”

2015-08-31

Content:

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.

12.1 What are Use Cases?


 Top

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:

  1. Compile an activity diagram. If this is already in place, the first step is to review it.
  2. List all scenarios
  3. Analyze and prioritize the scenarios according to risk – which are most important, commonest
  4. Identify the operational variables which can affect the expected result
  5. Write one or more test cases for each scenario

12.2 Use cases


 Top

Let us go back to the example of an ATM machine. A simple use case may look like this:

12.2.1 Example: Use Case – Withdraw Money

Assumptions:

  • The customer’s bank is one which is connected to the ATM system.
  • The customer has a correct and functioning magnetic strip card.
  • The ATM is switched on and is in ready mode.
  • The ATM is situated in Sweden so all withdrawals will be in swedish crowns,
  • SEK, and bills that can be withdrawn are 100 or 500 only.

Actors

  • Customer
  • ATM (network)
Main Flow:

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 Flows

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.

12.3 The Model – Compiling the Flow Graph


 Top

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.

12.4 Creating Base Test Cases


 Top

12.4.1 List All Scenarios

To cover the graph, we generate base test cases for the different flows at hand

  1. Start with the Main flow, which you use for the Happy Day test.
  2. Continue with the alternative flows – one at a time.
  3. There are different combinations of alternative flows. It is not always possible to draw up all the combinations: there may be infinite loops.
posted @ 2015-08-31 15:28  明-Ming  阅读(624)  评论(0编辑  收藏  举报