Konzept: Schlüsselmesswerte des Tests
In dieser Richtlinie werden Abdeckungs- und Qualitätsermittlungen für Testsuites vorgestellt.
Beziehungen
Hauptbeschreibung

Einführung

Zu den Schlüsselmesswerten für einen Test gehören Abdeckung und Qualität.

Mit der Testabdeckung wird die Vollständigkeit ermittelt. Sie ergibt sich aus der Abdeckung von zu testenden Anforderungen und Testfällen oder der Abdeckung von ausgeführtem Code.

Die Qualität ist ein Maß für die Zuverlässigkeit, Stabilität und Leistung des Testobjekts (System oder Anwendung) und ergibt sich aus der Bewertung von Testergebnissen und der Analyse von Änderungsanfragen (Mängeln), die beim Testen festgestellt wurden.

Abdeckungsermittlungen

Abdeckungsmetriken geben Aufschluss darüber, inwieweit die Tests vollständig sind. Am häufigsten wird die Abdeckung von Softwareanforderungen und von Quellcode ermittelt. Im Grunde wird mit der Testabdeckung die Vollständigkeit in Bezug auf eine Anforderung (anforderungsbasiert) oder auf die Design- und Implementierungskriterien des Codes (codebasiert) ermittelt. Bei der anforderungsbasierten Abdeckung müssen beispielsweise Anwendungsfälle geprüft werden, und bei der codebasierten Abdeckung müssen alle Zeilen des Codes ausgeführt werden.

Jede systematische Testaufgabe basiert auf mindestens einer Strategie zur Testabdeckung. Diese Strategie gibt den allgemeinen Zweck der Tests an und bildet damit die Grundlage für das Design von Testfällen. Eine solche Strategie kann eine einfache Anweisung sein, z. B. die Anweisung, alle Leistungswerte zu prüfen.

Eine anforderungsbasierte Strategie kann ausreichen, um eine quantifizierbare Messgröße für die Vollständigkeit der Tests zu erhalten, sofern die Anforderungen vollständig katalogisiert sind. Wenn alle zu testenden Leistungsanforderungen ermittelt sind, können die Testergebnisse daran gemessen werden. Sie könnten beispielsweise angeben, dass 75 % aller zu testenden Leistungsanforderungen geprüft wurden.

Codebasierte Strategien formulieren, wie viel von dem Quellcode während der Tests auszuführen ist. Für sicherheitsrelevante Systeme ist diese Art der Teststrategie sehr wichtig.

Beide Messgrößen können (mit den Gleichungen in den beiden folgenden Abschnitten) manuell abgeleitet oder mit Testautomatisierungstools berechnet werden.

Anforderungsbasierte Testabdeckung

Die anforderungsbasierte Testabdeckung wird mehrere Male während des Testzyklus ermittelt und gibt die Testabdeckung an einem Meilenstein des Testzyklus an, zum Beispiel die Abdeckung geplanter, implementierter, ausgeführter und erfolgreicher Tests.

  • Sie können die Testabdeckung mit der folgenden Gleichung berechnen:

Testabdeckung = T(g,i,a,e) / ZTA

Für diese Gleichung gilt Folgendes:
T ist die Anzahl der (geplanten, implementierten, ausgeführten oder erfolgreichen) Tests, ausgedrückt in Testverfahren oder Testfällen.

ZTA ist die Gesamtanzahl der zu testenden Anforderungen.

  • Bei der Testplanung wird die Abdeckung wie folgt berechnet, um die Abdeckung der geplanten Tests zu bestimmen:

Testabdeckung (Planung) = Tg / ZTA

Für diese Gleichung gilt Folgendes:
Tp ist die Anzahl der geplanten Tests, ausgedrückt in Testverfahren oder Testfällen.

ZTA ist die Gesamtanzahl der zu testenden Anforderungen.

  • Bei der Testimplementierung werden die Testverfahren (als Test-Scripts) implementiert. Hier wird die Testabdeckung mit der folgenden Gleichung berechnet:

Testabdeckung (Implementierung) = Ti / ZTA

Hier gilt:
Ti ist die Anzahl der implementierten Tests, ausgedrückt als Anzahl der Testverfahren oder Testfälle, für die es entsprechende Test-Scripts gibt.

