Frühes und häufiges Testen

Das rechtzeitige Abfangen von Fehlern ist die günstigste Möglichkeit zur Sicherstellung der Softwarequalität. Kent Beck und Cynthia Andres schrieben: "Das ist das Problem bei der Softwareentwicklung: Fehler sind teuer, ihre Beseitigung aber ebenso. Die meisten Fehler verursachen jedoch höhere Kosten als für ihre Vermeidung anfallen." ((Weitere Informationen finden Sie in der folgenden Webseite: Extreme Programming Explained: Embrace Change.) Bewährte Methoden und Tools können dem Team dabei helfen, die Kosten für das Verhindern und Beheben von Fehlern zu senken, indem die Qualität des Projekts in dessen Lebenszyklus erhalten bleibt.

Das Team kann jederzeit die aktuelle Qualität des Projekts genauer bestimmen, wenn Fehler gefunden, behoben oder überprüft werden. Durch häufige Tests behalten das Team und die Projektbeteiligten den Überblick über den aktuellen Zustand des Codes und können im gesamten Verlauf des Projekts die richtigen Entscheidungen treffen. Letztlich sollten Sie in der Lage sein, die Frage "Können wir das Produkt veröffentlichen?" zu beantworten und die Auswirkungen auf die Personen kennen, die die Software verwenden.

In diesem Thema werden die folgenden Übungen empfohlen:

• Erstellen eines Satzes automatisierter Komponententests für jede Klasse und für die API jeder Hauptkomponente. Das Schreiben von Komponententests beansprucht ungefähr 40 % der Zeit Teammitglieder. Weitere Informationen finden Sie unter Erstellen von automatisierten Tests.

• Erstellen Sie Tests für jede User Story. Diese Tests sollten vorzugsweise automatisiert werden. Weitere Informationen finden Sie unter Erstellen eines Testplans aus Anforderungen oder Benutzerberichten.

• Erstellen Sie Eincheckrichtlinien, die Teammitglieder daran erinnern, dass vor dem Einchecken von Code Komponententests ausgeführt werden müssen. Weitere Informationen finden Sie unter Hinzufügen von Eincheckrichtlinien.

• Richten Sie einen fortlaufenden oder nächtlichen Build ein, von dem sämtliche Tests ausgeführt werden.

• Überwachen Sie die Testabdeckung, um sicherzustellen, dass der gesamte Code getestet wird. Die Abdeckung sollte mindestens 70 % betragen. Weitere Informationen finden Sie unter Excel-Bericht "Testlücken" (Agile).

• Führen Sie gegen Ende jedes Sprints manuelle Tests aus.

Das Team kann diese Testaktivitäten im Projekt frühzeitig mit der Integration zwischen Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM) und Visual Studio Team Foundation Server verwalten und skalieren. Weitere Informationen finden Sie unter Testen der Anwendung.

In diesem Thema

• Teststrategie

• Testplanung

• Akzeptanztests

• Komponententests

• Testgesteuerte Entwicklung und frühzeitige Tests

• Manuelle Tests im Vergleich zu automatisierten Tests

• Melden der Testergebnisse

Teststrategie

Der Erfolg des Teams bei Tests hängt von mehreren Faktoren ab. Dazu gehören die Größe, die Methoden und die Verwaltungstools des Teams. Sie können Testergebnisse kontinuierlich mithilfe von Agile-Methoden verbessern. Mit dieser Methode können Tests nicht nur mit äußerst begrenzten Ressourcen gestartet werden, sondern die Vorgehensweise kann im Verlauf des Projekt auch nach Bedarf angepasst werden.

Hinweise zur Einführung von agilen Tests

Wenn Sie agile Tests in einer vorhandenen Anwendung einführen, kann das Team zuerst die Teststrategie sowohl auf Sprint- als auch auf Projektebene zum Gegenstand seiner Überlegungen machen. Auf Sprintebene kann ein Satz mit Akzeptanztests eingeschlossen werden, um jede User Story des aktuellen Sprints abzudecken. Auf Projektebene können Tests verwendet werden, die das gesamte Projekt umfassen, z. B. End-to-End-Tests. Dies ist hilfreich, wenn Sie die Funktionen überprüfen möchten, die mindestens zwei Sprints umfassen. Sie können alle Arten von Tests erstellen, während das Team im Zuge eines Sprints Code erstellt. Diese Tests schließen Komponententests, Akzeptanztests und nicht funktionale Tests ein, z. B. Leistungstests, Sicherheitstests und Benutzerfreundlichkeitstests.

Vor dem Anwenden agiler Testmethoden sollte zuerst der Verlauf der Anwendung und des Systems berücksichtigt werden, das vom Team verwendet wird. Sie können agile Testmethoden sowohl für neue als auch für vorhandene Anwendungen übernehmen. Mithilfe von Microsoft Test Manager können ein Testplan für das gesamte Projekt und ein Testplan für jeden Sprint im Projekt erstellt werden. Diese Testpläne ermöglichen es dem Team, Testfälle in Testsammlungen zu organisieren, die die Priorisierung von ausgeführten Tests und die Nachvollziehbarkeit der Testergebnisse erleichtern. Weitere Informationen finden Sie unter Erstellen eines Testplans aus Anforderungen oder Benutzerberichten. Das Team kann mithilfe von Visual Studio ALM Testfälle durch mehrere Methoden in Testsammlungen gruppieren:

• Erstellen und Verwalten einer statischen Gruppe von Testfällen

• Erstellen und Verwalten einer dynamischen Gruppe von Testfällen mit einer Abfrage (d. h., die Suche nach Testfällen erfolgt nach Priorität)

• Hinzufügen einer User Story oder einer Anforderung zu einem Testplan, in dem Testfälle einen Link zur Anforderung besitzen

• Kopieren einer vorhandenen Testsammlung aus einem anderen Testplan

Weitere Informationen finden Sie unter Organisieren von Testfällen in Testsammlungen.

Zweitens muss die Prüfbarkeit des Codes berücksichtigt werden. Dazu sind Kenntnisse der Architektur und der Muster der Anwendung erforderlich. Wenn Sie Muster wie Modell View Controller (MVC), Modell View ViewModel (MVVM) oder Modell View Presenter (MVP) verwenden, können Sie bestimmte Funktionen isolieren und Funktionstests ohne die negativen Auswirkungen von Benutzeroberflächentests ausführen. Dies entspricht jedoch nicht immer der Wirklichkeit. Sie können z. B. keine Funktionen für die Umgestaltungsbereiche der Anwendung isolieren. Zudem können bestimmte Bereiche des Codes nur über die Benutzeroberfläche oder Netzwerkereignishandler erreicht werden. Wenn Sie die Testqualität deutlich verbessern möchten, muss der Prozentsatz des testfähigen Codes erhöht werden. Weitere Informationen zu diesen Mustern finden Sie unter ASP.NET MVC 2.

Drittens müssen die Fähigkeiten des Teams eingeschätzt werden, bevor Sie agile Tests implementieren. Einige Teammitglieder sollten in der Lage sein, Komponententests zu erstellen, wenn Sie Funktionen implementieren. Einige Teammitglieder sollten in der Lage sein, manuelle Anwendungsfälle und Workflowtests zu erstellen und zu definieren, wenn sie mit den Geschäftsregeln für die Anwendung vertraut sind. Darüber hinaus sollten andere Teammitglieder in der Lage sein, automatisierte und detailliertere Tests zu erstellen, die auf diesen manuellen Tests basieren, wenn sie die erforderlichen technischen Kenntnisse besitzen.

Verwalten des Testlebenszyklus

Testen ist ein iterativer Prozess im Verlauf des Projekts. Berücksichtigen Sie die folgenden Schritte:

1. Legen Sie eindeutige Testziele fest, und stellen Sie sicher, dass das gesamte Team damit einverstanden ist. Bestimmen Sie die Teststrategie auf Grundlage dieser Ziele. Die Strategie könnte z. B. folgendermaßen aussehen: "Tests werden vor jedem Einchecken ausgeführt, Komponententests weisen eine Codeabdeckung von 70 % auf, und für jede User Story wird mindestens ein automatisierter Test ausgeführt".

2. Definieren Sie den Testplan auf Grundlage von projektbezogenen User Storys, Entwurfsannahmen und nicht funktionalen Anforderungen im aktuellen Sprint.

   1. Sie können dem Rückstand User Storys hinzufügen und sie für zukünftige Sprints planen. Ordnen Sie jeden Testplan mindestens einem Sprint zu. Daher sollten Testfälle für alle User Storys im Sprint vorhanden sein.

3. Definieren und erstellen Sie Testfälle, wie z. B. Akzeptanztests, Komponententests, Funktionstests und Leistungstests.

4. Gruppieren Sie Testfälle in Testsammlungen. Sie können diese Testsammlungen in definierte Testpläne einfügen, die die Steuerung des Testaufwands ermöglichen.

5. Führen Sie Testsammlungen und darin enthaltene Testfälle in einem Sprint wiederholt aus. Beginnen Sie die Ausführung von Tests in der Frühphase eines Sprints, und fügen Sie den Testsammlungen weiterhin Testfälle hinzu. Wenn Sie wichtige Testbedingungen und -situationen erkennen möchten, können Sie exploratives Tests anwenden und häufig Teamgespräche führen.

6. Stellen Sie sicher, dass alle Akzeptanztests für eine User Story erfolgreich verlaufen sind, bevor Sie den Status auf "Abgeschlossen" festlegen.

Obwohl der Workflow abhängig von der Aufteilung der Software wesentlich komplexer sein kann, erfasst die vorherige Abbildung die wesentlichen Bestandteile eines Workflows unter Hauptkomponenten.

• Mit Code werden Builds generiert.

• Der Code wird durch die definierte Arbeit, die Testpläne und die Qualität von Builds beeinflusst.

• Testpläne, Testsammlungen und Testfälle werden von geplanten Zielen und anderen Aspekten des Projekts beeinflusst, die in dieser Abbildung nicht erkennbar sind.

• Änderungen in Code können sich auf Testfälle auswirken.

Beheben von Fehlern

1. Fehler müssen so früh wie möglich behoben werden. Ein schwer wiegender Fehler bedeutet, dass die User Storys, die von dem Fehler betroffen sind, nicht abgeschlossen wurden.

2. Erstellen Sie Fehlerarbeitsaufgaben für Fehler, die entweder durch Tests oder andere Aktivitäten gefunden werden. Legen Sie den Schweregrad des Fehlers fest, um die Auswirkungen auf User Storys anzugeben. Ein hoher Schweregrad, z. B. 0 oder 1, gibt an, dass wichtige User Storys nicht implementiert wurden, oder dass Benutzer die User Story nur durch aufwändige Problemumgehungen fertig stellen können. Ein niedriger Schweregrad, z. B. 3, gibt an, dass Benutzer immer noch ihre Hauptziele ohne zusätzliche Arbeit erreichen können.

3. Arbeiten Sie mit anderen Teammitgliedern zusammen, um einen Aktionsplan für jeden Fehler zu erarbeiten.

4. Lösen Sie Fehler auf, sobald Sie diese beheben. Der Fehler sollte einer anderen Person zur Überprüfung zugewiesen werden. Überprüfen und schließen Sie Fehler so schnell wie möglich.

