MCA 203 Software Engineering & Project Management Lecture 5

By: Deepak Garg, Assistant Professor, NIT Kurukshetra

Contents
1 Goals of Software Testing ............................................................................................................... 2
1.1Short Term or Immediate Goals ................................................................................................. 2
1.2Long Term Goals ........................................................................................................................ 2
1.3Post Implementation Goals ......................................................................................................... 3
2 Testing Principles............................................................................................................................. 3
3 Test case characteristics .................................................................................................................. 4
4 Key Terms of Software Testing ...................................................................................................... 5
5. Testing Methods ............................................................................................................................... 6
5.1 White Box Testing ...................................................................................................................... 6
White Box Testing Techniques:............................................................................................. 7
5. 2 Black Box Testing ..................................................................................................................... 7
Black Box Testing Techniques: ............................................................................................ 8
5.3 Grey Box Testing ........................................................................................................................ 9
5.4 Comparison ................................................................................................................................. 9
6. Automated Software Testing ....................................................................................................... 10
6.1 Consideration during Automated Software Testing .................................................................. 10
6.2 Advantages of Automated Software Testing ............................................................................ 11
6.3 Disadvantages ........................................................................................................................... 11
6.4 Basic Tools used in Automated Software Testing .................................................................... 12
7. Coverage Criteria ......................................................................................................................... 13
8. Basis Path Testing ......................................................................................................................... 14
8.1 Importance of Basis Path Testing: ............................................................................................ 14
8.2 Steps of Basis Path Testing:...................................................................................................... 14
8.3 Key Terms Related To Basis Path Testing: .............................................................................. 14
a. Basis Set ..................................................................................................................................... 14
b. Control Flow Graph (CFG)........................................................................................................ 15
c. Cyclomatic Complexity ............................................................................................................. 15
9. Graph Matrices (Graph matrix and Connection Matrix).......................................................... 17
Graph Matrix ................................................................................................................................... 17
a. Graph matrix for finding set of all paths ................................................................................. 17
b. Connection Matrix................................................................................................................... 18
c. Cyclomatic complexity automatically. ................................................................................... 18

1
1 Goals of Software Testing
To understand the new concepts of software testing and to define it thoroughly, goals of
software testing may be classified into three major categories as shown in fig. 1.1

Fig. 1.1: Goals of Software Testing

 Short Term or Immediate Goals

These goals are the immediate results after performing testing. These goals may be set in the
individual phases of SDLC . Some of them are discussed below.
 Bug Discovery
More the bugs discovered at any early stage, better will be the success rate of software testing.
 Bug Prevention
From the behavior and interpretation of bugs discovered, everyone in the software
development team gets to learn how to code safely such that the bugs discovered should not
be repeated in later stages or future projects. Though errors cannot be prevented to zero, they
can be minimized.
 Long Term Goals
These goals affect the product quality in the long run, when one cycle of the SDLC is over.
Some of them are discussed below.
 Quality
Software is also a product; its quality is primary from the user‟s point of view. Quality
depends upon various factors, such as correctness, integrity, efficiency, etc.
 Reliability
It is a matter of confidence that the software will not fail and this level of confidence increases
with rigorous testing.
 Customer Satisfaction

2
Testing should be complete in the sense that it must satisfy the user for all the specified
requirements mentioned in the user manual, as well as for the unspecified requirements which
are otherwise understood.
 Risk Management
Risk is the probability that undesirable events will occur in a system. Software testing acts as
a control to manage risks (minimizing or eliminating).
 Post Implementation Goals
These goals are important after the product is released. Some of post implementation goals are
discussed below .
 Reduce maintenance cost
The maintenance cost of any software product is not its physical cost, as the software does not
wear out. The only maintenance cost in software products is its failure due to errors and post
release errors are costlier to fix.
 Improved Software testing process
A testing process for one project may not be successful and there may be scope for
improvement. Therefore, the bug history and post-implementation results can be analyzed to
find out snags in the present testing process, which can be rectified in future projects. Thus,
the long term post implementation goal is to improve the testing process for future projects.

