UoL CS Notes
Menu

Software Testing

COMP201 Lectures

Test Plan Template

Name of Case Description Input Data Action Expected Output Actual Output Pass
LoginOKPass Tests login with a good username and password. Username=test1
Password=pass1		 Click login. OK Login OK True
             

Black-Box Testing

This is a method of testing where we blindly test inputs and validate the outputs.

There are additional examples of test cases in the slides.

Equivalence Partitioning

Often many inputs produce similar outputs (correct login produces a login event):

  • We can then group the related inputs into an equivalence partition.

Testing data at the edge of the equivalence partition is more likely to produce errors.

White-Box Testing (Structural Testing)

This form of testing uses knowledge of the program to identify additional test cases:

  • The aim is to exercise all program statements (not all path combinations).

There are additional examples of test cases in the slides.

Cyclomatic Complexity

We can represent the branches in the code as a graph where:

  • Nodes - Branches
  • Edges - Program Flow

The cyclomatic complexity of a program graph is:

\[e -n+2\]
  • $e$ - The number of edges.
  • $n$ - The number of nodes.

This represents the number of tests to test all control statements.

There is an example of calculating cyclomatic complexity the the slides.

Integration Testing

This is the testing of complete systems, or sub-systems, composed of integrated components:

  • Should be black-box testing with tests derived from the specification.
  • We can use incremental integration to find which component interactions cause the issues.

Incremental Integration Testing

This method uses regression testing:

  • For each additional component we add, we still complete all of the tests that we have done before.

Top-Down Testing

This is where we start with a high-level system and integration from the top-down, replacing individual components by stubs where appropriate.

This method allows for the following:

  • Architectural Validation - This method is better at discovering errors in the system architecture.
  • System Demonstration - Top-Down integration testing allows a limited demonstration at an early stage in the development.

Bottom-Up Testing

This is where we integrate individual components in levels until the complete system is created.

This testing is best suited for:

  • Object Oriented Systems - There is a neat decomposition into classes and methods.
  • Real Time Systems - Allows use to identify slow code quickly.
  • Systems with Strict Performance Requirements - Allows us to measure the performance of individual methods early in the testing process.

Interface Testing

This takes place when modules, or sub-systems, are integrates to create larger systems.

The objective is to detect faults due to interface errors or invalid assumptions about interfaces.

Interface Types

  • Parameter Interfaces - Data is passed from one procedure to another.
  • Shared Memory Interfaces - A block of memory is shared between procedures.
  • Procedural Interfaces - Sub-system encapsulates a set of procedures to be called by other sub-systems.
  • Message Passing Interfaces - Sub-system request services from other sub-systems.

Interface Errors

  • Interface Misuse - A calling component calls another component and makes an error in its use of its interface.
  • Interface Misunderstanding - A calling component embeds assumptions about the behaviour of the called component which are incorrect.
  • Timing Errors - The called and the calling component operate at different speed and out-of-date information is accessed.

There is information on how to test these types of interfaces, stress testing, object-oriented testing, object class testing and testing levels in the slides.

There is also an example of testing a weather station object interface.

Cluster Testing

Cluster testing is concerned with integrating and testing clusters of cooperating objects. We can use the following testing methods on these systems:

  • Use-Case or Scenario Testing:
    • Testing is based on user interactions with the system.
    • Has the advantage that it tests system features as experienced by users.
    • Scenario testing should be supplemented with interaction diagrams.

    There is an example of scenario testing with a weather station in the slides

  • Thread Testing:
    • Tests the systems response to events as processing thread through the system.
  • Object Integration Testing:
    • Tests sequences of object interaction that stop when an object operation does not call on services from another object.