vu-sqa-lecture26 of principle of management.ppt

Management

1. 1
Software Testing –4 –WBT
Techniques
Lecture # 26
1

2. 2
Recap
Discussed black-box testing and white-box
testing, and spent some time talking about
their differences with respect to
perspective, objects, timeline, defect
focus, defect detection and fixing,
techniques, and testers
2

3. 3
Today’s Lecture
We’ll have some more discussion on
white-box testing
Specifically, we’ll talk about different white-
box testing techniques
3

4. 4
As you know, white-box testing deals with
that form of software testing, where code
or programs are available for review,
understanding, and flow of control and
data are visible
Let’s first ask a question about white-box
testing

5. 5
White-box Testing Question
Why spend time and energy worrying
about (and testing) logical details when we
might better expend effort ensuring
requirements have been met? or
Why don’t we spend all of our energy on
black-box tests?

6. 6
Answers to that Question
Logical errors and incorrect assumptions
are inversely proportional to probability
that a program path will be executed
We often believe that a logical path is not
likely to be executed when, in fact, it may
be executed on a regular basis
Typographical errors are random, it’s likely
that untested paths will contain some
6

7. 7
White-box testing uses the control
structure of the procedural design to
derive test cases

8. 8
WBT Methods Derive Test
Cases
Guarantee that all independent paths within a
module have been exercised at least once
Exercise all logical decisions on their true and
false sides
Execute all loops at their boundaries and
within their operational bounds
Exercise internal data structures to ensure
their validity

9. 9
White-Box Testing Techniques
Basis path testing
Condition testing
Data flow testing
Loop testing
9

10. 10
Basis Path Testing -1
Basis path testing is a white-box testing
technique first proposed by Tom McCabe
It enables the test case designer to derive
a logical complexity measure of a
procedural design and use this measure
as a guide for defining a basis set of
execution paths
10

11. 11
Basis Path Testing -2
Test cases derived to exercise basis set
are guaranteed to execute every
statement in the program at least once
Basis path testing uses cyclomatic
complexity, which is a software metric that
provides a quantitative measure of the
logical complexity of a program
11

12. 12
Basis Path Testing -3
When the cyclomatic complexity used in
the context of the basis path testing
method, the value computed for
cyclomatic complexity defines the number
of independent paths in the basis set of a
program and provides us with an upper
bound for the number of tests that must be
conducted to ensure that all statements
have been executed at least once
12

13. 13
An independent path is any path through
the program that introduces at least one
new set of processing statement or a new
condition
The cyclomatic complexity can be
calculated in a number of ways
13

14. 14
Number of simple decisions + 1
or
Number of enclosed areas + 1
In this case, V(G) = 4
Cyclomatic Complexity

15. 15
Cyclomatic complexity can also be
calculated by developing flow graph (or
program graph), which depicts the logical
control flow
A flow graph primarily consist of edges
and nodes
15

16. 16
A flow graph depicts logical control flow of
a program, and contains notation for
Sequences
If conditions
While conditions
Until statements
Case statements

17. 17
Flow Graph Notation

18. 18
If we are using flow graph graphs, the
cyclomatic complexity is calculated as
V(G) = Edges –Nodes + 2

19. 19
Steps in Basis Path Testing to
Derive Test Cases
Using the design or code as a foundation,
draw a corresponding flow graph
Determine the cyclomatic complexity of
the resultant flow graph
Determine a basis set of linearly
independent paths
Prepare test cases that will force
execution of each path in the basis set
19

20. 20
Since V(G) = 4,
there are four paths
Path 1: 1,2,3,6,7,8
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
Finally, we derive test
cases to exercise these
paths.
1
2
3
4
5 6
7
8
Finding Independent Paths

21. 21
Conditional Testing

22. 22
Condition Testing -1
Condition testing is a test case design
method that exercises the logical
conditions contained in a program module
Conditions can be
Simple conditions
Relational expressions
Compound conditions
22

23. 23
Condition Testing -2
Errors are much more common in the
neighborhood of logical conditions than
they are in the locus of sequential
procession statements
The condition testing method focuses on
testing each condition in the program
23

24. 24
Condition Testing -3
If a condition is incorrect, then at least one
component of the condition is incorrect,
therefore, types of errors in a condition
include the following
Boolean operator error
Boolean variable error
Relational operator error
Arithmetic expression error
24

25. 25
Condition Testing -4
The purpose is to detect errors in the
conditions of a program but other errors
also
25

26. 26
Condition Testing -5
There are two advantages of condition
testing
Measurement of test coverage of a condition
is simple
Test coverage of conditions in a program
provides guidance for the generation of
additional tests for the program

27. 27
Condition Testing Strategies
Branch testing
For a compound condition, C, the true and
false branches of C and every simple
condition in C need to be executed at least
once
Domain testing
Testing related to relational operators
BRO (branch and relational operator)
testing
27

28. 28
Data Flow Testing
The data flow testing method selects test
paths of a program according to the
locations of definitions and uses of
variables in the program
Data flow testing strategies are useful for
selecting test paths of a program
containing nested if and loop statements

29. 29
Loop Testing

30. 30
Loop Testing -1
Loops are the cornerstone for the vast
majority of all algorithms implemented in
software, and yet, we often them little
heed while conducting software tests
Complex loop structures are another
hiding place for bugs. It’s well worth
spending time designing tests that fully
exercise loop structures
30

31. 31
Loop Testing -2
It is a white-box testing technique that
focuses exclusively on the validity of loop
constructs
Four different classes of loops can be
defined
Simple loop
Concatenated loops
Nested loops
Unstructured loops
31

32. 32
Loop Testing
Nested
Loops
Concatenated
Loops Unstructured
Loops
Simple
loop

33. 33
Loop Testing: Simple
Loops
Minimum conditions—Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes

34. 34
Loop Testing: Nested Loops
Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.
Move out one loop and set it up as in step 2, holding all
other loops at typical values. Continue this step until
the outermost loop has been tested.
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is
used to initialize loop 2.
Nested Loops
Concatenated Loops

35. 35
Summary
In today’s lecture, we have discussed
white-box testing techniques in quite a bit
of detail
35

36. 36
References
Software Engineering: A Practitioner’s
Approach by Roger S. Pressman (Chapter
17.3-17.5)
36