SOFTWARE CODING AND TESTING

UNIT NO. : 04 MARKS : 12

 INTRODUCTION - CODING
 The objective of coding phase is to transform the design
of a system into code in a high-level language, and then
to unit test this code.
 A good software development organizations require their
programmers to adhere to some well-defined and
standard style of coding which they call their coding
standard.
 The main advantages of adhering to a standard style of
coding are the following:
 A coding standard gives a uniform appearance to the
codes written by different engineers.
 It facilitates code understanding.
 It promotes good programming practices. 2
 A coding standard lists several rules to be followed
during coding such as the way variables are to be
names, the way the code is to be laid out, the error
return conventions etc.
 Coding standards have to be mandatorily followed by
programmers, and compliance to coding standard is
verified before testing phase can start.
 In contrast, coding guidelines provide some general
suggestions regarding the coding style to be followed
but leave the actual implementation of these
guidelines to the direction of the individual
developers.
3
 CODING STANDARD AND GUIDELINES
 Good software development organizations usually
develop their own coding standards and guidelines
depending on what suits their organizations best and
based on the specific types of products they develop.
 Representative coding standards

 Rules for limiting the use of global : These rules

list what type of data can be declared global and
what can not.
 Standard headers to precede the code of
different modules :
 Naming conventions for global variables, local
variables and constant identifiers:
 Global variable : GlobalData
4
 Local variable : localData

 Constant Name: CONSTDATA

 Representative Coding Guidelines
 Do not use a coding style that is too clever or
too difficult to understand.
 Do not use an identifier for multiple purposes.
 The code should be well-documented.
 The length of any function should not exceed
10 source lines.
 Do not use GO TO statements.

5
CODE REVIEW
 Code review for a module is undertaken after the
module successfully compiles.
 That is , all the syntax errors have been eliminated
form the module.
 Eliminating an error from code involves three main
activities – testing, debugging and then correcting
the errors.
 Testing is carried out to detect if the system fails to
work satisfactory for certain types of inputs and
under certain circumstances.
 Once a failure is detected, debugging is carried out to
locate the error that is causing the failure.
6
 Finally, error correction is carried out to fix the bug.
 Types of code review technique

 CODE INSPECTION

 CODE WALKTHROUGH

7
 CODE INSPECTION
 During code inspection, the code is examined for the
presence of some common programming errors.
 The principal aim of code inspection is to check for
the presence of some common types of errors that
usually creep into code due to programmer
oversights and to check whether coding standards
have been adhered to.
 Good software development companies collect
statistics regarding different types of errors
commonly committed by their engineers and
identify the types of errors most frequently
8
committed.
 Following is a list of some classical
programming errors which can be checked
during code inspection:
 Use of uninitialized variables
 Jumps into loops
 Non-terminating loops
 Incompatible assignments
 Array indices out of bounds
 Improper storage allocation and deallocation.
 Mismatches between actual and formal
parameter in procedure calls. 9

 Improper modification of loop variables.

CODE WALKTHROUGH
 Code walkthrough is an informal code analysis
technique.
 In this technique, a module is taken up for review
after the module has been coded, successfully
compiled, and all syntax errors have been eliminated.
 A few members of the development team are given the
code a couple of days before the walkthrough meeting.
 Each member selects some test cases and simulates
execution of the code by hand.
 The main objective of code walkthrough is to
discover the algorithmic and logical errors in
10
the code.
 The members note down their findings of their
walkthrough and discuss those in a walkthrough
meeting where the coder of the module is present.
 Guidelines for Code Walkthrough
techniques:
 The team performing code walkthrough should
not be either too big or too small. Ideally, it
should consists of between three to seven
members.
 Discussions should focus on discovery of errors
and avoid deliberations on how to fix the
11
discovered errors.
SOFTWARE DOCUMENTATION
 When a software product is developed, in addition to
