28 White Box Testing II

R. Baskaran

WHITE BOX TESTING

White box is a testing methodology to test the internal structures and working of software. White box testing also know as structural testing is testing based on analysis of internal logic (design, code, etc.).

LEARNING OBJECTIVES 

• To focus on Program structures, Program internal logic and data structures, Program internal behaviors and states.

• To focus on internal program structure and discover all internal program errors.

Example Paths 

The following example shows the flow graph and the paths through the nodes, the example shows that the paths P3 and P4 are the same but they have different start and endpoints.

In the example, the paths that form cycles are identified, where P4, P8, P9 does not form cycles.

MODIFIED CYCLOMATIC COMPLEXITY MEASURES 

Given p connected components of a graph:

◦	V(G) = e – n + 2p	(1)
◦	VLI(G) = e – n + p + 1	(2)

Eq. (2) is known as linearly-independent cyclomatic complexity. VLI does not change when program is modularized into p modules. A number of industry studies have indicated that the higher V(G), the higher the probability or errors.

The following example shows computation of the cyclomatic complexity measures where modularization  does  not  increase  complexity.  This  is  known  as   intuitive   expectation where modularization should not increase complexity.

STATEMENT COVERAGE 

Statement Coverage requires that each statement will have been executed at least once. It is the simplest form of logic coverage and also known as Node Coverage. The given example shows the minimum number of test cases required to achieve statement coverage for the given program segment.

Another example to determine the complexity, where the given block code is:

public void howComplex() {

int i=20;

while (i<10) {

System.out.printf(“i is %d”, i);

if (i%2 == 0) {

System.out.println(“even”);

} else { System.out.println(“odd”);

}}}

The graph flow for the given block of code is given as follows, the complexity is given as follows;

V (G) = 2 enclosed area + 1 = 3 

BRANCH COVERAGE 

Branch Coverage requires that each branch will have been traversed, and that every program entry point will have been taken, at least once. It is also known as Edge Coverage. Branch coverage ensures that every program entry point will have been taken, at least once. Every branch is traversed to ensure that each branch is validated and does not exhibit any abnormal functionalities.

Relationship between Statement and Branch Coverage: 

Statement Coverage subsumes Branch Coverage (“statement => branch”). If a program has “dead (i.e., unreachable) code”, then “statement coverage” is unachievable. We would need to modify the program in order to bring the dead code back to “life”. The bottom line is that we will always assume the nominal case of “no dead code” unless explicitly stated otherwise. Under this assumption, Branch Coverage does indeed subsume Statement Coverage.

CONDITION COVERAGE 

A branch predicate may have more than one condition. The given example shows condition coverage.

input(X,Y)

if (Y<=0) or (X=0) then

Y := -Y

end_if

while (Y>0) and (not EOF) do

input(X)

Y := Y-1

end_while

Condition Coverage requires that each condition will have been true at least once and false at least once. For example:

if A or B then s1

else

s2 end_if_then_else

Branch/Condition Coverage requires that both Branch AND Condition Coverage will have been achieved. Therefore, Branch/Condition Coverage subsumes both Branch Coverage and Condition Coverage.

Summary of White-Box Coverage Relationships 

The following figure depicts the white box coverage relationships:

TESTING STRATEGIES 

Many unanswered questions about white box and black box testing. E.g. who does the testing? Which techniques should we use and when? There are no universal strategies, just principles that have been useful in practice. E.g. the notions of unit testing and integration testing.

Basic Principles 

• Testing starts at the component level and works “outwards”. Unit testing, integration testing and system testing.
• Different testing techniques are appropriate at different scopes.
• Testing is conducted by developers and/or by a specialized group of testers.
• Testing is different from debugging. Debugging follows successful testing

Scope and Focus

• Unit testing
  • Scope: individual com
  • Focus: component corre
  • Black-box and white-box techniques.
• Integration testing
  • Scope: set of interacting com
  • Focus: correctness of component interac
  • Mostly black-box, some white-box
• System testing
  • Scope: entire system.
  • Focus: overall system
  • Only black-box techniques.

TEST-FIRST PROGRAMMING

Modern practices emphasize the importance of testing during development.  Testing during development reduces risks, ensures consistency and saves development costs

Example: Test-first programming.

The basic idea before you start writing any code is first write the tests for this code. Write a little test code, write the corresponding unit code, make sure it passes the tests, and then repeat.

Advantages of Test-First Programming

• Developers do not “skip” unit testing.
• Satisfaction for the programmer, the feeling of accomplishment when the tests pass.
• Helps clarify interface and behavior before programming. To write tests for something, first you need to understand it well.
• Software evolution.
• After changing existing code, rerun the tests to gain confidence. (Regression testing).

Web Links

• softwaretestingfundamentals.com/white-box-testing/
• www.softwaretestinghelp.com/white-box-testing-techniques-with-example/
• Www.softwaretestingclass.com/white-box-testing/

Supporting & Reference Materials

• Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001.
• Pankaj Jalote, “An Integrated Approach to Software Engineering”, Second Edition, Narosa Publications, 2005.
• Ian Sommerville, “Software Engineering”, Tenth Edition, Pearson Education, 2017.