N this chapter, we will introduce you to the fundamentals of testing: why testing is

4 . 4
S T R U C T U R E - B A S E D O R W H I T E - B O X
T E C H N I Q U E S
SYLLABUS LEARNING OBJECTIVES FOR 4 .4 STRUCTURE-
BASED OR WHITE-BOX TECHNIQUES (K4)
LO-4.4.1 Describe the concept and value of code coverage. (K2)
LO-4.4.2 Explain the concepts of statement and decision coverage, and
give reasons why these concepts can also be used at test levels
other than component testing (e.g. on business procedures at
system level). (K2)
LO-4.4.3 Write test cases from given control flows using statement and
decision test design techniques. (K3)
LO-4.4.4 Assess statement and decision coverage for completeness with
respect to defined exit criteria. (K4)
In this section we will look in detail at the concept of coverage and how it can be
used to measure some aspects of the thoroughness of testing. In order to see how
coverage actually works, we will use some code-level examples (although coverage
also applies to other levels such as business procedures). In particular, we will show
how to measure coverage of statements and decisions, and how to write test cases to
extend coverage if it is not 100%.
As mentioned, we will illustrate white-box techniques that would typically apply
at the component level of testing. At this level, white-box techniques focus on the
structure of a software component, such as statements, decisions, branches or even
distinct paths. These techniques can also be applied at the integration level. At this
level, white-box techniques can examine structures such as a call tree, which is a
diagram that shows how modules call other modules. These techniques can also be
applied at the system level. At this level, white-box techniques can examine
structures such as a menu structure, business process or web page structure.
In this section, look for the definitions of the glossary terms branch coverage,
coverage, decision coverage, statement coverage, and test coverage.
4.4.1 Using structure-based techniques to measure
coverage and design tests
Structure-based techniques serve two purposes: test coverage measurement and
structural test case design. They are often used first to assess the amount of testing
performed by tests derived from specification-based techniques, i.e. to assess cover-
age. They are then used to design additional tests with the aim of increasing the test
coverage.
Structure-based test design techniques are a good way of generating additional
test cases that are different from existing tests. They can help ensure more breadth of
testing, in the sense that test cases that achieve 100% coverage in any measure will
be exercising all parts of the software from the point of view of the items being
covered.
Coverage (test
coverage) The degree,
expressed as a percentage,
to which a specified
coverage item has been
exercised by a test suite.
Section 4 Structure-Based or White-Box Techniques 99

What is test coverage?
Test coverage measures in some specific way the amount of testing performed by a
set of tests (derived in some other way, e.g. using specification-based techniques).
Wherever we can count things and can tell whether or not each of those things has
been tested by some test, then we can measure coverage. The basic coverage
measure is
Coverage
¼
Number of coverage items exercised
Total number of coverage items
 100%
where the
‘coverage item’ is whatever we have been able to count and see whether a
test has exercised or used this item.
There is danger in using a coverage measure; 100% coverage does not mean
100% tested! Coverage techniques measure only one dimension of a multi-
dimensional concept. Two different test cases may achieve exactly the same cover-
age but the input data of one may find an error that the input data of the other
doesn
’t.
One drawback of code coverage measurement is that it measures coverage of
what has been written, i.e. the code itself; it cannot say anything about the software
that has not been written. If a specified function has not been implemented,
specification-based testing techniques will reveal this. If a function was omitted
from the specification, then experience-based techniques may find it. But structure-
based techniques can only look at a structure which is already there.
Types of coverage
Test coverage can be measured based on a number of different structural elements in
a system or component. Coverage can be measured at component-testing level,
integration-testing level or at system- or acceptance-testing levels. For example, at
system or acceptance level, the coverage items may be requirements, menu options,
screens, or typical business transactions. Other coverage measures include things
such as database structural elements (records, fields and sub-fields) and files. It is
worth checking for any new tools, as the test tool market develops quite rapidly.
At integration level, we could measure coverage of interfaces or specific inter-
actions that have been tested. The call coverage of module, object or procedure calls
can also be measured (and is supported by tools to some extent).
We can measure coverage for each of the specification-based techniques as well:
l
EP: percentage of equivalence partitions exercised (we could measure valid and
invalid partition coverage separately if this makes sense).
l
BVA: percentage of boundaries exercised (we could also separate valid and
invalid boundaries if we wished).
l
Decision tables: percentage of business rules or decision table columns tested.
l
State transition testing: there are a number of possible coverage measures:
– Percentage of states visited
– Percentage of (valid) transitions exercised (this is known as Chow’s
0-switch coverage)
– Percentage of pairs of valid transitions exercised (‘transition pairs’ or
Chow
’s 1-switch coverage) – and longer series of transitions, such as
transition triples, quadruples, etc.
– Percentage of invalid transitions exercised (from the state table).
100
Chapter 4 Test design techniques

The coverage measures for specification-based techniques would apply at which-
ever test level the technique has been used (e.g. system or component level).
When coverage is discussed by business analysts, system testers or users, it most
likely refers to the percentage of requirements that have been tested by a set of tests.
This may be measured by a tool such as a requirements management tool or a test
management tool.
However, when coverage is discussed by programmers, it most likely refers to
the coverage of code, where the structural elements can be identified using a tool,
since there is good tool support for measuring code coverage. We will cover
statement and decision coverage shortly. However, at this point, note that the word
‘coverage’ is often misused to mean, ‘How many or what percentage of tests have
been run
’. This is not what the term ‘coverage’ refers to. Coverage is the coverage of
something else by the tests. The percentage of tests run should be called ‘test
completeness
’ or something similar.
Statements and decision outcomes are both structures that can be measured in
code and there is good tool support for these coverage measures. Code coverage is
normally done in component and component integration testing
– if it is done at all.
If someone claims to have achieved code coverage, it is important to establish
exactly what elements of the code have been covered, as statement coverage (often
what is meant) is significantly weaker than decision coverage or some of the other
code-coverage measures.
How to measure coverage
For most practical purposes, coverage measurement is something that requires tool
support. However, knowledge of the steps typically taken to measure coverage is
useful in understanding the relative merits of each technique. Our example
assumes an intrusive coverage measurement tool that alters the code by inserting
instrumentation:
1
Decide on the structural element to be used, i.e. the coverage items to be counted.
2
Count the structural elements or items.
3
Instrument the code.
4
Run the tests for which coverage measurement is required.
5
Using the output from the instrumentation, determine the percentage of elements
or items exercised.
Instrumenting the code (step 3) implies inserting code alongside each structural
element in order to record when that structural element has been exercised. Deter-
mining the actual coverage measure (step 5) is then a matter of analyzing the
recorded information.
Coverage measurement of code is best done using tools (as described in Chapter
6) and there are a number of such tools on the market. These tools can help to
increase quality and productivity of testing. They increase quality by ensuring that
more structural aspects are tested, so defects on those structural paths can be found.
They increase productivity and efficiency by highlighting tests that may be redun-
dant, i.e. testing the same structure as other tests (although this is not necessarily a
bad thing, since we may find a defect testing the same structure with different data).
In common with all structure-based testing techniques, code coverage techniques
are best used on areas of software code where more thorough testing is required.
Safety-critical code, code that is vital to the correct operation of a system, and
Section 4 Structure-Based or White-Box Techniques 101

complex pieces of code are all examples of where structure-based techniques are

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: