Der Unterschied zwischen Integrations- und Systemtest im Automotive-Bereich

von Günter Kissinger

Der Unterschied zwischen Integrations- und Systemtest im Automotive-Bereich

Sehr häufig haben Anwender Probleme Integrations- und Systemtest klar voneinander zu trennen, was gerade im Bereich Automotive besonders schwierig ist.

Integrationstest

Laut dem [ISTQBGlossarDE2.1] ist ein Integrationstest das “Testen mit dem Ziel, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten aufzudecken.” Der Komponentenintegrationstest wird dabei als Integrationstest ‘im Kleinen’, der Systemintegrationstest als Integrationstest ‘im Großen’ betrachtet.

Der Integrationstest liegt dabei auf einer Teststufe (engl. test level) unterhalb des Systemtests.

Im [AutomotiveSPICE_PAM2.5] heißt es unter ENG.9 Integration Test

“The purpose of the System integration test process is to integrate the system elements to produce an integrated system that will satisfy the system architectural design and the customers’ expectations expressed in the system requirements.”

bzw. in [AutomotiveSPICE_PAM2.3DE]

“Der Zweck des Systemintegrationstestprozesses besteht darin, die Systemelemente zusammenzuführen, um ein integriertes System zu erzeugen, das die Systemarchitektur und die in den Systemanforderungen spezifizierten Kundenanforderungen erfüllt.“

Und genau der 2. Halbsatz erschwert das Verständnis, dass es hier tatsächlich eine klare Trennlinie zum Systemtest gibt. Dass am Ende des gesamten Prozesses ein System herauskommt, das bereits die Kundenanforderungen erfüllt, entspricht der Sichtweise, dass der Systemtest dieses zwar noch überprüft, aber keine Fehlerwirkungen mehr aufzeigt. Das ist in der Praxis eine unrealistische Annahme.

Die Ergebnisse (Outcomes) des Prozesses verdeutlichen aber, dass es hier tatsächlich um die Integration der einzelnen Komponenten oder Teilsysteme und um die Prüfung der Architektur geht. [AutomotiveSPICE_PAM2.3DE]:

“Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses
1) ist eine Strategie zur Systemintegration und zum Systemintegrationstest für die mit der Systemarchitektur konsistenten Systemelemente entwickelt, gemäß der Priorisierung und Kategorisierung der Systemanforderungen;
2) ist eine Testspezifikation für den Systemintegrationstest entwickelt, um die Übereinstimmung mit der Systemarchitektur einschließlich der Schnittstellen zwischen den Systemelementen zu verifizieren;
3) ist ein integriertes System gemäß der Integrationsstrategie integriert;
4) sind die Elemente des integrierten Systems unter Verwendung der Testfälle verifiziert;
5) sind die Testergebnisse der Systemintegrationstests protokolliert und abgelegt;
6) sind Konsistenz und Traceability in beide Richtungen zwischen der Systemarchitektur und der  Testspezifikation für den Systemintegrationstest einschließlich Testfälle hergestellt; und
7) ist eine Regressionsteststrategie für erneute Tests der Systemelemente entwickelt und angewendet, wenn Änderungen vorgenommen wurden;

Anmerkung 1: Die Testspezifikation für die Systemintegration umfasst die Testdesignspezifikation/Test design specification (IEEE), die Testvorgehensspezifikation/Test procedure spezification (IEEE) und die Testfallspezifikation/Test case specification (IEEE).

Anmerkung 2: Die Testergebnisse der Systemintegration umfassen Testprotokolle/Test logs (IEEE), Testvorfallsberichte/Test incident report (IEEE) und Testabschlussberichte/Test summary reports (IEEE).”

Systemtest

[ISTQBGlossarDE2.1] definiert den Systemtest als das Testen eines integrierten Systems, um sicherzustellen, dass es spezifizierte Anforderungen erfüllt [Hetzel].

Im [AutomotiveSPICE_PAM2.5] heißt es unter ENG.10 System Test

“The purpose of the Systems testing process is to ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery.”

bzw. in [AutomotiveSPICE_PAM2.3DE]

“Der Zweck des Systemtestprozesses besteht darin, zu bestätigen, dass das System die definierten Systemanforderungen erfüllt, und zur Auslieferung bereit ist.”

