Chapter 5

Test Case Design

1
Test Case Design
 Part –I Black Box Testing
 Part –II White Box Testing

2
LESSON OUTLINE
 Black Box Testing (Functional testing)
 Equivalence Partitioning
 Boundary Value Analysis
 Cause Effect Graphing
 White Box Testing (Structural testing)

 Coverage Testing
 Statement Coverage

 Branch And Decision Coverage

 Path Coverage

 Comparison of black box and white box testing

BLACKBOX TESTING
 In Black Box Testing we just focus on inputs and output
of the software system without bothering about internal
knowledge of the software program.

[Figure of Blackbox Testing]

 The above Black Box executable program can be any software
system you want to test.
BLACKBOX TESTING
 By applying black-box techniques, you derive a set of test
cases that satisfy the following criteria:
 (1) test cases that reduce, by a count that is greater than one
the number of additional test cases that must be designed to
achieve reasonable testing, and
 (2) test cases that tell you something about the presence or
absence of classes of errors, rather than an error associated
only with the specific test at hand.
BLACKBOX TESTING
 Blackbox Techniques/ Methods:
 Equivalence partitioning: It is a software test design
technique that involves dividing input values into valid
and invalid partitions and selecting representative values
from each partition as test data.
 Boundary Value Analysis: It is a software test design
technique that involves determination of boundaries for
input values and selecting values that are at the
boundaries and just inside/ outside of the boundaries as
test data.
 Cause effect graphing: It is a software test design
technique that involves identifying the cases (input
conditions) and effects (output conditions), producing a
Cause-Effect Graph, and generating test cases accordingly.
BLACKBOX TESTING
 1. Equivalence partitioning:
 Equivalence Partitioning also called as equivalence class
partitioning.
 It can be applied at any level of testing and is often a good
technique to use first.
 The idea behind this technique is to divide (i.e. to partition) a
set of test conditions into groups or sets that can be
considered the same (i.e. the system should handle them
equivalently), hence ‘equivalence partitioning’.
 Equivalence partitioning is a testing technique where input
values set into classes for testing.
 Valid Input Class = Keeps all valid inputs.
 Invalid Input Class = Keeps all Invalid inputs.
BLACKBOX TESTING
 1. Equivalence partitioning:
 Equivalence classes may be defined according to the
following guidelines:
 1. If an input condition specifies a range, one valid and two
invalid equivalence classes are defined.
 2. If an input condition requires a specific value, one valid and
two invalid equivalence classes are defined.
 3. If an input condition specifies a member of a set, one valid
and one invalid equivalence class are defined.
 4. If an input condition is Boolean, one valid and one invalid
class are defined.
 By applying the guidelines for the derivation of equivalence
classes, test cases for each input domain data item can be
developed and executed.
BLACKBOX TESTING
 1. Equivalence partitioning:
 Example-1:

 A text field permits only numeric characters

 Length must be 6-10 characters long

 Partition according to the requirement should be like this:

Figure- Example of Equivalence partitioning]

 While evaluating Equivalence partitioning, values in all
partitions are equivalent that’s why 0-5 are equivalent, 6 – 10
are equivalent and 11- 14 are equivalent.
BLACKBOX TESTING
 1. Equivalence partitioning:
 At the time of testing, test 4 and 12 as invalid values and 7 as
valid one.
 It is easy to test input ranges 6–10 but harder to test input
ranges 2-600. Testing will be easy in the case of lesser test
cases but you should be very careful.
 Assuming, valid input is 7. That means, you belief that the
developer coded the correct valid range (6-10).
BLACKBOX TESTING
 2. Boundary Value Analysis:
 It’s widely recognized that input values at the extreme ends
of input domain cause more errors in system. More
application errors occur at the boundaries of input
domain.
 ‘Boundary value analysis’ testing technique is used to identify
errors at boundaries rather than finding those exist in center
of input domain.
 Boundary value analysis is a next part of Equivalence
partitioning for designing test cases where test cases are
selected at the edges of the equivalence classes.
 Boundary value analysis is the process of testing between
extreme ends or boundaries between partitions' of the input
values.
BLACKBOX TESTING
 2. Boundary Value Analysis:
 Boundary value analysis is the process of testing between
extreme ends or boundaries between partitions' of the input
values.
 So these extreme ends like Start- End, Lower- Upper,
Maximum-Minimum, Just Inside-Just Outside values are
called boundary values and the testing is called "boundary
value analysis testing".
 Example-1:

 Suppose you have very important tool at office, accepts valid

User Name and Password field to work on that tool, and
accepts minimum 8 characters and maximum 12 characters.
Valid range 8-12, Invalid range 7 or less than 7 and Invalid
range 13 or more than 13.
BLACKBOX TESTING
 2. Boundary Value Analysis:

[Figure-Example of Boundary Value Analysis]

 Write Test Cases for Valid partition value, Invalid partition
value and exact boundary value.
 Test Cases 1: Consider password length less than 8.
 Test Cases 2: Consider password of length exactly 8.
 Test Cases 3: Consider password of length between 9 and
