Software Testing and Quality Assurance• Ron Patton. ppt

1
Software Testing and Quality Assurance
Dang Van Hung
College of Technology
Vietnam National University
2
Reading Materials
• Ron Patton. Software Testing, second edition, Pearson Education, 2006
• Roger S. Pressman.
Software Engineering - A practitioner’s approach, sixth
edition, McGraw-Hill Companies, 2005.
• Shari Vance Pfleeger. Software Engineering - Theory and Practice - second
edition, Pearson Education, 2001.
• Kshirasagar Naik and Priyadarshi Tripathy.
Software Testing and Quality
Assurance, Theory and Practice
. A John Wiley & Sons, Inc., Publication, 2008.
• Sommerville,
Software Engineering, 8th edition, Pearson Education Limitted,
2007. Chapters 22 and 23.
• Jeff Tian. Software Quality Engineering Testing, Quality Assurance, and
Quantifiable Improvement
, Chapters 11, 12, the IEEE Computer Society, 2005.
3
Part 1: Introduction - A global View
Topics
• Software Testing Background
• The software Development Process
• The Realities of Software Testing
4
Software Testing Background

Topics:
• How software bugs impact our lives
• What bugs are and why they occur
• Who software tester are and what they do
5
Infamous Software Error Case Studies
• Disney’s Lion King, 1994-1995
• Intel Pentium Floating-Point Division Bug, 1994
• NASA Mars Polar Lander, 1999
• Patriot Missile Defense System, 1991
• The Y2K Bug, circa 1974
• Dangerous Viewing Ahead, 2004
6
What is a Bug?
• Terms for software failures: Defect, Variance, Fault, Failure, Problem,
Inconsistency, Error, Feature, Incident, Bug, Anomaly
• Generic terms: Problem, error, bugs (those cause software failure)
•
Formal definition of Software Bug:
1. The software doesn’t do something that the product specification says it
should do
2. The software does something that the product specification says it
shouldn’t do
3. The software does something that the product specification doesn’t
mention
4. The software doesn’t do something that the product specification doesn’t
mention, but it should
5. The software is difficult to understand, hard to use, slow, or–in the software
tester’s eyes–will be viewed by the end-user as just plain not right
7

Why do Bugs Occur?
Bugs are caused by numerous reasons, but the main cause can be traced to the
specification
8
The Cost of Bugs
9
What Does a Software Tester Do?
• The goal of a software tester is to find bugs
• The goal of a software tester is to find bugs and find them as soon as possible
• The goal of a software tester is to find bugs and find them as soon as possible
and make sure they get fixed
!
10
What make a Good Software Tester?
• They are explorers
• They are trouble shooter
• They are relentless (stronger and stronger)
• They are creative
• They are perfectionists
• They exercise good judgment
• They are tactful and diplomatic
• They are persuasive
11
Example: A Square Root Program
Program SquareRoot
Var r,s,x,y: integer;
input y;
r:=o; s:=-1; x:= 0;
while r <= y do
begin

s := s + 2;
r := r + s;
x := x + 1;
end;
x:=x-1 ; output x
end
12
Example: SQRT Program with Specification
Program SquareRoot
Var r,s,x,y: integer;
input y;
{y > 0}
r:=o; s:=-1; x:= 0;
while r <= y do
begin
s := s + 2;
r := r + s;
x := x + 1;
end;
x:=x-1
{x
2
≤ y ∧ (x + 1)
2
> y} ; output x
end
13
Automatic Testing (with Spin)
Test Case Generator:
chan inpt = [0] of {short};

active proctype inputgen()
{
short i = 1;
do
:: i < 1000 -> inpt!i; i=i+1
:: else -> break
od
}
14
chan inpt = [0] of {short};
active proctype sqrt()
{
short r = 0,s = -1, x = 0;
short y;
end: do
:: inpt? y ->
r = 0; s = -1; x = 0;
do
:: r <= y -> s = s + 2; r = r + s; x = x + 1;
:: else -> break
od;
x = x-1;
assert((! (x
*
x > y)) && (y < (x+1)
*
(x+1)));
printf ("if y = %d then x = %d\n",y, x)
od
}

