UNIT-2

Testing Techniques and Levels of Testing

 Testing Techniques

Software testing techniques are methods to check if a software

program works properly, meets its goals, and assesses the quality
of software.
These techniques include different methods, like manual testing,
where testers check the software, and automated testing, where
testers use tools to check. Each method helps find bugs, ensure
features work, or assess how well the software handles pressure.
 Levels Of Testing
In SDLC, we used different levels of testing to find bugs and errors. Those "stages", called Levels
of Testing, help to make sure all components of system are working properly.

Unit testing : Unit Testing is the first step in

testing your software. It focuses on
checking individual components or
functions of the application to make sure
they work correctly on their own.
Mainly features are:
Testing individual functions or components.
Ensuring correct behavior at the smallest level.
Catching errors early.

2. Integration Testing
After unit testing, Integration
Testing takes over. This level checks how
different modules or components of the Integration testing ensures that data flows correctly between modules and
software work together. that they communicate seamlessly. It helps catch problems that might arise
when different parts of the system interact.
3. System testing
System Testing is when you test the software as a system. This stage checks whether the entire system functions as
expected in a real-world environment. It includes both functional and non-functional tests to ensure that the software
meets customer needs.
Full end-to-end testing of the software.
Verifying both functional and non-functional requirements.
Testing the software's behavior in real-world conditions.

4. Acceptance Testing
Acceptance Testing, also known as User Acceptance Testing (UAT), is the final test before releasing the software to the
end-users. In this phase, the customer or end-users verify if the software meets their needs and expectations.
UAT is crucial because it verify the software is ready for production. It’s the last chance to catch any overlooked issues
before deployment. If the software passes this stage, the customer gives the green light for release.
Validating the software against business requirements. Are we building the product right
Ensuring the software meets customer expectations.
Getting final approval from the customer.
 WHITE BOX TESTING
White box testing is a software testing method where the internal logic, code structure, and paths of the
application are tested. It focuses on how the software works, not just what it does.

Why Perform White Box Testing?

Early bug detection, Code optimization, Improves security,
Ensures thoroughness: Tests internal logic, paths, and conditions for complete coverage. means perfection
Boosts quality assurance: Confirms the code works as expected and meets quality standards.

Tools and Frameworks for White Box Testing

JUnit
Eclipse
IntelliJ IDEA
Visual Studio
Types of White Box Testing
Different types of White Box Testing are:

Unit Testing: Tests individual functions or components in isolation to ensure they work correctly.
Static Code Analysis: Analyzes code without executing it to find syntax errors, code smells, or potential bugs.
Dynamic Testing: Examines the code while it runs to evaluate behavior, performance, and memory usage.
Statement Coverage: Ensures every line of code is executed at least once during testing.
Branch Testing: Verifies that all possible branches (if/else conditions) in the code are tested.
Path Testing: Checks that all possible logical paths through the code are executed.
Loop Testing: Tests loops in the code with different iteration conditions to catch errors in looping logic.
7. Penetration Testing
White box penetration testing, also known as crystal or oblique box pen testing, provides the tester with
complete network and system data, including network maps and passwords. This saves time and lowers the
overall cost of an engagement.

penetration meaning is admission or entry

 White Box Testing Example
#include <stdio.h>

int find_max(int a, int b, int c) {

if (a >= b && a >= c)
return a;
else if (b >= a && b >= c)
return b;
else
return c;
}

int main() {
int a = 5, b = 3, c = 1;
printf("Max: %d\n", find_max(a, b, c));
return 0;
}
 White Box Testing Techniques
1. Statement Coverage : One of the main objectives of white box testing is to cover as much of the source code as
possible. Code coverage is a measure that indicates how much of an application’s code contains unit tests that
validate its functioning.

2. Branch Coverage
In programming, “branch” is equivalent to, say, an “IF statement” where True and False are the two branches of an
IF statement. There will be two test conditions in the event of an “IF statement”:
One is used to validate the “true” branch, while the other is used to validate the “false” branch.
3. Path Coverage
Path coverage examines all the paths in a given program. This is a thorough strategy that assures that all program paths
are explored at least once. Path coverage is more effective than branch coverage. This method is handy for testing
complicated applications.

4. Decision Coverage
Decision Coverage is a white box testing methodology that reports the true or false results of each
boolean expression present in the source code. The purpose of decision coverage testing is to cover and
validate all available source code by guaranteeing that each branch of each potential decision point is
traversed at least once.
A decision point is a point when there is a possibility of the occurrence of two or more outcomes from
control flow statements such as an if statement, a do-while statement or a switch case statement.
Expressions in this coverage can become difficult at times. As a result, achieving 100% coverage is quite
difficult.
5. Condition Coverage
Condition coverage, also known as expression coverage, is a testing method for testing and evaluating the variables
or sub-expressions in a conditional statement. The purpose of condition coverage is to examine the outcome of each
logical condition.
Only expressions with logical operands (an operand is considered a logical operand if it has its output as either TRUE
or FALSE) are examined in this coverage. Condition coverage does not ensure complete decision coverage.

