Course Registration System (CREG)

Testplan

 

Version 1.0

Revisionsprotokoll

Datum

Version

Beschreibung

Autor

27. März 1999 1.0 Testplan für Release 1 und 2 K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

Inhaltsverzeichnis

  1. Zielsetzung
  2. Inhalt und Umfang
  3. Referenzen
  4. Zu testende Anforderungen
  5. Teststrategie
    1. Testarten
      1. Daten- und Datenbankintegrität testen
      2. Systemtests
      3. Geschäftszyklen testen
      4. Benutzerschnittstelle testen
      5. Leistungstests
      6. Belastungstests
      7. Stresstests
      8. Volumentests
      9. Sicherheit und Zugriffssteuerung testen
      10. Funktionsübernahme/Wiederherstellung testen
      11. Konfigurationstests
      12. Installationstests
    2. Tools
  6. Ressourcen
    1. Mitarbeiter
    2. System
  7. Projektmeilensteine
  8. Arbeitsergebnisse
    1. Testsuite
    2. Testprotokolle
    3. Mängelberichte
  9. Projektaufgaben

Testplan

 

1. Zielsetzung

Dieses Dokument beschreibt den Testplan für das Course Registration System. Dieses Testplandokument unterstützt folgenden Zielsetzungen:

    • Vorhandene Projektinformationen und die zu testende Softwarekomponenten angeben
    • Empfehlungen für die zu testenden Anforderungen auflisten
    • Anzuwendende Teststrategien empfehlen und beschreiben
    • Erforderliche Ressourcen benennen und eine Einschätzung des Testaufwands geben
    • Arbeitsergebniselemente der Testaufgaben auflisten

2. Inhalt und Umfang

    Dieser Testplan umfasst die Integrations- und Systemtests für Release 1 und 2 des CREG-Systems. Beachten Sie, dass es einen zusätzlichen Testplan [17] gibt, der die Teststrategie für den Architekturprototyp beschreibt.

    Es wird vorausgesetzt, dass bereits grünliche Blackboxtests mit breiter Quellcodeabdeckung durchgeführt wurden und alle Modulschnittstellen getestet wurden.

    Dieser Testplan gilt für die Tests aller Anforderungen an das Kursregistrierungssystem, wie sie im Visionsdokument [3], in den Spezifikationen der Anwendungsfälle [5-12] und in der ergänzenden Spezifikation [13] definiert sind.

3. Referenzen

Verfügbare Referenzen:

    1. Spezifikation der Abrechnungsschnittstelle für Kursgebühren WC93332, 1985, Wylie College Press
    2. Spezifikation der Kurskatalogdatenbank WC93422, 1985, Wylie College Press
    3. Course Registration System, Visionsdokument (WyIT387) Version 1.0, 1998, Wylie College IT
    4. Course Registration System, Glossar (WyIT406) Version 2.0, 1999, Wylie College IT
    5. Course Registration System, Spezifikation für den Anwendungsfall 'Registrierung abschließen' (WyIT403) Version 2.0, 1999, Wylie College IT
    6. Course Registration System, Spezifikation für den Anwendungsfall 'Anmeldung' (WyIT401) Version 2.0, 1999, Wylie College IT
    7. Course Registration System, Spezifikation für den Anwendungsfall 'Dozenteninformationen verwalten' (WyIT407) Version 2.0, 1999, Wylie College IT
    8. Course Registration System, Spezifikation für den Anwendungsfall 'Registrierung für Kurse' (WyIT402) Version 2.0, 1999, Wylie College IT
    9. Course Registration System, Spezifikation für den Anwendungsfall 'Zu haltende Kurse auswählen' (WyIT405) Version 2.0, 1999, Wylie College IT
    10. Course Registration System, Spezifikation für den Anwendungsfall 'Studenteninformationen verwalten' (WyIT408) Version 2.0, 1999, Wylie College IT
    11. Course Registration System, Spezifikation für den Anwendungsfall 'Noten erfassen' (WyIT409) Version 2.0, 1999, Wylie College IT
    12. Course Registration System, Spezifikation für den Anwendungsfall 'Zeugnis anzeigen' (WyIT410) Version 2.0, 1999, Wylie College IT
    13. Course Registration System, Ergänzende Spezifikation (WyIT400) Version 1.0, 1999, Wylie College IT
    14. Course Registration System, Softwareentwicklungsplan (WyIT418) Version 2.0, 1999, Wylie College IT
    15. Course Registration System, Softwarearchitekturdokument (WyIT431) Version 1.0, 1999, Wylie College IT
    16. Course Registration System, Richtlinien für Anforderungsattribute (WyIT404) Version 1.0, 1999, Wylie College IT
    17. Course Registration System, Testplan für den Architekturprototyp (WyIT432) Version 1.0, 1999, Wylie College IT

