Software Testing Methodologies - Aditya Engineering College 1

12/1/2016
SOFTWARETESTINGMETHODOLOGIESADITYAENGINEERINGCOLLEGE
SoftwareTestingMethodologiesCoursePage
R07RegulationDept.ofCSE&IT
AdityaEngineeringCollege
HOME
QUICKLINKS
BRIEF
OVERVIEW
UNITI
Purposeof
Testing
Dichotomies
Modelfor
Testing
Consequences
ofBugs
Taxonomyof
Bugs
Summary
UNITII
BasicsofPath
Testing
Predicates,Path
Predicatesand
Achievable
Paths
PathSensitizing
Path
Instrumentation
Applicationof
PathTesting
Summary
UNITIII
Transaction
Flows
Transaction
FlowTesting
Techniques
Implementation
BasicsofData
FlowTesting
Strategiesin
DataFlow
Testing
Applicationof
DataFlow
Testing
Summary
UNITIV
SCHEDULE
RESOURCES
GLOSSARY
ASSIGNMENTS
UNITIIITRANSACTIONFLOWTESTINGANDDATAFLOWTESTING
TRANSACTIONFLOWTESTINGANDDATAFLOWTESTING:
This unit gives an indepth overview of two forms of functional or system testing namely Transaction Flow
TestingandDataFlowTesting.
Attheendofthisunit,thestudentwillbeableto:
Understandtheconceptoftransactionflowtestinganddataflowtesting.
Visualizethetransactionflowanddataflowinasoftwaresystem.
Understandtheneedandappreciatetheusageofthetwotestingmethods.
Identifythecomplicationsinatransactionflowtestingmethodandanomaliesindataflowtesting.
Interpretthedataflowanomalystategraphsandcontrolflowgrpahsandrepresentthestateofthedata
objetcs.
UnderstandthelimitationsofStaticanalysisindataflowtesting.
Compareandanalyzevariousstrategiesofdataflowtesting.
TRANSACTIONFLOWS:
TOP
INTRODUCTION:
Atransactionisaunitofworkseenfromasystemuser'spointofview.
A transaction consists of a sequence of operations, some of which are performed by a
system,personsordevicesthatareoutsideofthesystem.
TransactionbeginwithBirththatistheyarecreatedasaresultofsomeexternalact.
Attheconclusionofthetransaction'sprocessing,thetransactionisnolongerinthesystem.
Example of a transaction: A transaction for an online information retrieval system might
consistofthefollowingstepsortasks:
Acceptinput(tentativebirth)
Validateinput(birth)
Transmitacknowledgementtorequester
Doinputprocessing
Searchfile
Requestdirectionsfromuser
Acceptinput
Validateinput
Processrequest
Updatefile
Transmitoutput
Recordtransactioninlogandcleanup(death)
TRANSACTIONFLOWGRAPHS:
Transactionflowsareintroducedasarepresentationofasystem'sprocessing.
Themethodsthatwereappliedtocontrolflowgraphsarethenusedforfunctionaltesting.
Transaction flows and transaction flow testing are to the independent system tester what
controlflowsarepathtestingaretotheprogrammer.
http://www.mcr.org.in/sureshmudunuri/stm/unit3.php#strategies_dft
1/14
12/1/2016
Domainsand
Paths
NiceandUgly
domains
DomainTesting
Domainand
Interface
Testing
Domainsand
Testability
Summary
The transaction flow graph is to create a behavioral model of the program that leads to
functionaltesting.
Thetransactionflowgraphisamodelofthestructureofthesystem'sbehavior(functionality).
AnexampleofaTransactionFlowisasfollows:
UNITV
Pathproducts
andPath
expression
Reduction
Procedure
Applications
Regular
Expressionsand
FlowAnomaly
Detection
Summary
UNITVI
LogicBased
Testing
DecisionTables
Path
Expressions
KVCharts
Specications
Summary
Figure3.1:AnExampleofaTransactionFlow
USAGE:
Transaction flows are indispensable for specifying requirements of complicated systems,
especiallyonlinesystems.
Abigsystemsuchasanairtrafficcontrolorairlinereservationsystem,hasnothundreds,but
thousandsofdifferenttransactionflows.
The flows are represented by relatively simple flowgraphs, many of which have a single
straightthroughpath.
Loopsareinfrequentcomparedtocontrolflowgraphs.
Themostcommonloopisusedtorequestaretryafteruserinputerrors.AnATMsystem,for
example,allowstheusertotry,saythreetimes,andwilltakethecardawaythefourthtime.
COMPLICATIONS:
In simple cases, the transactions have a unique identity from the time they're created to the
timethey'recompleted.
Inmanysystemsthetransactionscangivebirthtoothers,andtransactionscanalsomerge.
Births:Therearethreedifferentpossibleinterpretationsofthedecisionsymbol,ornodeswith
twoormoreoutlinks.ItcanbeaDecision,BiosisoraMitosis.
1.Decision:Here the transaction will take one alternative or the other alternative but
notboth.(SeeFigure3.2(a))
2.Biosis:Here the incoming transaction gives birth to a new transaction, and both
transactioncontinueontheirseparatepaths,andtheparentretainsitidentity.(See
Figure3.2(b))
3.Mitosis:Here the parent transaction is destroyed and two new transactions are
created.(SeeFigure3.2(c))
2/14
12/1/2016
Figure3.2:Nodeswithmultipleoutlinks
Mergers:Transaction flow junction points are potentially as troublesome as transaction flow
splits.Therearethreetypesofjunctions:(1)OrdinaryJunction(2)Absorption(3)Conjugation
1.OrdinaryJunction:Anordinaryjunctionwhichissimilartothejunctioninacontrol
flowgraph.Atransactioncanarriveeitherononelinkortheother.(SeeFigure3.3
(a))
2.Absorption:Inabsorptioncase,thepredatortransactionabsorbspreytransaction.
Thepreygonebutthepredatorretainsitsidentity.(SeeFigure3.3(b))
3.Conjugation:Inconjugationcase,thetwoparenttransactionsmergetoformanew
daughter. In keeping with the biological flavor this case is called as conjugation.
(SeeFigure3.3(c))
Figure3.3:TransactionFlowJunctionsandMergers
We have no problem with ordinary decisions and junctions. Births, absorptions, and
conjugationsareasproblematicforthesoftwaredesignerastheyareforthesoftwaremodeler
andthetestdesignerasaconsequence,suchpointshavemorethantheirshareofbugs.The
commonproblemsare:lostdaughters,wrongfuldeaths,andillegitimatebirths.
TOP
TRANSACTIONFLOWTESTINGTECHNIQUES:
TOP
GETTHETRANSACTIONSFLOWS:
Complicated systems that process a lot of different, complicated transactions should have
explicitrepresentationsofthetransactionsflows,ortheequivalent.
Transaction flows are like control flow graphs, and consequently we should expect to have
theminincreasinglevelsofdetail.
Thesystem'sdesigndocumentationshouldcontainanoverviewsectionthatdetailsthemain
transactionflows.
Detailed transaction flows are a mandatory pre requisite to the rational design of a system's
functionaltest.
INSPECTIONS,REVIEWSANDWALKTHROUGHS:
Transactionflowsarenaturalagendaforsystemreviewsorinspections.
Inconductingthewalkthroughs,youshould:
Discuss enough transaction types to account for 98%99% of the transaction the
systemisexpectedtoprocess.
Discusspathsthroughflowsinfunctionalratherthantechnicalterms.
Ask the designers to relate every flow to the specification and to show how that
transaction,directlyorindirectly,followsfromtherequirements.
Make transaction flow testing the corner stone of system functional testing just as path
testingisthecornerstoneofunittesting.
Selectadditionalflowpathsforloops,extremevalues,anddomainboundaries.
Designmoretestcasestovalidateallbirthsanddeaths.
Publish and distribute the selected test paths through the transaction flows as early as
possiblesothattheywillexertthemaximumbeneficialeffectontheproject.
3/14
12/1/2016
PATHSELECTION:
Select a set of covering paths (c1+c2) using the analogous criteria you used for structural
pathtesting.
Select a covering set of paths based on functionally sensible transactions as you would for
controlflowgraphs.
Try to find the most tortuous, longest, strangest path from the entry to the exit of the
transactionflow.
PATHSENSITIZATION:
Most of the normal paths are very easy to sensitize80% 95% transaction flow coverage
(c1+c2)isusuallyeasytoachieve.
Theremainingsmallpercentageisoftenverydifficult.
Sensitization is the act of defining the transaction. If there are sensitization problems on the
easypaths,thenbetoneitherabugintransactionflowsoradesignbug.
PATHINSTRUMENTATION:
Instrumentationplaysabiggerroleintransactionflowtestingthaninunitpathtesting.
The information of the path taken for a given transaction must be kept with that transaction
and can be recorded by a central transaction dispatcher or by the individual processing
modules.
Insomesystems,suchtracesareprovidedbytheoperatingsystemsorarunninglog.
TOP
IMPLEMENTATION:
TOP
Tobeadded
TOP
BASICSOFDATAFLOWTESTING:
TOP
DATAFLOWTESTING:
Data flow testing is the name given to a family of test strategies based on selecting paths
through the program's control flow in order to explore sequences of events related to the
statusofdataobjects.
For example, pick enough paths to assure that every data object has been initialized prior to
useorthatalldefinedobjectshavebeenusedforsomething.
Motivation:
itisourbeliefthat,justasonewouldnotfeelconfidentaboutaprogramwithout
executing every statement in it as part of some test, one should not feel
confident about a program without having seen the effect of using the value
producedbyeachandeverycomputation.
DATAFLOWMACHINES:
There are two types of data flow machines with different architectures. (1) Von Neumann
machnes(2)Multiinstruction,multidatamachines(MIMD).
VonNeumannMachineArchitecture:
Mostcomputerstodayarevonneumannmachines.
This architecture features interchangeable storage of instructions and data in the
samememoryunits.
The Von Neumann machine Architecture executes one instruction at a time in the
following,microinstructionsequence:
1.Fetchinstructionfrommemory
2.Interpretinstruction
3.Fetchoperands
4.ProcessorExecute
5.Storeresult
6.Incrementprogramcounter
4/14
12/1/2016
7.GOTO1
Multiinstruction,Multidatamachines(MIMD)Architecture:
Thesemachinescanfetchseveralinstructionsandobjectsinparallel.
Theycanalsodoarithmeticandlogicaloperationssimultaneouslyondifferentdata
objects.
Thedecisionofhowtosequencethemdependsonthecompiler.
BUGASSUMPTION:
Thebugassumptionfordataflowtestingstrategiesisthatcontrolflowisgenerallycorrectand
thatsomethinghasgonewrongwiththesoftwaresothatdataobjectsarenotavailablewhen
theyshouldbe,orsillythingsarebeingdonetodataobjects.
Also, if there is a controlflow problem, we expect it to have symptoms that can be detected
bydataflowanalysis.
Althoughwe'llbedoingdataflowtesting,wewon'tbeusingdataflowgraphsassuch.Rather,
we'lluseanordinarycontrolflowgraphannotatedtoshowwhathappenstothedataobjectsof
interestatthemoment.
DATAFLOWGRAPHS:
Thedataflowgraphisagraphconsistingofnodesanddirectedlinks.
Figure3.4:Exampleofadataflowgraph
Wewilluseancontrolgraphtoshowwhathappenstodataobjectsofinterestatthatmoment.
Ourobjectiveistoexposedeviationsbetweenthedataflowswehaveandthedataflowswe
want.
DataObjectStateandUsage:
DataObjectscanbecreated,killedandused.
Theycanbeusedintwodistinctways:(1)InaCalculation(2)AsapartofaControl
FlowPredicate.
Thefollowingsymbolsdenotethesepossibilities:
1.Defined:ddefined,created,initializedetc
2.Killedorundefined:kkilled,undefined,releasedetc
3.Usage: u used for something (c used in Calculations, p used in a
predicate)
1.Defined(d):
Anobjectisdefinedexplicitlywhenitappearsinadatadeclaration.
Orimplicitlywhenitappearsonthelefthandsideoftheassignment.
5/14
12/1/2016
Itisalsotobeusedtomeanthatafilehasbeenopened.
Adynamicallyallocatedobjecthasbeenallocated.
Somethingispushedontothestack.
Arecordwritten.
2.KilledorUndefined(k):
An object is killed on undefined when it is released or otherwise made
unavailable.
When its contents are no longer known with certitude (with aboslute
certainity/perfectness).
Releaseofdynamicallyallocatedobjectsbacktotheavailabilitypool.
Returnofrecords.
Theoldtopofthestackafteritispopped.
Anassignmentstatementcankillandredefineimmediately.Forexample,
ifAhadbeenpreviouslydefinedandwedoanewassignmentsuchasA
:=17,wehavekilledA'spreviousvalueandredefinedA
3.Usage(u):
A variable is used for computation (c) when it appears on the right hand
sideofanassignmentstatement.
Afilerecordisreadorwritten.
ItisusedinaPredicate(p)whenitappearsdirectlyinapredicate.
DATAFLOWANOMALIES:
Ananomalyisdenotedbyatwocharactersequenceofactions.
For example, ku means that the object is killed and then used, where as dd means that the
objectisdefinedtwicewithoutaninterveningusage.
Whatisananomalyisdependontheapplication.
There are nine possible twoletter combinations for d, k and u. some are bugs, some are
suspicious,andsomeareokay.
1.dd : probably harmless but suspicious. Why define the object twice without an
interveningusage?
2.dk:probablyabug.Whydefinetheobjectwithoutusingit?
3.du:thenormalcase.Theobjectisdefinedandthenused.
4.kd:normalsituation.Anobjectiskilledandthenredefined.
5.kk:harmlessbutprobablybuggy.Didyouwanttobesureitwasreallykilled?
6.ku:abug.theobjectdoesnotexist.
7.ud : usually not a bug because the language permits reassignment at almost any
time.
8.uk:normalsituation.
9.uu:normalsituation.
Inadditiontothetwolettersituations,therearesixsinglelettersituations.
We will use a leading dash to mean that nothing of interest (d,k,u) occurs prior to the action
notedalongtheentryexitpathofinterest.
Atrailingdashtomeanthatnothinghappensafterthepointofinteresttotheexit.
Theypossibleanomaliesare:
1.k : possibly anomalous because from the entrance to this point on the path, the
variablehadnotbeendefined.Wearekillingavariablethatdoesnotexist.
2.d:okay.Thisisjustthefirstdefinitionalongthispath.
3.u : possibly anomalous. Not anomalous if the variable is global and has been
previouslydefined.
4.k:notanomalous.Thelastthingdoneonthispathwastokillthevariable.
5.d : possibly anomalous. The variable was defined and not used on this path. But
thiscouldbeaglobaldefinition.
6.u:notanomalous.Thevariablewasusedbutnotkilledonthispath.Althoughthis
sequence is not anomalous, it signals a frequent kind of bug. If d and k mean
dynamic storage allocation and return respectively, this could be an instance in
whichadynamicallyallocatedobjectwasnotreturnedtothepoolafteruse.
DATAFLOWANOMALYSTATEGRAPH:
Dataflowanomalymodelprescribesthatanobjectcanbeinoneoffourdistinctstates:
1.K:undefined,previouslykilled,doesnotexist
2.D:definedbutnotyetusedforanything
3.U:hasbeenusedforcomputationorinpredicate
4.A:anomalous
6/14
12/1/2016
These capital letters (K,D,U,A) denote the state of the variable and should not be confused
withtheprogramaction,denotedbylowercaseletters.
UnforgivingDataFlowAnomalyFlowGraph:Unforgiving model, in which once a variable
becomesanomalousitcanneverreturntoastateofgrace.
Figure3.5:UnforgivingDataFlowAnomalyStateGraph
Assume that the variable starts in the K state that is, it has not been defined or does not
exist. If an attempt is made to use it or to kill it (e.g., say that we're talking about opening,
closing, and using files and that 'killing' means closing), the object's state becomes
anomalous(stateA)and,onceitisanomalous,noactioncanreturnthevariableto a working
state. If it is defined (d), it goes into the D, or defined but not yet used, state. If it has been
defined(D)andredefined(d)orkilledwithoutuse(k),itbecomesanomalous,while usage (u)
bringsittotheUstate.IfinU,redefinition(d)bringsittoD,ukeepsitinU,andkkillsit.
Forgiving Data Flow Anomaly Flow Graph:Forgiving model is an alternate model where
redemption(recover)fromtheanomalousstateispossible.
Figure3.6:ForgivingDataFlowAnomalyStateGraph
This graph has three normal and three anomalous states and he considers the kk sequence
not to be anomalous. The difference between this state graph and Figure 3.5 is that
redemption is possible. A proper action from any of the three anomalous states returns the
variabletoausefulworkingstate.
The point of showing you this alternative anomaly state graph is to demonstrate that the
specifics of an anomaly depends on such things as language, application, context, or even
yourframeofmind.Inprinciple,youmustcreateanewdefinitionofdataflowanomaly(e.g.,a
newstategraph)ineachsituation.Youmustatleastverifythattheanomalydefinitionbehind
thetheoryorimbeddedinadataflowanomalytesttoolisappropriatetoyoursituation.
STATICVsDYNAMICANOMALYDETECTION:
Static analysis is analysis done on source code without actually executing it. For example:
sourcecodesyntaxerrordetectionisthestaticanalysisresult.
7/14
12/1/2016
Dynamic analysis is done on the fly as the program is being executed and is based on
intermediatevaluesthatresultfromtheprogram'sexecution.Forexample:adivisionbyzero
warningisthedynamicresult.
Ifaproblem,suchasadataflowanomaly,canbedetectedbystaticanalysismethods,then
itdoesnotbelongsintestingitbelongsinthelanguageprocessor.
Thereisactuallyalotmorestaticanalysisfordataflowanalysisfordataflowanomaliesgoing
onincurrentlanguageprocessors.
For example, language processors which force variable declarations can detect (u) and (ku)
anomalies.
ButstilltherearemanythingsforwhichcurrentnotionsofstaticanalysisareINADEQUATE.
WhyStaticAnalysisisn'tenough?Therearemanythingsforwhichcurrentnotionsofstatic
analysisareinadequate.Theyare:
DeadVariables:Althoughitisoftenpossibletoprovethatavariableisdeadoralive
atagivenpointintheprogram,thegeneralproblemisunsolvable.
Arrays:Arrays are problematic in that the array is defined or killed as a single
object, but reference is to specific locations within the array. Array pointers are
usuallydynamicallycalculated,sothere'snowaytodoastaticanalysistovalidate
thepointervalue.Inmanylanguages,dynamicallyallocatedarrayscontaingarbage
unlessexplicitlyinitializedandtherefore,uanomaliesarepossible.
Records and Pointers:The array problem and the difficulty with pointers is a
special case of multipart data structures. We have the same problem with records
andthepointerstothem.Also,inmanyapplicationswecreatefilesandtheirnames
dynamically and there's no way to determine, without execution, whether such
objectsareintheproperstateonagivenpathor,forthatmatter,whethertheyexist
atall.
DynamicSubroutineandFunctionNamesinaCall:subroutine or function name
is a dynamic variable in a call. What is passed, or a combination of subroutine
namesanddataobjects,isconstructedonaspecificpath.There'snoway,without
executingthepath,todeterminewhetherthecalliscorrectornot.
False Anomalies:Anomalies are specific to paths. Even a "clear bug" such as ku
maynotbeabugifthepathalongwhichtheanomalyexistisunachievable.Such
"anomalies"arefalseanomalies.Unfortunately,theproblemofdeterminingwhether
apathisorisnotachievableisunsolvable.
Recoverable Anomalies and Alternate State Graphs:What constitutes an
anomaly depends on context, application, and semantics. How does the compiler
knowwhichmodelIhaveinmind?Itcan'tbecausethedefinitionof"anomaly"isnot
fundamental. The language processor must have a builtin anomaly definition with
whichyoumayormaynot(withgoodreason)agree.
Concurrency,Interrupts,SystemIssues:Assoonaswegetawayfromthesimple
singletask uniprocessor environment and start thinking in terms of systems, most
anomalyissuesbecomevastlymorecomplicated.Howoftendowedefineorcreate
data objects at an interrupt level so that they can be processed by a lowerpriority
routine?Interruptscanmakethe"correct"anomalousandthe"anomalous"correct.
True concurrency (as in an MIMD machine) and pseudoconcurrency (as in
multiprocessing) systems can do the same to us. Much of integration and system
testing is aimed at detecting dataflow anomalies that cannot be detected in the
contextofasingleroutine.
Although static analysis methods have limits, they are worth using and a continuing trend in
language processor design has been better static analysis methods, especially for data flow
anomalydetection.That'sgoodbecauseitmeansthere'slessforustodoastestersandwe
havefartoomuchtodoasitis.
DATAFLOWMODEL:
Thedataflowmodelisbasedontheprogram'scontrolflowgraphDon'tconfusethatwiththe
program'sdataflowgraph..
Hereweannotateeachlinkwithsymbols(forexample,d,k,u,c,p)orsequencesofsymbols
(for example, dd, du, ddd) that denote the sequence of data operations on that link with
respecttothevariableofinterest.Suchannotationsarecalledlinkweights.
Thecontrolflowgraphstructureissameforeveryvariable:itistheweightsthatchange.
Componentsofthemodel:
1.Toeverystatementthereisanode,whosenameisunique.Everynodehasatleast
oneoutlinkandatleastoneinlinkexceptforexitnodesandentrynodes.
2.Exitnodesaredummynodesplacedattheoutgoingarrowheadsofexitstatements
(e.g., END, RETURN), to complete the graph. Similarly, entry nodes are dummy
nodesplacedatentrystatements(e.g.,BEGIN)forthesamereason.
3.Theoutlinkofsimplestatements(statementswithonlyoneoutlink)areweightedby
thepropersequenceofdataflowactionsforthatstatement.Notethatthesequence
8/14
12/1/2016
canconsistofmorethanoneletter.Forexample,theassignmentstatementA:=A
+BinmostlanguagesisweightedbycdorpossiblyckdforvariableA.Languages
that permit multiple simultaneous assignments and/or compound statements can
haveanomalieswithinthestatement.Thesequencemustcorrespondtotheorderin
whichtheobjectcodewillbeexecutedforthatvariable.
4.Predicatenodes(e.g.,IFTHENELSE,DOWHILE,CASE)areweightedwiththep
use(s)oneveryoutlink,appropriatetothatoutlink.
5.Every sequence of simple statements (e.g., a sequence of nodes with one inlink
andoneoutlink)canbereplacedbyapairofnodesthathas,asweightsonthelink
betweenthem,theconcatenationoflinkweights.
6.If there are several dataflow actions on a given link for a given variable, then the
weight of the link is denoted by the sequence of actions on that link for that
variable.
7.Conversely, a link with several dataflow actions on it can be replaced by a
succession of equivalent links, each of which has at most one dataflow action for
anyvariable.
Letusconsidertheexample:
Figure3.7:ProgramExample(PDL)
Figure3.8:UnannotatedflowgraphforexampleprograminFigure3.7
9/14
12/1/2016
Figure3.9:ControlflowgraphannotatedforXandYdataflows.
Figure3.10:ControlflowgraphannotatedforZdataflow.
Figure3.11:ControlflowgraphannotatedforVdataflow.
TOP
STRATEGIESOFDATAFLOWTESTING:
TOP
INTRODUCTION:
DataFlowTestingStrategiesarestructuralstrategies.
Incontrasttothepathtestingstrategies,dataflowstrategiestakeintoaccountwhathappens
todataobjectsonthelinksinadditiontotherawconnectivityofthegraph.
10/14
12/1/2016
Inotherwords,dataflowstrategiesrequiredataflowlinkweights(d,k,u,c,p).
Data Flow Testing Strategies are based on selecting test path segments (also called sub
paths)thatsatisfysomecharacteristicofdataflowsforalldataobjects.
Forexample,allsubpathsthatcontainad(oru,k,du,dk).
A strategy X is stronger than another strategy Y if all test cases produced under Y are
includedinthoseproducedunderXconverselyforweaker.
TERMINOLOGY:
1.DefinitionClearPathSegment,withrespecttovariableX,isaconnectedsequenceoflinks
suchthatXis(possibly)definedonthefirstlinkandnotredefinedorkilledonanysubsequent
linkofthatpathsegment.llpathsinFigure3.9aredefinitionclearbecausevariablesXandY
are defined only on the first link (1,3) and not thereafter. In Figure 3.10, we have a more
complicated situation. The following path segments are definitionclear: (1,3,4), (1,3,5),
(5,6,7,4), (7,8,9,6,7), (7,8,9,10), (7,8,10), (7,8,10,11). Subpath (1,3,4,5) is not definitionclear
because the variable is defined on (1,3) and again on (4,5). For practice, try finding all the
definitionclearsubpathsforthisroutine(i.e.,forallvariables).
2.LoopFreePathSegmentisapathsegmentforwhicheverynodeinitisvisitedatmostonce.
ForExample,path(4,5,6,7,8,10)inFigure3.10isloopfree,butpath(10,11,4,5,6,7,8,10,11,12)
isnotbecausenodes10and11areeachvisitedtwice.
3.Simple path segment is a path segment in which at most one node is visited twice. For
example,inFigure3.10,(7,4,5,6,7)isasimplepathsegment.Asimplepathsegmentiseither
loopfreeorifthereisaloop,onlyonenodeisinvolved.
4.A du path from node i to k is a path segment such that if the last link has a computational
useofX,thenthepathissimpleanddefinitionclearifthepenultimate(lastbutone)nodeisj
thatis,thepathis(i,p,q,...,r,s,t,j,k)andlink(j,k)hasapredicateusethenthepathfromito
jisbothloopfreeanddefinitionclear.
STRATEGIES: The structural test strategies discussed below are based on the program's control
flowgraph. They differ in the extent to which predicate uses and/or computational uses of variables are
included in the test set. Various types of data flow testing strategies in decreasing order of their
effectivenessare:
1.All du Paths (ADUP): The alldupaths (ADUP) strategy is the strongest dataflow testing
strategydiscussedhere.Itrequiresthateverydupathfromeverydefinition of every variable
toeveryuseofthatdefinitionbeexercisedundersometest.
For variable X and Y:In Figure 3.9, because variables X and Y are used only on link (1,3),
any test that starts at the entry satisfies this criterion (for variables X and Y, but not for all
variablesasrequiredbythestrategy).
For variable Z: The situation for variable Z (Figure 3.10) is more complicated because the
variable is redefined in many places. For the definition on link (1,3) we must exercise paths
that include subpaths (1,3,4) and (1,3,5). The definition on link (4,5) is covered by any path
that includes (5,6), such as subpath (1,3,4,5,6, ...). The (5,6) definition requires paths that
includesubpaths(5,6,7,4)and(5,6,7,8).
For variable V: Variable V (Figure 3.11) is defined only once on link (1,3). Because V has a
predicate use at node 12 and the subsequent path to the end must be forced for both
directions at node 12, the alldupaths strategy for this variable requires that we exercise all
loopfreeentry/exitpathsandatleastonepaththatincludestheloopcausedby(11,4).Note
that we must test paths that include both subpaths (3,4,5) and (3,5) even though neither of
thesehasVdefinitions.Theymustbeincludedbecausetheyprovidealternatedupathstothe
Vuseonlink(5,6).Although(7,4)isnotusedinthetestsetforvariableV,itwillbeincluded
inthetestsetthatcoversthepredicateusesofarrayvariableV()andU.
The alldupaths strategy is a strong criterion, but it does not take as many tests as it might
seematfirstbecauseanyonetestsimultaneouslysatisfiesthecriterionforseveral definitions
andusesofseveraldifferentvariables.
2.All Uses Startegy (AU):The all uses strategy is that at least one definition clear path from
everydefinitionofeveryvariabletoeveryuseofthatdefinitionbeexercisedundersometest.
Just as we reduced our ambitions by stepping down from all paths (P) to branch coverage
(C2),say,wecanreducethenumberoftestcasesbyaskingthatthetestsetshouldinclude
at least one path segment from every definition to every use that can be reached by that
definition.
For variable V: In Figure 3.11, ADUP requires that we include subpaths (3,4,5) and (3,5) in
some test because subsequent uses of V, such as on link (5,6), can be reached by either
alternative. In AU either (3,4,5) or (3,5) can be used to start paths, but we don't have to use
11/14
12/1/2016
both. Similarly, we can skip the (8,10) link if we've included the (8,9,10) subpath. Note the
hole.Wemustinclude(8,9,10)insometestcasesbecausethat'stheonlywaytoreachthec
use at link (9,10) but suppose our bug for variable V is on link (8,10) after all? Find a
coveringsetofpathsunderAUforFigure3.11.
3.All puses/some cuses strategy (APU+C) : For every variable and every definition of that
variable, include at least one definition free path from the definition to every predicate use if
therearedefinitionsofthevariablesthatarenotcoveredbytheaboveprescription,thenadd
computationalusetestcasesasrequiredtocovereverydefinition.
For variable Z:In Figure 3.10, for APU+C we can select paths that all take the upper link
(12,13) and therefore we do not cover the cuse of Z: but that's okay according to the
strategy's definition because every definition is covered. Links (1,3), (4,5), (5,6), and (7,8)
must be included because they contain definitions for variable Z. Links (3,4), (3,5), (8,9),
(8,10), (9,6), and (9,10) must be included because they contain predicate uses of Z. Find a
covering set of test cases under APU+C for all variables in this example it only takes two
tests.
For
variable
V:In
Figure
3.11,
APU+C
is
achieved
for
V
by
(1,3,5,6,7,8,10,11,4,5,6,7,8,10,11,12[upper],13,2)and(1,3,5,6,7,8,10,11,12[lower],13,2).Note
thatthecuseat(9,10)neednotbeincludedundertheAPU+Ccriterion.
4.Allcuses/somepusesstrategy(ACU+P):Theallcuses/somepusesstrategy(ACU+P)is
tofirstensurecoveragebycomputationalusecasesandifanydefinitionisnotcoveredbythe
previouslyselectedpaths,addsuchpredicateusecasesasareneededtoassurethatevery
definitionisincludedinsometest.
ForvariableZ: In Figure 3.10, ACU+P coverage is achieved for Z by path (1,3,4,5,6,7,8,10,
11,12,13[lower],2),butthepredicateusesofseveraldefinitionsarenotcovered.Specifically,
the(1,3)definitionisnotcoveredforthe(3,5)puse,the(7,8)definitionisnotcoveredforthe
(8,9),(9,6)and(9,10)puses.
The above examples imply that APU+C is stronger than branch coverage but
ACU+Pmaybeweakerthan,orincomparableto,branchcoverage.
5.AllDefinitionsStrategy(AD):Thealldefinitionsstrategyasksonlyeverydefinitionofevery
variablebecoveredbyatleastoneuseofthatvariable,bethatuseacomputationaluseora
predicateuse.
For variable Z: Path (1,3,4,5,6,7,8, . . .) satisfies this criterion for variable Z, whereas any
entry/exitpathsatisfiesitforvariableV.
From the definition of this strategy we would expect it to be weaker than both
ACU+PandAPU+C.
6.All Predicate Uses (APU), All Computational Uses (ACU) Strategies : The all predicate
usesstrategyisderivedfromAPU+Cstrategybydroppingtherequirement that we include a
cuse for the variable if there are no puses for the variable. The all computational uses
strategyisderivedfromACU+Pstrategybydroppingtherequirementthatweincludeapuse
forthevariableiftherearenocusesforthevariable.
It is intuitively obvious that ACU should be weaker than ACU+P and that APU
shouldbeweakerthanAPU+C.
ORDERINGTHESTRATEGIES:
Figure 3.12 compares pathflow and dataflow testing strategies. The arrows denote that the
strategyatthearrow'stailisstrongerthanthestrategyatthearrow'shead.
12/14
12/1/2016
Figure3.12:RelativeStrengthofStructuralTestStrategies.
The righthand side of this graph, along the path from "all paths" to "all statements" is the
moreinterestinghierarchyforpracticalapplications.
Note that although ACU+P is stronger than ACU, both are incomparable to the predicate
biasedstrategies.Notealsothat"alldefinitions"isnotcomparabletoACUorAPU.
SLICINGANDDICING:
A(static)programsliceisapartofaprogram(e.g.,aselectedsetofstatements)definedwith
respecttoagivenvariableX(whereXisasimplevariableoradatavector)andastatementi:
itisthesetofallstatementsthatcould(potentially,understaticanalysis)affectthevalueofX
at statement i where the influence of a faulty statement could result from an improper
computationaluseorpredicateuseofsomeothervariablesatpriorstatements.
IfXisincorrectatstatementi,itfollowsthatthebugmustbeintheprogramsliceforXwith
respecttoi
Aprogramdiceisapartofasliceinwhichallstatementswhichareknowntobecorrecthave
beenremoved.
In other words, a dice is obtained from a slice by incorporating information obtained through
testingorexperiment(e.g.,debugging).
Thedebuggerfirstlimitsherscopetothosepriorstatementsthatcouldhavecausedthefaulty
value at statement i (the slice) and then eliminates from further consideration those
statementsthattestinghasshowntobecorrect.
Debugging can be modeled as an iterative procedure in which slices are further refined by
dicing, where the dicing information is obtained from ad hoc tests aimed primarily at
eliminating possibilities. Debugging ends when the dice has been reduced to the one faulty
statement.
Dynamic slicing is a refinement of static slicing in which only statements on achievable
pathstothestatementinquestionareincluded.
TOP
APPLICATIONOFDATAFLOWTESTING:
TOP
Tobeadded
TOP
13/14
12/1/2016
SUMMARY:
TOP
Themethodsdiscussedforpathtestingofunitsandprogramscanbeappliedwithsuitableinterpretation
tofunctionaltestingbasedontransactionflows.
Thebiggestproblemandthebiggestpayoffmaybegettingthetransactionflowsinthefirstplace.
Full coverage (C1 + C2) is required for all flows, but most bugs will be found on the strange,
meaningless,weirdpaths.
Transactionflow control may be implemented by means of an undeclared and unrecognized internal
language.
Thepracticeofattemptingtodesigntestsbasedontransactionflowrepresentationofrequirementsand
discussingthoseattemptswiththedesignercanunearthmorebugsthananytestsyourun.
Dataareasimportantascodeandwillbecomemoreimportant.
Dataintegrityisasimportantascodeintegrity.Justascommonsensedictatesthatallstatementsand
branchesbeexercisedonundertest,alldatadefinitionsandsubsequentusesmustsimilarlybetested.
Whatconstitutesadataflowanomalyispeculiartotheapplication.Besuretohaveaclearconceptof
dataflowanomaliesinyoursituation.
Use all available tools to detect those anomalies that can be detected statically. Let the extent and
excellence of static dataflow anomaly detection be as important a criterion in selecting a language
processorasproducedobjectcodeefficiencyandcompilationspeed.Usetheslowercompilerthatgives
you slower object code if it can detect more anomalies. You can always recompile the unit after it has
beendebugged.
The dataflow testing strategies span the gap between all paths and branch testing. Of the various
availablestrategies,AUprobablyhasthebestpayoffforthemoney.Itseemstobenoworsethantwice
thenumberoftestcasesrequiredforbranchtesting,buttheresultingcodeismuchmorereliable.AUis
nottoodifficulttodowithoutsupportingtools,butusethetoolsastheybecomeavailable.
Don'trestrictyournotionofdataflowanomalytotheobvious.Thesymbolsd,k,u,andtheassociated
anomalies, can be interpreted (with profit) in terms of file opening and closing, resource management,
andotherapplications.
TOP
2010SureshBabuMudunuri,AssociateProfessor,AdityaEngineeringCollege
14/14

Software Testing Methodologies - Aditya Engineering College 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Testing Methodologies - Aditya Engineering College 1

Uploaded by

Copyright:

Available Formats

12/1/2016

You might also like