Browse Prior Art Database

Code Coverage Measurement

IP.com Disclosure Number: IPCOM000119331D
Original Publication Date: 1991-Jan-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 5 page(s) / 153K

Publishing Venue

IBM

Related People

Couper, S: AUTHOR

Abstract

A technique is described for measuring the effectiveness of testing in a software project. Tools developed to implement this technique and how it was applied are described.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Code Coverage Measurement

      A technique is described for measuring the effectiveness
of testing in a software project.  Tools developed to implement this
technique and how it was applied are described.

      A large amount of effort is devoted to testing software without
any real measures of the effectiveness of that testing. Although unit
tests should exercise all code, in practice this does not occur for
the following reasons.  No practical way of measuring and tracking
the amount of code tested exists.  Unit testing is done by the
developers who prefer to move to the next routine rather than ensure
that every possible path in the current routine works and has a test
case to verify it.  Pressure is applied to move on to the next stages
of testing to demonstrate a working system even if only a small
portion works.  Resistance to such pressure is difficult unless there
is some measurable target to reach before moving on.  Moving on too
early results in an extended development cycle and lower quality
code.  As each new stage of testing is entered, more complexity is
added and it takes longer to find problems and fix them.  Because as
many bugs as possible should be found early in the test cycle, test
phases were entered too early, resulting in longer development
cycles.  Testing was done using a black box approach which tests that
the component meets the interface specifications but does not test
all possible conditions. Areas of code are left untested and there is
no measure of test progress or quality.  Finally, after shipment
APARS are raised on problems that should be found during product
testing.

      Solution Any program can be made up of basic building blocks
shown in Fig. 1.  A process can be defined as any section of code
which has no decision points in it which can be anything from one to
hundreds of instructions.  The Decision may take many forms in many
different languages but basically WHILE's, IF's TEST's FOR's all come
down to a simple YES NO decision point. The CASE block is an
extension of the switch block. Junctions are where two or more paths
through code meet.

      To test code completely every process should be executed under
every possible set of condtions;  go down every possible path to get
to every process.  Developing this philosophy results in complex and
unmanageable tasks. As a result, the philosophy has seldom been
implemented in practical software projects.  However, if a compromise
is made and the objective set such that every process should be
executed, then the task becomes manageable.  The basis of this
technique is, therefore, to measure processes that have been executed
and, from the information gained, write additional test cases to
cover processes w...