4. Zu testende Anforderungen

    Die folgende Auflistung enthält die Elemente (Anwendungsfälle, funktionale Anforderungen, nicht funktionale Anforderungen), die als Testobjekte ermittelt wurden. Sie gibt an, welche Elemente getestet werden. Details zu den einzelnen Tests werden später festgelegt, wenn die Testfälle identifiziert und die Test-Scripts entwickelt werden.

    (Anmerkung: In künftigen Releases dieses Testplans können Sie mit Rational RequisitePro eine direkte Verknüpfung zu den Anforderungen im Visionsdokument, in den Anwendungsfalldokumenten und der ergänzenden Spezifikation erstellen.)

    Daten- und Datenbankintegrität testen

    Zugang zur Kurskatalogdatenbank überprüfen

    Parallele Lesezugriffe auf die Datenbank überprüfen

    Sperre bei Aktualisierung des Kurskatalogs überprüfen

    Korrekten Abruf der Aktualisierung der Datenbankdaten überprüfen

    Systemtests (Funktionstests)

    Anwendungsfall 'Anmeldung' [6] verifizieren

    Anwendungsfall 'Registrierung abschließen' [5] verifizieren

    Anwendungsfall 'Studenteninformationen verwalten' [10] verifizieren

    Anwendungsfall 'Dozenteninformationen verwalten' [7] verifizieren

    Anwendungsfall 'Noten erfassen' [11] verifizieren

    Anwendungsfall 'Zeugnis anzeigen' [12] verifizieren

    Anwendungsfall 'Registrierung für Kurse' [8] verifizieren

    Anwendungsfall 'Zu haltende Kurse auswählen' [9] verifizieren

    Ergänzende Spezifikation, Abschnitt 4.1: "Alle Systemfehler müssen protokolliert werden. Bei schwerwiegenden Fehlern sollte das System ordnungsgemäß heruntergefahren werden."

    Ergänzende Spezifikation, Abschnitt 4.1: "Die Fehlernachrichten des Systems müssen eine Beschreibung des Fehlers, ggf. den Fehlercode des Betriebssystems, das Modul, bei dem die Fehlerbedingung festgestellt wurde, eine Datumsmarke und eine Zeitmarke enthalten. Alle Systemfehler müssen in der Fehlerprotokolldatenbank gespeichert werden."

    Visionsdokument, Abschnitt 12.2: "Das System muss an das vorhandene Kurskatalogdatenbanksystem angebunden werden. CREG muss das im Dokument [2] definierte Datenformat unterstützen."

    Visionsdokument, Abschnitt 12.2: "Das System muss an das vorhandene Gebührenabrechnungssystem angebunden werden und das im Dokument [1] definierte Datenformat unterstützen."

    Visionsdokument, Abschnitt 12.2: "Die Serverkomponente des Systems muss auf dem Kampusserver des College unter dem Betriebssystem UNIX ausgeführt werden."

    Ergänzende Spezifikation, Abschnitt 9.3: "Die Serverkomponente des Systems muss auf dem UNIX-Server des Wylie College ausgeführt werden."

    Visionsdokument, Abschnitt 12.2: "Die Clientkomponente des Systems soll auf jedem Personal Computer ausgeführt werden können, der mindestens mit einem 486-er Mikroprozessor ausgestattet ist."

    Ergänzende Spezifikation, Abschnitt 9.3: "Die Clientkomponente des Systems soll auf jedem Personal Computer ausgeführt werden können, der mindestens mit einem 486-er Mikroprozessor ausgestattet ist."

    Ergänzende Spezifikation, Abschnitt 9.1: "Das System soll in ein vorhandenes herkömmliches System (Kurskatalogdatenbank) integriert werden, das auf dem Großrechner des College (DEC VAX) ausgeführt wird."

    Ergänzende Spezifikation, Abschnitt 9.2: "Das System soll in das vorhandene Abrechnungssystem für Studiengebühren integriert werden, das auf dem Großrechner des College (DEC VAX) ausgeführt wird."

    Geschäftszyklen testen

Betrieb nach dem Download eines neuen Kurskatalogs prüfen

Betrieb für mehrere Semester und Jahrgänge prüfen

Fehlerfreien Betrieb für Semester prüfen, die sich über den Jahreswechsel hinaus erstrecken

    Benutzerschnittstelle testen

    Einfachheit der Navigation durch eine Stichprobe von Anzeigen überprüfen

    Übereinstimmung von Beispielanzeigen mit den GUI-Standards überprüfen

    Visionsdokument, Abschnitt 10: "Das System soll benutzerfreundlich und dem Zielmarkt (computererfahrene Studenten und Dozenten) angemessen sein."

    Visionsdokument, Abschnitt 12.1: "Die Desktop-Benutzerschnittstelle muss mit Windows 95/98 kompatibel sein."

    Ergänzende Spezifikation, Abschnitt 5.1: "Die Desktop-Benutzerschnittstelle muss mit Windows 95/98 kompatibel sein."

    Ergänzende Spezifikation, Abschnitt 5.2: "Die Benutzerschnittstelle des CREG-Systems soll einen hohen Bedienungskomfort haben. Sie ist für computererfahrene Benutzergruppen bestimmt, die keine zusätzliche Schulung für das System benötigen."

    Ergänzende Spezifikation, Abschnitt 5.3: "Zu jedem Feature des CREG-Systems muss es eine integrierte Onlinehilfe für den Benutzer geben. Die Onlinehilfe soll eine schrittweise Anleitung für die Verwendung des Systems enthalten. In der Onlinehilfe müssen Begriffe und Akronyme definiert sein."

    Leistungstests

    Antwortzeit beim Zugriff auf das Finanzsystem überprüfen

    Antwortzeit beim Zugriff auf das Kurskatalogsubsystem überprüfen

    Antwortzeit bei der Fernanmeldung überprüfen

    Antwortzeit bei der fernen Übergabe der Kursregistrierung überprüfen

    Visionsdokument, Abschnitt 12.3: "Die Latenzzeit des Systems beim Zugriff auf die herkömmliche Katalogdatenbank darf nicht mehr als 10 Sekunden betragen."

    Ergänzende Spezifikation, Abschnitt 7.2: "Die Latenzzeit des Systems beim Zugriff auf die herkömmliche Katalogdatenbank darf nicht mehr als 10 Sekunden betragen."

    Belastungstests

    Systemantwort bei 200 angemeldeten Studenten überprüfen

    Systemantwort bei 50 gleichzeitig auf den Kurskatalog zugreifenden Studenten überprüfen

    Ergänzende Spezifikation, Abschnitt 7.1: "Das System muss jederzeit bis zu 2000 gleichzeitige Benutzer der zentralen Datenbank und bis zu 500 gleichzeitige Benutzer des lokalen Servers unterstützen."

    Stresstests

    Systemantwort während der Hauptnutzungszeit des UNIX-Servers prüfen

    Systemantwort bei maximaler Anzahl angemeldeter Studenten prüfen

    Volumentests

    Systemantwort bei 90 % Kapazität der Kurskatalogdatenbank prüfen

    Sicherheit und Zugriffssteuerung testen

    Anmeldung an einem lokalen PC überprüfen

    Anmeldung an einem fernen PC überprüfen

    Anmeldesicherheit mit Benutzernamen und Kennwort überprüfen

    Ergänzende Spezifikation, Abschnitt 4.2: "Alle Funktionen müssen per Remote-Zugriff über eine Internet-Verbindung verfügbar sein."

    Funktionsübernahme/Wiederherstellung testen

    Ergänzende Spezifikation, Abschnitt 6.1: "Das CREG-System soll rund um die Uhr verfügbar sein. Die Ausfallzeiten dürfen bei maximal 4 % liegen."

    Ergänzende Spezifikation, Abschnitt 6.2: "Die mittlere Zeit zwischen auftretenden Fehlern soll bei mehr als 300 Stunden liegen."

    Konfigurationstests

    Visionsdokument, Abschnitt 12.2: "Die Clientkomponente des Systems soll unter Windows 95, Windows 98 und Microsoft Windows NT ausgeführt werden können."

    Ergänzende Spezifikation, Abschnitt 9.4: "Die webbasierte Schnittstelle des CREG-Systems muss in den Browsern Netscape 4.04 und Internet Explorer 4.0.4 angezeigt werden können."

    Ergänzende Spezifikation, Abschnitt 9.5: "Die webbasierte Schnittstelle muss mit der Laufzeitumgebung der Java 1.1 VM kompatibel sein."

    Installationstests

    Ergänzende Spezifikation, Abschnitt 8.1: "Upgrades zum Client des Course Registration System müssen über das Internet vom UNIX-Server auf den PC heruntergeladen werden können."

    Installation der Serverkomponente prüfen

    Installation der Clientkomponente prüfen

