CS 451 Software Engineering Winter 2009 Yuanfang Cai Room 104, - - PowerPoint PPT Presentation

cs 451 software engineering winter 2009
SMART_READER_LITE
LIVE PREVIEW

CS 451 Software Engineering Winter 2009 Yuanfang Cai Room 104, - - PowerPoint PPT Presentation

CS 451 Software Engineering Winter 2009 Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 1 Drexel University Software Testing Techniques FUNDAMENTALS The goal of testing is to find errors. A good


slide-1
SLIDE 1

1

Drexel University

CS 451 Software Engineering Winter 2009

1

Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu

slide-2
SLIDE 2

Drexel University

Software Testing Techniques

 FUNDAMENTALS

 The goal of testing is to find errors.  A good test is one that has a high probability of finding

an error.

 A good test is not redundant  A good test should be neither too simple nor to

complex.

slide-3
SLIDE 3

Drexel University

Black Box and White Box Testing

One can test an engineered product by:

1. Knowing the specified function that a product was designed to perform. 2. Knowing the internal workings of a product 

Black box testing alludes to tests that are conducted at the software interface.

A black box test examines some fundamental aspect of a system with little regard for the internal structure of the software.

White-box testing of software is predicated on close examination of procedural detail.

slide-4
SLIDE 4

Drexel University

White Box Testing

slide-5
SLIDE 5

Drexel University

White Box Testing

White box testing is sometimes called glass box testing.

White box testing uses the control structure described as part of the component level design to derive test cases.

Using white box testing methods, the software engineer can derive test cases that:

1. guarantee that all independent paths within a module have been exercised at least once. 2. exercise all logical decisions on their true and false sides. 3. execute all loops at their boundaries and within their

  • perational bounds

4. exercise internal data structures to ensure their validity.

slide-6
SLIDE 6

Drexel University

Code Coverage

 Method Coverage  Statement Coverage  Branch Coverage  Condition Coverage

slide-7
SLIDE 7

Drexel University

Method Coverage

 All methods have been called  Test Case 1: f(0, 0, 0) = 0

float f(int a, int b, int c) { if (a == 0) return 0; int x = b / a; if ((a == b || b == c) && (x != c)) x = -c; return 1.f / x; }

slide-8
SLIDE 8

Drexel University

Statement Coverage

 All “statements” have been executed  Test Case 1: f(1, 1, 1) = -1

float f(int a, int b, int c) { if (a == 0) return 0; int x = b / a; if ((a == b || b == c) && (x != c)) x = -c; return 1.f / x; }

slide-9
SLIDE 9

Drexel University

Branch Coverage

 All branches have been taken at least once  Test Case 1: f(1, 0, 0) = NaN

float f(int a, int b, int c) { if (a == 0) return 0; int x = b / a; if ((a == b || b == c) && (x != c)) x = -c; return 1.f / x; }

slide-10
SLIDE 10

Drexel University

Condition Coverage

 All predicates have been both true and false  Test Case 1: f(1, 1, 2) = -0.5

float f(int a, int b, int c) { if (a == 0) return 0; int x = b / a; if ((a == b || b == c) && (x != c)) x = -c; return 1.f / x; }

slide-11
SLIDE 11

Drexel University

Basis Path Testing

The basis path method 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.

Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

slide-12
SLIDE 12

Drexel University

Basis Path Testing

FLOW GRAPH NOTATION

A flow graph depicts logical control flow using the notation shown below:

Each structured construct corresponds to a flow graph symbol.

slide-13
SLIDE 13

Drexel University

Basis Path Testing

Flow charts and flow graphs correspond to

  • ne another

The flow chart depicts the program control structure.

The flow graph assumes no compound structures.

slide-14
SLIDE 14

Drexel University

Basis Path Testing

Flow Graph

Each circle, called a flow graph node, represents

  • ne or more procedural statements.

A sequence of process boxes and a decision diamond can map to a single node.

The arrows of a flow graph, called edges or links, represent flow of control.

An edge must terminate at a node.

Areas bounded by edges are called regions.

slide-15
SLIDE 15

Drexel University

Basis Path Testing

Flow Chart Flow Graph

slide-16
SLIDE 16

Drexel University

Basis Path Testing

Compound Conditions

Compound Conditions occur when one or more Boolean

  • perators (OR, AND, NAND, NOR) is/are present in a

conditional statement.

IF A OR B is represented as follows:

Compound Logic:

slide-17
SLIDE 17

Drexel University

Basis Path Testing

Independent Program Paths

An independent program path is any path through the program that introduces at least one new set of processing statements or a new condition.

When stated in terms of a flow graph, an independent path must move along at least one edge that has not been traversed before the path is defined.

