PG Department of Computer Science and Technology

S0 C 59 [Software
PS02EMCA59 [[So
So t a e Testing]
Software est g]
g]
Testing
 V&V (Verification & Validation)

Verification Validation
Verification addresses the concern: "Are we building Validation addresses the concern: "Are we building the
the product right? right product?
product?"
Ensures that the software system meets all the Ensures that the functionalities meet the intended
functionality. behavior.
Verification takes place first and includes the Validation occurs after verification and mainly
checking for documentation,
documentation code,
code etc.
etc involves the checking of the overall product.
product

Done by developers. Done by testers.

It has static activities, as it includes collecting It has dynamic activities, as it includes executing the
reviews walkthroughs,
reviews, walkthroughs and inspections to verify a software against the requirements.
requirements
software.
It is an objective process and no subjective decision It is a subjective process and involves subjective
should be needed to verify a software. decisions on how well a software works.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 2

 Black-box testing
• Black Box Testing is a software testing method in which the functionalities of
software applications are tested without having knowledge of internal code
structure,, implementation
p details and internal p
paths.
• Black Box Testing mainly focuses on input and output of software applications and
it is entirely based on software requirements and specifications.
• It is
i also
l known
k as Behavioral
B h i l Testing.
T ti

Input Black Box Output

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 3

 How to do Black-box testing?
• Initially, the requirements and specifications of the system are examined.
• Tester chooses valid inputs (positive test scenario) to check whether SUT
processes them correctly.
p y Also,, some invalid inputs
p ((negative
g test scenario)) are
chosen to verify that the SUT is able to detect them.
• Tester determines expected outputs for all those inputs.
• Software
S ft t t constructs
tester t t test
t t cases with
ith the
th selected
l t d inputs.
i t
• The test cases are executed.
• Software tester compares the actual outputs with the expected outputs.
• Defects if any are fixed and re-tested.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 4

 Black-box testing vs. White-box testing

Black-Box White-Box
Functional/Behaviour Testing (Focuses on functional Glass-box/Structural Testing (Focuses on the internal
requirements of the software).
software) structure of the program).
program)
Structure of the program is not considered. Structure of the program is considered.
Test cases are decided solely on the basis of the Test cases are decided solely on the basis of internals
requirements or specifications. of the module or the program i.e. from an
examination of the program
program’ss logic.
logic
Types of error : incorrect or missing functions, Types of error : logical error, run-time error, data-flow
interface errors, errors in data structures or external error, looping error , etc.
database access, bahaviour or performance errors,
initialization or termination errors, etc.
Examples : Examples:
Graph-based testing, Equivalence Partitioning, Statement coverage testing, condition testing, data-
Boundary Value analysis, Cause-effect Graphing, flow testing, mutation testing, Basis Path Testing,
Orthogonal Array Testing, pair-wise testing, State- Control Structure Testing, etc.
b
based
d testing,
t ti etc.
t

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 5

 Black Box Testing - Example
• A simple login screen of software or a web application will be tested for
seamless user login.
g screen has two fields,, username and p
• The login password as an input
p and the
output will be to enable access to the system.
• A black box testing will not consider the specifications of the code, and it will
t t the
test th valid
lid username and
d password
d to
t login
l i to
t the
th right
i ht account.
t

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 6

 Black Box Testing - Example
• This form of testing technique will check the input and output.
• A user logged in when inputs a present username and correct password.
• A user receives an error message
g when enters username and incorrect
password.
• The black box testing is also known as an opaque, closed box, function-centric
t ti
testing. It emphasizes
h i on the
th behavior
b h i off the
th software.
ft Bl k box
Black b testing
t ti checks
h k
scenarios where the system can break.
• For example, a user might enter the password in the wrong format, and a user
might not receive an error message on entering an incorrect password.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 7

 Black Box Testing Techniques
• This form of testing technique will check the input and output.
• A user logged in when inputs a present username and correct password.
• A user receives an error message
g when enters username and incorrect
password.
• The black box testing is also known as an opaque, closed box, function-centric
t ti
testing. It emphasizes
h i on the
th behavior
b h i off the
th software.
ft Bl k box
Black b testing
t ti checks
h k
scenarios where the system can break.
• For example, a user might enter the password in the wrong format, and a user
might not receive an error message on entering an incorrect password.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 8

 Black Box Testing Techniques

Boundary Equivalence State

Value Class Transition
Analysis Partitioning Testing

1 2 3
Decision Table Graph-Based Error
Testing Testing Guessing
Technique

