PANIMALAR ENGINEERING COLLEGE

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

IT6004-SOFTWARE TESTING (2013 Regulation)
UNIT II TEST CASE DESIGN
Test case Design Strategies – Using Black Box Approach to Test Case Design –
Random Testing Requirements based testing – Boundary Value Analysis –
Equivalence Class Partitioning – State based testing – Cause-effect graphing –
Compatibility testing – user documentation testing – domain testing – Using
White Box Approach to Test design – Test Adequacy Criteria – static testing vs.
structural testing – code functional testing – Coverage and Control Flow Graphs
– Covering Code Logic – Paths – code complexity testing – Evaluating Test
Adequacy Criteria

Introduction to Testing Design Strategies

• Where do we begin to learn more about testing ?
• What areas of testing are important?
• Which topics need to be addressed first?
Ans: Testing Maturity Model
• a learning tools ,or framework to learn about testing.
• Introduces both the technical and managerial aspects of testing
• Evolve testing process both in the personal and organizational levels

1
 Each Level Consist of ( Except Level 1 ) diagram
• A set of Maturity goal
• Supporting Maturity sub goal
• Activities task and responsibilities
The Smarter Tester
 Responsibility :
 Reveal Defects
 To evaluate software performance usability, and reliability.
 Testing is usually performed under budget and time constraints, Testers often
are subject to enormous pressure from the management and marketing .
 The smart tester must
 plan for testing, insure that the resource and
 select the test cases, time allocated for the job are
 monitor the process utilized effectively

Approach-1 :
Test a module or component using all possible i/p , this will enable to
detect all defects
Approach-2:
Select i/p at random
 Goal of the smart tester is to understand the functionality, input/output
domain, and the environment of use for the code being tested.
 Tester must also understand in detail how the code is constructed.
 Smart tester need to use knowledge of the types of defects that are commonly
injected during development or maintenance of this type of software.
 Tester should maximize the use of resources; it takes more time & effort.
TEST CASE DESIGN STRATEGIES
 Develop effective test cases for execution based testing.
 positive consequences of effective test cases
•A greater probability of detecting defects
•A more efficient use of organizational resources
•A higher probability for test reuse
•Closer adherence to testing and project schedules and budgets
•The possibility for delivery of higher quality software products
The two basic testing strategies
Test Strategy & Tester’s View Knowledge Sources Methods

Black Box Requirements Equivalence class

Documents Partitioning
Specification Boundary value analysis
Domain State transition
Knowledge testing
Defect Analysis Cause and Effect
Data Graphing
Error guessing
2
 White Box High level Design Statement
Detailed Design Testing
Control Flow Branch Testing
Graphs Path Testing
Cyclomatic Data Flow
Complexity testing
Mutation
Testing
Loop Testing

Black Box Testing

• size of the software -> simple module, member function, or object cluster to a
subsystem or a complete software system.
• The description behavior or functionality for the software under test may come
from a formal specification an input/ process output diagram (IP0), or well
defined set of pre and post conditions.
• Because the black box approach only considers software behavior and
functionality, it is often called functional or specification based testing.
• This approach is useful for revealing requirements and specification defects.

White Box Approach

• Since designing, executing and analyzing the results of white box testing is very
time consuming, this strategy is usually applied to smaller sized pieces of
software such as module or member function .
• White box testing methods are especially useful for revealing design and code
based control, logic and sequence defects, initialization defects and data flow
defects.

Using the Black Box Approach to Test Case Design:-

1) Random Testing:-
If a tester randomly selects input from the domain, this is called random testing
– Eg:- if the valid input domain for a module is all positive integer between 1 and
100,
– would randomly or unsystematically select valued form within that domain; for
example the values 55,24,3 might me chosen
2)Equivalence Class Partitioning:-
Partitioning of the input domain for the software into valid and invalid classes.
Invalid classes represent erroneous or unexpected inputs.
Advantage:-
 exhaustive testing - eliminated
 selecting a subset of test inputs with a high probability of detecting a defect
 cover a larger domain of inputs/outputs with a smaller subset selected from an
equivalence class.

3
 Guidelines
Input Conditions no of equivalent EXAMPLE
classes
range of one valid & Eg: range of 1-499
values two invalid Valid -> all values from 1-99
classes Invalid -> values < 1
Invalid  values > 499
specific one valid & Eg:- If the specification for a
value two invalid college code ,
classes Valid -> valid college code {210}
Invalid -> valid college code <210
Invalid  valid college code>210
Members one valid & eg:- paint module states that the
of a set one invalid Color RED, BLUE, GREEN and
classes YELLOW are allowed as inputs
Valid -> RED
Invalid -> BLACK
must be one valid & Eg:- if a specification for a module
condition one invalid states that the first character of a
(Boolean) classes part identifier must be a letter
Valid -> TOTAL
Invalid -> 3PI
If the input specification in an equivalence class is not handled in an
identical way by the software under test, then the class should be further
partitioned into smaller equivalence classes
Example: A specification of a square root function.
Function square_root
message (x:real)
when x >_0.0
reply (y:real)
where y >_0.0 & approximately (y*y,x)
otherwise reply exception imaginary_square_root
end function

