Unit Testing Module2023

JMSE-TEST - Software Testing &
Quality Assurance
Unit 4: Unit testing
Dr. Manal Shoman

Course Title: Software Testing & Quality Assurance
Unit 5: Testing techniques
Joint Master in Software Engineering Software Testing & Quality Assurance 2

Introduction
• The main objective of unit testing is to isolate the smallest piece of testable software
(module, function class) in the system, from the remainder of the code, and check
whether it behaves exactly as expected.
• Unit testing verifies that the component functions correctly (in a controlled
environment) with the expected output.
• large percentage of defects are recognizes during unit testing.
• unit testing allows us to isolate the errors to a single module.
• Unit test concentrate on the internal processing logic and data structure within the
unit.
• can be conducted in parallel for multiple

Joint Master in Software Engineering
Software modules.
Testing & Quality Assurance
Introduction
Unit testing found the following errors:
• computation errors
• Incorrect comparison
• Improper control flow
• Misunderstand and incorrect arithmetic precedence
• Mixed mode operation
• Incorrect initialization
• Precision inaccuracy
This unit covers: black box, white box and mutation testing techniques
Objectives
At the end of this unit the student would be able to:
• Understand meaning of unit testing
• Distinguish black box vs. white box testing
• To learn the basic white box and black box testing techniques.
• Identify equivalence classes for any given variable.
• Design test cases corresponding to equivalence class testing and boundary value
analysis for any given problem.
• Recognize and distinguish basic terms Adequacy and coverage
5
Joint Master in Software Engineering Software Testing & Quality Assurance Section 4
Objectives
At the end of this unit the student would be able to:
• Understand Concept of structural testing
• Design statement coverage test cases for a code segment.
• Design branch coverage test cases for a code segment.
• Design condition coverage test cases for a code segment .
• Draw control flow graph for any program.
• Identify the linear independent paths.
• Compute cyclomatic complexity from any control flow graph.
• Understand mutation testing as one application of fault-based testing principles
6
Joint Master in Software Engineering Software Testing & Quality Assurance
Unit 5: List of topics
1. Black Box Testing
2. White Box Testing,
3. Mutation Testing

Topic 1: Black Box Testing
8
• black-box technique also called, data-driven, or input/output- driven

testing.
• To use this method, view the program as a black box.
• This technique is to be completely unconcerned about the internal
structure of the program.
• It concentrate on finding cases in which the program does not
behave according to its specifications.
• Test case designer has no knowledge of algorithm implementation.
• test cases are designed from the requirement specification.

9
Software Testing & Quality Assurance
black box testing fundamentals

• view the program as a black box.
• known as specification-based testing, focuses on the functional requirements of the
software.
• Depends on inputs and outputs, with no knowledge of its implementation.
requirements
output
input
10

used to ensure that:
(1) the program does what it is supposed to do and
(2) does not do what it is not supposed to do.
can be applied in unit, integration, system and acceptance testing.
Dynamic testing, because the program is running

11

Inputs causing
anomalous
Input test data I behaviour
e
System
Outputs which reveal

the presence of
Output test results Oe defects


Attempts to find errors in the following categories:
Incorrect or lost functions
Interface errors
data structures errors and external database access
performance and behaviour errors
Initialization and termination errors

13

black box testing techniques are as follows:
• equivalence partitioning
• boundary value testing, and
• random testing.

14
Equivalence Partitioning
Equivalence partition (EP) or Equivalence Class (EC) is a method used to reduce the
number of test cases to a controllable level while maintaining reasonable test
coverage.
EC divides the input domain of a program (unit) into partitions (classes) of data
from which test cases can be derived.
Each EC comprise of a set of data that is treated the same by the unit or that
should exhibit the same result.
Data values within a class is equivalent, in terms of testing, to any other value.
Test cases are designed to cover each partition at least once.
This is a valuable technique because it is promising to uncover a class of errors
at a time, corresponding to the class of input.

15
Input domain
Input domain partitioned into four
partitions.
2
1
3
4
Large set of Four test inputs, one

test inputs. selected from each
Fig (a) partition .
Fig (b)
EQP Reduces test cases
16
equivalence partitioning test cases design steps:

(1) identify the equivalence classes and
(2) define the test cases.

Identifying the Equivalence Classes
First-level partitioning: Valid vs. Invalid values
Invalid Valid

