14.3 Testing Decision Structures
Specifications are often expressed as decision structures, such as sets of conditions on input values and corresponding actions or results. A model of the decision structure can be used to choose test cases that may reveal discrepancies between the decisions actually made in the code and the intended decision structure.
The example specification of Figure 14.3 describes outputs that depend on type of account (either educational, or business, or individual), amount of current and yearly purchases, and availability of special prices. These can be considered as Boolean conditions, for example, the condition educational account is either true or false (even if the type of account is actually represented in some other manner). Outputs can be described as Boolean expressions over the inputs, for example, the output no discount can be associated with the Boolean expression
Pricing The pricing function determines the adjusted price of a configuration for a particular customer. The scheduled price of a configuration is the sum of the scheduled price of the model and the scheduled price of each component in the configuration. The adjusted price is either the scheduled price, if no discounts are applicable, or the scheduled price less any applicable discounts.
There are three price schedules and three corresponding discount schedules, Business, Educational, and Individual. The Business price and discount schedules apply only if the order is to be charged to a business account in good standing. The Educational price and discount schedules apply to educational institutions. The Individual price and discount schedules apply to all other customers. Account classes and rules for establishing business and educational accounts are described further in […].
A discount schedule includes up to three discount levels, in addition to the possibility of "no discount." Each discount level is characterized by two threshold values, a value for the current purchase (configuration schedule price) and a cumulative value for purchases over the preceding 12 months (sum of adjusted price).
Educational prices The adjusted price for a purchase charged to an educational account in good standing is the scheduled price from the educational price schedule. No further discounts apply.
Business account discounts Business discounts depend on the size of the current purchase as well as business in the preceding 12 months. A tier 1 discount is applicable if the scheduled price of the current order exceeds the tier 1 current order threshold, or if total paid invoices to the account over the preceding 12 months exceeds the tier 1 year cumulative value threshold. A tier 2 discount is applicable if the current order exceeds the tier 2 current order threshold, or if total paid invoices to the account over the preceding 12 months exceeds the tier 2 cumulative value threshold. A tier 2 discount is also applicable if both the current order and 12 month cumulative payments exceed the tier 1 thresholds.
Individual discounts Purchase by individuals and by others without an established account in good standing is based on current value alone (not on cumulative purchases). A tier 1 individual discount is applicable if the scheduled price of the configuration in the current order exceeds the tier 1 current order threshold. A tier 2 individual discount is applicable if the scheduled price of the configuration exceeds the tier 2 current order threshold.
Special-price nondiscountable offers Sometimes a complete configuration is offered at a special, non-discountable price. When a special, nondiscountable price is available for a configuration, the adjusted price is the nondiscountable price or the regular price after any applicable discounts, whichever is less.
Figure 14.3: The functional specification of feature Pricing of the Chipmunk Web site.
When functional specifications can be given as Boolean expressions, we can apply any of the condition testing approaches described in Chapter 12, Section 12.4. A good test suite should at least exercise all elementary conditions occurring in the expression. For simple conditions we might derive test case specifications for all possible combinations of truth values of the elementary conditions. For complex formulas, when testing all 2n combinations of n elementary conditions is apt to be too expensive, the modified decision/condition coverage criterion (page 12.4) derives a small set of test conditions such that each elementary condition independently affects the outcome.
We can produce different models of the decision structure of a specification depending on the original specification and on the technique we want to use for deriving test cases. If the original specification is expressed informally as in Figure 14.3, we can transform it into either a Boolean expression, a graph, or a tabular model before applying a test case generation technique.
Techniques for deriving test case specifications from decision structures were originally developed for graph models, and in particular cause-effect graphs, which have been used since the early 1970s. Cause-effect graphs are tedious to derive and do not scale well to complex specifications. Tables, on the other hand, are easy to work with and scale well.
The rows of a decision table represent basic conditions, and columns represent combinations of basic conditions. The last row of the table indicates the expected outputs for each combination. Cells of the table are labeled either True, False,or don't care (usually written –), to indicate the truth value of the basic condition. Thus, each column is equivalent to a logical expression joining the required values (negated, in the case of False entries) and omitting the basic conditions with don't care values.[2]
Decision tables can be augmented with a set of constraints that limit the possible combinations of basic conditions. A constraint language can be based on Boolean logic. Often it is useful to add some shorthand notations for common combinations such as at-most-one(C1, …, Cn) and exactly-one(C1, …, Cn), which are tedious to express with the standard Boolean connectives.
Figure 14.4 shows the decision table for the functional specification of feature pricing of the Chipmunk Web site presented in Figure 14.3.
Education | Individual | |||||||
|---|---|---|---|---|---|---|---|---|
EduAc | T | T | F | F | F | F | F | F |
BusAc | - | - | F | F | F | F | F | F |
CP > CT1 | - | - | F | F | T | T | - | - |
YP > YT1 | - | - | - | - | - | - | - | - |
CP > CT2 | - | - | - | - | F | F | T | T |
YP > YT2 | - | - | - | - | - | - | - | - |
SP > Sc | F | T | F | T | - | - | - | - |
SP > T1 | - | - | - | - | F | T | - | - |
SP > T2 | - | - | - | - | - | - | F | T |
| Edu | SP | ND | SP | T1 | SP | T2 | SP |
Business | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
EduAc | - | - | - | - | - | - | - | - | - | - | - | - |
BusAc | T | T | T | T | T | T | T | T | T | T | T | T |
CP > CT1 | F | F | T | T | F | F | T | T | - | - | - | - |
YP > YT1 | F | F | F | F | T | T | T | T | - | - | - | - |
CP > CT2 | - | - | F | F | - | - | - | - | T | T | - | - |
YP > YT2 | - | - | - | - | F | F | - | - | - | - | T | T |
SP > Sc | F | T | - | - | - | - | - | - | - | - | - | - |
SP > T1 | - | - | F | T | F | T | - | - | - | - | - | - |
SP > T2 | - | - | - | - | - | - | F | T | F | T | F | T |
| ND | SP | T1 | SP | T1 | SP | T2 | SP | T2 | SP | T2 | SP |
Constraints
at-most-one(EduAc, BusAc) | at-most-one(YP < YT1, YP > YT2) |
YP > YT2 ↠ YP > YT1 | at-most-one(CP < CT1, CP > CT2) |
CP > CT2 ↠ CP > CT1 | at-most-one(SP < T1, SP > T2) |
SP > T2 ↠ SP > T1 |
Abbreviations
EduAc | Educational account | Edu | Educational price |
BusAc | Business account | ND | No discount |
CP > CT1 | Current purchase greater than threshold 1 | T1 | Tier 1 |
YP > YT1 | Year cumulative purchase greater than threshold 1 | T2 | Tier 2 |
CP > CT2 | Current purchase greater than threshold 2 | SP | Special Price |
YP > YT2 | Year cumulative purchase greater than threshold 2 | ||
SP > Sc | Special Price better than scheduled price | ||
SP > T1 | Special Price better than tier 1 | ||
SP > T2 | Special Price better than tier 2 |
Open table as spreadsheet
Figure 14.4: A decision table for the functional specification of feature Pricing of the Chipmunk Web site of Figure 14.3.
The informal specification of Figure 14.3 identifies three customer profiles: educational, business, and individual. Figure 14.4 has only rows Educational account (EduAc) and Business account (BusAc). The choice individual corresponds to the combination False, False for choices EduAc and BusAc, and is thus redundant. The informal specification of Figure 14.3 indicates different discount policies depending on the relation between the current purchase and two progressive thresholds for the current purchase and the yearly cumulative purchase. These cases correspond to rows 3 through 6 of Figure 14.4. Conditions on thresholds that do not correspond to individual rows in the table can be defined by suitable combinations of values for these rows. Finally, the informal specification of Figure 14.3 distinguishes the cases in which special offer prices do not exceed either the scheduled or the tier 1 or tier 2 prices. Rows 7 through 9 of the table, suitably combined, capture all possible cases of special prices without redundancy.
Constraints formalize the compatibility relations among different basic conditions listed in the table. For example, a cumulative purchase exceeding threshold tier 2 also exceeds threshold tier 1.
The basic condition adequacy criterion requires generation of a test case specification for each column in the table. Don't care entries of the table can be filled out arbitrarily, as long as constraints are not violated.
The compound condition adequacy criterion requires a test case specification for each combination of truth values of basic conditions. The compound condition adequacy criterion generates a number of cases exponential in the number of basic conditions (2n combinations for n conditions) and can thus be applied only to small sets of basic conditions.
For the modified condition/decision adequacy criterion (MC/DC), each column in the table represents a test case specification. In addition, for each of the original columns, MC/DC generates new columns by modifying each of the cells containing True or False. If modifying a truth value in one column results in a test case specifi∆ modified condition/decision coverage cation consistent with an existing column (agreeing in all places where neither is don't care), the two test cases are represented by one merged column, provided they can be merged without violating constraints.
The MC/DC criterion formalizes the intuitive idea that a thorough test suite would not only test positive combinations of values - combinations that lead to specified outputs - but also negative combinations of values - combinations that differ from the specified ones - thus, they should produce different outputs, in some cases among the specified ones, in some other cases leading to error conditions.
Applying MC/DC to column 1 of Figure 14.4 generates two additional columns: one for Educational Account = False and Special Price better than scheduled price = False, and the other for Educational Account = True and Special Price better than scheduled price = True. Both columns are already in the table (columns 3 and 2, respectively) and thus need not be added.
Similarly, from column 2, we generate two additional columns corresponding to Educational Account = False and Special Price better than scheduled price = True, and Educational Account = True and Special Price better than scheduled price = False, also already in the table.
Generation of a new column for each possible variation of the Boolean values in the columns, varying exactly one value for each new column, produces 78 new columns, 21 of which can be merged with columns already in the table. Figure 14.5 shows a table obtained by suitably joining the generated columns with the existing ones. Many don't care cells from the original table are assigned either True or False values, to allow merging of different columns or to obey constraints. The few don't-care entries left can be set randomly to obtain a complete test case.
EduAc | T | T | F | F | F | F | F | F | F | F | F | F | F | F | F |
BusAc | F | F | F | F | F | F | F | F | T | T | T | T | T | T | T |
CP > CT1 | T | T | F | F | T | T | T | T | F | F | T | T | F | F | T |
YP > YT1 | F | - | F | - | - | F | T | T | F | F | F | F | T | T | T |
CP > CT2 | F | F | F | F | F | F | T | T | F | F | F | F | F | F | F |
YP > YT2 | - | - | - | - | - | - | - | - | - | - | - | - | F | F | F |
SP > Sc | F | T | F | T | F | T | - | - | F | T | F | - | F | T | - |
SP > T1 | F | T | F | T | F | T | F | T | F | T | F | T | F | T | F |
SP > T2 | F | - | F | - | F | - | F | T | F | - | F | - | F | - | F |
| Edu | SP | ND | SP | T1 | SP | T2 | SP | ND | SP | T1 | SP | T1 | SP | T2 |
Open table as spreadsheet
EduAc | F | F | F | F | F | T | T | T | T | F | - |
BusAc | T | T | T | T | T | F | F | F | F | F | F |
CP > CT1 | T | T | T | F | F | F | F | T | - | - | F |
YP > YT1 | T | F | F | T | T | T | - | - | - | T | T |
CP > CT2 | F | T | T | F | F | F | F | T | T | F | F |
YP > YT2 | F | - | - | T | T | F | - | - | - | T | F |
SP > Sc | T | - | T | - | T | F | T | - | - | - | - |
SP > T1 | T | F | T | F | T | F | - | - | T | T | T |
SP > T2 | T | F | T | F | T | F | F | F | T | T | - |
| SP | T2 | SP | T2 | SP | Edu | SP | Edu | SP | SP | SP |
Open table as spreadsheet
Abbreviations
EduAc | Educational account | Edu | Educational price |
BusAc | Business account | ND | No discount |
CP > CT1 | Current purchase greater than threshold 1 | T1 | Tier 1 |
YP > YT1 | Year cumulative purchase greater than threshold 1 | T2 | Tier 2 |
CP > CT2 | Current purchase greater than threshold 2 | SP | Special Price |
YP > YT2 | Year cumulative purchase greater than threshold | 2 | |
SP > Sc | Special Price better than scheduled price | ||
SP > T1 | Special Price better than tier 1 | ||
SP > T2 | Special Price better than tier 2 |
Open table as spreadsheet
Figure 14.5: The set of test cases generated for feature Pricing of the Chipmunk Web site applying the modified adequacy criterion.
There are many ways of merging columns that generate different tables. The table in Figure 14.5 may not be the optimal one - the one with the fewest columns. The objective in test design is not to find an optimal test suite, but rather to produce a cost effective test suite with an acceptable trade-off between the cost of generating and executing test cases and the effectiveness of the tests.
The table in Figure 14.5 fixes the entries as required by the constraints, while the initial table in Figure 14.4 does not. Keeping constraints separate from the table corresponding to the initial specification increases the number of don't care entries in the original table, which in turn increases the opportunity for merging columns when generating new cases with the MC/DC criterion. For example, if business account (BusAc) = False, the constraint at-most-one(EduAc, BusAc) can be satisfied by assigning either True or False to entry educational account. Fixing either choice prematurely may later make merging with a newly generated column impossible.
[2]The set of columns sharing a label is therefore equivalent to a logical expression in sum-of-productsform.
No comments:
Post a Comment