Trend Guide "Embedded-Test"

Embedded-Test: Inhaltsverzeichnis

• Trend Spots
• Fundierte Basis für den Test schaffen:
  Von der Anforderungsanalyse zur Testspezifikation
• Gute Planung ist die halbe Miete: Testplan als Managementaufgabe
• Konkrete Vorgaben für Tester: Mit der Testspezifikation ins Detail
• Die verkannte Prüfmethode: Statische Analyse als Kostenkiller
• Robustheit und Funktionalität gewährleisten: Dynamischer Test prüft den Code
• Stunde der Wahrheit: Aussagekräftige Testauswertung
• Auf der Kostenbremse: Design for Test
• Schneller zur Marktreife: Automatisches Testen
• Info-Pool: Buch- und Webtipps
  
  

Fundierte Basis für den Test schaffen

1. Von der Anforderungsanalyse zur Testspezifikation

Bereits in dem frühen Projektstadium der Anforderungsanalyse entscheidet sich, ob ein Produkt durch Tests schnell zur Marktreife gelangen kann. Je genauer dort formuliert ist, was ein System können soll und was nicht, desto klarer umrissen sind damit bereits die späteren Aufgaben der Tester.

Die Anforderungsanalyse beschreibt ein System mit Ein- und Ausgaben, außerdem seine Umgebung und die Randbedingungen, unter denen es betrieben wird. Aus dieser Analyse resultiert die Anforderungsspezifikation, die den Kontext des Systems darlegt, also was es zu tun hat (funktional) und welche Qualitäten es dabei erfüllen muss (nichtfunktional). Funktionale Anforderungen sollten dabei am besten durch Sequenzen dargestellt sein. Generell werden Anforderungen heute meist noch mündlich mit dem Auftraggeber abgesprochen, obwohl eine schriftliche, im besten Fall sogar modellbasierte Fixierung späteren Problemen vorbeugen könnte. Bei mündlichen Vereinbarungen empfiehlt sich in jedem Fall eine ausführliche Testspezifikation. Außerdem sollte der Tester bei der Formulierung der Anforderungsspezifikation anwesend sein, damit das spätere System testbar ist.

Eine weitere Absicherung ist die Beschreibung von Funktionen, die das System nicht erfüllen soll, was aus Wettbewerbsgründen von Marketing und Vertrieb meist ungern gesehen wird. Doch ist es die Hauptaufgabe der Anforderungsspezifikation, den Rahmen für Entwicklung und Test so eng wie möglich abzustecken.

Qualitätsmerkmal	Teilmerkmale
Funktionalität	Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit
Zuverlässigkeit	Reife, Fehlertoleranz, Wiederherstellbarkeit
Benutzbarkeit	Verständlichkeit, Erlernbarkeit, Bedienbarkeit
Effizienz	Zeitverhalten, Verbrauchsverhalten
Änderbarkeit	Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit
Übertragbarkeit	Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit

Die Qualitätsmerkmale der Norm ISO/IEC 9126 sind - je nach Projekt - aus Kosten- und Aufwandsgründen unterschiedlich zu gewichten. Bei Embedded-Systemen sollte der Schwerpunkt auf dem Zeitverhalten liegen, da dieses am meisten zur Produktqualität beiträgt.

Eine professionelle Anforderungsspezifikation nennt auch die so genannten Stakeholder, also die Personen, die ein berechtigtes Interesse an dem System haben, unter anderem Entwickler, Tester, Management und auf Kundenseite den Besteller sowie Nutzer. Bei letzterem wird differenziert zwischen dem Primäranwender, der tagtäglich mit dem Produkt arbeiten muss, und dem Sekundäruser, wie beispielsweise einem Administrator, der nur gelegentlich darauf zugreift.

Außerdem beschreibt die Spezifikation den Zweck des Systems, der sich eng an seinen wirtschaftlichen Zielen orientieren sollte. In einem weiteren Schritt werden die Grenzen des Systems formuliert, das in diesem Stadium als Black Box betrachtet wird: Über welche Schnittstellen gelangen die Daten hinein, wer speist sie ein und wo werden sie von wem wieder abgeholt?

