SOFTWARE TESTING METHODOLOGIES

Unit – II

Dynamic Testing –Black box testing techniques

Black box Testing:
 Black-box technique is one of the major techniques in dynamic testing for designing effective testcases.
 This technique considers only the functional requirements of the software or module.
 In other words, the structure or logic of the software is not considered. Therefore, this is also known
as functional testing.
 The software system is considered as a black box, taking no notice of its internal structure,
so it is also called as black-box testing technique.

Black-box testing attempts to find errors in the following categories:

To test the modules independently
To test the functional validity of the software so that incorrect or missing functions can be recognize
--Interface errors are detected.
To test the system behaviour and check its performance
To test the maximum load or stress on the system
To test the software such that the user/customer accepts the system witdefined acceptable limits

Various methods to test a software product using black-box techniques are

• 4.1 BOUNDARY VALUE ANALYSIS (BVA)

• 4.2 EQUIVALENCE CLASS TESTING
• 4.3 STATE TABLE-BASED TESTING
• 4.4 DECISION TABLE-BASED TESTING
• 4.5 CAUSE-EFFECT GRAPHING BASED TESTING
• 4.6 ERROR GUESSING

1. Boundary Value Analysis:

Boundary value analysis(BVA) is based on testing at the boundaries between partitions.Here we
have both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions).
BVA offers several methods to design test cases:
-->1.Boundary Value Checking
-->2.Robustness Testing Method
-->3.Worst Case Testing Method.
 For example,if A is an integer between 10 to 255, and B is an integer between the range of 10 to
100 , then different methods of using BVA are as follows:

1.Boundary Value Checking: (BVC)

Test cases are designed by holding one variable at its extreme value and other variables at their
nominal values in the input domain.
The variable at its extreme value can be selected at:

--Minimum value (Min)

--Value just above the minimum value (Min+ )
--Maximum value (Max)
--Value just below the maximum value (Max-)

Anom, Bmin
Anom, Bmin+
Anom, Bmax
Anom, Bmax-
Amin, Bnom
Amin+, Bnom
Amax, Bnom
Amax-, Bnom
Anom, Bnom

It can be generalized that for n variables in a module, 4n + 1 test cases can be designed with boundary value
Checking method.
Ex:

2. Robustness Testing Method: In this method, we are going to add another values to the
Boundary Chec king Values, they are:
--A value just greater than the Maximum value (Max+)
--A value just less than Minimum value (Min-)
When test cases are designed considering above points in addition to BVC, it is called Robustness
testing.
Amax+, Bnom
Amin-, Bnom
Anom, Bmax+
Anom, Bmin-

It can be generalized that for n input variables in a module, 6n + 1 test cases can be designed with robustness testing
3.Worst Case Testing Method:
We can again extend the concept of BVC by assuming more than one variable on the boundary. It is
called Worst Case testing method:
two variables, A and B. We can add the following test cases to the list of 9 test cases designed in BVC as:

It can be generalized that for n input variables in a module, 5n test cases can be designed with worst-case testing

Example 1:
A program reads an integer number within the range [1,100] and determines whether the number is
a prime number or not. Design all test cases for this program using BVC, Robust testing and worst-
case testing methods:

1: Test cases using BVC

n=1
no of test cases=4n+1
=4*1+1
=5

2: Test cases using Robust Testing method:

No of test cases:6n+1
=6*1+1
=7
Example-2
 Equivalance Class Testing:
Equivalence class partitioning is a specification-based or black-box technique. It can be applied at
any level of testing and is often a good technique to use first.
----The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups
or sets that can be considered the same(i.e. the system should handle them equivalently), hence
‘equivalence class partitioning’.

In equivalence-partitioning technique we need to test only one condition from each partition.
This is because we are assuming that all the conditions in one partition will be treated in the same
way by the software.
Ex:

If one condition in a partition works, we assume all of the conditions in that partition will work, and
so there is little point in testing any of these others.

Equivalence partitioning method for designing test cases has the following goals:

