Chapter 6: Coding and Testing

• Topics to be covered include:

–Coding phase: Issues to be considered
during coding, Types of code
verification
–Testing Phase: Approaches to Testing
(Functional and structural), Levels of
testing (Unit, Integration, System,
Acceptance)
•
Ch - 06: Coding and Testing 1
6.1 Coding Phase

Ch - 06: Coding and Testing 2

 …
The goal of the coding or programming phase
is to translate the design of the system
produced during the design phase into code in
a given programming language.
The goal during the phase is not to simplify
the job of programmer, rather to simplify the
job of the tester and the maintainer.
During implementation, it should be kept in
mind that the programs should not be
constructed so that they are easy to write, but
so that they are easy to read and understand.
Ch - 06: Coding and Testing 3
Issues to be considered during coding:
1) Programming Methodology
 Top-down or Bottom-up methods may be used.
 In top-down, the implementation starts from the top of
the hierarchy (the main module), then its subordinates
are implemented, and their subordinates, and so on.
 This simplifies your programming.

Ch - 06: Coding and Testing 4

 …
2) Program Style
 Program names:
 variable names should be closely related to the entity they
represent, and module names should reflect their activity.
 Make the names as close as possible to the real-world entities of
the problem; this makes readability and understandability
simpler.
 Program Layout:
 proper indentation, blank spaces, and parentheses should be
used to enhance the readability of programs.
 Be consistent with one convention of style.

Ch - 06: Coding and Testing 5

 …

3) Program Portability
• Make your program so that it can be used on
different machines with little modification.

Ch - 06: Coding and Testing 6

 Types of code verification
1) Dynamic verification: The program is executed with some
test data and the outputs of the program are examined to
determine if there are any errors present.
2) Static verification: There is no actual execution of the
program on actual data. But execute (test) with symbols
manually.
 In static techniques, often the errors are detected directly,
unlike dynamic techniques where only the presence of an
error is detected.

Ch - 06: Coding and Testing 7

 Two static methods
i. Code Reading:
 Involves careful reading of the code by the programmer
to detect any discrepancies between the design
specifications and the actual implementation.
 Best done by reading the code inside-out (starting with
the innermost structure of the module).
ii. Symbolic execution: symbols are to be used.

Ch - 06: Coding and Testing 8

 …
 E.g. Consider the following function that swaps two integers:

1. void swap(int x, int y)

2. int temp;
3. {
4. temp = x;
5. x = y;
6. y = temp;
7. }

Ch - 06: Coding and Testing 9

 …
• Symbolic execution of the above fragment
with symbols x1 and y1:
After Statement x y temp
1 x1 y1 ?
4 x1 y1 x1
5 y1 y1 x1
6 y1 x1 x1

Ch - 06: Coding and Testing 10

6.2 Testing Phase

Ch - 06: Coding and Testing 11

 …
 Testing is a process of demonstrating the presence of errors.
 Its goal is to find errors but not to fix errors.
 One should not start testing with the intent of showing that a
program works; but the intent should be to show that a program
does not work.
 Hence, with this in mind we define testing as: “the process of
executing a program with the intent of finding errors.”
 One of the hard issues in testing is “when to stop testing”.

Ch - 06: Coding and Testing 12

 …

• One of the reasons many organizations require a

product to be tested by people not involved with
developing the program before finally delivering
it to the customer is that it is hard to be
destructive to something we have created
ourselves, and we all like to believe that the
program we have written ‘works’. (Psychology of
testing).

Ch - 06: Coding and Testing 13

 Approaches to Testing
 There are two approaches to testing: functional testing and
structural testing.
A. Functional Testing (Black-Box Testing)
 The structure of the program is not considered.
 Test cases are decided solely on the basis of the requirements or
specifications of the program or module, and the internals of the
module or the program are not considered for selection of test cases.
 Concerned with the function that the tested program is supposed to
perform but not concerned with implementation of the program.

Ch - 06: Coding and Testing 14

 …
Techniques for generating test cases for functional
testing:
The most obvious functional testing procedure is
exhaustive testing; but this is impractical.
One criterion for generating test cases is to generate them
randomly.
This strategy has little chance of resulting in a set of test
cases that is close to optimal (i.e., that detects the
maximum errors with minimum test cases).

Ch - 06: Coding and Testing 15

 Equivalence Class Partitioning
 This is a technique that can be used to select test case for
functional testing.
 Because we cannot do exhaustive testing, the next natural
approach is to divide the domain of all the inputs into a set of
equivalence classes, so that if any test in an equivalence class
succeeds, then every test in that class will succeed.
 That is, if the program behaves well on a member of the class,
then it is assumed for the whole class.

Ch - 06: Coding and Testing 16

 …
• E.g.1. Consider a ‘program’ that accepts input
between 20 and 35.
Test cases Data (input)
Case 1: values < 20 10
Case 2: values > 35 100
Case 3: values between 20 and 35
(inclusive) 25

