Startseite > Automotive > Modellbasiert entwickeln, automatisch testen

Entwicklungsprozess bei Continental

Modellbasiert entwickeln, automatisch testen

13. Mai 2011, 11:30 Uhr | Von Dr. Marco Kunze und Dr. Thomas Burger

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 4

Flexible Testdokumentation

Die MBD Test Suite definiert jeden Schritt des Arbeitsablaufs und die Verantwortlichkeiten jeder Rolle. Unterstützt wird dies durch eine Verfahrensbeschreibung mit Arbeitsfluss-Diagrammen (Bild 2), den exakt auf den Arbeitsablauf zugeschnittenen SDA Simulation Manager sowie eine XML-basierte Testdokumentation. Diese ist voll mit dem SDA Simulation Project (Testharness) und dem SDA Simulation Manager integriert. Darüber hinaus verknüpft dieses XML-Dokument das Testobjekt mit allen Anforderungsdokumenten und Änderungsanforderungen. Für verschiedene Projektszenarien werden unterschiedliche Dokumententypen sowie verschiedene Schnittstellen zu Anforderungs- und Veränderungs-Management-Werkzeugen unterstützt.

Während des Entwurfs sowie der Testentwicklung und -ausführung wird die Testdokumentation auf dem lokalen Test-PC als ein einziges XML-Dokument zusammen mit dem SDA-Modell gespeichert. Alle Entwurfs- und Testaktivitäten können dadurch auch offline durchgeführt werden, beispielsweise in einem Testfahrzeug. Alle testrelevanten Informationen sind so in einem Gesamtdokument konzentriert, was die Handhabung vereinfacht und die Arbeitseffizienz verbessert. Trotzdem kann dieses Dokument zu Konfigurations-, Test-Management- und Prozesszwecken in verschiedene Ansichten aufgeteilt und gespeichert oder in Kurzform in einer Datenbank gespeichert werden. Ein separater Bericht des Testergebnisses lässt sich beispielsweise aus der Test-Report-Ansicht erzeugen und als PDF-Datei speichern. Die mit der MBD Test Suite erstellte Dokumentation lässt sich entsprechend ihrer Abschnitte dynamisch filtern und ist in folgende Ansichten organisiert:

Allgemeine Information: Dieser Abschnitt enthält die Namen der Entwickler und deren jeweilige Rollen sowie Kommentare, Projektinformationen und Informationen über Testobjekte.
Dokumenten-Referenzliste: Referenz über testrelevante Dokumente. Referenzen werden mit Namen, Version und einer Kennung sowie anderen Attributen gespeichert, die vom jeweils zur Speicherung der Dokumente eingesetzten Werkzeug, z.B. Konfigurations- oder Änderungsverwaltungs-Werkzeug, abhängen. Die eingesetzten Werkzeuge variieren je nach Projekt und Geschäftsbereich.
Anforderungs-Referenzliste: Diese Liste enthält Referenzen zu den Anforderungsdokumenten sowie eine lokale Kopie der Anforderungen, um diese auch offline verfügbar zu machen. Derzeit werden Standardwerkzeuge zur Anforderungsverwaltung wie Doors und unternehmensinterne Werkzeuge unterstützt.
Testfall-Spezifikation: Dieser Abschnitt enthält für jeden Testfall allgemeine Informationen, eine Liste der abgedeckten Anforderungen, Listen mit Test-Fit-Kriterien und die Simulations-Spezifikation. Die Simulations-Spezifikation wird mit dem SDA Simulation Manager erzeugt und gepflegt, wodurch eine nahtlose Integration zwischen der Dokumentation durch die MBD Test Suite und dem Testharness – dem SDA Simulation Project – gewährleistet ist.
Testumgebung: Beschreibung der eingesetzten Software-Umgebung wie etwa verwendete Simulink-Blocksets und deren Version, die SDA-Version sowie die zum Rapid Prototyping eingesetzte Hardware. Die Dokumentation der Testumgebung garantiert eine vollständige Reproduzierbarkeit der ausgeführten Tests. Ein Teil der Information zur Testumgebung wird automatisch vom SDA Simulation Manager geschrieben oder überprüft.
Testbericht: Dokumentiert die Ergebnisse der Testfall-Ausführung, der Analyse und der Auswertung von Listen mit Test-Fit-Kriterien.
Defektliste: Dokumentiert entdeckte Software-Defekte und führt Referenzen zu den zugehörigen Änderungsanforderungen auf.

Die Testinformation im XML-Dokumentenschema der MBD Test Suite ist in einem maschinenlesbaren Format gespeichert und kann von verschiedenen Werkzeugen ausgelesen werden. Die Test Suite lässt sich dadurch flexibel in unterschiedlichen Werkzeugumgebungen einsetzen, ohne dass die Rückverfolgbarkeit zwischen wichtigen Dokumenten wie Anforderungen und Änderungsanforderungen beeinträchtigt wird.