Fehlgeschlagene Testfälle beheben

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 Bezeichnung erst genauer definieren. Was also kann als fehlgeschlagener Testfall gesehen werden?

Debugger

Ein negativer Testfall

Ein Testfall, der das Fehlerverhalten der AUT überprüfen soll, wie z.B. das Erscheinen einer Fehlermeldung, wenn ein falsches Passwort eingegeben wird. Diese Art von Testfall ist also erfolgreich, wenn ein Fehler in der AUT gemeldet wird.
Maintenance Mode

Ein Testfall, der einen Defekt in der AUT aufdeckt

Eigentlich ein erfolgreicher Testfall, da das Aufdecken von Defekten ja eines der eigentlichen Ziele der Testautomatisierung ist. Sie sollten in Erwägung ziehen, solche Testfälle in Ihre Regressionstests aufzunehmen.
Ranorex Remote

Ein Testfall, der fehlschlägt, ohne dass der Grund hierfür in der AUT liegt

Die Art von Testfall, die wir in diesem Artikel behandeln werden.

Wenn ein Testfall fehlschlägt, muss zuerst bestimmt werden, ob Definition #2 oder #3 anwendbar ist. Liegt der Grund für den Fehlschlag in einem Defekt der AUT oder gibt es ein Problem mit dem Testfall an sich, z.B. in Form von ungültigen Testdaten, einer fehlerhaften Testumgebung oder Änderungen in der AUT, die keine Defekte sind? Nicht immer ist das direkt ersichtlich; Sie werden unter Umständen erst eine genauere Fehlersuche am Testfall durchführen müssen, bevor Sie sich eines AUT-Defekts sicher sein können.

Es kann auch verleitend sein, den Testfall einfach erneut durchlaufen zu lassen, um zu sehen, ob er dieses Mal erfolgreich ist. Allerdings ist ein Testfall, der manchmal erfolgreich ist und dann scheinbar grundlos wieder fehlschlägt, unzuverlässig. Daher ist es wichtig, das Problem ausfindig zu machen und es zu beheben, sodass Sie sich auf Ihre automatisierten Tests und ihre Ergebnisse verlassen können.

Debugging-gerechte Testläufe

In einem früheren Artikel in dieser Serie, Einfach wartbare Tests, gingen wir bereits auf verschiedene Best Practices zur Erstellung von stabilen Testfällen ein. Unter anderem sollten dazu Abhängigkeiten zwischen Testfällen möglichst vermieden werden, auf eine stabile Testumgebung geachtet werden und Testfälle entfernt werden, bei denen ein Fehlschlag absehbar ist (z.B. aufgrund von unbehobenen Defekten). Eine Empfehlung war außerdem, Testfälle so zu konfigurieren, dass bei einem Fehlschlag ein Screenshot erstellt wird.

Sie sollten auch sicherstellen, dass sich Ihr Testlauf bei Fehlschlägen richtig verhält. Ein fehlgeschlagener Testfall sollte den gesamten Testlauf nur dann abbrechen, wenn es auch wirklich Sinn ergibt – z.B. wenn die AUT gar nicht erst startet oder schon Smoke-Tests fehlschlagen. Ranorex Studio bietet verschiedene Optionen, um einen Testlauf auch nach einem Fehlschlag weiterlaufen zu lassen, z.B. 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). Außerdem ist es möglich, Testfälle automatisch erneut durchführen zu lassen. Mehr dazu finden Sie in unserem User Guide.

Ein weiterer wichtiger Punkt betrifft das Ausmaß des Reports. Er sollte sich nur auf tatsächliche Fehler und Fehlschläge konzentrieren. Der Report in Ranorex Studio bietet mehrere vordefinierte Reportlevels, wie z.B. Debug, Information, Warning und Success. Bei großen Testläufen kann es problematisch sein, Informationen mit diesen Reportlevels im Report zu inkludieren, da er aufgrund der großen Datenmengen unübersichtlich werden kann. Stattdessen kann es sinnvoll sein, nur Meldungen mit den Reportlevels Error und Failure zu inkludieren, um Probleme schneller zu erkennen.

Das Problem isolieren

Wenn viele Testfälle fehlschlagen, sollten Sie mit der Fehlersuche in der Testumgebung, dem Framework oder der AUT beginnen.

Environment

Umgebung

Häufig laufen z.B. benötigte Dienste nicht oder werden nicht als Administrator ausgeführt.
Test Framework

Framework