11.
 Test Cases 4: Consider password of length exactly 12.
 Test Cases 5: Consider password of length more than 12.
BLACKBOX TESTING
 3. Cause effect graphing: A “Cause” stands for a separate input
condition that fetches about an internal change in the system. An
“Effect” represents an output condition, a system transformation
or a state resulting from a combination of causes.
 It is a testing technique that aids in choosing test cases that
logically relate Causes (inputs) to Effects (outputs) to produce
test cases.
 According to Myer Cause & Effect Graphing is done through
the following steps:
 Step – 1: For a module, identify the input conditions (causes)
and actions (effect).
 Step – 2: Develop a cause-effect graph.

 Step – 3: Transform cause-effect graph into a decision table.

 Step – 4: Convert decision table rules to test cases. Each column

of the decision table represents a test case.
BLACKBOX TESTING

[Figure of Cause Effect-Flow Diagram]

BLACKBOX TESTING

[Symbols used in Cause Effect-Flow Diagram]

BLACKBOX TESTING
 Example:
 The “Print message” is software that read two characters and,
depending of their values, messages must be printed.
 The first character must be an “A” or a “B”.

 The second character must be a digit.

 If the first character is an “A” or “B” and the second character is a

digit, the file must be updated.
 If the first character is incorrect (not an “A” or “B”), the message X
must be printed.
 If the second character is incorrect (not a digit), the message Y
must be printed.
BLACKBOX TESTING

[Test cases for previous example]

 Cont’d …
Example: Employee Payment validation test cases
 Decision table:

19
 Example: Credit Card issuance validation test cases

Source: Software Testing Techniques - GeeksforGeeks.html 20

 Cont’d …
 State transitional diagrams:

 Identify a finite number of states the model execution goes through

 Create a state transition diagram showing how the model transitions
from one state to the other
 Assess the model accuracy by analyzing the conditions under which
a state change occurs
 State transition: A transition between two states of a component or
system.

21
Cont’d …
Example: Flight Reservation Login States Transition

22
Cont’d …
Example: All Valid and Invalid States

23
:WHITEBOX TESTING:
 White Box Testing (also known as Clear Box Testing, Open Box
Testing, Glass Box Testing, Transparent Box Testing, Code-Based
Testing or Structural Testing) is a software testing method in
which the internal structure/ design/ implementation of the
item being tested is known to the tester.
 White Box Testing is like the work of a mechanic who examines
the engine to see why the car is not moving.
 Using white-box testing methods, you can derive test cases that

 (1) guarantee that all independent paths within a module have

been exercised at least once
 (2) exercise all logical decisions on their true and false sides

 (3) execute all loops at their boundaries and within their

operational bounds
 (4) exercise internal data structures to ensure their validity.
:WHITEBOX TESTING:

[Figure of Whitebox Testing Approach]

:WHITEBOX TESTING:
 Why and When White-Box Testing:
 White box testing is mainly used for detecting logical errors in
the program code.
 It is used for debugging a code, finding random typographical
errors, and uncovering incorrect programming assumptions.
 White box testing is done at low level design and implementable
code.
 It can be applied at all levels of system development
especially Unit, system and integration testing.
 White box testing can be used for other development artifacts like
requirements analysis, designing and test cases.
:WHITEBOX TESTING:
 Whitebox Testing Techniques:
 Following are Whitebox testing techniques:

 Statement coverage: This technique is aimed at exercising all

programming statements with minimal tests.
 Branch and decision coverage: This technique is running a
series of tests to ensure that all branches are tested at least
once.
 Path coverage: This technique corresponds to testing all
possible paths which means that each statement and
branch is covered.
:WHITEBOX TESTING:
 1. Statement coverage:
 Statement coverage is a white box testing technique, which
involves the execution of all the statements at least once in the
source code.
 Through statement coverage we can identify the statements
executed and where the code is not executed because of blockage.
 The statement coverage covers only the true conditions. The
main drawback of this technique is that we cannot test the false
condition in it.
 The statement coverage is count as per below formula:

 (Statement coverage = No of statements Executed/Total no of

statements in the source code * 100)
:WHITEBOX TESTING:
 Example:
 Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
endif
 Set1 :If A =5, B =2
No of statements Executed: 5
Total no of statements in the source code: 7
Statement coverage =5/7*100 = 71.00 %
 Set1 :If A =2, B =5 [False-Not supported by Statement coverage]
No of statements Executed: 6
Total no of statements in the source code: 7
Statement coverage =6/7*100 = 85.20 %
:WHITEBOX TESTING:
 2. Branch/Decision coverage:
 Branch coverage is also known as Decision coverage or all-
edges coverage.
 It covers both the true and false conditions unlikely the
statement coverage.
 A branch is the outcome of a decision, so branch coverage
simply measures which decision outcomes have been tested.
 This sounds great because it takes a more in-depth view of the