Completeness Without executing all the test cases, we strive to touch the completeness of testing domain.
Non-redundancy When the test cases are executed having inputs from the same class, then there is
redundancy in executing the test cases.
Time and resources are wasted in executing these redundant test cases, as they explore the same type of bug.
Thus, the goal of equivalence partitioning method is to reduce these redundant test cases.
To use equivalence partitioning, one needs to perform two steps:
1. Identify equivalence classes
2. Design test cases
Identification of Equivalent Classes:
Fig: Equivalence classes

 Different equivalent classes are formed by grouping inputs for which the behaviour
pattern of themodule is similar.
 The rationale for forming Equivalence classes like this is the assumption that if the
specifications requiress exactly the same behaviour for each element in a class of values.

Twotypes of classes can always be identified:

--Valid Equivalence class: The classes consider valid inputs to the programs.
--Invalid Equivalence class: The other class contains invalid inputs that will generate error
conditions or unexpected behaviour of the program.
Identifying the Test Cases:
--Assign a unique identification number to each Equivalence class.
--Write a new test case covering as many of the uncovered valid Equivalence class as possible,
until all valid Equivalence classes have been covered by test cases.
--Write a test case that covers one, and only one, of the uncovered invalid Equivalence classes
untilall invalid Equivalence classes have been covered by test case.
Ex:
 Example 1: A program reads three numbers A, B and C with range [1,50] and prints largest
number. Design all test cases for this program using equivalence class testing technique. Example
test casesare:
I1 = {<A,B,C> : 1 ≤ A ≤ 50}
I2 = {<A,B,C> : 1 ≤ B ≤ 50}
I3 = {<A,B,C> : 1 ≤ C ≤ 50}
I4 = {<A,B,C> : A < 1}
I5 = {<A,B,C> : A > 50}
I6 = {<A,B,C> : B < 1}
I7 = {<A,B,C> : B > 50}
I8 = {<A,B,C> : C < 1}
I9 = {<A,B,C> : C > 50}

Example 2:

A program determines the next date in the calendar. Its input is entered in the
form of <ddmmyyyy> with the following range:
1 ≤ mm ≤ 12
1 ≤ dd ≤ 31
1900 ≤ yyyy ≤ 2025
Its output would be the next date or an error message ‘invalid date.’ Design
test cases using equivalence class partitioning method.
 State Table Based Testing:
Tables are useful tools for representing and documenting many types of information relating to test
case design.
These are beneficial for the applications which can be described using state transition diagrams
and state tables.
Finite State Machine (FSM):
An FSM is a behavioural model whose outcome depends upon both previous and current inputs.
FSM model can be prepared for software structure or software behaviour. And it can be used as a
tool for functional testing.
State transition diagrams or State Graph:
A system or its components may have a number of states depending on its input and time.
For example, a task in an operating system can have the following states:
1. New State: When a task is newly created.
2. Ready: When the task is waiting in the ready queue for its turn.
3. Running: When instructions of the task are being executed by CPU.
4. Waiting: When the task is waiting for an I/O event or reception of a signal.
5. Terminated: The task has finished execution
States are represented by nodes
when one state is changed to another, it is called a transition
Transitions are represented by links that join the nodes.
State graph consists of:
• State: a condition in which a system is waiting for events
• Event: Input that may cause a transition
• Transition: Change from one state to another as result of event
• Action: operation initiated by transition

• Each arrow link provides two types of information:

• 1. Transition events like admitted, dispatch, interrupt, etc.
• 2. The resulting output from a state like T1, T2, T3, etc.
• T0 = Task is in new state and waiting for admission to ready queue
• T1 = A new task admitted to ready queue
• T2 = A ready task has started running
• T3 = Running task has been interrupted
 • T4 = Running task is waiting for I/O or event
• T5 = Wait period of waiting task is over
• T6 = Task has completed execution