Identifying the Equivalence Classes
Partition valid and invalid classes into equivalence classes
Invalid Valid
If there is any purpose to expect that the program does not treat elements in an
equivalence class identically, split the equivalence class into smaller equivalence
classes.
Guidelines of Equivalent classes

1. Input is a range –> one valid and two invalid equivalence classes:
less than range in range greater than range
Input condition is a range: there are a minimum of 3 classes of values, one valid
and two invalid classes are defined.
Example
Input condition
– range of values x: 1-50

• Valid equivalence class
– 1 < x < 50
• Invalid equivalence classes
–x<1
– x > 50

20
 Input condition requires specific value: one valid and two invalid classes are defined
Input is a specific value –> one valid and two invalid equivalence classes:
less than value value greater than value

21
Input condition is Boolean: one valid and one invalid class are defined
Input is Boolean –> one valid and one invalid class:
non Boolean Boolean

22
Input is a set of related values –> one valid and one invalid
not member of set

member of set

23
Examples
Input Condition Data Description values # valid classes # invalid classes
Range Age 1 – 99 1 2
Specific value Expiration Year 2005 1 2
Set Color red, blue green 1 1
Boolean balance overdue? True 1 1

Identifying the Test Cases
The process is as follows:
1. Assign a identifier to each equivalence class.
2. Until all valid equivalence classes have been covered by at least one test
case, write a new test case covering as many of the valid equivalence
classes as possible.
3. Until all invalid equivalence classes have been covered, write a test case
that covers one, and only one, of the uncovered invalid equivalence
classes.
For each test case, assign it with the equivalence class identifiers that it covers.

Identifying the Test Cases
Invalid Valid

Equivalence Partitioning: Example 1

Suppose that program P takes an input X, X being an integer.
For X<0 perform task (T1)
For X>=0 perform task (T2)

27
Equivalence Partitioning: Example 1

Equivalence class Equivalence class
One Possible X<0 X>=0

Test Case: Another test case:
X=-3 X=15
 All test inputs in the X<0 partition are considered equivalent.

 The assumption is that if one test input in this partition reveals an error in the
program, so will the others.
 This is true of the test inputs in the X>=0 partition also.
28
Advantages & disadvantages of EC

Advantages
A few number of test cases are required.
equivalence class partitioning technique used for both input and output
disadvantages
Assumptions of equivalence can be tricky – and incorrect
Designing a well equivalent class is difficult
dependent on the testers’ intuition
29
Boundary value testing
• Boundary value analysis (BVA) technique complements equivalence

partitioning.
• is a special case of equivalence testing focuses on the boundary values
of input variables.
• focuses on tests at and near the boundaries of equivalence classes.
• targets faults at the boundaries of equivalence classes.
• applied to both input and output conditions.

30
Invalid Valid


BV Steps:
1. Identify the ECs.
2. Identify the boundaries of each EC.
3. Create test cases for each boundary value by choosing one point on
the boundary, one point just below the boundary, and one point
just above the boundary.

32
GUIDELINES of BOUNDARY VALUE SELECTION

1. If the input range is bounded by a and b, then use a, b, and values just above
and just below a and b, respectively.
a b
Example:
Integer D with input condition [-3, 5]
Test values: -3, 5, -2, 6, -1, 4

GUIDELINES of BOUNDARY VALUE SELECTION
2. If the input is a number of values, use the minimum and maximum of the values and values just above and just below
them, respectively.
min max
Example:
Enumerate data E D with input condition {3, 5, 50, 75, 100, 102}
Test values: 3, 102, -1, 5, 100,110
3. Apply guidelines 1 and 2 to create output values at the minimum and maximum expected values.
4. If data structures have boundaries, test these boundary values and values just above and just below them, respectively.
e.g., for an array of bounds 1 to 10 — test array index equal to 0, 1,2, 9, 10, 11

34
advantages and disadvantages of BVA

Advantages
– Commercial tool support available
– Easy to automate
– Appropriate for computation-Intensitive applications with variables that
describe physical quantities (e.g., have units, such as meters, degrees,
kilograms)
Disadvantages
– Does not work well for Boolean variables
Does not work well for logical variables
– Tools only generate inputs, user must generate expected outputs.