6. Multiple Condition Coverage

In this testing technique, all the different combinations of conditions for each decision are evaluated.
For example, we have the following expression,
if (A||B) then print C
So, in this case, the test cases would be as given below:
TEST CASE1: A=TRUE, B=TRUE TEST CASE2: A=TRUE, B=FALSE TEST CASE3: A=FALSE,
B=TRUE TEST CASE4: A=FALSE, B=FALSE
The point to be noted here is that in this example we have 2 expressions A and B, and as result, we have 4 test
cases. So, similarly, for 3 conditions we will have 8 test cases.
So, the general formula for Multiple Condition Coverage is that for n conditions, there will be 2n test cases.
7. Finite State Machine Coverage
Finite state machine coverage is one of the most difficult forms of code coverage approach. This is due to the
fact that it works on the design’s functionality. This coverage approach requires you to count the number of
times a state is visited or transited. It also determines how many sequences are contained within a finite state
system. A sequence in a Finite State Machine is a sorted list of inputs or outputs.

8. Control Flow Testing

This testing technique aims to establish the program’s execution order by use of a control structure.
To construct a test case for the program, the control structure of the program is used. The tester selects a specific
section of a program to build the testing path.
It is used mostly in unit testing. The test cases are represented using the control graph of the program.
The control Flow Graph consists of the node, edge, decision node, and junction node for all execution paths.
 Example for Control Flow Graph
Quick Notes:
Node A node is used to create a basic path for
procedures. It depicts the sequence in which
different operations are to be carried out.
Edge An edge in a control flow graph is used
to link the directions between different nodes.
Decision Node A decision node is used to
determine the next node for a given
procedure as per the result of the last
operation carried out.
Junction Node It is the point where at least
three links meet.
Advantages of White Box Testing
•Optimization of code by the revelation of hidden faults.
•Transparency of the internal code structure helps to derive the
type of input data needed to adequately test an application.
•This incorporates all conceivable code paths, enabling a
software engineering team to carry out comprehensive
application testing.

Disadvantages of White Box Testing

•A complicated and expensive process that involves the skill of
an experienced professional, programming ability and
knowledge of the underlying code structure.
•A new test script is necessary when the execution changes too
frequently.
•Detailed testing with the white box testing approach is
significantly more demanding if the application covers many
different areas, such as the Gojek Super App.
 Structural Vs Static Testing
Static testing and structural testing are both critical components of software quality assurance, but they operate at
different levels and serve different purposes. Static testing is a "verification" method that involves reviewing and
analyzing code and documentation without executing the program. Structural testing, on the other hand, is a type of
white-box testing that examines the internal structure and logic of the code by executing it.

Definitions
Static Testing Static testing is a non-execution-based method of software testing. It's often performed early in the
Software Development Life Cycle (SDLC) to find defects in software artifacts like code, design documents, and
requirements. The goal is to prevent defects from being introduced into the code base. Common static testing
techniques include code reviews, walkthroughs, and static analysis tools.
Structural Testing Structural testing, also known as white-box testing, is a testing technique that analyzes the internal
workings of a software application. It requires an in-depth understanding of the code's structure, logic, and internal
paths. The goal is to ensure that all internal components and logic paths are tested. Examples of structural testing
techniques include statement coverage, branch coverage, and path coverage.
 Static vs. Dynamic vs. Structural Testing: 8 Key Differences
Feature Static Testing Dynamic Testing Structural Testing
Execution No code execution. Code is executed. Code is executed.

To prevent defects by finding errors in

To find defects by observing the software's behavior To ensure coverage of internal code paths and
Purpose documents and code before they're
during execution. logic during execution.
executed.

Performed early (requirements, design, Performed after coding, often by developers or

SDLC Phase Performed later (after coding and compilation).
and coding). during unit testing.

Manual reviews (walkthroughs,

Black-box testing (functional, system, integration)
Techniques inspections) and automated static Statement, branch, and path coverage.
and white-box testing.
analysis tools.

Generally higher as defects are found later in the Varies, but can be highly efficient for ensuring
Cost Generally low as issues are caught early.
cycle, making them more costly to fix. code quality and coverage.

Knowledge of business requirements and Knowledge of user requirements and system Deep knowledge of the internal code structure
Knowledge Required
design. behavior. and logic.

White-box testing, clear-box testing, or glass-box

Also Known As Verification testing. Validation testing.
testing.