State Table:
State graphs of larger systems may not be easy to understand. Therefore, state graphs are converted
into tabular form for convenience sake, which are known as state tables.
State table also specify inputs, transitions and outputs.
The following conventions are used for state table:
--Each row of the table corresponds to a state.
--Each column corresponds to an input condition

--The box at the intersection of a row and a column specifies the next state (transition) and the
output.

The highlighted cells of the table are valid inputs causing a change of state.
Other cells are invalid inputs

• Test cases are produced in a tabular form known as the test case table which contains six columns
• Test case ID : a unique identifi er for each test case
• Test Source : a trace back to the corresponding cell in the state table
• Current State : the initial condition to run the test
• Event : the input triggered by the user
• Output : the current value returned
• Next State : the new state achieved
 State Table Based Testing:
The procedure for converting state graphs and state tables into test cases is:
• 1. Identify the states
• 2. Prepare state transition diagram after understanding transitions between states
• 3. Convert the state graph into the state table
• 4. Analyse the state table for its completeness
• 5. Create the corresponding test cases from the state table
.

Example for state table based testing:

Let’s consider an ATM system function where if the user enters the invalid password
three times the account will be locked
Decision Table Based Testing:
Boundary Value Analysis and Equivalence class partitioning methods do not consider
combinationsof input conditions.
These methods consider the inputs separately.
Decision Table is another useful method to represent the information in a tabular method. It has the
speciality to consider complex combinations of input conditions and resulting actions.
Each operand or variable in a logical expression takes on the value, TRUE or FALSE.
Formation of Decision Table:

A decision table is formed with the following components:

Condition Stub: It is a list of input conditions for which the complex combination is made.
Action Stub: It is a list resulting actions which will be performed if a combination of input
condition is satisfied.
Condition entry: It is a specific entry in the table corresponding to input conditions mentioned in
the condition stub.
• When we enter TRUE or FALSE for all input conditions for a particular combination, then it is
called a Rule.
• a rule defines which combination of conditions produces the resulting action.
• When the condition entry takes only two values—TRUE or FALSE,then it is called Limited
Entry Decision Table
• When the condition entry takes several values, then it is called Extended Entry Decision
Table.
• In limited entry decision table, condition entry, which has no effect whether it is True or False,
is called a Don’t-Care state or immaterial state (represented by I).
•
Action Entry: It is the entry in the table for the resulting action to be performed when one rule
issatisfied.
‘X’ denotes the action entry in the table.
• The guidelines to develop a decision table for a problem
• List all actions that can be associated with a specific procedure (or module).
• List all conditions (or decision made) during execution of the procedure.
 • Associate specific sets of conditions with specific actions, eliminating impossible
combinations of conditions; alternatively, develop every possible permutation of conditions.
Define rules by indicating what action occurs for a set of conditions
Test Case Design using Decision Table:
For Designing test cases from a decision table, following interpretations should be done:
--Interpret condition stubs as the inputs for the test case.
--Interpret action stubs as the expected output for the test case.
--Rule, which is the combination of input conditions, becomes the test case itself.
If there are k rules over n binary conditions, there are at least k test cases and at the most
2 power n test cases.
Example:1
A program calculates the total salary of an employee with the conditions that if the working hours
are less than or equal to 48, then give normal salary. The hours over 48 on normal working days are
calculated at the rate of 1.25 of the salary. However, on holidays or Sundays, the hours are
calculated at the rate of 2.00 times of the salary. Design the test cases using decision table testing.

Example 2:
Example 3:
EXPANDING THE IMMATERIAL CASES IN DECISION TABLE :

• Immaterial cases (I) have been shown in the decision table which are don’tcare conditions.
• These conditions mean that the value of a particular condition in the specific rule does not make a difference
whether it is TRUE or FALSE.
• However, we should always test both the values of a don’t-care condition.
• So the rules in the table can be expanded
• Sometimes expanding the decision table to spell out don’t-care conditions can reveal hidden problems.
Cause Effect Graphing Based Testing:
 Cause and effect graph is a dynamic test case writing technique.
 Here causes are the input conditions and effects are the results of those input conditions.
 Cause-Effect Graphing is a technique which starts with set of requirements and determines
the minimum possible test cases formaximum test coverage .
 The goal is to reduce the total number of test cases still achieving the desired application
quality.
 Disadvantage: It takes time to model all your requirements into this cause-effect
graph beforewriting test cases.

The following process is used to derive the test cases:

Division of specification: The specification is divided into workable pieces, as cause-effect

graphingbecomes complex when used on large specifications.

Identification of causes and effects: A cause is a distinct input condition identified in the problem.

Transformation of specification into a cause-effect graph: Based on the analysis of the

specificationit is transformed into a boolean graph linking the causes and effects. This is the cause-
effect graph.

Converison into decision table: The cause-effect graph obtained is converted into a limited entry
decision table by verifying state conditions in the graph.

Deriving test cases: The columns in the decision table are converted into tst cases.

Basic Notations of Cause-Effect Graph:

The operations are: AND, NOT, OR, AND, Exclusive (only one value can be 1), Inclusive (atleast x
or y or z value must always be 1), Requires (if x to be 1, y must be 1), Mask (if x is 1 it forces y to
be 0)

Example:
• Design test cases for the following problem-
• If the character of the first column is ‘A’ or ‘B’ and the second column is a number, then the
file is considered updated. If the first character is erroneous, then message x should be printed.
If the second column is not a number, then message y should be printed.
•
• Step-01:
•
• Identify and describe the input conditions (causes) and actions (effect).
• The causes represented by letter “C” are as follows-
• C1 : The character in column 1 is ‘A’
• C2 : The character in column 1 is ‘B’
• C3 : The character in column 2 is a number
•
• The effects represented by letter “e” are as follows-
• e1 : File update (C1 OR C2) AND C3
• e2 : Message X is printed (NOT C1 AND NOT C2)
• e3 : Message Y is printed (NOT C3)

• Step-02:

• Build up a cause-effect graph-

• Step-03:
•
• Convert cause-effect graph into a decision table-

EXAMPLE 2:
 Error Guessing:
 Error Guessing is the preferred method when all the other methods fail.
 It is a very practical case wherein the tester uses his intuition and makes a guess about
where the bug can be.
 The tester does not have to use any particular testing technique.
 The basic idea is to make a list of possible errors inerror prone situations and then develop
the test cases.
 Thus there is no general procedure for this technique as it is largely an intuitive and ad-hoc
process.
 For example:
 Suppose you are testing a login page for a application and you are asked to identify any possible errors that may
occur during the login process. By error guessing technique, you might consider the following scenarios Entering
an invalid username and password combination
 Entering a valid username but an incorrect password
 Attempting to login with a username or password that exceeds the maximum character limit
 Attempting to login with a username or password that does not meet the required complexity criteria
 Entering a valid username and password but with the caps lock key on
 Attempting to login without entering any credentials
 Attempting to login with special characters in the username or password field

 --By considering these scenarios, you can identify potential errors

Some common areas of error guessing:


 Divide by zero
 Null pointer exception
 Entering blank spaces in the text fields
 Pressing the submit button without entering values.
 Uploading files exceeding maximum limits.
 Invalid parameters
 Refresh buttons
 

Benefits/Advantages of Error Guessing technique:


 Effective when used in combination with other formal testing techniques.
 Reveals those defects which would otherwise not be possible to find out, through formal
testing.
 Saves a lot of time and effort.
 Helps in error guessing of complex and problematic areas of the application

Dynamic Testing:White –Box Testing Techniques

White-box testing is another effective testing technique in dynamic testing.

It is also known as glass-box testing. Often, developers use white-box testing techniques
to test their own design and code.
This testing is also known as structural or development testing.
Need:
--White box testing (WBT) is also called Structural or Glass box testing.
--White box testing involves looking at the structure of the code.
--We need WBT to ensure:
-->That all independent paths within a module have been exercised at least once.
-->All logical decisions verified on their true and false values.
-->All loops executed at their boundaries and within their operational bounds internal data
structures validity.

Logic Coverage Criteria:

Structural or White-Box Testing considers the program code and test cases are designed based
on the logic of the program such that every element of the logic is covered. Therefore the intention in
WTB is to cover the whole logic. Different forms of logic coverage are:
--Statement Coverage
--Decision or Branch Coverage
--Condition Coverage
--Decision / Condition Coverage
--Multiple condition Coverage
 Example:
scanf(“%d%d”,&x,&y);while(x!=y)
{
if(x>y)
x=x-y;
else
y=y-x;
}
printf(“x=%d y=%d”,x,y);

Statement Coverage:
It is assumed that if all the statements of the module are executed once, every bug will be
notified. If we want to cover every statement in the above code, then the following test cases must be
designed:
Test case 1: x = y = n, where n is any number
Test case 2: x = n, y = n’, where n and n’ are different numbers.Test
case 3: x>y
Test case 4: x<y
These test cases will cover every statement in the code segment, however
statement coverage is a poor criteria for logic coverage. We can see that test
case 3 and 4 are sufficient to execute all the statements in the code. But, if
we execute only test case 3 and 4, then conditions and paths in test case 1
will never be tested and errors will go undetected. Thus, statement coverage is a
necessary but not a sufficient criteria for logic coverage
 Decision or Branch Coverage:
Branch Coverage states that each decision takes on all possible outcomes. In other words each
branch direction must be traversed atleast once. The different test cases that can be designed are:
Test case 1: x = y Test case 3: x < y
Test case 2: x != y Test case 4: x > y
Condition Coverage:
It states that each condition in a decision takes on all possible outcomes at least once. For
example consider the following statement: while((I<5) && (J<COUNT))
The different test cases are:
Test case 1: I <= 5, J < COUNTTest
case 2: I > 5, J > COUNT

Decision / Condition Coverage:

If the decision If (A && B) is being tested, then the test cases would be like:
Test Case 1: A is True, B is False.
Test Case 2: A is False, B is True.

Multiple condition Coverage:

In case of multiple conditions, for the statement If (A && B) the test cases would be:

Test Case 1: A = TRUE, B = TRUE Test

Case 2: A = TRUE, B = FALSE Test
Case 3: A = FALSE, B = TRUE Test
Case 4: A = FALSE, B = FALSE

Basis Path Testing:

Basis Path Testing (BPT) is the oldest structural testing technique . The technique is based on the
control structure of the program. Based on the control structure, a flow graph is prepared and all the
possible paths can be covered and executed during testing. The guidelines for effective path testing are:
--Path Testing is based on control structure of the program for which flow graph is prepared.
--It requires complete knowledge of the program’s structure.
--It is closer to the developer and used by him to test his module.
--The effectiveness of path testing is reduced with the increase in size of software under test.
--Choose enough paths in a program such that maximum logic coverage is achieved.

Control Flow Graph:

The control flow graph is a graphical representation of control structure of a program. Flow graph can be
prepared as a directed graph. A Directed graph (V,E) consists of set of vertices V and edges
E.
Flow graph notations are:
--Node: represents one or more procedural statements,
---Edges or links: represent the flow of control in a program,
---Decision Node: A node with more than one arrow leaving it is called a decision node.
--Junction node :A node with more than one arrow entering it is called junction node
--Regions: Areas bounded by edges and nodes

Flow Graph Notations for Different Programming Constructs:

Flow graph is also known as

Decision to Decision (D&D) graph.

Path Testing Terminology:

Path: A path through a program is a sequence of instructions or statements that starts at an entry,junction,
or decision and ends at another or possibly the same junction, decision or exit.

Segment: Path consists of segments. The smallest segment is a link, that is, a single process thatlies
between two nodes.
Path Segment: A path segment is a succession of consecutive links that belongs to some path.

Length of a Path: The length of a path is measured by the number of links in it and not by the
number of instructions or statements executed along the path.

Independent Path: An independent path is any path through the graph that introduces at least one new
set of processing statements or new conditions.

Cyclomatic Complexity:
--It provides a quantitative measure of the logical complexity of a program
--Defines the number of independent paths in the basis set
--Provides an upper bound for the number of tests that must be conducted to ensure all statements
have been executed at least once
--Can be computed three ways
-->The number of regions
-->V(G) = E – N + 2, E is the number of edges and N is the number of nodes in graph G
-->V(G) = P + 1, where P is the number of predicate nodes in the flow graph G

Guidelines for Basis Path Testing:

-- Draw the flow graph using the code provided for which we have to write test cases.
--Determine the cyclomatic complexity of the flow graph.
--Cyclomatic complexity provides the number of independent paths.
--Based on every independent path, choose the data such that this path is executed.
 Cyclomatic Complexity is:
-->V(G) = e – n + 2
= 10 – 8 +2
= 4
-->V(G) = Number of predicate nodes + 1
= 3 (Nodes B,C and F) + 1
= 4

-->V(G) = No. of Regions

= 4 (R1, R2, R3, R4)
• (c) Independent paths
• Since the cyclomatic
complexity of the graph is
4, there will be 4
independent
• paths in the graph as shown
 below:
• (i) A-B-F-H
• (ii) A-B-F-G-H
• (iii) A-B-C-E-B-F-G-H
(iv) A-B-C-D-F-H

Applications of path testing:

--Through testing / More coverage: Path testing provides us the best code coverage,
leading to a thorough testing because the basis path set provides us the number of test cases to be covered which ascertains the
number of test cases that must be executed for full coverage.
--Unit testing
--Integration testing
--Maintenance testing
--Testing effort is proportional to complexity of the software.
--Basis path testing effort is concentrated on error-prone software

Graph Matrices:
Flow graph is an effective aid in path testing. However, path tracing with the use of flow
graphs may be a cubersome and time consuming activity.
Graph Matrix ,a data structure is thesolution which can assist in developing a tool for automation of
path tracing.

Graph Matrix:
A Graph Matrix is a square matrix whose size is equal to the number of nodes on the flow
graph. Each row and column corresponds to an identified node, and matrix entries correspond to
connections between nodes.
The following points describe a graph matrix:
--Each cell in the matrix can be a direct connection or link between one node to another node.
--If there is a connection from node ‘a’ to node ‘b’, then it does not mean that there is connection
from node ‘b’ to node ‘a’.
--Conventionally, to represent a graph matrix, digits are used for nodes and letter symbols for edges or
connections
Connection Matrix:
If we add link weights to each cell entry, then graph matrix can be used as a powerful tool in testing.
The links between two nodes are assigned a link weight which becomes the entry in the cellof matrix.
The link weight provides information about control flow. when the connection exists, then the link
weight is 1, otherwise 0.
A matrix defined with link weights is called a connection matrix.
USE OF CONNECTION MATRIX IN FINDING CYCLOMATIC
COMPLEXITY NUMBER
Connection matrix is used to see the control flow of the program. Further, it
is used to find the cyclomatic complexity number of the flow graph. Given
below is the procedure to find the cyclomatic number from the connection
matrix:
Step 1: For each row, count the number of 1s and write it in front of that
row.
Step 2: Subtract 1 from that count. Ignore the blank rows, if any.
Step 3: Add the final count of each row.
Step 4: Add 1 to the sum calculated in Step 3.
Step 5: The final sum in Step 4 is the cyclomatic number of the graph.
Loop Testing:

If loops are not tested properly, bugs can go undetected.

Loop testing can be done effectively whileperforming unit testing by the developer.
Different kinds of loops available for testing are:
• There are four different kinds of loops
• Types of loop Tested
• Examples of types of loop tested are,
• Simple loop
• Nested loop
• Concatenated loop
• Unstructured loop

Simple loops:

• whether the condition is true or not.

• Example
• while(condition) {
• statement(s);
 • }

The following test cases should be considered for simple loops while testing them:
--> Check whether the loop control variable is negative.
--> Write one test case that executes the statements inside the loop.
--> Write test cases for a typical number of iterations through the loop.
--> Write test cases for checking the boundary values of maximum and minimum number of iterations
defined (say min and max) in the loop. It means we should test for the min, min+1, min-1,max-1, max
and max+1 number of iterations through the loop.

Nested loops
• When two or more loops are embedded, it is called a nested loop,

Example
• while(condition 1) {
• while(condition 2) {
• statement(s);
}
}

If we have nested loops in the program it is difficult to test.

If we adopt the approach of simple teststo test the nested loops, then the number of possible test cases
grow geometrically.
Thus the strategyis to start with the innermost loops while holding outer loops to their minimum values.
Continue this outward in this manner until all loops have been covered
 Concatenated loops:
Two loops are concatenated if it is possible to reach one after exiting the other while still on a path
from entry to exit.
If two loops are not on the same path, then they are not concatenated.
• If two loops are independent of one other, they are either tested as simple loops or
 If dependent tested as nested loops in concatenated loops

• Example
• while(condition 1) {
• statement(s);
• }
• while(condition 2) {
• statement(s);
• }

Unstructured loops
• The combination of nested and concatenated loops is known as an unstructured loop.
• Example
while(){
for()
{}
while()
{}
}

This type of loops is really impractical to test and they

must be redesigned or at least converted into simple or concatenated loops.

Data flow Testing:

Data Flow Testing is a white-box testing technique that can be used to detect improper useof
data values due to coding errors.
Errors may be unintentionally introduced in a program by programmers. For instance:
--A programmer might use a variable without defining it.
--He may define a variable but not initialize it.

Example: int a; if (a==100) { }

In this way, data flow testing gives a chance to look out of inappropriate data definition, its use
in predicates, computations and termination. It defies potential bugs by examining the patterns in
which that a piece of data is used.

State of a Data Object: A data object can be in the following state:

--Defined(d:) A data object is called defined when it is initialized.
--Killed / Undefined / Released (k): When the data has been reinitialized of the scope of a loop
control variable is finished.
--Usage (u): When the data object is on the right side of assignment or used as a control variable in a
loop. In general, we say that the usage is either computational use (c-use) or predicate use (p-use).

Data Flow Anomalies:

Data flow anomalies represent the patterns of data usage which may lead to an incorrect execution of
the code. An anomaly is denoted by a two character sequence of actions.

In addition to the above two character data anomalies, there may be a single character data
anomalies. To represent these types of anomalies, we take the following conventions:
~x: indicates all prior actions are not of interest to x.x~:
indicates all post actions are not of interest to x.

All single-character data anomalies are listed below:

 Terminology used in Data Flow Testing:
-->Definition Node: Input statements, Assignment statements, Loop control statements, Procedure
calls, etc.
-->Usage Node: Output statements, Assignment statements (Right), Conditional statements, Loop
control statements, etc.
-->Loop Free Path Segment: It is a path segment for which every node is visited once at most.
-->Simple Path Segment: It is a path segment in which at most one node is visited twice.
-->Definition-Use Path (du-path):A du-path with respect to a variable v is a path between
definition node and usage node of that variable. Usage node can be p-usage or c-usage node.
-->Definition-Clear path(dc-path): A dc-path with respect to a variable v is a path between definition
node and usage node such that no other node in the path is a defining node of variable v.

Static Flow Testing: With static analysis, the source code is analysed without executing it. Let us
consider an example of an application given below:
 Example:
main()
{
int a=10,b=10,c; c=a+b;
printf(“Value=%d”,c);
}
For Variable 'a':
Pattern Line Number Explanation
-d 3 Normal Case: Allowed
du 3-4 Normal Case: Allowed
uk 4 Normal Case: Allowed

For variable 'c':

