Für jedes erforderliche Zieltestelement Beziehungen mit Testmechanismen identifizieren
Zweck:
|
Verstehen, welche Unterstützung durch Testmechanismen die Zieltestelemente benötigen.
|
Überprüfen Sie für jedes Zieltestelement die Liste der Testmechanismen und identifizieren Sie diejenigen, die
Unterstützung bereitstellen können. Stellen Sie per Analyse fest, in welchem Maße die ausgewählten Testmechanismen eine
vollständige Testlösung bereitstellen und wie sie verbessert werden können. Wenn Sie keine geeigneten Mechanismen
finden können oder der Anpassungsaufwand erheblich ist, definieren Sie neue Testmechanismen und versuchen Sie, einen
Ausgleich zwischen Genauigkeit und Wiederverwendbarkeit zu finden.
|
Dynamische Elemente und Ereignisse des Systeme identifizieren
Zweck:
|
Dynamische und Laufzeitaspekte des Systems verstehen.
|
Identifizieren Sie die dynamischen Elemente und Ereignisse des Systems mit den verfügbaren Softwareanforderungen und
Designinformationen. Mit dem Anwendungsfallmodell, dem Designmodell, dem Implementierungsmodell und dem
Deployment-Modell können Sie relevante Elemente, wie z. B. Steuerungsklassen, Prozesse, Threads und Ereignisse,
identifizieren. Die Punkte, an denen Sie mit Ihrer Untersuchung ansetzen können, sind Klassen mit dem Stereotyp
<<Steuerung>> (Control), Anwendungsfallrealisierungen und Elemente, die in der Architektursicht des
Prozesses oder im Implementierungsmodell mit dem Stereotyp <<Prozess>> (Process) oder
<<Thread>> beschrieben sind.
Definieren Sie die physischen Anforderungen in Bezug auf die Vorgaben, die sich aus der Testumgebung ergeben.
|
Systemgrenzen und -schnittstellen identifizieren
Zweck:
|
Verstehen, welche Zuständigkeiten das System als Serviceprovider und welche Abhängigkeiten es als Client
hat.
|
Eine andere Gruppe von Elementen, die zu untersuchen sich lohnt, sind die Schnittstellen des Systems, insbesondere
diejenigen, die sich auf Akteure außerhalb der Systemgrenzen beziehen. Suchen Sie unter Verwendung des Designmodells
und des Implementierungsmodells nach Elementen mit dem Stereotyp <<Schnittstelle>> (Interface). Überprüfen
Sie auch die Modelle auf Klassen mit dem Stereotyp <<Grenze>> (Boundary).
Als Tester sollte man diese Systemgrenzen überschreiten, um eine Vorstellung von den Erwartungen der zugehörigen
Systeme, sowohl Client als auch Serviceprovider, zu bekommen. Dies ist erforderlich, um festzustellen, wie die
Schnittstellen validiert werden können und welche Testinfrastruktur erforderlich ist, um diese Schnittstellen zu testen
und möglicherweise zu simulieren.
|
Elemente der Testinfrastruktur identifizieren
Zweck:
|
Die wesentlichen, für die Testausführung erforderlichen Elemente identifizieren.
|
Damit ein iterativer Test erfolgreich sein kann, ist es wichtig, eine entsprechende Infrastruktur zu identifizieren.
Ohne eine solche Infrastruktur kann schnell eine Situation eintreten, in der der Test nicht mehr gepflegt werden kann
und damit unbrauchbar wird. Die Testinfrastruktur spielt für automatische Tests offensichtlich eine größere Rolle, ist
jedoch auch für manuelle Tests wichtig.
Prüfen Sie die dynamischen Elemente und Ereignisse im System. Welche Abhängigkeiten ergeben sich aus ihnen für die
Implementierung einzelner Tests? Suchen Sie nach Möglichkeiten, die Abhängigkeiten zwischen einzelnen Tests aufzulösen
und sie über allgemeine Steuerungspunkte, die eine Dereferenzierungsebene bereitstellen, zu verwalten. Allgemeine
Bereiche, die auf Abhängigkeiten untersucht werden können, sind die Testnavigation, die Verwendung von Testdaten sowie
Änderungen des Systemstatus.
Prüfen Sie unter Berücksichtigung der gesammelten Informationen, welche Anforderungen die Testinfrastruktur steuern und
welche Funktionen sie benötigen, um einen erfolgreichen Testansatz zu ermöglichen.
Unterthemen:
Einige Tests haben zwar eine allgemeine Struktur für das Szenario oder eine Prozedur, die bei der Ausführung verwendet
wird, diese Prozedur muss jedoch viele Male für verschiedene Testzielelemente ausgeführt werden. Im Falle der
Testautomatisierung kann es nützlich sein, allgemeine Testscripts oder Dienstprogrammfunktionen, die in vielen
verschiedenen Kontexten wiederverwendet werden können, zu erstellen, um diese allgemeinen Testszenarios effizient
ausführen zu können. So steht ein zentraler Modifikationspunkt zur Verfügung, wenn das Testszenario geändert werden
muss. Beispiele dafür sind die Durchführung von Standardgrenztests für geeignete Klassen von Schnittstellenelementen
und die Validierung von UI-Elementen hinsichtlich der Einhaltung von UI-Designstandards.
Wenn Tests in einer bestimmten Testumgebungskonfiguration durchgeführt werden sollen, gibt es ein Konfliktpotenzial in
den verwendeten Werten der Testdaten. Dieses Potenzial erhöht sich proportional, wenn die Umgebung von mehreren
Mitgliedern des Testteams gemeinsam genutzt wird. Ziehen Sie einen datengesteuerten Ansatz in Erwägung, der die
Testdatenwerte von den Testscripts, die sie verwenden, entkoppelt, und stellen Sie einen zentralen Sammel- und
Modifikationspunkt der Testdaten bereit. Dieser Ansatz bietet zwei wichtige Vorteile: Alle Mitglieder des Testteams
können die Testdaten sehen und potenzielle Konflikte in deren Verwendung vermeiden, außerdem wird ein zentraler
Modifikationspunkt für die Testdaten bereitgestellt, wenn sie aktualisiert werden müssen.
Die meisten Tests erfordern, dass das System sich in einem bestimmten Status befindet, damit sie durchgeführt werden
können, und sollen das System in einen bestimmten, bekannten Status zurückführen, wenn sie abgeschlossen sind.
Allgemeine Abhängigkeiten beinhalten Sicherheitsberechtigungen (für Funktionen oder Daten), dynamische oder
kontextsensitive Daten (z. B. Systemdaten, Auftragsnummer, Einstellungen für Benutzer-IDs), Datenablaufzyklen (z. B.
Sicherheitskennwörter, Produktablauf etc.). Einige Tests sind stark voneinander abhängig. Beispielsweise kann es sein,
dass ein Test eine eindeutige Folgenummer erstellt und ein folgender Test dieselbe Folgenummer zuteilt.
Häufig wird das Problem so gelöst, dass man Testsuites verwendet, um abhängige Tests in die richtige
Systemstatusreihenfolge zu setzen. Die Testsuites können dann entsprechenden Dienstprogrammen für
Systemwiederherstellung und Konfiguration zugeordnet werden. Für automatische Tests werden zuweilen dynamische
Systemdaten zentral gespeichert und Variablen in den Testscripts, die die zentralisierten Daten referenzieren,
verwendet.
Tests müssen manchmal geeignete Datenwerte aus einem oder mehreren Aspekten des Laufzeitsystemstatus berechnen oder
ableiten. Dies gilt für Testdatenwerte für die Eingabe und erwartete Ergebnisse. Ziehen Sie in Erwägung,
Dienstprogramme zu entwickeln, die die abgeleiteten Datenwerte berechnen, indem sie die Testausführung vereinfachen und
potenzielle, durch Benutzerfehler eingeführte Ungenauigkeiten beseitigen. Entwickeln Sie diese Dienstprogramme, wann
immer dies möglich ist, damit sie für manuelle oder automatische Tests verwendet werden können.
Für die Automatisierung des Tests sollten Sie in Erwägung ziehen, allgemeine Navigationssequenzen zu isolieren und sie
mit zentralen Dienstprogrammfunktionen oder Testscripts zu implementieren. Diese allgemeinen Navigationssequenzen
können dann an vielen Stellen wiederverwendet werden und als zentraler Modifikationspunkt fungieren, wenn die
Navigation später geändert werden soll. Diese allgemeinen Navigationshilfen navigieren die Anwendung einfach von einem
Punkt zu einem anderen und testen selbst lediglich den Anfangs- und den Endstatus, andere Tests werden normalerweise
nicht durchgeführt.
|
Testspezifische Designanforderungen identifizieren
Zweck:
|
Die Anforderungen der Disziplin Test, die potenzielle Vorgaben für den Softwareentwicklungsprozess, die
Softwarearchitektur, das entsprechende Design und die Implementierung festlegen, identifizieren.
|
Insbesondere bei der Testautomatisierung ist es wahrscheinlich, dass die Anforderungen für Testimplementierung und
Testbewertung Einschränkungen sowohl für den Ablauf des Softwareentwicklungsprozess als auch für die Architektur und
das Design der Software bedeuten. Es ist wichtig, dass das Softwareentwicklungsteam nicht unnötig bei seinen
Kernaufgaben behindert wird und das Testteam die Möglichkeit hat, die erforderlichen Tests durchzuführen. Der Abschnitt
Aufgabe: Zusage zur Testfähigkeit anfordern beschreibt, wie die
Bedürfnisse des Testteams dem Entwicklungsteam dargestellt und durchführbare Lösungen, die die Bedürfnisse aller
Disziplinen erfüllen, gefunden werden können.
Mit den Informationen, die Sie gesammelt haben, müssen Sie prüfen, welche Anforderungen sich aus den Tests für die
Entwicklung ergeben.
Unterthemen:
Prüfen Sie die identifizierten Schnittstellen. Gibt es zusätzliche Anforderungen, die beim Test berücksichtigt und dann
in der Implementierung zum Ausdruck gebracht werden müssen? In einigen Fällen sind weitere Schnittstellen zur
Unterstützung der Tests erforderlich oder vorhandene Schnittstellen erfordern zusätzliche Betriebsmodi bzw. geänderte
Nachrichtensignaturen (Änderungen an Eingabe- und Rückgabeparametern).
Identifizieren Sie die Vorgaben und Abhängigkeiten für die Tests hinsichtlich der Ziel-Deployment-Umgebungen (wie in
den Konfigurationen der Testumgebung erfasst) und des Entwicklungsplans selbst. Diese Abhängigkeiten machen es
möglicherweise erforderlich, Stubs bereitzustellen, um Umgebungselemente zu simulieren, die nicht verfügbar sind oder
einen unverhältnismäßig hohen Ressourcenaufwand für Testzwecke erfordern, oder um einen frühen Komponententest des
teilweise fertig gestellten Systems zu ermöglichen.
Einige Tests sind zwar potenziell nützlich, jedoch als echte Blackbox-Tests zu aufwendig zu implementieren. Darüber
hinaus ist es in Umgebungen, die eine hohe Zuverlässigkeit erfordern, wichtig, Fehler so schnell wie möglich per Test
ermitteln und isolieren zu können, um eine schnelle Behebung zu ermöglichen. In diesen Fällen kann es nützlich sein,
Tests direkt in die ausführbare Software selbst zu integrieren.
Das kann mit verschiedenen Ansätzen erreicht werden. Zwei der bekanntesten arbeiten mit integrierten Selbsttests, bei
denen die Software redundante Verarbeitungszyklen zur Ausführung von Integritätsselbsttests verwendet und außerdem
Diagnoseroutinen, die ausgeführt werden können, wenn eine ereignisbezogene Diagnosenachricht an die Software gesendet
wird oder das System für die Ausführung mit aktivierten Diagnoseroutinen konfiguriert wird.
Einige der Design- und Implementierungsoptionen, die das Entwicklungsteam ausgewählt hat, ermöglichen oder verhindern
die Tests. Verschiedene dieser Optionen sind zwar notwendig, es gibt jedoch eine Reihe von kleineren Entscheidungen -
insbesondere im Bereich der Implementierung - die geringe Auswirkungen auf das Entwicklungsteam, jedoch erhebliche
Auswirkungen auf das Testteam haben.
Die zu berücksichtigenden Bereiche sind folgende: Verwendung anerkannter Standardübertragungsprotokolle, Verwendung von
UI-Implementierungskomponenten, die von Testautomatisierungstools erkannt werden können, Verwendung von UI-Designregeln
einschließlich der Benennung von UI-Elementen, konsistente Verwendung von UI-Navigationskonventionen.
|
Anforderungen für Testfähigkeit der Software definieren
Zweck:
|
Die Anforderungen für die Softwarefunktionen, die für die Unterstützung der Implementierung und
Durchführung von Tests erforderlich sind, angeben.
|
Definieren Sie basierend auf der Arbeit, die Sie bereits für die Aufgabe geleistet haben, die testspezifischen
Anforderungen und Vorgaben, die beim Softwaredesign und der Softwareimplementierung berücksichtigt werden
sollten.
Es ist wichtig, dem Entwicklungsteam klar zu machen, warum die testspezifischen Funktionen in die Software integriert
werden müssen. Wichtige Gründe lassen sich normalerweise einem der folgenden Punkte zuordnen:
-
Die Implementierung manueller und automatischer Tests ermöglichen, durch Bereitstellung einer Schnittstelle
zwischen Zieltestelement und manuellem bzw. automatischem Test. Das ist normalerweise sehr wichtig, um
Einschränkungen, die für Testautomatisierungstools typisch sind, bewältigen zu können. Die Implementierung
ermöglicht den Zugriff auf die Softwareanwendung für Dateneingabe und -ausgabe.
-
Sicherstellen, dass integrierte Selbsttests von der entwickelten Software selbst ausgeführt werden können.
-
Sicherstellen, dass Zieltestelemente vom übrigen entwickelten System isoliert und getestet werden können.
Testspezifische, in die Software integrierte Funktionen müssen einen Mittelweg finden zwischen dem Nutzen einer
integrierten Testfunktion und dem Aufwand, der für Implementierung und Test erforderlich ist. Beispiele für integrierte
Testfunktionen sind die Erstellung von Prüfprotokollen, Selbstdiagnosefunktionen und Schnittstellen zum Abfragen von
Werten interner Variablen.
Während der Integration, bei der Stubs für Komponenten oder Subsysteme, die noch nicht implementiert oder eingebunden
sind, bereitgestellt werden müssen, werden ebenfalls häufig testspezifische Funktionen eingesetzt. Es gibt zwei
wichtige Implementierungsarten für Stubs:
-
Stubs und Treiber, die einfach nur "Dummys" sind und lediglich in der Lage sind, einen oder mehrere bestimmte
vordefinierte Werte als Eingabe- oder Rückgabewert bereitzustellen.
-
Stubs und Treiber, die intelligenter sind und ein komplexeres Verhalten simulieren oder näherungsweise berechnen
können.
Dieser zweite Stub-Typ bietet auch eine sehr effiziente Möglichkeit, Komponenten oder Komponentengruppen vom übrigen
System zu isolieren und so Flexibilität bei der Implementierung und Ausführung von Tests bereitzustellen. Wie schon
zuvor bei den testspezifischen Funktionen muss ein Mittelweg gefunden werden zwischen dem Nutzen eines komplexen Stub
und dem Aufwand, der für Implementierung und Test des Stub erforderlich ist. Verwenden Sie diesen zweiten Typ aus zwei
Gründen mit Vorsicht. Erstens, er benötigt mehr Ressourcen für die Implementierung, zweitens, es ist einfacher, sein
Vorhandensein zu übersehen und somit zu vergessen, ihn anschließend zu löschen.
Dokumentieren Sie Ihre Ergebnisse in Form testspezifischer Anforderungen für Design- und Implementierungsmodelle direkt
oder verwenden Sie dazu eine oder mehrere Spezifikationen für Testschnittstellen.
|
Testinfrastruktur definieren
Zweck:
|
Die Anforderungen für die Testinfrastruktur, die für die Unterstützung der Implementierung und die
Testausführung erforderlich sind, angeben.
|
Definieren Sie basierend auf der Arbeit, die Sie bereits für die Aufgabe geleistet haben, die Testinfrastruktur, die
erforderlich ist, um die Testimplementierung und Testausführung zu unterstützen.
Beachten Sie, dass Sie die Implementierungsfunktionen der Infrastruktur definieren. Das Hauptziel ist, die
verschiedenen Teile der Lösung, die diese Infrastruktur implementieren, zu definieren.
Unterthemen:
Wichtige Anforderungen oder Merkmale der Infrastruktur für Testautomatisierung sind folgende:
-
Navigationsmodell: Umlaufmethode, Unterteilungsmethode oder Hybridmethode sind üblich. Weitere Möglichkeiten sind:
ein Framework, das auf Aktionen und Wörtern basiert, oder Tabellen für die Navigation in der Anzeige.
-
Externer Datenzugriff: eine Methode, bei der über Testanweisungen extern auf Daten zugegriffen wird.
-
Fehlermeldung und -behebung: allgemeine Fehlerbehandlungsroutinen und Wrapper für die Wiederherstellung von
Testsuites.
-
Sicherheit und Zugriffsprofile: Benutzer-IDs für automatische Testausführung.
-
Fähigkeit der Software, Selbsttests durchzuführen.
Dokumentieren Sie Ihre Entscheidungen als Definitionen in den Implementierungsabschnitten der Architektur für
Testautomatisierung, als Prozessanleitung in einer oder mehreren Testrichtlinien oder als Testscripts, Testsuites oder
in Dienstprogrammroutinen für Testbibliotheken. Weitere Informationen finden Sie im Abschnitt Arbeitsergebnis: Architektur für Testautomatisierung.
Wichtige Anforderungen oder Merkmale der Infrastruktur für manuelle Tests sind folgende:
-
Testdaten-Repository: ein allgemeines Repository für die Definition von Testdaten.
-
Wiederherstellung: eine Methode, die Konfiguration der Testumgebung auf einen bekannten Status zurückzusetzen.
-
Sicherstellen, dass Zieltestelemente vom übrigen entwickelten System isoliert und getestet werden können.
Dokumentieren Sie Ihre Entscheidungen als Prozessanleitung in einer oder mehreren projektspezifischen Richtlinien.
|
Ergebnisse auswerten und prüfen
Zweck:
|
Überprüfen, ob die Aufgabe ordnungsgemäß ausgeführt wurde und die resultierenden Arbeitsergebnisse
annehmbar 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 Umfang "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 vom 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 die umgebende Situation für
das Arbeitsergebnis sich noch ändern wird und die bei Erzeugung des Arbeitsergebnisses gültigen Annahmen sich 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.
|
|