2 Testing Principles
Below are the basic but important principles of software testing which should be followed by
every tester, if these are not followed by tester then it may cause failure of complete testing
process.

 Effective testing, not exhaustive testing: All possible combinations of tests become so
large that it is impractical to test them all. So, considering the domain of testing as infinite,
exhaustive testing is not possible.
 Testing is not a single phase performed in SDLC: Testing is done at every phase of SDLC
like during requirement gathering phase, the analysis verification of requirements etc.
 Destructive approach for constructive testing: Tester must have the psychology that bugs
are always present in the program and they must think about the technique of how to uncover
them. This psychology of being always suspicious about bugs is a negative/destructive
approach.
 Early testing is the best policy: Testing process is not a phase after coding; rather it starts
as soon as requirement specifications are prepared. Moreover, the cost of bugs can be reduced

3
tenfold, as bugs are harder to detect in later stages if they go undetected. Thus the policy is to
start as early as possible.
 Probability of existence of an error in a section of a program is proportional to the number
of errors already found in that section: The principle provides the insight that if some section
are found error-prone in testing, then our next testing effort should give priority to these error-
prone sections.
 Testing strategy should start at the smallest module level and expand towards the whole
program: This principle supports the idea of incremental testing. Testing must begin at the
unit or module level, gradually progressing toward integrated module and finally the whole
system. Testing cannot be performed directly on the whole system. It must start with the
individual modules and slowly integrate the modules and test them. After this, the whole
system should be tested.
 Testing should also be performed by an independent team : When programmers develop
the software, they test it at their individual modules. However, these programmers are not
good testers of their own software. They are basically constructors of the software, but testing
needs a destructive approach. Programmers always think positively that their code does not
contain bugs. Moreover they are biased towards the correct functioning of the specified
requirements and not towards detecting bugs [CHA2011].
 Everything must be recorded in software testing: Testing is not an intuitive process; rather
it is a planned process. It demands that every detail be recorded and documented.
 Invalid inputs and unexpected behavior have a high probability of finding an error:
Whenever software is tested, test is done for valid inputs and for the functionality that the
software is supposed to do. But thinking in a negative way, software must be tested with
invalid inputs and with the behavior which is not expected in general.
 Testers must participate in specification and design reviews: If testers are not participating
in other reviews like specification and design, it may be possible that either some
specifications are not tested or some test cases are built for no specifications.

3 Test case characteristics

Kaner suggested the following attributes of a “good” test:

 A good test is not redundant: Testing time and resources are limited. There is no point in
conducting a test that has the same purpose as another test. Every test should have a different
purpose (even if it is subtly different).

4
 A good test has a high probability of finding an error: To achieve this goal, the tester must
understand the software and attempt to develop a mental picture of how the software might
fail. Ideally, the classes of failure are probed. For example, one class of potential failure in a
GUI (graphical user interface) is a failure to recognize proper mouse position. A set of tests
would be designed to exercise the mouse in an attempt to demonstrate an error in mouse
position recognition.
 A good test should be “best of breed” : In a group of test that have a similar intent, time
and resource limitations may mitigate toward the execution likelihood of uncovering a whole
class of errors should be used.
 A good test should be neither too simple nor too complex: Although it is sometimes
possible to combine a series of tests into one test case, the possible side effects associated
with this approach may mask errors. In general, each test should be executed separately.

4 Key Terms of Software Testing

Software Testing is the process of ensuring right software product to achieve full customer
satisfaction. The following terms are mostly used in software testing. So, are taken as key
terms of software testing

 Failure: Failure of a program is the mismatch between expected and actual results of the
program under test.
 Fault/Defect/Bug: Fault is a condition in a program that causes failure.
 Error: Error is very general term used for human mistake. Whenever a development team
member makes a mistake in any phase of SDLC errors are produced, error is the actual
location in the program where a mistake has been made that produced bug. It might be
typographical error, a misleading of a specification etc. Thus, an error causes a bug and the
bug in turn causes failure, as shown in fig. 1.2.

