Ein Angebot von

Sind Ihre Testfälle gut genug? Was Testfallgüte für die Fehlerfindung bedeutet

| Autor / Redakteur: Frank Büchner* / Sebastian Gerstl

Methoden zur Bestimmung der Testfallgüte

Äquivalenzklassenbildung

Ein ständiges Problem bei der Testfallerstellung ist, dass eine Eingangsvariable zu viele mögliche Werte annehmen kann und es ist praktisch unmöglich, alle diese Werte in Testfällen zu benutzen, insbesondere wenn diese Werte noch mit allen möglichen Werten anderer Eingangsvariablen kombiniert werden sollen (kombinatorische Explosion). Die Bildung von Äquivalenzklassen adressiert dieses Problem.

Äquivalenzklassenbildung ordnet jedem möglichen Eingangswert eine Klasse zu. Die Klassen werden dabei so gebildet, dass alle Werte in einer Klasse als äquivalent für den Test betrachtet werden. Äquivalent für den Test heißt hier, dass man davon ausgeht, falls ein Wert aus einer bestimmten Klassen einen bestimmten Fehler aufdeckt, dies auch alle anderen Werte in dieser Klasse tun. Unter dieser Annahme kann man einen beliebigen Wert aus einer Klasse als Stellvertreter für alle anderen Werte in dieser Klasse betrachten. Damit hat man die Werte, die ein bestimmter Eingangswert annehmen kann, u.U. beträchtlich reduziert und somit die Kombination mit anderen Werten praktikabel gemacht. Ein Beispiel ist Bild 6 zu entnehmen.

Wir müssen uns aber darüber im Klaren sein, dass ein Fehler bei der Äquivalenzklassenbildung dazu führen kann, dass eben nicht alle Werte in einer Klasse äquivalent für den Test sind und falls überdies für den Test derjenige Wert gewählt wird, der einen bestimmten Fehler nicht aufdeckt, obwohl er es sollte, schlüpft dieser Fehler durch. Es liegt in der Verantwortung des menschlichen Äquivalenzklassenbildners, die Klassen sorgfältig zu bilden.

Die Klassifikationsbaummethode

Die Klassifikationsbaummethode (KBM) ist eine Methode zur Testfallspezifikation, welche die Methoden anwendet, die wir bis jetzt kennengelernt haben.

Die Klassifikationsbaummethode beginnt mit der Analyse der Anforderungen. Daraus ergibt sich, welche relevanten Eingaben es gibt. Relevante Eingaben sind solche, die man während der Tests variieren möchte. Nun macht man sich Gedanken über die Werte, die eine relevante Eingabe annehmen kann. Sind es zu viele Werte, bildet man Klassen nach der Äquivalenzklassenmethode. Dann berücksichtigt man Grenzwerte, illegale und extreme Eingabewerte.

Daraus ergibt sich der sogenannte Klassifikationsbaum. Er bildet den oberen Teil einer Testfallspezifikation nach der Klassifikationsbaummethode. Die Wurzel des Baums ist oben, der Baum wächst von oben nach unten, die Blätter des Baums bilden den Kopf der Kombinationstabelle. Die Kombinationstabelle ist der untere Teil einer Testfallspezifikation nach der Klassifikationsbaummethode. Jede Zeile stellt einen Testfall dar. Aus welchen Klassen Werte in einem Testfall verwendet werden, wird durch Markierungen auf den Linien festgelegt. Sowohl das Entwerfen des Baums als auch die Entscheidung über die Anzahl der Testfälle sowie das Setzen der Markierungen in den Zeilen sind menschliche Aufgaben (und deshalb leider auch dem menschlichen Irrtum unterworfen).

Bild 7 ist ein Beispiel für eine Testfallspezifikation nach Klassifikationsbaummethode (KBM). Die Wurzel des Baums ist mit „Suspension“ bezeichnet, d.h. das Testobjekt scheint die Aufhängung eines Kraftfahrzeugs zu sein. Für ihren Test werden zwei (testrelevante) Aspekte betrachtet, nämlich Geschwindigkeit („speed“) und Lenkwinkel („Steering angle“). Beides sind Klassifikationen; diese werden in rechteckigen Rahmen dargestellt. Beide Klassifikationen sind in Äquivalenzklassen eingeteilt. Äquivalenzklassen werden ohne Rahmen dargestellt. Für „Steering Angle” gibt es drei Äquivalenzklassen: „left”, „central” und „right”. Aus dem Klassifikationsbaum können wir nicht erkennen, wie die Werte in einer bestimmten Klasse codiert sind. Das ist abhängig von der Implementierung und interessiert im Rahmen der Klassifikationsbaummethode nicht, da diese auf einem Black-Box-Ansatz basiert. Deshalb ist die Testfallspezifikation nach der Klassifikationsbaummethode abstrakt.