source code than simple statement coverage
 The formula to calculate decision coverage is:

 Decision Coverage=(Number of decision outcomes

executed/Total number of decision outcomes)*100%
:WHITEBOX TESTING:
 Example:
 READ X
READ Y
IF (X > Y)
PRINT “X is greater that Y”
ENDIF
 To get 100% statement coverage only one test case is sufficient for
this pseudo-code.
 TEST CASE 1: X=10 Y=5

 However this test case won’t give you 100% decision coverage as
the FALSE condition of the IF statement is not exercised.
 In order to achieve 100% decision coverage we need to exercise
the FALSE condition of the IF statement which will be covered
when X is less than Y.
:WHITEBOX TESTING:
 Example:…
 So the final TEST SET for 100% decision coverage will be:

 TEST CASE 1: X=10, Y=5

TEST CASE 2: X=2, Y=10
 Note: 100% decision coverage guarantees 100% statement
coverage but 100% statement coverage does not guarantee 100%
decision coverage.
 Loop Testing
 Loop testing validates four
different classes of loop
constructs
 Simple loops
 Nested loops
 Concatenated loops
 Unstructured loops

Testing occurs by varying the loop boundary values

Examples: for (i = 0; i < MAX_INDEX; i++)
while (currentTemp >= MINIMUM_TEMPERATURE)
 33
:WHITEBOX TESTING:
4. Path coverage:
 The basis path method enables the test-case designer to derive a
logical
 complexity measure of a procedural design and use this measure
as a guide for defin-ing a basis set of execution paths. Test cases
derived to exercise the basis set are guar-anteed to execute every
statement in the program at least one time during testing.
 Path Testing - Steps
1) Using the design or code as a foundation, draw a
corresponding flow graph
2) Determine the cyclomatic complexity of the resultant flow graph
3) Determine a basis set of linearly independent paths
4) Prepare test cases that will force execution of each path in the
basis set
:WHITEBOX TESTING:

[Figure of Path coverage Example]

 Path Testing – Flow Graph example
FLOW CHART 0 0
FLOW GRAPH
R4
1 1

2 2

3 R3
3

6 4 6 4
R2
7 8 5
7 R1 8 5
9
9
11 10 11 10

37
 Path Testing – Independent Paths
 Defined as a path through the program from the start node until
the end node that introduces at least one new set of processing
statements or a new condition (i.e., new nodes)
 Must move along at least one edge that has not been traversed
before by a previous path
 Basis set for flow graph on previous slide
 Path 1: 0-1-11
 Path 2: 0-1-2-3-4-5-10-1-11
 Path 3: 0-1-2-3-6-8-9-10-1-11
 Path 4: 0-1-2-3-6-7-9-10-1-11
 The number of paths in the basis set is determined by the
cyclomatic complexity

38
Path Testing – Cyclomatic Complexity
 Provides a quantitative measure of the logical complexity of a program
 Defines the number of independent paths in the basis set
 Provides an upper bound for the number of tests that must be conducted
to ensure all statements have been executed at least once
 Can be computed three ways
 The number of regions
 V(G) = E – N + 2, where E is the number of edges and N is the number of
nodes in graph G
 V(G) = P + 1, where P is the number of predicate nodes in the flow graph G
 Results in the following equations for the example flow graph
 Number of regions = 4
 V(G) = 14 edges – 12 nodes + 2 = 4
 V(G) = 3 predicate nodes + 1 = 4

39
 Path Testing Note: Test cases
 After determining the independent paths, design
test cases for each path
 The minimum number of test cases is equal to the
cyclomatic complexity.
 Problem – path testing cannot test all possible
combinations of paths through a program. There
are an infinite number of possible path
combinations in programs with loops
 IN GENERAL…

Number of Number of
 test cases
program
Paths required for
branch
coverage

Path  Branch
Coverage Coverage
:COMPARISON OF BLACKBOX TESTING AND
WHITEBOX TESTING:
:COMPARISON OF BLACKBOX TESTING AND
WHITEBOX TESTING:
White Box and Black Box Testing: Notes

• BBT: Functional test is applicable in testing at all

granularity levels:
• Unit test (from module interface spec)
• Integration test (from API or subsystem spec)
• System test (from system requirements spec)
• Regression test (from system requirements + bug
history)
• WBT: Structural test is applicable in testing relatively
small parts of a system:
• Unit test

44
Choosing test Techniques

 How do you choose the right

technique?
 Type of system
 Standards
 Customer or contractual requirements
 Level of risk
 Type of risk
 Testing objectives
 Documentation available
 Knowledge / skills of the testers
 Time and budget
 Development processes
 Pick the right techniques for the right
situation
Choosing test techniques
• The choice of which test techniques to use depends on a
number of factors, including:
 Activity5[Page Limit:1 page, Due date:1 May 2023]

1 What is test coverage? What is code coverage?

2 Differentiate path testing vs Control flow testing vs Data
Flow Testing.
3 When do we not use path testing?
4 How and why do we measure code complexity?
5 How do we know the number of test paths of the code
module?

47