5. Teststrategie

    Die Teststrategie ist der empfohlene Testansatz für die Softwareanwendungen. Im vorherigen Abschnitt mit den zu testenden Anforderungen wurde beschrieben, was zu testen ist. Hier wird beschrieben, wie die Tests durchgeführt werden.

    Der wichtigste Punkt der Teststrategie sind die anzuwendenden Verfahren und die Kriterien, anhand derer festgestellt werden kann, ob die Tests abgeschlossen sind.

    Tests sollten nur mit bekannten, kontrollierten Datenbanken in geschützten Umgebungen durchgeführt werden. Dieser Hinweis sollte zusätzlich zu den besonderen Hinweisen für die einzelnen Tests beachtet werden.

    Die folgende Teststrategie ist generischer Natur und gilt für die in Abschnitt 4 dieses Dokuments aufgelisteten Anforderungen.

    1. Testarten

1. Daten- und Datenbankintegrität testen

Datenbanken und die Datenbankprozesse sollten als gesonderte Systeme getestet werden. Testen Sie diese Systeme ohne die Anwendungen (als Schnittstelle zu den Daten). Um festzustellen, welche Tools und Verfahren es gibt, um die nachfolgend angegebenen Tests zu unterstützen, muss das DBMS näher untersucht werden.

Testzielsetzung: Sicherstellen, dass die Methoden und Prozesse für den Datenbankzugriff ordnungsgemäß und ohne fehlerhafte Daten funktionieren
Verfahren:
  • Rufen Sie jede Methode und jeden Prozess für den Datenbankzugriff einmal mit gültigen und einmal mit ungültigen Daten (oder Datenanfragen) auf.
  • Überprüfen Sie die Datenbank, um sicherzustellen, dass alle Daten wie vorgesehen eingetragen wurden und alle Datenbankereignisse ordnungsgemäß eingetreten sind, oder prüfen Sie die zurückgegebenen Daten und vergewissern Sie sich, dass die richtigen Daten (aus den richtigen Gründen) abgerufen wurden.
Erfüllungskriterien: Alle Methoden und Prozesse für den Datenbankzugriff funktionieren wie vorgesehen und ohne fehlerhafte Daten.
Besondere Hinweise:
  • Für die Tests könnte eine DBMS-Entwicklungsumgebung erforderlich sein. Möglicherweise werden Treiber benötigt, um Daten direkt in den Datenbanken eingeben und modifizieren zu können.
  • Die Prozesse sollten manuell aufgerufen werden.
  • Kleine Datenbanken oder Minimaldatenbanken (mit einer begrenzten Anzahl von Datensätzen) sollten verwendet werden, um die Erkennbarkeit inakzeptabler Ereignisse zu verbessern.

2. Systemtests

Bei Tests der Anwendung sollte der Schwerpunkt auf alle Zielanforderungen gelegt werden, die direkt aus Anwendungsfällen (oder Geschäftsfunktionen) und Geschäftsregeln abgeleitet werden können. Ziel dieser Tests ist es, die ordnungsgemäße Abnahme, Verarbeitung und Abfrage von Daten sowie die angemessene Implementierung der Geschäftsregeln zu bestätigen. Diese Art von Tests basiert auf Blackboxverfahren, d. h., die Anwendung und ihre internen Prozesse werden durch die Interaktion mit der Anwendung auf der GUI und durch die Analyse der Ausgaben (Ergebnisse) überprüft. Machfolgend sind die Tests angegeben, die für jede Anwendung empfohlen werden:

 

Testzielsetzung: Stellen Sie sicher, dass die Anwendungsnavigation, Dateneingabe, Datenverarbeitung und das Abrufen von Daten ordnungsgemäß funktionieren.
Verfahren:
  • Führen Sie jeden Anwendungsfall, jeden Ablauf innerhalb eines Anwendungsfalls oder jede Funktion mit gültigen und ungültigen Daten aus, um Folgendes zu verifizieren:
  • Bei der Verwendung gültiger Daten werden die erwarteten Ergebnisse erzielt.
  • Bei der Verwendung ungültiger Daten werden die entsprechenden Fehlernachrichten/Warnungen angezeigt.
  • Alle Geschäftsregeln werden ordnungsgemäß angewendet.
Erfüllungskriterien:
  • Alle geplanten Tests wurden ausgeführt.
  • Alle bekannten Mängel wurden bearbeitet.
Besondere Hinweise:
  • Es ist Zugriff auf den UNIX-Server des Wylie College mit dem vorhandenen Kurskatalogsystem und Gebührenabrechnungssystem erforderlich.

3. Geschäftszyklen testen

Tests für einen Geschäftszyklus sollten die Aktivitäten emulieren, die über einen bestimmten Zeitraum für das System ausgeführt werden. Sie sollten einen Zeitraum festlegen, z. B. ein Jahr. Führen Sie dann die Transaktionen und Aktivitäten aus, die im Verlaufe eines Jahres anfallen würden. Dazu gehören alle Tages-, Wochen- und Monatszyklen sowie Ereignisse mit bestimmtem Datum, beispielsweise in Terminkalendern.

 

Testzielsetzung Volle Funktionsfähigkeit der Anwendung und Hintergrundprozesse gemäß den erforderlichen Geschäftsmodellen und -plänen sicherstellen
Verfahren:
  • In den Tests werden verschiedene Geschäftszyklen simuliert. Dazu werden folgende Schritte ausgeführt:
  • Die Funktionstests für die Anwendung werden modifiziert/erweitert, um die Häufigkeit zu steigern, mit der die einzelnen Funktionen ausgeführt werden, und so mehrere verschiedene Benutzer in einem angegebenen Zeitraum zu simulieren.
  • Alle zeit- oder datumsabhängigen Funktionen werden mit gültigen und ungültigen Datumsangaben oder Zeiträumen ausgeführt.
  • Alle regelmäßig wiederkehrenden Funktionen werden zur vorgesehenen Zeit ausgeführt/gestartet.
  • Für die Tests werden gültige und ungültige Daten verwendet, um Folgendes zu verifizieren:
  • Bei der Verwendung gültiger Daten werden die erwarteten Ergebnisse erzielt.
  • Bei der Verwendung ungültiger Daten werden die entsprechenden Fehlernachrichten/Warnungen angezeigt.
  • Alle Geschäftsregeln werden ordnungsgemäß angewendet.
Erfüllungskriterien:
  • Alle geplanten Tests wurden ausgeführt.
  • Alle bekannten Mängel wurden bearbeitet.
