Course Registration System
Testplan für den Architekturprototyp
Version 1.0
Revisionsprotokoll
Datum | Version | Beschreibung | Autor |
---|---|---|---|
7. März 1999 | 1.0 | Erstes Release - Testplan für den Prototyp | K. Stone |
|
|
|
|
|
|
|
|
|
|
|
|
Inhaltsverzeichnis
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:
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:
Es werden die externen Schnittstellen zu folgenden Einheiten getestet:
Die wichtigsten zu testenden Leistungsmessgrößen sind:
Verfügbare Referenzen:
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
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 Testarten3.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: |
|
Erfüllungskriterien: | Alle Methoden und Prozesse für den Datenbankzugriff funktionieren wie vorgesehen und ohne fehlerhafte Daten. |
Besondere Hinweise: |
|
3.1.2 FunktionstestsBei 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: |
|
Erfüllungskriterien: |
|
Besondere Hinweise: |
|
3.1.3 Geschäftszyklen testen
3.1.4 Benutzerschnittstelle testenDieser Abschnitt gilt nicht für Tests des Architekturprototyps.
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:
|
Verfahren: |
|
Erfüllungskriterien: | Für jedes Fenster wurde nachgewiesen, dass es der Benchmark-Version entspricht oder innerhalb der Norm liegt. |
Besondere Hinweise: |
|
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: |
|
Erfüllungskriterien: |
|
Besondere Hinweise: |
|
3.1.6 BelastungstestsBei 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: |
|
Erfüllungskriterien: |
|
Besondere Hinweise: |
|
3.1.7 Stresstests
3.1.8 VolumentestsDieser Abschnitt gilt nicht für Tests des Architekturprototyps.
3.1.9 Sicherheit und Zugriffssteuerung testenDieser Abschnitt gilt nicht für Tests des Architekturprototyps.
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 SystemAusgehend 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: |
|
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: |
|
3.1.10 Funktionsübernahme und Wiederherstellung testen
3.1.11 KonfigurationstestsDieser Abschnitt gilt nicht für Tests des Architekturprototyps.
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: |
|
Erfüllungskriterien: | Die Transaktionen wurden für jede Kombination aus Prototyp und PC-Anwendung fehlerfrei ausgeführt. |
Besondere Hinweise: |
|
3.1.12 Installationstests3.2 ToolsDieser Abschnitt gilt nicht für Tests des Architekturprototyps für CREG.
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 RollenDiese 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:
|
Testdesigner | Margaret Cox
Carol Smith |
Testfälle identifizieren, nach Priorität einstufen und implementieren
Zuständigkeiten:
|
Systemtester | Carol Smith | Tests ausführen
Zuständigkeiten:
|
Testsystemadministrator | Simon Jones | Verwaltung und Pflege der Testumgebung und Test-Assets sicherstellen
Zuständigkeiten:
|
Datenbankadministrator/Datenbankmanager | Margaret Cox | Verwaltung und Pflege der Datenumgebung (Datenbank) und Daten-Assets sicherstellen
Zuständigkeiten:
|
Designer | Margaret Cox | Operationen, Attribute und Zuordnungen der Testklassen identifizieren und definieren
Zuständigkeiten:
|
Implementierer | Margaret Cox | Testklassen und Testpakete implementieren und Einheitentests für diese durchführen
Zuständigkeiten:
|
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 |
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 |
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 TestsuiteDie Testsuite definiert alle Testfälle mit den zugeordneten Test-Scripts.
6.2 TestprotokolleEs 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.
- Teststatus
- Build-Nummer
- Getestet von
- Testdatum
- Anmerkungen zum Test
7. ProjektaufgabenDer Systemtester ist für die Aktualisierung des Teststatus in RequisitePro verantwortlich.
Die Testergebnisse werden im Rahmen der Konfigurationssteuerung gespeichert.
6.3 MängelberichteFür die Protokollierung und Überwachung einzelner Mängel wird Rational ClearQuest verwendet.
Nachfolgend sind die Testaufgaben für den CREG-Architekturprototyp aufgeführt:
Test planen |
|
|
|
|
|
|
Testdesign erstellen |
|
|
|
|
|
Test implementieren |
|
|
|
|
|
Test durchführen |
|
|
|
|
|
|
Test bewerten |
|
|
|
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) |