Sub-System Integration Testing

Bread Crumbs: Home - SW_Dev_Proc - Tst - Sy Int Tst

Sub-system integration testing focuses on testing the external APIs (Application Programming Interfaces) between sub-systems.

There are several approaches to performing sub-system integration testing. For these different approaches, the black-box method of testing is utilized. The sub-system is viewed as a black box that presents a control panel in the form of API function. All testing is written to the available API functions according to the API documentation.

This page will cover the following sub-system integration testing topics:

Top-Down vs Bottom-Up Integration

Top-down testing versus bottom-up testing is really a question of what fits your situation. Bottom-up testing allows for easy use of existing reusable components in the testing approach since drivers can drive those components as the system architecture continues to be developed. Top-down testing must wait for architectural design activities to be finished before beginning. Because top-down testing tests high-level design elements, it can often find critical architectural problems earlier than bottom-up testing.

The following table summarizes the comparison between top-down and bottom-up integration testing.

Criteria

Comparison

Architectural Validation

Top-down testing is better suited than bottom-up testing for early detection of system architecture errors and high-level design errors. Early detection reduces the cost of fixing the errors.

System Demonstration

A top-down approach to testing allows the organization to quickly gain confidence in a skeletal system that can then be used for demonstration purposes. A bottom-up approach uses drivers at the highest system levels which would likely be more cumbersome to demonstrate.

Test Implementation

Top-down testing will generally place more of a burden on the development team since meaningful stub behavior will be required for the system to be tested. Stubs can become quite complex in order to provide the necessary behavioral characteristics. Reusable components, on the other hand, provide stable behavior and therefore developers do not need to be quite as creative when creating the drivers that drive those low-level components.

Test Observation

Top-down and bottom-up testing are about equal on this criteria. High-level components aren’t necessarily meant to generate observable output and must be made to do so using an artificial environment. Likewise, low-level components may need an artificial environment in order to probe their internal behavior.


The following diagram shows graphically the difference between top-down integration testing and bottom-up integration testing.

Note: The test sequence for the following diagram is left to right.
Top-Down vs Bottom-Up Testing PNG

Sub-System Integration Test Plan

Sub-system integration test plans must be created prior to system integration test execution. The following is a sub-system integration testing test plan for the microwave oven example.

Sub-System

Test Description

Command Processing System Testing

Tests for errors in integration and functioning of system sub-components.  Assures proper operation of Input Monitoring and Processing, Clock, Timer, Auto Cook, and Auto Defrost functions.

Cooking Control System Testing

Tests for errors in integration and functioning of cooking control function and oven control function.

Output Processing System

Tests for errors in integration of timer display, clock display, and beeper signaling.


V-Model Diagram

The sub-system integraton test plan creation activity should start as the interface design artifacts become relatively stable and mature.

V-Model Diagram - Sub-system Integration Testing PNG For this software development process, the system specification artifact is a document that captures development artifacts generated during requirements engineering phase that will be instrumental to the later development phases. Interface design of the system needs to stabilize very early in the development process in order to begin creating the stubbed-out function tests that call the API functions that are part of the system's external interface (V-Development). Sub-system integration testing focuses on testing the external APIs (Application Programming Interfaces) between sub-systems.

No part of this work should be produced or used without the permission of the authors: Michael Turner and Dr. Sharon A White.