I) Test Condition Relevant to Input Conditions:

1)The input conditions  variable x must be a real number and be
equal to or greater than 0.0.
2) The output conditions y must be a real number equal to or greater
than 0.0, whose square is approximately equal to x.

II) Generate equivalence classes

EC1. The input variable x is real, valid.

EC2. The input variable x is not real, invalid.
EC3. The value of x is greater than 0.0, valid.
EC4. The value of x is less than 0.0, invalid.

III) equivalence class reporting Table

Condition Valid EC Invalid EC
1 EC1 , EC3 EC2 , EC4

4
 IV) Summary of Test I/ps using EC Partitioning
Test case Id i/p Valid EC Invalid EC
TC1 -3 - EC4
TC2 4.0 EC1,EC3 -
TC3 AB - EC2
TC4 -6.2 - EC4
3)Boundary Value Analysis :
 The test cases developed based on equivalence class partitioning can be
strengthened by use of an another technique called boundary value analysis.
 boundary value analysis requires that the tester select elements close to the
edges, so that both the upper and lower edges of an equivalence class are
covered by test cases.

Guidelines
Input Valid & Invalid Test Case EXAMPLE
Conditions
range of values valid test cases- ends of Eg: range between _1.0 and _1.0
the range, input values of -1.0, -1.1, and 1.0,
invalid test cases - above 1.1.
and below the ends of the
range.
number valid test cases –min & Ex: house can have one to four
of values Max Numbers owners
Invalid Test Case – Min-1 , 0,1 owners and 4,5 owners
max+1 numbers
ordered set, focus on the first and i/p: {25,27,28}
last elements of the set. last element  27,28,29
first element  24,25,26
Example:
The input specification for the module states that a widget identifier should consist of 3–
15 alphanumeric characters of which the first two must be letters.
I) conditions that apply to the input:
(i) it must consist of alphanumeric characters,
(ii) the range for the total number of characters is between 3 and 15, and,
(iii) the first two characters must be letters.

II) Generate bounds groups

BLB—a value just below the lower bound
LB—the value on the lower boundary
ALB—a value just above the lower boundary
BUB—a value just below the upper bound
UB—the value on the upper bound
AUB—a value just above the upper bound
5
For our example module the values for the bounds groups are:
BLB—2 BUB—14
LB— 3 UB— 15
ALB—4 AUB—16
Generate Equivalent Classes
Condition1:
EC1. Part name is alphanumeric, valid.
EC2. Part name is not alphanumeric, invalid.

Condition2:
EC3. The widget identifier has between 3 and 15 characters, valid.
EC4. The widget identifier has less than 3 characters, invalid.
EC5. The widget identifier has greater than 15 characters, invalid.

Condition3:
EC6. The first 2 characters are letters, valid.
EC7. The first 2 characters are not letters, invalid.

III) Equivalence class reporting table.

IV) Summary of Test Inputs using equivalence class & BVA

Example 2: Pin number input of ATM SYSTEM (refer Class Notes)

4)Requirements Based Testing

 Deals with validating the requirements given in the SRS
6
  Requirements  1) Explicit 2) Implicit
 Precondition
 Detailed review of the requirements specification, it ensures that they are
consistent , correct , complete , testable.
 Implied requirements are converted and documented as explicit
requirements  more effective
 Explicit & Implicit requirements are collected and documented as “ Test
Requirements specification “ (TRS)
 Requirements are tracked by a Requirement Traceability Matrix (RTM)
 RTM traces all the requirements from their origin through design, development
and testing.
Example : Lock & Key (key is turned clockwise  unlock & key is turned
anticlockwise lock )
Sample Requirement Specification
Sno ReqId Description Priority (H,
M,L)
1. BR-01 Inserting the key numbered 123 H
-456 and turning it clockwise
should facilitate locking
2. BR-02 Inserting the key numbered 123 H
-456 and turning it
anticlockwise should facilitate
unlocking
3. BR- only key number 123-456 can H
03 be used to lock and unlock
4. ….

Requirement Traceability Matrix (RTM)

