Entscheidungstabellen zur Testdatenermittlung

Transkript

1 Entscheidungstabellen zur Testdatenermittlung ÜBERBLICK... 2 ERSTELLUNG VON ENTSCHEIUNGSTABELLEN AUFBAU VON ENTSCHEIUNGSTABELLEN BEISPIEL KFZ-VERSICHERUNG VARIANTEN VALIIERUNG VON ENTSCHEIUNGSTABELLEN STRATEGIEN ZUR GENERIERUNG VON TESTATEN ZUSAMMENFASSUNG... 7 Überblick In den bisherigen Referaten (z.b. strukturbasierte Tests, zustandsbasierte Tests ) wurde betrachtet, wie man Testfälle generieren kann. Im Fokus dieses Referats stehen Testdaten, wobei im Folgenden ein strukturiertes Verfahren zur Ermittlung von Testdaten vorgestellt wird. Für viele Softwareapplikationen gilt, dass eine Kombination von Inputvariablen zu bestimmten Aktionen führt. Mit Hilfe der kombinatorischen Logik kann man hierfür effektive Testmodelle erstellen, wobei sich Entscheidungstabellen zum Aufbau dieser Testmodelle eignen. azu müssen die folgenden Schritte durchgeführt werden: Modellierung der Spezifikation mittels einer Entscheidungstabelle Validierung der Entscheidungstabelle Ableiten einer logischen Funktion (optional, weil die logische Funktion nicht für alle Generierungsstrategien benötigt wird) Wahl der Strategie zur Generierung der Testdaten Generierung von Testdaten Jeder dieser Schritte kann auf vielfältige Weise ausgeführt werden. Im Folgenden wird eine mögliche Vorgehensweise erläutert, die insbesondere für kleine bis mittlere Modelle angewendet werden kann und sich auch für einige große Modelle als nützlich erwiesen hat. 2 Erstellung von Entscheidungstabellen Möchte man mit Hilfe von Entscheidungstabellen Testdaten ermitteln, so muss die IUT (implementation under test) folgende Voraussetzungen erfüllen: Abhängig von den Inputvariablen muss eine bestimmte Aktion ausgelöst werden. er Anwendungsfall muss durch disjunkte boolesche Ausdrücke darstellbar sein. ie auszulösende Aktion muss unabhängig sein von der Reihenfolge der Inputvariablen und früheren Ein- und Ausgaben. Erfüllt die IUT diese Kriterien, so sind Entscheidungstabellen zum Testen dieser IUT geeignet. Um eine Entscheidungstabelle zu erstellen, muss man zuerst die Entscheidungsvariablen und Bedingungen identifizieren. Anschließend sollten die zu produzierenden Aktionen ermittelt werden. iese Aktionen müssen einer bestimmten Kombination von Bedingungen zugeordnet werden. Im letzten Schritt sollte die logische Funktion des Modells abgeleitet werden, um seine Vollständigkeit und Konsistenz validieren zu können. 2. Aufbau von Entscheidungstabellen Eine Entscheidungstabelle besteht aus zwei Teilen: dem Bedingungsteil ( condition section ) und dem Aktionsteil ( action section ). er Bedingungsteil enthält zeilenweise die Entscheidungsvariablen mit den dazugehörigen Bedingungen, die jeweils true oder false sein können. Im Aktionsteil werden die möglichen Aktionen aufgelistet, die erzeugt werden, wenn die korrespondierende Kombination der Bedingungen erfüllt ist. Jede Spalte stellt eine einzelne Kombination von Bedingungen und daraus resultierenden Aktionen dar und wird als eine Variante bezeichnet. Entscheidungstabellen zur Testdatenermittlung

