ISE: Unit 4

Software
Coding and Testing

1
 Overview
• Introduction
• Code Review
• Software Documentation
• Testing
• Test Documentation

2
 Introduction: Coding
• When?
– After:
• Design phase is complete, and
• Design documents are successfully reviewed
• Objective
– To Transform the Design of System into Code
in high-level language and Unit testing of this
code
• Coding Standards
• Coding Guidelines
3
 Coding Standards
• Good SW development organisations require
their programmers to follow their coding
standards: Well defined and Standard style
of Coding
• Advantages:
1. A uniform appearance to the code written by
diff. engineers
2. Easy to Understand code & code reuse
3. It promotes good programming practice.

4
 Coding Guidelines
• Code should be well documented
• Length of any function should not exceed 10
source lines
• Do not use Go To statements
• Do not use coding style that is too clever or too
difficult to understand.

5
 Code Review
• When?
– After: Module successfully compiles
– All the syntax errors have been eliminated
• Code review v/s Testing
– Code Review:
• Cost-effective strategy for error elimination
• Direct detects errors from source code
– Testing:
• Detects failures only: different i/p, circumstances
• Requires efforts: Debugging – locate errors;
Error Correction – fix the bug
• Code Review: Two Types
• Code Walkthrough
• Code Inspection
6
 Code Walkthrough
• Informal code analysis technique
• When to review?
– After: Module is Coded, Compiled, and Syntax Errors are
eliminated
• How?
– Few members of development team are assigned this task
– Each member selects some test cases
– Simulate execution of code by hand
– (Trace execution through different Statements and
Instructions of the code)
– Note down findings;
– Discuss with coder in the meeting.
7
 Code Walkthrough (cont)
• Objective
– Discover the algorithmic and logical errors in
the code
• Guidelines
– Team size: Not too big, not too small: 3-7
member
– Focus on discovery of errors, not on how to fix
them
– Managers should not attend WT meeting – To
avoid feeling: engineers are being evaluated
8
 Code Inspection
• Code is examined for the presence of some
common/classical programming errors
– Use of uninitialized variables
– Incompatible assignments
– Non terminating loops
– Jumps into loops
– Improper modification of loop variables
– Mismatch in arguments in procedure (fun) calls
– Array indices out of bounds
– Improper storage allocation and de-allocation
– Use of incorrect logical operators; Precedence
– Comparison of equality of floating point values
9
 Code Inspection (cont)
• Objective:
– Check for the common types of errors
– Check whether coding standard have been
adhered to
• Good Software development companies
can maintain list of commonly committed
errors  check list for code inspection

10
 Software Documentation
• SW Product
– Executable files + Source Code + Documents
– Documents: Users’ manual, SRS doc, Design doc,
Test doc, Installation manual, etc
• Why required?
– Enhances understandability of SW product
– Reduces effort & time required for maintenance
– Help users to understand & effectively use the
system
– Help in effectively tackling manpower turnover
– Help manager to effectively track progress
11
Software Documentation
Two categories

1) Internal Documentation :
These are provided in the source code itself.

2) External Documentation:
Supporting documents such as SRS Document,
Installation Document, User Manual, Design
Document and Test Document

12
SW: Internal Documentation
• Code comprehension features: provided in
the source code itself
– Comments embedded in the source code
– Use of meaningful variable names
– Module and function headers
– Code indentation
– Code structuring (modules + functions)
– Use of constant identifiers
– Use of enumerated types
– Use of user-defined data types
13
SW: External Documentation
• Contains various types of supportive
documents
– Users’ manual
– SRS doc
– Design doc
– Test doc
– Installation manual…
• Features: Good external documentation
– Consistency
– Understandability
14
 Testing: Introduction
• Testing:
– Aim: Identify all defects in a program
• Error / Defect / Bug / Fault:
– Mistake committed by development team
during any of the development phases.
• Failure:
– Manifestation of an error
– Symptom of an error
• Test case: Triplet [I, S, O]: I/P, State, O/P
• Test suite: Set of all test cases…
15
 Testing: Levels/Stages
• Unit Testing
• Integration Testing
• System Testing

16
 Unit Testing
• When?
– After: Module has been coded and reviewed
• How?
– Design test cases
Driver
– Develop Environment Global
Data
– Do testing
Module under Test
• Environment
– Driver + Module + Stub
Stub
(Stub: Dummy procedures with simplified behavior)
(Driver: Non-local data str + Code to call fun of module)

17
 Black Box Testing
• Concept
– Based on functional specification of SW
– Based on functional behavior: Inputs/Outputs
– Also known as: Functional Testing
– No knowledge of design & code is required
• Two main approaches
– Equivalence Class Partitioning
– Boundary Value Analysis

18
 Black Box Testing: Example
• SW: Computes square root of integer
values in the range of 0 and 5000.
– Test Cases: Equivalence Class Partitioning
• {-5, 500, 6000}
– Test Cases: Boundary Value Analysis
• {-1, 0, 5000, 5001}

19
 White Box Testing
• Concept
– Based on analysis of code
– Based on structure of the implementation
– Also known as: Structural Testing
– Knowledge of design & code is required
• Two Types
– Fault based: Targets: detect certain types of F
– Coverage based: Targets: execute (cover)
certain elements of a program
20
White Box T: Coverage based
• Strategies
– Statement Coverage
• Each statement should be executed at least once
– Branch Coverage
• Each branch : traversed at least once
– Condition Coverage
• Each condition : True at least once and false at least
once
– Path Coverage
• Each linearly independent path : executed at least
once
21
 White Box T: Example
int test (int x, int y) Statement Coverage:

{ int z; {(x=1,y=1)}
z = -1;
Branch Coverage:
if (x>0 && y>0) {(1,1), (0,0)}
z = x;
Condition Coverage:
return z;
{(0,0), (0,1), (1,0), (1,1)}
}

22
 White Box T: Path Coverage
• Concept
– All linearly independent paths in the program
are executed at least once
• CFG: Control Flow Graph
– Directed graph – consisting of a set of Nodes
(N) and Edges (E) where
– Nodes (N): corresponds to a unique program
statement
– Edges (E): Transfer of control From one node
to another node
23
 White Box T: Path Coverage
• Example:
int gcd (int x, int y)
{
while (x!=y)
{
if (x>y)
x=x-y;
else
y=y-x;
}
return x;
}

24
 White Box T: Path Coverage
• Example:  CFG:
int gcd (int x, int y)
{ 1
1. while (x!=y)
{ 2
2. if (x>y)
3. x=x-y; 3 4
else
4. y=y-x; 5
5. }
6. return x;
} 6

25
Cyclomatic Complexity Metric
• V(G) = E – N + 2
• V(G) = Total number of non-overlapping
bounded areas + 1
• V(G) = Total number of non-overlapping
areas
• V(G) = Decision Points + 1
• V(G) = Predicate Nodes + 1

26
 Test Documentation
• When: Towards end of testing
• Represents: Test summary report
• Specifies:
– Total number of tests: applied to a sub-system
– How many tests were successful
– How many tests were unsuccessful; and at
which extent (degree): totally or partially

27