Req Description Priori Test Test Case Phases of
Id ty (H, Conditions IDs testing
M,L)
BR-01 Inserting the key numbered 123 -456 H Use key Lock_001 unit
and turning it clockwise should 123-456 Compone
facilitate locking nt
BR-02 Inserting the key numbered 123 -456 H Use key Lock_002 unit ,
and turning it anticlockwise should 123-456 Compone
facilitate unlocking nt
BR-03 only key number 123-456 can be H Use key Lock_003 Compone
used to lock and unlock 123-456 to nt
lock
Use key Lock_004
123-456 to
unlock
…..
 Tests for higher priority requirements will get precedence over tests for lower
priority  functionality that has higher risk is tested earlier
 cross ref b/w requirements and the subsequent phases is recorded in the RTM

7
  RTM helps in identifying the relationship between the requirements and test
cases. Combinations are
 one (requirements ) to one (Test Case)
 one to many
 many to one
 many to many
 one to none.
RTM in Requirement Based Testing:
 it is a tool to track the testing status of each requirement, without missing any
requirements
 prioritization enables selecting the right features to test
 list of test cases that address the particular requirement can be viewed
Test metrics
1. Requirements addressed priority wise
2. Number of test case requirement wise
3. Total no of test cases
Test results
1. Total no of test cases passed
2. Total no of test cases failed
3. Total no of defects in requirements
4. No of requirements completed
5. No of requirements pending

Summary of Test I/P:

s.no Req Priority Test Cases Total Total Total % No of
Id test test test Pass defects
cases cases cases
Passed Failed
1. BR-01 H Lock_01 1 1 0 100 1
2. BR-02 H Lock_02 1 1 0 100 1
3. BR-03 H Lock_03,04 2 1 1 50 3
4. …
Using above Observations can be made with respect to the requirement

5)State based Testing

It is useful in
o product is language processor
o work flow modeling
o dataflow modeling
Example: validate number using simple rules ( for language processor)
1. number start with an optional sign
2. sign can be followed by nay number of digits
3. digits can be optionally followed by a decimal point, represented by a period
4. if there is a decimal point , then there should be 2 digit after decimal
5. Any Number – whether or not it has a decimal point, should be terminated by
a blank.
8
An example of a state transition diagram.

State transition table

Current Input Next
state State
1 Digit 2
1 + 2
1 - 2
2 Digit 2
2 Blank 6
2 decimal point 3
3 Digit 4
4 Digit 5
5 Blank 6
the above state transition table can be used to derive test cases to test valid and
invalid numbers
1. Start the start state ( state #1)
2. Choose the path that leads to the next state ( ex: +/-/digit)
3. Invalid i/p in a given state, generate an error condition TC
4. Repeat the process till u reach the final state
A general outline for using state based testing methods with respect to
language processors is
1. Identify the grammar for the scenario. In the above example, we have
represented the diagram as a state machine. In some cases, the scenario can be
a context-free grammar, which may require a more sophisticated representation
of a "state diagram."
2. Design test cases corresponding to each valid state-input combination.
3. Design test cases corresponding to the most common invalid combinations of
state-input.
Ex2 : Leave application by an employee ( for work flow modeling)

9
6) Cause effect Graphing
• Equivalence class partitioning weakness -- does not allow testers to combine
conditions .
• dynamic test case writing technique.
• Cause and effect graphing is technique that can be used to combine conditions
and derive an effective set of test cases that may inconsistencies in a
specifications
• It restates the requirements specification in terms of logical relationship
between the input and output conditions. Since it is logical, it is obvious to use
Boolean operators like AND, OR and NOT.
Steps:
1. The tester must decompose the specification of a complex software component
into lower level units
2. Identify causes and effects
Cause - distinct i/p condition or an equivalence class of i/p conditions.
Effect - an output condition or a system transformation
3. From the cause and effect information, a Boolean cause and Effect graph is
created.
Graph : Node  causes(Left Side) and effects (Right side). logical operators
such as AND, OR and NOT and are associated with the arcs.

Notations for constructing cause and Effect graph

4. The graph may be annotated with constraints that describes combinations of

causes and/or effects that are not possible due to environmental or syntactic
constraints
5. Convert the graph into a decision table.
6. The columns in the decision table are transformed into test cases.

Example: module that allows user to perform a search for a character in an

existing string.
Step1 : decompose the specification

10
 Input  length of the string
character to search for.
Output  Char position
NOT FOUND
out of range
Step2 : Identify causes and effects

C1 : Positive integer from 1 to 80

C2 : Character to search for is in String
E1 : Integer out of range
E2 : Position of character in string
E3 : Character not found.

Rules or relationship :-
If C1 and C2, then E2.
If C1 and Not C2, then E3
If not C1, then E1.