5. Verfolgen Sie den Status von Fehlern. Sehen Sie sich in der Nachbereitungsbesprechung am Ende jeder Iteration den Fehlertrendbericht an, und diskutieren Sie die Gründe für ungewöhnliche Zunahmen von Fehlern. Weitere Informationen finden Sie unter Bericht "Fehlertrends".

Testplanung

Testplanung ist der Prozess, in dem das Team über die Grundlagen des Projekts informiert wird und auf alle Arten von Tests vorbereitet wird. Agile Tests beginnen auf Sprintebene. In jedem Sprint erstellt das Team Tests, um die User Storys zu überprüfen, die in diesem Sprint erstellt wurden. Das Team führt die Tests aus, die sowohl im aktuellen als auch in den vorherigen Sprints erstellt wurden. Im Verlauf des Projekts wird eine große Anzahl von Tests erstellt, die alle Funktionen abdecken. Die folgende Abbildung zeigt eine Vorlage für Testpläne im Projekt.

Erstellen eines Testplans für jeden Sprint und das Projekt

Mit den Testfunktionen von Visual Studio ALM kann das Team inkrementell Tests planen, organisieren, ausführen und melden. Das Team kann eine Vorlage für Testpläne erstellen, und Teammitglieder können Testsammlungen ausfüllen. In einem Testplan kann das Team bestimmen, wo automatisierte oder manuelle Testfälle verwendet werden sollen.

Für jeden Sprint im Projekt können Sie einen Testplan erstellen. Mit diesem Plan kann sich das Team im aktuellen Sprint auf die Überprüfung von Funktionen konzentrieren. Obwohl der Plan zunächst leer ist, können Sie ihn als Platzhalter für Testsammlungen verwenden. Anschließend können Sie Testfälle in entsprechenden Testsammlungen organisieren. Erstellen Sie diese Testfälle in der Frühphase und im gesamten Verlauf des Sprints, wenn Sie von Projektbeteiligten rechtzeitig Feedback erhalten möchten.

Sie können auch einen Testplan erstellen, der das gesamte Projekt abdeckt. Sie können Projekttestpläne verwenden, um Tests von vorherigen Sprints zu verbinden und um Testsammlungen zu organisieren, die für das gesamte Projekt gelten. Führen Sie weiterhin Regressionstestsammlungen aus, da es wichtig ist, dass Stabilität gewahrt wird und keine Unterbrechungen auftreten, wenn das Team größere Projekte erstellt. Insbesondere, wenn Sie mit größeren Teams arbeiten, deren Mitglieder über mehrere weiter voneinander entfernte Standorte verteilt sind, können mit Regressionstestsammlungen Fehler abgefangen werden, die aus Änderungen resultieren, die sich überlappende Auswirkungen zur Folge haben. Ohne entsprechende Maßnahmen können diese Fehler nur mit Schwierigkeiten abgefangen werden, und unter Umständen werden sie erst in der Endphase des Zyklus oder nach der Übermittlung abgefangen.

Einige Teams möchten ggf. einen Testplan definieren, der das gesamte Projekt umfasst. Mit diesen Arten von Testplänen werden möglicherweise verwandte Funktionen in einer Reihe von Sprints überprüft. Sie erhalten u. U. Testsammlungen, die im gesamten Projekt ausgeführt. Sie können z. B. eine Funktion testen, die nur dann User Storys in Sprints umfasst, wenn die gesamte Funktion vollständig ist.

Definieren von Akzeptanztests vor einem Sprint

Definieren Sie vor einem Sprint Akzeptanztests. Mit diesen Akzeptanztests wird bestimmt, ob eine User Story abgeschlossen ist. Sie können Akzeptanztestfälle verfolgen, wenn Sie eine Testsammlung erstellen, die in einem Testplan für jeden Sprint "Akzeptanztests" genannt wird. Weitere Informationen finden Sie unter Akzeptanztests weiter unten in diesem Thema.

Erstellen von Komponententests während eines Sprints

Das Team sollte während eines Sprints Komponententests erstellen. Mit Komponententests kann die Codeleistung überprüft werden, z. B. der Zeit- und Ressourcenaufwand für die Codeausführung. Andere Testtypen, z. B. nicht funktionale Tests (d. h. Leistungs- und Sicherheitstests), sollten erstellt und den entsprechenden Testsammlungen hinzugefügt werden. Organisieren Sie diese Testsammlungen, damit Sie ihre Kosten leicht ermitteln können.

Richten des Testschwerpunkts auf häufig verwendete Bereiche

Wenn Sie Bescheid wissen, an welcher Stelle der Software hohe Variabilität vorliegt, lässt sich bestimmen, wo sich die Hotspots befinden können. Die Benutzereingabe, die Umgebung zur Ausführung der Software, das Netzwerk und die Hardware sind Beispiele für Konfigurationsvariablen, die es dem Team ermöglichen, Hotspots in der Software zu ermitteln. Wenn eine Bedingung selten auftritt oder es eine verschachtelte Anzahl von Bedingungen gibt, die während eines Tests auftreten können, verringert sich der Wert des Tests, sofern die potenziellen Auswirkungen eines Fehlers nicht sehr schwerwiegend sind. Im Allgemeinen ist eine Isolation der Funktionen erwünscht (wenn möglich). Das Testen von Situationen mit schwerwiegenden Auswirkungen ist ebenfalls wichtig. Weitere Informationen zum Verwalten von Konfigurationen mithilfe von Microsoft Test Manager finden Sie unter Definieren der Testmatrix mit Testkonfigurationen.

