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

Second, moduletesting eases the task of debugging (the process of pinpointing andcorrecting a discovered error), since, when an error is found, it isknown to exist in a particular module. Finally, module testing introduces parallelism into the program testing process by presenting uswith the opportunity to test multiple modules simultaneously.The purpose of module testing is to compare the function of amodule to some functional or interface specification defining themodule.

To reemphasize the goal of all testing processes, the goalhere is not to show that the module meets its specification, but toshow that the module contradicts the specification. In this chapter wediscuss module testing from three points of view:1. The manner in which test cases are designed.2. The order in which modules should be tested and integrated.3. Advice about performing the test.9192The Art of Software TestingTest-Case DesignYou need two types of information when designing test cases for amodule test: a specification for the module and the module’s sourcecode. The specification typically defines the module’s input and output parameters and its function.Module testing is largely white-box oriented.

One reason is that asyou test larger entities such as entire programs (which will be the casefor subsequent testing processes), white-box testing becomes less feasible. A second reason is that the subsequent testing processes are oriented toward finding different types of errors (for example, errors notnecessarily associated with the program’s logic, such as the program’sfailing to meet its users’ requirements).

Hence, the test-case-designprocedure for a module test is the following: Analyze the module’slogic using one or more of the white-box methods, and then supplement these test cases by applying black-box methods to the module’sspecification.Since the test-case-design methods to be used have already beendefined in Chapter 4, their use in a module test is illustrated herethrough an example. Assume that we wish to test a module namedBONUS, and its function is to add $2,000 to the salary of all employees in the department or departments having the largest sales amount.However, if an eligible employee’s current salary is $150,000 ormore, or if the employee is a manager, the salary is increased by only$1,000.The inputs to the module are the tables shown in Figure 5.1.

If themodule performs its function correctly, it returns an error code of 0.If either the employee or the department table contains no entries, itreturns an error code of 1. If it finds no employees in an eligibledepartment, it returns an error code of 2.The module’s source code is shown in Figure 5.2. Input parameters ESIZE and DSIZE contain the number of entries in the employeeand department tables. The module is written in PL/1, but the following discussion is largely language independent; the techniques areapplicable to programs coded in other languages.

Also, since theModule (Unit) Testing93Figure 5.1Input tables to module BONUS.NameJobcodeDept.SalaryDept.SalesDepartment tableEmployee tablePL/1 logic in the module is fairly simple, virtually any reader, eventhose not familiar with PL/1, should be able to understand it.Regardless of which of the logic-coverage techniques you use, thefirst step is to list the conditional decisions in the program.

Candidates in this program are all IF and DO statements. By inspecting theprogram, we can see that all of the DO statements are simple iterations,each iteration limit will be equal to or greater than the initial value(meaning that each loop body always will execute at least once), andthe only way of exiting each loop is via the DO statement. Thus, theDO statements in this program need no special attention, since any testcase that causes a DO statement to execute will eventually cause it toFigure 5.2Module BONUS.BONUS : PROCEDURE(EMPTAB,DEPTTAB,ESIZE,DSIZE,ERRCODE);DECLARE1EMPTAB (*),2 NAME CHAR(6),2 CODE CHAR(1),2 DEPT CHAR(3),2 SALARY FIXED DECIMAL(7,2);DECLARE1DEPTTAB (*),2 DEPT CHAR(3),2 SALES FIXED DECIMAL(8,2);DECLARE(ESIZE,DSIZE) FIXED BINARY;DECLAREERRCODE FIXED DECIMAL(1);DECLAREMAXSALES FIXED DECIMAL(8,2) INIT(0); /*MAX.

SALES IN DEPTTAB*/DECLARE(I,J,K) FIXED BINARY;DECLAREFOUND BIT(1);DECLARESINC FIXED DECIMAL(7,2) INIT(200.00);/*STANDARD INCREMENT*/DECLARELINC FIXED DECIMAL(7,2) INIT(100.00);/*LOWER INCREMENT*/DECLARELSALARY FIXED DECIMAL(7,2) INIT(15000.00);DECLAREMGR CHAR(1) INIT('M');/*TRUE IF ELIGIBLE DEPT.

HAS EMPLOYEES*/1ERRCODE=0;2IF(ESIZE<=0)|(DSIZE<=0)3THEN ERRCODE=1;4ELSE DO;56END;DO J = 1 TO DSIZE;IF(SALES(J)=MAXSALES)/*ELIGIBLE DEPARTMENT*/THEN DO;11FOUND='0'B;12DO K = 1 TO ESIZE;13/*FIND MAXSALES AND MAXDEPTS*/IF(SALES(I)>=MAXSALES) THEN MAXSALES=SALES(I);810/*SALARY BOUNDARY*//*EMPTAB OR DEPTTAB ARE EMPTY*/DO I = 1 TO DSIZE;79/*COUNTERS*/IF(EMPTAB.DEPT(K)=DEPTTAB.DEPT(J))94Module (Unit) Testing14THEN DO;15FOUND='1'B;16IF(SALARY(K)>=LSALARY)|CODE(K)=MGR)17THEN SALARY(K)=SALARY(K)+LINC;18ELSE SALARY(K)=SALARY(K)+SINC;19END;20END;21IF(-FOUND) THEN ERRCODE=2;22END;232495END;END;25 END;branch in both directions (i.e., enter the loop body and skip the loopbody).

