In this section, you will learn about two kinds of testing strategies: how the logic is tested (via black-box and white-box testing) and how the testing is conducted (by top-down and
Top-down testing is driven by the principle that the main logic of an application needs more testing and verification than supporting logic. Top-down approaches allow comparison of the application to functional requirements earlier than a bottom-up approach. This means that serious design flaws should surface earlier in the implementation process than with bottom-up testing.
The major drawback to top-down testing is the need for extra code, known as scaffolding, to support the stubs, partial modules, and other pieces of the application for testing. The scaffolding usually begins with job control language and the main logic
of the application. The main logic is scaffolded and tested hierarchically. First, only the critical procedures and control logic are tested.
FIGURE 17-9 Vienna Development Method (VDM) Formal Specification Language Example
For example, Figure 17-10 shows the mainline logic for Customer Maintenance. The mainline of logic is important because it will be executed every time a maintenance request is performed. Since customer creation is the most probable maintenance activity, it should be guaranteed as much as possible. Further, if creation works, it is easily modified to provide update and delete capabilities which are a subset of creation functionality. Figure 17-11 is an example of COBOL stub logic for Create Customer. These two modules would be tested first, before any other logic is verified.
When critical procedures are working, the control language and main line code for less critical procedures are added. In the example above, the stubs for updating, deleting, and querying customers would be tested second. These are tested and retested throughout development as proof that the mainline of logic for all modules works.
After stubs, the most critical logic is coded, unit
tested, and placed into integration testing upon completion. In our example, the code for Create Customer would be tested next. The 'critical' code
includes screen data entry and writing to the file.
Finally, ancillary logic, such as editing input fields,
is completed and placed into testing. In our example,
the less critical code is the actual edit and validation
processing with error messages. Thus, in top-down
testing, the entire application is developed in a skeletal form and tested. As pieces of the skeleton are
fleshed out, they are added to the test application.
Procedure Division. Main-Line. Display Cust-Maint-menu. Accept Cust-Maint-Selection. If Cust-Maint-Selection =("A" or F6) Call Create-Customer else If Cust-Maint-Selection =("U" or F7) Call Update-Customer else If Cust-Maint-Selection =("D" or F8) Call Delete-Customer else If Cust-Maint-Selection =("R" or F9) Call Query-Customer else If Cust-Maint-Selection =("E" or F3) Go to Cust-Maint-Exit else Display Selection-Err Go To Main-Line. Cust-Maint-Exit. Exit.
FIGURE 17-10 Mainline Logic for Customer
In theory, top-down testing should find critical
design errors earlier in the testing process than other
approaches. Also, in theory, top-down testing should
result in significantly improved quality of delivered
software because of the iterative nature of the tests.
Unit and integration testing are continuous. There is
no discrete integration testing, per se. When the unit/
integrated test is complete, further system tests are
conducted for volume and constraint tests.
Identification Division. Program-ID. CreateCust. Environment Division. Configuration Section. Source-Computer. IBM. Object-Computer. IBM. File Section. FD Customer-Screen ... 01 Customer-Screen-Record. ... screen description FD Customer-File ... 01 Customer-File-Record. ...customer record description Data Division. Working-Storage Section. 01 Cust-Screen. ... 01 Customer-relation. ... Procedure Division. Main-Line. Perform Display-Cust-Screen. Perform Accept-Values. Perform Edit-Validate. Perform Write-Customer. Display Continue-Msg. Accept Cust-Response. If Cust-Resp = 'yO go to main-line else go to create-customer-exit. Display-Cust-Screen. Write Cust-Screen from Customer-Screen-Record. DCS-exit. Exit. Accept-Values. AV-Exit. Exit. Edit-Validate. EV-Exit. Exit. Write-Customer. Write Customer-Relation from Customer-File-Record on error perform Cust-Backout-Err. WC-Exit. Exit. Create-Customers-Exit. Exit.
FIGURE 17-11 COBOL Stub Program for
Top-down easily supports testing of screen designs and human interface. In interactive applications, the first logic tested is usually screen navigation. This serves two purposes. First, the logic for interactive processing is exhaustively exercised by the time all code and testing is complete. Second, users can see, at an early stage, how the final application will look and feel. The users can test the navigation through screens and verify that it matches their work.
Top-down testing can also be used easily with
prototyping and iterative development. Prototyping
is iterative and follows the same logic for adding
code as top-down testing. Presenting prototyping,
iterative development, and top-down testing together
for user concurrence helps ensure that prototypes
actually get completed.