Non-executable artifacts (documents, The application's external behavior and The application's internal code, control flow, and
Focus
code). functionality. data flow.
What is a Control Flow Path?
The control flow path testing is a structural testing of the software code. The testers should have the knowledge of
the code structure, design, implementation logic, algorithm in order to carry out the control flow path testing.
However, it is mostly covered by the developers themselves who have actually implemented the code. The entire
implementation logic, and how individual modules of a software are interconnected are tested in this approach.

Process of Control Flow Path Testing

The process of the control flow path tes ng is listed below −
Creation of Control Flow Graph − From the available piece of code, a control flow graph is created manually or by
using a tool.
Coverage Target − A coverage target is described in the control flow graph taking help of the nodes, edges, paths,
branches etc.
Creation of Test Cases − The test cases are created covering all the coverage targets.
Execution of Test Cases − The test cases are executed.
Analysis of Test Results − The results of the test cases execu on are compared to confirm if there are errors in the
software.
What is a Control Flow Graph?
The control flow graph is known as the graphical representation of the complete flow of the program
code. It is primarily used for static analysis and compiler software since it portrays the entire course of
the code.
Characteristics of Control Flow Graph
The characteris cs of a control flow graph are listed below −
It is driven by the complete process followed in the program code.
It discovers every path that can be covered while running the code.
It is a complete directed graph.
Its edges describe the paths that can be traversed, and nodes describe the basic blocks.
It has two sections namely the entry block which directs to the point of entry to the control flow graphs,
and the exit block which directs to the point of exit from the control flow graph.
 Different Components of Control Flow Graph

If-then-else Block While Block Do While Block For Block

 The control flow graph of the above lines of code is given below −
Example
Let us take an example of the
below block of code from where
we would draw the control flow
graph.
IF I = 250
THEN IF J > K
THEN I = J
ELSE I = K
END IF
END IF
PRINT I
Objectives of Control Flow Testing
The objec ves of the control flow tes ng are listed below −
It ensures that all the paths of the code have been traversed at least once.
It ensures that all the conditional points of the code are gauged as false and true at least once.
It ensures that all the probable results of the conditions are touched by running each of the
condition points in the code at least once.
It analyzes how the code runs in various use cases, namely zero, single, and multiple iterations.
It checks how the exception handling is done in the code.
It evaluates both easy and complex conditions in the decision statements.
It reduces the cyclomatic complexity of the code.
It verifies how different components of the software communicate with each other after their
integration.
It verifies how the code reacts when the extreme boundary values are fed into the software.
Advantages of Control Flow Testing
The advantages of the control flow tes ng are listed below −
It detects the maximum number of bugs which will be identified during the unit testing phase.
It is also capable of detecting some portions of bugs which will be identified during the entire testing cycle.
It supports both manual and automation approaches since the control flow graph can be created both
manually or with the help of tools.
Disadvantages of Control Flow Testing
The developer who developed the code is not always able to detect if he has covered all the paths in his own
code during the control flow testing.
A defect bash is an ad hoc testing ,done by
people performing different roles in the
same time duration during the integration
testing phase , to bring out all types of
defects that may have been left out by
planned testing
The testing by all the participants during
defect bash is not based on written test
cases.
What is to be tested is left to individual’s
decision
All the activities in the defect bash are
planned activities, except for what to be
tested
 It involve several steps
1. Choosing the frequency and duration of
defect bash
2. Selecting the right product build
3. Communicating the objective of each defect
bash to everyone
4. Setting up and monitoring the lab for defect
bash
5. Taking actions and fixing issues
6. Optimizing the effort involved in defect
bash
Frequent defect bashes will incur low return
on investment, and too few defect bashes
may not meet the objective of finding all
defects
Duration is also an important factor.
Optimizing the small duration is a big saving
as a large number of people are involved
Since defect bash involves a large number of
people, effort and planning a good quality
build is needed for defect bash

An intermediate build where the code

functionality is evolving or an untested build
will make the purpose and outcome of a
defect bash ineffective
The purpose and objective should be clear

Once they are told in advance, the members

of defect bash team will be in a better
position to contribute towards stated
objective
During the defect bash, the product
parameters and system
resources(CPU,RAM,disk)need to be
monitored for defects and also corrected so
that users can continue to use the system for
the complete duration of defect bash
There are 2 types of defects that will emerge
during the defect bash

The defects that are in the product, as

reported by the users are called functional
defects

Defects that unearthed while monitoring the

system resources, such as memory leak,long
turnaround time and so on are called non-
functional defects
Take necessary corrective action after the
defect bash

It is difficult to solve all the problems if they

are taken one by one and fixed in code.

The defects need to be classified into issues

at a higher level, so that a similar outcome
can be avoided in future defect bashes
Conduct “micro level” defect bashes before
conducting one on a large scale

Since a defect bash is an integration testing

phase activity, it can be experimented by
integration test team before they open it up
for others
Defect bash can be further classified into

Feature /component defect bash

Integration defect bash
Product defect bash