Testcover.com Testcover.com
Tutorial - Shopping Cart Example -
Sequence Unit Replay Design

Home
Existing User Login
Brochure
Sign up for Risk-Free Trial
About Testcover.com
Frequently Asked Questions
Tutorial with Examples
->Equivalence Partitioning
--->HTML Form Example
--->Functional Dependence
----->Temperature Example
----->Calendar Example
----->Fixed Values Procedure
--->Shopping Cart Example
----->Seq. Unit Replay Design
->UML State Machines
--->Shopping Cart Example
--->Thermostat Example
->Definitions of Terms
Performance
WSDL Interface
Background
Partners
Registrations
Contact Information

The shopping cart sequence unit replay design tests shopping cart scenarios for up to three different items. One or more items are placed in the cart. They may be checked for deletion and may have new quantities entered. Then the cart may be updated, and it may be sent on to checkout.

The design uses sequence units to exercise the system operation of interest. A sequence unit is a set of test inputs run consecutively during test execution (e.g. a test automation component). The test factors are sequence unit replay slots, in order of test execution. There are 11 test factors with values and state transitions as follows.

Test FactorNumber of Values Test Factor ValuesMain State Transition(s)
1.Position03 suShopA suShopB suShopCshopping-nonemptyCart
2.Position13 n/a suShopB suShopCnonemptyCart-shopping-nonemptyCart
3.Position22 n/a suShopCnonemptyCart-shopping-nonemptyCart
4.Delete02 n/a suDelete(0)nonemptyCart-nonemptyCart
5.Delete12 n/a suDelete(1)nonemptyCart-nonemptyCart
6.Delete21 n/anonemptyCart-nonemptyCart
7.NewQ05 n/a suNewQ(0,0) suNewQ(0,1) suNewQ(0,2) suNewQ(0,10)nonemptyCart-nonemptyCart
8.NewQ15 n/a suNewQ(1,0) suNewQ(1,1) suNewQ(1,2) suNewQ(1,10)nonemptyCart-nonemptyCart
9.NewQ24 n/a suNewQ(2,1) suNewQ(2,2) suNewQ(2,10)nonemptyCart-nonemptyCart
10.Update2 n/a suUpdatenonemptyCart-nonemptyCart
11.Checkout2 n/a suCheckoutnonemptyCart-checkout

The first three test factors (Position0, Position1 and Position2) choose different items to place in the cart. The value n/a indicates that a sequence unit is not run in that slot, e.g. for cases with only one or two items in the cart. The next three test factors (Delete0, Delete1 and Delete2) indicate whether the items in those positions are to be checked for deletion. The next three test factors (NewQ0, NewQ1 and NewQ2) show whether the items are to have new quantities entered, and if so, how many. The last two test factors (Update and Checkout) indicate whether those buttons are to be clicked.

All the replay slots except the first start in the nonemptyCart state. All the replay slots except the last end in the nonemptyCart state. Thus, when a sequence unit is skipped in any slot after the first one, the test case still may conform to the state diagram.

The test design has one partition with three blocks, for one, two and three different items in the cart. The items are placed in the cart starting at Position0. They are constrained to be different, to appear in separate cart positions. Otherwise, the item already in the cart would have its quantity incremented; a new cart position would not be filled. For example, when there are two different items, the test design constrains Position0 to have itemA or itemB. Position1 is constrained to have itemC.

Another constraint keeps the cart from becoming empty, so that the checkout button always can be used in this partition. The item in the last position is not checked for deletion, and its quantity is not entered as zero. This constraint explains why the value for the Delete2 factor always is n/a. When there are three items in the cart, the third one is never deleted. When there are fewer than three items, there is no third item to delete. Of course empty cart cases could be included in another partition, where going to checkout is not an expected result. (Enumerations of the ways to keep the cart nonempty, and the ways to empty it, are given with the UML state machine designs.)

The test case generator request is given below.
Shopping Cart Example - sequence unit replay design
Position0
Position1
Position2
Delete0
Delete1
Delete2
NewQ0
NewQ1
NewQ2
Update
Checkout
#
+ n=1, no suDelete(0), no suNewQ(0,0)
suShopA suShopB suShopC
n/a
n/a
n/a
n/a
n/a
n/a suNewQ(0,1) suNewQ(0,2) suNewQ(0,10)
n/a
n/a
n/a suUpdate
n/a suCheckout
+ n=2, no suDelete(1), no suNewQ(1,0)
suShopA suShopB
suShopC
n/a
n/a suDelete(0)
n/a
n/a
n/a suNewQ(0,0) suNewQ(0,1) suNewQ(0,2) suNewQ(0,10)
n/a suNewQ(1,1) suNewQ(1,2) suNewQ(1,10)
n/a
n/a suUpdate
n/a suCheckout
+ n=3, no suDelete(2), no suNewQ(2,0)
suShopA
suShopB
suShopC
n/a suDelete(0)
n/a suDelete(1)
n/a
n/a suNewQ(0,0) suNewQ(0,1) suNewQ(0,2) suNewQ(0,10)
n/a suNewQ(1,0) suNewQ(1,1) suNewQ(1,2) suNewQ(1,10)
n/a suNewQ(2,1) suNewQ(2,2) suNewQ(2,10)
n/a suUpdate
n/a suCheckout

