Geeignete Testsuites überprüfen
Zweck:
|
Testsuites verstehen und die zu implementierenden Testsuites auswählen
|
Beginnen Sie mit der Überprüfung aller vorhandenen Testsuite-Vorlagen und bestimmen Sie, welche Testsuites sich zum
derzeitigen Zeitpunkt für die Implementierung eignen. Verwenden Sie den Iterationstestplan, die Liste mit Testideen und
alle weiteren Arbeitsergebnisse für die Testdefinition, um Ihre Entscheidung zu treffen.
|
Zusammengehörige Tests und Zieltestelemente untersuchen
Zweck:
|
Die Beziehungen zwischen den geplanten Tests und den Zieltestelementen verstehen.
|
Geben Sie für jede Testsuite, die Sie für die Implementierung ausgewählt haben, die Zieltestelemente und zugehörigen
Tests an, die sich für die Aufnahme in die Testsuite eignen.
|
Testabhängigkeiten identifizieren
Zweck:
|
Alle Abhängigkeiten der Tests von anderen Tests und im Allgemeinen vom Systemzustand identifizieren
|
Schauen Sie sich zunächst die Konfiguration der Testumgebung an und den Anfangszustand des Systems an. Machen Sie sich
Gedanken darüber, wie die speziellen Konfigurationsanforderungen sein werden, z. B. Anfangsdaten für abhängige
Datenbanken. Wenn eine Zielumgebungskonfiguration für mehrere Testsuites verwendet wird, stellen Sie alle
Konfigurationseinstellungen zusammen, die für jede Testsuite verwaltet werden müssen, z. B. Bildschirmauflösung der
Videoanzeigen oder Ländereinstellungen für das Betriebssystem.
Bestimmen Sie jetzt alle speziellen Beziehungen zwischen den Tests. Suchen Sie nach Abhängigkeiten, bei denen die
Ausführung eines Tests in der Testsuite zu einer Änderung des Systemzustands führt, der eine Vorbedingung eines eines
anderen Tests ist.
Nachdem Sie die relevanten Abhängigkeiten identifiziert haben, bestimmen Sie den genauen Ablauf für die Ausführung der
abhängigen Tests.
|
Möglichkeiten für Wiederverwendung identifizieren
Zweck:
|
Wartungsfreundlichkeit der Testsuite durch Wiederverwendung vorhandener Assets und Konsolidierung neuer
Assets verbessern
|
Eine der primären Herausforderungen bei der Verwaltung Testsuite, insbesondere einer automatisierten, ist es
sicherzustellen, dass fortlaufende Änderungen einfach integriert werden können. Sofern möglich, empfiehlt es sich, eine
zentrale Änderungsstelle für die Elemente einzurichten, die in mehreren Tests verwendet werden. Die gilt insbesondere
dann, wenn zu erwarten ist, dass sich diese Elemente ändern.
Während die Tests selbst natürliche Einheiten der Modularität bilden, werden bei der Zusammenstellung der Tests in
einer Testsuite häufig doppelt vorhandene Prozedurelemente in mehreren Tests gefunden, die effizienter verwaltet werden
könnten, wenn sie konsolidiert wären. Ergreifen Sie die Gelegenheit und identifizieren Sie alle allgemeinen Mechanismen
der Tests, die potenziell in eine Standardroutine ausgelagert werden und somit zu einer einfacheren Verwaltung
beitragen könnten.
|
Erforderliche Dienstprogramme für Infrastruktur anwenden
Zweck:
|
Auslagerung komplexer Implementierungsdetails, die zur Unterstützung der Tests erforderlich sind, in
vereinfachte Dienstprogrammfunktionen
|
Für die meisten Tests müssen ein oder mehrere "Dienstprogramme" eingesetzt werden, die Informationen generieren,
erfassen, diagnostizieren, konvertieren und vergleichen, die während der Testausführung verwendet werden. Diese
Dienstprogramme vereinfachen normalerweise komplexe und arbeitsintensive Aufgaben, die fehleranfällig sind, wenn sie
manuell ausgeführt werden. Dieser Schritt steht mit der Anwendung vorhandener Dienstprogrammfunktionen in der Testsuite
und der Identifizierung neuer, erforderlicher Dienstprogramme in Zusammenhang.
Es empfiehlt sich, die Schnittstellen zu diesen Dienstprogrammen zu vereinfachen und so viel Komplexität wie möglich in
der privaten Implementierung des Dienstprogramms zu kapseln. Außerdem ist es eine gute Idee, das Dienstprogramm so zu
entwickeln, dass es bei Bedarf für manuelle und automatisierte Tests wiederverwendet werden kann.
Es wird davon abgeraten, Informationen, die einen einzelnen Test charakterisieren, in diesen Dienstprogrammen zu
verstecken. Stattdessen sollten Sie das Dienstprogramm auf komplexe Verfahren zum Erfassen von Informationen oder zum
Vergleichen echter Werte mit erwarteten Ergebnissen usw. beschränken. Sie sollten spezifische Informationen jedes
einzelnen Tests jedoch, sofern möglich, als Eingabe eines steuernden Tests (bzw. Testsuite) übergeben und die einzelnen
tatsächlichen Ergebnisse als Ausgabe an einen steuernden Test (bzw. Testsuite) zurückgeben.
|
Recovery-Anforderungen bestimmen
Zweck:
|
Recovery von Testsuites ohne vollständige Neuausführung der gesamten Testsuite ermöglichen
|
Bestimmen Sie die Punkte innerhalb der Testsuite, an denen ein Recovery möglich ist, falls die Testsuite während der
Ausführung scheitert. Dieser Schritt gewinnt an Bedeutung, wenn die Testsuite eine große Anzahl von Tests enthält oder
für längere Zeit, häufig unbeaufsichtigt ausgeführt wird. Obwohl dieser Punkt häufig als Anforderung für automatisierte
Testsuites angeführt wird, macht auch die Berücksichtigung von Recovery-Punkten für manuell ausgeführte Testsuites
Sinn.
Zusätzlich zu Recovery- bzw. Wiederanlaufpunkten sollten Sie bei automatisierten Testsuites über eine automatisierte
Testsuite-Recovery nachdenken. Zwei Ansätze für automatische Recovery sind 1) eine Basis-Recovery, wo die vorhandene
Testsuite nach einem geringfügigen Fehler in einem ihrer Tests alleine wieder anlaufen kann (normalerweise bei der
Ausführung des nächsten Tests in der Suite), und 2) eine fortgeschrittene Recovery, bei der nach dem gescheiterten Test
eine Bereinigung durchgeführt wird und der Systemzustand zurückgesetzt wird (einschließlich Warmstart des Systems und
Datenwiederherstellung, sofern erforderlich). Wie beim ersten Ansatz ermittelt die Testsuite anschließend, welcher Test
gescheitert ist, und wählt den nächsten auszuführenden Test aus.
|
Recovery-Anforderungen implementieren
Zweck:
|
Recovery-Prozess implementieren und prüfen, ob er wie erwartet funktioniert
|
Je nach Spezialisierungsgrad ist mit der Implementierung und Stabilisierung des Recovery-Prozesses ein erheblicher
Aufwand verbunden. Sie müssen Zeit einplanen, um eine Reihe wahrscheinlicher (und weniger wahrscheinlicher) Fehler zu
simulieren, um sicherzustellen, dass der Recovery-Prozess funktioniert.
Bei einer automatisierten Recovery haben beide im vorherigen Schritt genannten Ansätze ihre Stärken und Schwächen.
Überdenken Sie die Kosten einer fortgeschrittenen automatisierten Recovery sowohl im Hinblick auf die anfängliche
Entwicklung als auch in Bezug auf die laufenden Pflegearbeiten. Manchmal reicht eine manuelle Recovery durchaus aus.
|
Testsuite stabilisieren
Zweck:
|
Abhängigkeitsprobleme in Bezug auf Systemzustand und Ablauf der Testausführung lösen
|
Sie müssen sich für die Stabilisierung Ihrer Testsuite Zeit nehmen und mindestens eine Testausführung durchspielen. Die
Schwierigkeit, die Testsuite zu stabilisieren, nimmt proportional mit der Komplexität der Testsuite und einer extrem
engen Koppelung zwischen nicht zusammengehören Tests sowie einer geringen Kohäsion zwischen zusammengehörigen Tests zu.
Es können Fehler auftreten, wenn Tests zusammen in einer Testsuite ausgeführt werden, die nicht auftreten, wenn die
einzelnen Tests unabhängig voneinander ausgeführt werden. Solche Fehler sind häufig am schwierigsten zu ermitteln und
zu diagnostizieren, insbesondere wenn sie mitten in einer langwierigen automatisierten Testausführung auftreten. Sofern
dies möglich ist, sollten Sie die Testsuite regelmäßig ausführen, wenn Sie weitere Tests hinzufügen. Damit können Sie
Tests, die die Fehler hervorrufen, auf eine kleine Gruppe einschränken.
|
Rückverfolgbarkeitsbeziehungen verwalten
Zweck:
|
Wirkungsanalyse und Untersuchungsberichte für die verfolgten Elemente erstellen
|
Aktualisieren Sie unter Verwendung der Rückverfolgbarkeitsanforderungen, die im Testplan festgehalten sind, die
Rückverfolgbarkeitsbeziehungen. Testsuites können zu definierten Testfällen und Testideen zurückverfolgt werden.
Optional können sie auch zu Anwendungsfällen, Softwarespezifikationselementen, Implementierungsmodellelementen und
einem oder mehreren Messungen zur Testabdeckung zurückverfolgt werden.
|
Ergebnisse auswerten und prüfen
Zweck:
|
Sicherstellen, dass die Aufgabe angemessen ausgeführt wurde und dass die erzeugten Arbeitsergebnisse
akzeptabel sind
|
Wenn Sie Ihre Arbeit beendet haben, kann es vorteilhaft sein zu prüfen, ob diese Arbeit hinreichend nutzbringend oder
eine reine Papierverschwendung war. Sie sollten bewerten, ob die Qualität Ihrer Arbeit angemessen ist und ob der Umfang
der Arbeit ausreicht, um eine Hilfestellung für die Teammitglieder zu bieten, die sie als Arbeitsvorgabe verwenden
sollen. Verwenden Sie nach Möglichkeit die RUP-Prüflisten, um zu überprüfen, ob Qualität und Vollständigkeit "gut
genug" sind.
Legen Sie den Personen, die nachgeordnete Aufgaben ausführen müssen und auf Ihre Arbeitsvorgaben angewiesen sind, einen
Zwischenstand Ihrer Arbeiten zur Prüfung vor. Wählen Sie dafür einen Zeitpunkt, der eine Einbeziehung von
Änderungswünschen oder die Berücksichtigung von Problemstellungen zulässt. Bewerten Sie Ihre Arbeit auch anhand der
Arbeitsergebnisse, die für Sie die wichtigsten Vorgaben waren, um sicherzugehen, dass Sie diese präzise und ausreichend
dargestellt haben. Vielleicht lassen Sie Ihre Arbeit ja dahingehend von Autor dieser Arbeitsergebnisse prüfen.
Vergessen Sie nicht, dass RUP ein iterativer Bereitstellungsprozess ist und dass sich in vielen Fällen
Arbeitsergebnisse über einen längeren Zeitraum entwickeln. Es ist daher in der Regel nicht nötig und manchmal sogar
kontraproduktiv, ein Arbeitsergebnis, das für die unmittelbar folgenden Arbeiten nur teilweise oder gar nicht benötigt
wird, bereits vollständig und abschließend zu definieren. Es ist sehr wahrscheinlich, dass sich die umgebende Situation
für das Arbeitsergebnis noch ändern wird und dass sich die bei Erzeugung des Arbeitsergebnisses gültigen Annahmen als
fehlerhaft erweisen, so dass eine abschließende Gestaltung des Arbeitsergebnisses einen unnötigen Arbeitsaufwand und
teures Nacharbeiten bedeuten würde. Sie sollten auch nicht zu viel Zeit auf die Darstellung verwenden, sondern sich
eher auf den Inhalt konzentrieren. In Projektumgebungen, bei denen die Präsentation wichtig ist und als
Projektliefergegenstand einen wirtschaftlichen Wert hat, könnten Sie für die Darstellungsaufgaben eine administrative
Ressource nutzen.
|
|