Ein Testplan für den verteilten Kalender - 3 Objektorientierte Testplanung

3 Objektorientierte Testplanung

3.6 Ein Testplan für den verteilten Kalender

Wer mit dem herkömmlichen Testansatz planlos vorgeht, ist zum Scheitern verur-teilt. Die Messlatte der erforderlichen Professionalität ist um einige Intervalle höher gesetzt [MgKo94].

3.6 Ein Testplan für den verteilten Kalender

Als Beispiel für die Testplanung dient ein Projekt zur Entwicklung eines verteilten Kalenders. Jeder Mitarbeiter soll einen persönlichen Kalender auf seinem Rechner-Arbeitsplatz haben, um seine Tagesaktivitäten einzutragen. Jede Tagesaktivität soll eine Startzeit, eine Endzeit, einen Typ und eine Beschreibung haben. Die Anzahl der Aktivitäten sind auf 12 pro Tag begrenzt. Aktivitäten, die projektbezogen sind, werden gegen die entsprechenden Projekte gebucht. Dazu ist ein gemeinsames Projektkennzeichen erforderlich. Allerdings gehören die Projekte zu einem anderen System und werden auf einem anderen Rechner verwaltet. Es kommt darauf an, die Anzahl der geleisteten Stunden bei den Projekten sowie bei den Mitarbeitern zu akkumulieren.

Für den Mitarbeiter sind die Aktivitäten Tagen und die Tage Wochen zugeordnet.

Ein Jahreskalender hat bis zu 52 Wochen, eine Woche hat bis zu 7 Tage und ein Tag bis zu 12 Aktivitäten. Tage unterscheiden sich nach Arbeitstagen und Feierta-gen. Für die Arbeitstage gilt der Normaltarif, für Feiertage gilt ein Sondertarif.

Die Wochenkalender werden zwar an dem Arbeitsplatzrechner bearbeitet, jedoch an einem zentralen Server gehalten (Abbildung 3.12). Dort sollten sie in einer relatio-nalen Datenbank gespeichert sein. Hier hat auch das Management den Zugriff auf sie, um zu verfolgen, was die Mitarbeiter so machen.

Es ist entschieden worden, das System mit UML zu konzipieren, die Programme mit C++ zu realisieren, die Kalenderdaten mit ORACLE-8 zu speichern und die Aktivitäten mit den Projekten über eine Visibroker CORBA-Schnittstelle zu ver-binden.

Der Testmanager wird beauftragt, einen Testplan auszuarbeiten. Das Ergebnis sei-ner Arbeit könnte so aussehen, wie es in den folgenden Abschnitten gezeigt ist.

Kalender-Testprojektidentifikation

Das Kalendertestprojekt trägt den Titel Kalendertest und wird im Verzeichnis

X: Kalender\Test

geführt.

Projekt-oberfläche

Kalender-oberfläche

Kalender-bearbeitung

CORBA CORBA Client

Projekt-objekte

Kalenderverwaltung Projektverwaltung

Kalender-objekte

Projekt-bearbeitung

Abbildung 3.12 Kalendersystemarchitektur

Kalender-Testprojektbeschreibung Das Kalendertestprojekt soll den Beweis liefern, dass

• Mitarbeiterkalender in einer verteilten Umgebung fehlerfrei erstellt und fortge-schrieben werden können;

• Mitarbeiterstunden korrekt akkumuliert werden, sowohl bei den Mitarbeitern selbst als auch bei den Projekten, gegen welche die Stunden gebucht werden, und

• Kalender bei Systemabbrüchen und Netzausfällen gerettet werden.

Das Testprojekt läuft unter der Leitung des Testmanagers, der für den Integrations-test allein verantwortlich ist. Für die Dauer des SystemIntegrations-tests wird ein stellvertreten-der Endanwenstellvertreten-der zum Testprojekt abgestellt. Für den Modultest sind die Entwick-ler zuständig. Ihre Ergebnisse müssen jedoch vom Testmanager abgenommen wer-den.

Das Testprojekt soll in 7 Phasen parallel zum Entwicklungsprojekt ablaufen:

• Testkonzepterstellung,

• Testfallspezifikation,

• Testumgebungsaufbau,

• Klassentest,

• Integrationstest,

• Systemtest und