Step 3: Construct cause and Effect graph & E1

Step: 4 Graph annotated with constraints
C1
E2

C2
E3

Step 5: Convert the graph into a decision table(1- true , 0-false , - don’t care)
T1 T2 T3
C1 1 1 0
C2 1 0 -
E1 0 0 1
E2 1 0 0
E3 0 1 0

Step6 : Decision table are transformed into test cases

Columns are changed into testcases
Existing string  “abcde”
Inputs Length Character to Outputs
search for
T1 5 C 3
T2 5 w Not Found
T3 90 Integer out
of range

7) Positive & Negative Testing

Positive testing
 Verifies the requirements of the product & set of expected o/p

11
  To prove that the product work as per specification
 is to prove that the product works as per specification and expectations. A
product delivering an error when it is expected to give an error, is also a
part of positive testing.
 +ve testing is done to verify the known test conditions.
Ex; Lock & Key

Negative Testing
 Negative testing is done to show that the product does not fail when an
unexpected input is given. The purpose of negative testing is to try to break the
system. Negative testing covers scenarios for which the product is
 not designed and coded. In other words, the input values may not have been
represented in the specification of the product.
 -ve testing is done to break the product with unknowns

Difference between positive testing and negative testing

For positive testing if all documented no end to negative testing, and 100
requirements and test conditions are percent coverage –ve testing is
covered, then coverage can be impractical.
considered to be 100 percent. Negative testing requires a high degree
of among the testers to cover as many
"unknowns" as possible to avoid
at a customer site.

8)Compatibility testing
 It ensures the working of the product with different infrastructure components
(Non-functional testing ).
 test case results depend on infrastructure for delivering functionality
 infrastructure parameter are changed , product is expected to still behave
correctly and produce desired results.
 infrastructure parameter  H/W , S/W , other components
12
 Example
 Test the application in same browsers but in different versions. For e.g. to
test the compatibility of site ebay.com. Download different versions of Firefox
and install them one by one and test the ebay site. Ebay site should behave
equally same in each version.
 Test the application in different browsers but in different versions. For e.g.
testing of site ebay.com in different available browsers like Firefox, Safari,
Chrome, Internet Explorer and Opera etc.
Parameters:
 Processor (Pentium III / IV, Xenon, SPARC)
 Architecture( 32 bit / 64 bit )
 Resource Availability (RAM & Hard disk space)
 Equipment (printer , Modem, Router).
 Operating System
 Middle-tier infrastructure components (Web Server, App server)
 Back end components (Oracle, MS SQL )
 Any s/w used to generate product binaries (compiler, linker)
 Technological components (SDK, JDK)
Compatibility matrix :
Each row represents a unique combination of a specific set of values of the
parameter
Ex: Mail App
Server App Server Web Client Browser MS Office Mail
Server Server

Common Techniques
 Horizontal Combination( HC ): Parameters of the row grouped together for
executing the test cases
 Intelligent Sampling:
 In HC each feature of the product has to be tested with each row
in the compatibility matrix involves time & effort
 Various permutation and combination methods used
 Selection of intelligent sampling based on
 Information collected on the set of dependencies of the
product with parameter.
 Less dependent  removed from the list
 Can include parameters that are part of product
Types:
 Backward compatibility Testing is to verify the behavior of the developed
hardware/software with the older versions of the hardware/software.
 Forward compatibility Testing is to verify the behavior of the developed
hardware/software with the newer versions of the hardware/software.
13
Tools for compatibility testing:
 Adobe Browser Lab - Browser Compatibility Testing
 Secure Platform - Hardware Compatibility tool
 Virtual Desktops - Operating System Compatibility
9) User documentation testing:
User Documentation includes
Manuals user guides installation guides setup guides
online help read me files software release notes

Objective
 To check if what is stated in the document is available in the product
 To check if what is there in the product is explained correctly in the
document.
 Product upgraded  documentation upgraded
 Lack of coordination  documentation group & testing /development group
 sitting in front of the system & verifying screen by screen , transaction by
transaction , report by report
 checks language aspects (spell check & grammar)
Advantages
 Aids in highlighting problems overlooked during reviews
 High quality documentation minimizes defect reported by the customer
 Results in less difficult support calls
 New Programmer & testers can use doc. to learn the external functionality of the
product
 Customer need less training & can proceed more quickly to the advanced
training
The effort & money spent on this would form a valuable investment in the long
run for the organization.
10) Domain Testing :
 Testing the product purely based on domain knowledge &expertise in the
domain of application
 Requires business domain knowledge, Extension of black box testing
When to apply domain testing?

14
 o Ability to design and execute test cases that relate to the people who will buy