Besondere Hinweise:
  • Für Datumsangaben des Systems und Systemereignisse können spezielle unterstützende Aktivitäten erforderlich sein.
  • Zur Bestimmung der geeigneten Testanforderungen und Vorgehensweisen ist ein Geschäftsmodell erforderlich.

4. Benutzerschnittstelle testen

Beim Testen der Benutzerschnittstelle wird die Benutzerinteraktion mit der Software überprüft. Mit Tests der Benutzerschnittstelle soll sichergestellt werden, dass der Benutzer über die Schnittstelle angemessen auf die Funktionen der Anwendungen zugreifen und durch diese Funktionen navigieren kann. Mit Tests der Benutzerschnittstelle kann außerdem festgestellt werden, ob die Objekte auf der Schnittstelle wie erwartet funktionieren und Firmenstandards bzw. Industrienormen entsprechen.

 

Testzielsetzung: Prüfen Sie Folgendes:
  • Es ist eine einwandfreie Navigation durch die Anwendung gemäß den Geschäftsfunktionen und -anforderungen möglich. Dazu gehören die Navigation von Fenster zu Fenster sowie von Feld zu Feld und die Anwendung von Zugriffsmethoden (Tabulatortaste, Mausbewegungen, Direktaufruftasten).
  • Fensterobjekte, z. B. Menüs, und Fenstermerkmale wie Größe, Position, Status und Fokus entsprechen den Standards.
Verfahren:
  • Erstellen/Modifizieren Sie Tests für jedes Fenster, um die ordnungsgemäße Navigation und korrekte Objektstatus für jedes Fenster und Objekt der Anwendung zu verifizieren.
Erfüllungskriterien: Für jedes Fenster wurde nachgewiesen, dass es der Benchmark-Version entspricht oder innerhalb der Norm liegt.
Besondere Hinweise:
  • Es kann nicht auf alle Merkmale von kundenspezifischen Objekten oder Objekten von Fremdanbietern zugegriffen werden.

5. Leistungstests

Während der Leistungstests werden Antwortzeiten, Transaktionsraten und andere zeitkritische Anforderungen gemessen. Die Leistungstests sollen sicherstellen, dass die Leistungsanforderungen erfüllt werden. In der Regel werden Leistungstests mehrfach, jeweils mit einer anderen "Hintergrundlast" für das System durchgeführt. Der erste Test sollte mit einer "Nominallast" durchgeführt werden, die der normalen, auf dem Zielsystem festgestellten (oder zu erwartenden) Auslastung vergleichbar ist. Ein zweiter Leistungstest wird dann unter Spitzenbelastung durchgeführt.

Leistungstests können darüber hinaus durchgeführt werden, um die Leistung eines Systems als Funktion von Bedingungen wie der Auslastung oder Hardwarekonfigurationen zu optimieren und darzustellen.

ANMERKUNG: Der Begriff 'Transaktionen' steht im Folgenden für 'logische Geschäftstransaktionen'. Diese Transaktionen werden als spezifische Funktionen definiert, die ein Systembenutzer wahrscheinlich mit der Anwendung ausführen wird. Ein Beispiel wäre das Hinzufügen oder Modifizieren eines bestimmten Vertrages.

 

Testzielsetzung: Validieren Sie die Antwortzeit des Systems für die bezeichneten Transaktionen oder Geschäftsfunktionen unter den beiden folgenden Bedingungen:

- zu erwartendes normales Aufkommen

- schlimmstes zu erwartendes Aufkommen

Verfahren:
  • Verwenden Sie die für Geschäftsmodelltests (Systemtests) entwickelten Test-Scripts.
  • Modifizieren Sie Datendateien, um die Anzahl der Transaktionen zu erhöhen, oder Scripts, um die Anzahl der Iterationen für die einzelnen Transaktionen erhöhen.
  • Scripts sollten auf einer Maschine ausgeführt werden (am besten mit einem Benutzer und einer Einzeltransaktion als Benchmark) und dann mit mehreren (virtuellen oder realen) Clients wiederholt werden (siehe folgenden Abschnitt 'Besondere Hinweise').
Erfüllungskriterien:
  • Einzeltransaktion/Einzelbenutzer: Die Test-Scripts wurden fehlerfrei und innerhalb der erwarteten/erforderlichen Zeit (pro Transaktion) ausgeführt.
  • Mehrere Transaktionen/Benutzer: Die Test-Scripts wurden fehlerfrei und innerhalb eines vertretbaren Zeitrahmens ausgeführt.
Besondere Hinweise:
  • Bei umfassenden Leistungstests gibt es auf dem Server eine Hintergrundauslastung. Dies kann mit verschiedenen Methoden erreicht werden. Dazu gehören unter anderem:
    • Direkte Auslösung von Transaktionen auf dem Server, in der Regel durch SQL-Aufrufe
    • Erzeugung einer virtuellen Benutzerauslastung, um viele (in der Regel mehrere hundert) Clients zu simulieren. Für eine solche Auslastung werden Tools für die Emulation ferner Terminals verwendet. Sie können dieses Verfahren auch anwenden, um im Netz eine Belastung mit Datenverkehr zu erzeugen.
    • Verwendung mehrerer physischer Clients, von denen jeder ein Test-Script ausführt, um das System zu belasten
  • Leistungstests sollten auf einer dedizierten Maschine oder zu einer dedizierten Zeit ausgeführt werden, um die volle Kontrolle zu haben und genaue Messungen durchführen zu können.
  • Die Größe der Datenbanken für Leistungstests sollte der tatsächlichen Größe entsprechen oder entsprechend skaliert werden.

6. Belastungstests

Bei Belastungstests wird das zu testende System verschiedenen Belastungen ausgesetzt, um beurteilen zu können, in wie weit das System fähig ist, unter diesen verschiedenen Bedingungen fehlerfrei zu funktionieren. Mit einem Belastungstest soll festgestellt und sichergestellt werden, dass das System auch jenseits der erwarteten maximalen Auslastung fehlerfrei funktioniert. Belastungstests dienen außerdem der Bewertung von Leistungsmerkmalen (Antwortzeit, Transaktionsrate und andere zeitkritische Merkmale).

ANMERKUNG: Der Begriff 'Transaktionen' steht im Folgenden für 'logische Geschäftstransaktionen'. Diese Transaktionen werden als spezifische Funktionen definiert, die ein Systembenutzer wahrscheinlich mit der Anwendung ausführen wird. Ein Beispiel wäre das Hinzufügen oder Modifizieren eines bestimmten Vertrages.

Testzielsetzung: Überprüfen Sie die Antwortzeit des Systems für die vorgegebenen Transaktionen oder Geschäftsfälle unter variierenden Lastbedingungen.
Verfahren:
  • Verwenden Sie die für Geschäftszyklen entwickelten Tests.
  • Modifizieren Sie Datendateien, um die Anzahl der Transaktionen zu erhöhen, oder die Tests, um die Häufigkeit zu steigern, mit der die einzelnen Transaktionen ausgeführt werden.
