The art of software testing. Myers (2nd edition) (2004) (The art of software testing. Myers (2nd edition) (2004).pdf), страница 18

For example, statement 18 is never executed. Moreover,they do not accomplish much more than the test cases in Figure 5.3.They do not cause the output situation ERRORCODE=0. If statement 2had erroneously said (ESIZE=0) and (DSIZE=0), this error would goundetected. Of course, an alternative set of test cases might solvethese problems, but the fact remains that the two test cases in Figure5.4 do satisfy the condition-coverage criterion.Table 5.2Situations Corresponding to the Condition OutcomesDecision226ConditionESIZE ≤ 0ESIZE > 0DSIZE ≤ 0DSIZE ≤ 0DSIZE > 0SALES (I) ≥Will always occurat least once.Order DEPTTAB sothat a department withlower salesoccurs after adepartmentwith highersales.All departments donot have thesame sales.There is anemployee whois not in aneligibledepartment.An eligibleemployee earnsless thanLSALARY.An eligibleemployee is nota manager.An eligible department containsat least oneemployee.SALES (J) =MAXSALES13EMPTAB.DEPT(K) =DEPTTAB.DEPT(J)16False OutcomeESIZE ≤ 0MAXSALES9True OutcomeSALARY (K) ≥LSALARY16CODE (K) = MGR21-FOUNDWill always occurat least once.There is anemployeein an eligibledepartment.An eligibleemployee earnsLSALARY or more.An eligibleemployee is amanager.An eligibledepartmentcontains noemployees.98Module (Unit) Testing99Figure 5.4Test cases to satisfy the condition-coverage criterion.TestcaseInput12Expected outputESIZE = DSIZE = 0ERRCODE = 1All other inputs are irrelevantESIZE, DSIZE, EMPTAB, andDEPTTAB are unchangedERRCODE = 2ESIZE = DSIZE = 3EMPTABDEPTTABJONESED42 21,000.00D4210,000.00SMITHED32 14,000.00D328,000.00LORINMD42 10,000.00D9510,000.00ESIZE, DSIZE, and DEPTTAB areunchangedEMPTABJONESED4221,000.00SMITHED3214,000.00LORINMD4210,100.00Using the decision/condition-coverage criterion would eliminatethe big weakness in the test cases in Figure 5.4.

Here we would provide sufficient test cases such that all outcomes of all conditions anddecisions were evoked at least once. Making Jones a manager andmaking Lorin a nonmanager could accomplish this. This would havethe result of generating both outcomes of decision 16, thus causingus to execute statement 18.One problem with this, however, is that it is essentially no betterthan the test cases in Figure 5.3. If the compiler being used stopsevaluating an or expression as soon as it determines that one operandis true, this modification would result in the expression CODE(K)=MGR instatement 16 never having a true outcome. Hence, if this expressionwere coded incorrectly, the test cases would not detect the error.The last criterion to explore is multicondition coverage.

This criterion requires sufficient test cases that all possible combinations ofconditions in each decision are evoked at least once. This can beaccomplished by working from Table 5.2. Decisions 6, 9, 13, and 21100The Art of Software Testinghave two combinations each; decisions 2 and 16 have four combinations each. The methodology to design the test cases is to select onethat covers as many of the combinations as possible, select anotherthat covers as many of the remaining combinations as possible, and soon. A set of test cases satisfying the multicondition-coverage criterion is shown in Figure 5.5.

The set is more comprehensive than theprevious sets of test cases, implying that we should have selected thiscriterion at the beginning.It is important to realize that module BONUS could have a largenumber of errors that would not be detected by even the tests satisfyFigure 5.5Test cases to satisfy the multicondition-coverage criterion.TestcaseInput1Expected outputESIZE = 0 DSIZE = 0ERRCODE = 1All other inputs are irrelevantESIZE, DSIZE, EMPTAB, andDEPTTAB are unchangedESIZE = 0 DSIZE > 02Same as aboveAll other inputs are irrelevant3ESIZE > 0 DSIZE = 0Same as aboveAll other inputs are irrelevant4ESIZE = 5 DSIZE = 4EMPTABERRCODE = 2DEPTTABJONESMD42 21,000.00D42WARNSMD95 12,000.00D328,000.00LORINED42 10,000.00D9510,000.00TOYED95 16,000.00D4410,000.00SMITHEESIZE, DSIZE, and DEPTTAB areunchanged10,000.00EMPTABJONESMD4221,100.00WARNSMD9512,100.00LORINED4210,200.00TOYED9516,100.00SMITHED3214,000.00D32 14,000.00Module (Unit) Testing101ing the multicondition-coverage criterion.

