Aufgabe: Testfähigkeitselemente definieren
Diese Aufgabe beschreibt, wie die Elemente, die Tests unterstützen und ermöglichen, identifiziert werden.
Disziplinen: Test
Zweck

Der Zweck dieser Aufgabe:

  • Die Elemente, die zur Unterstützung der Zieltestelemente erforderlich sind, identifizieren
  • Die physischen Elemente der Infrastruktur der Testimplementierung, die für das Testen unter jeder Testumgebungskonfiguration erforderlich sind, identifizieren
  • Die Voraussetzungen für das Softwaredesign, die erfüllt werden müssen, damit die Software physisch getestet werden kann, definieren.
Beziehungen
Schritte
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:

Allgemeine Testszenarios vereinfachen Seitenanfang

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.

Testdatenabhängigkeiten vereinfachen Seitenanfang

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.

Teststatusabhängigkeiten vereinfachen Seitenanfang

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.

Abgeleitete Testdatenwerte vereinfachen Seitenanfang

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.

Allgemeine Testnavigationspfade vereinfachen Seitenanfang

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:

Testschnittstellen identifizieren Seitenanfang

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.

Integrierte Testschnittstellen identifizieren Seitenanfang

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.

Vorgaben für Testdesign identifizieren Seitenanfang

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:

Elemente der Testautomatisierung Seitenanfang

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.

Elemente manueller Tests Seitenanfang

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.



Weitere Informationen