Erfüllungskriterien:
  • Mehrere Transaktionen/Benutzer: Die Tests wurden fehlerfrei und innerhalb eines vertretbaren Zeitrahmens ausgeführt.
Besondere Hinweise:
  • Belastungstests sollten auf einer dedizierten Maschine oder zu einer dedizierten Zeit ausgeführt werden, um die volle Kontrolle zu haben und genaue Messungen durchführen zu können.
  • Die Größe der Datenbanken für Belastungstests sollte der tatsächlichen Größe entsprechen oder entsprechend skaliert werden.

7. Stresstests

Stresstests sollen Fehler finden, die bei knappen Ressourcen oder beim Konkurrenzkampf um Ressourcen auftreten. Bei geringer Speicherkapazität und wenig Plattenspeicherplatz können Mängel der Software sichtbar werden, die unter normalen Bedingungen nicht erkannt werden. Andere Mängel können auf Konkurrenzsituationen bei gemeinsam benutzten Ressourcen (wie Datenbanksperren oder Netzbandbreite) zurückzuführen sein. Stresstests ermitteln die Spitzenbelastung, der das System gewachsen ist.

ANMERKUNG: Der nachfolgend verwendete Begriff "Transaktionen" bezieht sich auf logische Geschäftstransaktionen.

Testzielsetzung: Bestätigen, dass das System und die Software unter den folgenden Stressbedingungen einwandfrei funktionieren:
  • wenig oder kein Speicher auf dem Server verfügbar (Arbeitsspeicher und DASD)
  • tatsächliche (oder physisch realisierbare) Maximalanzahl angeschlossener (oder simulierter) Clients
  • mehrere Benutzer, die dieselbe Transaktion für dieselben Daten/Accounts ausführen
  • denkbar schlimmstes Transaktionsvolumen / denkbar ungünstigster Transaktionsmix (siehe obige Leistungstests)

ANMERKUNGEN: Die Zielsetzung der Stresstests könnte auch sein, die Bedingungen, unter denen das System NICHT MEHR ordnungsgemäß funktioniert, zu identifizieren und zu dokumentieren.

Verfahren:
  • Verwenden Sie Tests, die für die Leistungstests entwickelt wurden.
  • Wenn Sie begrenzte Ressourcen testen möchten, führen Sie die Tests auf nur einer Maschine aus. Arbeitsspeicher und DASD auf dem Server sollten eingeschränkt sein.
  • Für die übrigen Stresstests sollten mehrere Clients verwendet werden, mit denen identische oder komplementäre Tests ausgeführt werden, um das Worst-Case-Szenario für das Transaktionsaufkommen oder die Kombination von Transaktionen zu erzeugen.
Erfüllungskriterien: Alle geplanten Tests wurden ausgeführt. Die angegebenen Systemgrenzen wurden ohne einen Softwarefehler erreicht/überschritten. (Die Bedingungen, unter denen ein Systemfehler auftritt, liegen jenseits der spezifizierten Bedingungen.)
Besondere Hinweise:
  • Zur Erzeugung von Stress im Netz können Netztools erforderlich sein, die das Netz mit Nachrichten/Paketen belasten.
  • Die für das System verwendete DASD sollte temporär eingeschränkt werden, um den für das Anwachsen der Datenbank verfügbaren Speicherplatz zu beschränken.
  • Die parallelen Clientzugriffe auf dieselben Datensätze/Datenaccounts müssen synchronisiert werden.

8. Volumentests

Beim Volumentest wird die Software einer großen Datenmenge ausgesetzt, um festzustellen, ob Grenzen erreicht werden, die einen Softwareausfall oder -fehler bewirken. Mit Volumentests kann ermittelt werden, welche kontinuierliche maximale Last bzw. welches kontinuierliche maximale Volumen das System über einen bestimmten Zeitraum bewältigen kann. Wenn die Software beispielsweise eine Reihe von Datenbanksätzen verarbeitet, um einen Bericht zu generieren, könnten Sie für einen Volumentest eine große Testdatenbank verwenden und überprüfen, ob sich die Software normal verhält und den richtigen Bericht erzeugt.

Testzielsetzung: Bestätigen, dass die Anwendung bzw. das System in den folgenden Szenarien mit hohem Datenvolumen fehlerfrei funktioniert:
  • Tatsächliche (oder physisch realisierbare) maximale Anzahl angeschlossener (oder simulierter) Clients, die über einen vorgegebenen Zeitraum alle dieselbe Geschäftsfunktion (Worst-Case-Szenario) ausführen
  • Die maximale Datenbankgröße ist erreicht (tatsächlich oder durch Skalierung) und mehrere Transaktionen für Abfragen/Berichte werden gleichzeitig ausgeführt.
Verfahren:
  • Verwenden Sie Tests, die für die Leistungstests entwickelt wurden.
  • Mit mehreren Clients werden identische oder komplementäre Tests ausgeführt, um das Worst-Case-Szenario für das Transaktionsaufkommen oder die Kombination von Transaktionen über einen längeren Zeitraum zu erzeugen (siehe obige Stresstests).
  • Es wird eine Datenbank maximaler Größe erstellt (tatsächlich, durch Skalierung oder durch Eingabe repräsentativer Daten), und mehrere Clients führen parallel und über einen längeren Zeitraum Transaktionen für Abfragen/Berichte aus.
Erfüllungskriterien: Alle geplanten Tests wurden ausgeführt. Die angegebenen Systemgrenzen wurden ohne einen Softwarefehler erreicht/überschritten.
Besondere Hinweise:
  • Welcher Zeitraum ist für Bedingungen mit hohem Volumen (wie sie oben geschildert wurden) angemessen?

9. Sicherheit und Zugriffssteuerung testen

Beim Testen der Sicherheit und der Zugriffssteuerung liegt der Schwerpunkt auf zwei Sicherheitsbereichen:

Anwendungssicherheit, einschließlich des Zugriffs auf die Daten oder Geschäftsfunktionen;
Systemsicherheit, einschließlich Anmeldung beim System und Remote-Zugriff auf das System

Ausgehend von Ihren Sicherheitsanforderungen kann die Anwendungssicherheit gewährleisten, dass sich Benutzer auf bestimmte Funktionen beschränken oder dass den Benutzern nur begrenzte Daten zur Verfügung stehen. Es wäre beispielsweise möglich, dass jeder Daten eingeben und neue Accounts erstellen kann, diese Daten und Accounts jedoch nur von Managern gelöscht werden dürfen. Falls es Sicherheitsvorkehrungen auf der Datenebene gibt, kann mit diesen Tests sichergestellt werden, dass der "Benutzer des Typs eins" alle Kundeninformationen sehen kann (einschließlich finanzieller Daten), der "Benutzer des Typs 2" für denselben Kunden jedoch nur demographische Daten sieht.

