Basiswissen Automotive Softwaretest. Ralf Bongard
(wie dem V-Modell) innerhalb abgeschlossener Testphasen statt. Im Rahmen von iterativ/inkrementellen Entwicklungsmodellen (wie Prototyping oder Scrum) ist das Testen hingegen eine kontinuierliche und begleitende Aktivität.
Die Entwicklung eines Fahrzeugs verläuft typischerweise entlang der sequenziellen Phasen des Produktentstehungsprozesses (siehe Abschnitt 2.3). Um die hohe Komplexität und die Größe des Entwicklungsumfangs beherrschen zu können, lagern Fahrzeughersteller (im Weiteren als Hersteller bezeichnet) Teile der Entwicklung an Zulieferer aus. In der so entstehenden Zulieferkette steht der Hersteller an der Spitze, gefolgt von einer Kette von Zulieferern.
Exkurs: OEM und Tier-1
In der Automobilindustrie haben sich die Bezeichnungen Original Equipment Manufacturer (OEM) für den Fahrzeughersteller und Tier (dt. Ebene, Rang) für die Zulieferer etabliert. Die Zulieferer werden abhängig von der Distanz zum OEM in der Zulieferkette als Tier-1, Tier-2 usw. bezeichnet. Die erste Zuliefererebene Tier-1 repräsentiert also direkte Zulieferer des OEM. Der Tier-2 liefert an den Tier-1 und so weiter. Durch das Zusammenspiel von Auftraggebern und Auftragnehmern auf jeder Ebene hat die Anzahl der Ebenen Einfluss auf die Anzahl und die Ausgestaltung der Teststufen.
Branche
Das Testen ist auf die Branche bzw. die Art des zu testenden Produkts anzupassen. So muss beispielsweise der Bestellvorgang in einem Webshop auch für einen Laien möglich sein. Im Falle einer Fehlfunktion geht zumeist der Umsatz verloren. Im schlimmsten Fall kann die Fehlfunktion das Image des Betreibers schädigen. Wichtige Testziele sind also die Bewertung der Funktionalität (Geschäftszweck) und der Gebrauchstauglichkeit. Für die Nutzung der Bremsen in einem Fahrzeug darf hingegen ein Führerschein vorausgesetzt werden. Allerdings kann hier eine Fehlfunktion tödliche Folgen haben. Wichtiges Testziel ist hier zwar auch die Bewertung der Funktionalität (Geschäftszweck), allerdings bekommt die Bewertung der Zuverlässigkeit einen deutlich höheren Stellenwert.
Technologie
Die Software klassischer IT-Systeme läuft meistens auf kommerzieller Standardhardware (wie PC, Workstation, Server). Hierzu liefern die Hersteller der Hardware auch die notwendigen Treiber. Die Entwicklung eines IT-Systems beschränkt sich somit meistens auf die Softwareapplikationen. Die Hardware und das Betriebssystem nimmt der IT-Entwickler als gegeben und getestet an.
Im Gegensatz dazu sind in der Softwareentwicklung von eingebetteten bzw. mechatronischen Systemen die Hardware (Elektrik/Elektronik) und die Mechanik untrennbare Bestandteile des Gesamtsystems. Daher lässt sich der Softwaretest nicht unabhängig von Hardware und Mechanik betrachten. Die enge Verzahnung der Entwicklungsprozesse für Software, Hardware und Mechanik wird dadurch zu einem wesentlich Erfolgsfaktor.
Grundsatz 7: Trugschluss: »Kein Fehler« bedeutet ein brauchbares System
Es ist ein Irrglaube, dass allein Verifizierung und Behebung identifizierter Fehlerzustände den Erfolg eines Systems sicherstellen. Denn mit der Verifizierung weist der Tests nur die Erfüllung festgelegter Anforderungen nach. Doch damit fehlt noch der Nachweis, dass das System auch die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt (Validierung).
Dies stellt eine besondere Herausforderung dar, wenn die festgelegten Anforderungen die Basis des Entwicklungsvertrags zwischen dem Fahrzeughersteller und seinen Zulieferern darstellen. Erfüllt die Software, das Steuergerät oder das System des Zulieferers diese Anforderungen, hat er den Vertrag erfüllt. Was ist aber in dem Fall, wenn der Zulieferer die Anforderungen in einer Weise interpretiert, dass dadurch der Liefergegenstand für den beabsichtigten Gebrauch nicht (vollumfänglich) geeignet ist? Testen darf deshalb nicht nur auf die Verifikation begrenzt sein. Der Tester sollte durch Validierung auch den beabsichtigten Gebrauch und die beabsichtigte Anwendung im Auge behalten.
2.2Der Testprozess
Testen ist mehr als nur die Testdurchführung (Abschnitt 2.2.1). Zu einer systematischen Vorgehensweise gehört auch die Testvorbereitung (Abschnitt 2.2.2 mit der Testanalyse, dem Testentwurf und der Testrealisierung) und das Testmanagement (Abschnitt 2.2.3 mit Testplanung, Testüberwachung und -steuerung und Testabschluss).
Abb. 2–1 Der Testprozess
Abhängig vom verwendeten Entwicklungsmodell können alle in Abbildung 2–1 dargestellten Testaktivitäten sowohl in sequenzieller Reihenfolge als auch (teilweise) parallel zueinander verlaufen. So kann beispielsweise der Testentwurf für einen später zu implementierenden Funktionsumfang bereits parallel zu der Testdurchführung für einen bereits implementierten Funktionsumfang erfolgen.
2.2.1Testdurchführung
Testprotokoll und Fehlerbericht
Wer von Testen spricht, redet meistens von der Testdurchführung. Während der Testdurchführung führt der Tester (oder der Entwickler) die zuvor spezifizierten Tests aus, protokolliert diese in Testprotokollen und berichtet in Fehlerberichten über etwaige Abweichungen vom erwarteten Ergebnis. Liegen die Testabläufe in maschinenlesbarer Form vor, kann die Durchführung unter Zuhilfenahme eines Testausführungswerkzeugs auch automatisiert erfolgen.
2.2.2Testvorbereitung
Von allen Testaktivitäten ist die Testdurchführung die Testaktivität, die alle Projektbeteiligten am meisten wahrnehmen. Denn sie liefert die im Projekt sichtbaren Testergebnisse und Fehlerberichte. Doch bevor der Tester die Tests ausführen kann, muss er die zugrunde liegende Testbasis analysieren, die Tests spezifizieren und im Anschluss die zur Durchführung benötigten Testmittel realisieren.
Leider suggerieren viele Entwicklungsmodelle (wie das V-Modell in Abb. 2–3), dass Testen nur am Ende der Entwicklung erfolgt. Dabei betrachten diese Modelle (zumindest zeitlich gesehen) lediglich die Testdurchführung. Mit den Tätigkeiten der Testvorbereitung kann und sollte der Tester schon früh und parallel zu den anderen Entwicklungsaktivitäten beginnen.
Testanalyse
Während der Testanalyse bewertet und analysiert der Tester die für die Tests zugrunde liegende Testbasis4 und identifiziert die zu testenden Aspekte (Testbedingungen).
Testbasis
Die Testbasis liefert ihm die Informationen, die er als Basis für den Testentwurf der Testfälle verwenden kann. Dabei kann es sich um Spezifikationen, interne Strukturen oder auch um Erfahrung des Testers aus anderen Projekten bzw. mit anderen Systemen handeln.
Testbedingung
Mit den identifizierten Testbedingungen bestimmt der Tester, was zu testen ist. Abhängig von der Testbasis können dies z.B. die Grenzwerte eines spezifizierten Parameters, die Entscheidungen eines Programmcodes oder die Erwartungen eines erfahrenen Testers sein.