the executable files and the source code, several kinds
of documents such as users’ manual, SRS document,
design document, test document, installation manual
etc. are developed as part of the software engineering
process.
 Good documents are very useful and serve the
following purposes.
 Good documents help enhance understandability of
a software product.
 Documents help the users to understand an
effectively use the system.
 Good documents help in effectively tackling the 12
manpower turnover problem.
 Different types of software documents can be
classified into the following:

 Internal Documentation:
 These are provided in the source code itself.

 External Documentation:
 These are the supporting documents that
usually accompany a software product.

13
INTERNAL DOCUMENTATION
 Internal documentation is provided in the source
code itself.
 Internal documentation can be provided in the
code in several forms.
 The important types of internal documentation are
the following:
 Comments embedded in the source code.
 Use of meaningful variable names,
 Module and function headers.
 Code structuring.
 Use of enumerated types.
 Use of CONSTANT identifiers. 14
EXTERNAL DOCUMENTATION

 External documentation is provided through various

types of supporting documents such as users’ manual,
SRS document, design document, test document etc.
 An important features of good external
documentation is consistency with the code.
 If the different documents are not consistent, a lot of
confusion is created for somebody trying to
understand the product.
 In other words, all the documents developed for
product should be up-to-date and every change made
to the code should be reflected in the relevant
external documents.
15
TESTING
 The aim of program testing is to identify all defects in
a program.
 However, in practice, even after satisfactory
completion of the testing phase, it is not possible to
guarantee that a program is error free.
 Terminologies of Testing

 Error : An error is a mistake committed by the

development team during any of the development
phases.
 Failure : A failure is the symptom of an error.
 Test Case: A test case is the triplet[I,S,O], where I
is the data input to the system, S is the state of the
system at which the data is input, and O is the
16
expected output of the system.
 Test Suite : A test suite is the set of all cases with
 Validation Vs Verification
 Verification : Verification is the process of
determining whether the output of one phase of
software development conforms to that of its
previous phase.
 Validation: Validation is the process of
determining whether a fully developed system
conforms to its requirement specification.
 Testing Activities:

 Test suite design

 Running test cases and checking the results to
detect failures
17
 Debugging
 Error correction
TESTING PROCESS

18
TESTING METHODS
 There are two main approaches to design test
cases:
 Black-box Approach

 In the black-box approach, test cases are

designed using only the functional
specification of the software.
 That is, test cases are designed solely based on
an analysis of the input/output behavior and
does not require any knowledge of the internal
structure of a program.
 For this reason, black-box testing is also
19
known as functional testing.
 White-box Approach
 In the white-box approach, designing white-
box test cases requires a knowledge of the
internal structure of a program, and therefore
white-box testing is also called as structural
testing.
 In white-box approach, test cases are based on
an analysis of the code.

20
BLACK-BOX TESTING
 In black-box testing, test cases are designed from
an examination of the input/output values only
and no knowledge of design or code is required.
 The following are the two main approaches
available to design black-box test cases.
 Equivalence Class Partitioning
 Boundary Value Analysis

21
EQUIVALENCE CLASS PARTITIONING
 In the equivalence class partitioning approach,
domain of input values to the program under
test is partitioned into a set of equivalence
classes.
 The partitioning is done such that for every
input data belonging to the same equivalence
class, the program behaves similarly.
 Equivalence classes for a program can be
designed by examining the input data and
output data.

22
 The following two general guidelines for designing the
equivalence classes.
1. If the input data values to a system can be specified
by a range of values, then one valid and two invalid
equivalence classes need to be defined. For example,
if the equivalence class is the set of integers in the
range 1 to 10, then the invalid equivalence classes
are [-∞,0],[11,+∞].
2. If the input data assumes values from a set of
discrete members of some domain, then one
equivalence class for the valid input values and
another equivalence for the invalid input values
should be defined. For example, if the valid
equivalence classes are {A,B,C}, then the invalid class
23
is U-{A,B,C}, where U is the universe of possible
input values.
 Example, for a software that computes the