Die Spezifikation lässt sich gut mit der UML erweitern, um primär die Plausibilität der Anforderungen abzusichern. Die UML-Diagramme dienen zur Verfeinerung der Spezifikation und helfen dem Ersteller, tiefer in das System einzudringen. Ein Beispiel dafür ist das Sequenzdiagramm, das dafür prädestiniert ist, Abläufe zwischen dem System und seiner Außenwelt darzustellen.

Die Sequenzdiagramme der Anforderungsspezifikation betrachten das System als Black Box, das über Schnittstellen mit Akteuren, also Sensoren und Aktoren, kommuniziert. Diese repräsentieren die Außenwelt wie beispielsweise Geräte oder die Umgebung.

Bild 1: Embedded-Test - Im Zentrum steht der Kontext des Produkts und nicht sein Innenleben.

Dem Fehler auf der Spur

Nach der Anforderungsspezifikation der Funktionen folgt die Fehleranalyse, die sich mit möglichen Problemen beschäftigt, wie sie Akteure im System verursachen könnten. Daraus werden später Tests oder Testsequenzen abgeleitet, die es auf Robustheit bezüglich äußerer Einflüsse überprüfen. Beispielsweise kann die Fehleranalyse zu dem Ergebnis führen, dass Ein- und Ausgaben redundant ausgelegt sein müssen, weil das System sicherheitskritisch ist. Damit soll gewährleistet werden, dass es im Fehlerfall minimal eingeschränkt oder ohne Funktionseinbußen weiterarbeitet.

Der Fehleranalyse kommt deshalb eine große Bedeutung zu, weil damit bereits in der Anforderungsspezifikation die Robustheit und damit auch Zuverlässigkeit bzw. Sicherheit des späteren Produkts festgelegt wird. Dies geschieht durch die Erkennung, Identifizierung und Klassifizierung der Fehler, aber auch durch die schriftliche Niederlegung von Toleranzen. Leider ist diese detaillierte Art der Beschreibung noch nicht weit verbreitet, obwohl sie die Arbeit des Testers spürbar vereinfacht. Optimal wäre außerdem eine Kopplung der Analyse mit Fehlerdatenbanken: Dann ist die Fehlerhistorie eines Systems jederzeit nachvollziehbar, was die Ableitung von Testfällen erleichtert.

Softwarefehler	Hardwarefehler
Verarbeitungsfehler - Fließkommazahlen - Bereichsüberschreitungen - Algorithmus	Ausfall - Gesamthardware - Peripherie
Speicherfehler - Überschreiben von Speicher - Pointer - Speicherüberlauf - Mangelhafte Initialisierung der Variablen	Fehlerhafte Initialisierung der Peripherie
Ausführung - Parallelität, z.B. Deadlocks - Missachtung der Zeitbedingungen - Rekursionen	Sporadische Fehler - Einstreuungen - Time-Outs

Die Fehleranalyse dient der Robustheit des Systems.

Unter den diversen Fehlerquellen sind im Stadium der Systemspezifikation vor allem die hardwarebedingten von Interesse, da Software-Bugs erst in der späteren Entwicklung produziert werden. Allerdings können in der Anforderungsspezifikation bereits Maßnahmen gefordert werden, die das Erkennen von Verarbeitungs-, Speicher- und Ausführungsfehlern ermöglichen. Fehler sollten in jedem Fall in einer Liste aufgeführt sein, die sich in Fehler, Quelle, Beschreibung, Art (systemkritisch oder -unkritisch) und Reaktion gliedert. Gegenüber einer Darstellung über Sequenzen haben Listen den Vorteil, dass es sich mit ihnen wesentlich schneller und effizienter arbeiten lässt.

Fehler	Quelle	Beschreibung	Art	Reaktion
Versagen Objektdetektor	Objektdetektor	Die fortlaufende Diagnostik stellt das Versagen des Objektdetektors fest.	systemkritisch	Öffnen des Tors; Abschalten des Systems
Versagen Motor	Motor		systemkritisch	Warnlicht einschalten

Beispiel für eine übersichtliche Fehlerliste

Testfälle ableiten