3.6 Ein Testplan für den verteilten Kalender __________________________________77

• Systemabnahme.

Kalender-Testgegenstände Es sind folgende Objekte zu testen Klassen:

• Kalender

• Zeitraum

• Wochen

• Tag

• Aktivität

• Mitarbeiter

• Projekt Schnittstellen:

• Mitarbeiter zu Kalender

• Aktivität zu Projekt

• Mitarbeiter zu Projekt Systeme:

• Kalenderführung

• Projektsteuerung Anwendungsfälle:

• Mitarbeiter anlegen

• Kalender anlegen

• Wochen anlegen

• Tage anlegen

• Aktivitäten anlegen

• Aktivitäten ändern

• Aktivitäten löschen

• Kalender löschen

Kalender-Testziele

Funktionale Testziele für den verteilten Kalender sind:

• Verifikation aller Klassenfunktionen

• Erzeugung aller Objektarten

• Erprobung aller Schnittstellen

• Auslösung aller Plausibilitätsprüfungen

• Bestätigung aller Anwendungsfälle mit mindestens zwei Varianten Nichtfunktionale Testziele sind:

• Messung der Zeit für die Übertragung der Kalenderobjekte auf den Clientrech-ner

• Messung der Zeit für die Abspeicherung der Kalenderobjekte auf dem Server-rechner

• Validation der Systemwiederanlaufsfähigkeit

• Validation der Datenbanksicherheit

Kalender-Testeinschränkungen

Es stehen maximal zwei Client-Arbeitsplätze zur Verfügung.

Der Projektserver steht für Testzwecke nur abends ab 18.00 Uhr zur Verfügung.

Das Datenbanksystem wird erst zum Integrationstest installiert.

Nur ein Anwender kann für höchstens eine Woche am Systemtest beteiligt sein.

Die Testgruppe darf nicht länger als einen Monat mit dem Test des Kalendersys-tems belastet sein.

Es dürfen nur die folgenden Testwerkzeuge eingesetzt werden:

• CPPANAL,

• CPPTEST,

• CPPINST,

• IDLTEST und

• WinRunner

Kalender-Teststrategie Die Teststrategien sind:

• Klassentest: Built-In-Strategie

• Integrationstest: Top-Down-Strategie

• Systemtest: Anwendungsfallstrategie

Diese Strategien werden im Testkonzept näher erläutert.

3.6 Ein Testplan für den verteilten Kalender __________________________________79

Kalender-Testendekriterien Die Mindesttestendekriterien sind:

• Klassentest: einmalige Erzeugung aller Objektarten und die Ausführung aller Operationen

• Integrationstest: Austausch zweier Nachrichten – einer korrekten und einer unkorrekten – zwischen den Kalendersystemen und dem Mitarbeiter sowie zwi-schen dem Kalendersystem und dem Projektsystem

• Systemtest: Test jedes spezifizierten Anwendungsfalls und jeder spezifizierten Fehlermeldung

Die endgültigen Testendekriterien werden im Testkonzept vereinbart.

Regressionstestkriterien für den verteilten Kalender

Da der Built-In-Test der Klassen im Klassensource bleiben soll, wird er immer wiederholbar sein. Der Entwickler muss allerdings die Zusicherungen den Codeän-derungen anpassen.

Der Integrationstest wird über die CORBA-Schnittstelle wiederholbar sein, weil die IDL-Definition vom IDLTEST-Schnittstellentreiber interpretiert wird. Dennoch muss auch hier der Tester die Vor- und Nachbedingungen den Schnittstellenände-rungen anpassen.

Der Systemtest wird das erste Mal an der Benutzungsoberfläche von WinRunner aufgezeichnet und alle weiteren Male von WinRunner zurückgespielt. Bei Ände-rungen in der Oberfläche muss das Testskript angepasst werden.

Kalender-Testergebnisse

Das Kalendertestprojekt hat folgende Ergebnisse zu liefern:

• Testkonzept

• Klassentestfälle

• Integrationstestfälle

• Systemtestfälle

• Testobjektverzeichnis

• Klassentestprotokoll

• Schnittstellenprotokoll

• Testüberdeckungsprotokoll

• Datenbankprotokoll

• Oberflächenprotokoll

• Mängelberichte

• Testvorfallsbericht

• Testabschlussbericht

