Regardless of which strategy the analyst follows, there are preferred practices to ensure that the testing is useful. The levels of tests and types of test data, combined
with testing libraries, are important aspects of the actual test process.
8.7.4 Levels of Test Systems are not designed as entire systems nor are they tested as single systems. The analyst must perform both unit and integration testing.
8.7.5 Unit Testing In unit testing the analyst tests the programs making up a system. (For this reason unit testing is sometimes called program testing) The software units in a system are the modules and routines that are assembled and integrated to perform a specific function. Ina large system, many modules at different levels are needed. Unit testing focuses first on the modules,
independently of one another, to locate errors. This enables the tester to detect errors in coding and logic that are contained within that module alone. Those resulting form the interaction between modules are initially avoided. For example, a hotel information system consists of modules to handle reservations guest check-in and checkout restaurant, room service, and miscellaneous charges convention activities and accounts receivable billing. For each, it
provides the ability to enter, change, or retrieve data and respond to inquiries or print reports. The test cases needed for unit testing should exercise each condition and option. For example, test cases are needed to determine how the system handles attempts to check-in guests who do and do not have reservations, as well as those instances involving changing the name on the reservation when a person other than the one listed arrives. Also needed are test cases for the checkout situations of paying the exact amount of the bill, only part of the bill, and more than the amount shown. Even checking out without making any payment at all must be included in a test case. If the module receives
input or generates output, test cases are also needed to test the range of values expected, including both valid and invalid data. What will happen in the hotel checkout example if a guest wishes to make a payment of Rs. 1,00,000 for an upcoming convention Are the payments and printing modules designed to handle this amount Testing for this question quickly detects existing errors. If the module is designed to perform iterations, with specific processes contained within a loop, it is advisable to execute each boundary condition 0 iteration,
iteration though the loop, and the maximum number of iterations through the loop. Of course, it is always important to examine the result of testing, but special attention should be given to these conditions. Analysts too often make the mistake of assuming that a case of 0 iteration will automatically be handled properly.
Unit testing can be performed from the bottom upstarting with the smallest and lowest – level modules and proceeding one at a time. For each module in bottom-up testing, a short program (called a driver program because it drives or runs the module) executes the module and provides the needed data, so that the module is asked to perform the way it will when embedded within the larger system. When bottom-level
modules are tested, attention turns to those on the next level that use the lower – level ones. They are tested individually and then linked with the previously examined lower – level modules.
Top-down testing, as the name implies, begins with the upper – level modules. However, since the detailed activities usually performed in lower-level routines are not provided (because those routines are not being tested, stubs are written. A stub is a module shell that can be called by the upper – level module and that, when reached properly, will return a
message to the calling module, indicating that proper interaction occurred. No attempt is made to verify the correctness of the lower-level module.
Share with your friends: