White Box Testing

Core QA Team
12th March 2008
Agenda

 What is White-Box Testing

 Why we do White-Box Testing
 Need of White-Box Testing
 Skills required
 Roles and Responsibilities of White-Box Tester
 Where White-Box Testing is Used
 The White-Box Testing process includes.
 Black-Box Vs White-Box Testing

2
©Copyright Kenexa® 2004
 What is White-Box Testing

• White box testing is a security testing method that can be used to validate
whether code implementation follows intended design, to validate
implemented security functionality, and to uncover exploitable
vulnerabilities.
• White-box testing is testing that takes into account the internal mechanism
of a system or component (IEEE, 1990). White-box testing is also known as
structural testing, clear box testing, and glass box testing.
• The connotations of “clear box” and “glass box” appropriately indicate that
you have full visibility of the internal workings of the software product,
specifically, the logic and the structure of the code.

3
©Copyright Kenexa® 2004
Why we do White Testing

To Ensure:

• That all independent paths within a module have been exercised at

least once.
• All logical decisions verified on their true and false values.
• All loops executed at their boundaries and within their operational
bounds internal data structures validity.

4
©Copyright Kenexa® 2004
Need of White-Box Testing

To Discover Following Type of Bugs:

• Logical error tend to creep into our work when we design and
implement functions, conditions or controls that are out of the
program
• The design errors due to difference between logical flow of the
program and the actual implementation
• Typographical errors and syntax checking

5
©Copyright Kenexa® 2004
Skills required

• We need to write test cases that ensure the complete coverage of

the program logic.
For this we need to know the program well i.e. We should know the
specification and the code to be tested. Knowledge of programming
languages and logic.

6
©Copyright Kenexa® 2004
 Roles and Responsibilities of a White-Box Tester

- Exercise independent paths within a module or unit;

- Exercise logical decisions on both their true and false side;

- Execute loops at their boundaries and within their operational bounds; and

- Exercise internal data structures to ensure their validity.

7
©Copyright Kenexa® 2004
 Where White-Box Testing is used
• There are six basic types of testing: unit, integration, function/system,
acceptance, regression, and beta. White-box testing is used for three of these
six types:
Unit testing: which is testing of individual hardware or software units or
groups of related units . A unit is a software component that cannot be
subdivided into other components . Software engineers write white-box test
cases to examine whether the unit is coded correctly. Approximately 65% of all
bugs can be caught in unit testing.
Integration testing: which is testing in which software components,
hardware components, or both are combined and tested to evaluate the
interaction between them. Test cases are written which explicitly examine the
interfaces between the various units. These test cases can be black box test
cases, whereby the tester understands that a test case requires multiple
program units to interact. Alternatively, white-box test cases are written which
explicitly exercise the interfaces that are known to the Tester.

8
©Copyright Kenexa® 2004
Where White-Box Testing is used

Regression testing : which is selective retesting of a system or

component to verify that modifications have not caused unintended
effects and that the system or component still complies with its specified
requirements . As with integration testing, regression testing can be
done via black-box test cases, white-box test cases, or a combination of
the two. White-box unit and integration test cases can be saved and
rerun as part of regression testing.

9
©Copyright Kenexa® 2004
The White-Box testing process includes

- Execution of each statement in a code component at least once

- Execution of each conditional branch in the code component
- Execution of paths with boundary and out-of-bounds input values
- Verification of the integrity of internal interfaces
- Verification of architecture integrity across a range of conditions
- Verification of Database design and structure
- Examples:
1.Loop Testing
2.Basic Path Testing

10
©Copyright Kenexa® 2004
Loop Testing

This is White-Box Testing technique and there are 4 different types of Loop Testing

1. Simple Loops
2. Concatenated Loops
3. Nested Loops
4. Unstructured Loops

11
©Copyright Kenexa® 2004
Basic Path Testing

• A Testing mechanism proposed by McCabe.

• Aim is to derive a logical complexity measure of a procedural design
and use this as a guide for defining a basic set of execution paths.
• Test cases which exercise basic set will execute every statement at
least once
Steps in Basic Path Testing Includes.
1.Flow Graph Notation: It’s a simple notation representing control
flow
2.Derive Cyclomatic Complexity.
3.Determine the number of Individual paths
4.Deriving Test cases to exercise these paths

12
©Copyright Kenexa® 2004
Basic Path Testing - Flow Graph Notation

Flow Graph Notation:

Notation for representing control flow

13
©Copyright Kenexa® 2004
Basic Path Testing - Flow Graph Notation

On a flow graph:

• Arrows called edges represent flow of control

• Circles called nodes represent one or more actions.
• Areas bounded by edges and nodes called regions.
• A predicate node is a node containing a condition
• Any procedural design can be translated into a flow graph.
• Note that compound Boolean expressions at tests generate at least
two predicate node and additional arcs

14
©Copyright Kenexa® 2004
Basic Path Testing - Flow Graph Notation

• Any procedural design can be translated into a flow graph.

• Note that compound Boolean expressions at tests generate at least
two predicate node and additional arcs

15
©Copyright Kenexa® 2004
Basic Path Testing - Cyclomatic Complexity

• The cyclomatic complexity gives a quantitative measure of the

logical complexity.
• This value gives the number of independent paths in the basis set,
and an upper bound for the number of tests to ensure that each
statement and both sides of every condition is executed at least
once.
• An independent path is any path through a program that introduces
at least one new set of processing statements (i.e., a new node) or
a new condition (i.e., a new edge)

16
©Copyright Kenexa® 2004
Basic Path Testing - Cyclomatic Complexity

17
©Copyright Kenexa® 2004
Basic Path Testing - Cyclomatic Complexity

Example has:

• Cyclomatic Complexity of 4. Can be calculated as:

– Number of regions of flow graph.
– #Edges - #Nodes + #terminal vertices (usually 2)
– #Predicate Nodes + 1
• Independent Paths:
– 1, 8
– 1, 2, 3, 7b, 1, 8
– 1, 2, 4, 5, 7a, 7b, 1, 8
– 1, 2, 4, 6, 7a, 7b, 1, 8
• Cyclomatic complexity provides upper bound for number of tests
required to guarantee coverage of all program statements

18
©Copyright Kenexa® 2004
Basic Path Testing – Deriving Test cases

Deriving Test cases:

• Using the design or code, draw the corresponding flow

graph.
• Determine the cyclomatic complexity of the flow graph.
• Determine a basis set of independent paths.
• Prepare test cases that will force execution of each path in
the basis set.

Note: some paths may only be able to be executed as part of

another test .
19
©Copyright Kenexa® 2004
Black Box Testing Vs White Box Testing

20
©Copyright Kenexa® 2004
Black Box Testing Vs White Box Testing-Test case
design

Black Box: White Box:

• Equivalence partitioning • Statement coverage
• Boundary-value analysis • Decision coverage
• Cause-effect graphing • Condition coverage
•
• Decision/condition coverage
Error guessing
• Multiple-condition coverage

21
©Copyright Kenexa® 2004
References

http://www.stctek.com/faqs.htm

http://www.geekinterview.com/question_details/35815

http://www.testinggeek.com/whitebox.asp

http://www.cs.rit.edu/~afb/20012/cs4/slides/stl-04.html

22
©Copyright Kenexa® 2004
 23
©Copyright Kenexa® 2004
www.kenexa.com