35
Example
function which takes a parameter “month”.
valid range for the month is 1 to 12, representing January to December.
two further partitions of invalid ranges.
x<1 1 ≤ x ≤ 12 12 < x
Test cases are chosen so that each partition would be tested.
-2 5 17
x<1
1 ≤ x ≤ 12
12 < x
Example
Test cases are supplemented with boundary values.
-2 1 5 12 17
0 2 11 13
x<1 1 ≤ x ≤ 12 12 < x

Example
• Consider a software unit that is designed to accept the name of a grocery item and
a list of the distincit sizes the item arrives, specified in ounces.
• The requirements are:
a) item name: alphabetic characters (length 2 to 15 characters).
b) Size: a value in the range [1 to 48].
c) The sizes are accepted in ascending order (smaller sizes first).
d) A maximum of five sizes may be entered for each item.
e) The item name is to be entered first, followed by a comma, then followed by a list of sizes.
f) A comma will be used to separate each size.
g) Spaces (blanks) are to be ignored anywhere in the input.

Derived Equivalence Classes

1.Item name is alphabetic (valid)
13. Size values entered in ascending order (valid)
2.Item name is not alphabetic (invalid)
14. Size values entered in nonascending order (invalid)
3.Item name is less than 2 characters in length
15. No size values entered (invalid)
(invalid)
4.Item name is 2 to 15 characters in length (valid) 16. One to five size values entered (valid)
5.Item name is greater than 15 characters in 17. More than five sizes entered (invalid)
length (invalid) 18. Item name is first (valid)

6.Size value is less than 1 (invalid) 19. Item name is not first (invalid)
7.Size value is in the range 1 to 48 (valid) 20. A single comma separates each entry in list (valid)
8.Size value is greater than 48 (invalid) 21. A comma does not separate two or more entries in the
9.Size value is a whole number (valid)
list (invalid)
10.Size value is a decimal (invalid)
22. The entry contains no blanks (???)
11.Size value is numeric (valid)
23. The entry contains blanks (????)
12.Size value includes nonnumeric characters
(invalid)
Black Box Test Cases

#Test Data Expected Classes Covered
Outcome
1 xy,1 T 1,4,7,9,11,13,16,18,20,22
2 AbcDefghijklmno,1,2,3,4,48 T 1,4,7,9,11,13,16,18,20,23
3 a2x,1 F 2
4 A,1 F 3
5 abcdefghijklmnop F 5
6 Xy,0 F 6
7 XY,49 F 8
8 Xy,2.5 F 10
9 xy,2,1,3,4,5 F 14
10 Xy F 15
11 XY,1,2,3,4,5,6 F 17
12 1,Xy,2,3,4,5 F 19
13 XY2,3,4,5,6 F 21
14 AB,2#7 F 12
Advantages & Disadvantages Black Box Testing

Disadvantages
Advantages
• more effective on larger units of code • only a small number of possible inputs can actually be tested, to
test every possible input stream would take nearly forever;
than glass box testing; • without clear and concise specifications, test cases are hard to
• tester needs no knowledge of design;
implementation, including specific • there may be unnecessary repetition of test inputs if the tester
is not informed of test cases the programmer has already tried;
programming languages; • may leave many program paths untested;
• tester and programmer are •cannot be directed toward specific segments of code which may
independent of each other; be very complex (and therefore more error prone);
• tests are done from a user's point of • most testing related research has been directed toward glass
box testing.
view;
• will help to expose any ambiguities or
inconsistencies in the specifications;
• test cases can be designed as soon
as the specifications are complete.

Topic 2: White Box Testing

42
• White box testing is applied through unit testing and applied by the developer
engineer.
• the software source is like a glass box in which everything inside the box is visible.
• It is a verification technique software engineers can use to examine if their code
works as expected.
• IT is also known as structural testing, clear box testing, glass box testing and code-
based test
• It is a test case design technique that based on expected behavior and uses the
control structure of the unit design to deduce test cases.

43
White-Box fundamentals
derives test cases based on the program’s logic
goal is to ensure that all statements and conditions have been executed at least
once
decide whether all of the software units do what they are designed for and error-
free
assumes that the tester knows everything about the software.

is much more expensive than Black Box testing.

44
White-Box fundamentals
white-box testing methods, apply test cases that
(1) Guarantee that all independent paths within a unit have been executed at
least once,
(2) Execute all logical decisions on their true and false sides,
(3) Execute all loops at their boundaries and within their operational bounds,
and
(4) Execute data structures to ensure their validity.