Auch hier erklären die Ergebnisse, dass es sich dabei um den Test des fertig integrierten Systems handelt:

“Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses
1) ist eine Strategie entwickelt, um das System gemäß der Priorisierung und Kategorisierung der Systemanforderungen zu testen;
2) ist eine Testspezifikation für Systemtests für das integrierte System entwickelt, um die vollständige Umsetzung der Systemanforderungen zu verifizieren;
3) ist das integrierte System unter Anwendung der Testfälle verifiziert;
4) sind die Testergebnisse des Systemtests protokolliert und abgelegt;
5) sind Konsistenz und Traceability in beide Richtungen zwischen den Systemanforderungen und der Testspezifikation für den Systemtest einschließlich Testfälle hergestellt; und
6) ist eine Regressionsteststrategie für erneute Tests des integrierten Systems entwickelt und angewendet, wenn Systemelemente verändert wurden;

Anmerkung 1: Die Testspezifikation für den Systemtest umfasst
die Testdesignspezifikation/Test design specification (IEEE), die Testvorgehensspezifikation/Test procedure spezification (IEEE) und die Testfallspezifikation/Test case specification (IEEE).

Anmerkung 2: Die Testergebnisse der Systemtests umfassen Testprotokolle/Test logs (IEEE), Testvorfallsberichte/Test incident report (IEEE) und Testabschlussberichte/Test summary reports (IEEE).”

Zu integrierende Komponenten / Teilsysteme

Bei ENG.8 Softwaretest wird rein die Software integriert und am Ende stehen also vollständig integrierte Software-Komponenten, die – theoretisch – nur noch mit der Hardware integriert werden müssen. Faktisch ist es aber so, dass Teile der Software ohne Hardware nicht oder nur schwer zu testen sind. Damit ist das Ergebnis der Softwareerstellung häufig nicht eine einzige Software-Komponente, sondern vielmehr mehrere Software-Komponenten, teilweise bereits mit anderen Systemkomponenten integriert. ENG.8, ENG.9 und ENG.10 vermischen sich daher sehr leicht und es wird umso wichtiger klare Strategien für alle drei Prozesse zu erarbeiten.

Teststrategien für Software-, Integrations- und Systemtest

Integrationsteststrategien sind immer auch Integrationsstrategien und damit auch Releaseplanungen. Um die optimale Strategie zu wählen, sind folgende Überlegungen hilfreich.

Da die grobe Releaseplanung in weiten Teilen vom OEM vorgegeben wird (oft genug schreibt er vor, was in A-, B-, C-, … Muster enthalten sein soll), sollte die Integrationsteststrategie das natürlich berücksichtigen. Grundsätzlich ist dabei eine Top-Down-Integrationsteststrategie hilfreich, weil dadurch bereits frühzeitig ein Prototyp entsteht.

Werden neue Technologien entwickelt, sollte Critical-First in Betracht gezogen werden, vor allem für A- und evtl. auch B-Muster. Hiermit wird eine frühe Machbarkeitsanalyse ermöglicht und nötigenfalls frühzeitig eine Planung von Alternativen.

Da die Reihenfolge der Fertigstellung aufgrund von unterschiedlichsten Problemen nicht immer genau der geplanten Reihenfolge entspricht, ist auch zu definieren, was mit “zu früh” erstellten Komponenten passieren soll. Sie können entweder gemäß der Asap-Strategie gleich integriert werden, oder sie bleiben in Warteposition, bis sie entsprechend der Planung integriert werden können. In ersterem Fall sind möglicherweise zusätzliche Treiber oder Stubs notwendig, die sonst nicht nötig gewesen wären. Andererseits könnte der Aufwand zur Erstellung für das gesamte Projekt günstiger sein, als das Warten auf vorher zu integrierende Komponenten, die möglicherweise zu spät kommen.

Zusätzlich gibt es noch technische Einschränkungen bezüglich der Integrationsreihenfolge. Es macht z.B. wenig Sinn, die Fensterhebermechanik und den Lautsprecher in einem Türmodul zu integrieren und gemeinsam zu testen, ohne dass Fensterhebermechanik und die zugehörige Ansteuerung vorab integriert worden sind.

Die Prozesse Softwaretest, Integrationstest und Systemtest werden gegebenenfalls mehrere Male in jeweils anderen Abstraktionsebenen durchgeführt. Was jeweils einzelne Komponenten und das damit entstehende System beinhaltet, muss in der Architektur der Software und des Systems festgelegt werden.

