Home
Existing User Login
Brochure
Sign up for Risk-Free Trial
About Testcover.com
Frequently Asked Questions
Tutorial with Examples
->Need for the Service
->Submitting Requests
->Reading Results
->Configuration Example
->Constraints Example
->Calendar Example
->Database Table Example
->Finite State Machine
->UML State Machine
->Definitions of Terms
Performance
WSDL Interface
Background
Partners
Registrations
Contact Information
|
The Calendar Example illustrates the use of the test case generator with error conditions.
This situation is different from the previous example which had impossible combinations to avoid.
Here there are combinations which need to be tested, but they reflect abnormal conditions.
These combinations lead to "rainy day" test cases which must be handled differently than "sunny day" cases.
Consider a calendar system which has three test factors with values as follows.
| Test Factor | Number of Values | Test Factor Values |
|---|
| 1. Month | 12 |
jan feb mar apr may jun jul aug sep oct nov dec |
|---|
| 2. Day | 7 |
1 10 28 29 30 31 32 |
|---|
| 3. Year | 3 | 2011 2012 2013 |
|---|
The tester plans to try several allowed dates, including first and last days of each month.
She also will try problem dates beyond the month boundaries (e.g. Month jan with Day 32)
to check that the system handles error cases correctly.
One error test case that could be generated is
This is an error test case because 2013 is not a leap year: February has only 28 days in 2013.
If this is the only test case which pairs the Month feb with Day 29,
there would be a gap in exercising the normal operation of the calendar.
The feb-29 pair would not be tested in an allowed date in a leap year.
The tester knows that the calendar system behaves differently during error handling,
so she plans to cover the feb-29 pair as a normal day in a leap year (2012) and as an error case (in 2013) also.
This is easily accomplished with two partitions, one for normal dates and one for months that are too long.
There are constraints among the factor values in both partitions due to the varying month lengths.
Thus both partitions have multiple blocks.
Any combination of values in a block is an allowed test case.
The request for this example is shown below.
Calendar Example
Month
Day
Year
#ok All good dates
jan feb mar apr may jun jul aug sep oct nov dec
1 10
2011 2012 2013
+ long month last day
jan mar may jul aug oct dec
31
2011 2012 2013
+ short month last day
apr jun sep nov
30
2011 2012 2013
+ feb last day
feb
28
2011 2013
+ leap day
feb
29
2012
#err Too long month
+ too long long month
jan mar may jul aug oct dec
32
2011
+ too long short month
apr jun sep nov
31
2012
+ feb too long, regular year
feb
29
2013
+ feb too long, leap year
feb
30
2012 |
The two results tables follow.
This example illustrates the use of Test Case ID prefixes (ok and err)
to distinguish between test cases from different partitions.
Optional partition comments also are shown.
Note that the feb-29 pair is covered in both partition results.
#1. All good dates
Test
Case ID | Month | Day | Year | Combo
Countdown | |
|---|
| 12 Values | 6 Values | 3 Values | 126 |
| ok1 | jan | 1 | 2011 | 123 |
| ok2 | jan | 10 | 2012 | 120 |
| ok3 | feb | 10 | 2011 | 117 |
| ok4 | feb | 1 | 2013 | 114 |
| ok5 | mar | 1 | 2012 | 111 |
| ok6 | mar | 10 | 2013 | 108 |
| ok7 | may | 31 | 2013 | 105 |
| ok8 | aug | 31 | 2012 | 102 |
| ok9 | oct | 31 | 2011 | 99 |
| ok10 | nov | 30 | 2012 | 96 |
| ok11 | apr | 30 | 2013 | 93 |
| ok12 | jun | 30 | 2011 | 90 |
| ok13 | feb | 29 | 2012 | 87 |
| ok14 | apr | 1 | 2011 | 85 |
| ok15 | apr | 10 | 2012 | 83 |
| ok16 | may | 10 | 2011 | 81 |
| ok17 | jun | 1 | 2012 | 79 |
| ok18 | jun | 10 | 2013 | 77 |
| ok19 | jul | 1 | 2011 | 75 |
| ok20 | jul | 10 | 2012 | 73 |
| ok21 | aug | 10 | 2011 | 71 |
| ok22 | aug | 1 | 2013 | 69 |
| ok23 | sep | 10 | 2011 | 67 |
| ok24 | sep | 1 | 2012 | 65 |
| ok25 | oct | 10 | 2012 | 63 |
| ok26 | nov | 10 | 2011 | 61 |
| ok27 | nov | 1 | 2013 | 59 |
| ok28 | dec | 10 | 2011 | 57 |
| ok29 | dec | 1 | 2012 | 55 |
| ok30 | jul | 31 | 2013 | 53 |
| ok31 | dec | 31 | 2013 | 51 |
| ok32 | jan | 31 | 2013 | 49 |
| ok33 | mar | 31 | 2011 | 47 |
| ok34 | sep | 30 | 2013 | 45 |
| ok35 | feb | 28 | 2011 | 43 |
| ok36 | may | 10 | 2012 | 42 |
| ok37 | may | 1 | 2013 | 41 |
| ok38 | oct | 1 | 2011 | 40 |
| ok39 | oct | 10 | 2013 | 39 |
| ok40 | feb | 28 | 2013 | 38 |
#2. Too long month
Test
Case ID | Month | Day | Year | Combo
Countdown | |
|---|
| 12 Values | 4 Values | 3 Values | 96 |
| err1 | jan | 32 | 2011 | 93 |
| err2 | apr | 31 | 2012 | 90 |
| err3 | feb | 29 | 2013 | 87 |
| err4 | feb | 30 | 2012 | 84 |
| err5 | mar | 32 | 2011 | 82 |
| err6 | may | 32 | 2011 | 80 |
| err7 | jul | 32 | 2011 | 78 |
| err8 | aug | 32 | 2011 | 76 |
| err9 | oct | 32 | 2011 | 74 |
| err10 | dec | 32 | 2011 | 72 |
| err11 | jun | 31 | 2012 | 70 |
| err12 | sep | 31 | 2012 | 68 |
| err13 | nov | 31 | 2012 | 66 |
The PowerPoint presentation Pairwise Testing Comes of Age
gives a further discussion on the selection of test input data based on the system state and expected results.
A similar example starting on slide 24 explains these ideas in more detail.
|