45
Exhaustive testing
indicate testing the given program with every member of the input value space
It is infeasible to realize exhaustive testing in general
For sample shown in the figure
There are 1014 possibility paths! If we execute one test per millisecond, it would take
3170 years to finished test
Test coverage criteria
execute a program using a definable and reasonable number of test cases
a selected path
loop 

46
Topic2: White-Box Testing
white-box testing techniques:

Statement coverage
branch coverage
condition coverage
path coverage

Statement coverage
• Ensures each statement in a program is executed at least once.
• The main consideration is that unless a statement is executed,

it is difficult to determine it has an error.
• Behaving a statement properly for one input value does not

guarantee that it will behave correctly for all input values

Example: Statement Coverage

1 int maxPositive(int n1, int n2) {
2 if (n1<=1 && n2<=1)
3 n1=1;
4 if (n1<=n2)
5 n1=n2;
6 return n1; }
Test Case: n1=n2=1

Guarantee statement coverage
Example
int compute-gcd (int x, int y){
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else y=y-x;
5}
6 return x;
GCD function }
Test cases set {(x=3,y=3),(x=4,y=3), (x=3,y=4)}
all statements are executed at least once.
Branch Coverage
Branch Coverage requires that each branch must be executed, and that every
program entry point will have been taken, at least once.
Also called Edge Coverage or decision coverage.
It executes of Boolean expressions of the unit as both true and false.
It stronger coverage technique guarantees statement coverage and evaluate an
compound Boolean expression as one true-or-false predicate.
The objective is to accomplish 100% branch coverage.
In large systems only 75%-85% is practical.

Branch Coverage- Example 1