15
Testing Results
Full statespace search for:
never-claim - (none specified)
assertion violations +
acceptance cycles - (not selected)
invalid endstates +
State-vector 36 byte, depth reached 4641, errors: 0
4387 states, stored
0 states, matched
4387 transitions (= stored+matched)
0 atomic steps
hash conflicts: 0 (resolved)
(max size 2ˆ18 states)
1.596 memory usage (Mbyte)
16
The Software Development Process
Topics:
• What major components go into a software product
• How software progress from an idea to a final product
17
What Effort Goes into a Software Product
• Customer Requirements
• Specification
• Schedule
• Software design documents (architec-
ture, data flow diagram, state transition
diagram, flowchart, commented code)
• Test documents (test plan, test cases,
bug reports, test tools and automation)

18
The Software Development Lifecycle Models
• Big-Bang
• Code-and-Fix
• Waterfall
• Spiral
19
Big-Bang Model
• The Approach:
P eople + Money + Energy =
P erfect Sof tware or Nothing!
•
Advantages:
Simple, needs less planning, less
formal development process
•
Disadvantages:
No formal testing activities, can’t
monitor, high risk
20
Code and Fix Model
• The Approach
Informal specification → loop of code and
fix till enough-is-enough decision → Re-
lease
•
Advantages
Little planning and documentation work.
• Disadvantages
Hard to manage the testing

21
Waterfall Model
• The Approach:
Discrete phases, a review after each
phase will decide to move next or stay at
this phase till it’s ready.
•
Advantages:
Easy to test (clear requirements)
• Disadvantages:
High bugs fixing cost (bugs creep), cus-
tomer is far from this till the end
22
Spiral Model
• The Approach
Round1 (Waterfall → Prototype)
Evaluate Round1
Round2 (Waterfall → Prototype)
Loop
•
Advantages:
Easy to test, the customer is tightly
involved
• Disadvantages:
Need risk-assessments expertise
23
The Realities of Software Testing
Topics:
• Why software can never be perfect
• Why software testing isn’t just a technical problem

• The terms commonly used by software testers
24
Testing Axioms
• It’s impossible to test a program completely
– large input space
– large output space
– large state space
– large number of possible execution paths
– subjectivity of specifications
25
Testing Axioms
Large Input/State Space
int exF unction(int x, int y){
. . .
}
• Exhausted testing ⇒ try all possible combination of x and y!
26
Testing Axioms
Large number of possible execution paths
. . .
for (int i = 0; i < n; + + i){
if (a.get(i) == b.get(i))
x[i] = x[i] + 100;
else
x[i] = x[i]/2;
}
. . .
Number of paths = 2
n
N Number of paths

1 3
2 5
3 9
10 1025
20 1048577
60 1.15 E+018
27
Testing Axioms
Upper limit to total number of tests (Binder)
2
n
× (L
1
× . . . × L
X
) × (V
1
× . . . × V
Y
)
• n the number of decisions
• L
i
number of times a decision can loop
• X the number of decisions that cause loops
• V
i
the number of possible values each input variable could have
• Y the number of input variables
28

Testing Axioms
• Software testing is a risk based exercise
– need to balance cost and risk of missing
bugs
• Testing can’t prove the absence of bugs
• The more bugs you find, the more bugs there
are
• The pesticide paradox
– a system tends to build resistance to a par-
ticular testing technique
29
Testing Axioms
• Not all bugs found are fixed
• Difficult to say when a bug is a bug
– only when observed (latent otherwise)
• Product specifications are never final
• Software testers aren’t the most popular members of a project team
• Software testing is a disciplined technical profession that requires training
30
Software Testing Terms and Definitions
• Precision and accuracy
• Verification and validation (V&V)
• Quality and reliability
• Testing and quality assurance
31
What Is The V&V
• Verification: Are we building the product right? - Confirming that something
(software) meets its specification.
•
Validation: Are we building the right product? - Confirming that it meets the

