Testcover.com Testcover.com
Tutorial - Calendar Example -
Constraints for Partitioning

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
->Equivalence Partitioning
->UML State Machines
->Definitions of Terms
Performance
WSDL Interface
Background
Partners
Registrations
Contact Information



The calendar example illustrates the use of the test case generator for 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 give test cases with expected results that are invalid, and which must be handled differently than test cases with valid results.

Consider a calendar system which has three test factors with values as follows.

Test FactorNumber of ValuesTest Factor Values
1. Month12 jan feb mar apr may jun jul aug sep oct nov dec
2. Day7 1 10 28 29 30 31 32
3. Year32015 2016 2017
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
feb292017
This is an error test case because 2017 is not a leap year: February has only 28 days in 2017. 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 (2016) and as an error case (in 2017) 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
2015 2016 2017
+ long month last day
jan mar may jul aug oct dec
31
2015 2016 2017
+ short month last day
apr jun sep nov
30
2015 2016 2017
+ feb last day
feb
28
2015 2017
+ leap day
feb
29
2016
#err Too long month
+ too long long month
jan mar may jul aug oct dec
32
2015
+ too long short month
apr jun sep nov
31
2016
+ feb too long, regular year
feb
29
2017
+ feb too long, leap year
feb
30
2016

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
MonthDayYearCombo
Countdown
12 Values6 Values3 Values126
ok1jan12015123
ok2jan102016120
ok3feb102015117
ok4feb12017114
ok5mar12016111
ok6mar102017108
ok7may312017105
ok8aug312016102
ok9oct31201599
ok10nov30201696
ok11apr30201793
ok12jun30201590
ok13feb29201687
ok14apr1201585
ok15apr10201683
ok16may10201581
ok17jun1201679
ok18jun10201777
ok19jul1201575
ok20jul10201673
ok21aug10201571
ok22aug1201769
ok23sep10201567
ok24sep1201665
ok25oct10201663
ok26nov10201561
ok27nov1201759
ok28dec10201557
ok29dec1201655
ok30jul31201753
ok31dec31201751
ok32jan31201749
ok33mar31201547
ok34sep30201745
ok35feb28201543
ok36may10201642
ok37may1201741
ok38oct1201540
ok39oct10201739
ok40feb28201738

#2. Too long month
Test
Case ID
MonthDayYearCombo
Countdown
12 Values4 Values3 Values96
err1jan32201593
err2apr31201690
err3feb29201787
err4feb30201684
err5mar32201582
err6may32201580
err7jul32201578
err8aug32201576
err9oct32201574
err10dec32201572
err11jun31201670
err12sep31201668
err13nov31201666

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.

The calendar example illustrates equivalence partitioning, which is introduced in a later tutorial section. The two partitions test different classes of results. The first partition allows valid dates and disallows invalid dates. The second partition allows invalid dates from months that are too long and disallows valid dates. The separation into partitions allows each class of results to be verified with all pairs of factors values.

An alternate way to handle calendar constraints is shown in a later section also. This technique uses the fact that the last day of any month is determined by its month and year. That is, it can be expressed as a function of the values of two other factors: last_day(month,year).

<Constraints Example Database Table Example>

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