3 if (a == 0) {
7 if ((a==b) OR ((c == d) AND bug(a) )) {
Table above shows three of the four necessary conditions - 75% branch
coverage.
add Test Case 3 : foo(1, 2, 1, 2, 1) to bring us to 100% branch coverage
52
Branch Coverage- Example 2

The following paths are sufficient
1
for branch coverage:
a > 1 AND true
b=0
1–2–4–5–7 false
2
1–3–4–6–7 x←x/a 3
Possible input: a == 2 true

OR x>1
1. a = 2, b = 2, x = -1 6
false x ←x+1 5
2. a = 3, b = 0, x = 1
7

Example
int compute-gcd (int x, int y){ Euclid's GCD function
1 while (x != y){
Test set {(x=3, y=3), (x=3, y=2),
2 if (x>y) then (x=4, y=3), (x=3, y=4)}
3 x=x-y; Satisfy branch coverage.
4 else y=y-x;
5}
6 return x; }

Branch Coverage
• Advantage:
easy to understand
simple to realize 100% coverage
overcomes the shortcomings of statement coverage.
• Disadvantage:
100% branch coverage does guarantee that the logical structure of the decision
point will be adequately tested.

55
Condition coverage
Designed test cases such that:
• each component of a compound decision expression takes on all possible outcomes (both
true and false) at least once
• Condition Coverage does not demand that each decision exercises on all possible outcomes
• Example: if Not (A or B) then C
• apply A = True, B = False, then A = False and B = True satisfies Condition Coverage,
although statement C will never be executed
• it tests relational operator like <, ≤, >, ≥, =, ≠ and Boolean operators like OR (|), AND (&),
NOT(⌐) that exist in your program.
• It is a measure of percentage of Boolean sub-expressions of the program that have been
evaluated as both true or false outcome in test cases.
• It is similar to decision coverage but has better sensitivity to the control flow.
• defined by the following formula
• Condition coverage = ( Total decisions exercised / Total number of decisions in
program)*100
• gives an indication of the percentage of conditions covered by a set of test cases
56
Condition Coverage –Example 1

if A or B then
s1 A B Branch
else
test 1 T F true
s2
end_if_then_else test 2 F T true
  
Condition Coverage => Branch Coverage

Condition Coverage –Example 2
Test cases for condition coverage: IF (A>1)&(B=0) THEN

A=1,B=0,X=3
X=X/A;
END;
A=2,B=1,X=0
IF (A=2)|(X>1) THEN
each condition be true and false once.
X=X+1;
END;

Multiple Condition Coverage

• Determine for each atomic (does not include AND or OR) condition
true and false combinations
• Drive test cases to execute each combination
• Multiple condition coverage also guarantee statement and branch
coverage

Multiple Condition Coverage: Example1

Consider D=(A<B) OR (A>C) composed of two simple conditions
A< B and A> C
four possibility combinations of the result of the two simple
conditions.
T or T
1 F or T
Does T doesn't cover all four combinations
T’ cover all four combinations
T or T
1 F or T
T or F
F or F60
Multiple Condition Coverage example2
int proc(int a, int b, int x)Need test cases satisfy the following”
{ 1. a > 1 is true and b = 0 is true
if ( (a>1) && (b==0) )
{ 2. a > 1 is true and b = 0 is false
x = x/a; 3. a > 1 is false and b = 0 is true
}
if ( (a==2) || (x>1) ) 4. a > 1 is false and b = 0 is false
{ 5. a = 2 is true and x > 1 is true
x = x+1;
} 6. a = 2 is true and x > 1 is false
return x; 7. a = 2 is false and x > 1 is true
}
Possible8. 2 is false
inputa to=satisfy test and x > 1 is false
cases:
a = 2, b = 0, x = 2 [1][5]
a = 2, b = 1, x = 0 [2][6]
a = 0, b = 0, x = 2 [3][7]
a = 0, b = 1, x = 0 [4][8]
Path Coverage
•Test each of the possible paths in each unit.
•also known as predicate coverage.
•Goal of path testing is to guarantee that test cases is will execute path
through the program is executed at least once.
• Design test cases satisfy that all linearly independent paths in the unit
are executed at least once.
• linearly independent path defined in using control flow graph (CFG) of
the component.
• The strongest testing technique
Path Coverage
Deriving Test Cases is as follows:
Step 1 : draw a flow graph Using the design or code of a unit,.
Step 2: Determine the cyclomatic complexity of the flow graph.
Step 3: Determine a basis set of linearly independent paths.
Step 4: Prepare test cases that will satisfy execution of each path in the basis set.

Path Coverage
Control flow graph represents:
way in which all statements executed.
control flows moving through the unit.
CFG steps:
Assign numbers to all the statements of the unit.
Numbers of statements:
depict nodes of the CFG.
An arc (edge) from one node to other node exists:
if execution of the statement presenting the first node
can proceed in
Joint Master in Software Engineering carry
Software over
Testing ofAssurance
& Quality control to the other node. 64
Control Flow Graphs (CFGs)
A control flow graph (CFG) captures the flow of
control in a program.
It consists of basic blocks and arcs connecting those
blocks.
A basic block is the longest possible sequence of
consecutive statements in a program (entry at
the first statement and exit from the last).
Let us see an example.

1 begin
2 int x, y, power;
3 float z;
4 input (x, y);
5 if (y<0)
6 power = -y;
7 else
8 power = y;
9 z = 1;
10 while (power! = 0){
11 z = z∗x; Takes two integers
12 power = power -1; x and y and
13 }
14 if (y<0)
outputs xy
15 z = 1/z;
16 output (z);

1 begin
2 int x, y, power;
3 float z; Basic block
4 input (x, y);
5 if (y<0)
6 power = -y;
7 else
8 power = y;
Basic block
9 z = 1; Takes two integers
10 while (power! = 0){ x and y and
11 z = z∗x; outputs xy
12 power = power -1;
13 }
14 if (y<0)
15 z = 1/z;
Control Flow Graph
A path through a control

flow graph is a
sequence of edges,
indicating the flow of
control in a
corresponding program.
(Start, 1, 3, 4, 5, 6, 5, 7, 8,
9, End)
(Start, 1, 2, 4, 5, 7, 9, End)
(Start, 1, 2, 4, 8, 9, End)
Path Coverage
basic structure constructs in a control flow graph
Sequence
If Then Else While

..
.
Until
Case

Path Coverage
Linearly independent path
A path through a CFG is a sequence of node and edge from the start
node to the end node of the CFG
An independent path is a path in the CFG that insert one newly node
at least which is not enclosed in any other independent paths.

Path Coverage
Example
int f1(int x,int y){
1
1 while (x != y){
2
2 if (x>y) then
3 x=x-y; 3 4
4 else y=y-x; 5
5} 6
6 return x; }
Path Coverage
Cyclomatic Complexity
• Cyclomatic complexity is a type of quantitative measure of complexity of a
program.
 Applied in the basis path testing method,
the cyclomatic complexity value defines the count of linearly independent paths.
 the value of cyclomatic complexity defines an upper bound of number of tests
(i.e., paths) that must be designed and exercised to guarantee path coverage
of the program
 it informs approximately how many paths to look for.

73
Path Coverage
Cyclomatic Complexity
Three methods to calculate cyclomatic complexity V(G) of a CFG G:

1. Cyclomatic complexity, V(G), for a flow graph G is defined as
V(G) = E - N +2
E is the number of edges and N is the number of nodes.
2. Cyclomatic complexity, V(G) = P + 1
P is the number of simple predicate nodes in G.
3. The number of regions of the flow graph.
1. V(G) = 11 edges -9 nodes + 2 = 4.
OR number of enclosed areas + 1 3. V(G) = 3 predicate nodes + 1 = 4.
3 The flow graph has four regions.

74
Path Coverage
Cyclomatic Complexity 1
Example of Control Flow Graph 2
3 4
Cyclomatic complexity = 7-6+2 = 3.
5
number of bounded areas is 2. 6

cyclomatic complexity = 2+1=3

Path Coverage
Example
int f1(int x,int y){ 1
1 while (x != y){ 2
2 if (x>y) then 3 4
3 x=x-y; 5
4 else y=y-x; 6
5}
6 return x; }
Test Cases
Number of independent paths: 3 1
Path 1: 1,6 test case (x=1, y=1) 2
Path2: 1,2,3,5,1,6 test case(x=1, y=2)

3 4
Path 3: 1,2,4,5,1,6 test case(x=2, y=1)
5

Path Coverage Example 3

procedure: process records
1. do while records remain
2. read record;
3. if record field 1 = 0
4. then store in buffer;
5. increment counter;
6. elseif record field 2 = 0
7. then reset counter;
8. else store in file;
9. endif
10. endif
11. enddo
end 78
Path Coverage Example 3
3
6 4
7 8
9 5
11 10
1-2-3-6-7-9-10-1-11 1-2-3-6-8-9-10-1-11 1-2-3-4-5-10-1-11 1-11

80
Loop Testing
• Branch coverage is not adequate to test the achievement
of loops
• It indicate two scenarios will be tested: the loop is run
zero times, and the loop is run at least once
• Motivation for loops testing: very often there are errors in
the boundary conditions
• Loop testing is a white-box technique that concentrate on
the validity of loops

Loop Testing p1
The Goal is to execute loops at end
within their bounds.
Two main components of the loop c1 p3
structure are:
A body statement (P2) which is
executed repeatedly
p2
A control statement (c1) that decide
whether if the body of statements
should be executed and thus serve
as entering and outgoing criteria.
.
Loop Testing
Seven situation proposed for each loop are:
1. Go around the loop (never enter the loop)
2. Go into the loop once
3. Go into the loop twice
4. Go into the loop some “typical” number
5. Go into the loop (max-1) times
6. Go into the loop (max) times
7. Go into the loop (max + 1) times

Loop Testing
Four different categories of loops are: simple loops, concatenated loops, nested loops, and unstructured loops
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops 84
Loop Testing
1. Test cases for simple loops (n iterations)
1 skip the loop entirely
2 only one pass through the loop
3 two passes through the loop
4 m passes through the loop where m < n
5 n-1, n, n+1 passes through the loop
Where n is the maximum number of allowable passes

Loop Testing
2. Test cases Nested Loops
1 Conduct simple loop tests for the innermost loop
while holding the outer loops at their minimum
iteration p1
2 Work outward, conducting tests for the next

c p3
innermost loop 1
Outer
3 Continue until all the loops have been tested loop
p2 p 21
 Tests grow geometrically as the level of nesting C

2 Inner
increases 1 loop
p 22
Loop Testing
3. Test cases Concatenated Loops
 If loops are independent loops  use
simple loop testing
 If loops are dependent loops  use nested
loop testing
4. Test cases Unstructured Loops

 Redesign the code
These loop test are designed to have the highest likelihood of
uncovering errors with the minimum amount of effort and overlap of
tests.

Loop Testing example

float avg_negative_balance (int arraysize, float balances[])
{
float total = 0.0;
int count = 0;
for I = 1 to arraysize
if ( balances[I] < 0 )
total += balances[I];
count ++;
end if;
end for;
return total / count;
}
Test Case Test Data
N=0 size = 0
N=1 size = 1
N = max-1 size = 999 (if SRS says max=1000)
N = max size = 1000
N = max+1 size = 1001, but array has only 1000 elements
Loop Testing &example

int ReadLine(istream is, char buf[], int bufLen) {
int count = 0;
while (count < bufLen) {
int c = is.get();
if (c != -1 && c != '\n')
buf[count++] = (char)c;
else
break;
}
return count;
} 1) Skip loop entirely:
a. bufLen == 0
2) Exactly one pass:
a. line of length 1 (including the '\n') OR bufLen == 1
3) Exactly two passes:
a. line of length 2 OR bufLen == 2
4) N-1, N, and N+1 passes:
a. lines of length bufLen-1, bufLen, and bufLen+1
5) M passes, where 2 < M < N-1
Joint Master in Softwarea. line of length
Engineering bufLen
Software Testing/&2
Quality Assurance
Advantages and disadvantages of White-Box Testing

