The following definitions are from a posting by Boris Beizer on
the topic of "integration testing" in the c.s.t. newsgroup.

    The definitions of integration tests are after Leung and White.
    Note that the definitions of unit, component, integration, and
    integration testing are recursive:

    Unit.  The smallest compilable component.  A unit typically is the
    work of one programmer (At least in principle).  As defined, it does
    not include any called sub-components (for procedural languages) or
    communicating components in general.

    Unit Testing:  in unit testing called components (or communicating
    components) are replaced with stubs, simulators, or trusted
    components.  Calling components are replaced with drivers or trusted
    super-components.  The unit is tested in isolation.

    component:  a unit is a component.  The integration of one or more
    components is a component.

        Note:  The reason for "one or more" as contrasted to "Two or
        more" is to allow for components that call themselves
        recursively.

    component testing: the same as unit testing except that all stubs
    and simulators are replaced with the real thing.

    Two components (actually one or more) are said to be integrated when:
            a.  They have been compiled, linked, and loaded together.
            b.  They have successfully passed the integration tests at the
                interface between them.

    Thus, components A and B are integrated to create a new, larger,
    component (A,B).  Note that this does not conflict with the idea of
    incremental integration -- it just means that A is a big component
    and B, the component added, is a small one.

    Integration testing: carrying out integration tests.

    Integration tests (After Leung and White) for procedural languages.
    This is easily generalized for OO languages by using the equivalent
    constructs for message passing.  In the following, the word "call"
    is to be understood in the most general sense of a data flow and is
    not restricted to just formal subroutine calls and returns -- for
    example, passage of data through global data structures and/or the
    use of pointers.

    Let A and B be two components in which A calls B.
    Let Ta be the component level tests of A
    Let Tb be the component level tests of B
    Tab  The tests in A's suite that cause A to call B.
    Tbsa  The tests in B's suite for which it is possible to sensitize A
            -- the inputs are to A, not B.
    Tbsa + Tab == the integration test suite (+ = union).

        Note:  Sensitize is a technical term.  It means inputs that will
        cause a routine to go down a specified path.  The inputs are to
        A.  Not every input to A will cause A to traverse a path in
        which B is called.  Tbsa is the set of tests which do cause A to
        follow a path in which B is called.  The outcome of the test of
        B may or may not be affected.

    There have been variations on these definitions, but the key point is
    that it is pretty darn formal and there's a goodly hunk of testing
    theory, especially as concerns integration testing, OO testing, and
    regression testing, based on them.

    As to the difference between integration testing and system testing.
    System testing specifically goes after behaviors and bugs that are
    properties of the entire system as distinct from properties
    attributable to components (unless, of course, the component in
    question is the entire system).  Examples of system testing issues:
    resource loss bugs, throughput bugs, performance, security, recovery,
    transaction synchronization bugs (often misnamed "timing bugs").