user’s requirements.
• The two major V&V activities are reviews, and testing. So, testing is a part of
V& V
• Validation testing
– alpha testing: test conducted at the developer’s site by end-user
– beta testing: test conducted at the end-user site
32
Testing and Quality Assurance
• The goal of a software tester is to find bugs and find them as soon as possible
and make sure they get fixed
!
• A software quality assurance person’s main responsibility is
to create and
enforce standards and methods
to improve the development process and to
prevent bugs from ever occurring!
33
Part 2: Testing Fundamentals
Topics:
• Examining the specification
• Testing the Software with Blinders On
• Examining the code
• Testing the Software with X-Ray Classes
34
Examining The Specification
Topics:
• What is black-box and white-box testing
• How static and dynamic testing differ
• What high-level techniques can be used for reviewing a product specification
• What specific problem you should look for when reviewing product

specification in detail
35
Black-box and White-Box Testing
36
Black-box and White-Box Testing
• Black-box (functional, behavioral, data-driven)
– The software under test considered as a black-box and no knowledge of
the internal structure or how the software actually works is utilized in testing
– Testing based on inputs and respective outputs
– The size of the black box can vary from one class or component to a whole
system
• White-box (structural, logic-driven)
– Testing based on knowing the inner structure of the system and the
program logic
37
Dynamic and Static Testing
• Dynamic methods - testing - executes code
– Software testing in the traditional sense: running and using software
– Dynamic analysis methods
•
Static methods do not execute code
– Reviews, inspections, static analysis; testing the specification is black-box
static testing
– Some authors name these static testing
38
Performing a High-level Review of The
Specification
• Pretend to be the customer
• Research existing standards and guidelines
– Corporate terminology and conventions

– Industry requirements
– Government standards
– Graphical user interface
– Security standards
• Review and test similar software (things to look for include scale, complexity,
testability, quality/reliability, and security)
39
Low-level Specification Test Techniques
• Specification
attributes
check list
– Complete
– Accurate
– Precise,
– Unambiguous,
– Clear
– Consistent
– Relevant
– Feasible
– Code-free
– Testable
•
Specification Terminology Check lists
– Always, every, all, none, never (think of cases that
violate them!)
– certainly, Therefore, Clearly, Obviously, Evidently
(Don’t fall to the trap)
– Some, sometimes, often, usually, ordinarily, cus-
tomarily, most, mostly (too vague to be tested)
– Etc, and so forth, so on, such as (aren’t testable)

– Good, fast, cheap, efficient, small, stable (unquan-
tifiable, need to explain)
– Handled, processed, rejected, skipped, eliminated
(these hide some functionalities that need to be
specified)
– If then (no else) (incomplete)
40
Testing The Software with Blinders On
Topics:
• What is dynamic black box testing
• How to reduce the number of test cases by equivalence partitioning
• How to identify troublesome boundary condition
• Good data values to use to induce bugs
• How to test software states and state transitions
• How to use repetition, stress, and high loads to locate bugs
• A few secret places where bugs hide
41
Dynamic Black-box Testing: Testing The
Software While Blindfold
• Testing software without having an insight into the details of underlying code;
program is running - testing is dynamic
• Test cases are specific inputs to try, and the procedure to follow
• Test case generation techniques described here belong to the black-box
testing category, using the software requirement/specification
• These techniques are useful during functional testing where the objective is to
test whether or not an application, unit, system, or subsystem, correctly
implements the functionality as per the given requirements
42
Test-to-Pass and Test-to-Fail
• Test-to-pass to assure that the software

does what it’s specified to do in
ordinary
circumstances
• Test-to-fail is to design and run test cases
with the sole purpose of breaking the
software
Use test-to-pass to reveal bugs before you test-to-fail!
43
Equivalence Partitioning
• Selecting test cases is the single most important task for the software testers
• Equivalence classing is a mean to select test cases that divide input domain of
a program into classes of data. Equivalence Partitioning strives to define a
test case that uncovers
classes of errors to reduce the total number of test
cases that must be developed.
• Example: windows calculator.
44
Equivalence Classes Definition
Equivalence classes defined with the guidelines:
• if an input condition specifies a range, one valid and two invalid equivalence
classes are defined
• if an input condition requires a specific value, one valid and two invalid
equivalence classes are defined
• if an input condition specifies a member of a set, one valid and one invalid
equivalence classes are defined
• if an input condition is Boolean, one valid and one invalid equivalence classes
are defined
45
Data Testing
Software can be viewed as to consists of two part: the data (its domain) and the