Error Bug Failure

Fig. 1.2: Relation between error, bug and failure.

5
 Test data: Test data is the data which have been specifically identified to use in testing
computer program.
 Test case: It is a well documented procedure designed to test the functionality of a feature
in the system. Test case includes test case id, purpose, preconditions, inputs, expected outputs
etc.
 Test oracle: An oracle is the means to judge the success or failure of a test, i.e. to judge the
correctness of the system for some test. This simplest oracle is comparing actual results with
expected results by hands.
 Test automation: Developing software for testing the software product.
 Coverage: It includes coverage of program or faults. The aim of coverage based testing
method is to „cover‟ the program with test cases that satisfy some fixed coverage criteria. The
aim of fault coverage criteria is to cover maximum fault in a program.
 Path: It is sequence of nodes and edges. If path starts form entry node and end at exit node
then it is called as a complete path.
 Branch predicate or condition: It is condition, in which a node that may lead to either true
path or false path.
 Path predicate or decision: A path predicate is defined as the collection of branch
predicates which are required to be true in order to traverse a path.
 Feasible path: The path, where there is valid input that execute in the path.
 Infeasible path: The path, where there is no valid input that execute in the path.
 Testware: The documents created during testing activities are known as testware. It may
include test plans, test specifications, test case design, test reports etc.

5. Testing Methods
Any engineered software product can be tested in one of the three methods white box testing,
black box testing and grey box testing. All these testing methods come under the class of
dynamic testing because all the methods that execute the code to test software come under the
dynamic testing technique.

5.1 White Box Testing

White box testing uses the control structure described as part of component level design to
derive test case. Using white box testing methods, the software engineer can derive test cases
that do following:

 Guarantee that all independent paths within a module have been exercised at least once.
 Exercise all logical decisions on their true and false sides.
6
 Execute all loops at their boundaries and within their operational bounds.
 Exercise internal data structures to ensure their validity.

White Box Testing Techniques:

 Statement Coverage: The first kind of logic coverage can be identified in the form of
statements. It is assumed that if all the statements of the module are executed once, every bug
will be notified.
 Decision or Branch Coverage: Branch coverage states that each decision takes on all
possible outcomes (true or false) at least once. In other words, each branch direction must be
traversed at least once.
 Condition Coverage: Condition coverage states that each condition in a decision takes on
all possible outcomes at least once.
 Decision/Condition Coverage: Condition coverage in a decision does not mean that the
decision has been covered. So, it requires sufficient test cases such that each condition in a
decision takes on all possible outcomes at least once, each decision takes on all possible
outcomes at least once, and each point of entry is invoked at least once.
 Multiple Condition Coverage: In case of multiple conditions, even decision/condition
coverage fails to exercise all outcomes of all conditions. The reason is that we have
considered all possible outcomes of each condition in the decision, but we have not taken all
combinations of different multiple conditions. Therefore, multiple condition coverage requires
that we should write sufficient test cases such that all possible combinations of condition
outcomes in each decision and all points of entry are invoked at least once.
 Path Coverage: It deals with complete paths in a given pieces of code. In other words,
every line of source code should be visited at least once during testing. Path coverage is a
more general criterion as compared to other coverage criteria and useful for detecting more
errors. But the problem with path criteria is that programs that contain loops may have an
infinite number of possible paths and it is not practical to test all the paths.

5. 2 Black Box Testing

It is also called as behavioral testing, focuses on the functional requirements of the software.
It enables the software engineer to derive sets of input conditions that will fully exercise all
functional requirements for a program. Black box testing is not an alternative to white box
testing but it is a complementary approach. Black box testing attempts to find errors in the
following categories:

 Incorrect or missing functions.

 Interface errors.
7
 Errors in the data structure or external database access.
 Behavior or performance errors.
 Initialization and termination errors.

Black Box Testing Techniques:

Below are some techniques used under black box testing:
 Boundary value analysis (BVA): It uncovers the bugs at the boundary of input values.