4 5 6
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 9
 Equivalence Class Partitioning
• Equivalence Class Testing, which is also known as Equivalence Class
Partitioning (ECP) and Equivalence Partitioning, is an important software testing
q
technique used by
y the team of testers for g
grouping
p g and p
partitioning
g of the test
input data, which is then used for the purpose of testing the software product
into a number of different classes.
• It is
i a software
ft t ti
testing t h i
technique or black-box
bl k b t ti
testing th t divides
that di id input
i t domain
d i
into classes of data, and with the help of these classes of data, test cases can be
derived.
• An ideal test case identifies class of error that might require many arbitrary test
cases to be executed before general error is observed.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 10

 Equivalence Class Partitioning
• In equivalence partitioning, equivalence classes are evaluated for given input
conditions. Whenever any input is given, then type of input condition is checked,
p conditions,, Equivalence
then for this input q class represents
p or describes set of
valid or invalid states.
• These different classes resemble the specified requirements and common
b h i
behaviour or attribute(s)
tt ib t ( ) off the
th aggregated
t d inputs.
i t
• You can apply this technique, where there is a range in the input field.
• Thereafter, the test cases are designed and created based on each class
attribute(s) and one element or input is used from each class for the test
execution to validate the software functioning, and simultaneously validates the
similar working of the software product for all the other inputs present in their
respective classes.
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 11
 Equivalence Class Partitioning
• Equivalence class testing can be termed as a logical step in the model
of functional testing.
p
• It improves the q
quality
y of test cases,, which further enhances the q
quality
y of
testing, by removing the vast amount of redundancy and gaps that appear in the
boundary value testing.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 12

 Equivalence Class Partitioning
• Guidelines for ECP:

If the range condition is given as an input, then one valid and two invalid equivalence
classes are defined.

If a specific
p value is g
given as input,
p then one valid and two invalid equivalence
q classes
are defined.

If a member of set is g
given as an input,
p , then one valid and one invalid equivalence
q
class is defined.

If Boolean number is g given as an input

p condition,, then one valid and one invalid
equivalence class is defined.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 13

 Equivalence Class Partitioning
• Important features of this testing technique are:
• It is a black box testing technique which restricts the testers to examine the
software p
product,, externally.
y
• Also known by the name of equivalence class partitioning, it is used to form
groups of test inputs of similar behaviour or nature.
• Based
B d on the
th approach,
h if one member
b works
k well
ll in
i the
th family
f il then
th th
the
whole family is considered to function well and if one members fails, whole
family is rejected.
• Test cases are based on classes, not on every input, thereby reduces the time
and efforts required to build large number of test cases.
• It may be used at any level of testing i.e.
i e unit,
unit integration,
integration system &
acceptance.
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 14
 Equivalence Class Partitioning
• Important features of this testing technique are:
• It is good to go for the ECP, when the input data is available in terms of
intervals and sets of discrete values.
• However, there is no such specific rule to use only input from each class.
Based on the experience and need, a tester may opt for more than one input.
• It mayy results into g
good amount of decrease in the redundant test cases,, if
implemented properly.
• It may not work well with the boolean or logical types variables.
• A mixed combination of Equivalence class testing and boundary value
testing produces effective results.
• The fundamental concept of equivalence class testing/partition comes
from the equivalence class,
class which further comes from equivalence
relations.
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 15
 Equivalence Class Partitioning
• The equivalence class testing can be categorized into four different types, which
are integral part of testing and cater to different data set.
yp of equivalence
• These types q class testing
g are:
• [1] Weak Normal Equivalence Class Testing: In this first type of equivalence
class testing, one variable from each equivalence class is tested by the team.
• Moreover,
M th values
the l are identified
id tifi d in
i a systematic
t ti manner.
• Weak normal equivalence class testing is also known as single fault
assumption.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 16

 Equivalence Class Partitioning
• [2] Strong Normal Equivalence Class Testing: Termed as multiple fault
assumption, in strong normal equivalence class testing the team selects test
cases from each element of the Cartesian p
product of the equivalence.
q
• This ensures the notion of completeness in testing, as it covers all
equivalence classes and offers the team one of each possible combinations
off inputs.
i t
• [3] Weak Robust Equivalence Class Testing: Like weak normal equivalence,
weak robust testing too tests one variable from each equivalence class.
• However, unlike the former method, it is also focused on testing test cases
for invalid values.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 17

 Equivalence Class Partitioning
