Course Registration System

Testplan für den Architekturprototyp

Version 1.0

 

Revisionsprotokoll

DatumVersion Beschreibung Autor
7. März 1999 1.0 Erstes Release - Testplan für den Prototyp K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

Inhaltsverzeichnis

  1. Zielsetzung
  2. Zu testende Anforderungen
  3. Teststrategie
  4. Ressourcen
  5. Projektmeilensteine
  6. Arbeitsergebnisse
  7. Projektaufgaben

 

Testplan

für den

Architekturprototyp

1. Zielsetzung

1.1 Verwendungszweck

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

1.2 Geltungsbereich

Dieser Testplan beschreibt die Integrations- und Systemtests für den Architekturprototyp im Anschluss an die Integration der Subsysteme und Komponenten, die im Build-Plan für die Integration des Prototyps [16] genannt sind.

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

Der Architekturprototyp wurde erstellt, um die Realisierbarkeit und Leistung der ausgewählten Architektur zu testen. Es ist entscheidend, dass alle System- und Subsystemschnittstellen sowie die Systemleistung in dieser frühen Phase getestet werden. Tests der Systemfunktionen und -features werden nicht am Prototyp durchgeführt.

Es werden die Schnittstellen zwischen den folgenden Subsystemen getestet:

    1. Kursregistrierung
    2. Finanzsystem
    3. Kurskatalogsystem

Es werden die externen Schnittstellen zu folgenden Einheiten getestet:

    1. Lokale PCs
    2. Ferne PCs

Die wichtigsten zu testenden Leistungsmessgrößen sind:

    1. Antwortzeit beim Fernanmeldung beim Kursregistrierungssystem
    2. Antwortzeit beim Zugriff auf das Finanzsystem
    3. Antwortzeit beim Zugriff auf das Kurskatalogsubsystem
    4. Antwortzeit für Studenten, wenn sich 200 Studenten beim System angemeldet haben
    5. Antwortzeit für Studenten bei 50 gleichzeitigen Zugriffen auf die Kurskatalogdatenbank
1.3Referenzen

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, Softwareentwicklungsplan (WyIT418) Version 1.0, 1999, Wylie College IT
    14. Course Registration System, Iterationsplan, Ausarbeitungsiteration A1 (WyIT420) Version 1.0, 1999, Wylie College IT
    15. Course Registration System, Softwarearchitekturdokument (WyIT431) Version 1.0, 1999, Wylie College IT
    16. Course Registration System, Build-Erstellungsplan zur Integration für den Architekturprototyp (WyIT430) Version 1.0, 1999, Wylie College IT
    17. Course Registration System, Richtlinien für Anforderungsattribute (WyIT404) Version 1.0, 1999, Wylie College IT
2.    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.

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

    2.1 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

    2.2. Funktionstests

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

    2.3 Geschäftszyklen testen

    Keine Tests

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

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

    2.6 Belastungstests

    Systemantwort bei 200 angemeldeten Studenten überprüfen

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

    2.7 Stresstests

    Keine Tests

    2.8 Volumentests

    Keine Tests

    2.9 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

    2.10 Funktionsübernahme und Wiederherstellung testen

    Keine Tests

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

    2.12 Installationstests

    Keine Tests

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

3.1 Testarten

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

 

 

3.1.2 Funktionstests

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:
  • Für die Ausführung einiger Systemtests für den Prototyp ist der Zugriff auf den UNIX-Server des Wylie College mit dem vorhandenen Kurskatalogsystem und Gebührenabrechnungssystem erforderlich.
 

3.1.3 Geschäftszyklen testen

Dieser Abschnitt gilt nicht für Tests des Architekturprototyps.

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

3.1.5 Leistungsprofil erstellen

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.

 

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

3.1.7 Stresstests

Dieser Abschnitt gilt nicht für Tests des Architekturprototyps.

3.1.8 Volumentests

Dieser Abschnitt gilt nicht für Tests des Architekturprototyps.

3.1.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 des Remote-Zugriffs 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.
 

3.1.10 Funktionsübernahme und Wiederherstellung testen

Dieser Abschnitt gilt nicht für Tests des Architekturprototyps.

3.1.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 mit jeweils unterschiedlicher Ressourcennutzung 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 aus Prototyp und PC-Anwendung 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.

 

3.1.12 Installationstests

Dieser Abschnitt gilt nicht für Tests des Architekturprototyps für CREG.

3.2 Tools

Der Architekturprototyp 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
 

4.    Ressourcen

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

4.1 Rollen

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

 

Personal

Rolle 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

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

Zuständigkeiten:

  • Testplan generieren
  • Testsuite generieren
  • Effektivität des Testaufwands bewerten
Systemtester Carol Smith 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 Testklassen und Testpakete implementieren und Einheitentests für diese durchführen

Zuständigkeiten:

  • In der Testsuite implementierte Testklassen und -pakete erstellen
 

4.2 System

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

Systemressourcen

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

Seriennummer: B9334022

Seriennummer: B9332544

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

Seriennummer: A8832234 (IT-Labor)

Seriennummer: W4592233 (IT-Labor)

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

Seriennummer: R3322435

Seriennummer: I88323423

Seriennummer: B0980988

Seriennummer: R3333223

Seriennummer: Y7289732

 

 

 5.    Projektmeilensteine

    Die Tests für den CREG-Architekturprototyp umfassen Aufgaben für jeden der vorgenannten Bereiche. Es werden separate Projektmeilensteine benannt, um den Projektstatus und den Erfüllungsstatus zu vermitteln.

    Informationen zur gesamten Phase bzw. zum Master-Zeitplan für das Projekt sind im Softwareentwicklungsplan [13] und im Iterationsplan für A1 [14] enthalten.

    Meilensteinaufgabe Aufwand (Werktage) Anfangstermin Endtermin
    Prototyptest planen 2 12. März 15. März
    Design für Prototyptest erstellen 3 15. März 18. März
    Prototyptest entwickeln 4 19. März 23. März
    Prototyptest durchführen 3 24. März 26. März
    Prototyptest bewerten 1 29. März 29. März

     

6.    Arbeitsergebnisses

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

    Arbeitsergebnisse Eigner Überprüfung / Verteilung Fälligkeitsdatum
    Testplan K. Stone Höheres Projektmanagement 15. März
    Testumgebung S. Jones - 18. März
    Testsuite C. Smith und M. Cox Interne Peer-Prüfung 23. März
    Testdatensets M. Cox Interne Peer-Prüfung 23. März
    Test-Scripts M. Cox - 23. März
    Test-Stubs, Treiber M. Cox - 23. März
    Mängelbericht C. Smith Höheres Projektmanagement 26. März
    Testergebnisse C. Smith - 26. März
    Testauswertungsbericht C. Smith Höheres Projektmanagement 29. März

6.1 Testsuite

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

6.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 [17] definiert.

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

Die Testergebnisse werden im Rahmen der Konfigurationssteuerung gespeichert.

6.3 Mängelberichte

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

7.    Projektaufgaben

Nachfolgend sind die Testaufgaben für den CREG-Architekturprototyp aufgeführt:

Test planen

Zu testende Anforderungen festlegen

Risiko einschätzen

Teststrategie entwickeln

Testressourcen identifizieren

Zeitplan erstellen

Testplan generieren

Testdesign erstellen

Auslastungsanalyse (für den Prototyp nicht zutreffend)

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