2 2.2 Beispiel Kfz-Versicherung Betrachtet wird das Modell einer Kfz-Versicherung, das als Entscheidungsvariablen die Anzahl der Schadensfälle und das Alter des Versicherten hat. In Abhängigkeit der Entscheidungsvariablen sind die folgenden Aktionen möglich: Erhöhung der Versicherungsprämie Senden einer Kündigungswarnung Kündigung der Versicherung as Modell ist im Folgenden in einer Entscheidungstabelle dargestellt: Abb.: Entscheidungstabelle des Beispiels der Kfz-Versicherung Spaltenweise kann man nun die einzelnen Varianten betrachten. ie Variante besagt z.b., dass bei keinen Schadensfall und einem Alter des Versicherten kleiner oder gleich 25 die Prämie um 5$ erhöht, keine Kündigungswarnung gesendet und die Versicherung auch nicht gekündigt wird. Möchte man diese Entscheidungstabelle in eine Wahrheitstabelle überführen, so wird jeder Bedingung eine Variable zugeordnet, die jeweils true oder false sein kann. 2.3 Varianten Eine Entscheidungstabelle mit n Bedingungen kann maimal 2 n Varianten haben, wobei meistens nicht alle von Bedeutung sind. Beispielsweise gibt es in dem Beispiel der Kfz-Versicherung sechs Bedingungen, d.h. es resultieren daraus 2 6 = 64 mögliche Varianten. In der Entscheidungstabelle sind allerdings nur sieben aufgeführt. iese sieben werden eplizite Varianten genannt. ie anderen 57 Varianten werden als implizite Varianten bezeichnet. Solche impliziten Varianten können aus don t care, type safe eclusion, don t know oder can t happen Bedingungen resultieren. don't care: Eine Bedingung wird als don t care bezeichnet, wenn das Ergebnis der Bedingung keine Auswirkung auf die resultierende Aktion hat. ie entsprechende Variante wird also ausgewählt, ohne dass beachtet werden muss, ob die don t care Bedingung erfüllt ist oder nicht. Im Beispiel der Kfz- Versicherung ist bei der Variante 7 das Alter des Versicherten ein don t care, weil die Versicherung in jedem Fall gekündigt wird, egal wie alt der Versicherte ist. type safe eclusion: Eine type safe eclusion tritt auf, wenn mehrere Bedingungen für eine nichtbinäre Entscheidungsvariable definiert sind, die Entscheidungsvariable allerdings nur einen Wert zu einem Zeitpunkt annehmen kann. Im Beispiel der Kfz-Versicherung kann die Anzahl der Schadensfälle nicht gleichzeitig und 3 sein - wenn ein Wert auftritt, werden alle anderen ausgeschlossen. don't know: iese Bedingung reflektiert ein unvollständiges Modell. Beispielsweise kann eine don t know Bedingung daraus entstehen, dass die Grenzen einer Entscheidungsvariable nicht eindeutig spezifiziert sind. Im Beispiel der Kfz-Versicherung liefert die Entscheidungstabelle keine Informationen darüber, was passieren soll, wenn das Alter des Versicherten < 3 Jahre ist. Eigentlich kann man aber davon ausgehen, dass die Kfz-Versicherung nicht daran interessiert ist, Personen zu versichern, die jünger als drei Jahre alt sind. Entscheidungstabellen zur Testdatenermittlung 2

