Scribd
Upload
10 views

Class 19

The document discusses different white-box testing methodologies like statement coverage, branch coverage, condition coverage, and path coverage. It then describes data flow-based testing, defining definition-use chains and how they can be used to select test paths. The document also covers mutation testing, where small deliberate changes are made to a program and tests are run to kill the mutants. Finally, it discusses using cause-and-effect graphs generated from requirements to automatically design functional test cases.

Uploaded by

vedidom615
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views

Class 19

The document discusses different white-box testing methodologies like statement coverage, branch coverage, condition coverage, and path coverage. It then describes data flow-based testing, defining definition-use chains and how they can be used to select test paths. The document also covers mutation testing, where small deliberate changes are made to a program and tests are run to kill the mutants. Finally, it discusses using cause-and-effect graphs generated from requirements to automatically design functional test cases.

Uploaded by

vedidom615
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Program Testing

1
White-Box Testing
● There exist several popular white-box
testing methodologies:
● Statement coverage
● Branch coverage
● Condition coverage
● Path coverage
● Data flow-based testing
● Mutation testing

2
Data Flow-Based Testing

● Selects test paths of a


program:
– According to the locations of
● Definitions and uses of different
variables in a program.

3
Data Flow-Based Testing

● For a statement numbered S,


– DEF(S) = {X|statement S contains a
definition of X}
– USES(S)= {X|statement S contains a use
of X}

4
DU Example
1 X(a){
2 a=5; /* Defines variable a */
3 while(C1) {
4 if (C2)
5 b=a*a; /*Uses variable a */
6 a=a-1; /* Defines & uses variable a */
7 }
8 print(a); } /*Uses variable a */

5
6
Data Flow-Based Testing

● A variable X is said to be
live at statement S1, if
–X is defined at a statement S,
and
– There exists a path from S to
S1 not containing any
definition of X.
7
Definition-use chain (DU
chain)
● [X,S,S1],
– S and S1 are statement numbers,
– X in DEF(S)
– X in USES(S1), and
– the definition of X in the statement S
is live at statement S1.

8
Data Flow-Based Testing
● One simple data flow testing
strategy:
– Every DU chain in a program be
covered at least once.
● Data flow testing strategies:
– Useful for selecting test paths of
a program containing nested if and
loop statements.

9
Data Flow-Based Testing
● 1 X(){
● 2 B1; /* Defines variable a */
● 3 While(C1) {
● 4 if (C2)
● 5 if(C4) B4; /*Uses & defines variable a */
● 6 else B5;
● 7 else if (C3) B2;
● 8 else B3; }
● 9 B6 }

10
Data Flow-Based Testing
● [a,1,5]: a DU chain.
● Assume:
– DEF(X) = {B1, B2, B3, B4, B5}
– USED(X) = {B2, B3, B4, B5, B6}
– There are 25 DU chains.

● However only 5 paths are needed to


cover these chains.

11
Mutation Testing
● The software is first tested:
– using an initial testing method based on
white-box strategies we already discussed.

● After the initial testing is complete,


– mutation testing is taken up.

● The idea behind mutation testing:


– make a few arbitrary small changes to a
program at a time.

12
Mutation Testing

● Each time the program is


changed,
– it is called a mutated program
– the change is called a mutant.

13
Mutation Testing
● A mutated program:
– tested against the full test suite of the
program.

● If there exists at least one test case in


the test suite for which:
– a mutant gives an incorrect result,
– then the mutant is said to be dead.

14
Mutation Testing
● If a mutant remains alive:
– even after all test cases have been
exhausted,
– the test suite is enhanced to kill the mutant.

● The process of generation and killing of


mutants:
– can be automated by predefining a set of
primitive changes that can be applied to the
program.

15
Mutation Testing
● The primitive changes can be:
– altering an arithmetic operator,
– changing the value of a constant,
– changing a data type, etc.

16
Mutation Testing
● A major disadvantage of
mutation testing:
– computationally very expensive,
– a large number of possible
mutants can be generated.

17
Cause and Effect Graphs
● Testing would be a lot easier:
– if we could automatically generate
test cases from requirements.
● Work done at IBM:
– Can requirements specifications be
systematically used to design
functional test cases?

18
Cause and Effect Graphs
● Examine the requirements:
– restate
them as logical relation
between inputs and outputs.
– Theresult is a Boolean graph
representing the relationships
● called a cause-effect graph.

19

You might also like