Das Format der Ergebnisse ist in der betrieblichen Testrichtlinie vorgegeben.

Kalender-Testaufgaben

Vor dem Test des verteilten Kalenders sind folgende Aufgaben wahrzunehmen:

• Testanforderungen ermitteln

• Testansatz festlegen

• Testszenarien ausarbeiten

• Testendekriterien setzen

• Testkonzept verfassen

• Testfälle spezifizieren

• Testwerkzeuge bereitstellen

• Testumgebung aufbauen

• Testdatenbank installieren

Im Test des verteilten Kalenders sind folgende Aufgaben wahrzunehmen:

• Objektmodell verifizieren

• Klassen statisch analysieren

• Klassen dynamisch analysieren

• Klassen abnehmen

• Komponenten testen

• Komponentenschnittstellen testen

• Komponenten abnehmen

• Oberfläche testen

• Datenbank testen

• Gesamtsystem testen

• Gesamtsystem abnehmen

Nach jedem Test des verteilten Kalenders sind folgende Aufgaben wahrzunehmen:

• Testprotokolle auswerten

• Testüberdeckung messen

• Testergebnisse validieren

• Mängelberichte erfassen

• Testbericht schreiben

3.6 Ein Testplan für den verteilten Kalender __________________________________81

Kalender-Testumgebungsanforderungen

Um das verteilte Kalendersystem zu testen, ist als Hardware erforderlich

• mindestens zwei PC-Arbeitsplätze

• ein Server für die Kalender

• ein zweiter Server für die Projekte

• ein LAN-Netz

Folgende Software ist erforderlich:

• ein CORBA-Konformer ORB

• eine relationale Datenbank

• eine Netzsoftware

• ein C++-Compiler

• ein C++-statischer-Analysator

• ein C++-dynamischer-Analysator

• ein CORBA-Schnittstellengenerator

• ein Capture/Replay-System

• ein Datenbankvalidator

• Mängelberichte erfassen

→

Entwickler, Testgruppe, Benutzervertreter, Testmanager

• Testbericht schreiben

→

Testmanager

Kalender-Testzeitplan

Das Testkonzept ist zeitgleich mit dem Klassenmodell abzuschließen.

Die Spezifikation der Testfälle und die Vorbereitung des Tests sollten bis zur Fer-tigstellung der ersten Klassen abgeschlossen sein.

Der Klassentest soll unmittelbar auf die Kodierung der Klassen folgen und maximal zwei Wochen dauern.

Der Integrationstest folgt auf den Klassentest und dauert ebenfalls maximal zwei Wochen.

Der Systemtest folgt dem Integrationstest und dauert bis zu einem Monat.

Nach Abschluss der Klassenkodierung sollte die Zeitdauer bis zur Systemabnahme nicht länger als die Zeitdauer bis zu diesem Zeitpunkt sein, d.h. der Beginn des Klassentests markiert die Mitte des Projekts, was Kalenderzeit und Personalauf-wand anbetrifft.

3.6 Ein Testplan für den verteilten Kalender __________________________________83

Kalender-Testrisiken und Notpläne

Es könnte sein, dass die Zeit für die Spezifikation aller notwendigen Testfälle nicht ausreicht. In diesem Falle sind extreme Testfälle und Ausnahmefälle wegzulassen.

Es könnte auch sein, dass die ORB-Verbindung zwischen den Kalendern und den Projekten nicht rechtzeitig realisiert wird. In diesem Fall wird eine Batchschnittstel-lendatei mit den projektbezogenen Aktivitäten erzeugt.

Es könnte schließlich vorkommen, dass das Testwerkzeug IDLTEST für den Test der Interaktionen zwischen verteilten Komponenten nicht so funktioniert, wie er-wartet. In diesem Falle ist der Integrationstest zu überspringen und direkt vom Klassentest in den Systemtest zu gehen.

Kalendertestgenehmigung

Dieser Testplan wird vom Projektleiter, dem Leiter der Anwendungsentwicklung und dem Leiter der zuständigen Fachabteilung genehmigt. Mit ihrer Unterschrift übernehmen sie die Verantwortung für das Testprojekt zusammen mit dem Testma-nager, der den Testplan verfasst hat.

4

Objektorientierter

Im Dokument Das Praxishandbuch für den Test (Seite 89-99)