3 can't happen: iese Bedingung beruht auf der Annahme, dass einige Inputs sich ausschließen bzw. nicht durch ihre Umgebung erzeugt werden können. Beispielsweise kann AB nicht true sein, wenn A = true und B = false ist. 3 Validierung von Entscheidungstabellen Bevor man mit Hilfe der Entscheidungstabelle Testdaten ermittelt, sollte die Entscheidungstabelle validiert werden, um sicherzustellen, dass diese testbar, vollständig, konsistent und frei von technischen Fehlern ist. urch die Validierung können Fehler und Auslassungen schon vor der Entwicklung der Testsuite aufgedeckt werden. Somit wird die Effektivität und Effizienz der Testsuite erhöht. Bei der Validierung bietet sich die folgende Vorgehensweise an: Inhaltsüberprüfung: mit Hilfe einer content checklist wird beispielsweise überprüft, ob die einzelnen Varianten sich gegenseitig ausschließen oder ob die auszulösende Aktion unabhängig von früheren Aktionen ist. Eine ausführliche content checklist ist in Robert V. Binders Testing Object-Oriented Systems (siehe Literaturverzeichnis) auf S.5 aufgeführt. Überprüfung der logischen Funktion: Beim manuellen Abschreiben bzw. Erstellen der Wahrheitstabelle oder logischen Funktion können leicht Fehler auftreten. eshalb sollte die logische Funktion z.b. durch eine automatische Erstellung der Wahrheitstabelle überprüft werden. Plausibilitätscheck: Es wird anhand der Anforderungen und der Spezifikation die technische Konsistenz überprüft. Beispielsweise sollte die don t know Bedingung des Kfz-Versicherungsbeispiels (Alter des Versicherten < 3 Jahre) während des Plausibilitätschecks aufgedeckt werden. 4 Strategien zur Generierung von Testdaten Robert V. Binder stellt folgende fünf verschiedene Teststrategien vor, mit denen Testdaten generiert werden können: All-Eplicit-Variants All-Variants/ All-True/ All-False/ All-Primes Each Condition/ All Condition B eterminants Variable Negation Wir werden auf die einzelnen Strategien anhand des nächsten Beispiels eingehen. Gegeben sei hierbei die folgende Tabelle (Abb. 2): Variante A B C Z Abb. 2: Beispiel einer Wahrheitstabelle Z stellt die Ausgangsvariable dar, abhängig von der Eingangsbelegung A, B, C und. Für alle vier Variablen eistieren 6 mögliche Kombinationen, die jeweils einer Zeile der Tabelle entsprechen (Variante bis 5). Z kann man als Funktion von A, B, C und interpretieren und ergibt sich aus den Variablenkombinationen, in denen Z = ist. So ergibt sich für Z: Entscheidungstabellen zur Testdatenermittlung 3

