Process GuidePrevious (disabled)Next - IntroductionGlossaryShortcutSummaryUp (disabled)

Integration Testing

Introduction
Concepts
Steps


Process GuidePrevious - Integration TestingNext - ConceptsGlossaryShortcutSummaryUp - Integration Testing

Integration Testing

Introduction

Integration Testing is performed after unit testing and before system testing. Its objective is to identify defects in the interfaces and interactions between system components as they are put together to form progressively larger subsystems. Since system components are identified and designed during the physical design, most of the information used in planning Integration Testing derives from physical design.
This technique assumes that the overall approach to system construction and integration has been defined, and considers what Integration Testing is required.
(Note on terminology. In the development of embedded real-time systems, the term "Integration Testing" is often used to refer to the integration of the software with the target hardware. This is a different use of the term. We are referring here to software integration testing, which occurs before functional system testing. We would refer to testing the software with alternative hardware configurations as one aspect of non-functional system testing).

Process GuidePrevious - IntroductionNext - Testing the Interface Between UnitsGlossaryShortcutSummaryUp - Integration Testing

Integration Testing

Concepts

Integration Testing is usually organized around system functions. For each function, Integration Testing starts with the units (programs or modules) which together constitute the function, and each of which works in isolation. (This will have been verified by unit testing). Integration Testing must examine their interactions to verify that they 'integrate' with each other correctly to provide the complete function. Integration Testing should be considered in two distinct ways:
Testing the Interface Between Units
Black Box Behavior Test.

Process GuidePrevious - ConceptsNext - Black Box Behavior TestGlossaryShortcutSummaryUp - Concepts

Concepts

Testing the Interface Between Units

During physical design the interaction between system components was specified in terms of their interfaces. There are two aspects to an interface - Invocation and Data.
Invocation refers to the control linkage between the units. To be integrated, there must be some mechanism for both units to be invoked. This may be by one unit 'calling' the other (e.g. a program calling a subroutine) or by another process calling both units (e.g. batch job control language calling one program and then the other). Whatever mechanism is used, Integration Testing must verify that invocation behaves according to the physical design specification.
The more complex aspect of the interface to test is usually the data, which may be parameters to transactions, parameter interfaces between modules, data access calls to databases, transaction files passed between programs, etc.
During Integration Testing it is necessary to verify that each of these interfaces works as intended. In particular, a test is required that each item of data sent into an interface by one component arrives safely and is recognized by the correct target component without being lost, truncated, overwritten, or mistaken for some other item. Conversely, it is necessary to verify that each item a component is expecting to receive has been sent in the correct format by the appropriate prior component.
All variants of the interface format need to be checked, such as:
  • are some items optional? If so what happens if they are missed out?
  • are there any time-ordering or sequencing constraints on a stream of interface items? (e.g. must a transaction file always have a header, several body records, then a trailer?)
  • will any special option indicators, flags or control variables be recognized and responded to?

Process GuidePrevious - Testing the Interface Between UnitsNext - StepsGlossaryShortcutSummaryUp - Concepts

Concepts

Black Box Behavior Test

Once the interface is working correctly and the white box logic has been tested, the pair (or group) of units can then be regarded as a single system component, and tested as a black box. For example, when integrating subroutines into a main program one moves from testing the subroutine interfaces and logic on to testing the program as a black box (i.e. ignoring the fact that inside the black box there are subroutines).
At higher levels of system integration this black box testing will in fact be functional system testing and should be considered under that heading. However, there are often intermediate levels of integration where a system component is built from a number of units and where a black box test of the component is useful.
The technique used for black box testing of these intermediate components is the same as the black box unit testing technique, and can often be based on the test cases identified for the black box unit tests.

Process GuidePrevious - Black Box Behavior TestNext - Architectural IntegrationGlossaryShortcutSummaryUp - Integration Testing

Integration Testing

Steps

Integration Testing can encompass a wide variety of different types of test, but in an application development project there are five forms of component integration which are recognized and which are likely to account for most Integration Testing. These are:
Architectural Integration
Process Component Integration
Dialog Component Integration
Batch System Integration
System Interface Integration

Process GuidePrevious - StepsNext - Process Component IntegrationGlossaryShortcutSummaryUp - Steps

Steps

Architectural Integration

The Integration Testing described so far has been concerned with application software. If the system architecture differs from the standard system architecture for the installation, it may be necessary to test the interactions between system software components, such as the TP monitor and the DBMS or a new TP scheduling system. Errors may result from system software being incorrectly installed or configured, or from developers misunderstanding some aspect of the operation of the new system software.
Even where the system architecture is familiar and well proven, Integration Testing may need to test the interaction between application software components and the system software, e.g. to verify that a data access module handles correctly all database error codes, or that the suite JCL deals properly with relevant operating system error codes.

Process GuidePrevious - Architectural IntegrationNext - Dialog Component IntegrationGlossaryShortcutSummaryUp - Steps

Steps

Process Component Integration

During Process Design, system processing is decomposed into modules, and the module interfaces, logic and detailed operations are defined. These design modules are then grouped into physical construction units.
It is usual to organize the Module Decomposition Charts so that each chart represents a single construction unit (i.e. a compilation unit or a 4GL process component).
This is illustrated in the figure below, which shows that transaction T84 calls two internal modules, Prepare Data and Send Screen, and two external modules, Retrieve Data and Calculate Bonus.
The internal modules would normally have been treated as part of a single unit, T84 Display Bonus, for the purposes of unit testing. If though they were large or complex, they might have been unit tested individually (even though they are part of the T84 Compile unit) and then integration tested in conjunction with the remainder of the T84 unit.
The external modules however have been separated out of the T84 decomposition, probably because they are common modules which are also used elsewhere. They would normally be separately compiled and unit tested. The purpose of Integration Testing is to verify that they integrate correctly into this context of use. Tests are derived from the linkage of the module call in the main program to the parameter interface of the called external module. Both interface and black box testing are required.

