Den Testansatz, die Zieltestelemente und den Bewertungsbedarf untersuchen
Zweck:
|
Sie sollen sich mit der Bewertung von Tests vertraut machen und verstehen, wie die spezifischen Testsuites
implementiert werden müssen, damit die Zieltestelemente bewertet werden können.
|
Beginnen Sie mit der Überprüfung des Testplans, um den Bewertungsbedarf zu ermitteln, und untersuchen Sie, wie die
Bewertung des Testumfangs und der Softwarequalität mit dem jeweiligen Testansatz bestimmt werden können.
Berücksichtigen Sie alle besonderen Anforderungen, die hinsichtlich der spezifischen Zieltestelemente behandelt werden
müssen.
|
Testfähigkeitsmechanismen und unterstützende Elemente untersuchen
Zweck:
|
Feststellen, welche Testfähigkeitselemente verfügbar sind. Feststellen, welche Mechanismen sie unterstützen
und welche Vorzüge sie bieten.
|
Überprüfen Sie die Mechanismen, die geeignet sind, das Testen in dieser Umgebung zu ermöglichen, und identifizieren Sie
die spezifischen Testfähigkeitselemente, die diese Mechanismen implementieren. Dazu gehört das Überprüfen von
Ressourcen wie der vom Testteam entwickelten Funktionsbibliotheken, Stubs oder Testsimulationen, die vom
Entwicklungsteam implementiert wurden.
Die Testfähigkeit wird durch eine Kombination aus testfähiger Entwicklungssoftware und Definition eines Testansatzes,
der das Testen in passender Weise unterstützt, erreicht. Die Testfähigkeit als solche ist ein wichtiger Aspekt der
Assetentwicklung des Testteams, so wie sie ein wichtiger Teil der Softwareentwicklung ist. Das Erreichen der
Testfähigkeit (der Fähigkeit, das Softwareprodukt effektiv zu testen) beinhaltet normalerweise eine Kombination der
folgenden Elemente:
-
Testfähigkeitsfaktoren, die von Testautomatisierungstools bereitgestellt werden
-
Spezifische Techniken zum Erstellen der Komponententest-Scripts
-
Funktionsbibliotheken, die komplexe Teile abtrennen und in der Basisdefinition der Testprozedur im Test-Script
kapseln und so einen zentralen Steuer- und Änderungspunkt bereitstellen.
Muss die aktuelle Testsuite verteilt werden? Wenn ja, verwenden Sie die Testfähigkeitselemente, die Verteilung
unterstützen. Diese Elemente sind normalerweise Funktionen spezifischer Automatisierungsunterstützungstools, die die
Testsuite verteilen, über ein fernes System ausführen und das Testprotokoll sowie andere Ausgaben für zentrale
Ergebnisbestimmung zurückgeben.
Muss die aktuelle Testsuite parallel zu anderen Testsuites ausgeführt werden? Falls ja, verwenden Sie die
Testfähigkeitselemente, die Verteilung unterstützen. Diese Elemente sind normalerweise eine Kombination aus
spezifischen Unterstützungstools und Dienstprogrammfunktionen, die die parallele Ausführung mehrerer Testsuites auf
verschiedenen physischen Maschinen ermöglichen. Die Parallelität erfordert ein sorgfältiges Design und Management der
Testdaten, um sicherzustellen, dass keine unerwarteten oder ungeplanten Nebenwirkungen auftreten, z. B. zwei parallele
Tests, die denselben Datensatz aktualisieren.
|
Erste Testsuite-Struktur erstellen
Zweck:
|
Die zu implementierenden Testsuites skizzieren.
|
Zählen Sie eine oder mehrere Testsuites auf, die dem Testteam bei der Ausführung ein vollständiges, sinnvolles und
nützliches Ergebnis geben und folgende Berichte an Stakeholder ermöglichen. Versuchen Sie, dem Projektteam
Informationen zur Verfügung zu stellen, die einerseits ausreichend spezifisch, andererseits nicht so detailliert sind,
dass sie die Nutzer überfordern und nicht mehr gehandhabt werden können.
Wenn bereits Test-Scripts vorhanden sind, können Sie die Testsuite und ihre Bestandteile wahrscheinlich selbst
assemblieren und die stabilisierte Testsuite dann zur Implementierung an einen Testsuite-Implementierer übergeben.
Für Testsuites, die die Erstellung neuer Test-Scripts erfordern, müssen Sie auf die Test-Scripts oder andere Testsuites
hinweisen, von denen Sie annehmen, dass sie von dieser Testsuite referenziert werden. Wenn eine einfache Aufzählung
möglich ist, verwenden Sie sie. Ist das nicht der Fall, können Sie einfach eine Kurzbeschreibung bereitstellen, die
angibt, welchen Inhalt die Haupt-Testsuite abdeckt. Es bleibt dem Testsuite-Implementierer überlassen, taktische
Entscheidungen zur Aufnahme der einzelnen Testsuites zu treffen.
|
Testsuite-Struktur so anpassen, dass sie die Einschränkungen für Teamorganisation und Tools widerspiegelt
Zweck:
|
Die Testsuite-Struktur so anpassen, dass sie mit den jeweiligen Zuständigkeiten im Team funktioniert.
|
Möglicherweise müssen Sie die Testsuites, die Sie identifiziert haben, unterteilen oder restrukturieren, damit Sie den
Projektstrukturplan unterbringen können. Damit helfen Sie, das Risiko von Zugriffskonflikten während der
Testsuites-Entwicklung zu reduzieren. Manchmal unterliegt die Art und Weise, in der Einzelpersonen mit
Automatisierungs-Assets arbeiten, gewissen Einschränkungen, die durch die Testautomatisierungstools vorgegeben sind.
Also müssen Sie die Testsuites erneut strukturieren, um dieses Problem zu umgehen.
|
Mechanismen für Kommunikation zwischen Scripts identifizieren
Zweck:
|
Die Testdaten und den Systemstatus, der von den Test-Scripts gemeinsam genutzt oder zwischen ihnen
übergeben werden muss, identifizieren.
|
Meistens können Testsuites andere Testsuites in einer bestimmten Reihenfolge aufrufen. In vielen Fällen ist das
ausreichend, um sicherzustellen, dass der richtige Systemstatus von einem Test-Script zum nächsten übergeben wird.
In bestimmten Systemklassen werden dynamische Laufzeitdaten vom System generiert oder von Transaktionen, die im System
stattfinden, abgeleitet. Beispielsweise wird in einem System für Auftragseingabe und -zuteilung jedes Mal, wenn ein
Auftrag eingegeben wird, vom System eine eindeutige Auftragsnummer generiert. Wenn ein automatisches Test-Script einen
Auftrag zuteilen soll, muss zuvor ein Test-Script für Auftragseingabe die eindeutige, vom System generierte Nummer
erfassen und an das Test-Script für Auftragszuteilung übergeben.
In Fällen wie diesen müssen Sie prüfen, welcher Mechanismus für die Kommunikation zwischen den Scripts am besten
verwendet werden soll. Typische Alternativen sind übergebene Parameter, Schreiben und Lesen von Werten in einer
Plattendatei und Verwenden globaler Laufzeitvariablen. Jede Strategie hat Vor- und Nachteile, aufgrund derer sie sich
für eine bestimmte Situation mehr oder weniger eignet.
|
Erste Abhängigkeiten zwischen Testsuite-Elementen definieren
Zweck:
|
Die Laufzeitabhängigkeiten zwischen Testsuite-Elementen identifizieren.
|
Das bezieht sich hauptsächlich auf die Reihenfolge der Test-Scripts und möglicherweise Testsuites für die
Laufzeitausführung. Tests, die durchgeführt werden, ohne dass die richtigen Abhängigkeiten hergestellt wurden, laufen
Gefahr, fehlzuschlagen oder fehlerhafte Daten zurückzugeben.
|
Architektur für Testimplementierung visuell modellieren
Zweck:
|
Ein Diagramm nutzen, um die Testimplementierung zu dokumentieren und zu erläutern.
|
Wenn Sie Zugriff auf ein UML-Modellierungs- oder Zeichentool haben, möchten Sie möglicherweise ein Diagramm des
Testimplementierungsmodells erstellen, das die Schlüsselelemente der automatisierten Testsoftware beschreibt. Sie
können auch einige Schlüsselaspekte der Architektur für Testautomatisierung in ähnlicher Weise in Diagrammform
darstellen.
Ein anderer Ansatz ist, diese Diagramme auf einem Whiteboard zu zeichnen, das für das Team gut erkennbar ist.
|
Testsuite-Struktur verfeinern
Zweck:
|
Erforderliche Anpassungen vornehmen, um die Integrität der Testimplementierung aufrechtzuerhalten.
|
Mit fortschreitendem Projekt nimmt die Wahrscheinlichkeit, dass die Testsuites sich ändern, zu: Test-Scripts werden
hinzugefügt, und alte Test-Scripts werden aktualisiert, neu sortiert oder gelöscht. Diese Änderungen sind ein
natürlicher Bestandteil der Testsuite-Verwaltung. Sie sollten diese Änderungen akzeptieren und nicht versuchen, sie zu
vermeiden.
Wenn Sie die Testsuites nicht aktiv verwalten, werden sie schnell fehlerhaft und kommen außer Gebrauch. Auch wenn nur
noch ein paar Builds zu bewältigen sind, kann es einen enormen Aufwand bedeuten, eine Testsuite zu reaktivieren, so
dass es möglicherweise einfacher ist, eine Testsuite einfach aufzugeben und eine vollkommen neue zu erstellen. Weitere
Richtlinien zur Verwaltung automatisierter Testsuites finden Sie im Abschnitt Weitere
Informationen in der Header-Tabelle dieser Seite.
|
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 nach Bedarf.
|
Ergebnisse bewerten 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.
|
|