Advantage:
can test extra functions
Disadvantages:
cannot test missing functions
selection of test cases can only be carried out after coding

90
Unit testing tool

Java Testing Tools
junit is a unit testing.
emma is a code coverage tool.
The tools provide statement and branch coverage reports during the unit testing
technique.
Junit Enables rapid and simple test creation, execution, and evaluation
JUnit is an open source unit testing tool for Java language developed by Kent Beck
and Erich Gamma.
Tests can be scattered in code or organized into separate suites
http://www.junit.org/

EclEmma free and easy to use.
EclEmma which is integrated into Eclipse
http://www.eclemma.org/
• See file JUnit_EclEMMA.pdf for instruction and example.

• http://junit.sourceforge.net/
• http://www.eclemma.org/

Thank you for
your attention.

Unit Testing Module2023

Uploaded by

Copyright:

Available Formats

You might also like

Unit Testing Module2023

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit Testing Module2023

Uploaded by

Copyright:

Available Formats

JMSE-TEST - Software Testing &

Unit 4: Unit testing

Dr. Manal Shoman

Unit 5: Testing techniques

Joint Master in Software Engineering Software Testing & Quality Assurance 2

• large percentage of defects are recognizes during unit testing.

• unit testing allows us to isolate the errors to a single module.

• can be conducted in parallel for multiple

