Course Registration
System
Zusammenfassende Testauswertung
für den
Architekturprototyp
Version 1.0
Revisionsprotokoll
Datum |
Version |
Beschreibung |
Autor |
21. März 1999 |
1.0 |
Testbewertung für den Architekturprototyp |
C. Smith |
|
|
|
|
|
|
|
|
Inhaltsverzeichnis
- Einführung
- Zusammenfassung der Testergebnisse
- Testabdeckung
- Codeabdeckung
- Mängelanalyse
- Vorgeschlagene Maßnahmen
- Diagramme
Zusammenfassende Testauswertung
für den
Architekturprototyp
- Einführung
- Verwendungszweck
Dieser Testauswertungsbericht bezieht sich auf die Tests für den Architekturprototyp des Course Registration System. Er beschreibt die (anforderungs- und codebasierte) Testabdeckung und die Mängelanalyse (Mängeldichte).
- Geltungsbereich
Dieser Testauswertungsbericht bezieht sich auf den Architekturprototyp für CREG. Die durchgeführten Tests sind im Testplan
[5] für den Prototyp beschrieben. Dieser Auswertungsbericht ist für Folgendes zu verwenden:
- Annehmbarkeit und Angemessenheit des Leistungsverhaltens des Prototyps einschätzen
- Annehmbarkeit der Tests einschätzen
- Verbesserungen hinsichtlich der Testabdeckung und/oder Testqualität ermitteln
- Referenzen
Verfügbare Referenzen:
- Course Registration System, Glossar (WyIT406) Version 2.0, 1999, Wylie College IT
- Course Registration System, Softwareentwicklungsplan (WyIT418) Version 1.0, 1999, Wylie College IT
- Course Registration System, Iterationsplan, Ausarbeitungsiteration A1 (WyIT420) Version 1.0, 1999, Wylie College IT
- Course Registration System, Build-Erstellungsplan zur Integration für den Architekturprototyp (WyIT430) Version 1.0, 1999, Wylie College IT
- Course Registration System, Testplan für den Architekturprototyp (WyIT432) Version 1.0, 1999, Wylie College IT
-
Zusammenfassung der Testergebnisse
Die in der Testsuite für den Prototyp definierten Testfälle wurden gemäß der im Testplan
[5] definierten Teststrategie ausgeführt.
Die Testabdeckung (siehe folgenden Abschnitt 5.0) ist bezogen auf die im Testplan
[5] definierten Anwendungsfälle und Testanforderungen vollständig.
Die Codeabdeckung ist im Abschnitt 6.0 beschrieben. Die Messung der Codeabdeckung wird für den Prototyp als nicht signifikant
angesehen.
Die (nachfolgend im Abschnitt 7.0 dargestellte) Mängelanalyse weist aus, dass
es erhebliche Leistungsmängel beim Zugriff auf das herkömmliche Kurskatalogsystem gibt. Die Leistungs- und Ladetests mit Lese- und Schreibzugriff auf das
Kurskatalogsystem bleiben weit hinter den Erwartungen zurück. Das Managementteam wird Systementwickler einbeziehen, die diese Testergebnisse genauer bewerten und Designalternativen
ermitteln sollen.
- Testabdeckung
Die für den Prototyp auszuführenden Tests und die entsprechenden Erfüllungskriterien sind in Abschnitt 5.1 des
Testplans [5] definiert. Ergebnisse für die Testabdeckung:
Faktor für ausgeführte Testfälle = 40/40 = 100 %
Faktor für erfolgreich ausgeführte Testfälle = 30/40 = 80 %
Bereich mit der höchsten Fehlerquote:
- Leistungstests mit Zugriff auf das Kurskatalogsystem
- Belastungstests mit Zugriff auf das Kurskatalogsystem
Weitere Details zur Testabdeckung können über Rational RequisitePro
und die Testfallmatrix für den Prototyp abgerufen werden.
- Codeabdeckung
Die Codeabdeckung der Prototyptests wurde mit Rational Visual PureCoverage gemessen.
Faktor für ausgeführte Codezeilen = 12.874/48.916 (ca. 25 %)
Während der Tests wurden ca. 25 % des Codes ausgeführt. Da alle Schnittstellen umfassend getestet wurden, kann diese Abdeckung als
ausreichend für die Prototyptests angesehen werden. In späteren Iterationen wird eine deutlich höhere Codeabdeckung erforderlich sein.
- Mängelanalyse
Dieser Abschnitt fasst die Ergebnisse der mit
Rational ClearQuest generierten Mängelanalyse zusammen. Abschnitt 8 empfiehlt geeignete Maßnahmen für die festgestellten Mängel.
- Mängeldichte
Die Daten zur Mängeldichte wurden anhand von Daten generiert, die aus
ClearQuest-Berichten extrahiert wurden. Abschnitt 9 dieses Dokuments enthält Diagramme, die Folgendes illustrieren:
- Mängel nach Schweregrad (kritisch, hoch, mittel, niedrig)
- Mängelverursacher (Komponente, bei der das Problem oder der Fault auftritt)
- Mängelstatus (protokolliert, zugewiesen, beseitigt, getestet, geschlossen)
Aus der Grafik der Mängel nach Schweregrad geht hervor, dass vier Mängel mit kritischer und vier mit hoher Priorität
protokolliert wurden. Eine detaillierte Analyse der Mängelprotokolle hat gezeigt, dass die Mängel mit kritischer und hoher Priorität
alle mit Leistungs- und Ladeproblemen beim Zugriff auf das herkömmliche Kurskatalogsystem zusammenhängen. (Anmerkung: Die Grafik ist nicht beigefügt.)
Die Grafik der Mängelverursacher zeigt einen überdurchschnittlichen hohen Anteil von Mängeln bei den Komponenten der
Systemschnittstelle.
Die Grafik zum Mängelstatus zeigt, dass viele Mängel protokolliert wurden, jedoch noch nicht für die Analyse zugewiesen
sind.
- Mängeltrend
Der Mängeltrend (d. h. die Anzahl der Mängel über der Zeit) wurde für die Tests des Architekturprototyps nicht ermittelt.
- Mängelalter
Die Überwachung des Alters von Mängeln ist für den Prototyp nicht erforderlich. Der aktuelle Plan sieht vor,
zu Beginn der Konstruktionsphase mit der Überwachung des Alters offener Mängel anzufangen. Die Diagramme zum Mängelalter werden mit ClearQuest generiert.
- Vorgeschlagene Maßnahmen
Folgende Maßnahmen werden empfohlen:
- Leistungs- und Ladeprobleme im Zusammenhang mit dem Zugriff auf das herkömmliche Kurskatalogsystem von zusätzlichen Systementwicklern genauer bewerten lassen; vor der Implementierung von Designlösungen sollte das
Projektteam Designalternativen prüfen.
- Zuordnung von Entwicklungsressourcen, um anstehende offene Mängel am Prototyp zu beseitigen
- Verzögerung des Starts der nächsten Iteration bei anstehender Beseitigung von Mängeln der Priorität 'kritisch' und 'hoch'
- Zusätzliche Tests zur weiteren Überprüfung der Belastungen und Zugriffszeiten des Kurskatalogsystems entwerfen; es sollte versucht werden, mit Rational Visual Quantify Leistungsengpässe zu bestimmen und zu analysieren.
- In künftigen Iterationen sollten Überprüfungen von Designs und Code, die im Zusammenhang mit externen Schnittstellen
stehen, vorgesehen werden. Damit sollte sich die Anzahl der festgestellten Probleme verringern.
7. Diagramme
-
|