next up previous contents
Next: 7.7 Weitergehende Information Up: 7. Die Cleanroom-Methode Previous: 7.5 Spezifikation, Entwurf und

Unterabschnitte

  
7.6 Statistisches Testen und Zertifizierung

7.6.1 Benutzungsmodellierung

Zur Erzeugung der Testfälle für das statistische Testen muß zunächst ein Benutzungsmodell aufgestellt werden. Basis hierfür ist das sogenannte Benutzungsprofil, eine (meist natürlichsprachliche) Beschreibung der erwarteten Benutzung des Programms, die in den Anforderungen niedergelegt ist.

Zur mathematischen Beschreibung des Benutzungsmodells werden in der Regel Markov-Ketten verwendet und zwar solche mit endlichem Zustandsraum und diskreten Ereignissen. Eine solche Markov-Kette ist nichts anderes als ein nichtdeterministischer endlicher Automat mit definierten Übergangswahrscheinlichkeiten.

\includegraphics[scale=1]{Bild/cleanusagemodel.ps}

In Abbildung 7.3 sehen wir als Beispiel einen kleinen Ausschnitt aus dem Benutzungsmodell für einen Texteditor. Die ovalen Kästen stehen für die Zustände, deren Erreichen zugleich stets eine Eingabeaktion des Benutzers repräsentiert. Diese Aktion ist hier verbal dargestellt. Die Pfeile zwischen den Zuständen geben die möglichen (d.h. modellierten!) Übergänge zwischen den Zuständen an, das heißt, die möglichen Abfolgen von Benutzeraktionen. Jeder Übergang ist mit seiner Wahrscheinlichkeit beschriftet. Die gestrichelten Übergänge führen zu Zuständen außerhalb des Modellausschnitts.

Die abgebildeten Übergänge beschreiben die typischen Folgen von Eingaben, wenn ein Textblock markiert wurde: Meist wird dann erst der Cursor bewegt und dann eine Blockoperation ausgelöst; andere Eingaben kommen jedoch ebenfalls vor. Das Beispiel macht auch klar, welche Abwägungen zu treffen sind: Beispielsweise steht ,,Cursorbewegung`` natürlich nicht nur für eine einzige mögliche Eingabe, sondern dahinter verbirgt sich eine ganze Klasse von Eingaben. Der entsprechende Zustand könnte im Benutzungsmodell also je nach Bedarf entweder in eine ganze Reihe von Zuständen verfeinert werden, was das Modell enorm vergrößert, oder durch ein ad-hoc gebildetes Untermodell realisiert werden, das nicht mit einer Markov-Kette beschrieben wird, z.B. indem zufällig irgendeine der möglichen Eingaben zur Cursorbewegung ausgewählt wird.

Für realistische Programme werden die benötigten Markov-Ketten enorm groß, wenn die Modellierung auch nur einigermaßen genau sein soll. Deshalb nimmt man meistens Zuflucht zu hierarchischen Modellen, in denen zunächst nach Benutzertypen unterschieden wird, für jeden Benutzertyp nach Benutzungsart (z.B. Teilfunktion) und erst für jede Teilfunktion eine Markov-Kette aufgestellt wird. Zwischen Einzelpunkten in verschiedenen dieser Ketten müssen dann Verbindungen eingeführt werden, die bedeuten, daß die Ausführung eines bestimmten Übergangs in einer Kette einen bestimmten anderen Übergang in einer anderen Kette bewirkt.

7.6.2 Testen

Aus dem Benutzungsmodell kann nun eine beliebige Anzahl von Testeingaben automatisch erzeugt werden. Dazu wird einfach das Benutzungsmodell an seinem Eingang betreten und mit Hilfe eines Zufallsgenerators entsprechend der Übergangswahrscheinlichkeiten solange durchlaufen, bis ein Ausgang (Endzustand) erreicht wird. Die in jedem Zustand erzeugten Eingabeteile werden aufgesammelt.

Dabei ergibt sich meistens das Problem, daß Testausgaben zur Kontrolle der Richtigkeit des Programms nicht automatisch mit erzeugt werden können. Diese Situation ist jedoch nicht grundsätzlich anders als beim normalen Testen. Die Ausgaben müssen entweder von Hand oder mit Hilfe anderer Programme ermittelt werden, oder man kann auf sie verzichten, weil Konsistenz- und Plausibilitätsprüfungen benutzt werden, um die Richtigkeit der Programmreaktionen zu beurteilen.

Beim Testen wird jeder Testfall auf Korrektheit geprüft und die Abstände zwischen den Programmversagen werden registriert.

7.6.3 Zertifizierung

Das Testen wird solange fortgeführt, bis eine angestrebte Zuverlässigkeitsaussage erreicht ist. Eine solche Zuverlässigkeitsaussage hat zum Beispiel die Form ,,Die MTTF des Programms beträgt mindestens m Testfälle mit einer Konfidenz von k Prozent``. MTTF bedeutet Mean Time To Failure, also mittlere Zeit bis zum nächsten Versagen, also: Erfolgsfälle pro Versagensfall.

Eine solche Aussage kann mit Methoden der Statistik geprüft werden. Ein vereinfachtes graphisches Schema, das dieses Vorgehen verdeutlicht, ist in Abbildung 7.4 zu sehen: Für jeden erfolgreichen Testfall geht die Linie um eine Einheit nach rechts, für jeden Versagensfall um eine Einheit nach oben.

\includegraphics[scale=1]{Bild/cleanteststop.ps}

Wir sehen einen Korridor, der die ,,Weitertesten``-Region enthält, in der der Test noch fortgeführt werden muß. Die Steigung des Korridors (Versagensfälle pro Erfolgsfall) gibt den Kehrwert der Zuverlässigkeit gemessen in MTTF an. Die Breite des Korridors beschreibt qualitativ gesehen die gewünschte Konfidenz. Wird der ,,Weitertesten``-Korridor nach oben verlassen, so wurde mit der gegebenen Konfidenz das Zuverlässigkeitsziel nicht erreicht, wird er nach unten verlassen, so wurde es mit der gleichen Konfidenz erreicht. Bei Betreten der ,,Akzeptieren``-Region wird also das Programm erfolgreich zertifiziert, bei Betreten der ,,Zurückweisen``-Region wird es als zu unzuverlässig abgelehnt. Es muß dann korrigiert oder neu entworfen werden und wird in seiner neuen Form dann erneut getestet.

In einer realen Anwendung können noch leistungsfähigere mathematische und statistische Methoden eingesetzt werden, um die Zuverlässigkeit und deren Konfidenz zu bestimmen. Insbesondere ist es möglich, die Ergebnisse der Testfälle von vor der Korrektur weiter in die Zuverlässigkeitsberechnung einzubeziehen. Dies erfolgt über ein Maß der Verbesserung der Zuverlässigkeit nach einer Programmkorrektur und erlaubt damit, die Genauigkeit der Aussage zu verbessern, ohne zusätzliche Testfälle durchführen zu müssen. Außerdem können verschiedene Fehler- und Versagensmodelle verwendet werden, um bessere Schranken für die Konfidenz zu erhalten.


next up previous contents
Next: 7.7 Weitergehende Information Up: 7. Die Cleanroom-Methode Previous: 7.5 Spezifikation, Entwurf und
Lutz Prechelt
1999-04-13