Path selection criteria

transcript

Tor Stålhane & ‘Wande Daramola

Why path selection criteria

Doing white box testing (Control flow testing, data flow testing, coverage testing) using the test-all-paths strategy can be a tedious and expensive affair. The strategies discussed here are alternative ways to reduce the number of paths to be tested.

As with all white box tests, it should only be used for small chunks of code – less than say 200 lines.

• Data flow testing is a powerful tool to detect improper use of data values due to coding errors.

main() {

int x;

if (x==42){ ...}

Data flow testing -1

• Variables that contain data values have a defined life cycle. They are created, they are used, and they are killed (destroyed) - Scope{ // begin outer block

int x; // x is defined as an integer within this outer block …; // x can be accessed here { // begin inner block

int y; // y is defined within this inner block ...; // both x and y can be accessed here

} // y is automatically destroyed at the end of this block ...; …; // x can still be accessed, but y is gone

} // x is automatically destroyed

Data flow testing -2

• Variables can be used – in computation – in conditionals

• Possibilities for the first occurrence of a variable through a program path – ~d the variable does not exist, then it is defined (d)– ~u the variable does not exist, then it is used (u)– ~k the variable does not exist, then it is killed or

destroyed (k)

Static data flow testing

define, use, kill (duk) – 1

We define three usages of a variable:

• d – define the variable

• u – use the variable

• k – kill the variable.

A large part of those who use this approach will only use define and use – du.

Based on the usages we can define a set of patterns potential problems.

duk – 2 We have the following nine patterns:• dd: define and then define again – error• dk: define and then kill – error• ku: kill and then used – error • kk: kill and then kill again – error • du: define and then use – OK • kd: kill and then redefine – OK • ud: use and then redefine – OK• uk: use and then kill – OK • uu: use and then use – OK

Example: Static data flow testing

For each variable within the module we will examine define-use-kill patterns along the control flow paths

Example cont’d: Consider variable x as we traverse the left and then the right path

~define correct, the normal casedefine-define suspicious, perhaps a programming errordefine-use correct, the normal case

ddu du

duk examples (x) – 1

Define x

Define xUse x

Define x

Define xUse x

Use x Use x

~use major blunderuse-define acceptabledefine-use correct, the normal caseuse-kill acceptable

Example Cont’d: Consider variable y

uduk udk

duk examples (y)- 2

Define y

Kill y

udukudk

~kill programming error

kill-use major blunder

use-use correct, the normal case

use-define acceptable

kill-kill probably a programming error

kill-define acceptable

define-use correct, the normal case

kuuud kkduud

Example Cont’d: Consider variable z

duk examples (z) - 3

Kill z

Use zUse z Kill z

Define z Kill zDefine z

Define zDefine z

Kill z

Use zUse z

kuuudkkduud

Use zUse z

Dynamic data flow testingTest strategy – 1

Based on the three usages we can define a total of seven testing strategies. We will have a quick look at each

• All definitions (AD): test cases cover each definition of each variable for at least one use of the variable.

• All predicate-uses (APU): there is at least one path of each definition to p-use of the variable

Test strategy – 2 • All computational uses (ACU): there is at

least one path of each variable to each c-use of the variable

• All p-use/some c-use (APU+C): there is at least one path of each variable to each c-use of the variable. If there are any variable definitions that are not covered then cover a c-use

Test strategy – 3

• All c-uses/some p-uses (ACU+P): there is at least one path of each variable to each c-use of the variable. If there are any variable definitions that are not covered then cover a p-use.

• All uses (AU): there is at least one path of each variable to each c-use and each p-use of the variable.

Test strategy – 4

• All du paths (ADUP): test cases cover every simple sub-path from each variable definition to every p-use and c-use of that variable.

Note that the “kill” usage is not included in any of the test strategies.

Application of test strategies – 1

Define x

Define xc-use xc-use z

Kill zc-use xDefine z

p-use yKill z

Define yp-use z

c-use c-use z

Kill yDefine z

All definitionsAll c-use

Define x

p-use yKill z

Define yp-use z

c-use c-use z

Kill yDefine z

All p-use

Application of test strategies – 2

Define x

p-use yKill z

Define yp-use z

c-use c-use z

Kill yDefine z

ACUAPU+C

Relationship between strategiesAll paths

All du-paths

All uses

All c/some p All p/some c

All c-uses

All p-uses

All defs

Branch

Statement The higher up in the hierarchy, the better is thetest strategy

Acknowledgement

The material on the duk patterns and testing strategies are taken from a presentation made by L. Williams at the North Carolina State University.

Available at: http://agile.csc.ncsu.edu/testing/DataFlowTesting.pdf

Path selection criteria

Documents