Course Registration System (CREG)

Zusammenfassende Testauswertung für Kt2

 

Version 1.0

Revisionsprotokoll

Datum

Version

Beschreibung

Autor

28. März 1999 1.0 Testauswertung für Release 1.0 (entwickelt in der Iteration Kt2) C. Smith
 
 
 
 
 
 
 
 

 

 

Inhaltsverzeichnis

  1. Zielsetzung
  2. Inhalt und Umfang
  3. Referenzen
  4. Einführung
  5. Testabdeckung
  6. Codeabdeckung
  7. Mängelanalyse
    7.1    Mängeldichte
    7.2    Mängeltrend
    7.3    Mängelalter
  8. Vorgeschlagene Maßnahmen
  9. Diagramme

Zusammenfassende Testauswertung für Kt2

1. Zielsetzung

    Dieser Testauswertungsbericht bezieht sich auf die Tests für Release 1.0 des Course Registration System. Er beschreibt die (anforderungs- und codebasierte) Testabdeckung und die Mängelanalyse (Mängeldichte). Diese Tests wurden während der Iteration Kt2 ausgeführt.

2. Geltungsbereich

Dieser Testauswertungsbericht bezieht sich auf Release 1.0 von CREG, das in der Iteration Kt2 implementiert wurde. Die durchgeführten Tests sind im Testplan [5] beschrieben. Dieser Auswertungsbericht ist für Folgendes zu verwenden:

  • Annehmbarkeit und Angemessenheit des Leistungsverhaltens von R 1.0 des Systems einschätzen
  • Annehmbarkeit der Tests einschätzen
  • Verbesserungen hinsichtlich der Testabdeckung und/oder Testqualität ermitteln

3. Referenzen

Verfügbare Referenzen:

    1. Course Registration System, Glossar (WyIT406) Version 2.0, 1999, Wylie College IT
    2. Course Registration System, Softwareentwicklungsplan (WyIT418) Version 1.0, 1999, Wylie College IT
    3. Course Registration System, Iterationsplan für Kt2 (WyIT500) Version 1.0, 1999, Wylie College IT
    4. Course Registration System, Build-Erstellungsplan zur Integration für Kt2 (WyIT502) Version 1.0, 1999, Wylie College IT
    5. Course Registration System, Testplan (WyIT501) Version 1.0, 1999, Wylie College IT

4. Einführung

    Die in der Testsuite definierten Testfälle wurden gemäß der im Testplan [5] definierten Teststrategie ausgeführt. Die beim Test festgestellten Mängel wurden protokolliert und alle Mängel mit der Priorität 'mittel', 'hoch' oder 'kritisch' wurden dem Eigner zur Beseitigung zugewiesen.

    Die Testabdeckung (siehe folgenden Abschnitt 5.0) liegt bezogen auf die im Testplan [5] definierten Anwendungsfälle und Testanforderungen bei 95 %. 10 Testfälle (Betriebssystem des Systems bei voller Auslastung) konnten aufgrund von Programmfehlern in der Lastsimulationssoftware nicht abgeschlossen werden.

    Die Codeabdeckung wurde mit Rational Visual PureCoverage gemessen und ist im Abschnitt 6.0 beschrieben.

    Die (nachfolgend im Abschnitt 7.0 dargestellte) Mängelanalyse weist aus, dass es sich bei der Mehrzahl der gefundenen Mängel um größere Probleme mit dem Schweregrad 'hoch' oder 'kritisch' handelt. Ein weiteres wichtiges Untersuchungsergebnis ist, dass eine überdurchschnittlich hohe Anzahl von Mängeln bei den Softwarekomponenten für die Schnittstelle zum Kurskatalogsystem aufgetreten sind.

5. Testabdeckung

Die Ausführung aller in der Testsuite definierten Testfälle wurde versucht. 10 Tests konnten wegen Softwarefehlern in der Lastsimulationssoftware nicht abgeschlossen werden. 15 der ausgeführten Testfälle haben den Test nicht bestanden.

Ergebnisse für die Testabdeckung:

Faktor für ausgeführte Testfälle = 110/120 = 92 %

Faktor für erfolgreich ausgeführte Testfälle = 95/110 = 87 %

Bereich mit der höchsten Fehlerquote:

    • Leistungstests mit Zugriff auf das Kurskatalogsystem
    • Belastungstests mit Zugriff auf das Kurskatalogsystem
    • Installation der Clientsoftware