and use the software.
o Concerned about everything in the business flow
o Testing the product , not by going through the logic built into the product.
o Business flow determines the steps, not the software under test  “ Business
Vertical Testing”
o To Test the software for “Domain Intelligence” , tester is expected to have
intelligence & knowledge of business flow
o Earlier phases of Black box Testing deals with Equivalent Class Partitioning
,Decision Table (Cause Effect Graphing)
o Domain testing is done all components are integrated and product has been
tested using black box approaches.

Ex: Cash Withdrawal of ATM system

Other Black Box testing Required denomination is available to dispense the
requested amount
Domain Testing Whether user has got the right amount / not

Summary of Black Box Testing

i/p values divided into class 1. Equivalent Class Partitioning
i/p values in range 2. Boundary Value Analysis
i/p & o/p values with multiple 3. Cause effect graphing
condition
Checking expected & un expected i/p 4. Positive & negative Testing
values
Language processor , work flow 5. State based testing
,process flow
To ensure the Requirements 6. Requirement Based Testing
To test domain expertise 7. Domain Testing
Documentation consistent with 8. Documentation Testing
product

Using the White Box Approach to Test Case Design

• white box Testing  The tester’s goal is to determine if all the logical and data
elements in the software unit are functioning properly.
• during the detailed design phase of development - knowledge needed for the
white box test design approach often becomes available to the tester in later
phase of software life cycle
• White Box test design follows black box design as the test efforts for a given
project progress in time

white box based test design • Black box useful for

is most useful when testing both small & large s/w
small components. components
• Level of detail required • Comparatively low
for test design is very high

15
 Static Vs Structural Testing
Static Structural
Product is tested by tester by Tests are run by computer on
going through the source code the built product
not the executable or binaries
Does not involve executing the Involves executing the program
program against predesigned test cases
Static test reveals :

 Code works according to the functional requirements

 Code has been written in accordance with the design developed earlier in the
project life cycle
 Code for any functionality has been missed out
 Code handles errors properly

Static test Methods :

1. Desk Checking of the code
 Informal checking done by author
 No structured method
 No Logs / check lists
 Depends on knowledge of the author

Disadvantages
 A developer is not the best person to detect problems in his or her own code.
He or she may be tunnel visioned and have blind spots to certain types of
problems.
 Developers generally prefer to write new code rather than do any
form of testing
 This method is essentially person-dependent and informal and thus may not
work consistently across all developers.

2. Code walkthrough
 Group oriented - method and formal inspection are group-oriented
methods

16
  Multiple perspective – walkthroughs and inspections is very thin and
varies from organization to organization. The advantage is that it brings
multiple perspectives
 Multiple roles - a set of people look at the' program code and raise
questions for the author. The author explains the logic of the code, and
answers the questions. If the author is unable to answer some questions,
he or she then takes those questions and finds their answers
3. Formal /Fagan Inspection:
1) Group oriented , highly formal & structured
2) specific roles , requires thorough preparation
This method increases the number of defects detected by
1) demanding thorough preparation before an inspection/review;
2) enlisting multiple diverse views;
3) assigning specific roles to the multiple participants; and
4) going sequentially through the code in a structured manner.
Roles :
1) Author
2) Moderator - expected to formally run the inspection according to the
process.
3) Inspector/Reviewer - provides, review comments for the code.
4) Scribe - takes detailed notes during the inspection meeting and circulates
them to the inspection team after the meeting.
Process:
Author & Moderator select the review team
Introductory Meeting
o Author present his perspective
o Typical Document (code, Design, SRS, Stds) is circulated
o Moderator informs date ,time venue – inspection meeting
Defect Logging Meeting:
The moderator takes the team sequentially through the program code, asking
each inspector if there are any defects in that part of the code. If any of the
inspectors raises a defect, then the inspection team deliberates on the defect
and, when agreed that there is a defect, classifies it in two dimensions

1 )Major (major defects need immediate attention.) / Minor – (may not

substantially affect a program)
2) Systematic (machine-specific idiosyncrasies may have to removed by
changing the coding standards) / mis execution(happens because of an error
or slip on the part of the author. example : a wrong variable in a statement)
Review Meeting (if the defect severe)

Challenges in Formal /Fagan Inspection

 Time Consuming
 Logistics & Scheduling - multiple people involved
 Not possible to review entire coding
17
Based on criticality & complexity of code is classified into
High ,medium Formal Inspection
Low Walk through , desk checking

Structural testing Methods:

The fundamental difference between structural testing and static testing is that
in structural testing tests are actually run by the computer on the built product,
whereas in static testing, the product is tested by humans using just the source
code and not the executables or binaries.

