V&V V&V V&V V&V

The whole picture

Integrate
units
Design
.
Requirements
engineering
Requirement
document
Design
document
Unit
Unit
System
Implement
unit
Implement
unit
VV system
VV
design
VV requirements
VV unit
VV unit
Requirement
document
Design
document
Unit
Unit
System
Project management
on!iguration management
"uality management
V&V
Validation
is it the right so!tware system#
e!!ecti$eness
e%ternal &$s user'
relia(ility
Veri!ication
is the so!tware system right#
e!!iciency
internal &$ertical trans!ormation o! documents is done correctly'
correctness
V & V
$alidation
sta)eholders
Design
document
Requirement
document
Unit
Unit
System
$eri!ication
V & V $s. cost o! !i%ing de!ect
Design
document
Requirement
document
Unit
Unit
System
ost o! !i%ing
de!ect
*ailure+ !ault+ de!ect
*ailure
,n e%ecution e$ent where the so!tware (eha$es
in an une%pected way
*ault
The !eature o! so!tware that causes a !ailure
-ay (e due to.
/ ,n error in so!tware
/ Incomplete0incorrect requirements
De!ect
*ailure or !ault
*ailure !ault de!ect
Fault Failure
causes
1, *
0,*
Defect
Insertion 0 remo$al
De!ect is characteri1ed (y
Insertion acti$ity &phase'
Remo$al acti$ity &phase'
time
remo$al
insertion disco$er
2asic goal o! VV
-inimi1e num(er o! de!ects inserted
annot (e 1ero due to inherent
comple%ity o! so!tware
-a%imi1e num(er o! de!ects
disco$ered and remo$ed
-inimi1e time span (etween insertion
and disco$er and remo$al
Insertion0remo$al (y phase /
typical scenario
0
2
4
6
8
10
12
14
16
Defects/KLOC
Requirements Design Code Unit test Integration
test
System test Operation
Injected
Discovered
Rewor) Pro(lem
The longer the delay insert3remo$e+ the higher the cost o!
remo$ing de!ect
,$oida(le rewor) accounts !or 453657 o! de$elopment
82oehm+ 9:;<= 2oehm&2asili+ >559?
-ore recent data a$aila(le at www.ce(ase.org
6%
12%
16%
12%
10%
19%
12%
8%
1%
4%
Reqmts Prelim.
Design
Detailed
Design
Code &
Unit Test
Integration
& System
Test
Rework
V&V techniques
Static
inspections
source code analysis
Dynamic
testing
Inspections
Inspections
Static
inspections
source code analysis
Dynamic
testing
Inspections
Integrate
units
Design
.
Requirements
engineering
Requirement
document
Design
document
Unit
Unit
System
Implement
unit
Implement
unit
VV system
VV
design
VV requirements
VV unit
VV unit
Requirement
document
Design
document
Unit
Unit
System
Project management
on!iguration management
"uality assurance
Inspection
onsists in
reading documents0code
2y a group o! people &@A+ group
dynamics'
Bith goal o! !inding de!ects &no
correction'
Variants o! inspections
/ Reading techniques+ wal)throughs+ re$iews
an !ind many de!ects
/ Test concentrates one de!ect at a time
Inspection
,d$antages
an (e applied to documents
/ Requirements+ design+ test cases+ ..
an (e applied to code
/ Does not require e%ecution en$ironment
Is $ery e!!ecti$e
/ Reuses e%perience and )now o! people on domain and
technologies
/ Cas more glo(al $iew &$s test. one de!ect at a time'
/ Uses group dynamics
Dimits
-ore suita(le !or !unctional aspects
Requires time &e!!ort and calendar time'
2ene!its
Early de!ect detection impro$es product quality and
reduces a$oida(le rewor) &down to 953>57'
Data !rom industry a$erages 8apers Fones+ 9::9?
/ more data a$aila(le at www.ce(ase.org
Requirements Insp.
Design Insp.
Code Insp.
Unit Test Insp.
Integration Test Insp.
System Test Insp.
5 (20)
8 (40)
15 (100)
7 (50)
3 (20)
1 (10)
Defects per KLOC passed
without inspection
Defects per KLOC passed
with inspection
Rework Costs
Inspection $s. testing
omplementary techniques
2oth should (e used in V and V
Roles in group
-oderator.
/Deads inspection process and nota(ly inspection
meeting
/ Selects participants+ prepares material
/ Usually not !rom project that produces document to (e
inspected
Readers.
/Read document to (e inspected
,uthor
/,nswers to questions that arise
Scri(e
/Brites inspection log
*agan Inspection Process
Select team+ arrange materials+ schedule
dates
Present process+ product
2ecome !amiliar with the product 2ecome !amiliar with the product 2ecome !amiliar with the product 2ecome !amiliar with the product
Team analysis to !ind de!ects Team analysis to !ind de!ects Team analysis to !ind de!ects Team analysis to !ind de!ects
orrect de!ects
Veri!y !i%es+ collect data
Planning
Overview
Preparation
Inspection Meeting
Rework
Follow-Up
Preparation
Preparation
Inspectors are
often unprepared.
How to make
visible the
quality of
preparation?
Process
G$er$iew
/ "uic)ly present inspection to group goals and
document to (e inspected
Preparation
/ Read indi$idually &applying inspection technique'
-eeting
/ Hroup reads+ discusses issues+ agrees on
pro(lems. Scri(e logs pro(lems. -oderator )eeps
!ocus+ )eeps pace+ stops &long' discussions
Rewor)
/ ,uthor !i%es de!ects0pro(lems
*ollow up
/ Repeat inspection or close and pass to ne%t phase
Prerequisites !or success!ul inspections
ommitment !rom management
E!!ort in$ested up!ront+ that Idoes not produce
anythingJ
*ind de!ects+ not !i% them
Document under inspection meets quality
standards
Results not used to e$aluate people &and nota(ly
author'
onstructi$e approach
Hroup aims to produce (est possi(le document
/ Ko I)ill the authorJ game
/ Ko Irela% and chatJ meetings
Rates &code inspections'
655 DG0hour &o$er$iew'
9>6 DG0hour &preparation'
:539>6 DG0hour &meeting'
E%. 655 DGs+ 4 people+ 45 person hours
/G$er$iew 9hr L 4M 4person hours
/Preparation 4hr L 4 M 9N person hours
/-eeting 6hr L 4 M >5 person hours
Techniques
Depend on document to (e inspected
,d hoc &code+ requirements+ design'
/ Fust read it
hec)list &code+ requirements+ design'
/ "uestions0controls to (e applied
De!ect ta%onomy &code+ requirements+ design'
/ ategories o! common de!ects
ode
/ ,uthor or reader Oe%ecutesP code
/ Reader reconstructs goal o! code !rom code
/ Reader de!ines and applies some test cases
Requirements
/ Scenario (ased reading
/ De!ect (ased
/ Perspecti$e (ased
De!ect Ta%onomies !or Requirements
Gne le$el
82asili et al.+ 9::N?
Gmission
Incorrect *act
Inconsistency
,m(iguity
E%traneous
In!ormation
Two le$els
8Porter et al.+ 9::6?
Gmission
-issing *unctionality
-issing Per!ormance
-issing En$ironment
-issing Inter!ace
ommission
,m(iguous In!ormation
Inconsistent In!ormation
Incorrect or E%tra
*unctionality
Brong Section
hec)lists !or Requirements
2ased on past de!ect in!ormation
"uestions re!ine a de!ect ta%onomy
8,c)erman et al.+ 9:;:?
ompleteness
9. ,re all sources o! input identi!ied#
Q
9>. *or each type o! run+ is an output $alue speci!ied !or each
input $alue#
...
,m(iguity
9;. ,re all special terms clearly de!ined#
...
onsistency
Q
hec)lists !or code
Depends on programming language
Depends on pre$ious results o!
inspections
Inspection
chec)s
Fault class Inspection check
Data faults Are all program variables initialised before their values
are used?
Have all constants been named?
Should the lower bound of arrays be 0, 1, or something
else?
Should the upper bound of arrays be equal to the size of
the array or Size -1?
If character strings are used, is a delimiter explicitly
assigned?
Control faults For each conditional statement, is the condition correct?
Is each loop certain to terminate?
Are compound statements correctly bracketed?
In case statements, are all possible cases accounted for?
Input/output faults Are all input variables used?
Are all output variables assigned a value before they are
output?
Interface faults Do all function and procedure calls have the correct
number of parameters?
Do formal and actual parameter types match?
Are the parameters in the right order?
If components access shared memory, do they have the
same model of the shared memory structure?
Storage management
faults
If a linked structure is modified, have all links been
correctly reassigned?
If dynamic storage is used, has space been allocated
correctly?
Is space explicitly de-allocated after it is no longer
required?
Exception
management faults
Have all possible error conditions been taken into
account?
Scenario (ased reading
,s) inspectors to create an appropriate
a(straction
/ Celp to understand the product
,s) inspectors to answer a series o!
questions tailored to the a(straction
Inspectors !ollow di!!erent scenarios each
!ocusing on speci!ic issues
De!ect32ased Reading
8Porter et al.+ 9::6?
, scenario3(ased reading technique to detect
de!ects in requirements e%pressed in a !ormal
notation &SR'
Each scenario !ocuses on a speci!ic class o! de!ects
data type inconsistencies
incorrect !unctionality
am(iguity0missing !unctionality
E%cerpt !rom incorrect !unctionality scenario
9. *or each !unctional requirement identi!y all input0output data o(jects.
questions ...
>. *or each !unctional requirement identi!y all speci!ied system e$ents.
&a' Is the speci!ication o! these e$ents consistent with their intended
interpretation#
@. De$elop an in$ariant !or each system mode.
questions ...
Perspecti$e32ased Reading
82asili et al.+ 9::N?
, scenario3(ased reading technique to detect de!ects in
requirements e%pressed in natural language
e%tended later !or design and source code
Each scenario !ocuses on re$iewing the document !rom the
point o! $iew o! a speci!ic sta)eholder
User &a(straction required. user tas)s descriptions'
Designer &a(straction required. design'
Tester &a(straction required. test suite'
*or each requirement0!unctional speci!ication+ generate a test or set
o! tests that allow you to ensure that an implementation o! the
system satis!ies the requirement0!unctional speci!ication. Use your
standard test approach and technique+ and incorporate test criteria in
the test suite. In doing so+ as) yoursel! the !ollowing questions !or
each test.
questions ...
Testing
Static
inspections
source code analysis
Dynamic
testing
Testing
Dynamic technique+ requires
e%ecution o! e%ecuta(le system or
e%ecuta(le unit
system test
unit test
Purpose o! test
The purpose o! testing process is to
!ind de!ects in the so!tware products
, test is success!ul i! it re$eals a de!ect
The process o! operating a system or
component under speci!ied conditions
o(ser$ing or recording the results to
detect the di!!erences (etween actual
and required (eha$ior
De!ect testing and de(ugging are
di!!erent acti$ities
-ay (e per!ormed (y di!!erent roles in
di!!erent times
Testing Testing Testing Testing tries to !ind !ailures !ailures !ailures !ailures
De(ugging De(ugging De(ugging De(ugging searches !or and remo$es
the !ault !ault !ault !ault
Testing $s. de(ugging
De(ugging
Locate fault
Test case result
&!ailure'
Design fault
repair
Repair
(code)
Re-test
Test suite
Design
doc
Test case
ertain stimulus applied to e%ecuta(le
&system or unit'+ composed o!
name
input &or sequence o!'
e%pected output
Bith de!ined constraints0conte%t
e%. $ersion and type o! GS+ D2-S+ HUI ..
Test suite
Set o! &related' test cases
Test case log
Test case A
Time and date o! application
,ctual output
Result &pass 0 no pass'
E%.
*unction Plus&%+y'
Test case.
T9&9+9= >'
T>&@+6= ;'
Test suite
TS9RT9+ T>S
Test log
T9+ 9N3@3>55: :.@9+ result >+ success
T>+ 9N3@3>55: :.@>+ result :+ !ail
Test acti$ities
Brite test cases
Test case+ test suite
Run test case &test suite'
Record results
Test case log
Test acti$ities
Write tests
Requirement doc+
design doc
Run tests Record results
Test case+
test suite
Test log
code
Possi(le scenario
Write tests
Run tests
Record results
Write code,
informally test
Debug
De$eloper team Tester team
Scenario >
Write tests
Run tests
Record results
Write code
Debug
De$eloper team
Scenario @
Write tests
Run tests
Record results
Write code,
informally test
Debug
De$eloper team
Tester team
Write tests
Run tests
Record results
Tester team
&@
rd
party'
Gracle
Test Case
Software
under test
Oracle
Comparator
Actual
output
Expected
output
Test
result
Gracle
The ideal condition would (e to ha$e
an automatic oracle and an automatic
comparator
The !ormer is $ery di!!icult to ha$e
The latter is a$aila(le only in some cases
, human oracle is su(ject to errors
The oracle is (ased on the program
speci!ications &which can (e wrong'
Gracle
Kecessary condition to per!orm testing.
Tnow the e%pected (eha$ior o! a program !or a
gi$en test case &oracle'
Cuman oracle
2ased on req. speci!ication or judgment
,utomatic oracle
Henerated !rom &!ormal' req. speci!ication
Same so!tware de$eloped (y others
Pre$ious $ersion o! the program &regression'
Theory and constraints
E%hausti$e test
E%hausti$e test
!unction. U M , A 2
, and 2 integers+ @> (it
Total num(er o! test cases . >
@>
V >
@>
M
>
N4
95
>5
9 ms0test @555 (illion years
E%hausti$e test
6 possi(le paths per
iteration
>5 iterations
G$erall. 6
>5
95
94
possi(le paths
9 ms0test @9<5
years
20 iterations
E%hausti$e test
E%hausti$e test is not possi(le
So goal o! test is !inding de!ects+ not
demonstrating that systems is de!ect
!ree
Hoal o! test &and VV in general' is
assuring a goodenough le$el o!
con!idence
Cowden theorem
*or an ar(itrary program P it is
impossi(le to !ind an algorithm that is
a(le to generate a !inite ideal test &that
is selected (y a $alid and relia(le
criterion'
2raierd Danderwe(er
Hi$en two programs the pro(lem o!
deciding whether they compute the
same !unction is indecidi(le
There!ore e$en i! we ha$e access to
the archetype program we cannot
demonstrate the equi$alence o! a new
program
Bein(ergPs law
, de$eloper is unsuita(le to test
his0her own code
Testing should (e per!ormed (y
, separate ", team
Peers
I! a de$eloper misunderstands a
pro(lem+ he cannot !ind such error
Pareto3Wip! law
,ppro%imately ;57 o! de!ects come
!rom >57 o! modules
It is (etter to concentrate on the !aulty
modules
Test classi!ication
Per phase0granularity le$el
Unit+ integration+ system
Regression
Per approach
2lac) (o% &!unctional'
Bhite (o% &structural'
Relia(ility assessment0prediction
Ris) (ased &sa!ety security'
Test per granularity le$el0phase
Unit tests
Indi$idual modules
Integration tests
-odules when wor)ing together
System tests
The system as a whole &usa(le system'
Test per phase
Integrate
units
Design
.
Requirements
engineering
Requirement
document
Design
document
Unit
Unit
System
Implement
unit
Implement
unit
VV system
VV
design
VV requirements
VV unit
VV unit
Requirement
document
Design
document
Unit
Unit
System
Project management
on!iguration management
"uality assurance
Unit test+
integration test
System test+
Testing classi!ication &>'
Phase
Unit Integration System
Functional
/ black box
X X X
Structural /
white box
X
Reliability X
Risks X
Regression testing
Run tests
Test suite
Element $. % Element $. %A9
Run tests
Test per approach
Hi$en an o(ject0arti!act to test+ approach
can (e
Requirements dri$en
/ ,re the requirements o! the o(ject satis!ied#
Structure
/ Is the o(ject (uilt as it should#
Thrustworthiness
/ Does it satis!y the customer need# &use most common
operational scenarios'
Ris) and relia(ility
/ Is it $ulnera(le to most li)ely ris)s#
Test classi!ication and co$erage
Unit test
Unit Test
Integrate
units
Design
.
Requirements
engineering
Requirement
document
Design
document
Unit
Unit
System
Implement
unit
Implement
unit
VV system
VV
design
VV requirements
VV unit
VV unit
Requirement
document
Design
document
Unit
Unit
System
Project management
on!iguration management
"uality assurance
Unit test
2lac) (o% &!unctional'
Random
Equi$alence classes partitioning
2oundary conditions
Bhite 2o% &structural'
o$erage o! structural elements
Unit test / (lac) (o%
Random
*unction dou(le squareRoot&dou(le %'=
/ E%tract randomly %
/ T9 &@.5 = X@'
/ T> &9555.; = X9555.;'
/ T@ &39>>@.<= error'
*unction dou(le in$ert&dou(le %'=
/ E%tract randomly %
/ T9 &9.5 = 9.5'
/ T> &3>.5 = 35.6'
Equi$alence classes partitioning
Di$ide input space in partitions
that ha$e similar (eha$ior !rom point o!
$iew o! &requirements !or' unit
Ta)e one 0 two test cases per partition
2oundary conditions
2oundary (etween partitions
Ta)e test cases on the (oundary
Equi$alence classes
System
Outputs
Invalid inputs Valid inputs
Equi$alence classes
Test cases can (e partitioned into
equi$alence classes
I! a test in a class has not success the
other tests in the same class should not
succeed
, class correspond to set o! $alid or
in$alid inputs !or a condition on the
input $aria(les
Equi$alence classes de!inition
,n inter$al condition will ha$e classes !or
Valid input within the inter$al
In$alid input less than the minimum
In$alid input greater than the ma%imum
Valid input close the (oundaries
, single $alue condition will ha$e classes
!or.
The $alid $alue
In$alid $alues less than the $alue
In$alid $alues greater than the $alue
Equi$alence classes de!inition
, discrete set condition will ha$e
classes !or.
Each $alue in the set
, $alue not (elonging to the set
, (oolean $alue condition will ha$e
classes !or.
TRUE $alue
*alse $alue
Selection o! test cases
E$ery equi$alence class must (e
co$ered (y a test case at least
, test case !or each in$alid input class
Each test case !or $alid input classes must
co$er as many &remaining' $alid classes
as possi(le
Equi$alence classes
*unction dou(le squareRoot&dou(le %'=
Partitions
/ Positi$e num(ers T9 &9 = X9'
/ Kegati$e num(ers T> &39 = error'
2oundary. 1ero+ in!inite
/ Wero and close
T@ &5= X5' T4&5.59= X 5.59' T6&35.59= error'
/ OIn!initeP and close
TN &ma%dou(le= X ma%dou(le' T< &ma%dou(leA9=
err'
T; &mindou(le= X mindou(le' T< &mindou(le39=
err'
Equi$alence classes
int con$ert&String s'
con$erts a sequence o! chars &ma% N' in an
integer num(er. Kegati$e num(ers start with a O3
O
Criterion to define
the class
Equivalence classes and test cases
String represents a
well formed integer
Yes
T1(123; 123)
No
T2(1d3 ; error)
Sign of number Positive
T1(123 ; 123)
Negative
T3(-123 ; -123)
Number of
characters
<=6
T1(123 ; 123)
>6
T4(1234567; err)
Equi$. classes3 com(inatorial
WF integer sign N char
yes Pos <=6 T1(123; 123)
>6 T4(1234567; err)
Neg <=6 T3(-123; -123)
>6 T5(-123456; err)
no Pos <=6 T2(1d3; err)
>6 T6(1sed345; err)
Neg <=6 T7(-1ed; err)
>6 T8(-1ed234; err)
2oundary 3 com(inatorial
WF integer sign N char
yes Pos <=6 0 999999
>6 1000000 9999999
Neg <=6 -0 -99999
>6 -999999
no Pos <=6
>6 (7 blanks)
Neg <=6 -
>6 -
Equi$ classes and state
Bhen a module has state
the state has to (e considered to de!ine
the partitions
State may (e di!!icult to read0create
Requires a sequence o! calls
Equi$ classes and state
dou(le ,$e@&int i'
omputes a$erage o! last three num(ers
passed+ e%cluding the negati$e ones
riteria
/ state. n elements recei$ed
/ int i. positi$e+ negati$e
Equi$ classes and state
N elements I
0 NA
1 Pos T1(10; 10)
Neg T2(-10; ?)
2 Pos T3(10,20 ; 15)
Neg T4(-10,-20; ?)
3 Pos T5(10,2,6; 6)
Neg T6(-10,-2,-6; ?)
>3 Pos T7(1,2,3,4; 2.5)
Neg T8(-1,-2,-3,-4; ?)
Test o! GG classes
Ca$e state
-any !unctions to (e tested
Identi!y criteria and classes
,pply them to each !unction
Test o! GG classes
pu(lic class E$ents"ueueR
00 recei$es and stores e$ents+ with time tag
pu(lic $oid reset&'= 00 cancels all e$ents
pu(lic $oid push&int timeTag' throws In$alidTag
00 discards e$ents with negati$e or 1ero time tag
00 and with time tag already e%isting
pu(lic int pop&' throws Empty"ueue
00 returns and cancels e$ent with lower time tag
00 raises e%ception i! queue empty
S
Test o! GG classes
Is empty Repeated
elements in
input
Sign > 0 Test case
yes yes Yes
Reset(); Push(10); Push(10);
Pop() 10;
Pop(); EmptyQueue
No
Reset();Push(-10); Push(-10);
Pop(); EmptyQueue
no Yes
No
no yes Yes
No
no Yes
No
*unction push&'
Test o! GG classes
Is empty Repeated
elements in
input
Sign > 0 Test cases
yes yes Yes NA
No NA
no Yes reset(); pop()
EmptyQueue
No NA
no yes Yes NA
No NA
no Yes NA
No NA
*unction reset&'
Unit test (lac) (o% 3 summary
*unctional test o! units &!unctions+
classes' generates test cases starting
!rom the speci!ication o! the unit
Tey techniques are
Random
Equi$alence classes partitioning
2oundary conditions
Unit test 3 Bhite (o%
Unit test
2lac) (o% &!unctional'
Random
Equi$alence classes partitioning
Bhite 2o% &structural'
o$erage o! structural elements
Statement co$erage
dou(le a(s&dou(le %'R
i! &%YM5' then return %=
else return 3%=
S
statements
Two test cases to co$er all statements T9& 9= 9'
T>& 39= 9'
Statement co$erage
Try to e%ecute all statements in the
program
-easure.
statement co$erage M
Zstatements co$ered0 Zstatements
Kode co$erage
%YM 5
return 3% return %
T9 &9= 9'
T> &39= 9'
Statement co$erage M node co$erage
dou(le a(s&dou(le
%'R
i! &%YM5' then
return %=
else return
3%=
S
Decision co$erage
dou(le a(s&dou(le %'R
i! &%[5' then % M 3%=
return %=
S
%Y5
% M 3%
return %
T> &39= 9'
Decision co$erage
Try to co$er all decisions in the program
with true and !alse
-easure.
decision co$erage M
Zdecisions co$ered0 Zdecisions
!loat homewor),$erage&!loat8? scores' R
!loat min M :::::=
!loat total M 5=
!or &int i M 5= i [ scores.length= iAA'R
i! &scores8i? [ min'
min M scores8i?=
total AM scores8i?=
S
total M total / min=
return total 0 &scores.length / 9'=
S
minM::::
totalM5
iM5
i[scores.length
scores8i?[min
minMscores8i?
totalAMscores8i?
iAA
true
tru
e
totalMtotal3min
return
T9&R9S= 9'
T>&R9+>S= 9.6'
Relations
Edge co$erage implies node co$erage
not $ice$ersa
ondition co$erage
Simple
Test case age>60 isRetired isMarried
T1 T T T
T2 F F F
R
(oolean is-arried=
(oolean isRetired=
int age=
i! &ageYN5 and isRetired or is-arried'
discountRate M @5=
else discountRate M 95=
S
ondition co$erage
-ultiple
Test case age>60 isRetired isMarried Decisio
T1 T T T T
T2 T T F T
T3 T F T T
T4 T F F F
T5 F T T T
T6 F T F F
T7 F F T T
T8 F F F F
R
(oolean is-arried=
(oolean isRetired=
int age=
i! &ageYN5 and isRetired or is-arried'
discountRate M @5=
else discountRate M 95=
S
Relations
-ultiple condition co$erage
Simple condition co$erage
Decision co$erage
Statement co$erage
T> and T< pro$ide simple condition
co$erage+ (ut no decision co$erage
Test case age>60 isRetired isMarried Decision
T1 T T T T
T2 T T F T
T3 T F T T
T4 T F F F
T5 F T T T
T6 F T F F
T7 F F T T
T8 F F F F
Path co$erage
Path M sequence o! nodes in a graph
select test cases such that e$ery path
in the graph is $isited
Path co$erage
E%. 4 paths in this simple
graph
9+>+@+4+6
9+@+6
9+@+4+6
9+>+@+6
9
6
@
>
4
Path co$erage
om(inatorial
e%plosion with cycle
9+@+6
9+@+6+9+@+6
9+@+6+9+@+6+9+@+6
Etc ..
9
6
@
>
4
Path co$erage
In most cases un!easi(le i! graph is
cyclic
,ppro%imations
Path/n
/ Path34 MM loop 5 to 4 times in each loop
Doop co$erage
/ In each loop cycle 5+ 9 + Y9 times
Doop co$erage
select test cases such that e$ery loop
(oundary and interior is tested
2oundary. 5 iterations
Interior. 9 iteration and Y 9 iterations
o$erage !ormula. %0@
Doop co$erage
onsider each loop &!or+ while'
separately
Brite @ test cases
/ Ko enter the loop
/ ycle once in the loop
/ ycle more than once
Doop co$erage
!loat homewor),$erage&!loat8? scores' R
!loat min M :::::=
!loat total M 5=
!or &int i M 5= i [ scores.length= iAA'R
i! &scores8i? [ min'
min M scores8i?=
total AM scores8i?=
S
total M total / min=
return total 0 &scores.length / 9'=
S
minM::::
totalM5
iM5
i[scores.length
scores8i?[min
minMscores8i?
totalAMscores8i?
iAA
true
true
totalMtotal3min
return
T9&R9S= 9' loops 9
T>&R9+>+@S= >' loops Y9
T@&RS= #' loops 5
Tools
To write and run test cases
E% FUnit
To compute co$erage
E%. o(ertura
FUnit
o(ertura
Summary
Structural 0 white (o% testing starts
!rom the code+ and uses se$eral
co$erage o(jecti$es
Statements
Decisions
onditions &simple+ multiple'
Path
Doop
Summary
Bhite (o% testing is typically made in
the de$elopment en$ironment and
supported (y tools to compute
co$erage
Integration test
Integration test
Integrate
units
Design
.
Requirements
engineering
Requirement
document
Design
document
Unit
Unit
System
Implement
unit
Implement
unit
VV system
VV
design
VV requirements
VV unit
VV unit
Requirement
document
Design
document
Unit
Unit
System
Project management
on!iguration management
"uality assurance
The pro(lem
Some units need others. Cow to test
them#
The dependency graph
!unction9&' R 00some code
call !unction>&'=
call !unction@&'=
00 some other codeS
!unction>&' R 00some code
call !unction4&'=S
function1
function2 function3
function4
The pro(lem 3>
*unction@+ !unction4 ha$e
no dependency
Unit test techniques can (e
applied
*unction9+ !unction> ha$e
dependencies+ how to
test them#
Gption9. test e$erything
together &(ig (ang
integration'
Gption>. incremental &top
down+ (ottom up+ mi%ed'
function1
function2 function3
function4
2ig (ang integration
,ll !unctions
are de$eloped
Test is applied
directly to the
aggregate as3
i! it were a
single unit
function1
function2 function3
function4
Test cases
Pro(lems
Bhen a de!ect is !ound+ how to locate
it#
ould (e generated
/ (y any !unction
/ !unction9+ >+ @+ 4
/ (y any interaction
/ !unction9 to !unction>+ !unction9 to !unction@+
!unction> to !unction4
/ Interaction pro(lems. (ad parameter passed+
parameter passed in wrong order+ in wrong timing
E%. Integration pro(lems
triangleSur!ace& !loat height+ !loat (ase'RS
main&' R
triangleSur!ace&95+ 4'= 00 int instead o! !loat
triangleSur!ace&@.9+ 4.>'= 00 e%changed (ase &@.9'
00 and height &4.>'
S
Incremental integration
Hoal.
,dd one unit at a time+ test the partial
aggregate
Pro.
De!ects !ound+ most li)ely+ come (y last
unit0interaction added
on.
-ore tests to write+ stu(s0dri$ers to write
Step 9
!unction4+ !unction@
ha$e no
dependencies. Test
them in isolation &unit
test'
function3
function4
Test cases
function4
Test cases
function3
Step >
Test !unction>A!unction4
as3i! they were one unit
i! de!ect is !ound+ it should
come
/ !rom !unction> or
/ !rom interaction !unction93
!unction4
/ Kot !rom !unction 4+ that is
now OtrustedP
function2
function4
Test cases
Function2+4
Step @
Test all
i! de!ect is !ound+ it
should come
/ !rom !unction9 or
/ !rom interaction
!unction93!unction>
/ !rom interaction
!unction93!unction@
/ Kot !rom !unction >A4+
and !unction@+ that are
now OtrustedP
function1
function2 function3
function4
Test cases
Stu(+ dri$er
Dri$er
Unit &!unction or class' de$eloped to pilot
another unit
Stu(
Unit de$eloped to su(stitute another unit
&!a)e unit'
,lso called moc) ups
E%. dri$er &FUnit'
pu(lic class on$erter R
pu(lic int con$ert&char8? str' throws E%ception R
i! &str.length Y N'
throw new E%ception&'=
int num(er M 5=
int digit=
int i M 5=
i! &str85? MM \3\'
i M 9=
!or &= i [ str.length= iAA' R
digit M str8i? 3 \5\=
num(er M num(er V 95 A digit=
S
i! &str85? MM \3\'
num(er M 3num(er=
i! &num(er Y @><N< ]] num(er [ 3@><N;'
throw new E%ception&'=
return num(er=
S
S
pu(lic class on$erterTest e%tends Testase R
pu(lic $oid testGne&'R
on$erter c M new on$erter&'=
char 8? str M R\9\+ \>\+\@\+\4\+\6\+\N\+ \<\S=
try R
c.con$ert&str'=
!ail&'=
S catch &E%ception e' R
assertTrue&true'=
S
S S
Stu(
-ust (e simpler than unit su(stituted &trade
o!! (etween simplicity and !unctionality'
E%. unit M !unction to compute social security
num(er !rom name0!amily name etc.
Stu( M returns always same ssn
E%. unit M catalog o! products+ contains
thousands o! them
Stu(. ontains @ products+ returns them
randomly
Incremental integration
Top down
2ottom up
De!ined relati$ely to the dependency
graph
, system
Level 2 Level 2 Level 2
Level 3 Level 3 Level 3 Level 3
Level 1
Top3down
Level 1
Level 2
stub
Level 2
stub
Level 2
stub
Level 1
Driver
Top3down
Level 1
Level 2 Level 2 Level 2
Level 3
stub
Level 3
stub
Level 3
stub
Level 3
stub
Level 1
Driver
Top3down
Pros
,llows early detection o! architectural
!laws
, limited wor)ing system is a$aila(le
early
ons
Requires the de!inition o! stu(s !or all
lower le$el units
Suita(le only !or top3down de$elopment
Dower le$els not directly o(ser$a(le
2ottom3up
Level 3 Level 3 Level 3 Level 3
Level 3
Driver
Level 3
Driver
Level 3
Driver
Level 3
Driver
2ottom3up
Level 2 Level 2 Level 2
Level 3 Level 3 Level 3 Level 3
Level 2
Driver
Level 2
Driver
Level 2
Driver
2ottom3up
Level 2 Level 2 Level 2
Level 3 Level 3 Level 3 Level 3
Level 1
Driver
Level 1
2ottom3up
Pros
Testing can start early in the de$elopment
process
Dower le$els are directly o(ser$a(le
ons
Requires the de!inition o! dri$ers !or all
lower le$el units
E%ample
, company has employees and departments+ each employee (elongs
to a department
Payroll
salary&ID' / returns salary gi$en employee ID
(onus&amount' / gi$es (onus OamountP to employees with higher sales
record
Employee
name+ surname+ ID+ salary
Department
name+ id+ salesPerUear
addEmployee
Employees
add employee
search employee+ returns employee gi$en ID
Departments
add department
search department+ returns department gi$en ID
lass diagram &9'
Payroll
+bonus()
+salary()
Employee
+name
+surname
+ID
+salary
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
0%%&
0%%&
0%%&
1
Dependencies &9'
Payroll
+bonus()
+salary()
Employee
+name
+surname
+ID
+salary
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
Integration
2ottom up
Employee
Employees Department
Departments
Payroll
Top Down
Payroll
Departments+ Employees
2U 3 9
Employee
+name
+surname
+ID
+salary
DriverEmployee
2U 3 >
Employee
+name
+surname
+ID
+salary
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
DriverDepartment
2U / @
Employee
+name
+surname
+ID
+salary
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
DriverDepartments
DriverEmployees
2U 3 4
Payroll
+bonus()
+salary()
Employee
+name
+surname
+ID
+salary
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
DriverPayroll
TD / 9
Payroll
+bonus()
+salary()
StubDepartments StubEmployees
DriverPayroll
TD 3 >
Stu(Department+
Stu(Employee
pro(a(ly useless+
ha$e similar
comple%ity o!
Department and
Employee
Payroll
+bonus()
+salary()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
DriverPayroll
StubDepartment StubEmployee
lass Diagram &>'
Payroll
+bonus()
+salary()
Employee
+name
+surname
+ID
+salary
+setDe#artment()
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
0%%&
0%%&
0%%&
1
Dependencies &>'
Payroll
+bonus()
+salary()
Employee
+name
+surname
+ID
+salary
+setDe#artment()
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
Employees
+a!!"m#loyee()
+searc$"m#loyee()
Departments
+a!!De#artment()
+searc$De#artment()
Integration
9. onsider classes with dependency
loop as single class
Kot !easi(le i! large0comple% classes
>. hange design+ split loop
ase 9 3 2U
Ke%t steps as !or 2U case
Employee
+name
+surname
+ID
+salary
+setDe#artment()
Department
+name
+ID
+salesPerear
+a!!"m#loyee()
DriverEmployeeDepartment
System test
System test
Integrate
units
Design
.
Requirements
engineering
Requirement
document
Design
document
Unit
Unit
System
Implement
unit
Implement
unit
VV system
VV
design
VV requirements
VV unit
VV unit
Requirement
document
Design
document
Unit
Unit
System
Project management
on!iguration management
"uality assurance
System test
Is applied to the so!tware system as a
whole
,ims at $eri!ying the correspondence
o! the system to the requirements
Is per!ormed (y a test team &typically
not the de$elopment team'
System test
Test o! !unctional requirements
o$erage o! uses cases0scenarios as listed in
requirement document
onsider usage pro!ile &the most common+
typical ways o! using the system'
/ !r. Unit and integration test+ goal is co$erage+ using
all !unctions+ all code.
Test in conditions as !ar as possi(le close to
wor)ing conditions
!r. ,cceptance test per!ormed (y user
!r. Plat!orm
The plat!orm
En$ironment where an application runs+
de!ined (y
Gperating system
Data(ase
Ketwor)
-emory
PU
Di(raries
Gther applications installed
Gther users
Q
Plat!orm and test
,n element &system+ unit+ ..' can (e
tested on
Target plat!orm
/ Bhere the element will run !or day (y day use
/ annot annot annot annot (e used !or production
/ Ris) o! corrupting data
/ ,$aila(ility
Production plat!orm
/ Bhere the element is produced
/ annot (e &in most cases' equal to the target
plat!orm
Plat!orms+ e%amples
Em(edded system
,2S !or car+ heating control system+
mo(ile phone
/ Production plat!orm is typically P+ e%ternal
de$ices simulated0emulated
In!ormation system
2an) account management+ student
enrollment management
/ Production plat!orm is P or wor)station+
data(ase replicated in simpli!ied !orm
System test $ariants
De$eloper+ production plat!orm
De$eloper+ target plat!orm
,cceptance testing
User+ de$eloper plat!orm
User+ target plat!orm
System test
Test o! non !unctional requirements
Kon !unctional properties are usually
system+ &emerging' properties. In many
cases only testa(le when system is
a$aila(le
/ See e!!iciency+ relia(ility
Kon !unctional properties
Usa(ility+ relia(ility+ porta(ility+ Usa(ility+ relia(ility+ porta(ility+ Usa(ility+ relia(ility+ porta(ility+ Usa(ility+ relia(ility+ porta(ility+
maintaina(ility+ e!!iciency &see ISG :9>N' maintaina(ility+ e!!iciency &see ISG :9>N' maintaina(ility+ e!!iciency &see ISG :9>N' maintaina(ility+ e!!iciency &see ISG :9>N'
on!iguration. on!iguration. on!iguration. on!iguration. the commands and
mechanisms to change the system
Reco$ery. Reco$ery. Reco$ery. Reco$ery. the capa(ility o! the system to
react to catastrophic e$ents
Stress. Stress. Stress. Stress. relia(ility o! the system under limit
conditions
Security. Security. Security. Security. resilience to non authori1ed
accesses
System test 3 $ariants
,cceptance testing
Data and test cases pro$ided (y the customer+
on target plat!orm
2eta3testing
Selected group o! potential customers
Test+ in summary
*unctional0
non
!unctional
Bho tests Plat!orm Techniques
Unit test *unctional De$eloper
or test
group
Producti
on
22+ B2
Integration test *unctional De$eloper
or test
group
Producti
on
Incremental
TD or 2U
System test *unctional
A non
!unctional
De$eloper
or test
group or
user
Producti
on+
target
Requireme
nt co$erage
Scenarios+
pro!iles
Regression testing
Regression testing
Tests pre$iously de!ined are repeated
a!ter a change
To assure that the change has not
introduced de!ects
/ Time5
/ Element &unit+ system ' in $5+ test set t5 is de!ined
and applied+ all tests pass
/ Time9
/ Element is changed to $9
/ Test set t5 is re3applied+ do all tests still pass#
Test+ documentation and
automation
Representing test cases
In!ormally
i.e. Bord document
*ormally
Bord0e%cel document A translator to
programming language
/ *IT+ *itnesse
Programming language
/ Fa$a+ Eclipse A FUnit
/ &similar !or + Z+ http+ perl+..'
Test automation
The pro(lem
Test cases should (e not only
documented
So that they are not lost+ and can (e
reapplied
/ !r. Test cases are just in$ented and applied
2ut also automated
So that application o! test cases is !ast
and error !ree
/ !r manual application o! test cases
Testing tools
Ta(le (ased testing
*IT+ *itnesse
Documentation and application
Funit
apture replay
o$erage
Pro!iling
Ta(le (ased testing
Test cases are written as ta(les
&word0e%cel'+ and lin)ed to application to (e
tested
Pro.
,llows end users to write tests &especially
acceptance tests+ (lac) (o% tests'
Independent o! HUI
,llows automation
ons
Requires !i%tures
*IT *ramewor) !or Integrated Test
Gpen source implementation o! ta(le
(ased testing
User speci!ies tests in CT-D ta(les
De$elopers de!ines !i%tures to parse
ta(les and e%ecute tests
*it compares ta(les and actual results
*ITnesse
Standalone wi)i thatPs hoo)ed to *IT
,llows group to easily edit test !iles
without worrying a(out ensuring the
correct $ersions propagate out to all
locations
http.00!itnesse.org
apture replay
apture tool. captures end user test as
sequence o! e$ents on the HUI
-ouse clic)s+ )ey(oard inputs+ screen outputs
Replay tool. reapplies any captured
sequence
Pros.
End user write test case+ seamlessly
,llows automation
ons.
Depends on HUI structure. i! changed+ captured
test cases may not (e replayed
o$erage
Show graphically and numerically
co$erage &statements+ (ranches+
conditions' on source code
E%.+ lo$er+ Fco$erage+ o(ertura+
Eclemma
Pro!ilers
Trace time spent per !unction+ gi$en
speci!ic test e%ecution
Per!ormance test
Test documentation
Test process
Test Process Standard
IEEE Standard !or So!tware Test
Documentation &Std. ;>:39::; /
Re$ised Std. ;>: 9:;@'.
De!ines the deli$era(les to (e
produced (y the testing process
Deli$era(les
Planning and speci!ication documents
TP TP TP TP Test Plan
TDS TDS TDS TDS Test Design Speci!ication
TS TS TS TS Test ase
TPS TPS TPS TPS Test Procedure Speci!ication
Enactment documents
TTR TTR TTR TTR Test 3item Transmittal Report
TD TD TD TD Test Dog
TIR TIR TIR TIR Test Incident Report
TSR TSR TSR TSR Test 3Summary Report
Test plan
Huide the management o! testing
Esta(lish a plan and schedule
De!ine the required resources
De!ine the generic pass0!ail criteria
Identi!y the test items
E%plain the nature and e%tent o! each
test
Test plan
It is important to map test cases to
requirements
Req
%.9
Req
%.>
Req
y.9
Test 9 L L
Test > L
Test @ L
Test-requirement
Correspondence Table
Test design speci!ication
Speci!ies+ !or one or more !eatures to
(e tested the details o! the approach
Testing techniques
,nalysis o! results
Dist o! test cases and moti$ation
Heneric attri(utes
Test case speci!ication
Speci!ies a test case in terms o!
Input data
E%pected output &oracle'
Test conditions
/ Required CB and SB
The test case is listed in a TDS
document
Test procedure speci!ication
Speci!ies how to e%ecute one o more test
cases
The test procedure de!ines.
Cow to prepare the e%ecution o! the test
Cow to start and conduct the e%ecution
Bhich measurements to collect
Cow to suspend the test in presence o!
un!oreseen e$ents
Cow to resume a suspended test
Relationship among deli$era(les
Test plan
TDS 1
TDS 2
TCS 1 TPS 1 TCS 1 TCS 2 TPS 1
E%ecution deli$era(les
Test item transmittal report
Descri(es a test item deli$ered !or test
Includes at least
/ Identi!ication o! sw item
/ Its status
/ Its physical location
Test log
omplete+ systematic+ chronological
records o! all details relati$e to test
e%ecution
Test3Incident Report
Test incident.
,ny e$ent occurred during testing requiring
!urther in$estigation
TIR documents all test3incidents
Input
E%pected output
,ctual output
,nomalies
Time
,ttempts to re3e%ecute the test
Personnel
Test summary report
Summari1es the result o! a testing
session
Includes
Dist o! sol$ed incidents
Solutions applied
Dist o! unsol$ed incidents
E$aluation o! test limitations
G(ject3oriented sw test
Procedural
2asic component. procedure
Test method. procedure I0G
, procedure call is statically (ound to a code
Procedures )eep the same conte%t
GG
2asic components. class &dataAoperation'+ o(ject
Test methods. se$eral le$els
Polymorphism and dynamic (inding can change
it at run3time
-ethods can (e inherited (y se$eral classes
GG sw test
The (eha$ior depends on the state too
It may (e di!!icult to o(ser$e the state
Object
Input
Current
State
Output
Next
State
Static analysis
Static
inspections
source code analysis
Dynamic
testing
Static analysis techniques
ompilation static analysis
ontrol !low analysis
Data !low analysis
Sym(olic e%ecution
Inspections
ompilation analysis
ompilers analy1e the code chec)ing
!or
Synta% correctness
Types correctness
Semantic correctness
The errors detected (y a compiler
strongly depend on the language
Doose $s. strongly typed languages
Static $s. dynamic $isi(ility
-ISR,3
-ISR,. -otor Industry So!tware
Relia(ility ,ssociation
Issues -isra3+ guidelines !or
programs
Issue9+ 9::;
/ 9>< rules+ :@ compulsory
Issue>+ >554
/ 949 rules+ 9>9 compulsory
Rules+ e%amples
6 Use only characters in the source character set. This
e%cludes the characters ^ and _+ among others.
>> Declarations o! identi!iers denoting o(jects should
ha$e the narrowest (loc) scope unless a wider
scope is necessary.
@4 The operands o! the && and ]] operators shall (e
enclosed in parenthesis unless they are single
identi!iers.
N< Identi!iers modi!ied within the increment
e%pression o! a loop header shall not (e modi!ied
inside the (loc) controlled (y that loop header.
95@ Relational operators shall not (e applied to
o(jects o! pointer type e%cept where (oth operands
are o! the same type and (oth point into the same
o(ject.
Rule 6
signed char dollar M P^P=
not accepted
signed char esc`m M PamP=
not accepted &what would (e the
associated (eha$iour to this escape
sequence#'
Rule @4
i! &&$arAA' ]] &num MM 99''R...S 0V GT V0
i! &$arAA ]] num MM 99'R...S 0V KGT GT V0
i! &&$ect8num?' && &num MM 99''R...S 0V GT V0
i! &&structure.!ield bM 5' && &num [ 99''R...S 0V
GT V0
i! &$ect8num? MM 4 && &num MM 99''R...S 0V KGT
GT V0
Rule N<
!or &int i M 5= i[ ma%= iAA'R
iMiA9= 00 KG
S
-isra static analy1ers
Parse source code and chec) i! rules
are $iolated
",3 (y Programming Research+ is a !ull
!eatured -ISR, 9 and > $alidator.
Test(ed (y DDR,+ o!!ers a static and
dynamic analysis.
P3Dint (y Himpel+ is one o! the !astest
and least e%pensi$e $alidtors.
D, (y Ristan3,SE+ pro$ides a re$erse
engineering+ documentation and code
analy1er.
2ad Smells &*owler'
*owler et al.+ Re!actoring+ Impro$ing
quality o! e%isting code
2ad smells
Duplicated code
Dong method
Darge class
Dong parameter list
Di$ergent change
Shotgun surgery
*eature en$y
Data clumps
Primiti$e o(session
Switch statements
Parallel inheritance hierarchies
Da1y class
Speculati$e generality
Temporary !ield
-essage chain
-iddle man
Inappropriate intimacy
,lternati$e classes with di!!erent inter!aces
Incomplete Di(rary class
Data class
Re!used (equest
omments
Fa$a analy1ers
P-D
pmd.source!orge.net
*ind(ug
!ind(ug.source!orge.net
P-D
ruleset
filename
Fa$a3generated
parser
InputStream
AST
For each
rule
Rules violations
P-D+ rules
empty try0catch0!inally0switch
statements...
Dead code 3 unused local $aria(les+
parameters and pri$ate methods...
Su(optimal code 3 waste!ul
String0String2u!!er usage...
G$ercomplicated e%pressions 3
unnecessary i! statements+ !or loops that
could (e while loops...
Duplicate code 3 copied0pasted code
means copied0pasted (ugs
*ind(ug+ rules
orrectness (ug.
/ Pro(a(le (ug 3 an apparent coding mista)e resulting in
code that was pro(a(ly not what the de$eloper
intended.
2ad Practice
/ Violations o! recommended and essential coding
practice. E%amples include hash code and equals
pro(lems+ clonea(le idiom+ dropped e%ceptions+
seriali1a(le pro(lems+ and misuse o! !inali1e.
Dodgy
/ ode that is con!using+ anomalous+ or written in a way
that leads itsel! to errors. E%amples include dead local
stores+ switch !all through+ uncon!irmed casts+ and
redundant null chec) o! $alue )nown to (e null.
P-D and *IKD 2UHS. let\s tryb
Det\s run the plugins with the !ollowing
piece o! code
Results comparison
pri$ate int unread= pri$ate int unread= pri$ate int unread= pri$ate int unread=
pu(lic $oid pu(lic $oid pu(lic $oid pu(lic $oid
print`a`null`string&'R print`a`null`string&'R print`a`null`string&'R print`a`null`string&'R
String s M new String String s M new String String s M new String String s M new String
&cI\m not null...yetc'= &cI\m not null...yetc'= &cI\m not null...yetc'= &cI\m not null...yetc'=
Avoid unused
private fields
Methods names should
not contain underscores
Avoid instantiating
String objects: it's
usually unnecessary
Avoid variables
with short names
Unused
field
Dead store to variable s
Invokes inefficient
new String(String)
constructor
Results comparison
sMnull= sMnull= sMnull= sMnull=
System.out.println System.out.println System.out.println System.out.println
&s.length&''= &s.length&''= &s.length&''= &s.length&''=
S SS S
Assigning an Object to null
is a code smell.
Consider refactoring.
System.(out|err).print is
used, consider using a
logger.
Null point
deference of s
Load of known null value
Anomaly: A recently defined variable is
redefined. This is ominous but don't
have to be a bug.
Data !low analysis
,naly1es the $alues o! $aria(les during
e%ecution to !ind out anomalies
Doo)s li)e dynamic (ut some in!ormation
can (e collected statically
Three operations on $aria(les
De!inition. 3 write3 a new $alue is assigned
Use. 3 read3 the $alue o! the $aria(le is read
Kulli!ication. the $aria(le has no signi!icant $alue
Data !low analysis
orrect sequences
D U
The use o! a $aria(le must (e always preceded
(y a de!inition o! the same $aria(le
Suspect &!or(idden' sequences
D D
K U
, use o! a $aria(le not preceded (y a de!inition
corresponds to the use o! an unde!ined $alue
Data !low analysis
Tools reco$er the sequence and recogni1e
suspect ones
%9 %> %
void swap(float*x1, float* x2){ D D 3
int float x; 3 3 K
*x2 = x; 3 D U
*x2 = *x1; U D 3
*x1 = x; D 3 U
}
x = *x2;
Sym(olic e%ecution
The program is e%ecuted with
sym(olic $alues instead o! actual
$alues
Gutput $aria(les are e%pressed as
sym(olic !ormulas o! input $aria(les
Sym(olic e%ecution may (e e%tremely
comple% e$en !or simple programs
Sym(olic e%ecution
9 integer product &int %+ int y+ int 1'R 9 integer product &int %+ int y+ int 1'R 9 integer product &int %+ int y+ int 1'R 9 integer product &int %+ int y+ int 1'R
> int tmp9+ tmp>= > int tmp9+ tmp>= > int tmp9+ tmp>= > int tmp9+ tmp>=
@ tmp9 M %Vy= @ tmp9 M %Vy= @ tmp9 M %Vy= @ tmp9 M %Vy=
4 tmp> M yV1= 4 tmp> M yV1= 4 tmp> M yV1= 4 tmp> M yV1=
6 return tmp9 V tmp> 0 y= 6 return tmp9 V tmp> 0 y= 6 return tmp9 V tmp> 0 y= 6 return tmp9 V tmp> 0 y=
N S N S N S N S
Stmt % y 1 tmp9 tmp> product
> L U W # # #
@ L U W LVU # #
4 L U W LVU UVW #
6 L U W LVU UVW LVUVUVW 0 U