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

  1. Einführung
  2. Zusammenfassung der Testergebnisse
  3. Testabdeckung
  4. Codeabdeckung
  5. Mängelanalyse
  6. Vorgeschlagene Maßnahmen
  7. Diagramme

Zusammenfassende Testauswertung

für den

Architekturprototyp

  1. Einführung
    1. Verwendungszweck
    2. 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).

    3. Geltungsbereich
    4. 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
    5. Referenzen
    6. 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, Ausarbeitungsiteration A1 (WyIT420) Version 1.0, 1999, Wylie College IT
        4. Course Registration System, Build-Erstellungsplan zur Integration für den Architekturprototyp (WyIT430) Version 1.0, 1999, Wylie College IT
        5. Course Registration System, Testplan für den Architekturprototyp (WyIT432) Version 1.0, 1999, Wylie College IT
  2. Zusammenfassung der Testergebnisse

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

  4. Testabdeckung
  5. 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.

     

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

  8. Mängelanalyse
  9. 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.

    1. Mängeldichte
    2. 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.

    3. Mängeltrend
    4. Der Mängeltrend (d. h. die Anzahl der Mängel über der Zeit) wurde für die Tests des Architekturprototyps nicht ermittelt.

    5. Mängelalter
    6. 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.

  10. Vorgeschlagene Maßnahmen
  11. Folgende Maßnahmen werden empfohlen:

      1. 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.
      2. Zuordnung von Entwicklungsressourcen, um anstehende offene Mängel am Prototyp zu beseitigen
      3. Verzögerung des Starts der nächsten Iteration bei anstehender Beseitigung von Mängeln der Priorität 'kritisch' und 'hoch'
      4. 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.
      5. 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
  1. 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