Einführung

Vollständige Testautomation erfordert die Automation der üblichen Teilschritte eines Tests. Dazu gehören Testfallselektion, Vorbereitung der Testumgebung, Testausführung und Testauswertung[Sneed88]. Testvorbereitung und Testausführung sind vergleichsweise einfach zu automatisieren. Dagegen stellt die Automation von Testfallselektion und Testauswertung eine größere Herausforderung dar.

Bei der automatischen Testfallselektion stellt sich die Frage, wie die Vorgaben über die gewünschten Testfälle in Code gefasst werden sollen. Eine rein zufällige Selektion[Gerlich93] kann dazu führen, dass wichtige, aber seltene Testfälle außen vor bleiben und keine Steuerungsmöglichkeiten existieren. Eine Selektion basierend auf rein formalen Kriterien[Durrieu04][Gotlieb01][Bin02] birgt dagegen das Risiko, dass die Kriterien für die Testfallauswahl unzureichend spezifiziert werden oder gar der Selektionsprozess in eine Richtung gelenkt wird, die für die Fehleridentifikation nicht förderlich ist.

Die automatische Testauswertung wird durch das sogenannte "Orakel"-Problem behindert, also die Schwierigkeit, automatisch festzustellen, ob die Reaktion des Prüflings auf eine Testeingabe der Spezifikation oder den Erwartungen entspricht.

Beide Probleme sind nicht generell lösbar. Es existieren zwar für Teilbereiche etwa des Orakel-Problems exakte Lösungsansätze, aber die notwendigen Voraussetzungen sind in der praktischen Anwendung meist nicht gegeben oder mit erheblichem Zusatzaufwand an anderer Stelle verbunden.

Das ultimative Testziel, mit minimaler Testfallzahl alle Fehler zu finden[Myers01] dürfte sich wohl kaum generell in formale Definitionen fassen lassen.

Der hier präsentierte Ansatz integriert zufällige und formale Testfallselektion mit heuristischen Testauswertungsverfahren, um den verbleibenden manuellen Testaufwand deutlich zu reduzieren und die Konservierung und iterative Verfeinerung von Test-Know-How zu ermöglichen.

Abdeckung als Testziel?

Die Testabdeckung hat sich mehr und mehr zum hauptsächlichen Kriterium entwickelt, auf dessen Grundlage die Repräsentativität der Testergebnisse beurteilt wird. Als Testabdeckung wird überlicherweise das Verhältnis zwischen zu testenden und tatsächlich getesteten Elementen des Prüflings bezeichnet. Bekannte und übliche Kriterien sind etwa Anweisungs-, Entscheidungs- oder Bedingungsabdeckung (MC/DC), aber auch funktionale Abdeckung auf Basis einer Spezifikation.

Bei der formalen automatischen Testfallselektion wird angenommen, dass alle Testfallmengen, die das vorgegebene Abdeckungskriterium erfüllen, zueinander äquivalent sind. Das Abdeckungskriterium wird also zum absoluten Testziel erhoben.

Dabei sind die klassischen Abdeckungskriterien nicht mehr als Minimalanforderungen an den Testumfang. Eine gute Testfallmenge wird die Abdeckungskriterien so gut wie immer erfüllen. Aus einer hohen Abdeckung ist aber nicht generell auf eine hohe Repräsentativität zu schließen.

Um also sinnvoll und erfolgreich Testautomation betreiben zu können, müssen die verwendeten Abdeckungskriterien erweitert und die Absolutheit des Kriteriums für die Testfallerzeugung abgeschafft werden.

Anwendung großer Testfallmengen

Die Repräsentativität eines Tests sinkt auch mit der sinkenden Anzahl von Testfällen. Durch die automatische Erzeugung einer großen Testfallmenge lässt sich also die Chance erhöhen, bisher verborgene Fehler zu finden. Sofern Testfallauswahl, Testvorbereitung und -ausführung automatisiert sind, bleibt allerdings noch die äußerst aufwändige Testauswertung als begrenzender Faktor für die Anzahl der Testfälle.