Aus der fertigen Anforderungsspezifikation lassen sich im nächsten Schritt bereits konkret Tests und Prüfungen ableiten. Der Tester sucht dabei nach Testfällen, mit denen er das Verhalten seines Prüflings in bestimmten Situationen untersucht: Verhält er sich gemäß den spezifizierten Vorgaben und Sollwerten? Testfälle setzen sich aus Parametern und Abläufen zusammen. Parameter können gültig oder ungültig gesetzt sein, so dass sich durch geschickte Parametrisierung mehrere Testfälle generieren lassen. Der Prüfer betrachtet dafür die Grenzen des Systems, also welche Ein- und Ausgangssignale die Aktoren und Sensoren liefern. Außerdem bezieht er Schnittstellen und Protokolle mit in die Überlegung ein. Für die Testabläufe betrachtet er Anwendungsfälle, Abläufe, Zustandsautomaten und ebenfalls wieder die Protokolle.

Bild 2: Die Parameter und Abläufe der Testfälle werden aus der Anforderungsspezifikation abgeleitet.

Dabei muss im Hinblick auf die nichtfunktionalen Anforderungen eine Unterscheidung getroffen werden: Externe Qualitätsmerkmale wie Zuverlässigkeit lassen sich beispielsweise durch Dauertests untersuchen, bei denen der Prüfling die geforderte Ausfallrate erfüllen muss. Für die Zeitanforderungen muss er eine bestimmte Aufgabe in einer bestimmten Zeit abarbeiten, die der Tester den Sequenzdiagrammen der Anforderungsanalyse als Sollwert entnimmt.

Problematisch gestaltet sich dagegen der Test interner Qualitätsmerkmale wie der Übertragbarkeit. Hier müsste der Tester das System auf unterschiedliche Hardware-Plattformen portieren, was aus Zeit- und Kostengründen praktisch nicht zu realisieren ist. Deshalb beschränkt er sich hier auf Prüfungen, betrachtet beispielsweise, was an der Systemarchitektur geändert werden muss, damit sich ein System von Prozessor A nach Prozessor B portieren lässt. Prüfungen sind immer dann die erste Wahl, wenn ein System nicht ausgeführt werden kann:

"You can't test what you can't execute!"
(Bruce Powel Douglass in seinem Buch "Doing Hard Time")

Als Prüfmethoden gelten typischerweise Reviews und statische Analysen, wie beispielsweise mit Compiler oder LINT. Prüfungen sind eher allgemein und übergreifend ausgelegt, während Tests exakt ablaufen und konkretere Ergebnisse liefern. So gesehen kann der Test als eine Variante der Prüfung gelten - wenn auch die aussagekräftigste und wichtigste.

Testname	ZugEinfahrt1
Testziel	Testen des Systemverhaltens bei Einfahrt eines Zuges mit einem Wagen
Testfallbeschreibung	Ein Zug mit einem Wagen fährt von rechts in den Bahnübergang ein.
Erwartete Ergebnisse	1. Ampel blinkt rot (ca. 1s) 2. Ampel schaltet um auf Rot 3. Schranke schließt, bis sie sich in waagrechter Position befindet
Konkretes Vorgehen	Vorbedingungen: - Schranke geöffnet - Ampel grün Vorgehen: 1. Drücken des rechten Einfahrschalters (1x) ...

Beispiel für die tabellarische Darstellung eines Testfalls

Gesamten Trend Guide "Embedded-Test" als PDF downloaden.

MicroConsult unterstützt Sie mit Training & Coaching rund um das Thema Embedded-Test:

• Embedded-Software-Test für C: Best Practices für den Unit-/Modul-/Komponenten-Test
• Embedded-Software-Test objektorientiert für C++: Best Practices für den Klassen- und Komponenten-Test
• Qualität, Test und Softwareentwicklung im Medizinbereich
• ISTQB® Certified Tester Foundation Level - Testen von Embedded- und IT-Systemen
• Agiles Testen und Test Driven Development von Embedded-Systemen (Agile TDD)
• Embedded-Linux für Tester, Support und Service

Training & Coaching zu den Themen unseren Portfolios finden Sie hier.

Darüber hinaus besteht die Möglichkeit, das Themenfeld Embedded-Software-Test auch in maßgeschneiderten Workshops zu behandeln. Sie werden auf die speziellen Bedürfnisse von Aufgaben, Projekten, Teams und Rollen zugeschnitten.
Setzen Sie sich mit uns Verbindung! Zum Kontaktformular

 

Weitere Trend Guides