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

First, theterms “top-down testing,” “bottom-down development,” and “topdown design” are often used as synonyms. Top-down testing andtop-down development are synonyms (they represent a strategy ofordering the coding and testing of modules), but top-down design issomething quite different and independent. A program that was110The Art of Software Testingdesigned in top-down fashion can be incrementally tested in either atop-down or a bottom-up fashion.Second, bottom-up testing (or bottom-up development) is oftenmistakenly equated with nonincremental testing. The reason is thatbottom-up testing begins in a manner that is identical to a nonincremental test (i.e., when the bottom, or terminal, modules are tested),but as we saw in the previous section, bottom-up testing is an incremental strategy.

Finally, since both strategies are incremental, theadvantages of incremental testing are not repeated here; only the differences between top-down and bottom-up testing are discussed.Top-down TestingThe top-down strategy starts with the top, or initial, module in theprogram. After this, there is no single right procedure for selectingthe next module to be incrementally tested; the only rule is that to beeligible to be the next module, at least one of the module’s subordinate (calling) modules must have been tested previously.Figure 5.8 is used to illustrate this strategy.

A through L are the 12modules in the program. Assume that module J contains the program’sI/O read operations and module I contains the write operations.The first step is the testing of Module A. To accomplish this, stubmodules representing B, C, and D must be written. Unfortunately,the production of stub modules is often misunderstood; as evidence,you may often see such statements as “a stub module need only writea message stating ‘we got this far,’ ” and “in many cases, the dummymodule (stub) simply exits—without doing any work at all.” In mostsituations, these statements are false. Since module A calls module B,A is expecting B to perform some work; this work most likely is someresult (output arguments) returned to A.

If the stub simply returnscontrol or writes an error message without returning a meaningfulresult, module A will fail, not because of an error in A, but becauseof a failure of the stub to simulate the corresponding module. Moreover, returning a “wired-in” output from a stub module is ofteninsufficient. For instance, consider the task of writing a stub representing a square-root routine, a database table-search routine, anModule (Unit) Testing111Figure 5.8Sample 12-module program.“obtain corresponding master-file record” routine, or the like. If thestub returns a fixed wired-in output, but, not having the particularvalue expected by the calling module during this invocation, the calling module may fail or produce a confusing result.

Hence, the production of stubs is not a trivial task.Another consideration is the form in which test cases are presentedto the program, an important consideration that is not even mentioned in most discussions of top-down testing. In our example, thequestion is: How do you feed test cases to module A? Since the topmodule in typical programs neither receives input arguments norperforms input/output operations, the answer is not immediatelyobvious. The answer is that the test data are fed to the module (module A in this situation) from one or more of its stubs. To illustrate,assume that the functions of B, C, and D are as follows:112The Art of Software TestingB—Obtain summary of transaction file.C—Determine whether weekly status meets quota.D—Produce weekly summary report.A test case for A, then, is a transaction summary returned fromstub B.

Stub D might contain statements to write its input data to aprinter, allowing the results of each test to be examined.In this program, another problem exists. Since module A presumably calls module B only once, the problem is how you feed morethan one test case to A.

One solution is to develop multiple versionsof stub B, each with a different wired-in set of test data to bereturned to A. To execute the test cases, the program is executedmultiple times, each time with a different version of stub B. Anotheralternative is to place test data on external files and have stub B readthe test data and return them to A. In either case, and because of theprevious discussion, you should see that the development of stubmodules is more difficult than it is often made out to be. Furthermore, it often is necessary, because of the characteristics of the program, to represent a test case across multiple stubs beneath themodule under test (i.e., where the module receives data to be actedupon by calling multiple modules).After A has been tested, an actual module replaces one of the stubs,and the stubs required by that module are added.

For instance, Figure5.9 might represent the next version of the program.After testing the top module, numerous sequences are possible. Forinstance, if we are performing all the testing sequences, four examples of the many possible sequences of modules are1. A2. A3. A4. ABBDBCEHFDFIJEJKDFCLIGGCEHKGCIDBGJHFKKLJHLIELIf parallel testing occurs, other alternatives are possible. Forinstance, after module A has been tested, one programmer could takemodule A and test the combination A-B, another programmer couldModule (Unit) Testing113Figure 5.9Second step in the top-down test.test A-C, and a third could test A-D.

