[go: up one dir, main page]
Scribd
Upload
89 views12 pages

Static and Dynamic Verification: - Software Inspections

This document discusses static and dynamic verification of software. Static verification involves analyzing the system representation without executing code, such as through inspections and static analysis tools. Dynamic verification involves executing the system with test data and observing behavior. Both are important and complementary approaches. Static analysis tools can check for errors but inspections involving human reviewers are still very effective at finding defects. Planning verification and validation activities carefully is important to make the most of inspections and testing.

Uploaded by

Saagar Minocha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
89 views12 pages

Static and Dynamic Verification: - Software Inspections

This document discusses static and dynamic verification of software. Static verification involves analyzing the system representation without executing code, such as through inspections and static analysis tools. Dynamic verification involves executing the system with test data and observing behavior. Both are important and complementary approaches. Static analysis tools can check for errors but inspections involving human reviewers are still very effective at finding defects. Planning verification and validation activities carefully is important to make the most of inspections and testing.

Uploaded by

Saagar Minocha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Static and dynamic verification

Software inspections

Concerned with analysis of the static system


representation to discover problems (static
verification)
May be supplement by tool-based document and
code analysis

Software testing

Concerned with exercising and observing


product behaviour (dynamic verification)
The system is executed with test data and its
operational behaviour is observed

Static and dynamic V&V


Static
verification

Requirements
specification

Prototype

High-level
design

Formal
specification

Detailed
design

Program

Dynamic
validation

V& V goals

Verification and validation should establish


confidence that the software is fit for
purpose
This does NOT mean completely free of
defects
Rather, it must be good enough for its
intended use and the type of use will
determine the degree of confidence that is
needed

V & V confidence

Depends on systems purpose, user


expectations and marketing environment
Software function

The level of confidence depends on how critical the


software is to an organization

User expectations

Users may have low expectations of certain kinds of


software

Marketing environment

Getting a product to market early may be more


important than finding defects in the program

V & V planning
Careful planning is required to get the most
out of testing and inspection processes
Planning should start early in the
development process
The plan should identify the balance
between static verification and testing
Test planning is about defining standards
for the testing process rather than
describing product tests

Software inspections

Involve people examining the source


representation with the aim of discovering
anomalies and defects
Do not require execution of a system so
may be used before implementation
May be applied to any representation of
the system (requirements, design, test
data, etc.)
Very effective technique for discovering
errors

Inspection success

Many different defects may be


discovered in a single inspection
In testing, one defect may mask another
so several executions are required

The reuse domain and programming


knowledge
reviewers are likely to have seen the
types of error that commonly arise

Inspections and testing

Inspections and testing are complementary


and not opposing verification techniques
Both should be used during the V & V
process
Inspections can check conformance with a
specification but not conformance with the
customers real requirements
Inspections cannot check characteristics
such as performance, usability, etc.

Program inspections
Formalized approach to document reviews
Intended explicitly for defect
DETECTION (not correction)
Defects may be logical errors, anomalies in
the code that might indicate an erroneous
condition (e.g. an uninitialized variable) or
non-compliance with standards

Inspection pre-conditions

10

A precise specification must be available


Team members must be familiar with the
organization standards
Syntactically correct code must be available
An error checklist should be prepared
Management must accept that inspection will
increase costs early in the software process
Management must not use inspections for staff
appraisal

11

The inspection process

Planning
Overview

Follow-up
Individual
preparation

Rework
Inspection
meeting

12

Inspection procedure
System overview presented to inspection
team
Code and associated documents are
distributed to inspection team in advance
Inspection takes place and discovered
errors are noted
Modifications are made to repair
discovered errors
Re-inspection may or may not be required

13

Inspection teams
Made up of at least 4 members
Author of the code being inspected
Inspector who finds errors,
omissions and inconsistencies
Reader who reads the code to the
team
Moderator who chairs the meeting
and notes discovered errors

14

Inspection checklists
Checklist of common errors should be used
to drive the inspection
Error checklist is programming language
dependent
The 'weaker' the type checking, the larger
the checklist
Examples: Initialization, loop termination,
array bounds, etc.

Inspection checks
Fault class
Data faults