ZTA ist die Gesamtanzahl der zu testenden Anforderungen.

  • Während der Testausführung gibt es zwei Abdeckungsermittlungen. Eine ermittelt die durch die Ausführung von Tests erreichte Testabdeckung und die andere stellt die Abdeckung der erfolgreichen Tests fest. (Dies sind Tests, die ohne festgestellte Mängel oder unerwartete Ergebnisse ausgeführt wurden.)

    Zur Berechnung der Abdeckung werden die folgenden Gleichungen verwendet:

    Testabdeckung (Ausführung) = Ta / ZTA

    Für diese Gleichung gilt Folgendes:
    Ta ist die Anzahl der ausgeführten Tests, ausgedrückt in Testverfahren oder Testfällen.

    ZTA ist die Gesamtanzahl der zu testenden Anforderungen.



Testabdeckung (erfolgreiche Ausführung) = Te / ZTA

Für diese Gleichung gilt Folgendes:
Te ist die Anzahl der ausgeführten Tests, ausgedrückt in Testverfahren oder Testfällen, die ohne festgestellte Mängel abgeschlossen wurden.

ZTA ist die Gesamtanzahl der zu testenden Anforderungen.



Wenn wir die obigen Verhältnisgleichungen in Prozentzahlen umsetzen, kann die anforderungsbasierte Testabdeckung wie folgt angegeben werden:

X % der Testfälle (T(g,i,a,e) in den obigen Gleichungen) sind mit einer Erfolgsquote von Y % abgedeckt.

Diese aussagekräftige Angabe zur Testabdeckung kann mit einem definierten Erfolgskriterium verglichen werden. Falls das Kriterium nicht erfüllt wurde, kann anhand dieser Angabe abgeschätzt werden, wie viel Testaufwand noch erforderlich ist.

Codebasierte Testabdeckung

Für die codebasierte Testabdeckung wird ermittelt, wie viel Code während der Tests ausgeführt wurde und wie viel Code noch auszuführen ist. Die Codeabdeckung kann für Steuerungsflüsse (Anweisung, Verzweigung oder Pfad) oder Datenflüsse ermittelt werden.

  • Bei der Abdeckung von Steuerungsflüssen kommt es darauf an, Codezeilen, Verzweigungsbedingungen, Pfade durch den Code oder andere Elemente des Steuerungsablaufs der Software zu testen.
  • Bei der Abdeckung von Datenflüssen soll getestet werden, ob der Status der Daten während des Softwarebetriebs gültig bleiben. Es könnte beispielsweise getestet werden, ob ein Datenfeld vor seiner Verwendung definiert wird.

Sie können die codebasierte Testabdeckung mit der folgenden Gleichung berechnen:

Testabdeckung = Ea / GEiC

Für diese Gleichung gilt Folgendes:
Ea ist die Anzahl der ausgeführten Elemente, ausgedrückt als Codeanweisungen, Codeverzweigungen, Codepfade, Entscheidungspunkte für den Datenstatus, oder Namen von Datenelementen.

GEiC ist die Gesamtzahl der Elemente im Code.



Wenn wir diese Verhältnisgleichung in Prozentzahlen umsetzen, kann die codebasierte Testabdeckung wie folgt angegeben werden:

x % der Testfälle (E in der obigen Gleichung) sind mit einer Erfolgsquote von y % abgedeckt.

Diese aussagekräftige Angabe zur Testabdeckung kann mit einem definierten Erfolgskriterium verglichen werden. Falls das Kriterium nicht erfüllt wurde, kann anhand dieser Angabe abgeschätzt werden, wie viel Testaufwand noch erforderlich ist.

Erkennbare Qualität messen

Die Bewertung der Testabdeckung gibt zwar Aufschluss über die Vollständigkeit der Tests, wie jedoch die Qualität der Software wahrgenommen wird, lässt sich am besten durch eine Bewertung der festgestellten Mängel angeben. Diese wahrgenommene Qualität kann zum Anlass genommen werden, sich Gedanken über die allgemeine Qualität des gesamten Softwaresystems zu machen. Die wahrgenommene Softwarequalität ist ein Maß dafür, wie gut die Software die an sie gestellten Anforderungen erfüllt. Mängel werden daher in diesem Kontext als eine Form der Änderungsanfrage angesehen, da das Testobjekt die Softwareanforderungen nicht erfüllen konnte.

Für die Bewertung von Mängeln können Methoden verwendet werden, die von einer einfachen Zählung der Mängel bis hin zu einem exakten statistischen Modell reichen.

Eine genaue Bewertung stützt sich auf Annahmen bezüglich des Auftretens von Mängeln oder der Mängelerkennungsquote während der Tests. Ein verbreitetes Modell geht von einer Poisson-Verteilung der Quote aus. Die tatsächlichen Daten zur Mängelquote werden dann in das Modell eingesetzt. Die anschließende Auswertung kann eine Einschätzung der aktuellen Zuverlässigkeit der Software liefern und prognostizieren, wie die Zuverlässigkeit bei fortgesetzten Tests und Beseitigung bestehender Mängel zunehmen wird. Diese Auswertung wird als ein Modell zur Darlegung der Softwarezuverlässigkeit beschrieben und ist Gegenstand intensiver Forschungen. Da es für diese Art der Auswertung keine Toolunterstützung gibt, sollten Sie die Vorteile dieses Ansatzes sorgfältig gegen den damit verbundenen Kostenaufwand abwägen.

