WHITE BOX TESTING

SORINA INDRECAN
 AGENDA
 CHARACTERISTICS
 USAGE 2

 CODE COVERAGE
 CONTROL FLOW TESTING
 STATEMENT COVERAGE AND STATEMENT TESTING
 DECISION COVERAGE AND DECISION TESTING

2
 WHITE BOX TESTING

= clear box testing, glass box testing, transparent box testing, structural testing,
structure based testing, logic driven testing, logic coverage testing.

= testing based on an analysis of the internal structure of the component or system.

3

= a method of testing software that tests internal structures or workings of an

application, as opposed to its functionality.

3
 WHITE BOX TESTING
- CHARACTERISTICS -
• Main resource is information of how the system is constructed (design,
code)
• It requires complete knowledge of the program structure and access to
source code.
• Focus on the test coverage of code ramifications and program flow.
• It has the potential to miss unimplemented parts of the specification or missing
requirements. 4
• Used for test coverage measurement and structural test cases design
• Based upon the decomposition of the component into constituent statements
• Is mostly used for three levels of testing:
• Unit testing
• Integration testing
• System testing

4
 WHITE BOX USAGE

UNIT TESTING:

• Or component testing
• Searches for defects and verifies functionality at a
low level, elements that are separately testable.
5
• Unit testing is important for ensuring the code is
solid before it is integrated with other code.
• The component is isolated from the rest of the
system. Stubs, drivers and simulators may be used.

5
 WHITE BOX USAGE

INTEGRATION TESTING
• Software components, hardware components, or both are
combined and tested to evaluate the interaction between
them.
• Test cases are written to explicitly examine the connections
between the
6 various units.

SYSTEM TESTING
• Checks the behavior of the whole system/product.
• It uses the most production like environment and
factors of influence.
• An independent test team often carries out system
testing.

6
 CODE COVERAGE

• = test coverage
• Measures the amount of testing performed by a set of tests.
• 100% coverage does not mean 100% tested.
• Measurement can be applied on different levels:
7 component, integration, system,
acceptance and in rare cases database level.
• Often used in sensitive or critical parts of the system from the safety perspective or
in complex areas of the system.
• We can also measure coverage for each of the specification-based techniques or
black-box testing: EP, BVA, decision tables.
• Most often made using tools.

7
 UPS AND DOWNS

+ -
• It creates additional test cases to increase • It measures coverage of what has been
coverage written, it cannot say anything about the
• It helps in finding areas of a program not software that has not been written.
exercised by a set of test cases • Brings complexity to testing because the
• It helps in determining a quantitative 8 tester must have knowledge of the
measure of code coverage, which indirectly program, including being a programmer.
measure the quality of the application or • On some occasions, it is not realistic to be
product. able to test every single existing condition
• Optimization of code by revealing hidden of the app.
errors and being able to remove these
possible defects.
• Tests are easy to automate.

8
 CONTROL FLOW TESTING

• Code modules are converted to graphs.

• The connections between the nodes are analyzed
and test cases are created based on the analysis.
• Control-flow testing is a structural testing strategy that
uses the program’s control flow as a model. 9
• The representations also enable us to verify
reachability, relationship with other nodes, edges and
loops effectively.

9
 CONTROL FLOW TESTING
GRAPH ELEMENTS:

• Process Blocks - a sequence of program statements that execute sequentially. No entry into the
block is permitted except at the beginning. No exit from the block is permitted except at the end.
Once the block is initiated, every statement within it will be executed sequentially.
• Decision Point - a point in the module at 10
which the control flow can change. Most decision points
are binary and are implemented by if-then-else statements. Multi-way decision points are
implemented by case statements. They are represented by a bubble with one entry and multiple
exits.
• Junction Point - a point at which control flows join together.

10
 CONTROL FLOW TESTING
EXAMPLES

11

11
 CONTROL FLOW TESTING
EXAMPLES

12

12
 STATEMENT COVERAGE AND STATEMENT TESTING
• Statement: An entity in a programming language, which is typically the smallest indivisible unit
of execution.
• In this process each and every line of code needs to be checked and executed.
• Derives test cases to execute specific statements.
• Through statement coverage we can identify13the statements executed and where the code is
not executed because of blockage.

13
 STATEMENT COVERAGE AND STATEMENT TESTING -
EXAMPLES
• We can test by looking at the code and determine a test case that
gives 100% statement coverage.
• To achieve 100% statement coverage of this code segment just one
test case is required, one which ensures that variable A contains a
value that is greater than the value of variable Y, for example, X = 12
and Y = 10.

14

• We can evaluate the test cases we have to determine the coverage

and analyze if we can add some more for an increased coverage.
• Test1: X= 2, Y = 3; Test2: X =0, Y = 25; Test3: X =47, Y = 1
• If we add Test4: X = 20, Y = 25 we will achieve 100% statement
coverage.

14
 DECISION COVERAGE AND DECISION TESTING
• = branch coverage
• A decision is an IF statement, a loop control statement (e.g. DO-WHILE or REPEAT-UNTIL), or a
CASE statement, where there are two or more possible exits or outcomes from the statement.
• Decision coverage measures the number of executed branches. A branch is an outcome of a
decision, so an ‘IF’ statement, for example, has two branches, which are ‘True’ and ‘False’.
• Decision coverage is stronger than statement coverage.
15
• 100% decision coverage always guarantees 100% statement coverage.
• Functional testing covers only around 40%-60% of decision testing.
• To calculate the decision coverage of a program we can use the following formula:

Decision Coverage = number of executed decision outcomes * 100%

total number of decision outcomes

15
 DECISION COVERAGE AND DECISION TESTING
EXAMPLES
• Test1: A=2-, B=15 - the test gives 100% coverage, but we have not
executed the False outcome of the decision statement, so decision
coverage is only 50%.
• Test2: A=10, B=2 – the 2 tests now cover both of the decision
outcomes, True (with Test 1) and False (with Test 2).

• When we have more than one decision to cover, we can 16write a test
for each of the branches, 4 in our case, or we can find input that
combines the two decisions so we can get 100% decision coverage
with less than 4 tests.
• Test1: A=7, B=5; Test2: A=3, B=2 – the two tests make 100%
decision coverage, Test1 going on the False path of both decisions
and Test2 going on the True side of both decisions.

16
 17

17