Concepts: Top-down software testing is an incremental unit testing method which begins
by testing the top level module, and progressively adds in lower level
modules, one at a time.
The idea is simple. Begin with the highest-level module, using stubs to
stand in for any module it invokes. For the next test, add in any module
which satisfies the following rule:
In order to test a unit, you must first have tested at least one module
which calls it. (Exception: the top-level unit, which is not called by any
In other words, you've done top-down testing correctly, if you never
have to write a driver.
All the advantages listed for incremental testing apply. As well:
  • There is less overhead than with the big bang method: No drivers need to be written when top-down testing is used.
  • Top-down testing provides an early working model of the program. This model can be presented to the user for an early test of the system. Design flaws can thus be detected early and corrected. DISADVANTAGES
  • Stubs still have to be written. While automated tools do exist which ease the writing of both stubs and drivers, stub tools are harder to find. As well, stubs are difficult to write since they must simulate the setting of output parameters in a way meaningful enough to avoid introducing new errors yet simple enough to be a stub and not the real thing.
  • It is hard to farm out top-down software testing to independent testing teams. Why? Each module can only be tested after a module that invokes it has been tested. Nevertheless, top-down software testing is a popular methodology and works quite well. And it meshes well with other top-down portions of the SDLC. For example, if the programmers are writing the code in a top-down sequence, as is often the case, each module could be tested as soon as coding is complete. THE STEPS OF TOP-DOWN SOFTWARE TESTING To perform top-down software testing, follow this procedure: 1) Start with the top-level module. Create a test system consisting of the top module and stubs for all the modules it invokes (those attached below it in the structure chart). Test this system. Do not proceed until all errors have been removed. 2) Next, choose any of the modules invoked by the top module just tested. To create the next test, begin with the system you created in the last test. But replace the stub of the chosen module with the real module. As well, add in stubs for any modules invoked by the chosen one. Run this test system. If any errors occur, they will be due to the new module's internal logic or its interface with the module that invoked it. 3) Choose the next module to test. This may be another module invoked by the top module or a module invoked by the one just tested in step 2. (Guidelines for selecting a module when a number of modules are possible, are discussed below.) Replace the chosen module's stub with the real thing. Next, add in stubs for any modules invoked by the chosen one. Test this system. 4) Continue incrementally adding and testing modules following the rule for top-down testing until all modules have been tested. GUIDELINES In steps 2 and 3, the software tester could choose from a number of modules that satisfy the rules of top-down testing. The following guidelines should be applied: A) Test critical modules as soon as possible. A critical module might be an unusually complex one, one that incorporates some new technology, or one that is similar to a module that has caused problems in the past. B) Test I/0 (input/output) modules as soon as possible. The tests will be difficult to run if I/0 modules are not incorporated early into the test system. The sooner you incorporate input modules, the sooner your test will be able to handle real records. Likewise, the sooner you incorporate output modules, the sooner you will be able to easily observe the effects of your test. Examples of I/0 modules are ones which read records from a file, get input from the user, write information to disk, or print information on reports.


    Find more by search "Top-down and bottom-up design"

    Software Testing Main Page
    © January 2002