Therefore, the statements that must be analyzed are2 IF (ESIZE<=O) | (DSIZE<=0)6 IF (SALES(I) >= MAXSALES)9 IF (SALES(J) = MAXSALES)13 IF (EMPTAB.DEPT(K) = DEPTTAB.DEPT(J))16 IF (SALARY(K) >= LSALARY) | (CODE(K) =MGR)21 IF(-FOUND) THEN ERRCODE=2Given the small number of decisions, we probably should opt formulticondition coverage, but we shall examine all the logic-coveragecriteria (except statement coverage, which always is too limited to beof use) to see their effects.To satisfy the decision-coverage criterion, we need sufficient testcases to evoke both outcomes of each of the six decisions.

Therequired input situations to evoke all decision outcomes are listed inTable 5.1. Since two of the outcomes will always occur, there are 10situations that need to be forced by test cases. Note that to construct96The Art of Software TestingTable 5.1, decision-outcome circumstances had to be traced backthrough the logic of the program to determine the proper corresponding input circumstances. For instance, decision 16 is notevoked by any employee meeting the conditions; the employee mustbe in an eligible department.The 10 situations of interest in Table 5.1 could be evoked by thetwo test cases shown in Figure 5.3.

Note that each test case includesa definition of the expected output, in adherence to the principlesdiscussed in Chapter 2.Although these two test cases meet the decision-coverage criterion, it should be obvious that there could be many types of errors inthe module that are not detected by these two test cases. For instance,the test cases do not explore the circumstances where the error codeis 0, an employee is a manager, or the department table is empty(DSIZE<=0).A more satisfactory test can be obtained by using the conditioncoverage criterion.

Here we need sufficient test cases to evoke bothTable 5.1Situations Corresponding to the Decision OutcomesDecision26True OutcomeESIZE or DSIZE ≤ 0.Will always occur at leastonce.9Will always occur at leastonce.There is an employee inan eligible department.An eligible employee iseither a manager orearns LSALARY or more.All eligible departmentscontain no employees.131621False OutcomeESIZE and DSIZE > 0.Order DEPTTAB so that a departmentwith lower sales occurs after adepartment with higher sales.All departments do not have thesame sales.There is an employee who is notin an eligible department.An eligible employee is not amanager and earns less thanLSALARY.An eligible department containsat least one employee.Module (Unit) Testing97Figure 5.3Test cases to satisfy the decision-coverage criterion.TestcaseInputExpected outputESIZE = 0ERRCODE = 1All other inputs are irrelevantESIZE, DSIZE, EMPTAB, and DEPTTAB1are unchanged2ERRCODE = 2ESIZE = DSIZE = 3EMPTABDEPTTABJONESED42 21,000.00D4210,000.00SMITHED32 14,000.00D328,000.00LORINED42 10,000.00D9510,000.00ESIZE, DSIZE, and DEPTTAB areunchangedEMPTABJONESED4221,100.00SMITHED3214,000.00LORINED4210,200.00outcomes of each condition in the decisions.

The conditions andrequired input situations to evoke all outcomes are listed in Table 5.2.Since two of the outcomes will always occur, there are 14 situationsthat must be forced by test cases. Again, these situations can beevoked by only two test cases, as shown in Figure 5.4.The test cases in Figure 5.4 were designed to illustrate a problem.Since they do evoke all the outcomes in Table 5.2, they satisfy thecondition-coverage criterion, but they are probably a poorer set oftest cases than those in Figure 5.3 in terms of satisfying the decisioncoverage criterion. The reason is that they do not execute everystatement.