Wenn man nun nicht „central” als extremen Lenkwinkel betrachtet, gibt es für Lenkwinkel keine Grenz-, Extrem- bzw. illegalen Werte. Bei „speed“ ist die anders. Die Klassifikation „speed“ ist in die zwei Äquivalenzklassen „valid“ und „invalid“ aufgeteilt. Letztere Klasse garantiert, dass beim Test ungültige Werte für „speed“ verwendet werden, weil jede Klasse im Baum mindestens einmal für einen Testfall ausgewählt werden muss. Die Klasse „invalid“ ist weiter unterteilt nach der Klassifikation „Too low or too high?”. Das ergibt die zusätzlichen Klassen „negative” und „> v_max”. Testfälle mit Werten aus diesen Klassen finden heraus, was passiert, wenn das Unerwartete / Unmögliche eintritt. Die gültigen Geschwindigkeiten sind in „normal” und „extreme” Geschwindigkeiten eingeteilt. Wir können annehmen, dass die Klasse „zero” für eine gültige Geschwindigkeit nur einen einzigen Wert (wahrscheinlich den Wert 0) enthält, ebenso wie die Klasse „v_max“ (die wahrscheinlich den maximalen Wert aus den Anforderungen enthält). Dies sind Grenzwerte.

Die Kombinationstabelle (der untere Teil der obigen Abbildung) besteht aus sieben Zeilen und spezifiziert somit sieben Testfälle. Die Testfälle können benannt sein. Die Markierungen in jeder Zeile geben an, aus welchen Klassen für diesen Testfall Werte ausgewählt werden. Dies ergibt die (abstrakte) Testfallspezifikation, die den Zweck eines Testfalls anzeigt. Im vorliegenden Beispiel wird dies auch durch den Namen des Testfalls ausgedrückt, aber dies muss nicht unbedingt immer der Fall sein.

Keine Angst vor Software-Varianten – Wiederverwendung und Vererbung von Testfällen

Keine Angst vor Software-Varianten – Wiederverwendung und Vererbung von Testfällen

27.11.18 - Die Herausforderung beim Testen von Software-Varianten besteht darin, dass jede Variante vollständig getestet werden muss. Über die Definition von Basistests, die an Variantentests vererbt werden, lässt sich redundante Arbeit leicht vermeiden. Bei jeder Änderung der Applikation muss der Entwickler die Tests nur an einer Stelle pflegen. lesen

Code Coverage bei Embedded Systemen

Code Coverage bei Embedded Systemen

20.08.18 - Der Nachweis der Testabdeckung – auch Code Coverage genannt – wird von zahlreichen Normen und Standards gefordert. Welche Hürden sich damit bei Embedded Systemen ergeben, und wie dies auch mit knappen Ressourcen zu bewältigen ist, erläutert Klaus Lambertz von Verifysoft Technology im Interview. lesen

Aus der Gesamt-Testfallspezifikation erkennt man, dass es nur drei „normale“ Testfälle gibt (die ersten drei Testfälle). Man kann auch erkennen, dass es beispielsweise einen „normalen“ Testfall mit geringer Geschwindigkeit und Lenkwinkel nach rechts nicht gibt. Gegebenenfalls kann man weitere „normale“ Testfälle hinzufügen. Allerdings geht es hier nicht um die Frage, ob drei normale Testfälle ausreichend sind oder nicht, sondern der Punkt ist, dass es offensichtlich ist, dass es nur drei normale Testfälle gibt. Das ist ein wichtiger Vorteil der Klassifikationsbaummethode.

Das Unit-Test-Werkzeug TESSY enthält einen graphischen Editor für Klassifikationsbäume. Somit können Unit-Tests für TESSY komfortabel anhand der Klassifikationsbaummethode spezifiziert werden.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45686267 / Test & Qualität)