program. Testing on the data is to check that information the user inputs, results
he receives and any interim results internal to the software are handle correctly.
Examples of data would be
1. The words you type into the word processor
2. The numbers entered into a spreadsheet
3. The number of shots you have remaining in your space game
4. The pictures printed by your photo software
5. The backup files stored on your floppy disk
6. The data being sent by your modem over the phone line
46
Data Testing II
• Boundary is the edges of software capabilities; if
the software can work on the boundary, it certainly
can work on normal condition
• Boundary conditions are special because program-
ming by its nature, is susceptible to problems at its
edges.
Types of boundary Conditions
• When you’re presented with a software test problem that involves identifying
boundaries, look for: Numeric, speed, character, location, position, size,
quantity
• And think about the following characteristics: First/Last, Min/Max, Start/Finish,
Over/Under, Empty/Full, Shortest/Longest, Slowest/Fastest, Soonest/Latest,
Largest/Smallest, Highest/Lowest, Next-to/Farthest-from
47
Testing The Boundary Edges
• Software is susceptible to bugs at the boundaries, choosing data from the
boundaries to include in the equivalence partition will help to find more bugs
• Create two equivalence partitions:
– one contains data expected to work properly (valid points inside the

boundaries)
– the other contains data expected to cause errors (invalid points outside the
boundaries)
48
Other Special Data Values
• Sub-Boundary Conditions (internal to the software, but need to be check by
the testers)
• Values Default, Empty, Blank, Null, Zero, and None
• Invalid, Wrong, Incorrect, and Garbage Data
49
State Testing I
• A software state is a condition or mode that the software can be in, the current
values of the program variables.
• Testing the Software’s Logic Flow: to traverse all paths to all states - it is
impossible for complex software. Apply equivalence partition techniques to
select states/paths.
50
State Testing II
• Creating a State Transition Map, A state transition map should show:
– Each unique state that the software can be in
– The input or condition that takes it from one state to the next
– Set conditions and produced output when a state is entered or exited
• Reducing the Number of States and Transitions to Test
• What to Specifically Test: defining test cases
51
Testing States to Fail
Find test cases that test the software to fail, examples are:
• Race Conditions and Bad Timing (e.g in multitasking OS)
• Repetition, Stress, and Load (repeated load and save, low, high conditions on
resources, etc.)

52
Other Black-Box Test Techniques
• Behave like a dumb user
• Look for bugs where you’ve already found them
• Think like a hacker
• Follow expertise, intuition and hunches
53
Examining The Code
Topics:
• The benefits of static white-box testing
• The different types of static white-box reviews
• Coding guidelines and standards
• How to generically review the code for errors
54
Static White-Box Testing: Examining The
Design and Code
• White-box (or clear-box) testing implies having access to the code, being able
to see it and review it.
• Static white-box testing is the process of carefully and methodically reviewing
the software design, architecture, or code for bugs without executing it. It’s
sometimes referred to as structural analysis.
• Benefits: finding bugs early, and those bugs difficult to uncover and isolate with
dynamic black-box testing; giving the team’s black-box tester ideas for test
cases to apply
• The unfortunate things: not always done, time-consuming, too costly, etc. Now,
more and more companies carry out white-box-testing (model checking, etc.)
55
Formal Review I
The process under which static white-box testing is performed (meetings and
inspections).

