Stefan Schmerler - Softwaretest in der Praxis

Abb. 3-4: Steckbrief Unit-Test

3.4.2 Komponententest

Der nächste Integrationsschritt in der klassischen Softwareentwicklung ist die Bildung von Softwaremodulen aus einzelnen Funktionen oder Methoden. Die Absicherung dieses Schritts ist Gegenstand des Komponententests. Testziel ist also das Zusammenspiel der Funktionen oder Methoden eines Moduls.

Fehler, die im Komponenten-

test gefunden werden

Typische Defects, die beim funktionalen Komponententest gefunden werden, sind Berechnungsfehler oder fehlende bzw. fälschlicherweise durchlaufene Programmpfade durch fehlerhafte Zweigprädikate. Man spricht von algorithmischem und logischem Absicherungsumfang.

Robustheitstests und Negativtests

Auch der Test auf Robustheit ist ein weiterer wichtiger Aspekt des Komponententests. Robustheitstests müssen nicht auf Integrations- oder Systemtestebene erfolgen und sollten, dem Grundsatz kleinstmöglicher Teststufen folgend, auf Komponentenebene verortet werden. Es werden nach der Spezifikation unzulässige oder nicht vorgesehene Testdaten eingesetzt, um eine korrekte Ausnahmebehandlung (Exception Handling) zu testen. Derartige Testfälle werden auch Negativtests genannt. Fehlen solche Ausnahmebehandlungen, treten möglicherweise Wertebereichsfehler und unter Umständen Programmabstürze auf.

über die Hälfte des Codes für die Robust-

heit und Ausnahmebehandlung

Diese Ausnahmebehandlung im Testobjekt kann, verglichen mit dem eigentlichen Funktionscode, durchaus umfangreich werden. In der Praxis dienen nicht selten über 50 % des Programmcodes der Behandlung von Ausnahmesituationen und damit der Robustheit.

nichtfunktionale Eigenschaften

Neben Funktionalität und Robustheit sind im Komponententest auch Qualitätseigenschaften der Komponente wie Effizienz, Performance und Wartbarkeit zu prüfen, die auf höheren Teststufen nicht mehr oder nur mit erhöhtem Aufwand getestet werden könnten. Die Messung von Speicherverbrauch oder Reaktionszeit gehört zum Standardprogramm einer Komponententestsuite.

Komponententest prüft die

inneren Qualitätsmerkmale.

Bei dieser Gelegenheit kann man auch einen Blick auf die »inneren Werte« des Codes, z. B. seine Wartbarkeit, werfen. Wie leicht oder schwer wird es einer anderen Person einmal fallen, den Code zu ändern, zu erweitern oder überhaupt erst einmal zu verstehen? Prüfaspekte, die hier im Vordergrund stehen, sind Modularität, Kommentierung, Codestruktur, die Einhaltung von Architektur- oder Codierrichtlinien sowie die Verständlichkeit und Aktualität der Dokumentation.

Möglichkeit des White-Box-Test

Da Komponententests typische Entwicklertests sind, liegt in aller Regel Zugang zum Quellcode vor, was den Komponententest zum White-Box-Test macht, d. h. die Kenntnis der Programmstrukturen ausnutzen lässt. Der Tester kann Testfälle mithilfe seines Wissens über komponenteninterne Codestrukturen, Methoden oder Variablen entwickeln. Durch Werkzeuge wie Debugger kann der Zustand der Komponente nicht nur beobachtet, sondern auch manipuliert werden. Dies ist besonders bei Robustheitstests von besonderem Nutzen.

oft genutzt: Black-Box-Test

Trotz der Möglichkeit von White-Box-Tests werden in der Praxis viele Komponententests nur als Black-Box-Verfahren durchgeführt, d. h. im Gegensatz zum White-Box-Test nur durch Beobachtung und Stimulation der äußeren Schnittstelle des Testobjekts. Dies kann dadurch erklärt werden, dass Softwaresysteme oft aus Tausenden von Komponenten bestehen, die erst in einer höheren Aggregationsstufe sinnvoll und praktikabel einem Komponententest unterzogen werden können. Diese Aggregationseinheiten sind dann aber bereits zu groß, um sich mit vertretbarem Aufwand beim Komponententest auf Codeebene bewegen zu können.

Test-First-Ansatz und

testgetriebene Entwicklung