Ein Kunde von mir hat daher auch in seinem Prozessmodell mehrere (Integrations-)Teststufen eingeführt, die in jedem Projekt entsprechend der Richtlinien einem Tailoring unterzogen werden. Diese lauten in etwa:

  1. Software A Integration
  2. System A = Software A + Hardware A Integration
  3. Software B Integration
  4. System B = Software B + Hardware B Integration
  5. System AB = System A + System B Integration

Und die jeweiligen Integrationsstrategien sind für 1. und 3., sowie für 2. und 4. durchaus unterschiedlich – sie werden allerdings in einem einzigen Dokument dargestellt.

Testzwecke

Der Integrationstest bezieht sich immer auf die Architektur. Er prüft ab, ob die geplante Architektur tatsächlich so umgesetzt wurde, was vor allem Schnittstellen und die Kommunikation (Signale) zwischen den einzelnen Modulen einschließt.

Der Zweck ist also zu zeigen,

  1. dass eine neu hinzuzufügende Komponente in ein bereits bestehendes integriertes Teilsystem eingefügt werden kann,
  2. dass die Schnittstellen dieser Komponente gemäß den Vorgaben aus der Architektur erstellt wurde (z.B. erwartete Parameterlisten einer SW-Komponente, Ports eines ICs, Ein- und Ausgänge eines elektronischen Bauteils, Anschlussklemmen von mechanischen, pneumatischen oder hydraulischen Bauteilen usw.),
  3. dass die Komponente von anderen Komponenten bestimmungsgemäß genutzt (angesprochen/bedient) werden kann und
  4. dass das Hinzufügen der Komponente keine negativen Auswirkungen auf das Restsystem hat (z.B. verändertes Antwort-Zeit-Verhalten oder Einfluss auf andere nicht-funktionale Qualitätsmerkmale).

Die Frage lautet nun, wann hören Integrationstests auf. Wann kann eine hinzugefügte Komponente als für diese Teststufe gut genug getestet bezeichnet werden? Sie wird ja im Systemtest wiederum auf möglicherweise sehr ähnliche Art und Weise getestet.

Die Antwort hierauf liefert die Architektur. Das minimale Testkriterium ist: jede Schnittstelle muss wenigstens einmal angesprochen werden. Das bedeutet, das in einem komplexen System möglichst einfache Signalflüsse abgetestet werden sollten. Hiermit werden der 1. und der 2. Zweck erfüllt. Um dem 3. Zweck gerecht zu werden, ist es notwendig die Komponente von allen nutzenden Komponenten wenigstens einmal anzusprechen. Der 4. Zweck bedingt den Aufbau von Regressionstests. Mit jeder integrierten Komponente sollte die Regressionstestfälle weiter ergänzt werden, so dass ein grundsätzliches Funktionieren des bis dato vorhanden Systems nachgewiesen werden kann. Zur Absicherung werden hier sicherlich einige Testfälle hinzukommen, die aus den Systemanforderungen abgeleitet werden. Die somit entstehenden Regressionstestfälle sind dann die Basis für die Regressionstestfälle des Systemtests und möglicherweise sogar schon vollständig.

Der Systemtest basiert ausschließlich auf den Anforderungen an das System. Gerade im Bereich Automotive sind dies häufig auch Anforderungen an das Design (Design Constraints) und somit nahe an der Architektur. Daher können Testfälle des Integrationstests auch im Systemtest so oder zumindest sehr ähnlich vorkommen. Wichtig ist aber der Blick von außen: was soll das gesamte System tun und tut es das auch? Signale werden somit nicht zwischen einer Komponente und dem Restsystem betrachtet, sondern als durchgängige Kette des tatsächlichen Ursprungsignals über (meist) mehrere Komponenten hinweg zum Ausgangssignal – also vom Sensor bis zum Aktuator. Hierbei wird ein besonderes Augenmerk auf die Korrektheit gelegt (z.B. auch auf unerlaubte Spannungsverluste) und auf nicht-funktionale Merkmale wie Effizienz (beispielsweise der Speichernutzung), Performanz und Zuverlässigkeit.


Whitepaper-Banner flach

Zurück

Einen Kommentar schreiben