Upload
ringo
View
89
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Software Testing Techniques (STT). Unit 3 – Transaction Flow & Data Flow testing. Sudhakar yadav. Compiled with reference from: Software Testing Techniques: Boris Beizer Craft of Software Testing: Brain Marrick. Transaction-Flow Testing. U2. - PowerPoint PPT Presentation
Citation preview
Software TestingSoftware TestingTechniquesTechniques
(STT)(STT)
Sudhakar yadavSudhakar yadav
Unit 3 – Transaction Flow & Data Flow testingUnit 3 – Transaction Flow & Data Flow testing
Transaction-Flow Testing
ref boris beizer2
We will see in this part of Unit 2:
• Concepts of Transaction flows
• Transaction-flow testing
U2
Transaction-Flow Testing
ref boris beizer3
ContentsContents
1. Definitions of Transaction, Transaction flow, Transaction flow graph2. It’s representation, implementation architecture in an O.S. & implementation in a system3. A perspective of TFG model. View wrt DFG, CFG
4. Handling cases – decisions, biosis, mitosis, transactional junction, absorption & conjugation5. TFG is not structured - Reasons
Transaction Flow Testing Techniques1. Building transaction flows2. Inspections, Reviews, and walkthroughs3. Path selection4. Path sensitization5. Instrumentation6. Test data bases7. Test Execution8. Transaction-flow implementation & testing related comments
1. Translation based systems2. Hidden languages
U2
Definitions of Transaction,Transaction-flow, TFG
ref boris beizer4
Transaction-flow
Transaction-flow represents a system’s processing. Functional testing methods are applied for testing T-F.
Transaction-flow Graph
TFG represents a behavioral (functional) model of the program (system) used for functional testing by an independent system tester.
Transaction
• is a unit of work seen from system’s user point of view.
• consists of a sequence of operations performed by a system, persons or external devices.
• is created (birth) due to an external act & up on its completion (closure), it remains in the form of historical records.
U2
A Simple Transaction
ref boris beizer5
Example: the sequence of steps in a transaction in an online information retrieval system
1. accept inputs 7. Accept Inputs
2. Validate inputs (Birth of tr.) 8. Validate inputs
3. Transmit ack. to the user 9. Process the request
4. Process input 10. Update file
5. Search file 11. Transmit output
6. Request direction from user 12. Record transaction in log & cleanup (Closure)
Users View of a transaction : Single step
Systems view : Sequence of many operations
U2-B
Example of a Transaction flow (diagram)
ref boris beizer6
User (terminal) Terminal controller CPUU2
User User BeginBegin
Request order
from CPU
Request Type
cancel
order
help
AcceptOrder from
CPU
ProcessForm
B
BTransmitPage to terminal
CAcceptInputField
MoreFields?
Y
TransmitTo CPU
D
User wantsReview?D
CPU-AcceptConfirm
Valid ?Y
MorePages ?
NDoneDone
TransmitDiagnosticto Terminal
C
N
Set upReview
Definitions
ref boris beizer7
Transaction-flow Graph : a scenario between users & computer
Transaction-flow : an internal sequence of events in processing a transaction
Uses of Transaction-flow
Specifying requirements of big, online and complicated systems.
Airline reservation systems, air-traffic control systems.
Loops are less as compared to CFG. Loops are used for user input error processing
U2
Implementation of Transaction-Flow (in a system)
ref boris beizer8
U2
• Implicit in the design of system’s control structure & associated database.
• No direct one-to-one correspondence between the “processes” and “decisions” of transaction-flow, and the corresponding program component.
• A transaction-flow is a path taken by the transaction through a succession of processing modules.
• A transaction is represented by a token.
• A transaction-flow graph is a pictorial representation of what happens to the tokens.
Input S A S B S C S S
D
ES : Scheduler A, B, C, D, E : Processes
Output
Implementation of Transaction-Flow
ref boris beizer9
U2
System Control Structure (architecture of the implementation) :
FrontEnd
InputQueue EXECUTIVE
SCHEDULER - AND / OR OPERATING SYSTEMDISPATCHER
OutputModule
OutputQueue
ProcessQueues A Processor B Processor C Processor D Processor E Processor
Application Processes
Do All B’s
Do All D’s
DiscReads
DiscReads
Do All C’s
Do All A’s
TapeWrites
TapeReads
Do All B’s
Do All E’s
DiscWrites
DiscWrites
2
1
1
2
Executive / Dispatcher Flowchart (a sample sequence)
Implementation of Transaction-Flow
ref boris beizer10
U2
System control structureSystem control structure
System is controlled by a scheduler …
A Transaction is created by filling in a Transaction Control Block (TCB) by user inputs and by placing that token on input Q of Scheduler.
Scheduler examines and places it on appropriate process Q such as A. When A finishes with the Token, it places the TCB back on the scheduler Q.
Scheduler routes it to the next process after examining the token :
1. It contains tables or code to route a token to the next process.
2. It may contain routing information only in tables.
3. Scheduler contains no code / data. Processing modules contain code for routing.
Implementation of Transaction-Flow
ref boris beizer11
U2
Transaction Processing SystemTransaction Processing System (simplified):
• There are many Tr. & Tr-flows in the system.
• Scheduler invokes processes A to E as well as disk & tape read & writes.
• The order of execution depends on priority & other reasons.
Cyclic structure like in this example is common in process control & communication systems.
The criteria for implementation mechanism depends on performance and resource optimization.
A perspective of Transaction-Flow
ref boris beizer12
U2
Transaction-flow testing is a block box technique. (as we assumed nothing regarding computer, communications, environment, O.S., transaction identity or structure or state.)
1. TFG is a kind of DFG.
• TFG has tokens, & DFG has data objects with history of operations applied on them.
• Many techniques of CFG apply to TFG & DFG
2. Decision nodes of TFG have exception exits to the central recovery process.
3. So, we ignore the effect of interrupts in a Transaction-flow.
ref boris beizer13
Transaction Flows – splitting & merging decisionsU2-B
Splits of transactions (Births)
1.A decision point in TFG
Alternative 1
Alternative 2
Daughter Tr.
ParentParent
Daughter Tr.
Daughter Tr.Parent
2.Biosis
3.Mitosis
ref boris beizer14
Transaction Flows – splitting & merging decisionsU2
Mergers of transactionsMergers of transactions
1.1. Junction Junction
DaughterParent
Parent
3. Conjugation
Path 2
Path 1
Continue
Daughter Tr.
Predator
Predator
2. Absorption
ref boris beizer15
TFG – splitting, merging TransactionsU2
NOTES:NOTES:
• Multiple meanings now for decision and junction symbols in a TFG.
• Simple TFG model is not enough to represent multi-processor systems & associated coordination systems.
• Petrinet model uses operations for all the above. But Petrinets are applied to H/W, N/W protocol testing – but not Software.
ref boris beizer16
Simplified TFG model U2
Simplify TFG modelSimplify TFG model
• Add New Tr-Flows for Add New Tr-Flows for Biosis, Mitosis, Absorption, ConjugationBiosis, Mitosis, Absorption, Conjugation
• Problems for programmer, designer & test designer.
• Need to design specific tests – possibility of bugs.
ref boris beizer17
Transaction-flow StructureU2-B
Reasons for UnstructurednessReasons for Unstructuredness
1.1. Processes involve Human UsersProcesses involve Human Users
2. Part of Flow from External Systems2. Part of Flow from External Systems
3. Errors, Failures, Malfunctions & Recovery Actions3. Errors, Failures, Malfunctions & Recovery Actions
4. Transaction Count, Complexity. Customer & Environment4. Transaction Count, Complexity. Customer & Environment
ref boris beizer18
Transaction-flow Structure U2-B
Reasons for Unstructuredness …Reasons for Unstructuredness …
5.5. New Transactions, & ModificationsNew Transactions, & Modifications
6.6. Approximation to RealityApproximation to Reality
• Attempt to StructureAttempt to Structure
ref boris beizer19
Transaction - Flow Testing - Steps U2-B
First, Build / Obtain Transaction FlowsFirst, Build / Obtain Transaction Flows
• Represent ExplicitlyRepresent Explicitly
• Design details the Main Tr-FlowsDesign details the Main Tr-Flows
• Create From PDLCreate From PDL
• HIPO charts & Petrinet RepresentationsHIPO charts & Petrinet Representations
Objective – Trace the transactionObjective – Trace the transaction
ref boris beizer20
Transaction - Flow Testing - Steps U2-B
1.1. Inspections, Reviews & WalkthroughsInspections, Reviews & Walkthroughs
Start From Preliminary DesignStart From Preliminary Design
1.1. Conducting WalkthroughsConducting Walkthroughs
• Discuss enough Transaction Types (Discuss enough Transaction Types (98% Transactions))
• User needs & Functional terms User needs & Functional terms (Design independent)
• Traceability to RequirementsTraceability to Requirements
ref boris beizer21
Transaction - Flow Testing - Steps U2-B
1.1. Inspections, Reviews & Walkthroughs …Inspections, Reviews & Walkthroughs …
2.2. Design Tests for C1 + C2 coverageDesign Tests for C1 + C2 coverage
3.3. Additional Coverage (> C1+C2)Additional Coverage (> C1+C2)
• Paths with loops, extreme values, domain boundaries• Weird cases, long & potentially troublesome Tr.
4.4. Design Test cases for Tr. Splits & mergersDesign Test cases for Tr. Splits & mergers
5.5. Publish Selected Test Paths earlyPublish Selected Test Paths early
6.6. Buyer’s Acceptance – functional & acceptance testsBuyer’s Acceptance – functional & acceptance tests
ref boris beizer22
Transaction - Flow Testing Techniques U2-B
2.2. Path SelectionPath Selection
1.1. Covering Set (C1+C2) of Functionally Sensible Tr.Covering Set (C1+C2) of Functionally Sensible Tr.
2.2. Add Difficult PathsAdd Difficult Paths
• Review with designers & implementers
• Exposure of interface problems & duplicated processing
• Very few Implementation bugs may remain
Transaction-flow Path Covering Set belongs inSystem Feature Tests
ref boris beizer23
Transaction - Flow Testing Techniques U2-B
3.3. SensitizationSensitization
1. Functionally Sensible Paths – Simple
2. Error, Exception, External Protocol Interface Paths - Difficult
Testing Tr.–Flows with External Interfaces
• Use patches & break points, mistune, and break the rules,
ref boris beizer24
Transaction - Flow Testing Techniques U2-B
4.4. InstrumentationInstrumentation
1. Link Counters are not Useful.
2. Need
• Trace
• Queues on which Tokens resided
• Entries to & Exits from Dispatcher
• A Running LogMake Instrumentation as part of System Design
ref boris beizer25
Transaction - Flow Testing Techniques U2-B
5.5. Test Data basesTest Data bases
1. Design & Maintenance of a Test Data base - Effort
2. Mistakes
• Unawareness about design of a centrally administered test DB
• Test DB design by Testers
• Using one DB for all tests (need 4 to 5)
Need experienced System & Test Designers
ref boris beizer26
Transaction - Flow Testing Techniques U2-B
6.6. Test ExecutionTest Execution
1. Use Test Execution Automation
2. Have to do a large # of Tests for C1+C2 coverage
ref boris beizer27
Transaction - Flow Testing - Implementation U2-B
1.1. Transaction based systemsTransaction based systems• TCBTCB
1.1. Centralized, Common Processing QueuesCentralized, Common Processing Queues• Just O(n) Queues for Links of O(nJust O(n) Queues for Links of O(n22))
2.2. Transaction DispatcherTransaction Dispatcher• Uses tables & Finite State MachinesUses tables & Finite State Machines
1.1. Recovery & Other LogsRecovery & Other Logs• Key events in Tr – Flow Key events in Tr – Flow
2.2. Self-Test SupportSelf-Test Support• Privileged modes in Transaction control tablesPrivileged modes in Transaction control tables
ref boris beizer28
Transaction - Flow Testing - CautionU2-B
Hidden Languages (flow control language)Hidden Languages (flow control language)
• Transaction Flows based on control codes in TCB or DBTransaction Flows based on control codes in TCB or DB
• Undeclared. Syntax & Semantics are not debugged.Undeclared. Syntax & Semantics are not debugged.
• Possibility of bugsPossibility of bugs
Software Testing Methodology
ref boris beizer29
To Unit 3 : Data flow testing …
U2
ref boris beizer30
Data - Flow Testing - BasicsWe will see in this part of Unit 2:
• Concepts of Data flows
• Data-flow testing strategies
U2
ref boris beizer31
Data - Flow Testing - Basics
Contents
• Synopsis
• Basics• Intro to Data flow, data flow graphs• Motivation & Assumption• Data flow model
• Data Flow Testing Strategies• General strategy• Definitions• Strategies:
• Slicing, Dicing, Data flow, Effectiveness
• Application of DFT, Tools & Effectiveness
U2
ref boris beizer32
Data - Flow Testing - Basics U2
AnomalyAnomaly
Unreasonable processing on dataUnreasonable processing on data
• Use of data object before it is definedUse of data object before it is defined• Defined data object is not usedDefined data object is not used
•Data Flow Testing (DFT) uses Control Flow Graph (CFG) to Data Flow Testing (DFT) uses Control Flow Graph (CFG) to explore dataflow anomalies.explore dataflow anomalies.
• DFT Leads to testing strategies between PDFT Leads to testing strategies between P and P1 / P2 and P1 / P2
ref boris beizer33
Data - Flow Testing - Basics U2
Definition:Definition:
DFT is a family of test strategies based on selecting paths DFT is a family of test strategies based on selecting paths through the program’s control flow in order to explore the through the program’s control flow in order to explore the sequence of events related to the status of data objects.sequence of events related to the status of data objects.
Example:Example:
Pick enough paths to assure that every data item has been initialized Pick enough paths to assure that every data item has been initialized prior to its use, or that all objects have been used for something.prior to its use, or that all objects have been used for something.
ref boris beizer34
Data - Flow Testing - Basics U2
MotivationMotivation
• Confidence in the programConfidence in the program
• Data dominated designData dominated design. . Code migrates to data..
• Source Code for Data DeclarationsSource Code for Data Declarations
• Data flow Machines vs Von Neumann’sData flow Machines vs Von Neumann’s
• Abstract M I M D Abstract M I M D • Language & compiler take care of parallel computationsLanguage & compiler take care of parallel computations
ref boris beizer35
Data - Flow Testing - Basics - Motivation U2
Program Control flow with Von Neumann’s paradigmProgram Control flow with Von Neumann’s paradigm Given m, n, p, q, find eGiven m, n, p, q, find e..
e = (m+n+p+q) * (m+n-p-q)e = (m+n+p+q) * (m+n-p-q)
a := m + na := m + nb := p + qb := p + qc := a + bc := a + bd := a - bd := a - b
e := c * de := c * d
a = n+m
b=p+q
c=a+b
d=a-b
e=c*d
Multiple representations of control flow graphs possible.
ref boris beizer36
Data - Flow Testing - Basics - Motivation U2
Program Flow using Data Flow Machines paradigmProgram Flow using Data Flow Machines paradigm
BEGIN PAR DO
READ m, n, n, p, qEND PARPAR DO
a := m+nb := p+q
END PARPAR DO
c := a+bd := a-b
END PARPAR DO
e := c * dEND PAREND
n m p q
a := m+n b := p+q
c := a+b
The interrelations among the data items remain same.The interrelations among the data items remain same.
d := a-b
e := c * d
ref boris beizer37
Data - Flow Testing - Basics - Motivation U2
•Control flow graphControl flow graph• Multiple representationsMultiple representations
•Data Flow GraphData Flow Graph A spec. for relations among the data objects. A spec. for relations among the data objects.
Covering DFG => Explore all relations under some test.Covering DFG => Explore all relations under some test.
ref boris beizer38
Data - Flow Testing - Basics U2
AssumptionsAssumptions
• Problems in a control flowProblems in a control flow
• Problems with data objectsProblems with data objects
ref boris beizer39
Data - Flow Testing - Basics U2
Data Flow Graphs (DFG)Data Flow Graphs (DFG)
• It is a graph with nodes & directed links
• Test the Von Neumann way - Convert to a CFG
Annotate : program actions (weights)
ref boris beizer40
Data - Flow Testing - Basics U2
Data Object State & UsageData Object State & Usage
Program Actions (d, k, u):Program Actions (d, k, u):
Defined (created)Defined (created) - - explicitly or implicitlyexplicitly or implicitly (d)(d)
Killed (released)Killed (released) - - directly or indirectlydirectly or indirectly (k)(k)
UsedUsed -- (u)(u)
• In a calculation In a calculation -- (c)(c)
• In a predicateIn a predicate -- directly or indirectlydirectly or indirectly (p)(p)
ref boris beizer41
Data - Flow Testing - Basics U2
Data Flow AnomaliesData Flow Anomalies
A Two letter sequence of Actions (d, k, u)A Two letter sequence of Actions (d, k, u)
dddd : : harmless, suspiciousharmless, suspicious
dkdk :: probably a bug.probably a bug.
dudu :: normalnormalkdkd :: normalnormalkkkk :: harmless, but probably a bugharmless, but probably a bug
kuku :: a buga bug
udud :: normal. Redefinition.normal. Redefinition.ukuk :: normalnormaluuuu :: normalnormal
A
Action
ref boris beizer42
Data - Flow Testing - Basics - Motivation U2
Program Flow using Data Flow Machines paradigmProgram Flow using Data Flow Machines paradigm
BEGIN PAR DO
READ m, n, n, p, qEND PARPAR DO
a := m+nb := p+q
END PARPAR DO
c := a+bd := a-b
END PARPAR DO
e := c * dEND PAREND
n m p q
a := m+n b := p+q
c := a+b
The interrelations among the data items remain same.The interrelations among the data items remain same.
d := a-b
e := c * d
ref boris beizer43
Data - Flow Testing - Basics – Data Flow Anomalies U2
Actions on data objectsActions on data objects
-- no action from no action from START to this pointSTART to this pointFrom this point till the From this point till the EXITEXIT
- d- d normalnormal- u- u anomalyanomaly
- k- k anomalyanomaly k-k- normalnormal u -u - normalnormal - possibly an anomaly - possibly an anomaly d -d - possibly anomalouspossibly anomalous
ref boris beizer44
Data - Flow Testing - Basics U2
Data Flow Anomaly State graphData Flow Anomaly State graph
• Data Object StateData Object State
• K, D, U, AK, D, U, A
• Processing StepProcessing Step
• k, d, uk, d, u
ref boris beizer45
Data - Flow Testing - Basics U2
Data Flow Anomaly State graphData Flow Anomaly State graph
• Object stateObject state• Unforgiving Data flow state graphUnforgiving Data flow state graph
K
DU Aud
u
k, u
d, k
d, k, u
d
DefinedUsed
Undefined
Anomalous
ref boris beizer46
Data - Flow Testing - Basics U2
Data Flow Anomaly State graphData Flow Anomaly State graph
Forgiving Data flow state graphForgiving Data flow state graph
K
DU
DD
ud
u
d
d
d
A DD, DK, KU
u
kKU
DK
k
u
u
kd
k
u
k
ref boris beizer47
Data - Flow Testing - Basics U2
Data Flow State GraphsData Flow State Graphs
• Differ in processing of anomaliesDiffer in processing of anomalies
• Choice depends on Choice depends on Application, language, contextApplication, language, context
ref boris beizer48
Data - Flow Testing - Basics U2
Static vs Dynamic Anomaly DetectionStatic vs Dynamic Anomaly Detection
• Static analysis of data flows
• Dynamic analysisIntermediate data valuesIntermediate data values
ref boris beizer49
Data - Flow Testing - Basics U2
Insufficiency of Static Analysis (for Data flow)Insufficiency of Static Analysis (for Data flow)
1. Validation of Dead Variables
2. Validation of pointers in Arrays
3. Validation of pointers for Records & pointers
1. Dynamic addresses for dynamic subroutine calls
2. Identifying False anomaly on an unachievable path
1. Recoverable anomalies & Alternate state graph
2. Concurrency, Interrupts, System Issues
ref boris beizer50
Data - Flow Testing - Basics U2
Data Flow ModelData Flow Model
• Based on CFG
• CFG annotated with program actions
• link weights : dk, dp, du etc..
• Not same as DFG
• For each variable and data object
ref boris beizer51
Data - Flow Testing - Basics : Data Flow Model U2
Procedure to Build:Procedure to Build:
1.1. Entry & Exit nodesEntry & Exit nodes
1.1. Unique node identificationUnique node identification
1.1. Weights on out linkWeights on out link
2.2. Predicated nodesPredicated nodes
3.3. Sequence of linksSequence of links1.1. JoinJoin
2.2. Concatenate weightsConcatenate weights
3.3. The converseThe converse
ref boris beizer52
Data - Flow Testing - Basics : Data Flow Model U2
Example:Example: a an – 1 – 1Z = b + ---------Z = b + ---------
START a - 1 a - 1INPUT a, b, nZ := 0IF a = 1 THEN Z := 1GOTO DONE1r := 1 c := 1POWER:
c := c * ar := r + 1IF r <= n THEN GO TO POWERZ := (c – 1) / (a – 1)
DONE1:Z := b + ZEND
ref boris beizer53
Data - Flow Testing - Basics – Data Flow model U2
CFG for the ExampleCFG for the Example
1 2
3 4
5 6
Read a,b,nZ := 0 Z := 1 Z := b + Z
Z := (c-1)/(a-1)
a = 1?P1
r < n ?
P2
Y
r := 1 c:=1 r := r+1, c:= c*a
Y
ref boris beizer54
Data - Flow Testing - Basics – Data Flow model U2
CFG annotated – Data Flow Model for ZCFG annotated – Data Flow Model for Z
1 2
3 4
5 6d
d or kd cd or ckd
a = 1?P1
r < n ?
P2
Y
Y
d or kd
ref boris beizer55
Data - Flow Testing - Basics – Data Flow model U2
CFG annotated – Data Flow Model for CFG annotated – Data Flow Model for cc
1 2
3 4
5 6
-d
ckd or kd
a = 1?P1
r < n ?
P2
Y
Y
c-
ref boris beizer56
Data - Flow Testing - Basics – Data Flow model U2
CFG annotated – Data Flow Model for CFG annotated – Data Flow Model for rr
1 2
3 4
5 6
-d
ckd or kd
a = 1?P1
r < n ?
P2
Y
Y
p-
ref boris beizer57
Data - Flow Testing - Basics – Data Flow model U2
CFG annotated – Data Flow Model for CFG annotated – Data Flow Model for bb
1 2
3 4
5 6d
a = 1?P1
r < n ?
P2
Y
Y
c
ref boris beizer58
Data - Flow Testing - Basics – Data Flow model U2
CFG annotated – Data Flow Model for CFG annotated – Data Flow Model for nn
1 2
3 4
5 6d
a = 1?P1
r < n ?
P2
Y
Y
p-
ref boris beizer59
Data - Flow Testing - Basics – Data Flow model U2
CFG annotated – Data Flow Model for CFG annotated – Data Flow Model for aa
1 2
3 4
5 6d
a = 1?P1
r < n ?
P2
Y
p
c-
c
ref boris beizer60
Data - Flow Testing - Basics – Data Flow model U2
A DFM for each variable A DFM for each variable Single DFM for multiple variablesSingle DFM for multiple variables
Use weights subscripted with variablesUse weights subscripted with variables
ref boris beizer61
Data - Flow Testing – Data Flow Testing Strategies U2
• A structural testing strategy (path testing)A structural testing strategy (path testing)
• Add, data flow strategies with link weightsAdd, data flow strategies with link weights
• Test path segments to have a ‘d’ (or u, k, du, dk)Test path segments to have a ‘d’ (or u, k, du, dk)
ref boris beizer62
Data - Flow Testing – Data Flow Testing Strategies U2
DEFINITIONSDEFINITIONS
• w.r.t. a variable or data object ‘v’w.r.t. a variable or data object ‘v’• Assume all DF paths are achievableAssume all DF paths are achievable
1.1. Definition-clear path segmentDefinition-clear path segmentno no k, kdk, kd
2.2. Loop-free path segmentLoop-free path segment
2.2. Simple path segmentSimple path segment
3.3. dudu path from node path from node ii to to kk• definition-clear & simple cdefinition-clear & simple c• definition-clear & loop-free pdefinition-clear & loop-free p
ref boris beizer63
Data - Flow Testing – Data Flow Testing Strategies U2
DFT StrategiesDFT Strategies
1.1. All-du paths (ADUP)All-du paths (ADUP)
2.2. All uses (AU) strategyAll uses (AU) strategy
3.3. All p-uses/some c-uses and All c-uses/some p-usesAll p-uses/some c-uses and All c-uses/some p-uses
1.1. All Definitions StrategyAll Definitions Strategy
1.1. All p-uses, All c-uses StrategyAll p-uses, All c-uses Strategy
Purpose:Purpose:
Test Design, Develop Test CasesTest Design, Develop Test Cases
ref boris beizer64
Data - Flow Testing – Data Flow Testing Strategies U2
1.1.All-du paths (ADUP)All-du paths (ADUP)
• Strongest DFTStrongest DFT
• EveryEvery dudu path for every variable for every definition to every use path for every variable for every definition to every use
2.2.All uses (AU) strategyAll uses (AU) strategy
• At least one At least one definition clear path segment from every definition of definition clear path segment from every definition of every variable to every use of that definition be exercised under every variable to every use of that definition be exercised under some test.some test.
• At least one path segment from every definition to every use that can be reached from that definition.
ref boris beizer65
Data - Flow Testing – Data Flow Testing Strategies U2
3.3.All p-uses/some c-uses and All c-uses/some p-All p-uses/some c-uses and All c-uses/some p-usesuses
•APU + cAPU + c
• Stronger than P2Stronger than P2
•ACU + pACU + p
• Weaker than P2Weaker than P2
ref boris beizer66
Data - Flow Testing – Data Flow Testing Strategies U2
4.4.All Definitions Strategy (AD)All Definitions Strategy (AD)
• Cover every definition by Cover every definition by at least oneat least one p or c p or c
• Weaker than ACU + p and APU + cWeaker than ACU + p and APU + c
ref boris beizer67
Data - Flow Testing – Data Flow Testing Strategies U2
5.5.All-Predicate Uses, All-Computational Uses StrategyAll-Predicate Uses, All-Computational Uses Strategy
• APU :APU :
• Include definition-free path for every definition of every variable Include definition-free path for every definition of every variable from the definition to predicate use.from the definition to predicate use.
• ACU :ACU :
• Include for every definition of every variable include at least one Include for every definition of every variable include at least one definition-free path from the definition to every computational definition-free path from the definition to every computational use.use.
ref boris beizer68
Data - Flow Testing – Data Flow Testing Strategies U2
Ordering the strategies Ordering the strategies
All Paths
All du Paths
All-uses Paths (AU)
All-c / some-p (ACU+p)
All c uses (ACU)
All-p / some-c APU+c
All P-uses APU
All Branches P2
All Stmts P1
All Defs AD
ref boris beizer69
Data - Flow Testing – Data Flow Testing Strategies U2
Testing, Maintenance & Debugging in the Data Flow contextTesting, Maintenance & Debugging in the Data Flow context
Slicing:
• A static program A static program sliceslice is a part of a program defined wrt a is a part of a program defined wrt a variable ‘variable ‘vv’ and a statement ‘’ and a statement ‘ss’; It is the set of all statements ’; It is the set of all statements that could affect the value of ‘that could affect the value of ‘vv’ at stmt ‘’ at stmt ‘ss’.’.
Stmt1 var vstmt2Stmt3 var vStmt4 var v
Stmt s var v
ref boris beizer70
Data - Flow Testing – Data Flow Testing Strategies U2
Testing, Maintenance & Debugging in the Data Flow contextTesting, Maintenance & Debugging in the Data Flow context
Dicing:Dicing:
• A program dice is a part of slice in which all stmts. which are known to be correct have been removed.
• Obtained from ‘slice’ by incorporating correctness information from testing / debugging.
ref boris beizer71
Data - Flow Testing – Data Flow Testing Strategies U2
Testing, Maintenance & Debugging in the Data Flow contextTesting, Maintenance & Debugging in the Data Flow context
Debugging:Debugging:
• Select a slice.
• Narrow it to a dice.
• Refine the dice till it’s one faulty stmt.
ref boris beizer72
Data - Flow Testing – Data Flow Testing Strategies U2
Testing, Maintenance & Debugging in the Data Flow contextTesting, Maintenance & Debugging in the Data Flow context
Dynamic Slicing:Dynamic Slicing:
• Refinement of static slicingRefinement of static slicing
• Only achievable paths to the stmt ‘s’ in question are included.Only achievable paths to the stmt ‘s’ in question are included.
Slicing methods bring together testing, maintenance & debugging..
ref boris beizer73
Data - Flow Testing - – Data Flow Testing Strategies U2
Application of DFTApplication of DFT
•Comparison Random Testing, P2, AU - by Ntafos
• AU detects more bugs than
• P2 with more test cases• RT with less # of test cases
•Comparison of P2, AU - by Sneed
• AU detects more bugs with 90% Data Coverage Requirement.
ref boris beizer74
Data - Flow Testing - – Data Flow Testing Strategies U2
Application of DFTApplication of DFT
•Comparison of # test cases for ACU, APU, AU & ADUP
• by Weyuker using ASSET testing system
• Test Cases Normalized. t = a + b * d d = # binary decisions
• At most d+1 Test Cases for P2 loop-free
• # Test Cases / Decision
ADUP > AU > APU > ACU > revised-APU
ref boris beizer75
Data - Flow Testing - – Data Flow Testing Strategies U2
Application of DFTApplication of DFT
Comparison of # test cases for ACU, APU, AU & ADUP by Shimeall & Levenson
Test Cases Normalized. t = a + b * d (d = # binary decisions)
At most d+1 Test Cases for P2 loop-free
# Test Cases / DecisionADUP ~ ½ APU*
AP ~ AC
ref boris beizer76
Data - Flow Testing - – Data Flow Testing Strategies U2
Application of DFTApplication of DFT
DFT vs P1, P2
• DFT is Effective
• Effort for Covering Path Set ~ Same
• DFT Tracks the Coverage of Variables
• Test Design is similar
ref boris beizer77
Data - Flow Testing - – Data Flow Testing Strategies U2
DFT - TOOLSDFT - TOOLS
• Cost-effective development
• Commercial tools :
• Can possibly do Better than Commercial Tools
• Easier Integration into a Compiler
• Efficient Testing
ref boris beizer78
Data - Flow Testing – Questions from the previous year’s exams U2
1. How is data flow testing (DFT) helpful in fulfilling gaps in path testing?
2. Explain the data flow Graphs (DFG).
3. How can anomaly be detected? Explain different types of data flow anomalies and Data flow Anomaly State Graphs.
4. Write applications of Data Flow Testing.
5. Name and explain Data flow testing strategies.
ref boris beizer79
Data - Flow Testing – Questions from the previous year’s exams U2
1. Distinguish Control Flow and Transaction flow. (6 M) *
2. What is meant by transaction flow testing. Discuss its significance. (10 M)*
3. Discuss in detail data - flow testing strategies. (16 M)***
4. What are data - flow anomalies? How data flow testing can explore them? (16M)
5. What are data-flow anomalies? How data flow testing can explore them? (16M)
6. What is meant by a program slice? Discuss about static and dynamic program slicing. (8 M)
7. Explain the terms Dicing, Data-flow and Debugging. (8 M)
8. What is meant by data flow model? Discuss various components of it? (8 M)
9. Compare data flow and path flow testing strategies? (8 M)
10.Explain data-flow testing with an example. Explain its generalizations and limitations.(8 M)
ref boris beizer80
Data - Flow Testing U-2C
To Unit 4 … Domain Testing