Startseite > Automotive > Software + Tools > Auf Nummer sicher

Effizienter Test von Software-Varianten

Auf Nummer sicher

27. Juli 2018, 10:30 Uhr | Von Michael Wittner

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Analyse der Software-Hierarchie

Die Menge der zu testenden Software-Varianten ergibt sich automatisch aus allen möglichen Konfigurationen einer Software. Für den Test ist dabei zu berücksichtigen, ob eine Variante – beispielsweise die Basis-Konfiguration – tatsächlich getestet werden kann: Ob es sich also um eine ausführbare Software handelt oder nur um eine Basis-Konfiguration, die alleine für sich noch keine funktionale Einheit bildet. Für solche abstrakten Varianten können unter Umständen auch schon abstrakte Tests definiert werden. Allerdings entstehen erst durch die weitere Implementierung solcher Tests für eine bestimmte funktionale Variante tatsächlich ausführbare Tests.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Auf der anderen Seite dient die Definition einer Varianten-Hierarchie vor allem der besseren Übersichtlichkeit bei verschachtelten Software-Varianten. In der vorgestellten Methode werden die Varianten in einem Variantenbaum angelegt, der durchaus mehrstufig sein kann und die Variantenstruktur der Software abbildet. Dieser Baum dient der Orientierung, welche Tests auf welchem Varianten-Level erstellt werden sollen.

Das Beispiel in Bild 4 zeigt eine Variantenhierarchie verschiedener Fahrzeuge, wobei es für Lkw die Varianten mit fest verbundenem oder optional zuschaltbarem Zusatztank gibt. Die Variante „Truck“ könnte in diesem Fall eine abstrakte Konfiguration oder auch eine konkrete Ausprägung eines Fahrzeugs sein.

Konfiguration oder auch eine konkrete Ausprägung eines Fahrzeugs sein.

Definition von Varianten-Tests

Tests können in zwei unterschiedliche Arten unterteilt werden:

Basistests
Variantentests

Die Basistests beziehen sich auf abstrakte Funktionen, also beispielsweise auf die Grundkonfiguration eines Software-Moduls. Auf dieser Ebene können bereits alle potenziellen Testfälle der aus diesem Basismodul abgeleiteten Varianten definiert werden.

Auch erste Testdaten können für Basistests bereits festgelegt werden, sie müssen aber nicht vollständig sein – weil man sie sowieso noch nicht ausführen möchte. Auf der obersten Ebene eines Variantenbaums lassen sich die möglichen Testfälle beispielsweise mit Hilfe eines Klassifikationsbaums definieren. Die untenstehende Testspezifikation berücksichtigt alle Varianten des genannten Beispiels.

Die Testspezifikation (Bild 5) beschreibt die notwendigen Tests, die nun im Variantenbaum weitervererbt werden: Die geerbten Tests können in jeder Variante geändert, ausgeblendet oder mit spezifischen Tests ergänzt werden. In Bild 6 sind beispielsweise alle Tests ausgeblendet, die sich nicht auf die Variante „Pkw“ beziehen.

Jeder übergeordnete Variantentest muss somit nur einmalig angelegt und bei einer neuen Anforderung und Änderung der Applikation nur an einer Stelle gepflegt werden.

Regeln zur Vererbung von Testfällen

Im Beispiel wurden auf oberster Ebene sämtliche möglichen Testfälle definiert. Für manche Varianten, beispielweise „Pkw“, sind aber nur einige dieser Testfälle sinnvoll: Daher sind Operationen für die Vererbung von Testfällen nötig:

Ändern von geerbten Testdaten
Löschen oder Ausblenden von geerbten Testfällen
Hinzufügen zusätzlicher Testfälle

Auf der Ebene der Testdaten muss ebenfalls unterschieden werden, ob ein Wert geerbt oder nur lokal definiert wurde. Bei der Synchronisation der Varianten werden alle geerbten Werte aktualisiert. Für den Wert einer Variablen in einem Variantentest ergeben sich damit folgende Zustände:

Wert wurde geerbt
Wert wurde geerbt und überschrieben
Wert wurde lokal für diesen Variantentest definiert.

Über eine Farbcodierung lassen sich diese Werte wie in Bild 7 gezeigt leicht unterscheiden: Die hellblauen Werte wurden geerbt, der lilafarbene Wert wurde in der Variante dagegen überschrieben.

Eindeutige Identifizierung von Testfällen

Für die eindeutige Identifikation werden jedem Basistestfall ein „Universal Unique Identifier“ (UUID) zugeordnet. Diese UUIDs werden weltweit und zeitlich eindeutig generiert. Wenn ein Testfall nun an eine Variante vererbt wird, dann handelt es sich bei dem geerbten und für die Variante angepassten Testfall letztlich um denselben (Basis-)Testfall. Bei einem Review der Tests können die geerbten Testfälle damit eindeutig mit den Basistests oder den Tests einer anderen Variante verglichen werden. Die Zuordnung von UUIDS ermöglicht auch ein räumlich verteiltes Arbeiten an Variantentests, weil sämtliche Testfälle eindeutig definiert sind und die Tests deshalb problemlos wieder zusammengeführt und aktualisiert werden können.

Ergebnisse

Für das gezeigte Variantenbeispiel wurde folgende Strategie für die Definition von Tests verwendet:

Übernahme der Variantendefinitionen aus dem Applikations-Design
Definition aller möglichen Testfälle auf oberster Ebene für alle möglichen Varianten
Ausblendung der nicht benötigten Testfälle in jeder Variante
Ergänzung oder Implementierung der Tests jeweils getrennt in jeder Variante

Der Vorteil dieser Vorgehensweise liegt in der zentralen Spezifikation der Testfälle in einem einzigen Klassifikationsbaum. Das erhöht die Übersichtlichkeit und gibt einen vollständigen Überblick über alle Tests bei einem Review.
Das Ausblenden von nicht benötigten Testfällen in Varianten ist relativ einfach und bewirkt gleichzeitig, dass sich der Testingenieur Gedanken darüber machen muss, welcher Testfall für seine Variante tatsächlich notwendig ist.

Der Autor

Michael Wittner

ist seit vielen Jahren im Bereich Software-Entwicklung und Test tätig. Nach dem Studium der Informatik an der TU Berlin arbeitete er als wissenschaftlicher Mitarbeiter bei Daimler an der Entwicklung von Testmethoden und Testwerkzeugen. Seit 1997 ist er geschäftsführender Gesellschafter von Razorcat Development, dem Hersteller der Testwerkzeuge Tessy und CTE.