Browser-Protokolle bei Automatisierungstests

Die Protokollierung spielt eine wesentliche Rolle bei der Aufzeichnung des Verhaltens einer Anwendung. Es gibt verschiedene Arten von Protokollen, z. B. Protokollierung jeder Operation einer Anwendung, Protokollierung nur bei Auftreten eines Fehlers, Protokollierung kritischer Operationen eines Benutzers, vor allem, wenn Sie die Kontrolle darüber haben wollen, wer was zu Prüfzwecken tut.

Anwendungen können auf Code-Ebene für Debugging-Zwecke oder auf Benutzerebene für Audits und Register für verbotene Zugriffe protokolliert werden.

Bei Automatisierungstests ist das Führen von Protokollen in erster Linie wichtig, um Probleme zu erkennen, die nicht mit den Aktionen des Benutzers zusammenhängen, so dass sie entsprechend gemeldet werden können. Es gibt auch die Möglichkeit, die protokollierten Informationen anders zu behandeln, was sich auf die Fortsetzung des Testprozesses auswirkt und ihn im schlimmsten Fall unterbricht.

Untersuchung

Im folgenden Beitrag werden wir die Untersuchung von Protractor-Browserprotokollen für Automatisierungstests behandeln. Die ursprüngliche Idee ist es, Browserprotokolle für Tests auf Abruf zu haben. Dazu wird eine Funktion erstellt, die bei Bedarf aufgerufen wird, z. B. in Fällen, in denen die Konsole nach einer bestimmten Aktion oder zunächst beim Öffnen einer bestimmten Seite überprüft werden soll.

Nach der anfänglichen Untersuchung, bei der entweder ein manueller Ansatz (um die Browser-Protokolle direkt vom Browser-Objekt zu erhalten) oder die Verwendung eines spezialisierten Pakets in Betracht gezogen wurde, wurde die folgende Schlussfolgerung gezogen:

1. Die Verwendung des Pakets protractor-browser-logs;
2. Einbindung des Pakets in das Standard-Anwendungsmodul;
3. Verschiedene Szenarien für die Verwendung ausprobieren;
4. Verwendung des Pakets beforeEach/afterEach in den Funktionen und Suche nach möglichen Alternativen.

Die Funktion

CheckBrowserLogs ist die erste Funktion, die wir in den Helfern des Standard-App-Moduls einrichten. Sie ermöglicht uns die Überprüfung der Browserprotokolle. Wir verwenden diese Funktion auf eine andere Weise als die offensichtliche - nämlich innerhalb des afterEach-Blocks als:

Der zweite Codeschnipsel ist fast derselbe, aber in unserem Fall werden wir uns an den ersten halten, weil er am Ende einen viel saubereren Code liefert.

Die Protokolle werden durch Importieren der protractor-browser-logs initialisiert:

Dies ist das beforeEach, das wir für jeden Testfall initialisieren müssen, wenn wir die gewünschten Protokolle erhalten wollen. Wir müssen beforeEach verwenden, um die richtige Seite/das richtige Modul mit den richtigen Protokollen zu versorgen.

Szenarien

Im Ausgangsszenario rufen wir die Browser-Logs-Funktion bei Bedarf auf. Das heißt, wenn wir Fehler in der Konsole bemerken oder wenn der Test fehlschlägt, rufen wir die Funktion 'checking for logs' auf, die untersucht, welche Art von Problem in den ersten vier Zeilen des Testfalls aufgetreten ist.

Es gibt mehrere Sonderfälle der (falschen) Verwendung der Funktion.

Aufrufen der Funktion zu Beginn des Tests:

In diesem Beispiel gehen wir davon aus, dass wir, wenn wir die Funktion logs am Anfang des Testfalls einfügen, Protokolle für alle Tests erhalten (der Pfeil rechts).

FALSCH: In Wirklichkeit rufen wir die Logs auf, bevor der Test überhaupt begonnen hat (der linke Pfeil zeigt nach oben). Diese Option ist aus dem Kontext gerissen.

Aufrufen der Funktion in der Mitte des Tests:  

Dies ist ein Beispiel dafür, dass wir die Protokolle für den zuvor abgeschlossenen Abschnitt erhalten, bis zu dem Moment, in dem die Protokolle implementiert wurden (der Pfeil links).

Dies funktioniert NUR, wenn der Test auf der gleichen Seite bleibt und wir nicht die Seite wechseln. Wenn wir zum Beispiel auf google.com sind und auf mehrere Dinge klicken, die nicht zu einer anderen Seite weiterleiten, dann erhalten wir die Protokolle für alles. Wenn wir jedoch eine Suche durchführen und die Eingabetaste drücken, erhalten wir nur die Protokolle für die letzte Seite und nicht für die vorherige, in diesem Fall also die Protokolle für die Suche und nicht für die Aktionen, die wir auf google.com durchgeführt haben.

Geben Sie den Befehl am Ende des Tests:

In diesem Fall erhalten wir nicht die Protokolle für alle zuvor durchgeführten Aktionen, sondern nur die Protokolle für den letzten Befehl, der im Test vor dessen Ende ausgeführt wurde.

Anhäufung von Funktionen beim Wechsel zu einer anderen Seite:

Sie verstehen, worum es geht. Wir müssen mehrere Browserprotokolle verwenden, um festzustellen, wo genau das Problem im Test auftritt.

Die Funktion SOLLTE NICHT verwendet werden, wenn die dazwischen liegenden Zeilen Aktionen auf derselben Seite durchführen. Wenn jedoch zu verschiedenen Seiten navigiert wird, sollten je nach Anzahl der Weiterleitungen mehrere Aufrufe der Funktion erfolgen.

Beispiel

Schauen wir uns das folgende Beispiel an, das eines der komplexesten Szenarien für das Testen näher beleuchtet. Ein Testfall führt Prüfungen nach Aktionen auf 3 verschiedenen Seiten im folgenden Ablauf durch:

• Aktionen auf Seite 1;
• Navigieren zu Seite 2, Aktionen auf Seite 2;
• Zurück zu Seite 1 navigieren, Aktionen auf Seite 1;
• Navigieren zu Seite 3, Aktionen auf Seite 3;
• Zurück zu Seite 1 navigieren, Aktionen auf Seite 1.

Um die richtigen Protokolle zu erhalten, die in dieser User Journey angefordert werden, müssen wir Protokolle an verschiedenen Stellen eingeben - dreimal nach jeder Aktionssequenz auf Seite 1, einmal nach den Aktionen auf Seite 2 und einmal nach den Aktionen auf Seite 3.

Mit diesem Beispiel erreichen wir eine 100%ige Abdeckung und können so sicherstellen, dass wir die gewünschten Protokolle erhalten und vor allem, dass die Funktion fünfmal im selben Test importiert wird.