software testing techniques (stt)

80
Software Testing Software Testing Techniques Techniques (STT) (STT) Sudhakar yadav Sudhakar yadav Unit 3 – Transaction Flow & Data Flow Unit 3 – Transaction Flow & Data Flow testing testing

Upload: ringo

Post on 21-Jan-2016

98 views

Category:

Documents


2 download

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

TRANSCRIPT

Page 1: Software Testing Techniques     (STT)

Software TestingSoftware TestingTechniquesTechniques

(STT)(STT)

Sudhakar yadavSudhakar yadav

Unit 3 – Transaction Flow & Data Flow testingUnit 3 – Transaction Flow & Data Flow testing

Page 2: Software Testing Techniques     (STT)

Transaction-Flow Testing

ref boris beizer2

We will see in this part of Unit 2:

• Concepts of Transaction flows

• Transaction-flow testing

U2

Page 3: Software Testing Techniques     (STT)

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

Page 4: Software Testing Techniques     (STT)

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

Page 5: Software Testing Techniques     (STT)

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

Page 6: Software Testing Techniques     (STT)

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

Page 7: Software Testing Techniques     (STT)

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

Page 8: Software Testing Techniques     (STT)

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

Page 9: Software Testing Techniques     (STT)

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)

Page 10: Software Testing Techniques     (STT)

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.

Page 11: Software Testing Techniques     (STT)

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.

Page 12: Software Testing Techniques     (STT)

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.

Page 13: Software Testing Techniques     (STT)

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

Page 14: Software Testing Techniques     (STT)

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

Page 15: Software Testing Techniques     (STT)

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.

Page 16: Software Testing Techniques     (STT)

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.

Page 17: Software Testing Techniques     (STT)

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

Page 18: Software Testing Techniques     (STT)

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

Page 19: Software Testing Techniques     (STT)

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

Page 20: Software Testing Techniques     (STT)

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

Page 21: Software Testing Techniques     (STT)

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

Page 22: Software Testing Techniques     (STT)

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

Page 23: Software Testing Techniques     (STT)

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,

Page 24: Software Testing Techniques     (STT)

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

Page 25: Software Testing Techniques     (STT)

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

Page 26: Software Testing Techniques     (STT)

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

Page 27: Software Testing Techniques     (STT)

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

Page 28: Software Testing Techniques     (STT)

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

Page 29: Software Testing Techniques     (STT)

Software Testing Methodology

ref boris beizer29

To Unit 3 : Data flow testing …

U2

Page 30: Software Testing Techniques     (STT)

ref boris beizer30

Data - Flow Testing - BasicsWe will see in this part of Unit 2:

• Concepts of Data flows

• Data-flow testing strategies

U2

Page 31: Software Testing Techniques     (STT)

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

Page 32: Software Testing Techniques     (STT)

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

Page 33: Software Testing Techniques     (STT)

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.

Page 34: Software Testing Techniques     (STT)

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

Page 35: Software Testing Techniques     (STT)

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.

Page 36: Software Testing Techniques     (STT)

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

Page 37: Software Testing Techniques     (STT)

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.

Page 38: Software Testing Techniques     (STT)

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

Page 39: Software Testing Techniques     (STT)

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)

Page 40: Software Testing Techniques     (STT)

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)

Page 41: Software Testing Techniques     (STT)

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

Page 42: Software Testing Techniques     (STT)

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

Page 43: Software Testing Techniques     (STT)

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

Page 44: Software Testing Techniques     (STT)

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

Page 45: Software Testing Techniques     (STT)

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

Page 46: Software Testing Techniques     (STT)

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

Page 47: Software Testing Techniques     (STT)

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

Page 48: Software Testing Techniques     (STT)

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

Page 49: Software Testing Techniques     (STT)

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

Page 50: Software Testing Techniques     (STT)

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

Page 51: Software Testing Techniques     (STT)

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

Page 52: Software Testing Techniques     (STT)

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

Page 53: Software Testing Techniques     (STT)

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

Page 54: Software Testing Techniques     (STT)

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

Page 55: Software Testing Techniques     (STT)

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-

Page 56: Software Testing Techniques     (STT)

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-

Page 57: Software Testing Techniques     (STT)

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

Page 58: Software Testing Techniques     (STT)

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-

Page 59: Software Testing Techniques     (STT)

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

Page 60: Software Testing Techniques     (STT)

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

Page 61: Software Testing Techniques     (STT)

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)

Page 62: Software Testing Techniques     (STT)

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

Page 63: Software Testing Techniques     (STT)

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

Page 64: Software Testing Techniques     (STT)

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.

Page 65: Software Testing Techniques     (STT)

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

Page 66: Software Testing Techniques     (STT)

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

Page 67: Software Testing Techniques     (STT)

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.

Page 68: Software Testing Techniques     (STT)

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

Page 69: Software Testing Techniques     (STT)

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

Page 70: Software Testing Techniques     (STT)

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.

Page 71: Software Testing Techniques     (STT)

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.

Page 72: Software Testing Techniques     (STT)

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..

Page 73: Software Testing Techniques     (STT)

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.

Page 74: Software Testing Techniques     (STT)

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

Page 75: Software Testing Techniques     (STT)

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

Page 76: Software Testing Techniques     (STT)

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

Page 77: Software Testing Techniques     (STT)

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

Page 78: Software Testing Techniques     (STT)

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.

Page 79: Software Testing Techniques     (STT)

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)

Page 80: Software Testing Techniques     (STT)

ref boris beizer80

Data - Flow Testing U-2C

To Unit 4 … Domain Testing