Software Engineering - PowerPoint PPT Presentation

1 / 25
About This Presentation
Title:

Software Engineering

Description:

... exercise the basis set are guaranteed to execute every statement in the program ... that will fully exercise all the functional requirements for a program. ... – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 26
Provided by: Salv9
Category:

less

Transcript and Presenter's Notes

Title: Software Engineering


1
Software Engineering 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.

2
Software Engineering Software Testing Techniques
  • BLACK BOX AND WHITE BOX TESTING
  • One can test an engineered product by
  • Knowing the specified function that a product was
    designed to perform.
  • 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.
  • Logical paths through the software and
    collaborations between components are tested by
    providing test cases that exercise specific sets
    of conditions and/or loops.

3
Software Engineering Software Testing Techniques
  • BLACK BOX AND 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
  • 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.

4
Software Engineering Software Testing Techniques
  • 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.

5
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • FLOW GRAPH NOTATION
  • A flow graph depicts logical control flow using
    the notation shown below
  • 14.1
  • Each structured construct corresponds to a flow
    graph symbol.

6
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Flow charts and flow graphs correspond to one
    another.
  • The flow chart depicts the program control
    structure.
  • The flow graph assumes no compound structures.

7
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Flow charts and flow graphs correspond to one
    another.
  • Each circle, called a flow graph node, represents
    one 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.

8
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Compound Conditions
  • Compound Conditions occur when one or more
    Boolean operators (OR, AND, NAND, NOR) is/are
    present in a conditional statement.
  • IF A OR B is represented as follows
  • FIGURE 14.3

9
Software Engineering Software Testing Techniques
  • 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.
  • 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

10
Software Engineering Software Testing Techniques
  • 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?

11
Software Engineering Software Testing Techniques
  • 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.
  • Cyclomatic complexity is computed a number of
    ways
  • The number of regions corresponds to the
    cyclomatic complexity.
  • Cyclomatic complexity, V(G), for a flow graph G,
    is defined asV(G) E N 2, where E is the
    number of flow graph edges, and N is the number
    of flow graph nodes.
  • Cyclomatic complexity, V(G), for a flow graph G,
    is defined asV(G) P 1,where P is the
    number of predicate nodes contained in the flow
    graph G.

12
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • The flow graph has 4 regions.
  • V(G) 11 edges 9 nodes 2 4
  • 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.

13
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Deriving 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.

14
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Figure 14.4

15
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Figure 14.5
  • V(G) 6 regions
  • V(G) 17 edges 13 nodes 2 6
  • V(G) 5 predicate nodes 1 6

16
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • 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

17
Software Engineering Software Testing Techniques
  • BASIS PATH TESTING
  • Prepare test cases that will force execution of
    each path in the basis set.

18
Software Engineering Software Testing Techniques
  • CONTROL STRUCTURE TESTING
  • Condition Testing
  • Condition Testing is a test case design method
    that exercises the logical conditions contained
    in a program module.
  • A simple condition is a Boolean variable or a
    relational expression, possibly preceded with one
    NOT operator. A relational expression takes the
    form
  • E1 ltrelational-operatorgt E2
  • Where E1 and E2 are arithmetic expressions and
    ltrelational-operatorgt is one of the following lt,
    lt, , ltgt, gt or gt.
  • A compound condition is composed of two or more
    simple conditions, Boolean operators, and
    parentheses.
  • Boolean operators allowed in a compound condition
    include OR, AND, and NOT.
  • Errors are much more common in the neighborhood
    of logical conditions than they are in the locus
    of sequential programming

19
Software Engineering Software Testing Techniques
  • CONTROL STRUCTURE TESTING
  • Loop Testing
  • Four different classes of loops
  • Figure 14.7

20
Software Engineering Software Testing Techniques
  • CONTROL STRUCTURE TESTING
  • Simple Loops The following tests should be
    performed for simple loops, where n is the
    maximum number of allowable passes through the
    loop.
  • Skip the loop entirely
  • Only one pass through the loop
  • Two passes through the loop
  • M passes through the loop where m lt n
  • N-1, n, n1 passes through the loop

21
Software Engineering Software Testing Techniques
  • CONTROL STRUCTURE TESTING
  • 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
  • Start at the innermost loop. Set all other loops
    to their minimum values.
  • Conduct simple loop tests for the innermost loop
    while holding the outer loops at their minimum
    iteration parameter. Add other tests for
    out-of-range or excluded values.
  • 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.
  • Continue until all loops have been tested.

22
Software Engineering Software Testing Techniques
  • 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.

23
Software Engineering Software Testing Techniques
  • BLACK BOX TESTING
  • Black box testing is also called behavioral
    testing.
  • Black box testing focuses on the functional
    requirements of software.
  • Black box testing consists of a set of input
    conditions that will fully exercise all the
    functional requirements for a program.

24
Software Engineering Software Testing Techniques
  • BLACK BOX TESTING
  • Equivalence Partitioning
  • EP divides the input domain of a program into
    classes of data from which test cases can be
    derived.
  • An ideal test case single handedly uncovers a
    class of errors that might otherwise require many
    cases to be executed before the general error is
    observed.
  • An equivalence class represents a set of valid or
    invalid states for input conditions.
  • Equivalence classes may be defined according to
    the following guidelines
  • If an input condition specifies a range, one
    valid and two invalid equivalence classes are
    defined.
  • If an input condition specifies a specific value,
    one valid and two invalid equivalence classes are
    defined.
  • If an input condition specifies a member of a
    set, one valid and one invalid equivalence class
    are defined.
  • If an input condition is Boolean, one valid and
    one invalid class are defined.

25
Software Engineering Software Testing Techniques
  • BLACK BOX TESTING
  • Boundary Value Analysis
  • A great number of errors occur at the boundaries
    of the input domain rather that in the center
  • Boundary value analysis is a test case technique
    that compliments equivalence partitioning.
    Rather than selecting any element of the
    equivalence class, BVA leads to the selection of
    test cases at the edges of the class.
  • Guidelines are as follows
  • If an input condition specifies a range bounded
    by values a and b, test cases should be designed
    with values a and b as well as just above and
    just below a and b.
  • If an input condition specifies a number of
    values, test cases should be developed that
    exercise the minimum and maximum numbers.
  • If internal program data structures have
    prescribed boundaries (e.g. an array has a
    defined limit of 100 entries), be certain to
    design a test case to exercise the data structure
    at its boundaries.
Write a Comment
User Comments (0)
About PowerShow.com