Überwachen Sie bei vorhandenen Projekten die Bereiche mit der höchsten Fehleranzahl, und ermitteln Sie, warum die Fehler vorhanden sind. Überwachen Sie außerdem Codeänderungen, da in diesem Bereich zugrunde liegende Annahmen übersehen werden könnten. Einige Gründe für Codefehler resultieren aus Schwierigkeiten, die auftreten, wenn außer Zuständen (z. B. Netzwerk und Benutzeroberfläche) auch Code verwaltet werden soll.

Separate Tests für das Verarbeiten und Speichern von Daten

In Code, in dem eine Datenbank verwendet wird, wird in der Regel die Verarbeitung der Daten vom Speichervorgang getrennt. Sie können die Datenverarbeitung durch Ausführen von Komponententests und den Datenspeicher direkt auf der Datenbankebene testen. Visual Studio Test Professional 2010 verfügt über die Funktionen zum Testen von in Datenbanken gespeicherten Prozeduren. Organisieren Sie diese Tests in einer eigenen Testsammlung. Weitere Informationen finden Sie unter Erstellen und Definieren von Datenbankkomponententests.

Mit Microsoft Test Manager können Momentaufnahmen von Computerimages erstellt werden, die die Wiederherstellung eines bekannten Zustands ermöglichen, nachdem von Daten (oder einem anderen Aspekt des Zustands) abhängige Tests ausgeführt wurden. Diese Tests sind sehr wertvoll und waren in der Regel sehr zeitintensiv.

Akzeptanztests

Akzeptanztests dienen zur Überprüfung von User Storys. Durch diese Tests kann nicht nur sichergestellt werden, dass die Objekte erstellt werden, die von den Kunden im Lebenszyklus des Projekts benötigt werden, sondern auch, dass das Vertrauen der Kunden gestärkt wird und die akzeptierten Zuständigkeiten angezeigt werden. Weitere Informationen finden Sie auf der folgenden Webseite: Acceptance Test Engineering Guide.

Erste Schritte bei Akzeptanztests

Öffnen Sie Microsoft Test Manager, und erstellen Sie anschließend eine Testsammlung, die im Testplan "Akzeptanztests" genannt wird. Das Team benötigt mindestens eine Testsammlung, in der Akzeptanztests für die einzelnen Sprints gruppiert werden. Weitere Informationen finden Sie unter Definieren des Testaufwands mit Testplänen.

Migrieren von manuellen Tests zu automatisierten Tests

Manuelle Tests sind einfacher zu definieren als automatisierte Tests, doch teurer in der Ausführung. Daher wird empfohlen, mit manuellen Tests zu beginnen und die wichtigeren Tests allmählich durch automatisierte Tests zu ersetzen.

Erstellen Sie zunächst eine Reihe von manuellen Testfällen, in denen jede User Story überprüft wird, die für den Sprint definiert wurde. Da am Start eines Sprints kein Code vorhanden ist, sollten in einem Testfall Aktionen auf hoher Ebene dargestellt werden, die Teilen einer User Story zugeordnet werden. Ein Schritt in einem Testfall kann z. B. "Als authentifizierter Benutzer Folgendes ausführen…" sein. Wenn mit einem manuellen Testfall begonnen wird, kann das Team rasch die idealen Akzeptanztests definieren, bevor ein Sprint gestartet wird.

Zweitens müssen Akzeptanztests überarbeitet und aktualisiert werden, um bestimmte Benutzererfahrungen widerzuspiegeln, wenn das Team über Code verfügt, mit dem User Storys in einem Sprint implementiert werden. Wenn das Team jedoch nicht den vorhandenen Satz Akzeptanztests ändern möchte, können Sie die Tests in eine neue Testsammlung importieren und einen Ausgangspunkt für detaillierte Tests erstellen. Ein Schritt in einem ausführlicheren Testfall kann z. B. "Geben Sie im Textfeld "Benutzername" einen Namen ein, und klicken Sie auf die Schaltfläche "Anmelden", um sich beim Bankkonto anzumelden" sein.

Drittens müssen auf Grundlage der Akzeptanztests Tests der codierten UI (Benutzeroberfläche) mithilfe von Aktionsaufzeichnung erstellt werden. Weitere Informationen finden Sie unter Gewusst wie: Generieren eines Tests der codierten UI aus einer Aktionsaufzeichnung. Tests der codierten UI können saubereren Code generieren, wenn Sie Schritte erstellen, durch die die Funktionen isoliert werden. Sie können automatisierte Tests vom Testplan ausführen, wenn Sie an einen Test der codierten UI an manuelle Testfälle anfügen (weitere Informationen finden Sie unter Gewusst wie: Zuordnen eines automatisierten Tests zu einem Testfall.)

Die manuellen Tests, die am Anfang eines Sprints definiert wurden, ermöglichen die Erstellung automatisierter Tests. Sowohl manuelle als auch automatisierte Tests verursachen Kosten, da manuelle Tests von einer Person ausgeführt werden müssen und automatisierte Tests aktualisiert werden müssen, wenn der Code oder die Benutzererfahrung geändert wird. Weitere Informationen finden Sie weiter unten in diesem Thema unter Manuelle im Vergleich zu automatisierten Tests.

Wer führt die Akzeptanztestfälle aus?

Das Team, der Produktbesitzer und die Kunden können Akzeptanztestfälle ausführen. Das Team sollte die Tests so oft wie möglich ausführen, um eine Grundlage dafür zu gewinnen, welcher Testsatz in einem Sprint erfolgreich verlaufen muss. Der Produktbesitzer und der Kunde können auch die Akzeptanztests ausführen, und sie benötigen möglicherweise diese Überprüfung, um den Sprint erfolgreich abzuschließen.

