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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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
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.
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.
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.
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 enthalten eine andere statistische Berechnung der Leistung.
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.
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.
|