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
- Zielsetzung
- Inhalt und Umfang
- Referenzen
- Zu testende Anforderungen
- Teststrategie
- Testarten
- Daten- und Datenbankintegrität testen
- Systemtests
- Geschäftszyklen testen
- Benutzerschnittstelle testen
- Leistungstests
- Belastungstests
- Stresstests
- Volumentests
- Sicherheit und Zugriffssteuerung testen
- Funktionsübernahme/Wiederherstellung testen
- Konfigurationstests
- Installationstests
- Tools
- Ressourcen
- Mitarbeiter
- System
- Projektmeilensteine
- Arbeitsergebnisse
- Testsuite
- Testprotokolle
- Mängelberichte
- 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:
- Spezifikation der Abrechnungsschnittstelle für Kursgebühren WC93332, 1985, Wylie College Press
- Spezifikation der Kurskatalogdatenbank WC93422, 1985, Wylie College Press
- Course Registration System, Visionsdokument (WyIT387) Version 1.0, 1998, Wylie College IT
- Course Registration System, Glossar (WyIT406) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Registrierung abschließen' (WyIT403) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Anmeldung' (WyIT401) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Dozenteninformationen verwalten' (WyIT407) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Registrierung für Kurse' (WyIT402) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Zu haltende Kurse auswählen' (WyIT405) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Studenteninformationen verwalten' (WyIT408) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Noten erfassen' (WyIT409) Version 2.0, 1999, Wylie College IT
- Course Registration System, Spezifikation für den Anwendungsfall 'Zeugnis anzeigen' (WyIT410) Version 2.0, 1999, Wylie College IT
- Course Registration System, Ergänzende Spezifikation (WyIT400) Version 1.0, 1999, Wylie College IT
- Course Registration System, Softwareentwicklungsplan (WyIT418) Version 2.0, 1999, Wylie College IT
- Course Registration System, Softwarearchitekturdokument (WyIT431) Version 1.0, 1999, Wylie College IT
- Course Registration System, Richtlinien für Anforderungsattribute (WyIT404) Version 1.0, 1999, Wylie College IT
- 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.
- 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.
-
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
|
|