Das Team kann mit Microsoft Test Manager jeden Akzeptanztestfall ausführen und eine Videobildschirmaufnahme der Testergebnisse aufzeichnen. Auf diese Weise erhalten Sie eine visuelle Zusammenfassung der Testergebnisse und können die Ergebnisse auch an die Kunden weitergeben. Dies ist hilfreich, wenn die Erstellung der erforderlichen Konfigurationen (z. B. Multiserverkonfigurationen) Schwierigkeiten bereitet.

Definieren von Akzeptanztestfällen mit User Storys

Sie können Akzeptanzkriterien unmittelbar nach den User Storys definieren. Durch Definieren von Akzeptanztests können dem Team die Akzeptanzkriterien für den aktuellen Sprint vom Produktbesitzer und den Kunden vermittelt werden. Da der Kunde den Akzeptanztests zustimmen muss, empfiehlt es sich, die Akzeptanztestfälle vor Beginn des Sprints zu erstellen.

Komponententests

Komponententests sind automatisierte Tests, durch die die Funktionen auf Komponenten-, Klassen-, Methoden- oder Eigenschaftenebene überprüft werden. Komponententests sind die Grundlage von automatisierten Tests und Regressionstests. Sie gewährleisten die langfristige Stabilität und zukünftige Verwaltbarkeit des Projekts.

Inwiefern tragen Komponententests dazu bei, den Entwurf meiner Anwendung weiterzuentwickeln?

Die Erstellung von Komponententests während der Erstellung des getesteten Codes ermöglicht die Definition der Codeform. Sie können Code erstellen, der mithilfe von Komponententests getestet werden kann. Schwierigkeiten beim Erstellen von Komponententests deuten darauf hin, dass der Code umgestaltet werden muss.

Wie organisiere ich meine Komponententests?

Jedes Teammitglied, das Code schreibt, sollte Komponententests für die von ihm erstellten Komponenten erstellen und den Komponententestcode in der Versionskontrolle in einem Visual Studio-Projekt überprüfen. Erfassen Sie die testfallbezogenen Arbeitsaufgaben in einer Buildüberprüfungs-Testsammlung, die während jedes Buildvorgangs durch fortlaufende Integration und auch in der Testsammlung ausgeführt wird, in der die entsprechende User Story überprüft wird.

Wie verwalte ich die Varianz von Komponententests, ohne den Testcode zu ändern?

Durch Varianz in Testeingaben werden die Unterschiede oder Ähnlichkeiten zwischen Tests definiert, wenn Funktionen im Projektcode überprüft werden. Wenn zum Beispiel die Anmeldekomponente einer Webanwendung getestet wird, können Sie mehrere Kennworttypen bereitstellen, um ein Benutzerkonto zu erstellen. Das System besitzt möglicherweise Regeln für die Reihenfolge und Kombination von Zeichentypen, die verwendet werden.

Visual Studio Test Professional 2010 bietet Funktionen zum Schreiben von datengesteuerten Komponententests und Tests der codierten UI. Weitere Informationen finden Sie unter Gewusst wie: Erstellen eines datengesteuerten Komponententests und Gewusst wie: Erstellen eines datengesteuerten Tests der codierten UI.

Testgesteuerte Entwicklung und frühzeitige Tests

Testgesteuerte Entwicklung befasst sich mit Entwürfen und Programmierung. Dabei wird jede Codezeile als Reaktion auf einen Test geschrieben, den der Programmierer unmittelbar vor der Codierung schreibt. Die Vorstellung der Consumer des Codes zu werden, den Sie implementieren möchten, ist sehr populär und sie bleibt eine realistische Erwartung im Hinblick auf die Verwendung und den Entwurf des Codes.

In TDD arbeitet der Entwickler in zahlreichen kleinen Inkrementen. Die Entwicklung jedes kleinen Inkrements dauert zwischen einigen Minuten und einigen Stunden. In der Regel bilden viele solcher Inkremente eine User Story. Der Entwickler checkt die Tests und den Code ein, wenn die User Story funktioniert. Der Entwickler arbeitet im folgenden Zyklus:

1. Schreiben Sie einen automatisierten Test, der wahrscheinlich erfolgreich verläuft, wenn das Inkrement geschrieben wird.

2. Vergewissern Sie sich, ob der neue Test fehlschlägt, um sicherzustellen, dass der Test funktioniert.

3. Schreiben Sie Code, der einen erfolgreichen Test gewährleistet.

4. Führen Sie den Test aus, um zu überprüfen, ob er erfolgreich verläuft.

5. Führen Sie zudem alle anderen Tests im gleichen Bereich aus, um sicherzustellen, dass sich keine Fehler eingeschlichen haben.

6. Gestalten Sie den Code ggf. um, um seine Struktur zu verbessern, ohne Verhalten hinzuzufügen. Führen Sie die Tests erneut aus, um sicherzustellen, dass der Code immer noch funktioniert.

7. Wiederholen Sie alle diese Schritte, bis eine vollständige User Story implementiert wird. Wenn die vorherigen Inkremente in eine vollständige User Story integriert werden, fügen Sie Tests zur Überprüfung der vollständigen Story hinzu.

8. Checken Sie den Implementierungscode und die Komponententests ein.

