Chapter 3 White-Box Testing

LOGO
 Contents

White-Box Testing
● 3.1 Basic Concepts
● 3.2 Logic Coverage
Chapter 3 ● 3.3 Control Flow Graph
● 3.4 Basis Path Testing
● 3.5 Loop Testing
● 3.6 Data Flow Testing
● 3.7 A Comparison of White-box Testing and
Black-box Testing
 3.1 Basic Concepts
● White-box testing can examine how the
internal mechanism of a program works.
● It focuses on the internal structure or
implementation, instead of the functionalities (Black-
box testing).
● Software engineers should design test cases based
on the implementation of the program.
 3.1 Basic Concepts
● White-box testing
● It indicates that you have full visibility of the
internal workings of the software product,
especially for the logic and the structure of the
code.
● It is also known as structural testing, clear box
testing, and glass box testing.
 3.1 Basic Concepts
● White-box testing: static & dynamic.
● Static white-box testing methods:
● code inspection
● structure analysis, etc.

● Dynamic white-box testing is based on coverage,

i.e., possible coverage of the test program
structure characteristic and logical path:
● logic coverage
● loop coverage
● basis path coverage, etc.
 3.1 Basic Concepts
● White-box testing must follow the following
principles:
● All independent paths in a module must be
implemented/executed at least once.
● All logic values require test two cases: true and
false.
● Inspecting internal data structure and ensuring
its effectiveness (global vs. local variables)
● Run all cycles within operational range.
 3.1 Basic Concepts
● Development of White-box Testing is
divided into four generations.
● The first generation:
● Perform test development in the initial period
● Debugging 、 assert and print statements.
● The second generation:
● Operation by some formal language for re-using.
(Test scripts )
● Test scripts are combined into test cases; test
cases are combined into a test set.
● Using the code coverage concept to evaluate the
quality of the testing work.
● Tools: RTRT, CppTest, and Cantata++
3.1 Basic Concepts
● The third generation:
● Continue to test.
● Tools: Xunit series like Junit.
● The fourth generation:
● Integration of the debugging and testing work
● Tools: VcTester
 3.1 Basic Concepts
● A Comparison on four generations of White-
box Testing

Evaluation Test Continue to Debugging and

test results automation test testing together

The first No No No No
The second Yes Yes No No
The third Yes Yes Yes No
The fourth Yes Yes Yes Yes
 3.2 Logic Coverage
a
● Logic coverage The ability of b
F T
c
(A>1) ∧(B=0)
finding errors:
● Statement coverage weak  strong
● Decision coverage x=x/A

● Condition coverage
● Condition/decision coverage F T
● Condition combination coverage
d e
(A=2) ∨(x>1)

● Path coverage x=x+1

Path ：
L1(a→c →e)
L2(a→b →d)
L3(a→b →e)
L4(a→c →d)
 3.2 Logic Coverage—Statement Coverage
● Statement coverage
● The goal is to design a number of test cases to run the
tested procedures. We should guarantee that each
executable statement implementation is run at least
once.
● In the previous example, all the executable statements
are in the path L1. We can design test case based on
L1. Then all the executable statements can be
covered .

L1:(A=2) and (B=0) or (A>1) and (B=0) and (x/A>1)

【（ 2, 0, 3 ） 】 covers ace 【 L1 】
 3.2 Logic Coverage—Statement Coverage
● Shortcoming:
● Errors in “abd”?
● (2, 0, 3):
If we swap ∧ and ∨, then ?
● (2, 0, 3):
If x>1 is written as x>0, then ?

Logical operation errors in some paths and judgment

may not be found
 3.2 Logic Coverage—Decision coverage
● The goal is to design a number of test cases to run
the tested procedures. We should guarantee that
the true and false branches of each judgment may
go through at least once.
【 2, 0, 3 】 covers ce 【 1, 1, 1 】 covers bd
or
【 3, 0, 3 】 covers cd 【 2, 1, 1 】 covers be

● For switch-case: one case corresponds to a branch.

 3.2 Logic Coverage—Decision coverage

● Shortcoming:
【 2, 0, 3 】 covers ce 【 1, 1, 1 】 covers bd
or
【 3, 0, 3 】 covers cd 【 2, 1, 1 】 covers be
If x>1 is written wrongly as x>0 ， test case
can’t find this problem. For example, if x>1 is
written wrong as x<1, using the above case
【 2,1,1 】 (be) will get the same result.
Decision Coverage cannot detect the wrong conditions in judgment
 3.2 Logic Coverage—Condition coverage
