What is White Box Testing?

White box testing (WBT) is also called Structural or Glass box

testing.

White box testing involves looking at the structure of the code.

When you know the internal structure of a product, tests can be
conducted to ensure that the internal operations performed
according to the specification. And all internal components have
been adequately exercised.

White Box Testing is coverage of the specification in the code.

Code coverage:

Statement coverage:
The statement coverage is strategy aims to design test cases so that
statement in a program is executed at least once. The principle idea
governing the statement coverage strategy is that unless we
execute a statement, we have no. of ways of determining an error
exists in that statement. Unless a statement is executed ,we cannot
observe whether it causes failure due to some illegal memory
access, wrong result computation ,etc. However ,no guarantee that
it will behave correctly for all input values .

Branch Coverage or Node Testing:

in the branch coverage –based testing strategy, test cases are
designed to make each branch .condition assume true and false in
turn .branch testing is also know as edge testing as in this testing
scheme, each edge of a program’s control flow graph is
transversed at least once.

It is obvious that branch testing guarantees statement coverage and

thus is a stronger testing strategy then the statement coverage
-based-testing.

Compound Condition Coverage :

In this structural testing, the test cases are designed too make each
component of a composite conditional expression assumed true

1
and false values. For example, in conditional expression ((c1 AND
c2) OR c3 ), the component c1, c2 and c3 are each made to assume
both true and false values. Branch testing is probably is the
simplest condition testing strategy where only the compound
conditions appearing in the different branch statements are made to
assume the true and false values. Thus, condition testing is a
stronger strategy than branch testing and branch testing is a
stronger testing strategy than statement coverage 2n test cases are
required. Thus, for condition coverage, the no. of test cases
increases exponentially with no. of component conditions.
Therefore, a condition coverage based testing technique is practical
only if n ( no. of condition ) is small.

Basis Path Testing:

Each independent path in the code is taken for testing.

Data Flow Testing (DFT):

In this approach you track the specific variables through each
possible calculation, thus defining the set of intermediate paths
through the code .DFT tends to reflect dependencies but it is
mainly through sequences of data manipulation. In short each data
variable is tracked and its use is verified.
This approach tends to uncover bugs like variables used but not
initialize, or declared but not used, and so on.

Path Testing:
Path testing is where all possible paths through the code are
defined and covered. It’s a time consuming task.

Loop Testing:
These strategies relate to testing single loops, concatenated loops,
and nested loops. Independent and dependent code loops and
values are tested by this approach.

2
Why we do White Box 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.

Need of White Box Testing?

To discover the following types 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

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.

Limitations of WBT:
Not possible for testing each and every path of the loops in
program. This means exhaustive testing is impossible for large
systems.
This does not mean that WBT is not effective. By selecting
important logical paths and data structure for testing is practically
possible and effective.
Reference- http://www.softrel.org/stgb.html

Comment out your queries on white box testing below. Meantime I

will cover Black box testing in detail.

3
Advantages of white box Testing

1-Forces test developer to reason carefully about implementation

2-Approximates the partitioning done by execution equivalence

3-Reveals errors in "hidden" code:

4-Beneficent side-effects

5-Optimizations (e.g. chartable that changes reps when size > 100)

6-As the knowledge of internal coding structure is prerequisite, it

becomes very easy to find out which type of input/data can help in
testing the application effectively.

7-The other advantage of white box testing is that it helps in

optimizing the code.

8-It helps in removing the extra lines of code, which can bring in
hidden defects.

Disadvantages of white box testing

1-Expensive

2-Miss cases omitted in the code

3-As knowledge of code and internal structure is a prerequisite, a

skilled tester is needed to carry out this type of testing, which
increases the cost.

4-And it is nearly impossible to look into every bit of code to find

out hidden errors, which may create problems, resulting in failure
of the application.

4
5-Not looking at the code in a runtime environment. That's
important for a number of reasons. Exploitation of vulnerability is
dependent upon all aspects of the platform being targeted and
source code is just of those components. The underlying operating
system, the backend database being used, third party security tools,
dependent libraries, etc. must all be taken into account when
determining exploitability. A source code review is not able to take
these factors into account.

Very few white-box tests can be done without modifying the

program, changing values to force different execution paths, or to
generate a full range of inputs to test a particular function.

Finish