Wenn Sie die Vorteile frühzeitig verwendeter Methoden nutzen möchten, können Sie zunächst manuelle Tests bzw. manuelle Akzeptanztests erstellen. Diese manuellen Tests können automatisiert werden, indem ein Test der codierten UI erstellt wird. (Weitere Informationen finden Sie unter Gewusst wie: Generieren eines Tests der codierten UI durch Aufzeichnen der getesteten Anwendung.) Integrationstests, bei denen das Komponententestframework in Visual Studio ALM verwendet wird, können ebenfalls erstellt werden, um die Funktionen zu überprüfen, die implementiert werden. Die Gruppen von Testfällen, die in der Frühphase der Iteration erstellt werden, werden zu einem frühen Zeitpunkt in der Iteration ausgeführt, um sowohl Funktionen zu überprüfen als auch Fehler zu suchen. Diese Testsammlungen und die Testfälle können während der gesamten Dauer des Projekts kontinuierlich als Regressionstests ausgeführt werden. Durch fortlaufende Ausführung der Tests stellen Sie sicher, dass die zu Beginn der Iteration gefundenen Fehler und die überprüften Funktionen nicht von späteren Änderungen im Projekt betroffen sind.

Verwenden von Komponententests für fortlaufende Integration

Die Komponententests, die bei Verwendung des Verfahrens der frühzeitigen Tests erstellt werden, sollten in der Testsammlung für den aktuellen Sprint und die aktuelle User Story organisiert werden. Diese Komponententests können auf den projektweiten Testplan hochgestuft werden und in regelmäßigen Abständen vom Team und im fortlaufenden Integrationszyklus ausgeführt werden. Komponententests dienen auch als Grundlage für Integrations-, Auslastungs- und Leistungstests.

Komponententests, die am Anfang erstellt werden, können als Teil fortlaufender Integration verwendet werden. Weitere Informationen zum Ausführen von Tests während eines Buildvorgangs finden Sie unter TestToolsTask-Aufgabe.

Verwalten von Testkonfigurationen mithilfe von Virtualisierung

Zum Ausführen von Komponententests können Sie einen Satz von Umgebungen erstellen, bei denen es sich um verwaltete Hyper-V-Images in Microsoft Test Manager handelt. Weitere Informationen zum Ausführen automatisierter Tests mit einem Testplan mithilfe von Microsoft Test Manager finden Sie unter TestToolsTask-Aufgabe.

Manuelle Tests im Vergleich zu automatisierten Tests

Automatisierte und manuelle Testfälle sind komplementär. Agile Teams bevorzugen eine größere Zahl von automatisierten Testfälle, da sie häufige oder fortlaufende Testläufe ermöglichen. Für eine fortlaufende Ausführung von Tests ist eine rasche und häufige Ausführung erforderlich, was sich mit manuellen Tests nur schwer verwirklichen lässt.

Es gibt mehrere Überlegungen, die angestellt werden sollten, wenn über das Verhältnis von manuellen zu automatisierten Testfällen entschieden wird.

Welchen Einfluss haben die Fähigkeiten in der Organisation auf die Verteilung von Testtypen?

Der Produktbesitzer leistet Hilfestellung bei der Definition der User Storys für das Projekt und sollte auch zur Erstellung von Akzeptanztests beitragen. Der Produktbesitzer erzeugt wahrscheinlich keine codierten Tests, besitzt jedoch ein umfassendes Wissen über die Geschäftssparte. Die Testfälle, die vom Produktbesitzer definiert werden, richten sich daher nach der Branchenterminologie und den Geschäftsregeln. Ein Produktbesitzer in einem Versandunternehmen gibt z. B. verschiedene Transportmöglichkeiten an, die vom Unternehmen unterstützt werden (z. B. Lastwagen-, Zug-, Luft- und Seetransport oder eine Kombination davon). Der Produktbesitzer kann anschließend mehrere Testfälle definieren, die in denen die unterschiedlichen Möglichkeiten berücksichtigt werden. Für diese manuellen Tests muss die Mindestanzahl von Tests angegeben werden, in denen die unterschiedlichen Optionen (in diesem Fall die Versandwege) berücksichtigt werden.

Teammitglieder, die Code erzeugen, können Tests der codierten UI erstellen, die auf den manuellen Tests basieren oder von jedem anderen Test unabhängig sein können. (Weitere Informationen finden Sie unter How to: Generate a Coded UI Test by Recording the Application Under Test) Tests der codierten UI müssen von Teammitgliedern unterstützt werden, die die Fähigkeit besitzen, Projektcode zu verwalten und zu entwickeln.

Wann sollten Sie manuelle Tests in automatisierte Tests konvertieren oder automatisierte Tests von Beginn an erstellen?

Sie können automatisierte Tests erstellen, wenn Sie davon ausgehen, dass Sie Tests wiederholt ausführen müssen, um die Stabilität des Codes aufrechtzuerhalten. Es ist wichtig, den Aufwand für die Erstellung von automatisierten Tests zu berücksichtigen, da der für die Automatisierung erforderliche Aufwand Teamressourcen beansprucht. Werden automatisierte Tests erstellt, wenn wenige Codeänderungen vorliegen, erhöht dies die Rentabilität, da weniger Teständerungen erforderlich sind. Allerdings ist es sinnvoll, die Automatisierung frühzeitig zu erstellen, da dadurch Probleme in der Logik sowie im Entwurf erkannt werden. In beiden Fällen müssen die Ressourcen, die zur Unterstützung des automatisierten Testcodes erforderlich sind, berücksichtigt werden.

Wenn Sie entschieden haben, dass ein Satz Tests automatisiert werden muss, gehen Sie möglichst schnell zu vollständiger Automatisierung über, da zu den Vorteilen der Automatisierung auch die Verwaltung der Stabilität des Codes gehört. Die Stabilität und die Anzahl der Fehler, die beim Schreiben der Automatisierung gefunden werden, beeinflussen den Aufwand für die Fertigstellung der Automatisierung. Letzten Endes muss bei der Aufteilung in manuelle und automatisierte Tests die Priorisierung der Testarten bedacht werden, die während der Dauer des Projekts erstellt und ausgeführt werden müssen.

