Testing the programs II Defect testing

1
Testing the programs II - Defect testing
2
What is defect testing?

• This testing is intended to exercise a system so
  that latent defects are exposed before the system
  is delivered.
• A successful defect test is a test which causes
  the system to perform incorrectly and hence
  exposes a defect.

3
What is defect testing?(2)

• Test data inputs which have been devised to
  test the system.
• Test cases input and output specifications plus
  a statement of the function under test.
• Three approaches
• Functional or black-box testing
• Structural or white-box testing
• Interface testing

4
Black-box testing

• System is a black box whose behavior can only
  be determined by studying its inputs and the
  related outputs
• The key problem is to select inputs that have a
  high probability of causing anomalous behavior.

5
Equivalence Partitioning

• The classes of data should meet these criteria
• Every possible input belongs to one of the
  classes.
• No input datum belongs to more than one class.
• If the executing code demonstrates a fault when a
  particular class member is used as input, then
  the same fault can be detected using any other
  member of the class as input.

6
Structural testing(1)

• Test data selected based on software structure/
  implementation
• An analysis of the code can be used to find how
  many test cases are need.

selected inputs
Component code
7
Path testing(1)

• A white box testing strategy whose objective is
  to exercise every independent path through the
  component.
• The starting point is a program flow graph

8
Path testing(2)

• Path testing technique are only really usable at
  the unit testing and module testing of the
  testing process.

9
Path testing example(1)
If Y gt 1 THEN Y Y 1 IF Y gt 9 THEN
Y Y 1 ELSE Y Y 3 END
Y Y 2 ELSE Y Y 4 END IF Y gt 10
THEN Y Y 1 ELSE Y Y - 1 END
Program Implementation
Program Specification
10
Path testing - example(2)
Path Domain Y gt 8 infeasible 5 Y 8 1 lt Y lt
5 infeasible Y 1
Program Path T T T T T F T F T
T F F F - T F - F
11
Interface testing(1)

• Takes place when modules or sub-system are
  integrated to create larger systems.
• Particularly important for object-oriented
  development.
• Types of interface
• Parameter interfaces data or function
  references are passed from one component to
  another.
• Shared memory interfaces a block memory is
  shared between sub-systems.
• Procedural interfaces one sub-system
  encapsulates a set of procedures which can be
  called by other sub-systems. Message passing
  interfaces one sub-system requests a service
  from another sub-system by passing a message to
  it.

12
Interface testing(2)

• Interface errors
• Interface misuse
• Particularly common with parameter interfaces
• Interface misunderstanding
• A calling component misunderstands the
  specification of the interface of the called
  component.
• Timing errors
• Occur in real-time systems which use a shared
  memory or a message passing interface.

13
Interface testing(3)

• Guidelines for interface testing
• Examine the code to be tested and explicitly list
  each call to an external component. Design a set
  of tests where the values are at the extreme ends
  of their ranges.
• Where pointers are passed across an interface,
  always test the interface with null pointer
  parameters.
• Where a component is called through a procedural
  interface, design tests which should cause the
  component to fail.
• Use a stress testing strategy in message passing
  systems.
• Where several components interact through shared
  memory, design tests that vary the order in which
  these components are activated.