Testcover.com - Tutorial - Start Command Example with 2 States

	Testcover.com
		Tutorial - Start Command Example - Hierarchical State Machine with 2 States

Home
Existing User Login
Brochure
Sign up for Risk-Free Trial
About Testcover.com
Frequently Asked Questions
Tutorial with Examples
->Finite State Machine
--->Start Command: 3 States
--->Start Command: 2 States
Performance
WSDL Interface
Background
Partners
Registrations
Contact Information

Continuing with the Start Command Example, the test designer considers the differences between the test application and the production application. Test and production data differ, but generally the database schemas are the same or very similar. Test and production network parameters differ, but the network services use identical facilities and configurations. The test designer reasons that the test and production states can be considered equivalent for the purposes of the start command testing. If there are 2 states instead of 3, there will be 2 • 2 = 4 transitions, i.e. 4 partitions rather than 9. Fewer test cases may be expected.

Whether this simplification is justified may depend on a good understanding of the system under test, the scope of the whole test program, risks and consequences of incomplete testing, and other considerations. The point of this example is not to say whether the 3-state model or the 2-state model is the correct one. Rather it is to demonstrate both techniques for appropriate use.

The 2-state model is similar to the 3-state model in that it has the same 6 test factors and values (below). In fact the 2-state model uses the same request blocks as the 3-state model. Therefore the same pairs of factor values will be covered in both models. The 2-state model is different from the 3-state model because the 9 blocks are grouped into 4 partitions rather than 9. The 2-state model treats test and production as equivalent for transitions involving its idle and active states. At the same time, the 2-state model retains the factor values and constraints defined by the blocks of the 3-state model.

Test Factor	Number of Values	Test Factor Values
1. Other state	3	idle test production
2. This state	3	idle test production
3. Dump this db?	2	no yes
4. Start production?	2	no yes
5. Start test?	2	no yes
6. Restore db?	4	no from_other_prod from_this_prod from_other_test

For test factors 3, 4, 5 and 6, the value no stands for no or not prompted.

The request is composed of four partitions (P1, P2, P3, P4) corresponding to the four state transitions between the idle and active states.

The request for this test model is shown below. Partition prefixes (e.g. 2-II, 2-IA, etc.) are used to distinguish the test cases of different partitions. The relationship between this 2-state model request and the 3-state request is summarized here.
Start Command with 2 states Other state This state Dump this db? Start production? Start test? Restore db? #2-II idle to idle +idle to idle idle test production idle no no no no #2-IA idle to active (test or production) +idle to test idle test production idle no no yes no from_other_prod from_this_prod from_other_test +idle to production idle test idle no yes no no from_other_prod from_this_prod #2-AI active (test or production) to idle +test to idle idle test production test no yes no no no +production to idle idle test production no yes no no no #2-AA active (test or production) to active (test or production) +test to test idle test production test no yes no yes no from_other_prod from_this_prod from_other_test +test to production idle test test no yes yes no no from_other_prod from_this_prod +production to test idle test production no yes no yes no from_other_prod from_this_prod from_other_test +production to production idle test production no yes yes no no from_other_prod from_this_prod

The four results tables follow.

#1. idle to idle

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db? Combo
Countdown

3 Values 1 Value 1 Value 1 Value 1 Value 1 Value 25

2-II1 idle idle no no no no 10

2-II2 test idle no no no no 5

2-II3 production idle no no no no 0

#2. idle to active (test or production)

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db? Combo
Countdown

3 Values 1 Value 1 Value 2 Values 2 Values 4 Values 67

2-IA1 test idle no no yes from_other_test 52

2-IA2 idle idle no yes no no 38

2-IA3 production idle no no yes from_other_prod 29

2-IA4 idle idle no no yes from_this_prod 22

2-IA5 test idle no yes no from_other_prod 17

2-IA6 production idle no no yes no 14

2-IA7 test idle no yes no from_this_prod 11

2-IA8 idle idle no no yes from_other_prod 10

2-IA9 production idle no no yes from_this_prod 9

2-IA10 idle idle no no yes from_other_test 8

2-IA11 test idle no no yes no 7

2-IA12 production idle no no yes from_other_test 6

#3. active (test or production) to idle

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db? Combo
Countdown

3 Values 2 Values 2 Values 1 Value 1 Value 1 Value 40

2-AI1 idle test no no no no 25

2-AI2 test production yes no no no 13

2-AI3 production test yes no no no 7

2-AI4 test test no no no no 5

2-AI5 idle production no no no no 3

2-AI6 idle test yes no no no 2

2-AI7 production test no no no no 1

#4. active (test or production) to active (test or production)

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db? Combo
Countdown

3 Values 2 Values 2 Values 2 Values 2 Values 4 Values 92

2-AA1 test test yes no yes from_other_test 77

2-AA2 idle test no yes no no 62

2-AA3 test production no no yes from_other_prod 50

2-AA4 idle production yes yes no from_this_prod 38

2-AA5 production test yes no yes no 30

2-AA6 test test no no yes from_this_prod 25

2-AA7 test test no yes no from_other_prod 20

2-AA8 idle production no no yes from_other_test 15

2-AA9 production test yes no yes from_other_prod 13

2-AA10 production test no no yes from_other_test 11

2-AA11 test production yes no yes no 9

2-AA12 idle test no no yes from_other_prod 8

2-AA13 production test yes no yes from_this_prod 7

In each of the four partitions, all allowed pairs of factor values are covered. The total number of test cases for this model is 35 (compared with 63 for the 3-state model).

As with the 3-state model, these 2-state model test cases can be ordered to create a path through the test model states. In a successful test run, each transition would set up the initial conditions for the following test case. Here, the test cases are sorted by the 3 other state values to create 3 corresponding test runs. In each run the transitions for this host are ordered so that the resulting state of each test case sets up the initial state of the next. Note that the 2-state model test cases are dependent on the test and production substates.

Run 1. Other state idle

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db?

2-II1 idle idle no no no no

2-IA2 idle idle no yes no no

2-AI5 idle production no no no no

2-IA4 idle idle no no yes from_this_prod

2-AI1 idle test no no no no

2-IA8 idle idle no no yes from_other_prod

2-AI6 idle test yes no no no

2-IA10 idle idle no no yes from_other_test

2-AA2 idle test no yes no no

2-AA4 idle production yes yes no from_this_prod

2-AA8 idle production no no yes from_other_test

2-AA12 idle test no no yes from_other_prod

Run 2. Other state test

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db?

2-II2 test idle no no no no

2-IA1 test idle no no yes from_other_test

2-AI4 test test no no no no

2-IA5 test idle no yes no from_other_prod

2-AI2 test production yes no no no

2-IA7 test idle no yes no from_this_prod

2-AA3 test production no no yes from_other_prod

2-AA1 test test yes no yes from_other_test

2-AA6 test test no no yes from_this_prod

2-AA7 test test no yes no from_other_prod

2-AA11 test production yes no yes no

2-AI4 test test no no no no

2-IA11 test idle no no yes no

In this run test case 2-AI4 was repeated once to set up its following test case.

Run 3. Other state production

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db?

2-II3 production idle no no no no

2-IA3 production idle no no yes from_other_prod

2-AI3 production test yes no no no

2-IA6 production idle no no yes no

2-AI7 production test no no no no

2-IA9 production idle no no yes from_this_prod

2-AA5 production test yes no yes no

2-AA9 production test yes no yes from_other_prod

2-AA10 production test no no yes from_other_test

2-AA13 production test yes no yes from_this_prod

2-AI7 production test no no no no

2-IA12 production idle no no yes from_other_test

In this run test case 2-AI7 was repeated once to set up its following test case.

Summary. The Start Command Example illustrates pairwise testing using finite state machines. In the 3-state model each state is considered a different initial condition and/or expected result. Separate partitions are used to model transitions between states to insure that all allowed pairs of factor values are tested. This may lead to pairs being tested multiple times in different transitions.

In the 2-state model two states are considered equivalent, and each transition to/from either of them is modeled with one partition. Each allowed pair of values is covered in each partition, but there is no attempt to associate each pair with both of the equivalent states. Both test models can accommodate factor values with constraints and which depend on the current state or substate.

The final comparison between the test models examines test cases generated from two request blocks used in both models. In the 3-state model the blocks are in separate partitions representing transitions from idle to test and from idle to production. In the 2-state model the blocks are in the same partition representing one transition from idle to active (test or production). Consider the test cases with a database restoration from the other production dump. There are 5 such test cases in the 3-state model and 3 test cases in the 2-state model.

The tables below show for each test model the test cases from idle to test or production with database restoration from the other production dump.

3-state model: P2B1 and P3B1

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db?

3-IT3 idle idle no no yes from_other_prod

3-IP4 idle idle no yes no from_other_prod

3-IT9 test idle no no yes from_other_prod

3-IP2 test idle no yes no from_other_prod

3-IT6 production idle no no yes from_other_prod

2-state model: P2B1 and P2B2

Test
Case ID Other state This state Dump this db? Start production? Start test? Restore db?

2-IA8 idle idle no no yes from_other_prod

2-IA5 test idle no yes no from_other_prod

2-IA3 production idle no no yes from_other_prod

3-IT3 and 3-IP4 are the 3-state model test cases for when the other state is idle. They differ only by whether the test or production application is started. 2-IA8 is the only corresponding 2-state model test case. It is identical to 3-IT3.

3-IT9 and 3-IP2 are the 3-state model test cases for when the other state is test. They differ only by whether the test or production application is started. 2-IA5 is the only corresponding 2-state model test case. It is identical to 3-IP2.

3-IT6 is the 3-state model test case for when the other state is production. 2-IA3 is the corresponding 2-state model test case, and it is identical. There are no test cases here for starting the production application on this host because requirements prohibit that when the other state is production.