square root of an input integer that can
assume values in the range of 0 to 5000.
Determine the equivalence class test suite.

 There are three equivalence classes- the set of

negative integers, the set of integers in the range
of 0 and 5000, and the set of integers larger than
5000.
 Therefore, the test cases must include
representatives for each of the three equivalence
classes.
24
 So, a possible test suite can be {-5,500,6000}.
BOUNDARY VALUE ANALYSIS
 A type of programming error that is frequently
committed by programmers is missing out on the
special consideration that should be given to the
values at the boundaries of different equivalence
classes of inputs.
 The reason behind programmers committing such
errors might purely be due to psychological factors.
 Programmers often fail to properly address the special
processing required by the input values that lie at the
boundary of the different equivalence classes.
 For example, programmers may improperly use <
25
instead of <= etc.
 Boundary value analysis-based test suite design
involves designing test cases using the values at
the boundaries of different equivalence classes.
 For an equivalence class that is a range of values,
the boundary values need to be included in the
test suite.
 For example, if an equivalence class contain the
integers in the range 1 to 10, then the boundary
value test suite is {0,1,10,11}.

26
WHITE-BOX TESTING
 White-box testing is an important type of unit
testing.
 A large number of white-box testing strategies
exist.
 Each testing strategy essentially designs test case
based on analysis of some aspect of source code and
is based on some heuristic.
 A white-box testing strategy can either be
coverage-based or fault-based.
 Fault-based testing
 A fault-based testing strategy targets to detect certain 27
types of faults.
 Coverage-based testing
 A coverage-based testing strategy attempts to
execute certain elements of a program.
 Popular examples of coverage-base testing
strategies are statement coverage, branch
coverage and path coverage-based testing.

28
 Statement Coverage:
 The statement coverage-based strategy aims to design test cases
so as to execute every statement in a program at least once.
 It is obvious that without executing a statement, it is difficult to
determine whether it leads to a failure due to some illegal
memory access, wrong result computation due to improper
arithmetic operation, etc.
 Example: Design statement coverage-based test suite for the
following Euclid’s GCD computation program.
int computeGCD(int x,int y)
{
while(x!=y)
{
if(x>y) then
x=x-y;
else
y=y-x;
} 29

}
 To design the test cases for the statement
coverage, the conditional expression of the while
statement needs to be made true and the
conditional expression of the if statement needs
to be made both true and false.
 By choosing the test set { (x=3, y=3) , (x=4, y=3) ,
(x=3, y=4) } all statements of the program would
be executed at least once.

30
 Branch Coverage:
 Branch coverage-based testing requires test cases to
be designed so as to make each branch condition in
the program to assume true and false values in turn.
 Branch testing is also known as edge testing, since in
this testing scheme, each edge of a program’s control
flow is traversed at least once.
 For previous example, the test cases for branch
coverage can be {(x=3, y=3) , (x=3, y=2) , (x=4, y=3) ,
(x=3, y=4) }.
 Branch coverage-based testing is a stronger testing
than statement coverage-based testing.
31
 Path Coverage:
 Path coverage-based testing strategy requires designing
test cases such that all linearly independent paths in the
program are executed at least once.
 A linearly independent path can be defined in terms of the
control flow graph(CFG) of a program.
 A control flow graph describes how the control flows
through the program.
 In order to draw the flow graph of a program, we need to
first number all the statements of a program.
 The different numbered statements serve as nodes of the
control flow graph.
 There exists an edge from one node to another, if the
execution of the statement representing the first node can
32

result in the transfer of control to the other node.

 Example:
 Sequence:
1. a=5;
2. b = a*2 -1

 Selection:
1. if(a>b)
2. c=3;
3. else c=5;
4. c=c*c;

33
 Iteration:
1. while(a>b) {
2. b=b-1;
3. b=b*a;}
4. c=a+b ;

34