Ch - 06: Coding and Testing 17

 …
 E.g.2. Consider a function that searches or looks for a key in an array and sets
its index to S if key is found otherwise sets S to -1.
S = Search (Array, size, key);
Test cases
1. Array size is 1, key is in the array.
2. Array size is 1, key is not in the array.
3. Array size is empty, key is in the array or not.
4. Array size is even, key is in the array
5. Array size is even, key is not in the array
6. Array size is odd, key is in the array
7. Array size is odd, key is not in the array

Ch - 06: Coding and Testing 18

 …

• Input (array, key) Expected output (S) Test case (s) used
• {10}, 2 -1 2, 7
• {1, 2, 3}, 3 2 (if 1st index = 0) 6
• {2}, 2 0 1, 6
• {} -1 3
• {11, 3}, 11 0 4
• {11, 12}, 13 -1 5

Ch - 06: Coding and Testing 19

 …
B. Structural Testing (White-Box or Glass-Box Testing)
 Concerned with testing the implementation of the program.
 Test cases are generated for functional testing, which are
frequently imprecise, the criteria for structural testing are
generally quite precise as they are based on program
structures, which are formal and precise.

Ch - 06: Coding and Testing 20

 …
• Approaches to structural testing: Control flow-based testing
and Data flow-based testing.
1. Control Flow-Based Testing
– Most common structure-based criteria (testing) are based on the
control flow of the program.
– In these criteria, the control flow-graph of a program is considered
and coverage of various aspects of the graph are specified as criteria.
– Control flow-graph (or simply flow-graph) of a module /program is a
graph consisting of nodes and arcs.
• A node represents a block of statements that is always executed
together.
• An arc from nodei to nodej represents a possible transfer of control
from the last statement of nodei to the first statement of nodej.

Ch - 06: Coding and Testing 21

 …
E.g. Draw the flow graph of the following segment.
1. {
2. i = 1;
3. while (i <= n)
4. {
5. j = 1;
6. while (j <= i)
7. {
8. if (A[ i ] < A[ j ])
9. Swap (A[ i ], A[ j ];
10. j = j + 1;
11. }
12. i = i + 1;
13. }
14. }

Ch - 06: Coding and Testing 22

 …
• The control graph:
1,2,3

4,5,6

13,14 7,8

11,12 9
10

Ch - 06: Coding and Testing 23

 …
 Now, let us consider control flow-based criteria:
a. Statement Coverage Criteria:
 Requires that each statement of the program be
executed at least once during testing
 Requires that the paths executed during testing include
all the nodes in the path (all-nodes criterion).
 Limitation: does not require a decision to evaluate to false if no else clause
in an if statement.

Ch - 06: Coding and Testing 24

 …
 E.g. The following fragment returns an absolute value of a number.

1. int abs(x)
2. {
3. if ( x >= 0)
4. return x;
5. }
 Here, the statement coverage criterion will be satisfied by test
cases with the set {0, 1, 2, 3, …} but does not reflect the error
(leaves the error undetected) if x < 0.

Ch - 06: Coding and Testing 25

 …
b) Branch Coverage Criteria:
– Requires that the decisions in a module or
program be evaluated to true and false.
– Requires that each edge in the control flow graph
be traversed at least once during testing (all-edges
criterion).

Ch - 06: Coding and Testing 26

 …
 E.g. The following fragment tests the validity of input data to be
between 0 and 50.

1. int check (x)

2. {
3. if (x >= 0) && (x <= 100)
4. check = True;
5. else
6. check = False;
7. }

Ch - 06: Coding and Testing 27

 …
Here, the branch coverage criterion will be satisfied
by test cases {x = 5, x = -5} but the error is not
detected if 50 < x <= 100.
This occurs because the decision is evaluating to true
and false because of the condition x >= 0.
The condition x <= 100 never evaluates to false
during test with {x = 5, x = -5}; hence the error in this
condition is not revealed.

Ch - 06: Coding and Testing 28

 …
2. Data Flow-Based Testing
• This is testing based on data flow analysis.
• Here, besides the control flow, information about where the
variables are defined and where the definitions are used is
also used to specify the test cases.
• The basic idea behind data flow-based testing is to make sure
during testing, the definitions of variables and their
subsequent use is tested.
• Just like the all-nodes and all-edges criteria try to generate
confidence in testing by making sure that at least all
statements and all branches have been tested.
• The data flow testing tries to ensure some coverage of the
definitions and uses of variables.

Ch - 06: Coding and Testing 29

 …

• There are three types of occurrences of a variable

in a block of statements:
i. def: - represents the definition of a variable.
– The variable on the left-hand side of an
assignment statement is the one getting defined.
– Variables in input statements are of this type.

Ch - 06: Coding and Testing 30

 …
ii. c-use: -represents computational use of a variable.
 Any statement (e.g. input, output, and assignment)
that uses the value of variables for computational
purposes is said to be making c-use of the variables.
 In an assignment statement, all variables on the right-