Welche Testtypen werden automatisiert?

Komponententests

Mit Komponententests werden Funktionen in Code oder durch einen Prozess wie die testgesteuerte Entwicklung überprüft. Komponententests sind wichtig, da sie dazu beitragen, dass die Stabilität und die Abhängigkeiten im Code aufrechterhalten werden. Tendenziell sind mit der testgesteuerten Entwicklung bessere Entwürfe mit Abhängigkeiten und einer sinnvollen Ebenendefinition möglich, da sich dadurch leichter nachvollziehen lässt, wie der Entwurf aus Sicht des Codebenutzers aussieht.

Auslastungstests

Sie können Auslastungstests erstellen, die auf vorhandenen automatisierten Testfällen basieren, oder Sie können Tests erstellen, die bestimmte Typen von Lasten in Anwendungen oder Diensten generieren. Weitere Informationen zum Verwenden von Test-Agent-Controllern und Test-Agents zur Generierung simulierter Testlasten finden Sie unter Gewusst wie: Ausführen eines Test-Controllern und Test-Agents.

Weitere Informationen zu Auslastungstests mit Visual Studio ALM finden Sie auf der folgenden Seite auf der Microsoft-Website: Understanding Load Tests.

Fortlaufende Integrationstests

Sie können fortlaufende Integration mit Visual Studio ALM verwenden, um sicherzustellen, dass Code bei jedem neuen Entwickeln und Einchecken mit dem vorhandenen Code kompatibel ist. Fortlaufende Integration ist im Zuge des Wachstums von Team und Codebasis wichtig. Sie können einen Buildtyp definieren, der Testparameter enthält, und angeben, welche Tests nach Abschließen des Buildvorgangs ausgeführt werden sollen. Weitere Informationen zum Definieren eines Builds, der Tests ausführt, finden Sie unter Definieren eines Builds mithilfe der Standardvorlage.

Welche Typen von Tests können automatisiert werden?

Konfigurationstests

Tests in mehreren installierten Umgebungen können eine sehr mühsame Aufgabe sein. Microsoft Test Manager bietet Möglichkeiten zur Ausführung von Testsammlungen auf anderen Konfigurationen mithilfe von virtuellen oder physischen Computern. Für weitere Informationen zum Ausführen von Tests und zum Erfassen von Daten in mehreren Umgebungen finden Sie unter Einrichten von Testcomputern zum Ausführen von Tests oder Sammeln von Daten.

Benutzeroberflächentests

Visual Studio ALM bietet die Möglichkeit, automatisierte Tests direkt für die Benutzeroberfläche zu erstellen. Weitere Informationen zum Erstellen von Tests der codierten UI finden Sie unter Gewusst wie: Erstellen eines Tests für codierte UI.

Installationstests

Sie können mit den Lab-Funktionen von Microsoft Test Manager eine Gruppe von Konfigurationen einrichten, mit denen überprüft werden kann, ob die Installationsprogramme für die Anwendungen erwartungsgemäß funktionieren.

Worin liegen die Einschränkungen für die Automatisierung?

Fähigkeiten des Teams

Für die Erstellung von Automatisierung muss ein Teil des Testteams das Schreiben von Code erlernen. Planen Sie die Lernkurve bei der Erstellung von Automatisierung und beim Entwurf des Testcodes ein. Gestalten Sie den Automatisierungscode ähnlich wie beim Produktionscode im Hinblick auf ihre Zielvorgaben, wie Verwaltbarkeit, einfache Komposition und Langlebigkeit.

Weitere Informationen zum Erstellen von automatisierten Tests mithilfe von Visual Studio Test Professional 2010 finden Sie unter Erstellen von automatisierten Tests.

Codeänderung

Code, der häufig geändert wird, ist ein bewegliches Ziel und hat Auswirkungen bis in den Testautomatisierungscode hinein, da dieser ebenfalls geändert werden muss. Vermeiden Sie diese überlappenden Effekte, indem Sie Testautomatisierungscode für Komponenten und Schnittstellen erstellen, die mit einer geringeren Wahrscheinlichkeit geändert werden.

Codeentwurf

Codeframeworks wie z. B. ASP.NET MVC und MVVM unterstützen Teammitglieder beim Schreiben von Code, der die Isolation besitzt, die zur Überprüfung verschiedener Bestandteile des Codes erforderlich ist. Code, der eng an die Benutzeroberfläche gebunden wird, ist schwierig zu testen, da er vom Benutzer möglicherweise eine Interaktion mit den Benutzeroberflächen-Steuerelementen erfordert.

Was sind die Vorteile manueller Testfälle?

Manuelle Testfälle bieten die folgenden Vorteile:

• Manuelle Tests ermöglichen dem Team das Erkennen von Fehlern durch Untersuchung.

• Manuelle Testfälle sind einfach zu definieren, da die Schritte in jeder beliebigen Abstraktion und Erfolg und Fehler durch beliebige Begriffe definiert werden können.

• Es ist sehr einfach, manuelle Testfälle in der Frühphase des Projekts zu erstellen, bevor Code geschrieben wird. Dies ist während der Definition von Akzeptanztests wichtig.

• Wenn Sie Visual Studio Test Professional 2010 verwenden, können Testfälle aus freigegebenen Schritten zusammengesetzt werden. Dadurch wird beim Definieren ähnlicher Tests Zeit gespart, und dem Team wird es ermöglicht, eine einzelne Version einer Teilmenge des Tests erneut zu verwenden. Die Verwendung freigegebener Schritte ist auch hilfreich, wenn Testfälle geändert werden, da durch Ändern der freigegebenen Schritten automatisch alle Testfälle geändert werden, für die die freigegebenen Schritte verwendet werden. Weitere Informationen zum Erstellen und Verwenden von freigegebenen Schritten finden Sie unter How to: Share Common Test Case Steps Using Shared Steps.

