Module 2 White box and black box testing.

PART I-Topics
White box testing
Static testing.
1. Static testing by human(desk checking,code walk through,formal inspection etc)
2. Static analysis tools
Structural testing
1. Unit/code testing
2. Code coverage testing(statement,path,condition ,function coverage)
3. Code complexity testing

White box testing

What is white box testing ?
White box testing is a software testing technique that focuses on the internal
structures and workings of an application. Testers utilize their knowledge of the
code, algorithms, and architecture to verify that inputs flow correctly through the
code and that specific functions execute as intended. This method allows for the
identification of potential vulnerabilities or errors.

Also known as clear box testing or structural testing, white box testing differs
from black box testing, which looks at the software's inputs and outputs without
considering its internal workings. White box testers analyze the code to create
comprehensive test cases that cover all possible paths, conditions, and branches,
ensuring thorough coverage and reliability of the application.

1
 I. Static testing.
Static testing is a software testing method that involves examining the
code, documentation, or any other project artifacts without executing the
program. The goal is to identify defects, ensure compliance with
requirements, and improve the quality of the software early in the
development process.
Going through the code to find out
• The code working according to the functional requirements.
• The code has been written in accordance with the design
developed earlier in the project life cycle
• The code for any functionality has been missed out.
• The code handles errors properly.
Examples(code reviews, walkthroughs ,inspections)

Static testing can be done by humans or with the help of

specialized tools.
1. Static testing by human
• Sometimes humans can find errors that computers cannot.
• By making multiple humans read and evaluate the program ,we
can get multiple perspectives and there fore have more problems
identified than a computer could.
• A human evaluation of the code can compare it against the
specifications or design and thus ensure that it does what is
intended to do.
• A human evaluation can detect many problems at one go and can
even try to identify the root causes of the problems.
• By making human test the code before execution ,computer
resources can be saved.
• A proactive method of testing like static testing minimizes the
delay in identification of the problems.
• Finding the defects later in the cycle can create pressure on
programmers resulting in higher chances of defects creeping in.
Static testing by human different methods.
1. Desk checking of the code

2
 • Normally done manually by the author of the code before
compiling and executing.
• desk checking is the method to verify the portions of the code for
correctness by comparing with design or specification.
• Completely relies on authors thoroughness, diligence and skill.
• This method is characterized by:
o No structured method or formalism to ensure
completeness.
o No maintain of a log or checklist.
• Advantages.
o An expert programmer is well equipped to read and
understand his own code.
o Since this is done individually there are fewer scheduling
and logistics overheads .
o The defects are detected and corrected with minimum time
delay .
• Disadvantages
o The developer is not the best person to detect problem in
his own code.
o He may be tunnel visioned and have blind spots to certain
problems
o Developers generally prefer to rewrite code rather than
testing
o This method is person dependent and informal ,thus may
not work consistently across all developers.

2. Code walkthrough.
• Group oriented method bringing multiple perspectives.
• Set of people look and the program code and raise questions to
the auther for which he has to answer or find answer.
3. Code review.
Code review is a static white box testing technique in which the source
code is manually examined by humans without executing the program.
Since the internal logic and structure of the code are visible, reviewers
analyze it to detect logical errors, coding standard violations,
inefficiencies, and security issues. It is typically performed by peers or
senior developers and helps in early defect detection, improving code
quality, and ensuring maintainability.

4. Code Inspection-Formal inspection also called Fagan inspection.

3
 • High degree of formalism.
• Focus is to detect all faults, violations and other side effects.
• Defects are detected by
o Demanding thorough preparation before inspection
o Enlisting multiple diverse views.
o Assigning specific roles to multiple participants.
o Going sequentially through the code in a structured
manner.

• Should takes place after desk checking and walkthrough.

• When the code is ready arrange an inspection meeting . there are
4 roles
Author: is the person who has written the code
Moderator-Formally run the inspection ,author or moderator
select the team.
Inspectors-Provide review comments for the code
Scribe – formally documents the defects,takes detailed notes
during meetings and circulate to the team.