• [4] Strong Robust Equivalence Class Testing: Another type of equivalence
class testing, strong robust testing produces test cases for all valid and
invalid elements of the p
product of the equivalence
q class.
• However, it is incapable of reducing the redundancy in testing.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 18

 Advantages of ECP
• Equivalence class testing helps reduce the number of test cases, without
compromising the test coverage.
• Reduces the overall test execution time as it minimizes the set of test data.
• It can be applied to all levels of testing, such as unit testing, integration
testing, system testing, etc.
• Enables
E bl th testers
the t t t focus
to f on smaller
ll d t sets,
data t which
hi h increases
i th
the
probability to uncovering more defects in the software product.
• It is used in cases where performing exhaustive testing is difficult but at the
same time maintaining good coverage is required.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 19

 Disadvantages of ECP
• It does not consider the conditions for boundary value.
• The identification of equivalence classes relies heavily on the expertise of
testers.
• Testers might assume that the output for all input data set are correct, which can
become a great hurdle in testing.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 20

 Boundary Value Analysis (BVA)
• Boundary value analysis is a black box test design technique, where the test
cases are designed with the help of representation of those numerical entities
g in those test cases.
which demarcate the ranges
• Boundary testing is the process of testing between extreme ends or boundaries
between partitions of the input values.
• So
S these
th extreme
t ends
d like
lik Start-
St t End,
E d Lower-
L U
Upper, M i
Maximum-Minimum,
Mi i J t
Just
Inside-Just Outside values are called boundary values and the testing is called
"boundary testing".

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 21

 Boundary Value Analysis (BVA)
• The basic idea in normal boundary value testing is to select input variable values
at their:
Minimum
Just above the minimum
A nominal value
J t below
Just b l th maximum
the i
Maximum
• It tests the extreme ends of divisions formed out of input values.
• As a technique, boundary value analysis enables easy generation of test cases.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 22

 Advantages of Boundary Value Analysis (BVA)
• Helps to reduce the number of test cases.
• This analysis is very handy for testing calculation intensive software using
numerical entities.
• Boundary value analysis facilitates clarity in determination of test cases.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 23

 Disadvantages of BVA
• Boundary value testing is efficient only for variables of fixed values
i.e. boundary.
p values.
• It cannot test all test case input
• BVA technique is not suitable with Boolean Variable, because Boolean is a type
of data which have values of 1 and 0.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 24

 ECP vs. BVA
Equivalence Class Partitioning Boundary Value Analysis

1. Equivalence Class Testing is a type of 1. Next part of Equivalence Class

q
black box technique. Partitioning/Testing.
g g
2. It can be applied to any level of testing, 2. Boundary value analysis is usually a part
like unit, integration, system, and more. of stress & negative testing.
3. A test case design technique used to
divide input data into different 3 This test case design technique used to
3.
equivalence classes. test boundary value between partitions.
4. Reduces the time of testing, while using
less and effective test cases 4. Reduces the overall time of test
e ec tion
execution, while
hile making defect
5. Tests only one from each partition of the detection faster & easy.
equivalence classes. 5. Selects test cases from the edges of the
equivalence classes.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 25

 Decision Table Testing
• DECISION TABLE : Decision tables are used in various engineering fields to
represent complex logical relationships.
g is a very
• This testing y effective tool in testing
g the software and its requirements
q
management.
• The output may be dependent on many input conditions and decision tables give
a tabular
t b l view
i off various
i combinations
bi ti off input
i t conditions
diti and
d these
th conditions
diti
are in the form of True(T) and False(F).
• Also, it provides a set of conditions and its corresponding actions required in
the testing.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 26

 Decision Table Testing
• PARTS OF DECISION TABLE
• Decision table has 4 parts which are divided into portions and are given below :

Stub Entries
C1
Conditions Part-1
C2 Part-3
C3
A1
A2
Actions Part-2
A3
Part-4
A$
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 27
 Decision Table Testing
• Condition Stubs : The conditions are listed in this first upper left part of the
decision table that is used to determine a particular action or set of actions.
• Action Stubs : All the p
possible actions are g
given in the first lower left p
portion ((i.e,,
below condition stub) of the decision table.
• Condition Entries : In the condition entry, the values are inputted in the upper
right
i ht portion
ti off the
th decision
d i i t bl In
table. I the
th condition
diti entries
t i partt off the
th table,
t bl there
th
are multiple rows and columns which are known as Rule.
• Action Entries : In the action entry, every entry has some associated action or
set of actions in the lower right portion of the decision table and these values are
called outputs.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 28

 Decision Table Testing
Types of Decision Tables
• The decision tables are categorized into two types and these are given below:
y : In the limited entry
• Limited Entry y decision tables,, the condition entries are
restricted to binary values.
• Extended Entry : In the extended entry decision table, the condition entries have
more than
th t
two values.
l Th decision
The d i i t bl
tables use multiple
lti l conditions
diti where
h a
condition may have many possibilities instead of only ‘true’ and ‘false’ are known
as extended entry decision tables.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 29

 Example of Decision Table (for Login Screen)

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 30

 Example of Decision Table (for Login Screen)

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 31

 Decision Table Testing

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 32

 Graph Based Testing
• Graph-based testing first builds a graph model for the program under test, and
then tries to cover certain elements in the graph model.
q
• This technique of Black box testing
g involves a g
graph
p drawing
g that depicts
p the
link between the causes (inputs) and the effects (output), which trigger the
effects.
• This
Thi testing
t ti utilizes
tili diff
different
t combinations
bi ti off output
t t and
d inputs.
i t
• It is a helpful technique to understand the software’s functional performance, as
it visualizes the flow of inputs and outputs in a lively fashion.
• Major steps involved in graph based testing includes :

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 33

 Graph Based Testing
• Major steps involved in graph based testing includes :

Step 1: Build a graph model

• What information to be captured, and how to represent those information?

Step 2: Identify test requirements (TR)

• A test requirement is a structural entity in the graph model that must be

covered during testing

St 3
Step 3: S
Select
l t ttestt paths
th tto cover th
those requirements
i t

Step 4: Derive test data so that those test paths can be

executed

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 34

 Error Guessing Technique
• This is a classic example of Experience-Based Testing.
• In this technique, the tester can use his/her experience about the application
behavior and functionalities to g
guess the error-prone
p areas.
• Many defects can be found using error guessing where most of the developers
usually make mistakes.
• This
Thi testing
t ti t h i
technique i capable
is bl off guessing
i th erroneous output
the t t and
d inputs
i t to
t
help the tester fix it easily.
• It is solely based on judgment and perception of the earlier end user experience.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 35

 Error Guessing Technique
Few common mistakes that developers usually forget to handle.
• Divide by zero.
g null values in text fields.
• Handling
• Accepting the Submit button without any value.
• File upload without attachment.
• File
Fil upload
l d with
ith less
l th or more than
than th the
th limit
li it size.
i

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 36

 State Transition Techniques
• State Transition Testing is a black box testing technique in which changes made
in input conditions cause state changes or output changes in the Application
under Test (AUT).
( )
• State transition testing helps to analyze behaviour of an application for different
input conditions.
• Testers
T t can provide
id positive
iti and
d negative
ti i
input
t test
t t values
l and
d record
d the
th
system behavior.
• It is the model on which the system and the tests are based.
• Any system where you get a different output for the same input, depending on
what has happened before, is a finite state system.
• State Transition Testing Technique is helpful where you need to test different system
transitions.
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 37
 White Box Testing
• White Box Testing is software testing technique in which internal structure, design
and coding of software are tested to verify flow of input-output and to improve
g , usability
design, y and security.
y
• In white box testing, code is visible to testers so it is also called Clear box testing,
Open box testing, Transparent box testing, Code-based testing and Glass box
t ti
testing.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 38

 What do you verify in White Box Testing?
White box testing involves the testing of the software code for the following:
• Internal security holes
• Broken or p
poorly
y structured p
paths in the coding
gpprocesses
• The flow of specific inputs through the code
• Expected output
• The
Th functionality
f ti lit off conditional
diti l loops
l
• Testing of each statement, object, and function on an individual basis

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 39

 How do you do perform White Box Testing?
White box testing involves the testing of the software code for the following:
• Step-1 : Understand the source code
• Learn and understand the source code of the application.
pp
• Since white box testing involves the testing of the inner workings of an
application, the tester must be very knowledgeable in the programming
l
languages used
d in
i the
th applications
li ti th are testing.
they t ti
• Also, the testing person must be highly aware of secure coding practices.
• Security is often one of the primary objectives of testing software.
• The tester should be able to find security issues and prevent attacks from
hackers and naive users who might inject malicious code into the
application either knowingly or unknowingly.
unknowingly

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 40

 How do you do perform White Box Testing?
White box testing involves the testing of the software code for the following:
• Step-2 :Create Test Cases and Execute
p to white box testing
• The second basic step g involves testing
g the
application's source code for proper flow and structure.
• One way is by writing more code to test the application's source code.
• The
Th tester
t t will
ill develop
d l littl tests
little t t for
f each
h process or series
i off processes
in the application.
• This method requires that the tester must have intimate knowledge of the
code and is often done by the developer.
• Other methods include Manual Testing, trial, and error testing and the use
of testing tools.
tools

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 41

 Advantages of White Box Testing
• Code optimization by finding hidden errors.
• White box tests cases can be easily automated.
g is more thorough
• Testing g as all code p
paths are usually
y covered.
• Testing can start early in SDLC even if GUI is not available.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 42

 Disadvantages of White Box Testing
• White box testing can be quite complex and expensive.
• Developers who usually execute white box test cases detest it. The white box
g by
testing y developers
p is not detailed can lead to p
production errors.
• White box testing requires professional resources, with a detailed understanding of
programming and implementation.
• White-box
Whit b t ti
testing i time-consuming,
is ti i bi
bigger programming
i applications
li ti t k the
take th
time to test fully.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 43

 White Box Testing Techniques

White Box
Testing

Control Flow Data Flow Slice Based Mutation

Testing Testing Testing Testing

Statement Branch Condition Path

Coverage Coverage Coverage coverage

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 44

 Control Flow Testing
• This technique is very popular due to its simplicity and effectiveness.
• We identify paths of the program and write test cases to execute those paths.
• As we all know,, p
path is a sequence
q of statements that begins
g at an entry
y and ends at
an exit.
• There may be too many paths in a program and it may not be feasible to execute all
off them.
th
• As the number of decisions increase in the program, the number of paths also
increase accordingly.
• Every path covers a portion of the program.
• We define ‘coverage’ as a ‘percentage of source code that has been tested with
respect to the total source code available for testing
testing’.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 45

 Control Flow Testing
• We may like to achieve a reasonable level of coverage using control flow testing.
• The most reasonable level may be to test every statement of a program at least once
p
before the completion of testing.
g
• Hence, we may write test cases that ensure the execution of every statement.
• If we do so, we have some satisfaction about reasonable level of coverage.
• If we stop
t t ti
testing without
ith t achieving
hi i thi level
this l l (every
( statement
t t t execution),
ti ) we do
d
unacceptable and intolerable activity which may lead to dangerous results in future.
• Testing techniques based on program coverage criterion may provide an insight
about the effectiveness of test cases. Some of such techniques are part of control
flow testing.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 46

 Statement Coverage
• It is one type of white box testing technique that ensures that all the statements of
the source code are executed at least once.
• It covers all the p
paths,, lines,, and statements of a source code.
• It is used for calculation of the number of statements in source code which have
been executed.
• The
Th main
i purpose off Statement
St t t Coverage
C i to
is t cover all
ll the
th possible
ibl paths,
th lines
li
and statements in source code.
• Statement Coverage = ( No. of Executed Statements / Total no. of Statements)/100

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 47

 Example of Statement Coverage

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 48

 Statement Coverage
Set1 : If X =8, Y =4
• Number of statements Executed: 5
• Total no of statements in the source code: 7
• Statement coverage =(5/7)*100 = 71.00 %

Set2 :If X =1, Y =7

• Number of statements Executed: 6
• Total no of statements in the source code: 7
• Statement coverage =(6/7)*100 = 85.20 %

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 49

 Statement Coverage
Advantage of statement coverage
• It verifies what the written code is expected to do and not to do
• It measures the q
quality
y of code written
• It checks the flow of different paths in the program and it also ensure that
whether those path are tested or not
Wh t is
What i covered
d by
b Statement
St t t Coverage
C t ti ?
testing?
• Unused Statements
• Dead Code
• Unused Branches
• Missing Statements

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 50

 Branch Coverage
• Branch coverage is a testing method, which aims to ensure that each one of the
possible branch from each decision point is executed at least once and thereby
g that all reachable code is executed.
ensuring
• That is, every branch taken each way, true and false. It helps in validating all the
branches in the code making sure that no branch leads to abnormal behavior of
th application.
the li ti
• Branch Testing = (Number of decisions outcomes tested / Total Number of
decision Outcomes) x 100 %

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 51

 Branch Coverage
• Branch Coverage is a white box testing method in which every outcome from a
code module(statement or loop) is tested.
• The p
purpose
p of branch coverage
g is to ensure that each decision condition from
every branch is executed at least once. It helps to measure fractions of
independent code segments and to find out sections having no branches.
• Branch
B h coverage is
i a testing
t ti method,
th d which
hi h aims
i t ensure that
to th t each
h one off the
th
possible branch from each decision point is executed at least once and thereby
ensuring that all reachable code is executed.
• That is, every branch taken each way, true and false. It helps in validating all the
branches in the code making sure that no branch leads to abnormal behavior of
the application.
application
• Branch Coverage = (Total number of Branch Executed / Total No of Branches)
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 52
 Branch Coverage

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 53

 Branch Coverage
• Logic can be represented by flowchart as :
• To calculate Branch Coverage, one has to
find out the minimum number of paths
p
which will ensure that all the edges are
covered. In this case there is no single
path
th which
hi h will
ill ensure coverage off all
ll the
th
edges at once. The aim is to cover all
possible true/false decisions.
• (1) 1A-2C-3D-E-4G-5H
• (2) 1A-2B-E-4F
• Hence Branch Coverage is 2.
2

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 54

 Branch Coverage
Advantages of Branch Coverage:
• Allows you to validate-all the branches in the code
p y
• Helps you to ensure that no branched lead to any
y abnormality
y of the p
program’s
g
operation
• Branch coverage method removes issues which happen because of statement
coverage testing
t ti
• Allows you to find those areas which are not tested by other testing methods
• It allows you to find a quantitative measure of code coverage
• Branch coverage ignores branches inside the Boolean expressions

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 55

 Path Coverage
• Path Coverage testing is a structured testing technique for designing test cases
with intention to examine all possible paths of execution at least once.
g and executing
• Creating g tests for all p
possible p
paths results in 100% statement
coverage and 100% branch coverage.
• In this type of testing every statement in the program is guaranteed to be
executed
t d att least
l t one time.
ti Fl
Flow G
Graph,
h Cyclomatic
C l ti Complexity
C l it are used
d to
t
arrive at basis path.
• Cyclomatic Complexity is a software metric used to indicate the complexity of a
program.
• Cyclomatic Complexity refers to the number of minimum test cases for a white
boxed code which will cover every execution path in the flow.
flow

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 56

 Path Coverage
• PathCoverage = Number of Paths Covered/ Number of Total Paths .
• Example of Path Coverage Testing:

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 57

 Path Coverage
• Program graph of the Code :

PathCoverage ensures covering of all

the paths from start to end.
• All possible
ibl paths
th are-
1-3-5-7
1-3-5-6-8
1-2-4-5-6-8
1-2-4-5-7

• So PathCoverage is 4.
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 58
 Path Coverage
Advantages of Path Coverage Testing :
• Path Testing helps reducing redundant tests
• Focus on p
program
g logic
g
• Test cases will execute every statement in a program at least once

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 59

 Overall Summary
• White box testing techniques are testing methods that rely on having access to
the internal structure, design, and implementation of the software being tested.
q
These techniques are also known as structural testing
g or code-based testing,
g, as
they involve analyzing the code and the internal structure of the software to
verify its behavior.
• Some
S common white
hit box
b testing
t ti techniques
t h i are:
• Statement Coverage: This technique ensures that each statement in the code
has been executed at least once during testing.
• Branch Coverage: This technique checks if all possible paths of execution within
the code have been tested. It involves testing all possible branches of
conditional statements and loops.
loops

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 60

 Statement Coverage
• Path Coverage: This technique checks if all possible paths through the code
have been executed during testing. It requires testing every possible
combination of conditions and loops.
p
• Condition Coverage: This technique ensures that every possible outcome of a
conditional statement has been tested. It involves testing every possible
combination
bi ti off true
t and
d false
f l conditions.
diti
• Loop Coverage: This technique ensures that every possible iteration of a loop
has been tested. It involves testing the loop with minimum and maximum
iterations.
• Data Flow Testing: This technique checks the flow of data within the code. It
involves tracing the flow of input and output data within the code to identify any
potential errors.
Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 61
 Statement Coverage
• Static Analysis: This technique involves analyzing the code without executing it.
It can detect coding errors, security vulnerabilities, and other potential issues.
g This technique
• Mutation Testing: q involves introducing
g artificial faults into the
code to test the effectiveness of the test cases. It helps to identify any
weaknesses in the test suite.
• Overall,
O ll white
hit box
b t ti
testing t h i
techniques can help
h l identify
id tif defects
d f t in
i the
th software's
ft '
internal structure, design, and implementation. They can be used to ensure that
the software meets its functional and non-functional requirements and is
reliable, secure, and maintainable.

Dr. B. B. Patel (Associate Professor), S P University ( - [email protected] ) 62