Einleitung Auch wenn Testfälle sorgfältig mit Stabilität und Wartbarkeit im Hinterkopf erstellt wurden, können sie dennoch fehlschlagen. Was genau wir unter einem Fehlschlag im Zusammenhang mit Testautomatisierung verstehen, müssen wir angesichts der Verwendung dieser...
Eine der größten Herausforderungen der Testautomatisierung sind Wartungsarbeiten, die sich aus UI-Änderungen ergeben. Ebenfalls herausfordernd ist die Identifizierung und Verbesserung sogenannter „flaky Tests“, also instabiler Tests, die mal erfolgreich sind, mal fehlschlagen, und das obwohl sich am Code nichts geändert hat. In diesem Artikel beschreiben wir verschiedene Zugänge zur Testfallgestaltung, zum Coden und zur Testausführung, die dabei helfen sollen, diese Herausforderungen zu bewältigen und den Wartungsaufwand zu verringern.
Testfallgestaltung
Zuerst entscheiden, WAS getestet wird, dann WIE es getestet wird
Ein gut strukturierter Testfall wird weniger Wartungsaufwand mit sich bringen.
Identifizieren Sie zuerst alle Funktionen, die getestet werden sollen. Dann brechen Sie jeden Test für diese Funktionen auf eine Reihe von einfachen Schritten herunter, mit einer klaren Definition des erwarteten Ergebnisses. Erst dann sollten Sie entscheiden, welche Tests manuell und welche automatisiert ausgeführt werden sollen. Mehr Informationen dazu finden Sie im ersten Artikel dieser Serie, in dem behandelt wird, welche Testfälle automatisiert werden sollten.
Testfälle dokumentieren
Vollständige Dokumentation von Testfällen trägt zu gut strukturierten Testfällen bei, da so für alle die Vorbedingungen, auszuführenden Schritte und erwarteten Ergebnisse nachvollziehbar und überprüfbar sind. Testfallvorlagen oder Testmanagementtools wie TestRail sind nützliche Hilfsmittel zur Erstellung von Testfalldokumentation.
Testfälle einfach halten
Idealerweise sollte ein Testfall eine einzige Funktion überprüfen und nur aus einem einzigen definierten Grund fehlschlagen. Komplexe Testfälle neigen eher zu Instabilität. Wenn ein Testfall viele Schritte umfasst, kann es sinnvoll sein, die Aktionen auf zwei oder mehr Testfälle aufzuteilen.
Standardisierte Namensgebung
Die Namen von UI-Elementen und Testobjekten sollten selbsterklärend sein. Wenn zusätzliche Kommentare nötig sind, um einen Testfall oder -schritt zu dokumentieren, dann kann das auf zu große Komplexität hindeuten.
Coden
Modulare Strukturen
Ein Testfall sollte unabhängig von anderen ausführbar sein. Testfälle sollten also so wenig wie möglich von den Ergebnissen vorhergehender Testfälle abhängig sein. Zum Beispiel sollte ein Testfall für den Zahlungsprozess eines Webshops nicht von einem vorhergehenden Testfall abhängig sein, der prüft, ob das Hinzufügen von Artikeln zum Warenkorb funktioniert. Voneinander unabhängige Testfälle erleichtern die Wartung und ermöglichen es Ihnen außerdem, von paralleler bzw. verteilter Ausführung zu profitieren. Wenn eine Abhängigkeit allerdings unvermeidlich ist, verwenden Sie die verfügbaren Features Ihres Testautomatisierungsframeworks, um sicherzustellen, dass alle Testfälle in der richtigen Reihenfolge ausgeführt werden.
Robuste Tests
Tests, die auch bei UI-Änderungen weiterhin funktionieren, sind einfacher zu warten. Verlassen Sie sich daher nicht auf Bildschirmkoordinaten zur Erkennung von UI-Elementen. Bei Webanwendungen sollten Sie sich außerdem weder auf die HTML-Struktur der Seite, noch auf dynamische IDs verlassen. Idealerweise sollten die UI-Elemente Ihrer Anwendung schon in der Entwicklung mit einzigartigen IDs versehen werden. Das vereinfacht die Objektauffindung und macht Tests robuster. Leider kann dem aber nicht immer nachgekommen werden. Deswegen wendet unser Objekterkennungstool Ranorex Spy automatisch Best Practices bei der Identifizierung von UI-Elementen an, um Ihre Tests so robust wie möglich zu gestalten.
Testgliederung nach Funktionsbereichen
Gliedern Sie Ihre Testfälle nach dem Funktionsbereich der AUT, den sie abdecken. Das erleichtert die Aktualisierung von verwandten Testfällen, wenn ein Funktionsbereich von Änderungen betroffen ist. Außerdem können Sie so Teilregressionstests für diesen Funktionsbereich ausführen. In Ranorex Studio können Sie wiederverwendbare Codemethoden erstellen und in einer Bibliothek speichern. Dort können Sie die Methoden einer Sammlung für einen bestimmten Funktionsbereich hinzufügen. Sowohl Methoden als auch Sammlungen können mit Beschreibungen versehen werden, die in der Bibliothek sichtbar sind und Testern dabei helfen, die richtige Methode auszuwählen.
Kein Kopieren von Testcode
Wiederholen Sie nicht dieselben Schritte in mehreren Tests. Sammeln Sie sie stattdessen in wiederverwendbaren Modulen. Sie sollten z.B. nur ein Modul haben, das Ihre AUT startet. Dieses können Sie dann in anderen Testfällen wiederverwenden. Falls sich dann am Startprozess der AUT etwas ändert, müssen Sie nur das Originalmodul aktualisieren. Mit seiner Unterstützung von schlüsselwortgetriebenen Tests, lokalen und globalen Parameters und Bedingungen eignet sich Ranorex Studio besonders zur einfachen Erstellung von ausgefeilten Testfällen basierend auf einzelnen, wiederverwendbaren Testmodulen.
Testschritte und Testdaten trennen
Schreiben Sie Testdaten nicht direkt in Ihren Code. Verwalten Sie sie stattdessen in einer externen Tabelle oder Datenbank und referenzieren Sie dann diese über Variablen und Parameter. Mehr zu datengetriebenem Testen finden Sie im Ranorex User Guide.
Source Control verwenden
Entwickler nutzen Source-Control-Tools wie Git, Subversion und Microsoft TFS, um gemeinsam Code zu entwickeln und gegebenenfalls einfach auf frühere Versionen zurückzufallen. Wenn möglich sollten Sie zur Verwaltung Ihres Testcodes dasselbe Source-Control-System wie zur Anwendungsentwicklung verwenden.
Ausführung
Ensure that your test environment is stable.
Unzuverlässige Server oder Netzwerkverbindungen können zu Testfehlschlägen führen. Ziehen Sie die Verwendung von Mockservern in Betracht, um Fehlerpotential zu eliminieren, das nicht mit der AUT zusammenhängt.
Setup- und Teardown-Prozesse verwenden
Verwenden Sie Setupprozesse, um Vorbedingungen für Tests zu verwalten und so sicherzustellen, dass die AUT im gewünschten Zustand für die Testausführung ist. Ein Setupprozess umfasst normalerweise: Start der AUT, Login, Laden der Testdaten und andere für den Test nötige Vorbereitungen. Verwenden Sie Teardownprozesse, um die AUT zum Ausgangszustand für den nächsten Testlauf zurückzusetzen, bspw. durch Bereinigung der AUT von allen eingegebenen Testdaten.
Fail-Fast
Fail-Fast ist ein Schlüsselkonzept in der Testgestaltung. Es besagt, dass Fehlschläge nur so viel Zeit in Anspruch nehmen sollten wie nötig. Wenn also ein ernsthaftes Problem vorliegt, bei dem ein Anhalten des Tests vorgesehen ist, sollte dieses sofort identifiziert und berichtet werden, anstatt den Test noch weiter mit dem Fehler laufen zu lassen. Setzen Sie außerdem vernünftige Werte für Zeitbeschränkungen, damit Ihr Test nicht ewig nach unauffindbaren UI-Elementen sucht.
Fehlschlag nur wenn nötig
Ihr Test sollte nur dann als Ganzes fehlschlagen, wenn dies nötig ist. Einen Test bspw. nach nur einem Fehler zu stoppen kann wertvolle Zeit verschwenden. Außerdem erfahren Sie so nicht, ob die anderen Testfälle durchgelaufen wären. Zu diesem Zweck stellt Ihnen Ranorex Studio neben dem einfachen Stoppen des Tests noch drei weitere Optionen betreffend Fehlerverhalten zur Verfügung: continue with iteration (weiter mit nächster Iteration), continue with sibling (weiter mit nächstem Testfall auf gleicher Ebene) und continue with parent (weiter mit nächstem Testfall auf übergeordneter Ebene). Mehr dazu finden Sie im Ranorex User Guide.
Erwartete Fehler isolieren
Führen Sie nur jene Tests aus, von denen Sie erwarten, dass sie erfolgreich sein werden. Tests, die einen Defekt abdecken, der noch nicht behoben ist, sollten aus dem Haupttestlauf entfernt werden und separat ausgeführt werden. Dadurch lässt sich einfacher erkennen, ob im Haupttestlauf Probleme vorhanden sind. Ebenso sollten Sie auch mit instabilen Tests vorgehen. Testen Sie diese dann manuell.
Screenshots aufzeichnen
Konfigurieren Sie Ihre automatisierten Tests so, dass Sie Screenshots aufzeichnen und verwenden Sie das Reporting, um detaillierte Informationen zur Fehlerbehebung zu erhalten. Ranorex Studio bietet einen sogenannten maintenance mode, der es Ihnen erlaubt, einen Testlauf zu pausieren, um Fehler zu diagnostizieren und direkt zu beheben. In diesem Screencast können Sie den Maintenance Mode in Aktion sehen:
Folgen Sie den Tipps aus diesem Artikel, um den Wartungsaufwand für Ihre Testfälle niedrig zu halten. Das wird Ihnen auch dabei helfen, die Stabilität Ihrer Tests zu erhöhen und Fehler einfacher ausfindig zu machen und zu beheben.
Related Posts:
10 Best Practices: #6 Der Umgang mit fehlgeschlagenen Testfällen
Finden Sie heraus, wie Sie durch konsequente Behebung von fehlgeschlagenen Testfälle Ihre Fähigkeiten verbessern und Ihre Tests noch zuverlässiger werden.
10 Best Practices: #7 Integration in CI-Pipelines
Automatisierte Tests erlauben die Einhaltung kurzer Entwicklungszyklen. Hier finden Sie Best Practices für Tests in einer CI-/CD-/DevOps-Umgebung.
10 Best Practices: #1 Was soll man automatisieren?
Erfahren Sie in unserem ersten Artikel in der Serie „10 Best Practices“, welche Tests automatisiert werden sollten, welche nicht und welche eine Herausforderung darstellen.