Process GuidePrevious - Process Component IntegrationNext - Batch System IntegrationGlossaryShortcutSummaryUp - Steps

Steps

Dialog Component Integration

Dialog Design produces a large number of dialog components, each of which is designed and built relatively independently. During Integration Testing the interaction between these components is tested. The main area to test is the invocation of transactions, both from the Menu Control Structure and from the Transaction Dialog Structure of another transaction.
In the figure above, the Menu Control Structure will have been implemented as a program (or navigation table) and the transaction T1 will be a unit which has been constructed and unit tested. Integration Testing needs to verify that the TP monitor, the MCS and the transaction work together in such a way that:
  • the transaction can be invoked from the menu using F3
  • the correct parameters or initial data are sent to it
  • when the transaction ends, it returns control correctly (to M2)
  • the correct parameters are returned to the MCS program.
In many on-line environments the mechanism for implementing the parameter interface is some kind of communication area, scratch pad area or partial results file which is accessed both by the MCS and the transaction. A key concern of dialog component integration testing is to verify that the use of this communication area is correct and consistent i.e. that the data interface between the dialog components behaves as specified.
Transactions can also be called from within the Transaction Dialog Structure of another transaction (see figure below).
Once again, Integration Testing must verify that F10 invokes the transaction, that appropriate data is sent to it, and that control returns to the correct place with correct data. This often involves re-establishing the state of transaction T2 to the state it was in prior to calling T10.
A third aspect of dialog component integration testing concerns global dialog features. Depending on the physical dialog design, a global may be implemented in one component yet activated from many others. Once again, Integration Testing must verify that invocation of the global from each transaction works as specified, that appropriate data is sent (and received by the global component), and that when global processing is completed, control is returned to the context from which the global was invoked.

Process GuidePrevious - Dialog Component IntegrationNext - Invocation via Job Control Language (JCL)GlossaryShortcutSummaryUp - Steps

Steps

Batch System Integration

The design specification consists of a suite of diagrams showing the usage of data, and batch program designs expressed as module decompositions.
Integration Testing of subprograms used by the batch programs is treated like that for any other process component, as described in Process Component Integration. When batch programs are integrated together to form larger units, these larger units typically constitute suites (or fragments of suites). An example of batch suite notation is shown below. Integration testing of batch suites involves addressing a number of issues, specifically:
Invocation via Job Control Language (JCL)
Communication via Files
File Assignment
Sorts/Merges/Extracts.

Process GuidePrevious - Batch System IntegrationNext - Communication via FilesGlossaryShortcutSummaryUp - Batch System Integration

Batch System Integration

Invocation via Job Control Language (JCL)

Rather than one batch program directly calling another in a suite, it is more common first for program A to be called by the JCL and then for program B to be called by the JCL. Integration testing needs to verify that the JCL logic implements the suite design, and does not contain any defects.

Process GuidePrevious - Invocation via Job Control Language (JCL)Next - File AssignmentGlossaryShortcutSummaryUp - Batch System Integration

Batch System Integration

Communication via Files

Batch programs in a suite frequently communicate with each other via data stored on a secondary storage device, either as a transaction file or as items in a database.
This has implications for Integration Testing, such as:
  • what types of records can be in the file, and will they all be recognized?
  • does the data have to be accessed in a particular order?
  • can the data be accidentally overwritten before the receiving program has processed it?
  • are there multiple versions of the file? (e.g. one per day).

Process GuidePrevious - Communication via FilesNext - Sorts/Merges/ExtractsGlossaryShortcutSummaryUp - Batch System Integration

Batch System Integration

File Assignment

A key part of batch system integration is to link programs to the data they use. During Integration Testing it is essential to verify that the correct version of the correct data file is assigned to the correct program with the correct access mode (read/write/delete/extend, etc.). It may be possible to specify such assignments in several different places, such as:
  • in the program itself
  • in the suite JCL
  • in the system catalogue.
It is thus very easy for unintended effects to occur and the validity and consistency of all such assignments must be verified.

Process GuidePrevious - File AssignmentNext - System Interface IntegrationGlossaryShortcutSummaryUp - Batch System Integration

Batch System Integration

Sorts/Merges/Extracts

Batch suites often use utilities to sort transaction data into particular sequences, to merge two or more sets of data, or to extract certain records or fields out of a database or transaction file. These processes must all be tested as part of batch system integration testing.

Process GuidePrevious - Sorts/Merges/ExtractsNext  (disabled)GlossaryShortcutSummaryUp - Steps

Steps

System Interface Integration

An important issue to consider in Integration Testing is the integration of a system into its wider environment. What interfaces does the system have with other systems?
The physical design process ensures that these interfaces are designed as an integral part of the
system, so most of the external interfaces will already have been identified as, for example:
  • writing to a database which is also accessed by another system
  • calling an external module in another system (or vice versa)
  • a dialog interaction between this system and some other, such as being able to invoke a transaction in another system from within this system
  • a batch interface shown on the suite diagram (e.g. receiving a tape of data, or sending output to a file which will be transmitted through a communications link).
Integration tests for these interfaces should already have been identified and designed as discussed in:
Process Component Integration
Dialog Component Integration
Batch System Integration.
However, when planning Integration Testing it is worth returning to the Required System DFD and asking, in addition:
  • "What are all the ways in which the system interacts with its environment?"
  • "What is the form of these interfaces across which those interactions take place?"
  • "Do the planned integration tests adequately test the interaction across each of these interfaces?"