Four essential elements:
• Identify Problems
• Follow Rules (e.g. the amount of code for reviewing)
• Prepare (contributions to the review)
• Write a Report
56
Formal Review II
In addition to finding problems, holding formal reviews has a few indirect results
• Communications (e.g. to the black box testers)
• Quality (improvement of code)
• Team Camaraderie (better understanding each other’s job for testers and
programmers)
• Solutions
Formal review is the first net for catching bugs!
57
Formal Review III
• Peer Reviews (informal discussion: programmers who designed and testers)
• Walkthroughs (the programmer who wrote code presents to a small group of
4,5 programmers and testers)
• Inspections (most formal, presenters are not original programmers)
58
What Is The Characteristics of ’Peer reviews’?
• Informal.
• Audience: Owner(author) and peer(s) of similar expertise (no managers).
• It requires guidelines and checklist.
59
What Is The Characteristics of The
’Walkthrough’?
• More formal.
• Audience: 3-5 , at least 1 senior, the owner act as a reader and recorder.

• The owner should send a copy of things that need review prior to the meeting.
• Reader should write a report with the feedback and how to address it.
• 2nd meeting can be conducted to follow up.
60
What Is The Characteristics of The
’Inspection’?
• The most formal.
• Audience: typically 3-8 people including a moderator, reader, and a recorder
to take notes.
• The reader should not be the owner.
• The owner should send a copy of things that need review prior to the meeting.
• Each Inspectors should review the code for a different perspective.
• After the inspection meeting the moderator call for another meeting to discuss
the feedback and how the owner will address them.
• Require training.
61
Coding Standards and Guidelines
There are problems where the code may operate properly but may not be written
to meet a specific standard or guideline or some criteria. Three reasons for
adherence to a standard or guideline:
• Reliability: code written to a specific standard or guideline is more reliable and
secure that code that isn’t.
• Readability/Maintainability: code written to a specific standard or guideline is
easier to read and understand
• Portability: easier to move it to different platform.
62
Example of Programming Standards and
Guidelines
For main parts of the standard:
•

Title describes what topic the standard covers
•
Standard (guideline) describes the standard or guideline explaining exactly
what’s allowed and not allowed
•
Justification gives the reasoning behind the standard
•
Example show simple programming samples
63
Examples
TOPIC 3.05 Control-reduction on control structures
STANDARD
The
goto statement should not be used
The
while loop should be used instead of do-while loop.
If a single if-else can replace a continue, an if-else should be used.
JUSTIFICATION
The goto is prohibited because it is highly correlated with errors and hare-to-read
code.
64
Obtaining Standards and guidelines
Sources of reference
• American National Standards Institute (ANSI), www.ansi.org
• International Engineering Consortium (IEC), www.iso.org
• International Organization for Standardization (ISO), www.iso.ch
• National Committee for Information Technology Standards (NCITS),
www.ncits.org
• Association for Computing Machinery (ACM), www.acm.org
• Institute of Electrical and Electronics Engineers, Inc (IEEE), www.ieee.org

65
Generic Code Review Checklist
• Data Reference Errors
• Data Declaration Errors
• Computation Errors
• Comparison Errors
• Control Flow Errors
• Subroutine Parameter Errors
• Other Checks
66
Testing The Software with X-ray
Glasses
Topics:
• What dynamic white-box testing is
• The difference between debugging and dynamic white-box testing
• What unit and integration testing are
• How to test low-level functions
• The data areas that need to be tested at a low level
67
Dynamic White Box Testing
• Examining the code, and watching it as
it runs - testing the software with X-ray
glasses!
• Other name: structural testing (you can see
and use the underlying structure of the code
to design and run your tests)
• Knowing how the software operate will influence how you test!
• Four areas that dynamic white-box testing encompasses:
– Directly testing low-level functions, procedures, etc
– Testing the software at the top-level as a completed program

– Gaining access to read variables helps to determine if your tests are doing
as your thought
– measuring how much of the code you hit during running a test
68
Dynamic White-Box Testing Versus Debugging
• Both Dynamic White-Box Testing and Debugging involve dealing with software
bugs and looking at the code, but are different in their goals
• Dynamic White-Box Testing is to find bugs
• Debugging is to fix bugs
69
Testing The Pieces
• Why Testing the Pieces? It is because testing the whole with dynamic black-box
testing is very costly, and bugs are found late, and may hide each others with
the techniques
•
Unit and Integration Testing
– unit testing (or module testing) occurs at the lowest level
– after the lowest level bugs are found and fixed, units are integrated and
integration testing is performed (against the group of modules)
– the process of incremental testing continues until the entire product is
tested -
system testing
• The problem of NASA Mars Polar Lander, 1999 caused by poor integration
testing
70
V-Model and Incremental Testing
Unit and Intergration
Testing
System
Testing