Weitere Details zur Testabdeckung können über Rational RequisitePro und die Testfallmatrix abgerufen werden.

6. Codeabdeckung

    Die Codeabdeckung der Tests wurde mit Visual PureCoverage gemessen.

    Faktor für ausgeführte Codezeilen = 94.399/102.000 = 93 %

    Während der Tests wurden ca. 93 % des Codes ausgeführt. Das Ziel von 90 % wurde damit überschritten.

7. 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.

7.1     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)

Die Grafik der Mängel nach Schweregrad zeigt, dass 26 von 36 protokollierten Mängeln mit dem Schweregrad 'hoch' oder 'kritisch' eingestuft sind. Das ist eine sehr hohe Anzahl, zumal das Release erst freigegeben werden kann, wenn alle Mängel der Priorität 'hoch' oder 'kritisch' geschlossen sind.

Die Grafik der Mängelverursacher zeigt einen überdurchschnittlichen hohen Anteil von Mängeln bei den Komponenten (c-abx, c-xxx), die die Schnittstelle zum Kurskatalogsystem bilden. Darüber hinaus gibt es viele Mängel bei den Softwarekomponenten, die die Installation der Clientsoftware steuern.

Die Grafik zum Mängelstatus zeigt, dass die Mängel sofort zugewiesen und bearbeitet werden. Die Mehrzahl der Mängel wurde überprüft und geschlossen.

Darüber hinaus hat die Analyse der Mängel mit kritischer und hoher Priorität ergeben, dass viele dieser Mängel auf zu lange Antwortzeiten beim Zugriff auf das Kurskatalogsystem in Lastspitzen zurückzuführen sind. (Nur 50 % der Testfälle zur Prüfung der Leistungsanforderungen haben den Test bestanden.)

7.2     Mängeltrend

      Der Mängeltrend (d. h. die Anzahl der Mängel über der Zeit) ist in der Grafik im Abschnitt 9 dargestellt. Dieser Trend zeigt, dass die Anzahl auftretender Mängel unverändert hoch ist. Falls dieser Trend anhält, müssen zusätzliche Iterationen in Erwägung gezogen werden, um noch bestehende Mängel im Code zu finden.

7.3     Mängelalter

Das Diagramm zum Mängelalter (siehe Abschnitt 9) zeigt, dass bis zum Schließen einiger Mängel mehr als 30 Tage vergehen.

 8.  Vorgeschlagene Maßnahmen

Folgende Maßnahmen werden empfohlen:

  1. Es sollten weiterhin Systementwickler beauftragt werden, sich mit dem Antwortzeitproblem des Kurskatalogsystems zu beschäftigen. Dies ist ein kritisches Problem, da Release 1.0 nicht freigegeben werden kann, wenn die Leistungsanforderungen nicht erfüllt sind.
  2. Es sollte überprüft werden, ob der Master-Terminplan in der Konstruktionsphase das Hinzufügen einer vierten Iteration zulässt. Der Trend der Mängel über der Zeit weist darauf hin, dass der Code noch viele Mängel enthält und ein zusätzlicher Testzyklus ratsam ist.
  3. Komponenten mit hoher Mängelquote sollten vor der Erstellung eines neuen Builds überprüft werden. Dazu gehören c-abx und c-xxx.
  4. Der hohe Anteil von Mängeln mit dem Schweregrad 'kritisch' oder 'hoch' kann ein Hinweis darauf sein, dass das Design unvollständig war und nicht ordnungsgemäß überprüft wurde. Für Release 2.0 sollten weitere Designprüfungen eingeplant werden.
  5. Die Probleme mit der Lastsimulationssoftware sind zu beheben. Anschließend müssen die betreffenden Tests erneut ausgeführt werden.
  6. Das Alter der Mängel muss untersucht werden. Warum dauert die Beseitigung einiger Mängeln länger als 30 Tage?
 9.  Diagramme
Im obigen Inhalt beschriebene Abbildung
Im obigen Inhalt beschriebene Abbildung
Im obigen Inhalt beschriebene Abbildung
Im obigen Inhalt beschriebene Abbildung
Im obigen Inhalt beschriebene Abbildung

Copyright  (c) IBM Corp. 1987, 2004. Alle Rechte vorbehalten. 

Webbeispiel CREG-Projekt (Course Registration)
Version 2001.03