Objectives: Introduction Over View of System Analysis and Design



Download 0.94 Mb.
View original pdf
Page108/140
Date13.11.2023
Size0.94 Mb.
#62581
1   ...   104   105   106   107   108   109   110   111   ...   140
ms-04
8.7.2 Specification Testing
To perform specification testing, the analyst examines the specifications stating what the program should do and how it should perform under various conditions. Then test cases are developed for each condition or combination of conditions and submitted for processing. By examining the results, the analyst can determine whether the program performs according to its specified requirements. This strategy treats the program as if it were a black box the analyst does not look into the program to study the code and is not concerned about whether every instruction or path through the program is tested. In that sense, specification testing is not complete testing. However, the assumption is that, if the program meets the specifications, it will not fail. Neither code nor specification testing strategy is ideal. However, specification testing is a more efficient strategy, since it focuses on the way software is expected to be used. It also shows once again how important the specifications developed by the analysts are throughout the entire systems development process.
8.7.3 Managing Testing Practices

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.

Download 0.94 Mb.

Share with your friends:
1   ...   104   105   106   107   108   109   110   111   ...   140




The database is protected by copyright ©ininet.org 2024
send message

    Main page