The shopping cart example has 35 test cases in one partition in the sequence unit replay design. All test cases start with an empty cart. The results table follows.

#1.
Test
Case ID
Position0 Position1 Position2 Delete0 Delete1 Delete2 NewQ0 NewQ1 NewQ2 Update Checkout Combo
Countdown
3 Values3 Values2 Values2 Values2 Values1 Value5 Values5 Values4 Values2 Values2 Values428
1suShopBn/an/an/an/an/asuNewQ(0,10)n/an/asuUpdatesuCheckout373
2suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,1)suNewQ(1,10)suNewQ(2,1)n/an/a318
3suShopAsuShopCn/asuDelete(0)n/an/asuNewQ(0,0)suNewQ(1,1)n/an/asuCheckout279
4suShopAsuShopBsuShopCn/asuDelete(1)n/an/asuNewQ(1,2)suNewQ(2,10)suUpdaten/a242
5suShopAsuShopBsuShopCsuDelete(0)n/an/asuNewQ(0,0)suNewQ(1,0)suNewQ(2,2)suUpdaten/a215
6suShopBsuShopCn/an/an/an/asuNewQ(0,2)suNewQ(1,2)n/an/an/a191
7suShopCn/an/an/an/an/asuNewQ(0,1)n/an/asuUpdaten/a172
8suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,10)n/asuNewQ(2,10)suUpdatesuCheckout155
9suShopAsuShopCn/asuDelete(0)n/an/an/asuNewQ(1,10)n/asuUpdatesuCheckout141
10suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,2)suNewQ(1,2)suNewQ(2,1)suUpdatesuCheckout128
11suShopAsuShopBsuShopCn/an/an/asuNewQ(0,10)suNewQ(1,1)suNewQ(2,1)n/an/a117
12suShopAsuShopBsuShopCn/an/an/asuNewQ(0,1)suNewQ(1,0)suNewQ(2,10)n/asuCheckout108
13suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/an/asuNewQ(1,1)suNewQ(2,2)suUpdatesuCheckout101
14suShopAn/an/an/an/an/an/an/an/an/an/a95
15suShopAsuShopBsuShopCn/an/an/asuNewQ(0,2)suNewQ(1,10)suNewQ(2,2)n/asuCheckout89
16suShopBsuShopCn/asuDelete(0)n/an/asuNewQ(0,1)suNewQ(1,1)n/asuUpdaten/a84
17suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,0)suNewQ(1,10)n/asuUpdatesuCheckout79
18suShopCn/an/an/an/an/asuNewQ(0,2)n/an/asuUpdatesuCheckout75
19suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/an/asuNewQ(1,0)suNewQ(2,1)suUpdatesuCheckout71
20suShopBsuShopCn/asuDelete(0)n/an/asuNewQ(0,0)n/an/an/asuCheckout68
21suShopAsuShopBsuShopCn/asuDelete(1)n/asuNewQ(0,0)suNewQ(1,1)suNewQ(2,10)suUpdaten/a65
22suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,10)suNewQ(1,2)suNewQ(2,2)suUpdaten/a62
23suShopCn/an/an/an/an/asuNewQ(0,10)n/an/an/asuCheckout60
24suShopAsuShopCn/asuDelete(0)n/an/asuNewQ(0,10)suNewQ(1,10)n/an/an/a58
25suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,0)n/asuNewQ(2,1)suUpdatesuCheckout56
26suShopAsuShopBsuShopCsuDelete(0)n/an/asuNewQ(0,1)n/asuNewQ(2,2)suUpdatesuCheckout54
27suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/asuNewQ(0,2)suNewQ(1,0)suNewQ(2,10)suUpdaten/a52
28suShopAsuShopBsuShopCn/an/an/asuNewQ(0,10)suNewQ(1,0)n/an/asuCheckout50
29suShopCn/an/an/an/an/an/an/an/asuUpdaten/a49
30suShopBn/an/an/an/an/an/an/an/asuUpdatesuCheckout48
31suShopBsuShopCn/an/an/an/asuNewQ(0,0)suNewQ(1,10)n/asuUpdaten/a47
32suShopAsuShopCn/asuDelete(0)n/an/asuNewQ(0,1)suNewQ(1,2)n/asuUpdatesuCheckout46
33suShopBsuShopCn/asuDelete(0)n/an/asuNewQ(0,2)suNewQ(1,1)n/asuUpdaten/a45
34suShopAsuShopCn/asuDelete(0)n/an/asuNewQ(0,0)suNewQ(1,2)n/asuUpdatesuCheckout44
35suShopAsuShopBsuShopCsuDelete(0)suDelete(1)n/an/asuNewQ(1,10)suNewQ(2,10)n/asuCheckout43

In the first test case itemB is placed in the cart (Position0), and its new quantity is entered as 10. The cart is updated and then sent to checkout.

The sequence unit replay design is based on one state transition path which would be covered if sequence units in all the slots were executed. Some of the sequence units are skipped in some test cases (when they have n/a values). So the paths of the different test cases are not always the same. What the design requires, however, is for the action of each transition triggered in the sequence to be an expected result of one equivalence class. When this criterion is met, pairwise coverage is possible.

<Shopping Cart Example UML State Machines>

Copyright © 2003-2017 Testcover.com, LLC. All rights reserved.