Top down Testing

Top down Testing: In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule. Advantages: - Advantageous if major flaws occur toward the top of the program. - Once the I/O functions are added, representation of test cases is easier. - Early skeletal Program allows demonstrations . Disadvantages: - Stub modules must be produced - Stub Modules are often more complicated than they first appear to be. - Before the I/O functions are added, representation of test cases in stubs can be difficult.

Bottom up testing
Bottom up testing: In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module. Advantages: - Advantageous if major flaws occur toward the bottom of the program. - Test conditions are easier to create. - Observation of test results is easier. Disadvantages: - Driver Modules must be produced. - The program as an entity does not exist until the last module is added. Stubs and Drivers It is always a good idea to develop and test software in "pieces". But, it ITSE 4205 S/W MEASURMENTS AND TESTING AREEJALMAJED 1

may seem impossible because it is hard to imagine how you can test one "piece" if the other "pieces" that it uses have not yet been developed (and vice versa). A software application is made up of a number of Units, where output of one Unit goes as an Input of another Unit. e.g. A Sales Order Printing program takes a Sales Order as an input, which is actually an output of Sales Order Creation program. Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use Stub and Driver. A Driver is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary Inputs required for the Unit and then invokes the Unit. Driver passes test cases to another piece of code. Test Harness or a test driver is supporting code and data used to provide an environment for testing part of a system in isolation. It can be called as a software module which is used to invoke a module under test and provide test inputs, control and, monitor execution, and report test results or most simplistically a line of code that calls a method and passes that method a value. For example, if you wanted to move a fighter on the game, the driver code would be moveFighter(Fighter, LocationX, LocationY); This driver code would likely be called from the main method. A white-box test case would execute this driver line of code and check "fighter.getPosition()" to make sure the player is now on the expected cell on the board. A Unit may reference another Unit in its logic. A Stub takes place of such subordinate unit during the Unit Testing. A Stub is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a Stand-in for the subordinate unit and provides the minimum required behavior for that unit. A Stub is a dummy procedure, module or unit that stands in for an unfinished portion of a system. Four basic types of Stubs for Top-Down Testing are: - Display a trace message - Display parameter value(s) ITSE 4205 S/W MEASURMENTS AND TESTING AREEJALMAJED 2

- Return a value from a table - Return table value selected by parameter A stub is a computer program which is used as a substitute for the body of a software module that is or will be defined elsewhere or a dummy component or object used to simulate the behavior of a real component until that component has been developed. For example, if the movefighter method has not been written yet, a stub such as the one below might be used temporarily which moves any player to position 1. public void moveFighter(Fighter player, int LocationX, int LocationY) {fighter.setPosition(1);} Ultimately, the dummy method would be completed with the proper program logic. However, developing the stub allows the programmer to call a method in the code being developed, even if the method does not yet have the desired behavior. Programmer needs to create such Drivers and Stubs for carrying out Unit Testing. Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question. Stubs and drivers are often viewed as throwaway code. However, they do not have to be thrown away: Stubs can be "filled in" to form the actual method. Drivers can become automated test cases. Example - For Unit Testing of Sales Order Printing program, a Driver program will have the code which will create Sales Order records using hard coded data and then call Sales Order Printing program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a Stub, which will simply return fix discount data. 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 ITSE 4205 S/W MEASURMENTS AND TESTING AREEJALMAJED 3

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.

ITSE 4205 S/W MEASURMENTS AND TESTING

AREEJALMAJED