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.