Abhilfe würde die vollständige Automation der Testauswertung schaffen, so dass dem Testingenieur nach Testablauf nur noch jene Testfälle präsentiert werden, die einen Fehler im Prüfling aufgedeckt haben. Dies erfordert jedoch eine aufwändige und fehleranfällige Formalisierung der Vorgaben an den Prüfling. Im Falle einer Validierung ist dies überhaupt nicht möglich. Auch bei der Testauswertung ist also ein Mittelweg zwischen formalen und heuristischen Methoden notwendig.

Der Ansatz

Der Ansatz kombiniert zufällige und formale Testfallerzeugung, wobei die zufällige Komponente dominiert um eine möglichst breite Streuung der Testfälle zu erreichen. Um eine Steuerung der Testfallerzeugung zu ermöglichen, werden die spezifizierten - inkl. Abdeckung - zur Überwachung herangezogen. Nur dort, wo die zufällige Testfallerzeugung die Kriterien nicht zu erfüllen vermag, werden formale Methoden zur Testfallableitung eingesetzt.

Die Spezifikation der Testkriterien basiert auf Regeln, die, auf den Prüfling oder ein anderes Dokument - etwa eine formale Anforderungsspezifikation - angewendet, formale und konkrete Anforderungen an die Eingabewerte einzelner Testfälle liefern. Die Regeln können z.B. typische Fehlerquellen - etwa die Grenzfälle der Schleifenausführung (kein- oder einmalige Iteration) - beschreiben.

Die Regeln können in einer Datenbank gespeichert und auf jeden Prüfling erneut automatisch und ohne Zusatzaufwand angewendet werden. Verfeinerungen und Erweiterungen im Rahmen eines Projekts fließen erneut in die Datenbank ein, so dass sich diese zu einem Speicher für Test-Know-How entwickelt.

Um die Auswertung der Testfälle zu vereinfachen, wird aus der großen Testmenge eine Untermenge für die manuelle Auswertung ausgewählt. Grundlage der Auswahl sind die o.g. Testkriterien, aber auch vom Testingenieur vorgegebene Plausibilitätskriterien, durch die bevorzugt solche Testfälle ausgewählt werden, die mit großer Wahrscheinlichkeit einen Fehler aufdecken.

Der dominierende Zufallscharakter der Testfallerzeugung ermöglicht zudem eine statistische Auswertung der Testfallmengen. Interessant ist hierbei insbesondere, welche Teilkriterien jeweils durch wieviele Testfälle erfüllt wurden. Bei bestimmten Kriterien sind bereits hier Fehler erkennbar, ohne die Testfälle im Einzelnen zu betrachten[Gerlich05].

Das Ziel

Das Verfahren soll dem Testingenieur umfassende, aber im Detailreichtum abgestufte Informationen bieten, um einen schnellen Überblick über den Zustand des Prüflings zu erhalten und so informiert über die Maßnahmen der Testauswertung, aber auch der Fehlerkorrektur entscheiden zu können. Konservierung und Verfeinerung von Test-Know-How und damit die schrittweise Annäherung an das Testideal sollen ermöglicht werden.

Dieser Ansatz ist Gegenstand bereits abgeschlossener[Gerlich05] und fortlaufender Forschungs- und Evaluierungsarbeiten.

Literaturverzeichnis

[Bin02] .......................... Bin, Eyal et. al.: Using a constraint satisfation formulation and solution techniques for random test program generation, IBM Systems Journal, 2002
[Boehm79] .................... Boehm, B.W.: Software engineering: R&D trends and defense needs, Research directions in Software Technology, 1979
[Durrieu04] .................... Durrieu, Guy et. al.: Automatic test case generation for critical embedded systems, Proceedings of DASIA 2004 - DAta Systems In Aerospace, 2004
[Gerlich05] .................... Gerlich, Ralf: Size-Optimising Automatic Random Testcase Set Generation for Verification and Validation, 2005 (Diplomarbeit)
[Gerlich93] .................... Gerlich, Rainer: A Random-Testing Environment for Ada Programs, Eurospace Symposium ' Ada in Aerospace', 1993
[Gotlieb01] ..................... Gotlieb, Arnaud: INKA: An Automatic Software Test Data Generator, Proceedings of DASIA 2001 - DAta Systems In Aerospace, 2001
[Myers01] ..................... Myers, Glenford J.: Methodisches Testen von Programmen, 2001
[Sneed88] ...................... Sneed, Harry M.: Software-Qualitätssicherung, 1988