Here boundary means the maximum or minimum values taken by the input domain. BVA has
shown good results It includes basically 3 methods.
a. Boundary value checking (BVC): Here test cases are designed by holding only one
variable at its 4 extreme (min, min+, max, max-) value and other variables at their nominal
values in their input domain. So, for n variables in a module 4n+1 test case can be designed
with boundary value checking method.
b. Robustness testing method: Here testing for bugs is done by holding one variable at 6
extreme values (min, min+, min-, max, max+, max-) and other variable at their nominal value.
So, for n variables in a module 6n+1 test case can be designed with boundary value checking
method.
c. Worst-Case testing method: Here more than one variable can be on their 4 extreme values.
n
So, for n variables in a module 5 test cases can be designed with worst case testing.
 Equivalence Class testing: Here input domain is partitioned into classes based on some
common features like same kind of processing and output to occur . Then execute only one
test case from each class, if one test case in an equivalence class detects a bug then all other
test case in that class has the same probability of finding bugs. Thus it ensures completeness
and non redundancy. Two types of classes can always be identified, which are valid and
invalid equivalence classes.
 Decision table based testing: It has the specialty to consider combinations of input
conditions and resulting actions which are not considered by boundary value analysis and
equivalence class partitioning. Decision table obtain their power form logical expressions.
Decision table consists of condition stub (list of input conditions), action stub (list of resulting
actions), condition entry (specific entry in the table corresponding to input conditions
mentioned in the condition stub) and action entry (entry in the table for the resulting action to
be performed when one rule is satisfied).
 Cause-Effect Graphing: It is built upon the belief that combinations of input can cause
failures in software, thus the multiple fault assumption uses the cartesian product to cover all
combination of inputs, often leading to a high yield set of test cases. In this firstly divide
specification into small pieces (also known as the divide and conquer principle) then list all
8
causes (input classes) and all effects (output classes) then link causes to effects using a
boolean graph then describe combinations of causes/effects that are impossible then covert the
graph to a table then create test cases from the columns in the table.

5.3 Grey Box Testing

It is a combination of white box testing and black box testing. The aim of this testing is to
search for the defects if any due to improper structure or improper usage of applications. A
grey box tester partially knows the internal structure, which includes access to the
documentation of internal data structures as well as the algorithms used. Grey box testers
require both high level and detailed documents describing the application, which they collect
in order to define test cases. Two primary examples of testing in this area are for assertions
and exceptions. Essentially these conditions provide metadata about an executing program.
For assertion testing, test case generators attempt to find data that violate assertions inserted
by the original programmers. The assertions specify constraints with how the program should
execute. An error is indicated if a created test data violates an assertion.

5.4 Comparison
Table 1.1 shows the comparison between black box, grey box and white box testing in terms
of granularity, known or unknown internal knowledge, degree of exhaustiveness, alternative
names, functionality etc .

Table 1.1: Comparison of Testing Methods

Black Box testing Grey box testing White Box testing

Low granularity. Medium granularity. High granularity.

Internals not known, neither Internal partially known. Internals fully known.
required to be known.

Likely to be least exhaustive of Somewhere in between. Potentially most

the three. exhaustive of the three.

Not suited for algorithm Not suited for algorithm testing. Appropriate for
testing. algorithm testing.

It is concerned with validating Here we have a better variety of It enables logic

outputs for given inputs, the inputs and ability to extract test coverage, coverage of
application being treated as a results from database for statements, decisions,
black box. comparison with expected conditions, paths etc
results.

9
 Also known as
Opaque box testing
Closed box testing
Function testing
Data driven testing
Also known as translucent box Also known as
testing. Glass box testing
Structural testing
Clear box testing

Test data can be designed Medium Can not be designed

earlier because functionalities earlier before internal
are known view

Test cases can not be executed Medium Test cases executed

before completion of full earlier
system

6. Automated Software Testing

Developing software to test the software is called as test automation/automated testing. In
simple terms, automated testing is automating the manual testing process . It is used to replace
or supplement manual testing with a suite of testing tools. Automated testing tools assist
software testers to evaluate the quality of the software by automating the mechanical aspects
of the software testing task. Automated testing tools vary in their underlying approach, quality
and ease of use.

6.1 Consideration during Automated Software Testing

While performing testing with automated tools, the following points should be noted as
guidelines. If these are not followed then it may cause failure of automated software testing.

 Clear and reasonable expectations should be established in order to know what can and
what cannot be accomplished with automated testing in the organization.
 There should be clear understanding of the requirements that should be met in order to
achieve successful automated testing. This requires that the technical personnel should use the
tools effectively.
 The organization should have detailed, reusable test cases which contain exact expected
results and a standalone test environment with a restorable database.

10
 Testing tools should be cost effective. The tool must ensure that test cases developed for
manual testing are also useful for automated testing.
 Select a tool that allows the implementation of automated testing in a way that conforms to
the specified long term testing strategy.

6.2 Advantages of Automated Software Testing

Below are advantages of automated software testing over manual software testing in terms of
time, reliability, reusability, resources requirements, independency and high educated staff.

 Saves time: Automated execution of test cases is faster than manual execution. This saves
time. This time can also be utilized to develop additional test cases, thereby improving the
coverage of testing.
 More Reliable: Manual running the tests may result in boredom and fatigueness, more
chances of human error. Automated testing overcomes all these shortcomings.
 Reusable: Automatic testing is reusable while manual testing is not reusable.
 Less Resource Requirement: Tests, once automated take comparatively far less resources
to execute. A manual test suite requiring 10 persons to execute it over 31 days i.e. 31*10=310
man days, may take just 10 man-days for execution, if automated.
 Independency to Test Engineers: Manual testing requires the presence of test engineers but
automated test can be done independently.
 No Need of High Educated Staff (testers): Automated testing doesn‟t require high educated
testers because testing is done by automatic tools.

6.3 Disadvantages
Below are disadvantages of automated software testing over manual software testing in terms
of cost, coverage of bugs, variety of bugs, time to test execution .

 Costly: An automated test suite development is normally 3-5 times the cost of a complete
manual test cycle.
 Not complete coverage: It achieves less than 50% statement coverage because it finds bugs
only in part of codes that are actually executable.
 Uncovers limited types of bugs: It can uncover only those types of bugs that are
traversable through execution, while there is no such condition in manual software testing.
 Only when executables are ready: Automatic testing can be done only when executables
are ready, while manual testing can be done before compilation.

11
6.4 Basic Tools used in Automated Software Testing
Since testing is of two types, static testing and dynamic testing. In the same way testing tools
are accordingly classified in to two types as given below:

 Static Testing tools: These tools do not involve actual input and output. Rather they take a
symbolic approach to testing, i.e. they do not test the actual execution of the software. It
includes flow analyzers, path tester, coverage analyzers, interface analyzers etc.
 Dynamic Testing tools: These tools test the software system with „live‟ data. Dynamic test
tools includes test drivers, test beds, emulators mutation analyzers etc.

On the whole, there are various tools for automating the software testing and that can be used
in different areas of testing. At this moment, there are many tools to assist software testing
such as capture/playback tools, tools for automated execution of tests, coverage analyzers, test
case generators, logical and complexity analyzers, code instrumentation tools, defect tracking
tools and test management tools.

 Capture/playback tools can be either intrusive or non-intrusive. Intrusive tools are native
tools as they along with software under test reside on the same machine. In non intrusive
capture/playback tool software under test and testing tool resides on the different machines.
Capture/playback tools are used to record testing sessions in script files, allowing to playback
them later. It can be made for multiple tests and the results can be compared. Those tools are
useful in regression testing. One of the most boring and time consuming activity during
testing life cycle is to rerun manual tests number of time. So, capture/playback tools are of
great help to the testers.
 Coverage analyzers are tools used to evaluate how much of the structure of the tested code
has been covered by the test cases. These tools are useful for identifying the code sequences
which were not covered by the tests.
 Test case generations are tools based on information such as requirements, data models
and object models which are used to generate significant test cases. The main advantage of
using these tools is that the testing redundancy is eliminated by finding the test cases that
assure the best coverage for the code.
 Test data generators are used to fill data in files and databases that will be used for testing.
Data are chosen randomly or based on some specific conditions. These tools are usually used
for large volume of data necessary in operational testing and load testing.
 Tools for code instrumentation are tools used for the analysis of source code of the
program under test and inserting calls to specific functions in order to gather information
about program during its execution.
12
 Defect tracking tools are used to manage the information regarding the detected errors,
their status and to centralize that information in order to provide information regarding the
trend of the fault. Some steps of the software development cycle can be improved on the basis
of trends obtained.
 Tools for test management are tools used to assist in planning and organizing of all
elements involved in testing such as- script files, test cases, test reports and test results.
 Logical and complexity analyzers are tools used to quantify the complexity of the code.
Many of these tools can show the graphical structure of the code [AGG2006]. These tools are
useful to find the necessary test cases for execution of some point s of the code in complex
modules.

7. Coverage Criteria
To measure how well the program is exercised by a test suite, one or more coverage criteria
are used or it gives the measure to what extent the software is exercised in the process of
testing by a test suite . Coverage can be applied during any stage of testing, whether it is unit
testing, integration testing or system testing etc. Test coverage can be based on functional
specification (black box testing) or an internal program structure (white box testing). Structure
coverage is more commonly used. Such testing can measure coverage at various granularities,
including statements, lines, blocks, conditions, methods and classes. It provides a way to
quantify the degree of thoroughness of white box testing. A coverage criterion is usually
defined as a rule or requirement, which a test suite needs to satisfy.
Coverage= (Number of coverage items exercised / Total no. of coverage items) * 100

There are number of coverage criteria exist, below are few ones :

 Statement Coverage: Has each line of the source code been executed by test suite?
 Decision Coverage: Has each branch/ decision of the source code been executed on both
true and false output by test suite?
 Condition Coverage: Has each condition of the source code been executed on both true and
false output by test suite?
 Function Coverage: Has each function in the source code been executed by test suite?
 Path Coverage: Has every possible path in the source code been executed by test suite?
 Multiple Condition coverage: Has all combination of different multiple conditions in the
source code been executed by test suite?

13
8. Basis Path Testing
Basis path testing is a white box testing technique. It was proposed by Tom McCabe. The
basis path method enables the test case designer to derive a logical complexity measure of a
procedural design and use this measure as a guide for defining a basis set of execution
paths . This set of independent paths is called basis set, that’s why it is termed as basis path
testing.

8.1 Importance of Basis Path Testing:

 Basis path testing strategy can detect almost 65 percent of errors in program under test
 Various structural test date generation can be transformed into a path oriented test data
generation problem.
 Basis path testing is a hybrid between path testing and branch testing.

8.2 Steps of Basis Path Testing:

The method devised by Tom McCabe to carry out basis path testing has four steps, which are
given below:

1. Using the code as a foundation, draw a corresponding flow graph.

2. Determine the 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.

8.3 Key Terms Related To Basis Path Testing:

Below are some key terms related to basis path testing including basis set, control flow
graph, cyclomatic complexity, graph matrix, connection matrix etc.

a. Basis Set
Basis set is a finite set of linearly independent paths through a standard flow graph. An
independent path is a path of a program, where at least one edge of this path never appears
in any other path in the control-flow graph (CFG). Every path in the Basis set should satisfy
these three conditions:

1. Every path should be an independent path.

2. All edges in a CFG should be covered by all paths in the basis set.
3. Every path not contained in this basis set of paths can be constructed by linear operations
among paths in this set.

14
b. Control Flow Graph (CFG)
The control flow graph is a graphical representation of control structure of a program. Flow
graphs can be prepared as a directed graph. A directed graph (V, E) consists of a set of
vertices V and a set of edges E that are ordered pairs of elements of V.

Notations of CFG
 Node- It represents one or more procedural statements (having a fixed input and fixed output).
The nodes are denoted by a circle. These are numbered or labeled.
 Edge- They represent the flow of control in a program, denoted by an arrow on the edge
 Decision Node – A node with more than one arrow leaving is called a decision node.
 Regions- Areas bounded by edges and nodes are called regions.
Important points regarding CFG
 Sequential statements having no conditions or loops can be merged in a single node. That is
why; the flow graph is also known as decision to decision graph or DD graph.
 An edge must terminate at a node, even if the node does not represent any procedural
statements.
 When counting region we include the area outside the graph as a region.
 A compound condition occurs when one or more Boolean operators (logical OR, AND,
NAND, NOR) is present in a conditional statement, so a separate node is created for each of the
compound condition as shown in fig. 1.3

Fig. 1.3: Example CFG for compound condition.

c. Cyclomatic Complexity
McCabe has given a measure for the logical complexity of a program by considering its
control flow graph by considering only independent paths. Cyclomatic complexity number
gives the number of independent paths (as basis set) as upper bounds for the number of
tests that must be conducted to ensure that all the statements and every condition has been
executed on its true and false sides at least once.

15
  Strongly connected graph in which each node can be reached from any other node.
 When counting the regions, area outside the graph is also considered as a region.

Table 1.2 gives cyclomatic complexity of any graph g including following notations:

V(g)-Cyclomatic complexity number

e=No. of edges
n=No. of nodes
d=No. of decision
r=No. of regions
p=No. of components of whole graph

Table 1.2: Cyclomatic complexity of a graph

Not Strongly connected Strongly connected

1- V(g)= e- n +2p 1 V(g)= e- n +p
2- V(g)= d + p 2 V(g)= d + p
3- V(g)= r 3 V(g)= r – p

V(g)= 8-7+2=3 V(g)= 9-7+1= 3

V(g)= 2+1= 3 V(g)=2+1=3

V(g)= 3 V(g)=4-1

Counting no. of decision nodes (d) for Switch-case/multiple if else: When a decision node
has exactly two arrows leaving it, then we count it as a single decision node [CHA2011].
However, switch case and multiple if else statements having more than two arrows leaving a
16
decision node, then no. of decision nodes will be one less than no. of arrows leaving it as
shown in table 1.3.

Table 1.3: Counting no. of decision nodes

Arrow leaving from a node Counted as No of decision nodes

2 1

K>2 k-1

9. Graph Matrices (Graph matrix and Connection Matrix)

As the size of graph increase manual path tracing becomes difficult and leads to errors. So,
the idea is to develop a software tool which will help in basis path testing . So, Graph Matrix
is a data structure which can assist in developing a tool for automation of path tracking.

Graph Matrix
It is a square matrix whose rows and columns are equal to the number of nodes in the flow
graph; matrix entries represent a connection between the nodes [AGG2006]. Example CFG is
shown in fig. 1.4 and its graph matrix is in fig. 1.5

1. 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‟.

2. To represent a graph matrix, digits are used for nodes and letter symbols for edges.

Fig. 1.4: CFG of example. Fig. 1.5: Graph matrix of example.

a. Graph matrix for finding set of all paths: If A is a initial graph matrix of 1 link path from
one node to other node then if we want to find k link path‟s graph matrix G from every node
to other node then it can be find by following.
A=one length matrix

17
G= A1 + A2 + A3………+ A k

b. Connection Matrix
It is a square matrix, where number of rows and number of columns are equal to number of
nodes in the CFG of a program . In the simplest form when the connection exists, the link
weight is 1, otherwise 0 ( but 0 is not entered in the cell entry of matrix to reduce the
complexity).
c. Cyclomatic complexity automatically: Here is the use of connection matrix in finding
Cyclomatic complexity Number in fig. 1.6 of CFG graph in figure 1.4.
1. For each row, count the total number of 1s and write it in front of that row.
2. Subtract 1 from that count . Ignore the blank rows, if any.
3. Add the final count of each row.
4. Add 1 to the sum calculated in step 3
5. The final sum in Step 4 is the cyclomatic number of CFG.

Fig. 1.6: Connection matrix of example CFG.

18