1. Unit Functional Testing – methods fall under debugging category

a. Initially Quick test – the developer can perform certain obvious tests, knowing
the input variables and the corresponding expected output Variables
b. modules with Complex logic & condition – build debug version( ex:
intermediate print statement)
c. run the product under debugger or IDE (single stepping of instruction, break
points etc)
2. Code Coverage Testing

Code coverage testing involves designing and executing test cases and finding
out the percentage of code that is covered by testing.
instrumentation
 % of code covered by testing is found by a technique
 specialized tool to rebuild the product , link with the set of lib
 Reporting on the portion of the code covered frequently, so easy to identify
critical & most often code.
Types of coverage
a)Statement Coverage b)Path Coverage
c)Condition Coverage d)Function Coverage

a)Statement Coverage
Programming constructs (4 types)
1. Sequential control flow
2. Two-way decision statements like if then else
3. Multi-way decision statements like Switch
4. Loops like while do, repeat until and for

1)Sequential Control flow(SC)

 Generate test data to make the program enter the sequential block, to make it
go through the entire block
 this may not always be true , Asynchronous Exceptions - (for example, a divide
by zero)
 Multiple Entry Point , in Non Structured Programming
SC metric= # of statements exercised / Total # of Statements

18
 2) Two-way decision statements –if then else
 Have data to test the then part
 Have data to test the else part
 Relevance of statement coverage ?
If the program implements wrong requirements and this wrongly implemented
code is "fully tested," with 100 percent code coverage, it still is a wrong program
and hence the 100 percent code coverage does not mean anything.

Ex: Total =0;

If(code ==’M’)
{ Stm1;
…
Stm7; }
Else
Percent = value/Total *100; /*divide be zero*/
when we test with code = "M," we will get 80 percent code coverage. But if the
data distribution in the real world is such that 90 percent of the time, the value
of code is not = "M," then, the program will fail 90 percent of the time (because
of the divide by zero in the highlighted line).

3) multi way decision statements – switch

- can be reduced to multiple two way if statement
4) Loops – while do ,repeat until , for
- Skip the loop - so that the situation of the termination condition being true before
starting the loop is tested.
-Exercise the loop between one & max number of times - to check all possible
"normal" operations of the loop
-Cover the loop around the boundary ( i.e n-1, n,n+1)

b)Path Coverage
 statement coverage may not indicate “true coverage”
 path coverage gives better representation, split a program into a number distinct
paths.
-prev ex : having data go through the THEN part & ELSE part gives only
50% coverage , irrespective of number of statements in each path.
Path Coverage= # of path exercised/Total # of path in the program

Ex: leapyear() function ( returns FALSE/ TRUE based on i/p)

i/p  validate numeric i/p for date (dd , mm , yyyy)
array  dayofMonth[] contains No of days in each month

Different Path can be taken through program

A B-D-G B-C-E-G B-C-F-G
B-D-H B-C-E-H B-C-F-H

19
Summary of Test inputs
TC ID Path ( Description) Input Expected o/p
TC1 A ( Month Wrong Path) 20/ 0/2000 Invalid Date
TC2 B-D-G ( Not Feb - days wrong) 31/4/2015 Invalid Date
TC3 B-D-H ( Not Feb - days correct) 31/1/2015 valid Date
TC4 B-C-E-G ( Feb , Leap Year - days wrong) 30/2/2016 Invalid Date
TC5 B-C-E-H ( Feb , Leap Year - days correct) 29/2/2016 valid Date
TC6 B-C-F-G ( Feb , Not Leap Year - days wrong) 29/2/2014 Invalid Date
TC7 B-C-F-H ( Feb , Not Leap Year - days Correct) 10/2/2014 valid Date

C)Condition Coverage
 Further refinement of path coverage , Make sure each Boolean expression is
covered for TRUE as well as FALSE paths
 Ex: Path A covered on giving mm < 1 , reporting invalid month
Program not tested for mm> 12
 Compliers perform optimizations to minimize the number of Boolean operations
and all the conditions may not get evaluated, even though the right path is
chosen.
 For example, when there is an OR condition (as in the first IF statement above),
once the first part of the IF (for example, mm < 1) is found to be true, the second
part will not be evaluated at all as the overall value of the Boolean is TRUE.
 Similarly, when there is an AND condition in a Boolean expression, when the
first condition evaluates to FALSE, the rest of the expression need not be
evaluated at all.
Condition Coverage= # of conditions exercised/Total # of conditions in the program

20
d)Function Coverage
 finds how many functions are covered by test cases
 Ex: Database s/w -- inserting a row into the database
Payroll app – calculate tax
 Adv: 1) Functions are easier to identify