The chosen members have the skillset to uncover asmany defects as possible . in
an introductory meeting ,the inspectors get copies of the code to be inspected
along other supporting documents such as design documents ,requirements
documents and any documentation of applicable [Link] author also present
his or her perspective of what the program intended to do along with any specific
issues that he may want the inspection team to put extra focus on .
The moderator informs the team abot the date ,time and venue of the
inspection [Link] inspectors get adequate time to go through the documents
and programs and ascertain their compliance to the requirements ,design and
standards.
The inspection team assembles ,the moderator takes the team sequencially
through the program ,asking inspectors if there any defects in that part of the
program. If any of the inspectors raises a defect then the inspection team
deliberates on it and when agreed that there is a defect ,classifies it in two
dimensions -major/minor and systemic / mis execution
( mis execution happens because of an error or slip on the part of the author-it is
unlikely to be repeated. systematic defects need correction at different level.
Minor defects that may not substantially affect a program., where as major need
immediate attention

4
 • Benefits: Formal inspections have been shown to be effective in catching
defects early, as they involve diverse viewpoints and a systematic approach to
code review.
• Challenges: While beneficial, formal inspections can be time-consuming and
logistically challenging due to the involvement of multiple participants. It may
not always be feasible to inspect every line of code, so prioritizing critical or
complex sections is essential.

Overall, formal inspections are a vital part of static testing that helps ensure code
quality and adherence to standards before the software is executed.

2. Static analysis tools.

All the above mechanisms need significant amount of manual work.
There are static analysis tools that can reduce the manual work and
perform manual work and perform analysis of the code to find out
following types of errors
1. Whether there are unreachable code (usage of GOTO statements
sometimes creates this situation; there could be other reasons too.
2. Variables declared but not used.

3. Use non portable or architecture dependent programming

constructs .
4. Memory allocated but not having corresponding statements for
freeing up memory.
5. Calculation of cyclomatic complexity

Popular Static Analysis Tools

1. SonarQube: Supports multiple languages; detects code smells, bugs, and

vulnerabilities.
2. Checkstyle: Focuses on Java code and enforces coding conventions.
3. FindBugs/SpotBugs: Java-specific tool for identifying bugs.
4. PMD: Identifies problematic patterns in Java and other languages.
5. Coverity: Finds critical defects in a wide range of programming languages.
6. Cppcheck: Specialized for C and C++ code analysis.
7. Lint Tools (e.g., ESLint, PyLint): Analyzes JavaScript, Python, and other
scripting languages for stylistic errors and bugs.
8. Fortify Static Code Analyzer: Focuses on security vulnerabilities across
languages.

Structural Testing.

5
 Structural testing, also known as white-box testing, involves testing the
internal structure, design, and implementation of the software. It ensures that
the code behaves as expected and adheres to its intended design by focusing
on the control flow, data flow, and logic of the program.
Structural tests are actually run by the computer on the built product . ,where
as in static testing the product is tested by humans using just the source code
and not the executables.
Classification of Structural Testing
I. Unit/code functional testing.
This initial part of structural testing corresponds to some quick checks that a
developer perform before subjecting the code to more extensive code coverage
testing or code complexity testing.
This is a subset of structural testing focused on verifying the smallest functional
parts of a program, typically individual functions or methods, by analyzing their
internal logic and structure.

This process involves testing specific sections or modules of the code for basic
functionality. Key methods include:

1. Quick Tests:
o Perform simple tests with known input and expected output values.
o These tests help catch obvious errors early.
2. Debug Versions for Complex Logic:
o Create a debug version of the product.
o Use intermediate print statements to verify the execution of loops
and conditions.
o Remove these statements once defects are fixed.
3. Debugger/IDE Usage:
o Use debugging tools to step through code line-by-line.
o Allows setting breakpoints, monitoring variable values, and
analyzing system parameters

II. Code Coverage Testing

This involves measuring how much of the program code is exercised during
testing. It ensures that test cases adequately cover the code.

Types of Code Coverage:

1. Statement Coverage: Ensures every executable statement is run at least

once.
6
 2. Path Coverage: Tests all possible paths through the code.
3. Condition Coverage: Verifies all logical conditions are tested (true/false).
4. Function Coverage: Ensures all functions are called during testing.

[Link] Coverage

Statement coverage ensures that all executable statements in the code are tested
at least once during testing. It focuses on achieving coverage for different types
of program constructs found in most programming languages, such as:

• Sequential Control Flow

• Two-Way Decision Statements (e.g., if-else)
• Multi-Way Decision Statements (e.g., switch)
• Loops (e.g., while, do-while, for, etc.)

Sequential Control Flow:

o Statements are executed from top to bottom.

o Test cases can be written to ensure all statements are covered.
o However, exceptions like runtime errors (e.g., division by zero) or
multiple entry points in a section may lead to incomplete coverage.

Two-Way Decision Statements (if-else):

o Both the then and else branches should be tested.

o At least one test case is required for each branch to ensure all
statements in both parts are executed.

Multi-Way Decision Statements (switch):

o Each case in a switch statement should be treated as an independent

if condition.
o Multiple test cases are needed to cover all possible switch cases.

Loops:

o Loops should be tested with boundary conditions, including:

▪ Zero iterations (loop not entered).
▪ A single iteration.
▪ Multiple iterations.
o Boundary conditions often cause defects, such as improper loop
termination conditions.

Statement coverage =(Total staements exercised /total no of executable

statementsin program)*100
2. Path coverage
7
Path coverage testing is a type of white-box testing technique that ensures every
possible path in a program's control flow is tested at least once. It aims to evaluate
all the execution paths within the software, including decisions and branches, to
verify that each path produces the expected results.

In path coverage testing, a path is a unique route taken through the control flow
graph of the program, starting from the entry point and ending at the exit point.
The goal is to identify and test all possible paths, including those that may be less
frequently executed or hidden.

Path coverage =(total paths exercised /total no of paths in program)*100

3. Condition coverage

Condition coverage (also known as predicate coverage) is a white-box testing

technique that focuses on testing the individual conditions within decision
statements (e.g., if, while, for, etc.). In condition coverage, each condition in a
logical expression is evaluated both to true and false at least once during the
testing process.

The primary goal of condition coverage is to ensure that each boolean sub-
expression (condition) in a decision has been evaluated to both true and false
during testing. This is particularly useful for detecting errors where individual
conditions within compound logical expressions may not be exercised correctly.

Condition coverage=(total decisions exercised /total no of decisions in

program)*100

4. Function coverage
Function coverage is a code coverage metric in software testing that measures the
extent to which all functions in the source code are executed during testing. It
ensures that every function is invoked at least once, helping to identify untested
or unreachable functions, which could indicate dead code or inadequate testing.
Measured as the percentage of functions called out of the total, it provides a
simple and high-level overview of testing completeness. While it highlights
untested areas, it does not verify the correctness of outputs or the internal logic
of functions. Often used in white-box testing, function coverage is most effective
when combined with other metrics like statement or branch coverage for more
thorough evaluation.
Function Coverage=(Total number of functions/Number of functions cal
led)×100.
Advantages

8
 • Simplicity and Understandability: Function coverage is one of the simplest
forms of coverage metrics, making it easy for testers and developers to
comprehend and implement.
• Ensures Functionality is Invoked: It guarantees that all functions in the
code are at least executed once, which helps ensure no part of the
application remains untested at the functional level.
• Detection of Dead or Unreachable Code: By identifying functions that are
never called during testing, it can help highlight potential dead code or
functionality that may no longer be required.
• Foundation for Comprehensive Testing: Function coverage provides a
starting point for more detailed coverage analysis, such as branch and
statement coverage, and encourages the creation of test cases that cover all
functions.
• Improves Test Case Design: Helps testers design test cases systematically
to ensure that no functions are left untested.

III. Code Complexity Testing

Code complexity testing involves analysing the structure of code to assess its
complexity, which can affect the software's reliability, maintainability, and
testability. Metrics like cyclomatic complexity are commonly used.

Metrics Used

Cyclomatic Complexity:

Developed by Thomas McCabe, this metric calculates the number of

independent paths through a program.

A program is represented in form of a flow graph which consist of nodes and

edges .inorder to convert a standard flow chart in to flow graph following steps
can be taken

Identify the decision nodes

Combine all sequential statements into a single node.

Make sure that all the edges terminating at some node.

A Control Flow Graph (CFG) is a graphical representation of all possible

paths that can be traversed through a program during its execution. It consists of
nodes (representing basic blocks of code or statements) and edges (representing
control flow between these blocks).

Formula: M=E−N+2P

9
 ▪ E = Number of edges in the control flow graph.
▪ N = Number of nodes.
▪ P = Number of connected components (e.g., functions or
modules).
o Higher values indicate more complex code, which is harder to test
and maintain.

Complexity value 1 to 10 -well written code,testability is high,cost/effort to

maintain is low

10 -20-moderately complex ,testability is medium,cost/effort to maintain is

medium

20 -30- very complex,testability is low, cost/effort to maintain is high.

>40 not testable ,any amount of money /effort to maintain may not be enough.

Challenges in white box testing.

In simpler terms, the challenges of white box testing are:

1. Complex Code:
o When the code is complicated, it’s harder to understand and test
every part of it properly.
2. Takes Time:
o Testing every detail of the code takes a lot of time, especially for
larger programs.
3. Hard to Test Everything:
o It’s difficult to test all possible paths or branches in the code, which
means some parts might be missed.
4. Requires Technical Skills:
o Testers need to know how to read and understand the code. Not all
testers are programmers.
5. Creating Test Data:
o You need to create the right kind of input data to test the code
thoroughly, which can be tricky.
6. Keeping Tests Up-to-Date:
o As the code changes, the tests need to be updated too, which can be
a lot of extra work.
7. Misses User Experience:
o White box testing focuses on code, not how users interact with the
software. So, issues with the interface might be missed.
8. Doesn’t Test Non-Functional Aspects:
o Things like performance or security are hard to test with white box
testing, which focuses mainly on functionality.
9. False Results:
10
 o Sometimes, the tests might show problems that aren't there (false
positives) or miss real problems (false negatives).
[Link] Many Tests:
o If the system is big, you might end up with too many tests to
manage, which can become overwhelming.
[Link] Limitations:
o Tools used for testing might not support all programming
languages or complex systems, making the process harder.
[Link] Modular Code:
o When code is split into many parts or modules, testing all
combinations can become very complicated.

Despite these challenges, white box testing helps find bugs early in the code,
making it an essential part of the software development process.

****************************************************************

PART 2
Black Box Testing.
WHEN to do
How to do
• Requirements based testing
• Positive and negative testing
• Boundary value analysis.
• Equivalence partitioning
• State or graph based testing.
• Model based testing
Difference between white box and Black box testing

11