At the end of this unit the student would be able to:

• Understand meaning of unit testing

• Distinguish black box vs. white box testing

• Identify equivalence classes for any given variable.

• Recognize and distinguish basic terms Adequacy and coverage

Joint Master in Software Engineering Software Testing & Quality Assurance 7

• black-box technique also called, data-driven, or input/output- driven

Joint Master in Software Engineering

black box testing fundamentals

black box testing fundamentals

Joint Master in Software Engineering

black box testing fundamentals

Outputs which reveal

Joint Master in Software Engineering Software Testing & Quality Assurance

black box testing fundamentals

Joint Master in Software Engineering

black box testing fundamentals

• boundary value testing, and

Joint Master in Software Engineering

Joint Master in Software Engineering

Large set of Four test inputs, one

EQP Reduces test cases

equivalence partitioning test cases design steps:

Joint Master in Software Engineering Software Testing & Quality Assurance

Joint Master in Software Engineering Software Testing & Quality Assurance

Guidelines of Equivalent classes

less than range in range greater than range

– range of values x: 1-50

Joint Master in Software Engineering

Guidelines of Equivalent classes

less than value value greater than value

Joint Master in Software Engineering

Guidelines of Equivalent classes

Input is Boolean –> one valid and one invalid class:

non Boolean Boolean

Joint Master in Software Engineering

Guidelines of Equivalent classes

not member of set

Joint Master in Software Engineering

Input Condition Data Description values # valid classes # invalid classes

Specific value Expiration Year 2005 1 2

Set Color red, blue green 1 1

Boolean balance overdue? True 1 1

Joint Master in Software Engineering Software Testing & Quality Assurance

Joint Master in Software Engineering Software Testing & Quality Assurance

Joint Master in Software Engineering Software Testing & Quality Assurance

Equivalence Partitioning: Example 1

For X<0 perform task (T1)

For X>=0 perform task (T2)

Joint Master in Software Engineering

Equivalence Partitioning: Example 1