4 ( A B C ) + ( A B C ) + ( A B C ) + ( A B C ) ( A B C ) Z = + iese logische Gleichung lässt sich mit den Regeln von e Morgan umformen, so dass sich die kurze Form für Z ergibt: ( + ) oder Z = A A B C Z = A B C + All-Eplicit-Variants: Bei dieser Strategie wird jede einzelne eplizite Variante mindestens einmal getestet. Eplizit bedeutet hierbei, dass nur die Varianten getestet werden, die in der Entscheidungstabelle aufgeführt werden. Wenn ein Fehler auftritt, weil zum Beispiel can t happen oder don`t know Bedingungen auftreten, wird dieses in der Testsuite nicht erfasst. ie Fehler werden nicht aufgedeckt. ie Strategie eignet sich auch für Entscheidungstabellen mit nicht-binären Variablen. Im Versicherungsbeispiel würde die Testsuite den Varianten -7 (siehe Abb. ) entsprechen. Im Falle einer binären Entscheidungstabelle entspricht die All-Eplicit-Variants-Strategie der All-True-Strategie. Sie entspricht der Minimalanforderung für jede Variablenanzahl. zugehörige Testsuite: { 9,, 2, 3, 5 } All Variants: iese Strategie entspricht dem vollständigen Test und überprüft alle (eplizite und implizite) Varianten. ie Testsuite besteht folglich bei n Variablen aus 2 n Varianten, die alle überprüft werden. as entspricht einem Fehlererkennungsgrad von %. abei steigt jedoch die Menge der Testdaten eponentiell mit der Anzahl der Variablen, so dass diese Strategie nur für Probleme mit kleiner Variablenanzahl (n 7) geeignet ist. zugehörige Testsuite: {,,, 5} All-True: Bei dieser Strategie werden alle Varianten geprüft, bei denen eine Aktion ausgelöst wird (Z=). as entspricht dem Testen aller Min-Terme (Summe der Produktterme). Bei Anwendung dieser Strategie sollte das Verhalten im False-Fall von geringer Bedeutung sein, da diese Varianten nicht getestet werden. zugehörige Testsuite: { 9,, 2, 3, 5 } All-False: iese Strategie testet analog nur diejenigen Varianten, welche die Aktion nicht auslösen. ie Testsuite besteht folglich aus dem Komplement der Testsuite der All-True-Strategie. Entsprechend sollte möglichst nur aus den False-Fällen wichtiges Verhalten folgen. zugehörige Testsuite: {,, 2, 3, 4, 5, 6, 7, 8,, 4 } All-Primes: Bei dieser Strategie wird jeder Produktterm mindestens einmal getestet, wobei hierzu die logische Funktion in Form der minimalen Summe der Produkte vorliegen muss. Hierbei wird eine Testsuite gewählt, so dass alle Produktterme mindestens einmal true sind. Auch die All-Primes- Strategie entspricht der Minimalanforderung für jede Variablenanzahl. zugehörige Testsuite: { 3 } oder { 9, 2 } Each Condition/ All Condition-Strategie: Hinter dieser Strategie verbergen sich Heuristiken zur Reduktion der Testdaten. iese können nur für Ausdrücke angewendet werden, die logische Operationen wie AN und OR enthalten. Es werden Testfälle durch die Bildung der true-singletons - Varianten erzeugt. abei wird nacheinander jeder Produktterm betrachtet. Jede Variable dieses Terms wird einmal true gesetzt. Gleichzeitig sollen alle anderen Faktoren des Produktterms false sein. Abb. 3: true-singletons -Varianten A B C Ergebnis A true B true C true A, B, C true A Ergebnis A true true A, true Entscheidungstabellen zur Testdatenermittlung 4

5 Nun sucht man sich aus der gegebenen Wahrheitstabelle die Varianten heraus, die der ermittelten Variablenbelegung entsprechen und erhält für Produktterm AB C die Testsuite {, 6,, 2 } und für A die Testsuite {, 8, 9 }. Beide Mengen werden vereinigt und man erhält (wie unten aufgeführt) die zugehörige Testsuite. ie Strategie ist für jede Variablenanzahl geeignet, weil nur die wesentlichen Primterme betrachtet werden. as reduziert die Testsuite. zugehörige Testsuite: {,, 6, 8, 9,, 2 } Binary ecision iagramm (B): Mit dieser Strategie wird eine gegebene Wahrheitstabelle in eine kompakte Form umgewandelt, so dass sich die Anzahl der Testdaten und damit die Testsuite reduziert. abei geht man folgendermaßen vor: ie Variablenbelegung aus der Wahrheitstabelle wird in einen binären Baum überführt, wobei A, B, C und die Knoten darstellen.ie Belegungen für Z sind die einzelnen Blätter. abei stellen die linken Kanten den False-Fall und die rechten Kanten den True-Fall dar. Unsere Wahrheitstabelle umgewandelt würde als Baum wie folgt aussehen: Abb. 4: Binärbaum Anschließend werden die Knoten zusammengefasst. Man arbeitet sich von links unten nach oben durch und vergleicht die Blätter eines Knoten. Sind diese gleich, so werden sie gelöscht und der Knoten wird durch eines der Blätter ersetzt. In unserem Beispiel lässt sich dadurch die gesamte linke Baumseite auf reduzieren, das heißt Z ist abhängig davon, ob A true ist. Wenn die Blätter unter einem Knoten verschieden sein, wird dieser gelöscht und durch ein Blatt mit der Knotenvariable ersetzt. Abb. 5: Reduktion des Binärbaums Entscheidungstabellen zur Testdatenermittlung 5

6 Wir erhalten nach Anwendung dieser Regel folgenden B-Baum mit vier Varianten: Abb. 6: B-Baum iesen Restbaum überführt man dann in eine B-Tabelle, die in unserem Beispiel folgendermaßen aussieht: B Variante A B C Z Abb. 7: B-Tabelle Jede Zeile entspricht dabei einem Pfad von der Wurzel bis zum Blatt im Baum. Hier ist allerdings zu erkennen, dass Z von abhängig ist (siehe Zeile 2 und 3). Um die Testsuite zu erhalten, müssen Kombinationen mit variablenabhängigen Ergebnissen aufgeschlüsselt werden. Sprich wird für die zweite und dritte Zeile bzw. gesetzt, wie aus Abbildung 8 zu entnehmen ist. Jede Zeile entspricht dabei einem Testdatum, für den noch die don`t care Variablen vergeben werden müssen. zugehörige Testsuite : {, 8, 9, 2, 4, 5 } Abb. 8: B-Testsuite Entscheidungstabellen zur Testdatenermittlung 6