• Manuelle Testfälle können in der Frühphase des Projekts oder Sprints als Kommunikationsmittel dienen.

• Manuelle Testfälle können als Möglichkeit zur Dokumentation eines automatisierten Testfalls dienen, ohne dass jemand den Code überprüft.

• Wenn Sie Visual Studio ALM verwenden, kann durch Ausführen von manuellen Tests Codeabdeckungsmetrik erfasst werden.

Was sind die Nachteile manueller Testfälle?

Manuelle Testfälle haben die folgenden Nachteile:

• Die Definition von Erfolgskriterien kann sich kompliziert gestalten, da sie von der Perspektive und der Sprache abhängt, die in der Definition des Tests verwendet werden. Sprache kann teilweise unterschiedlich interpretiert werden, was Fehler nach sich ziehen kann.

• Die Ausführung von Testsammlungen, die manuelle Testfälle einschließen, erfordert, dass eine Person, die Testschritten direkt mitverfolgt und die Ergebnisse meldet. Dieser Prozess kann viel Zeit in Anspruch nehmen und erfordert daher möglicherweise entweder eine größere Anzahl von Teammitgliedern für die Ausführung von Tests oder einen längeren Zeitraum für das Ausführen der Testsammlung. Mit Visual Studio Test Professional 2010 kann das Team "manuelle Tests beschleunigen", in denen Aktionen während Tests aufgezeichnet werden, die dann in zukünftigen Testläufen ausgeführt werden können.

• Abhängig von der Stabilität des Codes unterscheidet sich der allgemeine Aufwand für die Ausführung der Tests. Daher kann das Ausführen manueller Tests den Arbeitsfortschritt des Teams beeinflussen.

• Der größte Nachteil besteht darin, dass manuelle Tests anfällig für menschliche Fehler bei der Fehlererkennung sind. Tester haben den Fehler direkt vor Augen, ohne ihn jedoch zu erkennen.

Was sind die Vorteile automatisierter Testfälle?

Automatisierte Testfälle bieten die folgenden Vorteile:

• Automatisierte Tests tragen zur Wahrung der Stabilität bei und ermöglichen das Auffinden von Regressionen, die aufgrund von Codeänderungen auftreten können.

• Automatisierte Tests können unbeaufsichtigt ausgeführt werden.

• Automatisierte Tests sind Software und können aus anderem wieder verwendbarem Code entworfen und zusammengesetzt werden. Dadurch werden automatisierte Tests flexibel und verwaltbar.

• Automatisierung kann auf mehreren Konfigurationen mithilfe von Microsoft Test Manager ausgeführt werden.

• Codeabdeckungsmetrik kann erfasst werden, wenn automatisierte Tests ausgeführt werden.

Was sind die Nachteile automatisierter Testfälle?

Nachteile von automatisierten Testfällen:

• Besondere Bedingungen müssen berücksichtigt werden und mit Code implementiert werden. Wenn die Automatisierung erstellt und ausgeführt wird, werden zusätzliche Bedingungen bei ihrer Erkennung implementiert.

• Wenn Code geändert oder umgestaltet wird, treten möglicherweise Überlappungen auf, die einen entsprechenden Aufwand erfordern, um die betroffenen automatisierten Tests zu ändern.

• Möglicherweise wird die Motivation des Teams beeinträchtigt, wenn durch Codeänderungen viele Tests fehlschlagen. Wenn diese Tests als Flags verwendet werden, möchte das Team möglicherweise keine Flags auslösen.

• Möglicherweise entsteht ein falsches Sicherheitsgefühl, wenn alle Tests erfolgreich verlaufen, wenn die Testfälle nicht auf die richtigen Bedingungen getestet werden. Es ist wichtig, die Testsammlungen beizubehalten und sicherzustellen, dass sie die richtigen Bedingungen und die Ergebnisse überprüfen.

Melden der Testergebnisse

Aus einer agilen Perspektive ist das Melden und Abfragen von Team Foundation Server für den aktuellen Zustand der Qualität auf Grundlage von Fehlern oder der gesamten Metrik Teil der Feedbackschleife, die es dem Team ermöglicht, Iterationen von Code, Projektplan und Testplan auszuführen und Änderungen daran vorzunehmen. Weitere Informationen finden Sie unter Bericht "Testplanstatus".

Welche Testebenen sollten dem Team gemeldet werden?

Mit Visual Studio Test Professional 2010 und Team Foundation Server kann das Team den Status der Planung und des Ausführens von Tests nachvollziehen. Team Foundation Server speichert Testpläne, Testsammlungen, Testfälle, Testergebnisse und alle anderen zugeordneten Daten, die im Testverfahren generiert werden. Sie können den Prozess der Tests und der Qualitätskontrolle visuell darstellen, wenn Sie Microsoft Test Manager mit Berichterstellung kombinieren und die Arbeitsaufgabe Abfragen in Team Foundation Server ausführt. Sie können mithilfe von Microsoft Test Manager Fehler in einer Vielzahl von unterschiedlichen Zuständen abfragen. Fehler, die als von anderen Teammitgliedern behoben markiert wurden, befinden sich im Zustand "Gelöst". Sie können die behobenen Fehler mithilfe von nachfolgenden Builds überprüfen. Informationen dazu, wie Sie überprüfen können, ob ein Fehler behoben wurde, finden Sie unter Gewusst wie: Überprüfen der Behebung eines Fehlers mit Microsoft Test-Manager.