Beim Framework können z.B. Lizenzfehler oder falsche Konfiguration eines Remote Agents Probleme bereiten.
System Error

AUT

Stellen Sie sicher, dass die AUT korrekt vorbereitet wurde. Das schließt ortsgebundene Systemeinstellungen, falsche Browserversionen oder auch eine andere Systemsprache ein. Auch ausstehende Aktualisierungen des Betriebssystems können die UI blockieren.
Wenn der Großteil Ihrer Testfälle erfolgreich ist, dann liegt das Problem wahrscheinlich eher bei den fehlgeschlagenen Testfällen selbst. Überprüfen Sie, ob es Fehlermeldungen gibt, die auf die Ursache hinweisen. Aber auch wenn keine ausgegeben wurden, sollten Sie nicht annehmen, dass ein Testfall zufällig fehlgeschlagen ist und ihn einfach erneut ausführen. Für jeden Fehlschlag gibt es einen Grund. Ein Testfall, der ohne ersichtlichen Grund erfolgreich ist oder fehlschlägt, ist „flaky“, also instabil. Nutzen Sie die folgende Checkliste, um dem Problem auf den Grund zu gehen.

Fehlersuche

Gehen Sie Schritt für Schritt die wahrscheinlichen Gründe für einen Fehlschlag durch:

  • Ist der Testfall an die aktuelle AUT-Version angepasst? Reflektiert der Testfall z.B. alle UI-Änderungen der letzten Version?
  • Sind die Testdaten korrekt und kann der Testfall darauf zugreifen?
  • Sind alle Parameter korrekt gesetzt?
  • Sind die erwarteten Ergebnisse gültig? Erwartet der Testfall ein einziges gültiges Ergebnis, während die AUT mehrere gültige Ergebnisse ausgibt?
  • Bestehen Abhängigkeiten zu früheren Testfällen, die das Problem verursacht haben könnten? Um das zu vermeiden, sollten Sie Ihre Testfälle so modular und unabhängig von einander aufbauen wie möglich. Genauer beschreiben wir das im Artikel Einfach wartbare Tests.
  • Wurde die Teardown-Sektion des letzten Testlaufs korrekt ausgeführt? Ist die AUT im korrekten Zustand, z.B. mit allen Browser geschlossen? Wurden alle im letzten Testlauf eingegebenen Daten wieder gelöscht und zurückgesetzt?
  • Besteht ein Problem im zeitlichen Ablauf? Eine Studie der University of Illinois at Urbana-Champaign zu instabilen Tests ergab, dass diese oft durch Asynchronitäten verursacht werden: Der Testfall schlägt fehl, weil die AUT das erwartete Ergebnis nicht schnell genug ausgibt. In diesen Fällen kann es notwendig sein, Wartezeiten zu konfigurieren, damit der Test nicht unnötig fehlschlägt. In Ranorex Studio kann das mit der Aktion Wait for gelöst werden. Details zu dieser Aktion können sie in unserem User Guide nachlesen.

Debugging-Tools verwenden

Nutzen Sie die Ihnen zur Verfügung stehenden Debugging-Tools. Ranorex Studio bietet mehrere Tools, um Ihnen bei der Fehlersuche behilflich zu sein:

Debugger

Debugger

Mit dem integrierten Debugger können Sie Breakpoints setzen und so schrittweise den fehlgeschlagenen Testfall durchgehen, um z.B. Variablen und Ausdrücke zu überprüfen.
Maintenance Mode

Maintenance Mode

Mit diesem Tool können Sie fehlgeschlagene Testfälle identifizieren und direkt vom Report aus beheben. Mehr dazu in unserem User Guide: Maintenance Mode.
Ranorex Remote

Ranorex Remote

Ranorex Remote eignet sich besonders zur Fehlerbehebung bei Fehlschlägen auf virtuellen Maschinen. Konfigurieren Sie damit den Testlauf so, dass er nur die Schritte bis direkt vor dem Fehlschlag ausführt und die AUT so in den richtigen Zustand versetzt. Dann verbinden Sie sich mit der virtuellen Maschine und können mit der Fehlersuche beginnen, wie beschrieben im Artikel How to Reconstruct Failed Test Cases in CI Systems.
Nehmen Sie sich konsequent die Zeit, Ihre fehlgeschlagenen Testfälle zu beheben. Sie werden dadurch Ihre Fähigkeiten verbessern und Ihre Tests werden noch zuverlässiger werden.
Steigen Sie direkt in die Testautomatisierung ein mit unserer kostenlosen 30-tägigen Testversion: