What is basis path testing?

Basis path testing is a type of white-box testing that tests all possible
independent paths in the control flow graph of a program.

Note:

A path is the route of nodes in the control flow graph that a program takes from
one point to another.

An independent paths of a program are all unique.

Steps for basis path testing

Draw the control flow graph of the program.

cyclomatic complexity of the control flow graph. This will be

Calculate the
the maximum number of independent paths in the graph.

Identify independent paths in the control flow graph.

Design test cases based on the independent paths identified so that the test
cases execute all independent paths.
Example

Consider the code below, for which we will conduct basis path testing:

int num1 = 6;
int num2 = 9;
if(num2 ==0)
{

cout<<"num1/num2 is undefined"<<endl;
}
Else

if(num1 > num2)

{ cout<<"num1 is greater"<<endl;

Else

{
cout<<"num2 is greater"<<endl;
 Start 1

int num1 = 6; 2

int num2 = 9; 3

C
4
D Yes No E
if num2 == 0

Print "num1/num2 5 6 No
is undefined" Yes if num1 > num2

G H

Print "num1 is 7 Print "num2 is 8

F greater" greater"

End

9
Step 2: Calculate cyclomatic complexity

The cyclomatic complexity of the control flow graph above will be:

Cyclomatic complexity = E - N + 2*P

Cyclomatic complexity = 10 - 9 + 2*1

Cyclomatic complexity = 3

where,

E = The number of edges in the control flow graph.

N = The number of nodes in the control flow graph.
P = The number of connected components in the control flow graph
Step 3: Identify independent paths

The independent paths in the control flow graph are as follows:

Path 1: 1A-2B-3C-4D-5F-9
Path 2: 1A-2B-3C-4E-6G-71-9
Path 3: 1A-2B-3C-4E-6H-8J-9
Step 4: Design test cases
The test cases to execute all paths above will be as follows:

Path Input values

Path 1: 1A-2B-3C-4D-5F-9 num1 = 9
num2 = 0

num1 = 4
Path 2:1A-2B-3C-4E-6G-71-9 num2 = 2

Path 3: 1A-2B-3C-4E-6H-8J-9 num1 = 6

num2 = 8
Coverage testing :

refers to the measurement and analysis of how much of a software

application's code or functionality has been executed during the testing
process.

It provides a quantitative metric to assess thoroughness of a

the test suite and
identify areas that may not have been adequately tested.
•Test Coverage (Functional/Requirements Coverage):

This focuses on how thoroughly the functional requirements and user scenarios

of an application have been covered by the tests.

It ensures that the software meets its intended functionality and user

expectations.
Code Coverage:
This measures the percentage of the codebase that has been executed by a test suite.
Common types of code coverage include:
Statement Coverage:
Measures the percentage of executable statements in the code that have been run.

Branch/Decision Coverage:
Measures the percentage of decision points (e.g., if-else statements, loops) where all
possible outcomes have been tested.
Condition Coverage:
Measures the percentage of boolean conditions where all possible true/false outcomes
have been tested.
Path Coverage:
Measures the percentage of distinct paths through the code that have been exercised.
Black Box Testing

A method in which the functionalities of software applications are tested

without having knowledge of internal code structure, implementation details
and internal paths.

focuses on input and output of software applications and it is entirely based

on software requirements and specifications.

Black Box Testing

Input BLACK Output

BOX
 Black Box Testing Techniques

Equivalence Class Testing: It is used to minimize the number of

possible test cases to an optimum level while maintains reasonable test
coverage.

Boundary Value Testing:

Decision Table Testing: A decision table puts causes and their

effects in a matrix. There is a unique combination in each
column.
Equivalence Class Testing:
It is used to minimize the number of possible test cases to an

optimum level while maintains reasonable test coverage.

Reasons for Using ECP

Purpose Explanation
Reduce number of test Instead of testing possible input, ECP lets you
every
cases test one representative from each group (partition),
saving time and effort.
Ensure good test Helps cover all important types of inputs (valid and
coverage invalid) without missing edge cases.

void redundant testing Since all values in one partition are expected to
behave the same way, there's no need to test them all.

Improve efficiency Focuses testing only the most meaningful inputs,

on

which speeds up the testing process.

 Example to understand the need

If a function accepts marks from 0 to 100, without ECP, you might test:

0, 1, 2, 3, ..., 99, 100 101 test cases!

With ECP, you divide into:

Valid: 0-100 → test with 50

Invalid: < 0 → test with -5

Invalid: > 100 → test with 110

Only 3 test cases, but still good coverage.

Key Idea:
Divide input data into equivalent groups where all values in a group should
be treated the same.
Test one value from each group, not every value.

Example: Age Validation

Suppose a system allows only users aged between 18 and 60 to register.

Step 1: Identify Input Condition

Valid age: 18 to 60
Step 2: Create Equivalence Partitions

Partition Type Range Example Value

Valid 18-60 30

Invalid Less than 18 16

Invalid Greater then 60 65

Step 3: Design Test Cases

Test Case ID Test Input Expected Result Partition Type

TC01 30 Accept registration Valid

TC02 16 Reject registration Invalid
TC03 65 Reject registration Invalid
 Consider a field in a form asking for PIN code (6-digit only).

Valid class: 100000 to 999999

Invalid classes: Less than 6 digits (e.g., 123)

More than 6 digits (e.g., 1234567)Non-numeric characters (e.g.,
AB123C)

Test cases would be::::

One valid PIN (e.g., 560001)

One short PIN (e.g., 123)
One long PIN (e.g., 1234567)
One non-numeric (e.g., AB123C)
 Boundary Testing
Boundary testing is the process of testing between extreme ends or boundaries
between partitions of the input values.

Boundary value testing is focused on the values at boundaries.

This technique determines whether a certain range of values are acceptable by the
system ornot.
It is very useful in reducing the number of test cases. It is most suitable for the
systems where an input is within certain ranges.

These extreme ends like Start- End, Lower- Upper, Maximum-Minimum values
are called boundary values and the testing is called "boundary testing".
The basic idea in normal boundary value testing is to select input variable values
at their:

Minimum
Just above the minimum
A nominal value

Just below the maximum

Maximum
 a b
X

x(min) x(min-) x(nom) x(max+) x(max)

In Boundary Testing, Equivalence Class Partitioning plays a good

role.

Boundary Testing comes after the Equivalence Class Partitioning.

Invalid Valid Invalid Invalid

Ο 1 10 11 99 100

Partition 1 Partition 2 Partition 3 Partition 4

In BOUNDARY VALVE ANALYSIS You will check

the boundary valves like 0, 1. 10, 11, 99, 100

We test values at both valid and invalid boundaries.

Boundary Value Analysis is also called range checking.

Example: Age Validation

System rule: Age must be between 18 and 60 (inclusive)

Step 1: Identify Boundaries

Lower boundary: 18
Upper boundary: 60
Step 2: Choose Test Values

Test Case ID Test Value Reason Expected Result

TC01 17 Just below lower limit Reject registration
TC02 18 At lower limit Accept registration

TC03 19 Just above lower limit Accept registration

TC04 59 Just below upper limit Accept registration
TC05 60 At upper limit Accept registration

TC06 61 Just above upper limit Reject registration

If a banking app allows withdrawals between ₹500 and *25,000:

Test with: ₹499, ₹500, ₹501, 24,999, ₹25,000, ₹25,001

Decision Table Testing

Example: Login Screen

Rules:
User must enter a valid username.

User must enter a valid password.

If either username or password is wrong → Show error.
If both are correct → Login success.
Step 1 - Identify Conditions & Actions

Conditions: Username is correct? (Y/N)

Password is correct? (Y/N)
Actions: Login success.
Show error message.

Step 2 - Create Decision Table

Rule No. Username Correct? Password Correct? Action

1 Y Y Login Success

2 Y N Show error

3 N Y Show error

4 N N Show error
 Step 3 - Derive Test Cases

Test Case ID Input Expected

Output
TC01 Correct username + Correct Login success

password
TC02 Correct username + Wrong Show error

password
TC03 Wrong username + Correct Show error
password
TC04 Wrong username + Wrong Show error

password

Example of growth:
State Transition Testing

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.
Example:

If the user enters a valid password in any of the first three attempts the
user will be able to log in successfully.

If the user enters the invalid password in the first or second try, the user

will be prompted to re-enter the password.

When the user enters password incorrectly 3rd time, the action has taken,
and the account will be blocked.
State Transition Diagram

Incorrect Pln Incorrect Pin

Start 1St Try 2nd Try 3rd Try

Correct PIN
Incorrect Pin

Correct PIN

Access Account

Granted Blocked

In thisdiagram when the user gives the correct PIN number, he or she
is moved to Access granted state.
State Transition Table

Correct PIN Incorrect PIN

S1) Start S5 S2

S2) 1st att ipt S5 S3

S3) 2nd attempt S5 S4

S4) 3rd attempt S5 S6

S5) Access Granted

S6) Account blocked

 Advantages of Black Box Testing

The testers do not require programming and technical skills to start

working on the black box testing.

It is effective in adopting black box testing in large systems.

Every test conducted here is done from the customers perspective.

Disadvantages of Black Box Testing

It is not possible to create test cases with incomplete requirements.

It is not easy to carry out black box testing with multiple sets of input data at
the various testing stages.

It is not possible to detect the root cause of a defect.

The intermediate stages of the software go untested.

[Link] Black Box Testing White Box Testing

The internal working of the software is not The internal working of the software is
1
known to the testers. known to the testers.

Itonly deals with the inputs fed to the It deals with the independent code
2 software and the outputs generated from snippets, algorithms, methods, functions
them. etc.

It only verifies the software functionalities

3
It verifies the internal working of the
and if they are working as per the user
software.
requirements.

It does not require technical skills and It requires technical skills and
4
programming knowledge of the testers. programming knowledge of the testers.

It uses equivalence
methods like It uses methods like statement coverage,
5 partitioning, boundary value analysis, error boundary value analysis, data flow,
guessing etc. control flow etc.

It mainly focuses on the functional It mainly focuses on the unit, integration,

6
periphery of the software. and system level testing of the software.
Grey Box Testing

Grey Box Testing is a software testing technique to test a software product or

application with partial knowledge of internal structure of the application.

The purpose of grey box testing is to search and identify the defects due to

improper code structure or improper use of applications.

Gray Box Testing is a software testing method, which is a combination of

both White Box Testing and Black Box Testing method.
In White Box testing internal (code) is known
structure
In Black Box testing internal structure (code) is unknown
In Grey Box Testing internal structure (code) is partially known

=
Black Box White Box Gray Box
Testing Testing Testing

Gray Box Testing gives the ability to test both sides of an application,
presentation layer as well as the code part.
Advantages of Gray Box Testing

The developers and testers are fully aware of the expectations from them while

testing the software.

It is performed from the customers viewpoints.

It does not require extensive technical and coding knowledge from the testers.

It helps in enhancing the overall quality of the software.

It is found to be more productive than performing simple integration testing on
the software.