Die Systemsicherheit gewährleistet, dass nur Benutzer mit erteilter Zugriffsberechtigung über die entsprechenden Gateways auf die Anwendungen zugreifen können.

Testzielsetzung: Funktions-/Datensicherheit: Bestätigen Sie, dass ein Benutzer nur auf die Funktionen/Daten zugreifen, für die sein Benutzertyp berechtigt ist.

Systemsicherheit: Bestätigen Sie, dass der Zugriff auf das System und auf Anwendungen nur berechtigten Benutzern gewährt wird.

Verfahren:
  • Funktions-/Datensicherheit: Benennen Sie alle Benutzertypen und listen Sie die Funktionen/Daten auf, für die jeder einzelne Typ eine Zugriffsberechtigung hat.
  • Entwickeln Sie Tests für jeden Benutzertyp und verifizieren Sie die Berechtigungen, indem Sie spezifische Transaktionen für die verschiedenen Benutzertypen erstellen.
  • Modifizieren Sie den Benutzertyp und wiederholen Sie die Tests mit denselben Benutzern. Überprüfen Sie in jedem einzelnen Fall, ob die zusätzlichen Funktionen/Daten richtigerweise verfügbar oder nicht verfügbar sind.
  • Systemzugriff (siehe folgenden Abschnitt 'Besondere Hinweise')
Erfüllungskriterien: Für jeden bekannten Benutzertyp sind die entsprechenden Funktionen/Daten verfügbar. Alle Transaktionen können wie erwartet und in den vorherigen Anwendungsfunktionstests bestätigt ausgeführt werden.
Besondere Hinweise:
  • Der Zugriff auf das System muss mit dem jeweiligen Netz- oder Systemadministrator besprochen werden. Möglicherweise sind diese Tests nicht erforderlich, da sie in den Zuständigkeitsbereich des Netz- oder Systemadministrators fallen.

10. Funktionsübernahme/Wiederherstellung testen

Durch das Testen der Funktionsübernahme/Wiederherstellung kann sichergestellt werden, dass bei diversen Fehlfunktionen der Hardware, der Software oder des Netzes ein Ausweichbetrieb für eine Anwendung oder ein ganzes System oder eine Wiederherstellung der Anwendung bzw. des Systems ohne Datenverlust oder eine Verletzung der Datenintegrität möglich ist.

Für Systeme im Dauerbetrieb kann ein Funktionsübernahmetest sicherstellen, dass das alternative System oder Ausweichsystem unter den entsprechenden Bedingungen die Funktionen des ausgefallenen Systems übernimmt, ohne dass es zu einem Verlust von Daten oder Transaktionen kommt.

Der Wiederherstellungstest ist ein antagonistischer Testprozess, bei dem die Anwendung oder das System extremen (oder simulierten) Bedingungen ausgesetzt wird, um einen Fehler/Ausfall hervorzurufen, z. B. einen E/A-Fehler einer Einheit oder ungültige Datenbankzeiger und -schlüssel. Es werden Wiederherstellungsprozesse aufgerufen. Die Anwendung oder das System wird überwacht und/oder untersucht, um zu verifizieren, dass die Anwendung bzw. das System oder die Daten ordnungsgemäß wiederhergestellt wurden.

Testzielsetzung: Bestätigen Sie, dass die (manuelle oder automatisierte) Wiederherstellung die die Datenbank, die Anwendungen und das System in den bekannten Sollstatus zurückzuversetzt. Für diese Tests sind unter anderem die folgenden Arten von Bedingungen erforderlich:
  • Unterbrechung der Stromzufuhr zum Client
  • Unterbrechung der Stromzufuhr zum Server
  • Unterbrechung der Kommunikation zwischen Netzservern
  • Unterbrechung der Kommunikation von DASD-Einheiten und -Controllern oder Unterbrechung der Stromzufuhr zu diesen Einheiten und Controllern
  • Unvollständige Zyklen (unterbrochene Datenfilterprozesse, unterbrochene Datensynchronisationsprozesse)
  • Ungültige Datenbankzeiger/-schlüssel
  • Ungültige/beschädigte Datenelemente in der Datenbank
Verfahren: Für die Tests der Anwendungsfunktionen und Geschäftszyklen sollte eine Reihe von Transaktionen erstellt werden. Wenn der für den Testbeginn gewünschte Punkt erreicht ist, sollten die folgenden Aktionen einzeln ausgeführt (oder simuliert) werden:
  • Unterbrechung der Stromzufuhr zum Client: Schalten Sie den PC aus.
  • Unterbrechung der Stromzufuhr zum Server: Simulieren Sie die Ausschaltprozedur für den Server oder leiten Sie die Prozedur tatsächlich ein.
  • Unterbrechung der Kommunikation zwischen Netzservern: Simulieren Sie den Verlust der Kommunikation mit dem Netz oder leiten Sie den entsprechenden Prozess tatsächlich ein (Abziehen der Übertragungskabel oder Abschalten von Netzservern/-routern).
  • Unterbrechung der Kommunikation von DASD-Einheiten und/oder -Controllern oder Unterbrechung der Stromzufuhr zu diesen Einheiten und Controllern: Simulieren Sie den Ausfall der Kommunikation mit mindestens einer DASD-Einheit oder mindestens einem DASD-Controller oder unterbrechen Sie die Kommunikation physisch.

Sobald die oben beschriebenen Bedingungen oder deren Simulation erreicht ist, sollten Sie zusätzliche Transaktionen ausführen. An diesem Testpunkt sollten die Wiederherstellungsprozeduren aufgerufen werden.

Beim Testen auf unvollständige Zyklen werden dieselben Verfahren wie oben angewendet, nur dass hier die Datenbankprozesse abgebrochen bzw. vorzeitig beendet werden.

Beim Testen der folgenden Bedingungen muss ein bekannter Datenbankstatus erreicht werden. Verwenden Sie Datenbanktools, um mehrere Datenbankfelder, -zeiger und -schlüssel manuell und direkt in der Datenbank zu beschädigen. Führen Sie zusätzliche Transaktionen aus. Ziehen Sie dazu die Tests der Anwendungsfunktionen, Geschäftszyklen und vollständigen Zyklen heran.

