Learning objectives • Understand why data flow criteria have been designed and used • Recognize and distinguish basic DF criteria Data flow testing – All DU pairs, all DU paths, all definitions • Understand how the infeasibility problem impacts data flow testing • Appreciate limits and potential practical uses of data flow testing (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 1 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 2 Motivation Data flow concept • Middle ground in structural testing 1 x = .... – Node and edge coverage don’t test interactions • Value of x at 6 could be – Path-based criteria require impractical number of 2 if .... computed at 1 or at 4 test cases 3 • Bad computation at 1 or 4 • And only a few paths uncover additional faults, anyway .... x = .... 4 could be revealed only – Need to distinguish “important” paths 5 if they are used at 6 ... • Intuition: Statements interact through data • (1,6) and (4,6) are flow 6 y = x + ... def-use (DU) pairs – Value computed in one statement, used in another – defs at 1,4 – Bad value computation revealed only when it is used – use at 6 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 3 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 4
Terms Definition-clear path • DU pair: a pair of definition and use for some • 1,2,3,5,6 is a definition- clear path from 1 to 6 1 variable, such that at least one DU path exists x = .... – x is not re-assigned from the definition to the use between 1 and 6 2 if .... x = ... is a definition of x • 1,2,4,5,6 is not a 3 = ... x ... is a use of x 4 definition-clear path .... x = .... from 1 to 6 • DU path: a definition-clear path on the CFG 5 ... – the value of x is “killed” starting from a definition to a use of a same (reassigned) at node 4 variable 6 y = x + ... • (1,6) is a DU pair because – Definition clear: Value is not replaced on path 1,2,3,5,6 is a definition- – Note – loops could create infinite DU paths between clear path a def and a use (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 5 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 6 Adequacy criteria Difficult cases • All DU pairs: Each DU pair is exercised by at • x[i] = ... ; ... ; y = x[j] least one test case – DU pair (only) if i==j • All DU paths: Each simple (non looping) DU path • p = &x ; ... ; *p = 99 ; ... ; q = x is exercised by at least one test case – *p is an alias of x • All definitions: For each definition, there is at • m.putFoo(...); ... ; y=n.getFoo(...); least one test case which exercises a DU pair – Are m and n the same object? containing it – Do m and n share a “foo” field? – (Every computed value is used somewhere) Corresponding coverage fractions can also be • Problem of aliases : Which references are defined (always or sometimes) the same? (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 7 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 8
Infeasibility Data flow coverage with complex structures • Arrays and pointers are critical for data flow analysis • Suppose cond has not changed between 1 and 5 1 – Under-estimation of aliases may fail to include some DU pairs if ( cond ) – Over-estimation, on the other hand, may introduce unfeasible • Or the conditions could be different, but the first test obligations 3 2 .... x = .... implies the second • For testing, it may be preferrable to accept under- • Then (3,5) is not a 4 estimation of alias set rather than over-estimation or ... (feasible) DU pair expensive analysis 5 • But it is difficult or if ( cond ) – Controversial: In other applications (e.g., compilers), a impossible to determine conservative over-estimation of aliases is usually required which pairs are infeasible 6 7 y = x + ... .... – Alias analysis may rely on external guidance or other global • Infeasible test analysis to calculate good estimates obligations are a problem – Undisciplined use of dynamic storage, pointer arithmetic, etc. • No test case can cover may make the whole analysis infeasible them (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 9 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 10 Infeasibility Summary • The path-oriented nature of data flow analysis • Data flow testing attempts to distinguish makes the infeasibility problem especially “important” paths: Interactions between relevant statements – Combinations of elements matter! • Intermediate between simple statement and branch coverage and more expensive path-based structural testing – Impossible to (infallibly) distinguish feasible from • Cover Def-Use (DU) pairs: From computation of infeasible paths. More paths = more work to check value to its use manually. • In practice, reasonable coverage is (often, not • Intuition: Bad computed value is revealed only when it is used always) achievable • Levels: All DU pairs, all DU paths, all defs (some use) – Number of paths is exponential in worst case, but • Limits: Aliases, infeasible paths often linear • Worst case is bad (undecidable properties, exponential – All DU paths is more often impractical blowup of paths), so pragmatic compromises are required (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 11 (c) 2007 Mauro Pezzè & Michal Young Ch 13, slide 12
Recommend
More recommend
