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

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 example applies pairwise testing to system operation. Systems generally operate in different states, which may respond differently to inputs. Controlling the set-up and operation of the test system is essential for repeatable results and for knowing what has and has not been tested. The shopping cart example illustrates testing system operation, first with the sequence unit replay model and later with models based on a UML state machine.

The shopping cart provides an on-line shopper with a repository for items to purchase, and an interface for updating the items and viewing their cost. When a shopper selects an item and places it in the cart, she is taken to the shopping cart page. Here items can be checked for deletion, and new quantities can be entered. The update button initiates these changes to the items in the cart. The shop button returns to the previous shopping page, and the checkout button presents the interface for shipping and payment. Whan a shopper selects an item that is already in the cart, the quantity of that item is incremented. The update and checkout buttons do not appear when the cart is empty. A cart button returns to the shopping cart from checkout.

The sequence unit replay model applies pairwise testing to a sequence of state transitions. Comparisons with expected results are made at selected points during the sequence, and test factors are chosen to replay different runs over the area of interest. Each partition corresponds to a state transition path on which equivalent results are expected at each transition. When available a state diagram can clarify the transition paths. The paths are chosen to meet test goals, and may or may not include all transitions.

Each partition tests a set of transitions with one behavior. That is, each transition in the sequence is associated with one equivalence class, so that the action of the transition is an expected result in that class. This is a necessary condition to cover all pairs of inputs. Otherwise some input combinations may not be applied to the intended state, as in the HTML form example. Designing the partition's test cases to follow the same path can facilitate the association of each transition to its equivalence class, and thus cover the allowed pairs of test factor values. Each partition's test cases follow the path through the diagrammed states, while exercising different program variables comprising the extended state.

A sequence unit is a set of test inputs run consecutively during test execution (e.g. a test automation component). Sequence units may have parameters specifying which inputs are applied and what their values are. Test factors are the sequence unit replay slots, in order of test execution. Test values are the chosen sequence units and their parameters as needed. Sequence units for the shopping cart test design are as follows.

Sequence UnitReplay Action
suShopA Go to shopping page for itemA and add it to the shopping cart. Go to the cart.
suShopB Go to shopping page for itemB and add it to the shopping cart. Go to the cart.
suShopC Go to shopping page for itemC and add it to the shopping cart. Go to the cart.
suCart Go to the cart.
suDelete(i) Check (or uncheck) the cart delete box for the item in position i.
suNewQ(i,q) Type q in the cart quantity box for the item in position i.
suUpdate Click the cart update button.
suCheckout Click the cart checkout button.

During execution earlier sequence units test the system, and they set up the system for later test interactions as well. The test inputs and result checks may use more than one interface, but the timing of the interactions must be coordinated to be repeatable.

The sequence unit replay model provides test design flexibility in the choice of transition paths. So the model can be effective in focusing on new or changed functions. This flexibility also comes with a risk of omission of some transitions. The test models based on UML state machines avoid this risk by treating all the transitions systematically.

The sequence unit replay design for the shopping cart is shown on the next page.

<Fixed Values Procedure Sequence Unit Replay>

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