Unit 2
Types of Testing
Testing
Static Dynamic
Reviews Functional
Structural
Inspections
(Functionality of
Walkthrough (Logic of the Program)
the program)
Black Box Testing White Box Testing
Static Testing Dynamic Testing
Definition •Definition
Static testing is performed to check the Dynamic testing is performed to analyze
defects in the software without actually the dynamic behavior of the code.
executing the code.
Objective Objective
The objective is to prevent defects. The objective is to find and fix defects.
Static Testing?
It also known as Verification testing or Non-execution testing is a type of Software
Testing method that is performed to check the defects in software without actually
executing the code of the software application.
Static testing is performed in the early stage of development to avoid errors as it is
easier to find sources of failures and it can be fixed easily.
It involves assessing the program code and documentation.
It involves manual and automatic assessment of the software documents.
Documents that are assessed in Static Testing
are:
Test Cases
Test Scripts.
Requirement Specification.
Test Plans.
Design Document.
Source Code.
Static Testing Techniques
Informal Reviews
Walkthroughs
Technical Reviews:
Code Reviews
Inspection
Benefits of Static Testing
Early detection of defects:
Cost-effective:
Easy to find defects:
Increase development productivity:
testing increases development productivity due
Static to quality and
understandable documentation, and improved design.
Identifies coding errors: Static testing helps identify coding errors
to and
syntax issues resulting in cleaner and more maintainable code.
Sr. No. Static Testing Dynamic Testing
1. Static Testing done without Dynamic Testing done by executing
executing the progıam. the program.
2. This testing does verification Dynamic testing does the validation
process. process.
3. Static testing is about prevention of Dynamic testing is about finding
defects. the defects.
4. Dynamic testing gives bugs/
Static testing gives assessment of
code and documentation. bottlenecks in the software system.
5. Static testing involves a checklist Dynamic testing involves test cases
and process to be followed. for execution.
6. This testing can be performed Dynamic testing is performed
before execution. during execution.
7. Cost of finding defects and fixing Cost of finding and fixing defects is
them is low. high.
8. Return on investment will be high Return on investment will be low as
as this process is involved at early this process involved after the
stage. coding phase.
9. More reviews and comments are Early defects are highly
highly recommended for good recommended for good quality.
quality.
10. Requires loads of meetings. Comparatively requires lesser
meetings.
What is White Box Testing?
White Box Testing is also called Clear Box Testing, Glass Box Testing, or
Structural Testing.
In this, the internal logic, structure, and code of the software are tested.
The tester knows the internal code of the application and creates test cases
based on it.
Design and code
Input Output
White Box
Process of Software White Box Testing
Inputs - It includes the specifications, requirements, architecture and design
documents, and the source code.
Processing - It includes identification of all the probable risks in the software.
Test Planning - It includes the creation, and execution of test cases as per the
test plan.
Reporting - It includes the evaluation of test execution results, and reporting
the errors. Once completed, the report is shared with the stakeholders.
Types of White Box Testing
White box
testing
Integration
Unittesting
testing
Execution Operations Mutation Top Down Bottom Up Hybrid
testing testing testing Approach Approach Approach
Statement Branch Path
Coverage Coverage Coverage
What is Unit Testing?
Definition:
Unit testing involves testing small, individual modules (functions,
methods, or classes) of a program to ensure that they work correctly in isolation.
It verifies the correctness of code logic, internal functions, and data flow inside
each module.
Performed early in the development cycle by developers (or testers with
programming knowledge).
1. Execution Testing:
• Tests if all code statements execute correctly without errors.
Uses coverage techniques such as:
Statement Coverage: Ensures every line of code is executed.
Branch Coverage: Ensures all decision paths (if/else) are tested.
.
Path Coverage: Ensures all possible execution paths are tested.
Note:
The statement, branch, or path coverage does not identify any bugs or
defects that need to be fixed.
It only identifies those lines of code which are either never executed or
remain untouched. Based on this, we can focus on further testing.
1. Statement Coverage
Definition: Ensures that every line (statement) in the code is executed at
least once during testing.
Goal: Detect errors in statements that may not be executed under normal
conditions.
Statement Coverage = Number of Executed Statements Example:
X 100
Total Number of Statements
if (x > 0)
printf("Positive");
printf("Done");
Test with x=5 (covers both lines).
Test with x=-3 (only the second line executes).
Test Cases for Statement Coverage
Example Code Statements in Code Test Cases (Inputs) Explanation
1. Check 1. if (n > 0) TC1: n = 5 With n=5, lines 1, 2,
Positive/Negative 2. printf("Positive"); TC2: n = -2 and 4 are executed.
3. printf("Negative or With n=-2, lines 1, 3,
Zero"); and 4 are executed.
4. printf("End");
2. Voting Eligibility TC1: age 20 Both inputs ensure
if (age >= 18)
=
TC2: age = 15 each line runs at least
2. printf("Eligible");
once (True/False
3. printf("Not Eligible");
branches of if).
4. printf("End");
3. Find Maximum of TC1: a=10, b=5 First test covers line 2,
1. if (a > b)
Two TC2: a=3, b=7 second covers line 3.
2. printf("A is max");
3. printf("B is max or
equal");
Branch Coverage
Branch coverage (also called decision coverage) is a white-box testing
technique that ensures every possible branch (True/False) in a decision structure
(e.g., if, switch, for) is executed at least once.
It measures whether both the true and false outcomes of a condition have been
evaluated during testing.
Why Branch Coverage is Important?
A program can have untested branches that may contain hidden bugs.
Statement coverage alone is not enough because a statement can be
executed without covering all decision outcomes.
Example
if (x > 0)
A test case with x = 5 would achieve statement
printf("Positive");
else coverage but NOT branch coverage, because
the else branch (x <= 0) is not tested.
printf("Negative or
Zero");
Branch Coverage (%) is calculated as:
Number of branches executed
Branch Coverage =
100
Total number of branches
Advantages of Branch Coverage:
Detects missing or conditions.
untested
Ensures more thorough testing than statement coverage.
Identifies logical errors in decision-making.
•
Disadvantages:
Does not guarantee all paths are tested (e.g., combination of
conditions in nested decisions).
Path Coverage:
Path Coverage ensures that all possible execution paths in a program are
tested at least once.
Example:
Possible Paths:
void checkNumber(int x) {
if (x > 0) { Path 1: x > 0→ prints "Positive".
printf("Positive"); Path 2: x < 0 → prints "Negative".
} else if (x < 0) { Path 3: x ==0→ prints "Zero".
printf("Negative");
} else { Test Cases for Path Coverage:
printf("Zero"); To cover all paths,
TC1: x = 5 (Covers Path 1: Positive)
} TC2: x = -3 (Covers Path 2: Negative)
TC3: x = 0 (Covers Path 3: Zero)
2. Operations Testing:
Focuses on verifying specific operations or functions within the
module.
Ensures thatinput-output mappings, logic operations, and data
manipulations within a function work correctly.
3. Mutation Testing:
Involves modifying the code slightly (mutations) to check if the
existing test cases can detect errors.
Helps to measure the effectiveness of test cases.
Example: Changing > to < or + to - in the code and seeing if the test
fails (it should).
Integration Testing
Integration Testing is defined as a type of testing where software modules are
integrated logically and tested as a group.
A typical software project consists of multiple software modules, coded by
different programmers.
The purpose of this level of testing is to expose defects in the interaction
between these software modules when they are integrated
Integration Testing focuses on checking data communication amongst these
modules.
A Module, in general, is designed by an individual software developer
whose understanding and programming logic may differ from other
programmers.
Integration Testing becomes necessary to verify the software modules work
in unity
Example
Scenario:
Application has 3 modules say 'Login Page', 'Mailbox' and 'Delete
emails' and each of them is integrated logically.
이
Here do not concentrate much on the Login Page testing as it's already
been done in Unit Testing.
But check how it's linked to the Mail Box Page.
Similarly Mail Box: Check its integration to the Delete Mails Module.
Test
Case Test Case Objective Test Case Description Expected Result
ID
Check the interface link Enter login credentials
To be directed to the Mail
1 between the Login and and click on the Login
Box
Mailbox module button
Check the interface link From Mailbox select the Selected email should
2 between the Mailbox and email and click a delete appear in the Deleted/Trash
Delete Mails Module button folder
Types of Integration Testing
1. Big Bang Approach :
2. Incremental Approach: which is further divided into the following
• Top Down Approach
Bottom Up Approach
Approach Combination of Top Down and Bottom Up
•
Sandwich -
Big Bang Testing
all the components or modules are integrated together at once and then
tested as a unit.
This combined set of components is considered as entity while testing.
an
If all of the components in the unit are not completed, the integration
process will not execute.
Advantages:
Convenient for small systems.
Disadvantages:
Fault Localization is difficult.
Incremental Testing
Testing is done by integrating two or more modules logically related
that are
to each other and then tested for proper functioning of the application.
Then the other related modules are integrated incrementally and the process
continues until all the logically related modules are integrated and tested
successfully.
Bottom-up Integration Testing
A strategy in which the lower level modules are tested first.
These tested modules are then further used to facilitate the testing of higher
level modules.
The process continues until all modules at top level are tested. Once the
lower level modules are tested and inteorated then the next level of modules
are
Module
1
Module Module
2 3
Bottom
Module Module Module
Up 4 5 6
Drivers are used to simulate the higher-level modules until they are
developed.
Example
Scenario: ATM System
1. ATM Interface
2. Transaction Module 3. Account Info Module
4. Balance Module 5. PIN Verification Module
Step 1: Test the lowest-level modules first
• Modules 4 (Balance) and 5 (PIN Verification) are developed and tested
first.
A test driver is written to simulate calls from upper modules.
•
Example Driver for Balance Module:
int
} main()
float balance = getBalance(12345); // 12345 is dummy account number
printf("Balance: %.2f\n", balance);
return 0;
}
Step 2: Integrate level
next
•Transaction Module (2) and Account Info Module (3) are now
integrated with tested lower modules.
•Replace test drivers with real module calls.
Advantages:
Fault localization is easier.
No time is wasted waiting for all modules to be developed unlike Big-bang
approach
Disadvantages:
Critical modules (at the top level of software architecture) which control the
flow of application are tested last and may be prone to defects.
Top-down Integration Testing
A method in which integration testing takes place from top to bottom
following the control flow f software system.
The higher-level modules are tested first and then lower-level modules are
tested and integrated in order to check the software functionality.
Module
1
Top Down
Module Module
2 3
Module Module Module
4 5 6
In top-down testing, stubs are used.
Stubs are temporary code modules that simulate the behavior of lower-level
(not-yet-developed) modules.
They're used when those modules are not ready but the higher-level modules
(which call them) need to be tested.
Example:
Suppose we are testing the Library System module which calls the Search
module, but Search isn't developed yet.
In real code, it might look like this:
// In LibrarySystem.c
void LibrarySystem() {
printf("Welcome to Library System\n");
SearchBook(); // Call to lower-level module
}
But SearchBook() is not implemented yet.
So, we write a stub:
Stub for SearchBook():
// This is a SearchBook)
stub for
void SearchBook() {
printf("[Stub] SearchBook() called\n");
printf("Simulating book found: 'Introduction to C
Programming'\n");
Now when we the LibrarySystem()
run function, it will call the stub
instead of the actual SearchBook().
Test Case Design
Designing of White Box Test Case:
1. Basis Path Testing
1. Draw the flow graph
2. Calculate the cyclometric complexity
2. Coverage Testing
1. Statement coverage-code and data coverage
2. Branch and decision coverage