Page 283 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 14: Flow Based Testing Process

Among the more common errors in computation are: Notes
1. Misunderstood or incorrect arithmetic precedence,
2. Mixed mode operations,

3. Incorrect initialization,
4. Precision inaccuracy, and

5. Incorrect symbolic representation of an expression.
Comparison and control flow are closely coupled to one another (i.e., change of flow frequently
occurs after a comparison.) Test cases should uncover errors such as:

1. Comparison of different data types,
2. Incorrect logical operators or precedence,
3. Expectation of equality when precision error makes equality unlikely,

4. Incorrect comparison of variables,
5. Improper or nonexistent loop termination,
6. Failure to exit when divergent iteration is encountered, and

7. Improperly modified loop variables.
Good design dictates that error conditions be anticipated and error handling set up to reroute
or cleanly terminate processing when an error does occur. Your done calls this approach anti
bugging. Unfortunately, there is a tendency to error handling into software and then never test
it. A true story may serve to illustrate:
Unit Test Procedures
Unit testing is normally considered as an adjunct to the coding step. After basis level code has
been developed, reviewed, and verified for correspondence to component level design, unit
test case design begins. A review of design information provides because a component is not
a stand-alone program, driver and/or stub software must be developed for each unit test. The
unit test environment is illustrated. In most applications a driver is nothing more than a “main
program” that accepts test case data, passes such data to the component (to be tested), and prints
relevant results. Stubs serve to replace modules that are subordinate (called by) the component
to be tested. A stub or “dummy subprogram” uses the subordinate module’s interface, may
do minimal data manipulation, prints verification of entry, and returns control to the module
undergoing testing.
Drivers and stubs represent overhead. That is, both are software that must be written (formal
design is not commonly applied) but that is not delivered with the final software product.
If drivers and stubs are kept simple, actual overhead is relatively low. Unfortunately, many
components cannot be adequately unit tested with “simple” overhead software. In such cases,
complete testing can be postponed until the integration test step.
14.1.2 Integration Testing

A neophyte in the software world might ask a seemingly legitimate question modules have been
unit tested: “If they all work individually, why do you doubt they will work when we put them
a together?” The problem, of course, is “putting together”-interfacing. Data can be lost across an
interface; one module can have an inadvertent, adverse affect on another; sub functions, when
combined, May not duce the desired major function; individually acceptable imprecision may
be fined to unacceptable levels; global data structures can present problems.

LOVELY PROFESSIONAL UNIVERSITY 277