ESE Fachwissen
Vom Anwendungsfall zum Testfall
Autor: Alexander Huwaldt, Laser & Co. Solutions
Beitrag - Embedded Software Engineering Kongress 2015
Ausgangspunkt und Anwendungsbereich der hier vorgestellten Methodik bilden anwenderzentrierte funktionale Systemanforderungen und daraus hergeleitete Nutzungsszenarien sogenannter User Storys eingebetteter Systeme. Für die Notation wurden UML-Anwendungsfall- und Aktivitätsdiagramme genutzt. Die so erfassten Systemanforderungen dienen als Basis zur automatischen Generierung von Testfällen für den System- und Abnahmetest.
Das UML-Anwendungsfalldiagramm ist geeignet, nach einem einfachen fast schlichten Schema Systemanforderungen mit grober Granularität zu erfassen und zu visualisieren. Dabei steht der Anwender des Systems im Mittelpunkt der Betrachtung (Use Case Driven Design, siehe dazugehörige Abbildung, PDF).
Der Anwendungsfall repräsentiert in dieser Form das Nutzungsszenario des Systems als Mensch-Maschine-Interaktion. Das Nutzungsszenario selbst wird als Aktivitätsmodell verfeinert. Dabei kann im Idealfall einer Systemanforderung genau ein typisches Nutzungsszenario zugeordnet werden. Es ist aber auch möglich, einem primären Nutzungsszenario weitere sekundäre Szenarien beizustellen, um die Komplexität der Visualisierung zu verringern. Die Interaktion wird als abwechselnde Aktivitäten und Entscheidungen zwischen Anwender und System notiert. Es entsteht ein auf den Anwender und dessen Handlungen fokussierter Ablauf, eine User Story. Die funktionalen Anforderungen an das System werden dabei systematisch weiter ausformuliert. Das Aktivitätsmodell sollte in lediglich zwei Partitionen untergliedert werden - den Anwender und das System. Die notierten Systemfunktionen müssen für den Anwender später sichtbares und somit verifizierbares Systemverhalten sein (siehe dazugehörige Abbildung, PDF).
Das Aktivitätsmodell sollte so formuliert werden, dass es für einen typischen Systemanwender leicht nachvollziehbar bleibt. Es wird somit aus dem Fundus des UML-Aktivitätsdiagramms lediglich ein kleiner Teil der möglichen Notationselemente benötigt. Neben der Generierung transparenter Testszenarien haben sich die Aktivitätsmodelle auch als Anwenderdokumentation bewährt. Änderungen der Systemanforderungen müssen immer über die Anwendungsfälle und User Storys in das Modell eingepflegt werden. Die Generierung von Testszenarien aus dem vorliegenden Modell kann mit verschiednen Überdeckungsgraden angefordert werden. Der Testdesigner hat die Möglichkeit, die generierten Szenarien zu sortieren bzw. zu priorisieren und ggf. Vor- und Nebenbedingungen der Tests zu ergänzen.
Anhand des folgenden Fallbeispiels soll der Einsatz der Methodik und der Werkzeuge kurz demonstriert werden. Bei dem vorgestellten System handelt es sich um eine Anlage zum Befüllen von Isolierfenstern mit Edelgas. Das Modell wurde zwar vereinfach, stellt jedoch die wesentlichen Elemente dar. Zunächst der schematische Aufbau der Anlage als SysML-Blockdefinitionsdiagramm. Für die Formulierung der User Storys ist die Kenntnis der Systemstruktur essentiell. Das später zu formulierende "sichtbare" Systemverhalten lässt sich nicht nur auf optische und akustische Anzeigeelemente reduzieren. So sind auch die Magnetventile, welche hörbar arbeiten, durchaus geeignet, Systemverhalten für den Tester verifizierbar zu machen (siehe dazugehörige Abbildung, PDF).
Dem Modell der Systemstruktur wird die Anwendersicht auf oberster Abstraktionsebene beigestellt, das Anwendungsfalldiagramm. Dieses bildet den Ausgangspunkt für die weitere Verfeinerung der Nutzungsszenarien. Dazu werden die Anwendungsfälle als Aktivitätsdiagramme verfeinert (siehe dazugehörige Abbildung, PDF).
Das folgende Diagramm (siehe dazugehörige Abbidlung, PDF) zeigt ein hinreichend vollständiges Nutzungsszenario der Anlage. Dabei könnte zur Verringerung der Komplexität nach Bedarf der Fall des Abbruchs des Befüllvorgangs durch den Benutzer als sekundäres Szenario noch ausgegliedert werden.
Aus diesem Aktivitätsmodell werden jetzt automatisch die möglichen Pfade mit einem vorgegebenen Überdeckungsgrad ermittelt. Die verschiedenen Pfade können im verwendeten Werkzeug als Layer visualisiert werden. Die verkleinerten Darstellungen zeigen einen Auszug aus den ermittelten Kontrollflusspfaden des obigen Ablaufmodells (siehe dazugehörige Abbildung, PDF).
Für den Testdesigner sind die ermittelten Pfade die Basis für das Erstellen der Testdokumente. Dazu kann er durch Sortieren die primären bzw. aus Anwendersicht typischen Pfade priorisieren und zusätzliche Testbedingungen ergänzen. Im nächsten Schritt generiert er aus dem so vorbereiteten Material eine Darlegung der Testfälle und Testszenarien, zum Beispiel als Textdokumente oder HTML. Weitere Ausgabeformate, wie XML zur Übergabe der Testfälle an weitere Werkzeuge, sind ebenfalls möglich. Das Testszenario wird sowohl in Textform als auch grafisch dargelegt. Die folgenden Beispiele zeigen mögliche Darlegungsformen.
Monteur: schaltet das System an
FGFS: System fährt hoch
FGFS: Geht auf Standby, LED-Anzeige Aus
Monteur: [möchte den Befüllvorgang starten] / betätigt START
FGFS: System automatisch kalibrieren
FGFS: Befüllvorgang starten, LED "füllen" an
FGFS: 20s Zwangsbefüllung
FGFS: Füllstand ermitteln
FGFS: [Gasanteil ermittelt] / Füllstand anzeigen
FGFS: [reines Gas ermittelt, Scheibe voll] / Befüllvorgang beenden
FGFS: geht auf Stand By, LED Anzeige Aus
Monteur: [möchte die Anlage ausschalten] / schaltet das System aus
(siehe dazugehörige Abbildung, PDF).
Monteur: Schaltet das System an
FGFS: System fährt hoch
FGFS: Geht auf Standby, LED-Anzeige Aus
Monteur: [möchte den Befüllvorgang starten] / betätigt START
FGFS: System automatisch kalibrieren
FGFS: Befüllvorgang starten, LED "füllen" an
FGFS: 20s Zwangsbefüllung
FGFS: Füllstand ermitteln
FGFS: [Gasanteil ermittelt] / Füllstand anzeigen
Monteur: [möchte den Befüllvorgang abbrechen] / betätigt STOPP
FGFS: Befüllvorgang beenden, LED "füllen" aus
FGFS: Geht auf Standby, LED-Anzeige Aus
Monteur: [möchte die Anlage ausschalten] / schaltet das System aus
(siehe dazugehörige Abbildung, PDF).
Monteur: Schaltet das System an
FGFS: System fährt hoch
FGFS: Geht auf Stand By, LED Anzeige Aus
Monteur: [möchte den Befüllvorgang starten] / betätigt START
FGFS: System automatisch kalibrieren
FGFS: Befüllvorgang starten, LED "füllen" an
FGFS: 20s Zwangsbefüllung
FGFS: Füllstand ermitteln
FGFS: [Gasanteil ermittelt] / Füllstand anzeigen
FGFS: [ermittelt MaxFüllzeit überschritten] / Befüllvorgang beenden
FGFS: Geht auf Standby, LED-Anzeige Aus
Monteur: [möchte die Anlage ausschalten] / schaltet das System aus
(siehe dazugehörige Abbildung, PDF).
Die vorgestellte Methodik zeichnet sich durch leicht verständliche und leicht zu notierende Darstellungen aus. Es wird bewusst nur auf wenige Modellierungselemente der UML zugegriffen. Dadurch ist deren Einführung mit wenig Lernaufwand verbunden, und es kann mit einem hohen Akzeptanzgrad bei Nicht-UML-Kundigen, wie Anwender, Auftraggeber, Techniker etc., gerechnet werden. Bei entsprechender Werkzeugunterstützung und verfügbaren Generatoren können neben den anschaulichen Diagrammen weitere Repräsentationsformen, wie Listen, Tabellen, Matrizen für Systemanforderungen, Systemfunktionen, Testszenarien und Benutzerdokumentationen, aus den einmal erstellten Modellen gewonnen werden.
Test, Qualität & Debug - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualität & Debug.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Test, Qualität & Debug - Fachwissen
Wertvolles Fachwissen zum Thema Test, Qualität & Debug steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.