path testing

32
PATH TESTING Path Testing is a name given to a family of testing techniques based on judiciously selecting a set of test paths through the program. If the set of paths is properly chosen then we can achieve a measure of test thoroughness. Path Testing is normally used for White box testing, however, nowadays it is also being used for Black box testing techniques as well. It is a structural technique and it requires complete knowledge of program( Source Code). Path Testing is often used by programmers to unit test their own source code.

Upload: api-3774139

Post on 10-Apr-2015

472 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: PATH TESTING

PATH TESTING

• Path Testing is a name given to a family of testing techniques based on judiciously selecting a set of test paths through the program. If the set of paths is properly chosen then we can achieve a measure of test thoroughness.

• Path Testing is normally used for White box testing, however, nowadays it is also being used for Black box testing techniques as well. It is a structural technique and it requires complete knowledge of program( Source Code). Path Testing is often used by programmers to unit test their own source code.

Page 2: PATH TESTING

Procedure for Path testing

• Create a Network Flow Graph• Create a path table • Select appropriate paths

Page 3: PATH TESTING

Control Flow Graphs

Control flow graph is a diagrammatic representation of a network depicting just the paths irrespective of the network elements involved in the network. It helps in selecting the appropriate path.

Page 4: PATH TESTING

Elements of Control Flow Graph

• Process• Decision• Junction

Page 5: PATH TESTING

Process

• Sequence of program statements uninterrupted by either Decisions or Junctions.

• Single Entry / Exit • Consists of single as well as a sequence of statements/

instructions• Also called as Process block

Page 6: PATH TESTING

Decision

• Program point at which central flows can diverge• It consists of decision box and YES and NO.

Page 7: PATH TESTING

Junctions

• Junction is a point in a program flow where central flow can merge.

Page 8: PATH TESTING

DO PROCESS A

PROCESS BLOCK

IF A= B

YES

NO

DECISION BLOCK

1 2

JUNCTIONS

1

2

N

- -CASE OF

FLOW GRAPH ELEMENTS

Page 9: PATH TESTING

Flow Graph VS Flow Chart

A Program’s flowchart resembles control flowgraph; but differs in one important way .In control flow graph, we don’t show the details of what is in process block. The entire block is shown as one entity,

Page 10: PATH TESTING

Fundamentals of Path testing

• Path• Multi Entry/Exit Routines• Path Selection Criteria• Path Testing Criteria

• Path• Multi Entry/Exit Routines• Path Selection Criteria• Path Testing Criteria

Page 11: PATH TESTING

PATH

• Path through a program is a sequence of instructions / statements that starts at an entry point, or junction ,or decision and ends at another or possibly the same junction, decision or Exit

• Path consist of Segments. Path segment is a succession of consecutive Links that belongs to the same path. Length of path is measured by number o f links in it and not by number of instructions/ statements executed along the path.

Page 12: PATH TESTING

Multi Entry/Exit Routines

There might be conditions with multiple Entry/Exit routines.

Page 13: PATH TESTING

PATH SELECTION CRITERIA

• Exercise every path from Entry to Exit• Exercise every statement/ instruction at least once.• Exercise every branch and case statement, in each

direction at least once.

Page 14: PATH TESTING

PATH TESTING CRITERIA

• Path Testing : Execute all possible control

flow paths through the

program• Statement Testing: Execute all statements in the

program at least once .Also

known as Node testing• Branch testing : Execute enough tests to

assure that every branch alternative

has been exercised at least once

under some test.

Page 15: PATH TESTING

SOME COMMON STRATEGIES

• Not testing a piece of code leaves a residue of bugs in the program in proportion to the size of the untested code and probability of bugs.

• High Probability paths are always thoroughly tested to demonstrate that system works properly. If we have to leave any code untested , its always more rational to leave the Normal. High probability paths untested as someone else is sure to exercise them during integration testing or system testing.

• Logic errors are inversely proportional to the probability of path’s execution.

• The subjective probability of executing a path as seen be the routine’s design and its objective execution probability are far apart

• The subjective evaluation of the importance of code segment as judged by its programmer is biased by aesthetic sense, ego and familiarity.

Page 16: PATH TESTING

TESTING A PATH

• Path Flow Graph• Path table

Page 17: PATH TESTING

1BEGIN3 4

5

10 98

6

7

a b c

i

YYY

NO

YES NO

lk

h

d

j

NO

f

YES

NO

ENDYES

e

m

PATH FLOW GRAPH

Page 18: PATH TESTING

PATH TABLE

Path Decision Process Link

abcde Y4 Y6 abcde

abhkde N4 Y6 N9 abhkde

abhlibcde N4 Y4 Y9 abhlibcde

abcdfjdge N4 Y4 Y6 Y7 abcdfjdge

abcdfmibcde Y4 N6 Y6 Y7 abcdfmibcde

Page 19: PATH TESTING

CHECK LIST

• Does every table has YES or NO in its column (C1)• Has every case of all statements been marked (C2)• Is every three way branch (less, equal or greater)

covered (C2)• Is every link (Process) covered at least once (C1)• C1 +C2 should be achieved

Page 20: PATH TESTING

TESTING TACTICS

• Select successive paths as small variations of previous paths.• Try to change only one thing at a time; only one decision’s outcome

if possible.• Its better to have several paths, each differing by only one

parameter rather than one path that covers more than parameters differing which might be highly confusing and can lead to human errors.

• Small changes from path to path mean small easily documented, and gradual changes in the setup.