Requirement
Analysis
System Design
Program Design
Coding
Acceptance
Testing
and Maintenance
Operation
71
Unit and Integration Testing
72
Unit Testing
• Unit testing (or component testing) focuses verification effort on the smallest
unit of software design - software component or module. Unit test focuses on
the internal processing logic and structure within the boundaries of a
component
• Types of components for testing: individual functions or methods within an
object, object classes that have several methods& attributes, composite
components made up of several different objects or functions
• Unit test considerations: module interface, local data structures, boundary
conditions, independent paths, error handling paths
73
Example: WeatherStation State Diagram
Shutdown Waiting
Calibrating
Testing
Transmiting
Summarising
Collecting

startup()
shutdown()
clock
donecollection
calibrate()
test()
calibration OK
transmition
reportWeather
weather summary
complete
done
test complete
Operation
State Diagram for the Object
74
Example: WeatherStation Object
WeatherStation
identifier
reportWeather()
calibrate (instruments)
test()
startup (instruments)
shutdown (instruments)
The Object
75
What to be tested?
• We need to define test cases for individual methods reportWeather, calibrate,
test, startup, shutdown (in isolation or test sequences when necessary)
• We need to test the states. We have to identify sequences of state transitions

to be tested:
Shutdown → Waiting → Shutdown
Waiting → Calibrating → Testing → Transmiting → Waiting
Waiting → Calibrating → Waiting → Summarising → Transmiting → Waiting
etc.
76
Interface Testing
Test cases
A B
C
77
Types of Interfaces
1. Parameter interfaces (data and function references are passed between
components)
2. Shared memory interfaces
3. Procedural interfaces (one component encapsulates a set of procedures that
can be called by other component)
4. Message passing interfaces (services are requested by sending messages)
78
Types of Interface Errors
1. Interface misused
2. Interface misunderstanding
3. Timing errors
79
Guidelines for Interface Testing
1. Examine the code to be tested and explicitly list each call to an external
component. Design a set of test cases where the values of the parameters to
the external components are at the extreme ands of their range
2. Where the pointers are passed across an interface, always test the interface
with null pointer parameters

3. For a procedural interface, design tests that cause the encapsulating
component to fail
4. use stress testing for message passing interfaces
5. For sharing memory interfaces of a set of components, design tests that vary
the order in which the components are activated.
80
System Testing
Two distinct phases to system testing:
1. Integration testing
2. Release testing
81
Integration Testing
• Integration testing is a systematic technique for constructing the software
architecture while at the same time conducting tests to uncover errors
associated with interfacing (to make sure components actually work together)
• Big-bang approach and incremental integration approach
• Bottom-up integration, top-down integration, and regression testing
82
Incremental Integration Testing
T5
C
D
Test sequence 1 Test sequence 2 Test sequence 3
B
A
T1
T2
T3
A
B

T1
T1
T2
T2
T3
T3
T4
A
B
C
T4
83
Data Coverage
Data is one of the two parts of Software, data includes all the variables, data
structures, input/output devices.
• Data Flow
• Sub-Boundaries
• Formulas and Equations
• Error Forcing
84
Example
A = P (1 + r/n)
nt
, where:
P = principle amount r = annual interest rate
n = number of times the t = number of years
interest is compound per year A = amount of money after time t
• n = 0? Precondition is not satisfied
• n = 0? Precondition is satisfied
• Depending on how is the function used?