2)Higher level of abstraction than code, easy to achieve 100%
3) more logical mapping to requirements than other type of coverage
4) importance of functions can be prioritized based on the importance of
requirements
5) provides natural transition to black box testing
Function Coverage= # of function exercised/Total # of functions in the program

3)Code Complexity Testing

While using these coverage : following questions are raised
1) which of the paths are independent ?(to minimize the test cases)
2) is there an upper bound on the number of tests to be executed to ensure all
the statements have been executed at least once ?
Ans : Cyclomatic complexity “ a metric that quantifies the complexity of a
program”
Steps in Determining Cyclomatic complexity
1) Construct Flow Graph
2) Compute cyclomatic complexity of the resultant flow graph
3) Determine a basis set of linearly independent paths -
4) Prepare test cases that will force execution of each path in the basis set
Flow Graph
 Program is represented in the form of a flow graph.
 Flow graph consist of nodes and graphs

Steps to convert flowchart into flow graph

1) Identify the predicates or decision points
2) Ensure that the predicates are simple

21
3) Combine all sequential statements into a single node
4) When a set of sequential statements are followed by a simple predicate ,
combine all the sequential statements & predicate check into one node & have 2
edges emanating from this one node
5) Make sure that all the edges terminate at some node.

To Compute cyclomatic complexity : 3 ways

i) Cyclomatic Complexity V(G) = E – N + 2, where E is the number of edges
and N is the number of nodes in graph G
ii) V(G) = P + 1, where P is the number of predicate nodes in the flow graph G
iii) V(G) =the number of regions (Closed & Outer Region)

Example : sum of all positive numbers (greater than zero)

a array name
num_of_entries  no of elements
sum  to store total value

1. pos_sum(a, num_of_entries, sum)

2. sum=0
3. int i=1
4. while (i <=num_of_entries)
5. if a[i] >0
6. sum=sum+a[i]
endif
7. i=i+1
end while
8. end pos_sum

1)Construct Flow Graph

22
2) Calculate the cyclomatic complexity of the resultant flow graph
i)V(G)= E - N+2 E= 7, N= 6 V(G) = 7 - 6 + 2 =3
ii)V(G)= P+1 P=2 V(G) = 2+1 = 3
iii) V(G) = No of Regions(R) R=3 V(G) = 3
3)Determine a basis set
A path is a sequence of control flow nodes usually beginning from the entry
node of a graph through to the exit node.
(i) 1-2-3-4-8
(ii) 1-2-3-4-5-6-7-4-8
(iii) 1-2-3-4-5-7-4-8
4) Prepare summary of test cases
Test Input Expected o/p Actual o/p Result
case Id :Pass/Fail
TC1 num_of_entries = -5 0 0 Pass

num_of_entries = 3 i=1 sum=30 Pass

TC2 30 i=2 sum=90
60 i=3 sum=110 110
20 Sum=110

num_of_entries = 1 i=1 sum=0 Pass

TC3 -30
Sum=0 0

Meaning of cyclomatic complexity value

Complexity Meaning
1-10 Well written code , testability is high , cost/effort maintain
is low
10-20 Moderately complex , testability is medium ,cost/effort to
maintain is medium

23
 20-40 Very complex , testability is low ,cost/effort to maintain is
high
>40 Not testable ,any amount of money /effort to maintain may
not be enough

Problem: Biggest of 3 Numbers( Refer Class Notes)

1 Read A,B,C
2 If A > B then
3 If A >C then
4 Print “ A is greater”
Else
5 Print “C is greater”
6 Endif
Else
7 If B >C then
8 Print “ B is greater”
Else
9 Print “C is greater”
10 Endif
11 Endif

1. Construct Flow Graph

2. Calculate Cyclomatic Complexity
3. Derive Basis Set
4. Summary of Test I/p

Additional White Box Test Design Approaches

 Data Flow and White Box Test Design
 Mutation Testing
 Loop Testing
Test Adequacy Criteria TAC:- (stopping rule)
 Def: Tester need a framework for deciding which structural elements to select
as the focus of testing, for choosing the appropriate test data and for deciding
when the testing efforts are adequate enough to terminate the process with
confidence that the software is working properly.
 It is minimal standards for testing a program
– Helping testers to select properties of a program to focus on during test
– Helping testers to select a test data set for a program based on the selected
properties
– Supporting testers with development of quantitative objects for testing
– Indicating to testers whether or not testing can be stopped for that program
Types of TAC:
1. Program Based TAC : focus on structural properties of program , includes logic
,control structure , data flow
2. Specification based TAC: focus on program specification