Bei einer Mängelanalyse wird die Verteilung von Mängeln nach den Werten bestimmter Mängelattribute analysiert. Die Mängelanalyse erlaubt eine Aussage über die Zuverlässigkeit der Software.

Meistens werden bei der Mängelanalyse die vier wichtigsten Mängelattribute analysiert:

  • Status - der aktuelle Status eines Mangels (offen, in Bearbeitung, geschlossen usw.)
  • Priorität - die relative Wichtigkeit der Bearbeitung/Beseitigung eines Mangels
  • Schweregrad - die relativen Folgen eines Mangels für den Benutzer, ein Unternehmen, Dritte usw.
  • Ursache - Position und Art des ursprünglichen Fehlers, der zu diesem Mangel geführt hat, oder die Komponente, die korrigiert werden muss, um diesen Mangel abzustellen

Die Mängelanzahl kann in einem Trenddiagramm oder Bericht als Funktion der Zeit dargestellt werden. Sie kann auch in einem Bericht zur Mängeldichte als Funktion von Mängelattributen wie Schweregrad oder Status angegeben werden. Diese Analyseformen geben einen Ausblick auf die Entwicklungstrends oder die Verteilung von Mängeln, die die Zuverlässigkeit der Software widerspiegeln.

Es wird beispielsweise erwartet, dass die Mängelerkennungsquote mit dem Fortschreiten der Tests und der Mängelbeseitigung abnimmt. Es kann ein Mängel- oder Qualitätsschwellenwert etabliert werden, ab dem die Softwarequalität nicht mehr akzeptabel ist. Die Anzahl der Mängel kann auch nach ihrem Ursprung im Implementierungsmodell dokumentiert werden. So können Module erkannt werden, die Schwach- oder Brennpunkte sind, aber auch Softwarekomponenten, die immer wieder korrigiert werden müssen, was auf fundamentale Designfehler schließen lässt.

In eine Analyse dieser Art werden nur bestätigte Mängel einbezogen. Nicht alle dokumentierten Mängel stellen einen Fehler im eigentlichen Sinne dar. Bei einigen dieser Mängel kann es sich um Verbesserungsvorschläge handeln, die nicht zum Umfang des Projekts gehören, oder um bereits gemeldete Mängel. Es lohnt sich jedoch, der Frage nachzugehen, warum nicht bestätigte Mängel eigentlich dokumentiert oder warum manche Mängel doppelt aufgelistet werden.

Mängelberichte

Der Rational Unified Process empfiehlt eine Bewertung von Mängeln nach den folgenden Kategorien:

  • Berichte zur Mängelverteilung (Dichte) erlauben eine Darstellung der Mängelanzahl als Funktion von Mängelattributen.
  • Berichte zum Alter von Mängeln sind eine spezielle Dokumentationsform zur Mängelverteilung und zeigen, wie lange ein Mangel einen bestimmten Status hatte (z. B. offen war). In den einzelnen Alterskategorien können die Mängel außerdem nach anderen Attributen (z. B. nach Eigner) sortiert werden.
  • Berichte zum Mängeltrend stellen die Anzahl der Mängel nach Status (neu, offen oder geschlossen) als Funktion der Zeit dar. Es gibt kumulative und nicht kumulative Trendberichte.

Viele dieser Berichte sind für die Bewertung der Softwarequalität von großem Wert. Besonders hilfreich sind sie, wenn sie zusammen mit Testergebnissen und mit Fortschrittsberichten ausgewertet werden, die die Testergebnisse über mehrere Iterationen und Testzyklen für das Testobjekt zeigen. Zu den üblichen Testkriterien gehört die Angabe der tolerierbaren Anzahl offener Mängel in bestimmten Kategorien, z. B. pro Schweregrad. Diese Anzahl lässt sich durch eine Auswertung der Mängelverteilung leicht überprüfen. Wenn die Verteilung nach Testmotivationen sortiert wird, ist bei der Auswertung eine bessere Fokussierung auf wichtige Problemstellungen möglich.

Für eine effektive Erstellung von Berichten dieser Art ist normalerweise Toolunterstützung erforderlich.

Berichte zur Mängeldichte

