White Box Testing

Adam Hendra Brata

2

Agenda

White Box Testing– Introduction

– Techniques

Equivalence Partitioning

Coverage

– Function Coverage

– Statement Coverage

– Branch Coverage

– Decision Coverage

– Path Coverage

Automatic Testing

3

White Box TestingIntroduction

4

White Box

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

(Beizer, 1995)

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

5

White Box

6

White Box

White Box is one of two parts of the basic

"box testing" approach of software testing

– It’s counter-part of black box testing which involves

testing from an external or end-user type perspective

– On the other hand, white box testing is based on the

inner workings of an application and revolves around

internal testing

Main goal of White Box testing is to derive and/or

select test cases based on an analysis of the internal

structure of a component or system

7

White Box

White box testing involves the testing of the software

code for the following :

– Internal security holes

– Broken or poorly structured paths in the coding

processes

– The flow of specific inputs through the code

– Expected output

– The functionality of conditional loops

– Testing of each statement, object and function on an

individual basis

8

White Box

Advantages

– Testing is more thorough, with the possibility of covering

most paths

– Optimization of code by revealing hidden errors and being

able to remove these possible defects

– Gives the programmer introspection because developers

carefully describe any new implementation

– Provides traceability of tests from the source, allowing

future changes to the software to be easily captured in

changes to the tests

– White box tests are easy to automate

– White box testing give clear, engineering-based, rules for

when to stop testing

– Testing can be commenced at an earlier stage

9

White Box

Disadvantages

– White-box testing brings complexity to testing because the

tester must have knowledge of the program, including being

a programmer.

– On some occasions, it is not realistic to be able to test every

single existing condition of the application and some

conditions will be untested

– The tests focus on the software as it exists, and missing

functionality may not be discovered

– Test script maintenance can be a burden if the

implementation changes too frequently

– Expensive as one has to spend both time and money to

perform white box testing

10

White Box Workflow

11

White Box Testing TechniquesEquivalence Partitioning &Boundary Value Analysis

12

Equivalence Partitioning and Boundary Value Analysis

Like EV and BVA on Black Box, these strategies also

have a main purpose to reduce the number of

possible test cases

Similar to Black Box, we categorize and check the

possible inputs to several classes based on several

conditions

In white box, we have known the internal

implementation of the program, so we can perform

the analysis more accurate than before

For further information : black box testing slide

13

White Box Testing TechniquesCoverage

14

Coverage

In software testing, test coverage measures the

amount of testing performed by a set of test

– It will include gathering information about which parts of a

program are actually executed when running the test suite

in order to determine which branches of conditional

statements have been taken

In simple terms, it is a technique to ensure that your

tests are actually testing your code or how much of

your code you exercised by running the test

15

Coverage

The basic coverage measure is where the ‘coverage

item’ is whatever we have been able to count and

see whether a test has exercised or used this item

16

Coverage

What Test Coverage does

– Finding area of a requirement not implemented by a

set of test cases

– Helps to create additional test cases to increase

coverage

– Identifying a quantitative measure of test coverage,

which is an indirect method for quality check

– Identifying meaningless test cases that do not

increase coverage

17

Coverage

Types of coverage items

– Function / Method Coverage

– Statement Coverage

– Branch Coverage

– Decision Coverage

– Path Coverage

18

Function / Method Coverage

Method coverage is a measure of the percentage of

methods that have been executed by test cases

– Has each function (or subroutine) in the program been

called?

Undoubtedly, your tests should call 100% of your

methods.

– It seems irresponsible to deliver methods in your product

when your testing never used these methods

As a result, you need to ensure you have 100%

method coverage

You need to made a complete analysis into your

code

19

Statement Coverage

Statement coverage is a measure of the percentage

of statements that have been executed by test cases

– Has each statement in the program been executed?

Your objective should be to achieve 100% statement

coverage through your testing

20

Branch Coverage

Branch coverage is a measure of the percentage of

the decision points (Boolean expressions) of the

program have been evaluated as both true and false

in test cases

– Has each branch (also called DD-path) of each control

structure (such as in if and case statements) been

executed?

– For example, given an if statement, have both the true and

false branches been executed? Another way of saying this

is, has every edge in the program been executed?

We evaluate an entire Boolean expression as one

true-or-false predicate even if it contains multiple

logical-and or logical-or operators

21

Decision Coverage

Condition coverage is a measure of percentage of

Boolean sub-expressions of the program that have

been evaluated as both true or false outcome

[applies to compound predicate] in test cases

– Has each Boolean sub-expression evaluated both to true

and false?

– Condition coverage measures the outcome of each of these

sub-expressions independently of each other

– With condition coverage, you ensure that each of these sub

expressions has independently been tested as both true

and false

22

Coverage Example

Consider this code snippet

int check(int x, int y)

{

int z = 0;

if ((x>0) && (y>0))

{

z = x;

}

return z;

}

Coverage ?

• Function

• Statement

• Branch

• Condition

• Decision

Assume this function is a part of some bigger program and this program

was run with some test suite

23

Coverage Example

If during this execution function ‘check' was called at least

once, then function coverage for this function is satisfied.

Statement coverage for this function will be satisfied if it was

called with some specific input e.g. as check(1,1), as in this

case, every line in the function is executed including z = x;

Tests calling check(1,1) and check(0,1) will satisfy branch

coverage because, in the first case, the 2 if conditions are met

and z = x; is executed, while in the second case, the first

condition (x>0) is not satisfied, which prevents executing z = x;

Condition coverage can be satisfied with tests that call

check(1,0) and check(0,1).

– These are necessary because in the first cases, (x>0) evaluates to

true, while in the second, it evaluates false

– At the same time, the first case makes (y>0) false, while the

second makes it true

24

Coverage Example

Condition coverage does not necessarily imply branch

coverage directly

For example, consider the following fragment of code:

Condition coverage check each of the conditional parts

independently and the other side branch coverage check the

conditional part as one final statement based on the outer

conditional keyword

If (x>1) AND (y<=0) then

Blue part can be satisfied

at least by two tests:

• Value of x is more than

1 (2,3,….)

• Value of x is less than

1 (0,-1,….)

Yellow part can be satisfied

at least by two tests:

• Value of y is more than 0

(1,2,….)

• Value of y is less than 0

(-1,-2,….)

25

Path Coverage

Path coverage tests all the paths of the program

Path coverage is the strongest criterion of coverage

items in white box testing

– This is a comprehensive technique which ensures that all

the paths of the program are traversed at least once

– This technique is useful for testing the complex programs

Path coverage can be measured with basis path

testing approach

– Look into Software Engineering course’s slide

26

White Box Testing TechniquesAutomatic Testing

27

Automatic Testing

One of the advantages of white box testing is easy to

automation

Nowadays there are so many software testing tools

which we can use to

test our code

28

Thank You