24
3. Random TAC: ignores both program structure& specification
Ex: TAC focus on statement/branch properties
“A test data set is statement, or branch , adequate if a test set T for program P
Causes all the statements, or branches to be executed respectively”
Coverage Analysis: The TAC & the requirement that certain features of the code
are to be exercised by the test case, also named as coverage criteria

Degree of coverage : when a coverage related testing goal is expressed as a

percent.
degree of coverage < 100% due to the following:-

1. The Nature of the Unit

i. Some statements/branches may not be reachable
ii. The unit may be simple, and not mission or safety , critical and so
complete coverage is thought to be unnecessary
2. The lack of resources
i. The time set aside for testing is not adequate to achieve 100% coverage
ii. There are not enough trained testers to achieve complete coverage for all
the units
iii. There is a lack of tools to support complete coverage.
3. Other project related issued such as timing, scheduling and marketing
constraints.
Ex: 4 branches in s/w unit
2 are executed by planned set of test cases Coverage goal is
Degree of branch coverage : 50% not met
Develop Additional test cases & re execute Continue until
the test cases desired degree is
obtained
Evaluating Test Adequacy Criteria :TAC hierarchy
 Tester can select appropriate criterion using the hierarchy
 Criteria at the top includes the Criteria at the Bottom , for example All def-
use path adequacy means - tester achieved branch & statement adequacy
 Each Adequacy Criteria has both strength and weakness
 Stronger criteria  tester need more time and resource
Example : (Sample code with data flow information)
def  defined use  Used p-use  Predicate Use
c-use  Computation use
1 sum=0 sum, def
2 read (n) n, def
3 i=1 i, def
4 while (i <=n) i, n p-sue
5 read (number) number, def
6. sum=sum+number sum, def, sum, number, c-use
7 i=i+1 i, def, c-use
8 end while
9 print (sum) sum, c-use

25
 Ex: DU Chain (Def-Use Path) Chain in Data flow Testing
Def-Use Path a path from a variable definition to a use is called a def-use path

Partial Ordering for Test Adequacy Criteria

Axioms
set of axioms that allow testers to formalize properties which should be satisfied
by any good program-based test data adequacy criterion
Testers can use the axioms to
 recognize both strong and weak adequacy criteria;

26
 focus attention on the properties that an effective test data adequacy criterion
should exhibit;
 select an appropriate criterion for the item under test;
 stimulate thought for the development of new criteria;

The axioms are based on the following set of assumptions

(i) programs are written in a structured programming language;
(ii) programs are SESE (single entry/single exit);
(iii) all input statements appear at the beginning of the program;
(iv) all output statements appear at the end of the program.

The axioms/properties described by Weyuker are the following

1. Applicability Property
2. Non exhaustive Applicability Property
3. Monotonicity Property
4. Inadequate Empty Set
5. Anti extensionality Property
6. General Multiple Change Property
7. Anti decomposition Property
8. Anti composition Property
9. Renaming Property
10. Complexity Property
11. Statement Coverage Property
Sample test data adequacy criteria and axiom satisfaction

Mutation Testing
• is a testing technique that focuses on measuring the adequacy of test cases.
• A test case is adequate if it is useful in detecting faults in a program.
• A test case can be shown to be adequate by finding at least one mutant program
that generates a different output than does the original program for that test
case.
• If the original program and all mutant programs generate the same output, the
test case is inadequate.
27
 Basic Steps

Kinds of Mutation
A mutation is a small change in a program.
Value Mutations: these mutations involve changing the values of constants
or parameters (by adding or subtracting values etc), e.g. loop bounds { being
one out on the start or finish is a very common error.
Decision Mutations: this involves modifying conditions to reflect potential
slips and errors in the coding of conditions in programs, e.g. a typical mutation
might be replacing a > by a < in a comparison.
Statement Mutations: these might involve deleting certain lines to reflect
omissions in coding or swapping the order of lines of code. There are other
operations, e.g. changing operations in arithmetic expressions. A typical
omission might be to omit the increment on some variable in a while loop.
Example of Testing By Decision Mutation
First test data set--M=1, N=2 , the original function returns 2
• five mutants: replace”>“ operator in if statements by (>,<,<=or=)
Program Mutants
function MAX(M ,N:INTEGER) Mutants Outputs Comparison
return INTEGER is if M>=N then 2 live
begin if M<N then 1 dead
if M>N then if M<=N then 1 dead
return M; if M=N then 2 live
else if M< >N then 1 dead
return N;
end if:
end MAX;
• Executing each mutant: adding test data M=2, N=1 will eliminate the latter live
mutant, but the former live mutant remains live because it is equivalent to the
original function. No test data can eliminate it.

28
University Questions :
PART – B

29
30