Mängelstatus und Mängelpriorität

Ordnen Sie jedem Mangel eine Priorität zu. In der Regel ist es ausreichend, die folgenden vier Prioritätsstufen anzuwenden:

  • Priorität 'kritisch' (unverzüglich zu beseitigender Mangel)
  • Priorität 'hoch'
  • Priorität 'normal'
  • Priorität 'niedrig'

Anmerkung: Die Verteilung von Mängeln nach diesen Prioritätsstufen könnte als Kriterium für den Erfolg eines Tests verwendet werden. Ein solches Kriterium könnte beispielsweise lauten, "keine offenen Mängel mit Priorität 1 und weniger als fünf offene Mängel mit Priorität 2". Sie sollten ein Mängelverteilungsdiagramm wie das folgende generieren.

Mängelverteilungsdiagramm



Es ist klar, dass das Kriterium nicht erfüllt ist. Dieses Diagramm muss mit einem Filter erstellt werden, damit nur offene Mängel angezeigt werden, wie es im Testkriterium gefordert ist.

Mängelstatus und Mängelpriorität

Berichte zum Schweregrad von Mängeln zeigen, wie die Anzahl der Mängel für die einzelnen Schweregrade an, z. B. schwerwiegender Fehler, Hauptfunktion nicht ausführbar, kleineres Ärgernis.

Mängelstatus und Ursprung im Implementierungsmodell

Berichte zur Mängelursache zeigen die Verteilung von Mängeln auf die Elemente des Implementierungsmodells.

Berichte zum Alter von Mängeln

Eine Analyse des Alters von Mängeln gibt Aufschluss über die Testeffektivität und die Wirksamkeit der Mängelbeseitigung. Wenn die Mehrzahl der älteren nicht behobenen Mängel beispielsweise den Status 'Validierung anstehen' hat, sind wahrscheinlich nicht genug Ressourcen für die Testdurchführung verfügbar.

Berichte zum Mängeltrend

Berichte zum Mängeltrend enthalten Mängelquoten und geben einen besonders guten Überblick über den Status des Testprozesses. Mängeltrends folgen in einem Testzyklus einem vorhersehbaren Muster. Am Anfang des Zyklus steigt die Mängelquote schnell an, erreicht dann einen Höhepunkt und nimmt bis zum Ende des Zyklus allmählich ab.



Diagramm für einen Bericht zum Mängeltrend

Wenn Sie Probleme feststellen wollen, sollten Sie diesen Trend in Relation zum Projektplan setzen. Steigt die Mängelquote beispielsweise in der dritten Woche eines vierwöchigen Testzyklus noch immer an, liegen die Projektarbeiten eindeutig nicht mehr im Plan.

Diese einfache Trendanalyse geht davon aus, dass Mängel sofort beseitigt und die Korrekturen in den folgenden Builds getestet werden und die Schließungsrate der Mängel dasselbe Profil wie die Mängelerkennungsquote hat. Trifft dies nicht zu, gibt es ein Problem bei der Mängelbeseitigung. Möglicherweise sind die Ressourcen für die Behebung von Mängeln oder für das Testen und Auswerten der Korrekturen unzureichend.

Diagramm für einen Trendanalysebericht

Der in diesem Bericht dargestellte Trend zeigt, dass zu Beginn des Projekts rasch neue Mängel festgestellt werden und dass mit der Zeit die Zahl neuer Mängel zurückgeht. Der Trend für offene Mängel ist zeitlich etwas verschoben, ansonsten aber mit dem für neue Mängel vergleichbar. Für geschlossene Mängel zeigt sich im Verlaufe der Zeit ein steigender Trend, da offene Mängel geprüft und korrigiert werden. Diese Trends spiegeln einen erfolgreichen Testzyklus wieder.

Falls Ihre Trends erheblich von den hier dargestellten abweichen, kann dies ein Hinweis darauf sein, dass in bestimmten Entwicklungs- oder Testbereichen zusätzliche Ressourcen eingesetzt werden müssen.

In Kombination mit den Testabdeckungsermittlungen ermöglicht die Mängelanalyse eine sehr gute Einschätzung, aus der die Testerfüllungskriterien abgeleitet werden können.

Leistungsermittlungen

Für die Einschätzung des Leistungsverhaltens des Testobjekts werden zahlreiche Ermittlungen durchgeführt. Schwerpunktmäßig werden verhaltensbezogene Daten erfasst, z. B. die Antwortzeit, Ablaufsteuerungsprofile, der Ausführungsablauf, die Zuverlässigkeit des Betriebs und Grenzwerte. Diese Ermittlungen werden hauptsächlich im Rahmen der Testauswertung analysiert. Es gibt aber auch Leistungsermittlungen, die während der Testausführung zur Bewertung des Testfortschritts und des Teststatus herangezogen werden.