Pattern Line Number Explanation

-d 3 Normal Case: Allowed
du 3-4 Normal Case: Allowed
uk 5 Normal Case: Allowed
It is not always possible to determine the state of a data variable by just static analysis of the code. For
example, if the data variable in an array is used as an index for a collection of data elements, wecannot
determine its state by static analysis.

Dynamic Data Flow Testing:

Dynamic data flow testing is performed with the intention to uncover possible bugs in data usage
during execution of the code. Various strategies are employed for the creation of test cases.All these test
strategies are defined below:
-->All-du Paths (ADUP): IT states that every du path from every definition of every variable toevery
use of that definition should be excercised under some test.
-->All-uses (AU): This states that for every use of the variable, there is a path from the definition ofthat
variable to the use.
-->All-p-uses / Some-c-uses (APU + C): This strategy states that for every variable and every
definition of that variable, include at least one dc- path from the definition to every predicate use.
-->All-c-uses / Some-p-uses (ACU + P): This strategy states that for every variable and every
definition of that variable, include at least one dc- path from the definition to every computationaluse.
-->All-Predicate-Uses(APU): It is derived from the the APU+C strategy and states that for every
variable there is a path from every definition to every p-use of that definition.
-->All-Computational-Uses(ACU): It is derived from the the ACU+P strategy and states that forevery
variable there is a path from every definition to every c-use of that definition.
-->All-Definition (AD): It states that every definition of every variable should be covered by atleast one
use of that variable.
 • While selecting a test case, we need to analyse the relative strengths of various
data flow testing strategies
---the relative strength of testing strategies r
• It means that all-du-paths (ADPU) is the
• strongest criterion for selecting the test cases educes along the direction of the arrow.

Mutation Testing
Mutation testing is the process of mutating some segment of code(putting some error in the code) and
then testing this mutated code with some test data.
If the test data is able to detect the mutationsin the code. Mutation testing helps a user create test data
by interacting with the user to iteratively strengthen the quality of test data.
During mutation testing, faults are introduced into a program by creating many versions of the
program, each of which contains one fault.
Test data are used to execute these faulty programs with the goal of causing each faulty program to fail.

Faulty programs are called mutants of the original program and a mutant is said to be killed when atest
case causes it to fail. When this happens, the mutant is considered dead
 Primary Mutants:
When the mutants are single they are called as primary Mutants. Mutation operators are
dependent on programming languages.

Example: if(a>b)
x = x+y;else
x=x-y;
printf(“%d”,x);

Example mutants are:

M1: x = x – y; M2: x = x / y; M3: x = x+1; M4:printf(“%d”,y);

Results of initial program and mutants are shown below

Secondary Mutants:
This class of mutants is called secondary mutants when multiple levels of
mutation are applied on the initial program. In this case, it is very difficult to
identify the initial program from its mutants.

Example: if(a<b)
c=a;M1:
if(a<=b-1)
c=a;

M2: if(a+1 <=b)

c=a;

M3: if(a==b)
c=a+1;
 MUTATION TESTING PROCESS
The mutation testing process is

--Construct the mutants of a test program.

--Add test cases to the mutation system and check the output of the program
on each test case to see if it is correct.
If the output is incorrect, a fault has been found and the program must
be modified and the process restarted.
--If the output is correct, that test case is executed against each live
mutant.
--If the output of a mutant differs from that of the original program on the
same test case, the mutant is assumed to be incorrect and is killed.
--After each test case has been executed against each live mutant, each
remaining mutant falls into one of the following two categories.
 One, the mutant is functionally equivalent to the original program.
An equivalent mutant always produces the same output as the
original program, so no test case can kill it.
 Two, the mutant is killable, but the set of test cases is insufficient to
kill it. In this case, new test cases need to be created, and the process
iterates until the test set is strong enough to satisfy the tester.
The mutation score for a set of test data is the percentage of non-equivalent
mutants killed by that data. If the mutation score is 100%, then the
test data is called mutation-adequate.