Erfüllungskriterien: Die Anwendung, die Datenbank und das System sollte in allen oben genannten Fällen nach Abschluss der Wiederherstellungsverfahren einen bekannten Sollstatus haben. Beschädigte Daten sind auf die bekannten beschädigten Felder,Zeiger und Schlüssel beschränkt. Prozesse oder Transaktionen, die durch die Unterbrechungen nicht abgeschlossen werden konnten, sind in einem Bericht erfasst.
Besondere Hinweise:
  • Wiederherstellungstests sind ein erheblicher Systemeingriff. Das Abziehen von Kabeln (für eine Unterbrechung der Stromzufuhr oder der Kommunikation) ist unter Umständen nicht erwünscht oder machbar. Es können alternative Methoden erforderlich sein, z. B. die Verwendung von Softwarediagnosetools.
  • Es werden Ressourcen der Systeme (Computeroperationen), der Datenbank und der Netzgruppen benötigt.
  • Diese Tests sollten nach Geschäftsschluss oder auf isolierten Maschinen durchgeführt werden.

11. Konfigurationstests

Mit Konfigurationstests wird der Softwarebetrieb in unterschiedlichen Software- und Hardwarekonfigurationen überprüft. In den meisten Produktionsumgebungen variieren die Hardwarespezifikationen für die Clientworkstations, die Netzverbindungen und die Datenbankserver. Auf Clientworkstations kann verschiedene Software wie Anwendungen, Treiber usw. geladen sein. Zu jedem Zeitpunkt sind viele verschiedene Kombinationen möglich.

 

Testzielsetzung: Validieren und bestätigen Sie, dass die Clientanwendungen auf den vorgegebenen Clientworkstations ordnungsgemäß funktionieren.
Verfahren:
  • Verwenden Sie die Scripts für Integrations- und Systemtests.
  • Öffnen/Schließen Sie im Rahmen des Tests oder vor Testbeginn verschiedene PC-Anwendungen.
  • Führen Sie ausgewählte Transaktionen aus, um Benutzeraktivitäten (Eingaben/Ausgaben) für die verschiedenen PC-Anwendungen zu simulieren.
  • Wiederholen Sie den obigen Prozess unter Minimierung des verfügbaren herkömmlichen Speichers auf dem Client.
Erfüllungskriterien: Die Transaktionen wurden für jede Kombination fehlerfrei ausgeführt.
Besondere Hinweise:
  • Welche PC-Anwendungen sind auf den Clients verfügbar? Auf welche dieser Anwendungen kann zugegriffen werden?
  • Welche Anwendungen werden normalerweise benutzt?
  • Welche Daten werden mit den Anwendungen bearbeitet (z. B. eine große Tabellenkalkulation in Excel oder ein hundertseitiges Dokument in Word))
  • Im Rahmen dieses Tests müssen alle Systeme, Netzserver, Datenbanken usw. dokumentiert werden.

12. Installationstests