For instance, no test casesgenerate the situation where ERRORCODE is returned with a value of 0;thus, if statement 1 were missing, the error would go undetected. IfLSALARY were erroneously initialized to $150,000.01, the mistakewould go unnoticed. If statement 16 stated SALARY(K)>LSALARY insteadof SALARY(K)>=LSALARY, this error would not be found. Also, whethera variety of off-by-one errors (such as not handling the last entry inDEPTTAB or EMPTAB correctly) would be detected would depend largelyon chance.Two points should be apparent now: the multicondition-criterionis superior to the other criteria, and any logic-coverage criterion isnot good enough to serve as the only means of deriving module tests.Hence, the next step is to supplement the tests in Figure 5.5 with a setof black-box tests.

To do so, the interface specifications of BONUSare shown in the following:BONUS, a PL/1module, receives five parameters, symbolicallyreferred to here as EMPTAB, DEPTTAB, ESIZE, DSIZE, and ERRORCODE.The attributes of these parameters areDECLARE 1 EMPTAB(*),/*INPUT AND OUTPUT*/2 NAME CHARACTER(6),2 CODE CHARACTER(1),2 DEPT CHARACTER(3),2 SALARY FIXED DECIMAL(7,2);DECLARE 1 DEPTTAB(*),/*INPUT*/2 DEPT CHARACTER(3),2 SALES FIXED DECIMAL(8,2);DECLARE (ESIZE, DSIZE) FIXED BINARY;DECLARE ERRCODE FIXED DECIMAL(1);/*INPUT*//*OUTPUT*/The module assumes that the transmitted arguments have theseattributes. ESIZE and DSIZE indicate the number of entries in EMPTABand DEPTTAB, respectively. No assumptions should be made aboutthe order of entries in EMPTAB and DEPTTAB.

The function of the102The Art of Software Testingmodule is to increment the salary (EMPTAB.SALARY) of thoseemployees in the department or departments having the largestsales amount (DEPTTAB.SALES). If an eligible employee’s currentsalary is $150,000 or more, or if the employee is a manager(EMPTAB.CODE='M'), the increment is $1,000; if not, the incrementfor the eligible employee is $2,000. The module assumes that theincremented salary will fit into field EMPTAB.SALARY.

If ESIZE andDSIZE are not greater than 0, ERRCODE is set to 1 and no furtheraction is taken. In all other cases, the function is completelyperformed. However, if a maximum-sales department is found tohave no employee, processing continues, but ERRCODE will have thevalue 2; otherwise, it is set to 0.This specification is not suited to cause-effect graphing (there isnot a discernable set of input conditions whose combinations shouldbe explored); thus, boundary-value analysis will be used. The inputboundaries identified are as follows:1. EMPTAB has 1 entry.2.

EMPTAB has the maximum number of entries (65,535).3. EMPTAB has 0 entries.4. DEPTTAB has 1 entry.5. DEPTTAB has 65,535 entries.6. DEPTTAB has 0 entries.7. A maximum-sales department has 1 employee.8. A maximum-sales department has 65,535 employees.9. A maximum-sales department has no employees.10. All departments in DEPTTAB have the same sales.11. The maximum-sales department is the first entry in DEPTTAB.12. The maximum-sales department is the last entry in DEPTTAB.13. An eligible employee is the first entry in EMPTAB.14. An eligible employee is the last entry in EMPTAB.15.

An eligible employee is a manager.16. An eligible employee is not a manager.17. An eligible employee who is not a manager has a salary of$149,999.99.Module (Unit) Testing10318. An eligible employee who is not a manager has a salary of$150,000.19. An eligible employee who is not a manager has a salary of$150,000.01.The output boundaries are as follows:20. ERRCODE=0.21. ERRCODE=1.22. ERRCODE=2.23. The incremented salary of an eligible employee is$299,999.99.A further test condition based on the error-guessing technique isas follows:24. A maximum-sales department with no employees is followedin DEPTTAB with another maximum-sales department havingemployees.This is used to determine whether the module erroneously terminatesprocessing of the input when it encounters an ERRCODE=2 situation.Reviewing these 24 conditions, conditions 2, 5, and 8 seem likeimpractical test cases.

Since they also represent conditions that willnever occur (usually a dangerous assumption to make when testing,but seemingly safe here), they are excluded. The next step is to compare the remaining 21 conditions to the current set of test cases (Figure 5.5) to determine which boundary conditions are not alreadycovered. Doing so, we see that conditions 1, 4, 7, 10, 14, 17, 18, 19,20, 23, and 24 require test cases beyond those in Figure 5.5.The next step is to design additional test cases to cover the 11boundary conditions. One approach is to merge these conditionsinto the existing test cases (i.e., by modifying test case 4 in Figure5.5), but this is not recommended because doing so could inadvertently upset the complete multicondition coverage of the existing testcases.