7 Variable Negation: Bei dieser Strategie werden zusätzlich Fehler aufgedeckt, weil mit der Strategie Fehler der don`t-care -Fälle aufgedeckt werden können. azu muss unsere logische Funktion in der Form der Summe von Produkten gegeben sein, was in unserem Beispiel der Fall ist. ie Testsuite besteht dann aus den unique true points und den near false points, welche sich folgendermaßen ergeben: Unique true points: Es wird die Variante gesucht, die den betrachteten Produktterm true, dabei aber alle anderen Produktterme false setzt. So geht man sicher, dass der andere Produktterm den betrachteten nicht beeinflusst. In Frage kommen für den Term AB C die Variante 2 und 3 unseres Beispiels. a aber Zeile 3 auch den Produktterm A true setzt, stellt nur Zeile 2 einen unique true point dar (Testkandidat ). Für den Produktterm A ergibt sich entsprechend Zeile 9, und 5 als unique true point. Es kommt auch vor, dass solche Varianten nicht eistieren. Near false points: Nachdem für jeden Produktterm ein unique true point gefunden worden ist, werden alle einzelnen Faktoren nacheinander negiert und dabei alle anderen gleich gelassen. Es werden nun diejenigen Varianten in das Testkandidatenset übernommen, für welche Z = gilt. So werden auch die don`t- care -Variablen überprüft, indem z. B. für A sämtliche Kombinationen (von A, B, C, ) in das Testkandidatenset aufgenommen werden, die das Kriterium erfüllen (A true und und Z=). as würde dann in unserem Beispiel wie folgt aussehen: AB C false Produkttermnegationen Mögliche Varianten Testkandidatenset Testkandidatenset Nr. A B C 2, 3 3 A B C 4, A B C 8, A B C 4, 5 4, 5 4 A 9,, 3, 5 9,, 5 5 A 8,, 2, 4 8,, 4 6 A, 3, 5, 7, 3, 5, 7 7 Abb. 9: Erstellung der Testkandidaten ie Testkandidatensets enthalten nun eine oder mehrere Varianten, die sich in einer Matri darstellen lassen. Hierbei werden den einzelnen Testkandidaten in einer Tabelle die einzelnen Varianten zugeordnet, so dass man ablesen kann, welche Varianten zum Testen notwendig sind. a Varianten auch mehr als einmal vorkommen, kann die Testdatenmenge geringer ausfallen als die ursprünglich vorgesehene Zahl. as wiederum reduziert den Testumfang und erleichtert somit die Überprüfung der Testdaten. zugehörige Testsuite: { 5, 8,, 2, 4 } 5 Zusammenfassung Insgesamt lässt sich festhalten, dass Entscheidungstabellen effektiv dazu verwendet werden können, um Testdaten zu ermitteln und somit Fehler in der Spezifikation und deren Implementierung aufzudecken. Hierbei ist eine sorgfältige Erstellung der Entscheidungstabelle nötig, weil das Problem auf binäre Ausdrücke reduziert wird und allein eine falsche Belegung weitreichende Folgen haben könnte. ie Wahl der Teststrategie ist abhängig von der Anforderung an die zu testende Software. Beispielsweise ist der Test aller Varianten unnötig, wenn laut Anforderung nur True-Fälle relevant sind und das Verhalten im False-Fall keine Rolle spielt. Literatur ROBERT V. BINER: Testing Object-Oriented Systems - Models, Patterns, and Tools (Addison-Wesley, 2) Entscheidungstabellen zur Testdatenermittlung 7