Installationstests dienen zwei verschiedenen Zwecken. Zum einen soll sichergestellt werden, dass die Software unter normalen und anormalen Bedingungen auf jede mögliche Weise (Neuinstallation, Upgrade, vollständige oder benutzerdefinierte Installation, installiert werden kann. Anormale Bedingungen wären unzureichender Plattenspeicherplatz, fehlende Berechtigung für das Anlegen von Verzeichnissen usw. Zum anderen soll verifiziert werden, dass die Software nach der Installation fehlerfrei ausgeführt werden kann. Zu diesem Zweck müssen in der Regel mehrere Tests ausgeführt werden, die als Funktionstests entwickelt wurden.

 

Testzielsetzung: Prüfen und bestätigen, dass die Clientsoftware unter folgenden Bedingungen fehlerfrei auf jedem Client installiert werden kann:
  • Neuinstallation: neue Maschine, die noch nicht installiert wurde
  • Update: Maschine die bereits mit derselben Version installiert wurde
  • Update: Maschine die bereits mit einer älteren Version installiert wurde
Verfahren:
  • Validieren Sie manuell oder mit eigens entwickelten automatisierten Scripts den Zustand der Zielmaschine (neu und noch nie installiert, bereits mit gleicher oder älterer Version installiert).
  • Starten Sie die Installation oder führen Sie sie aus.
  • Führen Sie die Transaktionen aus. Verwenden Sie dafür eine vorab definierte Gruppe von Tests-Scripts für Integrations- oder Systemtests.
Erfüllungskriterien: Die Transaktionen können fehlerfrei ausgeführt und abgeschlossen werden.
Besondere Hinweise:
  • Welche Transaktionen sollten für einen Test ausgewählt werden, mit dem nachgewiesen werden kann, dass die Anwendung erfolgreich installiert wurde und dass keine wichtigen Softwarekomponenten fehlen?

2. Tools

Das System wird mit folgenden Tools getestet:

 

Tool

Version

Testmanagement Rational RequisitePro

Rational Unified Process

NZE
Testdesign Rational Rose NZE
Mängelerfassung Rational ClearQuest NZE
Funktionstests Rational Robot NZE
Leistungstests Rational Visual Quantify NZE
Überwachungsprogramm oder Profilerstellungsfunktion für Testabdeckung Rational Visual PureCoverage NZE
Weitere Testtools Rational Purify

Rational TestFactory

NZE
Projektmanagement Microsoft Project

Microsoft Word

Microsoft Excel

NZE
DBMS-Tools NZE NZE

6. Ressourcen

    In diesem Abschnitt sind die empfohlenen Ressourcen für die Tests des CREG-Systems mit ihren Zuständigkeiten, ihrer Qualifikation und ihrem Know-how aufgeführt.

    1. Mitarbeiter

Diese Tabelle listet die für die Testaufgaben vorausgesetzten Mitarbeiter auf.

Personal

Mitarbeiter

Empfohlene Mindestressourcen

(Anzahl der zugewiesenen Vollzeitmitarbeiter)

Spezielle Zuständigkeiten / Kommentare

Testmanager 1 - Kerry Stone Testmanagement beaufsichtigen

Zuständigkeiten:

  • Technische Leitung
  • Geeignete Ressourcen anfordern
  • Berichte an die Unternehmensleitung
Testdesigner Margaret Cox

Carol Smith

Sophie King

Testfälle identifizieren, nach Priorität einstufen und implementieren

Zuständigkeiten:

  • Testplan generieren
  • Testsuite generieren
  • Effektivität des Testaufwands bewerten
Systemtester Carol Smith

Sophie King

Adrian Harmsen

Tests ausführen

Zuständigkeiten:

  • Tests durchführen
  • Ergebnisse protokollieren
  • Wiederherstellung nach Fehlern durchführen
  • Mängel dokumentieren
Testsystemadministrator Simon Jones Verwaltung und Pflege der Testumgebung und Test-Assets sicherstellen

Zuständigkeiten:

  • Testmanagementsystem verwalten
  • Zugriff auf Testsysteme einrichten und verwalten
Datenbankadministrator/Datenbankmanager Margaret Cox Verwaltung und Pflege der Datenumgebung (Datenbank) und Daten-Assets sicherstellen

Zuständigkeiten:

  • Testdaten (Datenbank) verwalten
Designer Margaret Cox Operationen, Attribute und Zuordnungen der Testklassen identifizieren und definieren

Zuständigkeiten:

  • Testklassen identifizieren und definieren
  • Testpakete identifizieren und definieren
Implementierer Margaret Cox

Adrian Harmsen

Testklassen und Testpakete implementieren und Einheitentests für diese durchführen

Zuständigkeiten:

  • In der Testsuite implementierte Testklassen und -pakete erstellen

2. System

In der folgenden Tabelle sind die Systemressourcen für die Tests des CREG-Systems aufgeführt.

Systemressourcen

Ressource

Name / Typ / Seriennummer

Wylie-College-Server Seriennummer: X179773562b
  Kurskatalogdatenbank Version: CCDB-080885
  Gebührenabrechnungssystem Version: BSSS-88335
Clienttest-PCs
 
  10 ferne PCs (mit Internet-Zugang) Seriennummer: A8339223

Seriennummer: B9334022

Seriennummer: B9332544

<7 NZE>

  6 lokale PCs (über das LAN angeschlossen) Seriennummer: R3322411 (Registrator)

Seriennummer: A8832234 (IT-Labor)

Seriennummer: W4592233 (IT-Labor)

Seriennummer: X3333411 (Fakultätsbüro)

Seriennummer: A987344 (wissenschaftliches Labor)

Seriennummer: X9834000 (Studentengewerkschaft)

Test-Repository
 
  Wylie-College-Server Seriennummer: X179773562b
6 Testentwicklungs-PCs Seriennummer: A8888222

Seriennummer: R3322435

Seriennummer: I88323423

Seriennummer: B0980988

Seriennummer: R3333223

Seriennummer: Y7289732

Lastsimulator Seriennummer: ABC-123

 

 

7. Projektmeilensteine

    Die Testaktivitäten und Meilensteine sind stark von den Entwicklungsiterationen abhängig. Die Konstruktionsphase ist in drei Iterationen unterteilt. Zu jeder dieser Iterationen gehört ein vollständiger Testzyklus mit Planung, Design, Entwicklung, Ausführung und Bewertung.

    Schauen Sie sich den Softwareentwicklungsplan [14] und die Iterationspläne für den Master-Zeitplan sowie den Plan zur Konstruktionsphase mit den Entwicklungsiterationen an.

    In der folgenden Tabelle sind die Testmeilensteine angegeben. Aufwand, Anfangstermin und Endtermin können nachgetragen werden, wenn der Iterationsinhalt geplant wird.

    Meilensteinaufgabe Aufwand (Werktage) Anfangstermin Endtermin
    Iteration Kt1: Betaversion

    Testplanung

    Testdesign

    Testentwicklung

    Testausführung

    Testauswertung

    NZE 15. März 12. April
    Iteration Kt2: Release 1.0

    Testplanung

    Testdesign

    Testentwicklung

    Testausführung

    Testauswertung

    NZE 13. April 14. Mai
    Iteration Kt3: Release 2.0

    Testplanung

    Testdesign

    Testentwicklung

    Testausführung

    Testauswertung

    NZE 15. Mai 17. Juni

     

8. Arbeitsergebnisse

    Die Arbeitsergebnisse der in diesem Testplan definierten Testaufgaben sind in der folgenden Tabelle aufgeführt.

    Beachten Sie, dass einige dieser Arbeitsergebnisse mehrfach erzeugt werden (für jeden Testzyklus oder jede Iteration einmal). Andere Arbeitsergebnisse wie der Testplan werden in jeder Entwicklungsiteration aktualisiert.

    Arbeitsergebnisse Eigner Überprüfung / Verteilung Fälligkeitsdatum
    Testplan K. Stone Höheres Projektmanagement 28. März
    Testumgebung S. Jones - 28. März
    Testsuite C. Smith und M. Cox Interne Peer-Prüfung 28. März
    Testdatensets M. Cox Interne Peer-Prüfung 31. März
    Test-Scripts M. Cox - 2. April
    Test-Stubs, Treiber M. Cox - 4. April
    Mängelbericht C. Smith Höheres Projektmanagement NZE
    Testergebnisse C. Smith Testmanager NZE
    Testauswertungsbericht C. Smith Höheres Projektmanagement NZE

     

1. Testsuite

      Die Testsuite definiert alle Testfälle mit den zugeordneten Test-Scripts.

2. Testprotokolle

Es ist geplant, für die Identifizierung und Statusüberwachung der Testfälle RequisitePro zu verwenden. Die Testergebnisse werden in RequisitePro als 'nicht getestet', 'bestanden', 'bedingt bestanden' oder 'nicht bestanden' eingestuft. RequisitePro wird für die Unterstützung der folgenden Attribute für die einzelnen Testfälle konfiguriert. Diese Attribute sind in den Richtlinien für Anforderungsattribute [16] definiert.

    • Teststatus
    • Build-Nummer
    • Getestet von
    • Testdatum
    • Anmerkungen zum Test

Der Systemtester ist für die Aktualisierung des Teststatus in RequisitePro verantwortlich.

Die Testergebnisse werden im Rahmen der Konfigurationssteuerung gespeichert.

Für die Protokollierung und Überwachung einzelner Mängel wird Rational ClearQuest verwendet.

9. Projektaufgaben

Nachfolgend sind die Testaufgaben für das CREG-System aufgeführt:

 

Test planen

Zu testende Anforderungen festlegen

Risiko einschätzen

Teststrategie entwickeln

Testressourcen identifizieren

Zeitplan erstellen

Testplan generieren

Testdesign erstellen

Auslastungsanalyse

Testsuite entwickeln

Testfälle identifizieren und beschreiben

Test-Scripts identifizieren und strukturieren

Testabdeckung prüfen und beurteilen

Test implementieren

Testumgebung einrichten

Test-Scripts erfassen oder programmieren

Test-Stubs und Treiber entwickeln

Testspezifische Funktionalität im Design- und Implementierungsmodell identifizieren

Externe Datensets erstellen

Test durchführen

Test-Script ausführen

Testausführung bewerten

Wiederherstellung nach Testunterbrechung

Ergebnisse prüfen

Unerwartete Ergebnisse untersuchen

Mängel protokollieren

Test bewerten

Testfallabdeckung bewerten

Codeabdeckung bewerten

Mängel analysieren

Feststellen, ob die Erfüllungs- und Erfolgskriterien erfüllt wurden

Testauswertungsbericht erstellen

 

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

Webbeispiel CREG-Projekt (Course Registration)
Version 2001.03