J.E.D.I
6.3 Software Test Case Design Methods
There are two ways software is tested. One approach is to test the internal workings of the software. It checks if internal operations perform as specified, and all internal
components have been adequately tested. The other approach is to test the software as a whole, i.e., know how the software works and tests if it conforms to the specified
functionality in the requirements. The first approach is known as white-box testing while the second approach is known as black-box testing.
6.3.1 White-Box Testing Techniques
White-Box Testing is also known as glass-box testing. It is a test case design technique that uses the internal control structure of the software component as defined
by their methods to derive test cases. Its goal is to ensure that internal operations perform according to specification of the software component. It ensures that no logical
errors, incorrect assumptions and typographical errors have been missed. It produces test cases that:
• Ensures that all independent paths with the component have been tested at least
onces; •
Tests all logical decisions on their true or false sides; •
Tests all loops at their boundaries and within their operational bounds; and •
Tests internal data structures for their validity. •
Tests paths within the components that are considered “out of the mainstream”. There are several techniques that can be employed in defining test cases using the white-
box approach. They are discussed in the succeeding section.
Basic Path Testing Basis Path Testing is a white-box testing technique that enables the test case designer
to derive a logical complexity measure based on the procedural specification of a software component. This complexity measure is used as a guide for defining a basis set of
execution paths to be tested.
Steps in Deriving Test Cases using Basis Path Testing STEP 1. Use a procedural specification as input in deriving the basic set of execution
path.
The procedural specification can be the design pseudo-code or flowchart or the source code itself. For classes, the operation or method procedural design will be used. As an
example, assume that the following is pseudo-code of some method of some class.
Software Engineering 270
J.E.D.I
STEP 2. Draw the flow graph of the procedural specification.
The flow graph depicts the logical control flow of the procedural specification. It uses nodes, edges and regions. The nodes represent one or more statements. It can be
mapped to sequences or conditions. The edges are the links of the nodes. They represent flow of control similar to flow charts. Areas that are bounded by the edges and
nodes are called regions. Figure 6.1 shows the flow graph of the sample procedural code. The graph does not normally shows the code. It is placed there for clarification
purposes.
Software Engineering 271
while condition1 do statement1;
statement2; do case var1
condition1: statement3
condition2: statement4;
statement5; condition3:
if condition2 then statement6;
else statement7
statement8 endif
endcase statement9;
endwhile
Text 14: Sample Design Code
J.E.D.I
STEP 3. Compute for the complexity of the code. The cyclomatic complexity is used to determine the complexity of the procedural code.
It is a number that specifies the independent paths in the code, which is the basis of the basic set. It can be computed in three ways.
1. The number of regions of the flow graph.
2. The number of predicate nodes plus one, i.e, VG = P + 1.
3. The number of edges minus the nodes plus 2, i.e., VG = E – N + 2
Software Engineering 272
Figure 6.1 Flow Graph
1
while condition1 do
2
statement1; statement2
3
do case var1
5
condition2 statement4
statement5
4
condition1 statement3
6
condition3 if condition2 then
7
statement6
8
statement7 statement8
9
statement9
11
J.E.D.I
In the example: The number of regions is 5.
The number of predicates is 4. The number of edges is 13.
The number of nodes is 10.
Using the formulae: •
VG = 5 regions •
VG = 4 predicates + 1 = 5 •
VG = 13 edges – 10 nodes + 2 = 5 STEP 4. Determine the basic set of execution paths.
Software Engineering 273
Figure 6.2 Cyclomatic Complexity Values
1
while condition1 do
2
statement1; statement2
3
do case var1
5
condition2 statement4
statement5
4
condition1 statement3
6
condition3 if condition2 then
7
statement6
8
statement7 statement8
9
statement9
11
REGION 1
REGION 2 REGION 3
REGION 4 REGION 5- Outside
where node 11 belongs
Node 3 is counted as 2 predicates. It is
equivalent to two nested if
statements.
J.E.D.I
The cyclomatic complexity provides the number of the linearly independent paths through the code. In the above example, 5 linearly independent paths are identified.
Path 1: Node-1, Node-2, Node-3, Node-4, Node-9 Path 2: Node-1, Node-2, Node-3, Node-5, Node-9
Path 3: Node-1, Node-2, Node-3, Node-6, Node-7, Node-9 Path 4: Node-1, Node-2, Node-3, Node-6, Node-8, Node-9
Path 5: Node-1, Node-11
STEP 5: Document the test cases based on the identified execution path. Test cases are prepared to force execution of each path. Conditions on predicate nodes
should be properly set. Each test case is executed and compared from the respected result. As an example:
PATH 1 Test Case: For Node-1, condition2 should evaluate to TRUE Identify the necessary values.
For Node-3, evaluation of var1 should lead to Node-4 Identify value of var1 Expected Results: should produce necessary result for Node-9.
Software Engineering 274
J.E.D.I
Control Structure Testing Control Structure Testing is a white-box testing technique that test three types of
program control, namely, condition testing, looping testing and data flow testing. 1.
Condition Testing. It is a test case design method that test the logical conditions contained in a procedural specification. It focuses on testing each
condition in the program by providing possible combination of values. As an example, consider the following condition of a program.
if result 0 numberOfTest = 100 The test cases that can be generated is shown in Table 26.
Test Case result 0
numberOfTest = 100 Compound
1 T
T T
2 T
F F
3 F
T F
4 F
F F
Table 26: Control Structure Test Cases
2. Looping Testing. It is a test case design method that focuses exclusively on
the validity of iterative constructs or repetition. There are four classes of iteration: simple, concatenated, nested and unstructured. They are shown in
Table 27.
Software Engineering 275
J.E.D.I
Simple Iteration: DO WHILE
Statement ENDWHILE
Concatenated Iteration: DO WHILE
Statement ENDWHILE
DO WHILE Statement
ENDWHILE Nested Iteration:
DO WHILE Statement
DO WHILE Statement
ENDWHILE ENDWHILE
Unstructured Iteration: DO WHILE
Statement :Label1
DO WHILE Statement
:Label2 IF condition
GOTO Label1 ENDIF
GOTO Label2 ENDWHILE
ENDWHILE
Table 27: Iteration or Repetition Structure
For Simple Iteration, the test cases can be derived from the following possible execution of the iteration or repetition.
• Skip the loop entirely.
• Only one pass through the loop.
• Two passes through the loop.
• m passes through the loop where m n
• n – 1, n, n + 1 passes through the loop
For Nested Iterations, the test cases can be derived from the following possible execution of the iteration or repetition.
• Start with the innermost loop.
• Conduct simple loop tests for the innermost loop while holding the outer
loop at their minimum iteration parameter values. Add other test for out- of-range or excluded values.
Software Engineering 276
J.E.D.I
• Work outward, conducting tests for the next loop, but keeping all other
outer loops at minimum values and other nested loops to “typical” values. •
Continue until all loops have been tested. For Concatenated Iteration, the test cases can be derived from the following
possible execution of the iteration or repetition •
If loops are independent, the test for simple loops can be used. •
If loops are dependent, the test for nested loops can be used. For Unstructured Iteration, no test cases can be derived since it would be best to
redesign the loop since it is not a good iteration or repetition constructs.
3. Data Flow Testing. It is a test case design method that selects test paths of a
program according to the locations of the definitions and uses of variables in the program.
6.3.2 Black-Box Testing Techniques
Kategori