• Testing is Experimenting: Good experiments rely on changing only one thing at a time.

• The cost of extra paths are few more micro seconds of computer’s time, the time to run an other case, and cost of additional documentation.

Page 21: PATH TESTING

PATH SELECTION

• Pick the simplest, functionally sensible Entry/Exit path.• Pick additional paths as small variations from previous

paths. Pick paths that do not have loops rather than paths that do.

• Favor short paths than long ones; simple over complicated, and sensible paths.

• Pick additional paths that have no obvious functional meaning only if it’s necessary to provide coverage. But ask yourself a question before this why such path was chosen and why a sensible was not capable to achieve this goal.

• Keep digging into the problem untill your reach C1 + C2

Page 22: PATH TESTING

LOOPS – The Pain in the Neck

• Single Loops• Nested Loops• Concatenated Loops

Page 23: PATH TESTING

SINGLE LOOPS

• Single loop, zero minimum, N maximum, No excluded values

• Single Loop, Non zero minimum,No excluded values• Single Loop with excluded values

Page 24: PATH TESTING

SINGLE LOOP, ZERO MINIMUM N MAXIMUM NO EXCLUDED VALUES

• Try bypassing the loop( zero iterations); If you can’t , then either there is a bug or zero is not minimum or we have a wrong case.

• Check whether loop control variable is negative• One pass through the loop• Two passes through the loop• Typical number of iterations unless covered by the previous test• One less than max. no. of iterations• Max. no. of iterations

• Attempt one more than max. no. of iterations. What prevents loop

control variable from having this value.

Page 25: PATH TESTING

HUANG’S THEOREM

• Huang gave a theorem on two passes in a loop• Some data flow anomalies; such as some initialization

problems can be detected by two passes through the loop. The problem occurs when data are initialized within the loop and referenced after leaving the loop. If due to bugs, variable is defined within the loop but is not referenced or used in the loop, only two traversals of the loop would show the double initialization.

Page 26: PATH TESTING

SINGLE LOOP, NON ZERO MINIMUM, NO EXCLUDED VALUES

• Try one less than expected minimum, What happens if the loop control variable is less than the minimum? What prevents the value from being less than the minimum.

• Minimum number of iterations.• One more than minimum number of iterations.• Once, unless covered by the previous test• Twice, unless covered by the previous test• A typical value• One less than typical value• Maximum number of iterations• Attempt more than maximum number of iterations

Page 27: PATH TESTING

SINGLE LOOPS WITH EXCLUDED VALUES

• Treat single loops with excluded values as two sets of tests consisting of loops without excluded values, such as in cases discussed above. Say total range of control variable is 1 to 20, but values 7,8,9,10 are excluded.

• Two sets are 1-6 and 11- 20.test cases to attempt would be 0,1,2,4,6,7 for the first range and 10,11,15,19,20,21

• Similarly, we can also try a value within the excluded range. Say all odd numbers are excluded, we can test the extreme points, for the excluded values, and also for the typical excluded values. If the range is 0-20 and odd values are excluded, try -1,0,1,2,3,10,11,18,19,20,21,22

Page 28: PATH TESTING

NESTED LOOPS-Loop in a Loop

• If we have 5 tests for a single loop( assuming one less than min. and one more than max. is not achievable), then a pair of nested loops would require 25 tests and triplet of nested loops would required 125 tests.

Page 29: PATH TESTING

TACTICS FOR NESTED LOOPS

• Start at the innermost loop and set all outermost loop to their minimum values.

• Test the min. min.+1, typical, max-1, and max. for innermost loop, while holding outer loops at their minimum values. Expand the tests as required for out of range and excluded values.

• If you are done with outermost loop, GOTO step 5,Else move out of one loop and set it up as in step 2 with all other loops set to typical values.

• Perform five cases for all the loop in the nest simultaneously.• This process works out to 12 tests for pair of nested loops, 16 tests

for 3 nested loops and 19 for 4 nested loops. Estimate the processing time for the loop and multiply by the product of loop iteration variables to estimate the time spent in the loop.

Page 30: PATH TESTING

CONCATENATED LOOPS

• These kind of loops fall between single and nested loops w.r.t. test cases. Two loops are concatenated if its possible to reach one after exiting the other while still on a path from entry to exit.

• If loops are not on the same path , they can’t be concatenated and can be treated as individual loops. Even if the loops are on the same path and we are sure that they are independent of each other , they can still be treated as individual loops, but if the iteration values in one loop are directly or indirectly related to iteration values of another loop and they can occur on same path, then they should be treated as Nested Loops.

• The problem of excessive processing time for combinations of loop iteration values should not occur because loop iteration values are additive rather than multiplicative as in nested loops

Page 31: PATH TESTING

LOOP TESTING TIME

• Any kind of loop can lead to long testing times, especially if all extreme values cases ( MAX-1, MAX, MAX+1) are to be attempted. This situation gets worse in nested and dependent concatenated loops.

• In real testing scenario, most tests take a fraction of a second to execute, and even deeply nested tests can be tested in seconds or minutes.

Page 32: PATH TESTING

HORRIBLE LOOPS

At times it becomes very difficult to analyze loops. It’s also difficult at times to see how deeply nested the loops are, or indeed whether there are any nested loops. The use of code that jumps into and out of loops, intersecting loops, hidden loops, and cross connected loops, makes iteration value selection for test cases an awesome and difficult task, which is another reason horrible loops must be avoided.