RSS Feed

Integration Tests

What are Integration Tests?

The expression integration test can mean a great variety of things. First of all it has to be said that in the software community the term "integration test" is often misused to mean "integration" as such, talking about "big bang integration" vs. progressive integration etc. but not really talking about the tests associated with it. To sort this confusion a little we have to see what kind of integrations usually take place in software development:

  1. The integration of software components to build a bigger component or a complete software. This usually happens if software is developed by different departments or even companies and then has to be brought together. We will call it from now on "software integration".
  2. The integration of software into the complete system, i.e. the destination hardware. This usually is a scenario where software is developed using e.g. simulation systems or laboratory systems instead of the destination hardware, and whenever it seems to be finished, it has to be brought to the destination hardware. We call this from now on "system integration".

Software Integration Tests

Basically there is nothing special about these tests which was not already covered by the dynamic tests. It all boils down to unit tests and component tests which e.g. could be done by a Perl script or other test environment, for the last and final components or the complete software. The focus of these test is:

  1. Functional check of the individual components which have to be integrated (e.g. by our Perl test environment or any other suitable environment).
  2. Check of the interfaces of the components which have to be integrated to form the next bigger component.
  3. Functional check of the next bigger component i.e. the integrated software (e.g. by our Perl test environment or any other suitable environment).
  4. This can be done step by step for a big number of components, forming next bigger components, which are then integrated in turn.

System Integration Tests

This is where integration into the system and related integration tests happen. Very often this is a big challenge, since it is not easy to design tests which e.g. stimulate hardware in micro controller systems in the required way to give sufficient test coverage. The focus of these tests is:

  1. Substituting simulated inputs and outputs by the real hardware, as e.g. sensors or other peripheral devices. This has to be done step by step until the complete system is integrated and integration tested.
  2. Check of the CPU resources as e.g. RAM, runtime, stack. For this worst case scenarios have to be stimulated and sufficient checks have to be implemented to determine the resource situation.

System Tests

System tests are always very specific. It is a big difference if I have to test an automatic transmission in a vehicle or if I have to test the brake system of an aircraft. However there are some general rules about system testing. First of all a system test has to be always performed in the original environment. Finally at this stage it is not allowed to use test benches or especially made prototypes of the system any more. You always should use a series system. Further the test environment must not influence the behaviour of the system. This is the most tricky part of it. Of course you would like to measure values and look inside the system to see if it behaves the same as you saw it to behave during all your other development phases. But every measuring may influence the system. Because of this many systems have a build in diagnostic interface and diagnostic function. It is part of the system and it is used throughout development and will finally serve as measuring interface for most of the system tests. Since system tests are usually the most expensive ones it has to be well considered what you want to achieve with them and what you leave to previous testing phases. But it is not only the expenses of the system tests, it is the mere inability to generate the test cases as complete as you would need them to have a good test coverage for a real system. Therefore the previous functional tests (e.g. on a test bench) should achieve the needed test coverage and the system tests should be selected in a way to prove that your previous test cases were valid and let you come to the conclusion that the system behaves as expected under all circumstances.