Testüberdeckungsgrad: Geschätzt oder doch berechnet?

Testüberdeckungsgrad: Geschätzt oder doch berechnet?

Dem Testmanger wird oft unterstellt, dass er viele für den Test benötigten Zahlen nicht berechnen kann und deshalb schätzt. Schließlich kann man ja zum Beispiel nicht wissen wie viele Testfälle benötigt oder wie viele Fehler während des Tests gefunden werden. In den Augen vieler findet man diese Zahlen nur in einer großen Glaskugel. Dem ist aber nicht so. Beim Testen gibt es, wie in allen anderen Managementdisziplinen auch, Regeln, Formeln und Metriken mit denen man viele Werte berechnen kann. Einer dieser Werte ist der Testüberdeckungsgrad, der das Verhältnis der getesteten Requirements (Anforderungen), bzw. Use Cases (Anwendungsfälle) gegenüber den definierten Requirements, bzw. Use Cases bestimmt.

Der Testüberdeckungsgrad wird oft auch als Testabdeckungsgrad bezeichnet. Je nach Test kann man unterschiedliche Formeln zum Berechnen des Testüberdeckungsgrads anwenden.

White-Box-Test

Bei einem White-Box-Test kennt der Tester die Struktur des Programms, wie dies beim Modul-, bzw. Komponententest der Fall ist. Er dient hauptsächlich der Identifikation von Programmierfehlern, wie zum Beispiel dem Auffinden von unbenutztem oder fehlerhaftem Code. Für eine 100%ige Überdeckung muss man im Quellcode alle Anweisungen, Zweige oder Pfade jeweils 1x durchlaufen. Man spricht in diesem Fall auch von Anweisungs-, Zweig-, bzw. Pfadüberdeckung.

  • Die Anweisungsüberdeckung (auch Knotenüberdeckung genannt) ist relativ einfach zu realisieren. Bei einer 100%igen Anweisungsüberdeckung wird jede Anweisung 1x ausgeführt. Mit Hilfe dieses Testes können nicht erreichbare Anweisungen, jedoch keine leeren Zweige aufgedeckt werden.
  • Die Zweigüberdeckung (auch Kantenüberdeckung genannt) sollte als Minimumtest durchgeführt werden. Sie beinhaltet die Anweisungsüberdeckung. Jeder Zweig wird mit den Werten TRUE und FALSE durchlaufen, d.h. alle Schleifen werden mindestens 2x durchlaufen.
  • Bei der Pfadüberdeckung werden alle möglichen Pfade vom Programmstart bis zum Programmende durchlaufen, was zu einem sehr hohen Testaufwand führt. Obwohl dieser Test die höchste Fehlerentdeckungsrate hat, ist in den meisten Fällen, vor allem bei vielen Schleifen, eine 100%ige Überdeckung in der Regel unmöglich.

Um den Testüberdeckungsgrad zu berechnen kann man folgende Formel benutzen:

Testüberdeckungsgrad = (Anzahl der beim Test durchlaufenen Anweisungen) / (Anzahl aller Anweisungen im Code)

Analog kann diese Formel auch für die Zweig- oder Pfadüberdeckung verwendet werden.

Black-Box-Test

Beim Black-Box-Text kennt der Tester nur die Spezifikation und nicht die Struktur des Programms. Tester erstellen für die Requirements oder Use Cases der Spezifikation Testfälle.

Je nach Granularität der Requirements, bzw. Use Cases sollte man als Minimum die Vorgabe machen, dass für jedes Requirement, bzw. jeden Use Case mindestens ein Testfall erstellt werden muss.

Hier ein kleines Beispiel: In einem Onlineshop muss sich der Kunde vor dem Bezahlvorgang einloggen.

Das zu diesem Vorgang passende Requirement könnte sein: „Der Kunde muss sich vor dem Bezahlvorgang mit seiner Kennung und seinem Passwort einloggen“. Der Negativfall, sowie Sonderfälle werden in diesem Requirement nicht berücksichtigt. Ein einziger Testfall wäre für dieses Requirement also auf keinen Fall ausreichend.

Der gleiche Vorgang könnte auch in mehrere Requirements aufgeteilt sein und wie folgt aussehen:

  1. Der Kunde muss vor dem Bezahlvorgang seine Kennung und seinem Passwort eingeben und durch drücken auf den ‚Login‘ Button abschicken.
  2. Die Kennung ist die E-Mail-Adresse des Benutzers.
  3. Das eingegebene Passwort wird verschlüsselt angezeigt.
  4. Gibt der Benutzer eine falsche Kennung/Passwort Kombination ein erscheint die Meldung: ‚Die von ihnen eingegeben Logindaten sind uns nicht bekannt. Bitte überprüfen Sie ihre Logindaten und versuchen es erneut‘. Nach einer Lesebestätigung durch Drücken von ‚OK‘ erscheint wieder die Loginmaske.
  5. Ist bei der Eingabe des Passwortes die Feststelltaste gedrückt erscheint zusätzlich die Meldung ‚Die Feststelltaste ist aktiviert‘.

Die Requirements sind in diesem Fall wesentlich ausführlicher und berücksichtigen auch Sonderfälle. Ein Testfall pro Requirement könnte daher als ausreichend angesehen werden.

Wie man daran sehen kann hängt die Qualität der Testüberdeckung an der Qualität der Requirements, bzw. Use Cases und der Qualifikation des Testteams, die aus diesen Testfälle erstellen. Je besser, bzw. detaillierter die Requirements definiert wurden und je feingranularer, desto bessere Testfälle kann man daraus ableiten. Je besser die Testfälle sind, desto besser ist die Testüberdeckung.

Den Testüberdeckungsgrad kann man dann wie folgt berechnen:

Testüberdeckungsgrad = (Anzahl Testfälle) / ((Anzahl Requirements) * (Anzahl Testfälle die für ein Requirement zu erstellen sind))

Die so errechnete Zahl zeigt allerdings nur den theoretischen Wert, d.h. den Testüberdeckungsgrad der Maximal erreicht werden könnte und berücksichtigt auch nicht, dass mehr als die definierte Anzahl an Testfällen pro Requirement existieren kann. Um den tatsächlichen Testüberdeckungsgrad zu errechnen muss man folgende Formel anwenden:

Testabdeckungsgrad = (Anzahl durchgeführter Testfälle) / (Anzahl aller Testfälle)

Fazit

Der Testüberdeckungsgrad kann mit Formeln berechnet werden. Im White-Box-Test ist dies noch relativ einfach möglich, während es beim Black-Box-Test schwieriger wird. Auch hier gibt es einfache Formeln, aber der Testüberdeckungsgrad hängt von der Anzahl und Qualität der definierten Testfälle ab. Aus diesem Grund ist großer Wert auf die Qualität der Testfälle zu legen. Hier spielt nicht zuletzt die Qualifikation der Tester und des Testmanagers eine große Rolle.

Leave a Reply

Your email address will not be published.