se software coding and testing 150407
DESCRIPTION
Software Coding and Testing 4th Unit, Fundamentals of Software Development, Diploma in Computer/IT Engineering, Gujarat Technological University, Gujarat, IndiaTRANSCRIPT
Software Coding and Testing
by:Bharat V. Chawda
Computer Engineering Department,BBIT, VVNagar
Overview Introduction Code Review Software Documentation Testing Test Documentation
(As per GTU Curriculum – Diploma in Computer/IT Engineering)
Based on Books:1. Fundamentals of Software Engineering – by Rajib Mall2. Software Engineering: A Practitioner’s Approach – by Roger
Pressman
Introduction: Coding When?
After: Design phase is complete, and Design docs are successfully reviewed
Objective Design of System Code in high-level
lang Unit test this code
Coding Standards Coding Guidelines
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
Testing: Detects failures only: diff i/p, circumstances Requires efforts: Debugging – locate errors;
Error Correction – fix the bug CR: Two Types
Code Walkthrough, Code Inspection
Code Walkthrough Informal code analysis technique When to review?
After: Module is Coded, Compiled, and Syntax Errors are eliminated
How? Few members of dev 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 WT
meeting
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
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
Code Inspection (cont) Objective:
Check for the common types of errors Check whether coding standard have
been adhered to
SW companies can maintain list of commonly committed error check list for code inspection
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 4 maintenance
Help users to und & effectively use the system
Help in effectively tackling manpower turnover
Help manager to effectively track progress
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
SW: External Documentation Contains various types of supportive
docs Users’ manual SRS doc Design doc Test doc Installation manual…
Features: Good external documentation
Consistency Understandability
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…
Unit Testing When?
After: Module has been coded and reviewed
How? Design test cases Develop Environment Do testing
Environment Driver + Module + Stub
(Stub: Dummy procedures with simplified behavior)(Driver: Non-local data str + Code to call fun of
module)
Driver
Stub
Module under Test
Global Data
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
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}
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
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
White Box T: Example
int test (int x, int y)
{ int z;
z = -1;
if (x>0 && y>0)
z = x;
return z;
}
Statement Coverage:
{(x=1,y=1)}
Branch Coverage:
{(1,1), (0,0)}
Condition Coverage:
{(0,0), (0,1), (1,0), (1,1)}
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
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;
}
White Box T: Path Coverage Example:
int gcd (int x, int y){
1. while (x!=y) {
2. if (x>y)3.
x=x-y;else
4. y=y-x;
5. }6. return x;
}
CFG:
1
2
3 4
5
6
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
Cyclomatic Complexity of previous example of GCD: 3
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