Inspection check
Are all program variables initialised before their values
are u sed?
Have all co nstan ts been named?
Should the lower bound of arrays be 0, 1, or somethin g
else?
Should the upper bound of arrays be equal to the size of
the a rray or Size -1?
If character strin gs are used, is a delimiter exp licitly
as signed?
Control faults
For each conditional statement, is the condition correct?
Is each loop certain to terminate?
Are compound s tatements correctly bracketed?
In case s tatements, are all possible cases accounted for?
Input/output faults
Are all input variables used?
Fault class
Inspection
check
Are
all output
variables assigned a value before they are
Data faults
Are all program variables initialised before their values
output?
are uall
sed?
Interface faults
Do
function and proced ure calls have the correct
Have allofcoparameters?
nstan ts been named?
number
Should
theand
lower
bound
of arrays
be 0,match?
1, or somethin g
Do
formal
actual
p arameter
types
else?the parameters in the right order?
Are
Should
the upper
bound
of arrays
be equal
to the
size the
of
If
components
access
shared
memory,
do they
have
the a rray
orlSize
same
mode
of the-1?
shared memory s tructure?
If acharacter
strin
gs are
used, is, a delimiter
exp licitly
Storage management If
linked s tru
cture
is modified
have all links
been
as signed?reassigned?
faults
correctly
Control faults
For
conditional
the condition
correct?
If
dyeach
namic
storage isstatement,
u sed, has is
space
been allocated
Is each loop certain to terminate?
correctly?
Are
compound
s tatements
correctly
Is
s pace
explicitly
d e-allocated
after bracketed?
it
is no longer
In case s tatements, are all possible cases accounted for?
required?
Input/output faults
Are allallinput
variables
used? ns been taken
Exception
Have
possible
error conditio
into
Are all output variables assigned a value before they are
management fau lts
account?
output?
Interface faults
Do all function and proced ure calls have the correct
number of parameters?
Do formal and actual p arameter types match?
Are the parameters in the right order?
If components access shared memory, do they have the
same mode l of the shared memory s tructure?
Storage management If a linked s tru cture is modified , have all links been
faults
correctly reassigned?
If dy namic storage is u sed, has space been allocated
correctly?
Is s pace explicitly d e-allocated after it
is no longer
required?
Exception
Have all possible error conditio ns been taken
into
management fau lts
account?

Inspection checks

17

Inspection rate
500 statements/hour during overview
125 source statement/hour during
individual preparation
90-125 statements/hour can be inspected
Inspection is therefore an expensive
process
Inspecting 500 lines costs about 40 man/
hours
effort = $$

18

Automated static analysis


Static analysers are software tools for
source text processing
They parse the program text and try to
discover potentially erroneous conditions
and bring these to the attention of the V &
V team
Very effective as an aid to inspections. A
supplement to but not a replacement for
inspections

19

Static analysis checks


Fault class
Data faults

Static analysis check


Variables used before initialis ation
Variables declared but never used
Variables as signe d twice b ut never used
between assignments
Possible array bound violations
Undeclared variables
Co ntrol faults
Unreachable code
Unconditional branches into loops
Input/output faults
Variables output twice with no intervenin g
as signment
Interface faults
Parameter type mismatches
Parameter n umb er mismatches
Non-us age of the results of function s
Uncalled functions and procedures
Storage
management Unassigned pointers
faults
Pointer arithmetic

20

Stages of static analysis


Control flow analysis. Checks for loops with
multiple exit or entry points, finds unreachable
code, etc.
Data use analysis. Detects uninitialized
variables, variables written twice without an
intervening assignment, variables which are
declared but never used, etc.
Interface analysis. Checks the consistency of
routine and procedure declarations and their
use

10

21

Stages of static analysis


Information flow analysis. Identifies the
dependencies of output variables. Does not
detect anomalies itself but highlights
information for code inspection or review
Path analysis. Identifies paths through the
program and sets out the statements
executed in that path. Again, potentially
useful in the review process
Both these stages generate vast amounts
of information. Must be used with care.

138% more lint_ex.c!


"
#include <stdio.h>"
printarray (Anarray)"
int Anarray;"
{"
printf(%d,Anarray);"
}"
main ()"
{"
int Anarray[5]; int i; char c;"
printarray (Anarray, i, c);"
printarray (Anarray) ;"
}"
"
139% cc lint_ex.c!
140% lint lint_ex.c!
!
lint_ex.c(10): warning: c may be used before set"
lint_ex.c(10): warning: i may be used before set"
printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10)"
printarray, arg. 1 used inconsistently lint_ex.c(4) ::
lint_ex.c(10)"
printarray, arg. 1 used inconsistently lint_ex.c(4) ::
lint_ex.c(11)"
printf returns value which is always ignored "
"

LINT static analysis

11

Use of static analysis

23

Particularly valuable when a language


such as C is used which has weak
typing and hence many errors are
undetected by the compiler
Less cost-effective for languages like
Java that have strong type checking
and can therefore detect many errors
during compilation

12

You might also like