Ein häufig zum Einsatz kommender Ansatz für Komponententests ist es, zuerst die Tests zu erstellen und zu automatisieren und dann erst mit der Implementierung der Komponente zu beginnen. Man spricht vom Test-First-Ansatz. Dabei ist das Vorgehen stark iterativ. Der Code wird mit den vorhandenen Testfällen überprüft und sukzessive in kleinen Schritten verbessert, bis die Tests, die nach jeder Änderung im Code automatisiert durchgeführt werden, fehlerfrei durchlaufen werden. Man bezeichnet dieses Vorgehen aus offensichtlichen Gründen auch als testgetriebene Entwicklung. Auch Negativtests können auf diese Weise vor Implementierungsbeginn eingebunden werden.

Spezifika in der Automobilelektronik

Unter Komponententest versteht man im Kontext Automobilelektronik auch den Test einzelner Steuergeräte eines Steuergeräteverbunds. Dies ist der Test eines Steuergeräts oder der entsprechenden Software stand-alone, aber durchaus mit simulierter Umgebung, z. B. indem andere Komponenten (zumindest in der Kommunikation) simuliert werden. Dieses Vorgehen wird als Restbussimulation bezeichnet. Ohne eine höchst realistische Stimulation, die auch spezifikationsgerecht auf Ausgaben der zu testenden Komponenten reagiert, würde der Test aufgrund der permanent stattfindenden Plausibilitätsprüfungen der Eingangswerte an den Steuergeräten mit Eintrag in den Fehlerspeicher abgebrochen werden. Das Steuergerät würde also eine Fehlerroutine einleiten, die weiteres Testen verhindert.

Komponententest ist notwendig,

aber nicht hinreichend.

Ein erfolgreicher Komponententest ist eine notwendige, aber keine hinreichende Bedingung für den Integrationserfolg. Viele Auffälligkeiten stellen sich erst im Verbund ein. Im Bereich des Netzwerkmanagements, bei spezifischen Protokollen wie Service Discovery oder bei im Verbund dargestellten komplexen Funktionen stößt der Komponententest an seine Grenzen. Ein sich anschließender Integrationstest ist unbedingt erforderlich.

Abb. 3-5: Steckbrief Komponententest in der klassischen SW-Entwicklung

3.4.3 Integrationstest

Softwareintegration

In der klassischen Softwareentwicklung überprüft der Integrationstest, aufbauend auf dem Komponententest, das Zusammenspiel der Komponenten bzw. Funktionen oder Klassen. Gruppen dieser Komponenten werden zunächst von Testern oder Integrationsteams zu größeren Teilsystemen verbunden. Diesen Vorgang bezeichnet man als Softwareintegration.

Integrationstest

Anschließend kann getestet werden, ob das Zusammenspiel der integrierten Komponenten untereinander spezifikationskonform erfolgt. Dieser Test wird als Integrationstest bezeichnet. Er hat zum Ziel, Fehlerzustände in Schnittstellen und im Zusammenspiel integrierter Komponenten zu finden.

Integrationstest setzt

Komponententest voraus.

Wichtig für einen effizienten und erfolgreichen Integrationstest sind im Vorfeld erfolgte Komponententests. Auch bei diesen Tests können Schnittstellenfehler der Komponenten unerkannt bleiben – schon aus diesem Grunde ist ein Integrationstest unbedingt erforderlich. Ein übergeordneter funktionaler Test wäre auf Ebene des Komponententests zudem in keiner Weise leistbar.

Wiederverwendung der Test-

treiber des Komponententests

Auch beim Integrationstest werden Testtreiber benötigt, die die Testobjekte mit Testdaten versorgen und deren Ergebnisse aufnehmen und weiterverarbeiten bzw. protokollieren. Da die Testobjekte Systeme aus zusammengesetzten Komponenten sind, die keine anderen Schnittstellen nach außen aufweisen als ihre Einzelkomponenten, können vorhandene Testtreiber des Komponententests beim Integrationstest wiederverwendet werden.

Systemintegrationstest

Auch die Schnittstellen zur Systemumgebung sind Gegenstand von Integration und Test. Werden Schnittstellen zu (aus Sicht des SUT) externen Softwaresystemen – oder gar zur Hardware – getestet, spricht man von Systemintegrationstest. Er erfolgt nach dem Systemtest.