85
Code Coverage
• Code is the other part Software, testing the code includes testing the
program’s states and flow.
• Code covering is to attempt to enter and exit every module, execute every line
of code, follow every logic and decision path. Code coverage include:
– Program Statement and Line Coverage
– Branch Coverage
– Condition Coverage
86
Control Flow, Data Dependency, and
Interaction Testing
Software made of interacting components - two important types of interactions:
• Interactions between execution paths
• Interactions among data items in execution
Testing the interactions:
• Control Flow Testing
• Data Flow Testing
87
Control Flow Graph (CFG)
A CFG represents the control flow of a program
• Notes: each note represents a unit of information processing - corresponds to
a state in Finite State Machines
• Links: each link represents the relation “Followed by”
• Initial/entry and final/exit nodes represent where program execution
starts/ends
• Outlinks/inlinks (incoming/outgoing edges)
• Decision, junction, and processing nodes: nodes with multiple outlinks, nodes
with multiple inlinks, and nodes with single in/outlinks - entry/exit nodes are
processing nodes

88
A Simple CFG
T
F
G2
P1
G1
C1
P2
J1
P3
C2
P4
P5
C3
G3
P6
J2
J3
P7
T F
T
F
Figure 1: a CFG
89
CFG (con’d)
• Paths (complete): a path starts from an entry node and ends up in an exit
node
• Segment: a subpath of a path
• Loops: a loop is a subpath from a node to itself

90
CFT
• Basic idea: to select paths as test cases and sensitize them by assigning
corresponding values
• CFT includes:
1. Build and verify the CFG
2. Define and select paths to cover as individual test cases based on CFG
3. Sensitize the paths or the test cases by deciding the input values
4. Plan for result checking
91
Example: a program and its CFG
L1: input(a,b,c);
L2: d:=b*b−4*a*c;
L3: if (d > 0) then
L4: r:=2
L5: else−if (d=0) then
L6: r:=1
L7: slse−if (d<0) then
L8: r:=0;
L9: output(r)
d−>0
L1−2
d=?
d=0
d<0
L4 L6 L8
J1
L9
92
Path Selection

Strategy:
1. CFG decomposition: into subgraph using the sequential concatenation and
nesting
2. Bottom-up path definition: Given G1 with M paths, and G2 with N paths.
Concatenation G = G1 ◦ G2 has M × N path, and nesting G = G1(G2) has
M + N − 1 paths (why?) (see Fig. 1)
93
Path Sensitization
• Selecting input values corresponding to selected paths
• Example: consider the CFG in Fig. 1 with C1 as x > 0, C2 as y < 100 and C3
as z = 10.
94
Loop Types
Prev
C?
T
F
B
Next
U
Prev
B
Next
C?
I
T F
for (I; C; U) do {B}
While C do {B}
95
Loop Testing: Difficulties

• The number of paths grows quickly with the number of iterations
• CFG with nested loops is very complicated, cannot test all paths
96
Loop Testing: A Heuristic Strategy
• We only need to sample only one interior point while focusing on boundary
conditions
• Bypass the loop: this test case often reveal loop initialization problems
• Going through the loop once: this test case often reveal loop initialization or
set up problems
• Going through the loop twice: this test case often reveal loop problems that
prevent loop repetitions
97
Operations on Data
Operations:
• Data definition (creation, initialization, assignment, side effects, etc – called
D-operation, it is destructive - any things stored in the data item is destroyed
after this operation)
• Data use in general computation (C-use) or in predicate (called P-use) - this
sort of use called U-operation, it is non-destructive - the data item remains the
same after this operation
Corresponding relations for Data Dependency Analysis (DDA):
• D-U relations: normal usage case
• D-D relations: overloading or making situation
• U-U relations: no effect or data dependency
• U-D relations: anti-usage (a problem in software)
98
Basics of DFT
DFT is to test the correct handling of data dependencies during program execution
Data flow is the mechanism that data are carried along during program execution.
DDA provides test cases. Data dependencies modeled by DDG (Data

Dependency Graph)
In DFT, we directly focus on the data dependencies captured in DDG instead of
computational sequences or control flow in CFT.
99
DDG
• each node represents the definition of data item (variable, constant, or
structured data structure)
• links represent the D-U relation, or “is used by”
x y
z
z:=x+y
+
100
DFT
Four steps:
• Build and verify the DDGs
• Define and select data slices to cover as individual test cases based on the
DDGs (a data slice consists of a data item, usually an output variable, with its
definition in term of other data items)
• Sensitize the data slices or the test cases by deciding the input values
• Plan for result checking