hand side have a c-use occurrence.
 In output statements, all variable occurrences are of
this type.

Ch - 06: Coding and Testing 31

 ...
ii. p-use: - represents the use of a variable for
transferring control (represents predicate use).
• A data flow-based testing uses a definition use
(def-use) graph.
• The def-use graph is constructed by constructing a
set of variables associated with edges and nodes.

Ch - 06: Coding and Testing 32

 …
 E.g. construct a def-use graph for the following fragment
that computes xy for any integers x & y.

1. cin>>x>>y; if(y < 0)

2. pow = 0 – y;
3. else pow = y;
4. z = 1.0;
5. while (pow != 0)
6. { z = z * x; pow = pow – 1; }
7. if (y < 0)
8. z = 1.0/z;
9. cout<< z;

Ch - 06: Coding and Testing 33

 …
. Def ={x,y}
1 C-use=Φ
y
Def={pow) 2 3 def={pow}
C-use={y} C-use ={y}

Def={z}
4
C-use=Φ

Def=c-use=Φ
5
pow
pow
Def={z,pow} 7 Def=c-use=Φ
C-use={x,z,pow} 6 y y
Def={z} 8 Def=Φ
9
C-use={z} C-use={z}
Ch - 06: Coding and Testing 34
 …
• dpu:- set of branches where a variable is p-
used.
• dcu:- set of nodes where a variable is c-used.

Ch - 06: Coding and Testing 35

 From the above example
(node,var) Dcu dpu
(1,x) {6} Φ
(1,y) {2,3} {(1,2),(1,3),(7,8),(7,9)}
(2,pow) {6} {(5,6),(5,7)}
(3,pow) {6} {(5,6),(5,7)}
(4,z) {6,8,9} Φ
(6,z) {6,8,9} Φ
(6,pow) {6} {(5,6),(5,7)}
(8,z) {9} Φ

Ch - 06: Coding and Testing 36

 …
 Test case selection (for data flow-based testing):
a) Identify a path that satisfies (the chosen) a criterion.
Here the path should be feasible. Identifying feasible
path requires the programmer to use his judgment and
knowledge about the program.
b) Identify a test data that executes that path (the
identified path).

Ch - 06: Coding and Testing 37

 …
All-edges criterion (100% branch coverage):
To make sure that each edge in the graph is traversed
during testing.
(1;2;4;5;6;7;8;9), (1;3;4;5;7;9) are feasible
(1;2;4;5;6;7;9) is not feasible because 1-2 implies that y is
negative.
Test cases (x=3,y=-1) and (x=3, y=0) satisfy this criterion.

Ch - 06: Coding and Testing 38

 …
 All–defs criterion (all-use)
 Requires that for all definitions of all variables, at least one use
(c-use or p-use) must be exercised during testing.
 (1;2;4;5;6;5;6;7;8;9),(1;3;4;5;6;7;9)
 1;2;4;5;6 ensures all defs of node 1,2 and 4 have been used,
having 5;6 after this ensures that the defs in node 6 are used.
 Test cases (x=3,y=4), (x=3,y=-2) satisfy this criterion.

Ch - 06: Coding and Testing 39

 Levels of testing
 The code contains requirement defects, design defects,
and coding defects
 Nature of defects is different for different injection stages
 One type of testing will be unable to detect the different
types of defects
 Different levels of testing are used to uncover these
defects

Ch - 06: Coding and Testing 40

User needs Acceptance testing

Requirement System testing

specification

Design Integration testing

code Unit testing

Ch - 06: Coding and Testing 41

 Unit Testing
• Different modules tested separately
• Focus: defects injected during coding
• Essentially a code verification technique, covered in previous
chapter
• UT is closely associated with coding
• Frequently the programmer does UT; coding phase sometimes
called “coding and unit testing”.
• Structural testing is used mostly here.

Ch - 06: Coding and Testing 42

 Integration Testing
 Focuses on interaction of modules in a subsystem
 Unit tested modules combined to form subsystems
 Test cases to “exercise” the interaction of modules in different
ways
 May be skipped if the system is not too large
 Can be considered testing the design

Ch - 06: Coding and Testing 43

 System Testing
Entire software system is tested
Focus: does the software implement the
requirements?
Validation exercise for the system with respect to the
requirements
Generally the final testing stage before the software
is delivered
May be done by independent people
Defects removed by developers
Most time consuming test phase

Ch - 06: Coding and Testing 44

 Acceptance Testing
 Focus: Does the software satisfy user needs?
 Generally done by end users/customer in customer
environment, with real data
 Only after successful AT software is deployed
 Any defects found are removed by developers
 Acceptance test plan is based on the acceptance test criteria
in the SRS
 Mostly functional testing is performed on this level and on
system testing.

Ch - 06: Coding and Testing 45

 Deadline – Coding (with defense )
• Two days after your last final Exam!

Ch - 06: Coding and Testing 46