In general, there is no bestsequence, but here are two guidelines to consider:1. If there are critical sections of the program (perhaps moduleG), design the sequence such that these sections are added asearly as possible. A “critical section” might be a complexmodule, a module with a new algorithm, or a module suspected to be error prone.2. Design the sequence such that the I/O modules are added asearly as possible.The motivation for the first should be obvious, but the motivationfor the second deserves further discussion. Recall that a problem withstubs was that some of them must contain the test cases and othersmust write their input to a printer or display.

However, as soon as themodule accepting the program’s input is added, the representation oftest cases is considerably simplified; their form is identical to the inputaccepted by the final program (e.g., from a transaction file or a terminal). Likewise, once the module performing the program’s output114The Art of Software Testingfunction is added, the placement of code in stub modules to writeresults of test cases might no longer be necessary. Thus, if modules Jand I are the I/O modules and if module G performs some criticalfunction, the incremental sequence might beABFJDICGEKHLand the form of the program after the sixth increment would be thatshown in Figure 5.10.Once the intermediate state in Figure 5.10 has been reached, therepresentation of test cases and the inspection of results are simplified.It has another advantage in that you have a working skeletal version ofthe program, that is, a version that performs actual input and outputoperations.

However, stubs are still simulating some of the “insides.”This early skeletal version• Allows you to find human-factor errors and problems• Allows the program to be demonstrated to the eventual user• Serves as evidence that the overall design of the program issound• Serves as a morale boosterThese points represent the major advantage of the top-down strategy.On the other hand, the top-down approach has some seriousshortcomings. Assume that our current state of testing is that of Figure 5.10 and that our next step is to replace stub H with module H.What we should do at this point (or earlier) is use the methodsdescribed earlier in this chapter to design a set of test cases for H.Note, however, that the test cases are in the form of actual programinputs to module J.

This presents several problems. First, because ofthe intervening modules between J and H (F, B, A, and D), we mightfind it impossible to represent certain test cases to module J that testevery predefined situation in H. For instance, if H is the BONUSmodule of Figure 5.2, it might be impossible, because of the natureof intervening module D, to create some of the seven test cases ofFigures 5.5 and 5.6.Module (Unit) Testing115Figure 5.10Intermediate state in the top-down test.Second, because of the “distance” between H and the point atwhich the test data enter the program, even if it were possible to testevery situation, determining what data to feed to J to test these situations in H is often a difficult mental task.Third, because the displayed output of a test might come from amodule that is a large distance away from the module being tested,correlating the displayed output to what went on in the module maybe difficult or impossible.

Consider adding module E to Figure 5.10.The results of each test case are determined by examining the outputwritten by module I, but because of the intervening modules, it maybe difficult to deduce the actual output of E (that is, the data returnedto B).The top-down strategy, depending on how it is approached, mayhave two further problems. People occasionally feel that it can beoverlapped with the program’s design phase. For instance, if you arein the process of designing the program in Figure 5.8, you might116The Art of Software Testingbelieve that after the first two levels are designed, modules A throughD can be coded and tested while the design of the lower levels progresses.

As we have emphasized elsewhere, this is usually an unwisedecision. Program design is an iterative process, meaning that whenwe are designing the lower levels of a program’s structure, we maydiscover desirable changes or improvements to the upper levels. Ifthe upper levels have already been coded and tested, the desirableimprovements will most likely be discarded, an unwise decision inthe long run.A final problem that often arises in practice is not completely testing a module before proceeding to another module. This arises fortwo reasons: because of the difficulty of embedding test data in stubmodules, and because the upper levels of a program usually provideresources to lower levels.

In Figure 5.8 we saw that testing module Amight require multiple versions of the stub for module B. In practice,there is a tendency to say, “Because this represents a lot of work, Iwon’t execute all of A’s test cases now. I’ll wait until I place moduleJ in the program, at which time the representation of test cases is easier, and remember at this point to finish testing module A.” Ofcourse, the problem here is that we may forget to test the remainderof module A at this later point in time.