● The goal is to test all possible values of each
condition at least once.
● For the first judgment
● Condition A ＞ 1 true value is T1 ， false value is !T1
● Condition B ＝ 0 true value is T2 ， false value is !T2
● For the second judgment
● Condition A ＝ 2 true value is T3 ， false value is !T3
● Condition X ＞ 1 true value is T4 ， false value is !T4
 3.2 Logic Coverage—Condition Coverage

● Condition coverage: OK; Decision coverage: OK

Coverage
Test case Path Condition value
branch
(2, 0, 3) ace(L1) T1 T2 T3 T4 c，e
(1, 1, 1) abd(L2) !T1 !T2 !T3 !T4 b，d

● Condition coverage: OK; Decision coverage: No

Condition Coverage
Test case Path
value branch
(1, 0, 3) abe(L3) !T1 T2 !T3 T4 b，e
(2, 1, 1) abe(L3) T1 !T2 T3 !T4 b，e
 3.2 Logic Coverage—Condition / Decision
Coverage
● Condition/decision coverage: the goal is to
design sufficient test cases to guarantee that all
possible conditions of each judgment can be
tested at least once, and all possible results of
each judgment (decision branch) can be tested
at least once.
Test Coverage
path Condition value
case branch
(2,0,3) ace(L1) T1 T2 T3 T4 c，e

(1,1,1) abd(L2) !T1 !T2 !T3 !T4 b，d

3.2 Logic Coverage—Condition Combination
Coverage
● Condition combination coverage: the goal
is to design sufficient test cases to make all
possible condition combinations of each
judgment implement as least once.
● If the test cases meet the condition
combination coverage, then they certainly
meet the decision coverage, condition
coverage and condition/decision coverage.
3.2 Logic Coverage—Condition Combination
Coverage
① A ＞ 1, B ＝ 0 as T1T2

② A ＞ 1, B≠0 as T1!T2
③ A≯1, B ＝ 0 as !T1T2
④ A≯1, B≠0 as !T1!T2
⑤ A ＝ 2, X ＞ 1 as T3T4
⑥ A ＝ 2, X≯1 as T3!T4
⑦ A≠2, X ＞ 1 as !T3T4
⑧ A≠2, X≯1 as !T3!T4
 3.2 Logic Coverage—Condition Combination
Coverage
Test Path Coverage Coverage Combination
case condition branch coverage No.
(2, 0, 3) ace(L1) T1 T2 T3 T4 c，e ①⑤
(2, 1, 1) abe(L3) T1 !T2 T3 !T4 b，e ②⑥

(1, 0, 3) abe(L3) !T1 T2 !T3 T4 b，e ③⑦

(1, 1, 1) abd(L2) !T1 !T2 !T3 !T4 b，d ④⑧

There are four paths in the procedure. Although the
four test cases above cover all condition combinations
and 4 branches, only 3 paths are covered and the path
“acd” is missed.
 3.2 Logic Coverage—Path Coverage
● Path coverage is to design enough test case
to cover all possible path in the procedure
(condition coverage cannot be guaranteed)

Test Condition
No. path
case coverage
1 (2, 0, 3) ace(L1) T1T2T3T4
2 (1, 0, 1) abd(L2) !T1!T2!T3!T4
3 (2, 1, 1) abe(L3) !T1!T2!T3T4
4 (3, 0, 3) acd(L4) T1T2!T3!T4
 3.2 Logic Coverage

● Complete coverage
No. Test case path Condition coverage

1 (2, 0, 3) ace(L1) ①⑤

2 (1, 0, 1) abd(L2) ④⑧

3 (2, 1, 1) abe(L3) ②⑥

4 (3, 0, 3) acd(L4) ①⑧

5 (1, 0, 3) abe(L3) ③⑦
 3.2 Logic Coverage—Path Coverage
● In many scenarios, it is difficult to enumerate
all possible paths.
• For multiple choices
and nesting cycle of the
procedure, the number
of different possible
paths is astronomical.
M1
• When the cycle≤20
times, the number of D1
D2
different paths is 5 .
20
D3 D4
• If the implementation
M5
time of each path is 1 M2 M3 M4 M6
ms , it will take M7
3170years to test all
D5
paths.
One optimization is to transfer “while-statement” into
“if-else” statement, i.e., the loop body is executed only
once.
 3.2 Logic Coverage — Summary
● Relationships
path
condition
combination

decision—condition

decision condition

stateme
nt
LOGO