Primär werden die folgenden Leistungsermittlungen durchgeführt:

  • Dynamische Überwachung - Erfassung und Anzeige des Status und Zustands jedes ausgeführten Test-Scripts in Echtzeit
  • Berichte zu Antwortzeit und Durchsatz - Messung der Antwortzeiten und des Durchsatzes des Testobjekts für angegebene Akteure und Anwendungsfälle
  • Perzentilberichte - Berichte, die Daten in Perzentile unterteilen und die daraus resultierenden Berechnungen grafisch darstellen (Beispiel: Die Transaktionen pro Sekunde können als Perzentile angegeben werden. Die durchschnittliche Antwortzeit bei dieser Auslastung kann dann grafisch dargestellt werden.)
  • Vergleichende Berichte - Unterschiede zwischen zwei (oder mehr) Datengruppen für verschiedene Testausführungen oder Trends über mehrere Testausführungen
  • Trace-Berichte - Details der Kommunikation zwischen dem Akteur (Test-Script) und dem Testobjekt

Dynamische Überwachung

Die dynamische Überwachung ermöglicht eine Echtzeitanzeige und echtzeitorientierte Berichte während der Testausführung. In der Regel werden die Überwachungsergebnisse als Histogramm oder Graph dargestellt. Zur Überwachung und Einschätzung der Ausführung von Leistungstests werden der aktuelle Zustand, der Status und der Fortschritt der Test-Scripts angezeigt.

Dynamische Überwachung mit Histogrammanzeige

Im obigen Histogramm gibt es beispielsweise 80 Test-Scripts, die denselben Anwendungsfall ausführen. 14 dieser Test-Scripts befinden sich im Zustand 'Leerlauf', 12 im Zustand 'Abfrage', 34 im Zustand 'SQL-Ausführung', 4 im Zustand 'SQL-Verbindung' und 16 im Status 'Andere'. Sie werden erwarten, dass sich mit fortschreitendem Test die Anzahl der Scripts für die einzelnen Zustände ändert. Die dargestellte Ausgabe zeigt eine typische und normale Situation in der Mitte der Testausführung. Wenn sich der Zustand der Test-Scripts jedoch während der gesamten Testausführung nicht ändert, könnte ein Problem bei der Testausführung vorliegen. Möglicherweise müssen weitere Leistungsermittlungen implementiert oder ausgewertet werden.

Berichte zu Antwortzeit und Durchsatz

Wie der Name schon sagt, wird in diesem Berichten das Leistungsverhalten in Relation zur Zeit und bezogen auf den Durchsatz (Anzahl der verarbeiteten Transaktionen) ermittelt und berechnet. Diese Berichte werden in der Regel als Graph mit der Antwortzeit (oder Anzahl der Transaktionen) auf der Y-Achse und den Ereignissen auf der X-Achse angezeigt.

Beispieldiagramm für einen Durchsatz- und Analysebericht

Neben der Anzeige des tatsächlichen Leistungsverhaltens ist häufig die Berechnung und Anzeige von statistischen Informationen, z. B. der durchschnittlichen Abweichung und der Standardabweichung der Datenwerte, von großem Wert.

Perzentilberichte

Perzentilberichte enthalten eine andere statistische Berechnung der Leistung.

Beispieldiagramm für einen Perzentilbericht

Vergleichende Berichte

Es ist wichtig, die Ergebnisse der verschiedenen Ausführungen von Leistungstests miteinander zu vergleichen, um bewerten zu können, welche Auswirkungen die zwischen den Ausführungen vorgenommenen Änderungen auf das Leistungsverhalten haben. Mit vergleichenden Berichten können Sie die Unterschiede zwischen den Datengruppen (der verschiedenen Testausführungen) oder die Trends über mehrere Testausführungen anzeigen.

Trace-Berichte und Profilberichte

Der Trace-Bericht kann der wichtigste Bericht überhaupt sein, wenn das Leistungsverhalten inakzeptabel ist oder die Leistungsüberwachung mögliche Engpässe aufzeigt (z. B. wenn sich der Zustand von Test-Scripts über einen längeren Zeitraum nicht ändert). Trace-Berichte und Profilberichte enthalten detaillierte und differenzierte Informationen. Dazu gehören unter anderem die zwischen dem Akteur und dem Testobjekt ausgetauschten Nachrichten, die Ausführungsreihenfolge sowie Informationen zum Datenzugriff und zu den Funktions- und Systemaufrufen.