slide-18
SLIDE 18

Drexel University

Basis Path Testing

For example, a set of independent paths for the flow graph illustrated in Figure 14.2b is:

Path 1: 1-11

Path 2: 1-2-3-4-5-10-1-11

Path 3: 1-2-3-6-8-9-10-1-11

Path 4: 1-2-3-6-7-9-10-1-11

Each new path introduces a new

  • edge. Note the following path is

not independent:

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

slide-19
SLIDE 19

Drexel University

Basis Path Testing

A basis set for a flow graph is the set of paths that cover every statement in the program.

Therefore Paths 1, 2, 3, & 4 are the basis set for the previous figure.

If tests are designed to force execution of these paths, every statement is guaranteed to execute at least one

  • time. Every condition will have been executed on its

true and false sides.

Note, a basis set is not unique. A number of basis sets may be derived from a procedural design.

How do we know how many paths to look for?

slide-20
SLIDE 20

Drexel University

Basis Path Testing

Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program.

When 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 an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.

slide-21
SLIDE 21

Drexel University

Basis Path Testing

Cyclomatic complexity is computed a number of ways:

1. The number of regions corresponds to the cyclomatic complexity. 2. Cyclomatic complexity, V(G), for a flow graph G, is defined as: V(G) = E – N + 2, where E is the number of flow graph edges, and N is the number of flow graph nodes. 3. Alternatively: V(G) = P + 1, where P is the number of predicate nodes contained in the flowchart G.

slide-22
SLIDE 22

Drexel University

Basis Path Testing

Cyclomatic Complexity

1. The flow graph has 4 regions. 2. V(G) = 11 edges – 9 nodes +2 = 4 3. V(G) = 3 predicate nodes + 1 = 4

Often components with a high V(G) are a high risk for error and should be tested more completely.

slide-23
SLIDE 23

Drexel University

Basis Path Testing

Deriving Test Cases

1. Using the design or code as a foundation, draw a corresponding flow graph. 2. Determine the cyclomatic complexity of the resultant flow graph. 3. Determine a basis set of linearly independent paths. 4. Prepare test cases that will force execution of each path in the basis set.

slide-24
SLIDE 24

Drexel University

Basis Path Testing

Figure 14.4

slide-25
SLIDE 25

Drexel University

slide-26
SLIDE 26

Drexel University

Basis Path Testing

Figure 14.4

V(G) = 6 regions

V(G) = 17 edges – 13 nodes + 2 = 6

V(G) = 5 predicate nodes + 1 = 6

Paths:

Path 1: 1-2-10-11-13

Path 2: 1-2-10-12-13

Path 3: 1-2-3-10-11-13

Path 4: 1-2-3-4-5-8-9-2-…

Path 5: 1-2-3-4-5-6-7-8-2….

Path 6: 1-2-3-4-5-6-7-8-9-2… Prepare test cases that will force execution of each path in the basis set.

slide-27
SLIDE 27

Drexel University

Dealing With Loops

 Look for test cases to:

 Skip loop entirely  Go through loop once  Go through loop more than once

slide-28
SLIDE 28

Drexel University

Control Structure Testing

Four different classes of loops:

slide-29
SLIDE 29

Drexel University

Control Structure Testing

Four different classes of loops:

Simple Loops: The following tests should be performed for simple loops, where n is the maximum number of allowable passes through the loop.

1. Skip the loop entirely 2. Only one pass through the loop 3. Two passes through the loop 4. M passes through the loop where m < n 5. N-1, n, n+1 passes through the loop

slide-30
SLIDE 30

Drexel University

Control Structure Testing

Four different classes of loops:

Nested Loops:

If we extended the simple loop test cases to nested loops, the number of tests would grow geometrically.

Instead use the following scheme:

1. Start at the innermost loop. Set all other loops to their minimum values. 2. Conduct simple loop tests for the innermost loop while holding the

  • uter loops at their minimum iteration parameter. Add other tests

for out-of-range or excluded values. 3. Work outward, conducting tests for the next loop, but keeping all the other outer loops at minimum values and other nested loops to “typical” values. 4. Continue until all loops have been tested.

slide-31
SLIDE 31

Drexel University

Control Structure Testing

Concatenated Loops

Concatenated loops can be tested using the approach defined for simple loops, if each of the loops is independent of each other.

If the two loops are concatenated and the loop counter for loop 1 is used as an initial value of loop 2, then the loops are not independent.

Unstructured Loops

Whenever possible, this class of loops should be redesigned to reflect the use of the structured programming constructs.

slide-32
SLIDE 32

Drexel University

Summary

 Flow graph vs. Flow chart  Cyclomatic Complexity  Independent Path  Code Coverage  Test cases