Fixieren von Selen in Ihrer CI / CD-Pipeline

Das kontinuierliche Ausführen automatisierter Tests mag wie ein Kinderspiel erscheinen. Ein CI-System ist der Schlüssel, um agilen Entwicklungsteams einen sofortigen Einblick in den Zustand ihrer Anwendungen zu geben. Wenn automatisierte Tests bestanden werden, ist die Anwendung fehlerfrei. Wenn die Tests fehlschlagen, ist die Anwendung in irgendeiner Weise defekt. Oder ist es?

Die unglückliche Realität ist, dass automatisierte Tests uns nicht immer ein solches Vertrauen geben, insbesondere wenn wir Selenium-Tests durchführen. Selentests können aus vielen verschiedenen Gründen fehlschlagen, unabhängig davon, ob die Anwendung in irgendeiner Weise beschädigt ist oder sich geändert hat. Diese Probleme sind schön detailliert in ein vorheriger Blog-Beitrag. Hier werde ich erklären, wie die CI / CD-Pipeline geändert wird, um diese Probleme automatisch zu beheben und das Vertrauen in die Testergebnisse des CI-Systems zu verbessern.

Selen CI Trauer

CI / CD verstärkt Selen-Testprobleme. Schauen wir uns an, wie das passiert. Erstens führt die Entwicklung zu einigen Codeänderungen. Das CI-System erkennt die Änderung und löst die Build-Pipeline aus. Module werden kompiliert, Komponententests ausgeführt und bestanden (yay!), Und dann wird die Anwendung für die Bereitstellung gepackt. Die Bereitstellungspipeline wird als Nächstes ausgelöst, indem eine Testumgebung bereitgestellt, die zu testende Anwendung bereitgestellt und anschließend die Integrationstests gestartet werden, von denen viele mit Selenium geschrieben wurden. Nicht alle Selen-Tests bestehen. Zu diesem Zeitpunkt benachrichtigt das CI-System verschiedene Personen per E-Mail über die Testfehler. Diese Personen reagieren und verbrennen manchmal viel Zeit mit der Untersuchung und Fehlerbehebung. Produktbesitzer, Manager und andere interessierte Parteien sehen die Fehler auch auf ihren Dashboards, die ihre Aufmerksamkeit von anderen Dingen ablenken. Wenn man weiß, dass die Selentests selbst instabil sind, wie kann man dann darauf vertrauen, dass CI / CD eine echte Regression oder einen echten Defekt gemeldet hat? Wie viel Zeit wird für die Fehlerbehebung bei Fehlalarmen verschwendet?

Das einfache Verbessern von Selentests kann nicht trivial sein und manchmal Versuch und Irrtum beinhalten, insbesondere wenn Probleme zeitweise auftreten oder schwer zu reproduzieren sind. Von einem Build zum anderen gibt es Fehler, die sich verschieben können, wenn kein einziger Test schuld ist. Dies können systemische oder umweltbedingte Probleme sein, die kommen und gehen. Das CI-System kann VM- oder Cloud-basierte Executoren mit inkonsistenten Leistungsmerkmalen verwenden. Tests werden ausgeführt und geben Entwicklerarbeitsstationen weiter, schlagen jedoch in der CI-Automatisierung fehl. Klingt bekannt?

Selen CI gelöst

Parasoft Selenic wurde entwickelt, um solche Herausforderungen zu bekämpfen. Selenic automatisiert die Analyse und Korrektur von Selenium-Testproblemen, bietet Korrekturen oder Einblicke in diese Probleme und stellt diese Ergebnisse zur Verfügung, sobald Menschen von ihrem CI-System benachrichtigt werden. Die Last wird auf das CI-System verlagert, weg von den Menschen, die auf Benachrichtigungen aus dem CI-System reagieren. Mit nur zwei einfachen Schritten können Sie den Prozess der Korrektur von Selenium-Tests als Teil der CI / CD-Pipeline mithilfe von Parasoft Selenic automatisieren.

Injizieren Sie den Selenic Agent

Um Parasoft Selenic zu integrieren, nehmen Sie eine einzeilige Änderung an Ihrem vorhandenen Testausführungsskript vor. Angenommen, ich habe einen Maven-Ausführungsschritt in der Pipeline, der meine Java-basierten Selenium-Tests steuert. Normalerweise spezifiziere ich zwei Maven-Ziele, "sauber" und "test", die als Befehlszeilenargumente an Maven übergeben werden. Hier fügen Sie nur ein zusätzliches Maven-Befehlszeilenargument hinzu:

-DargLine = -javaagent: $ {SELENIC_HOME} /selenic_agent.jar=selfHealing=true,sessionId = $ {BUILD_TAG}

In Jenkins CI könnte dies ungefähr so ​​aussehen:

Der Selenic Agent wird jetzt in den Testausführungsprozess eingefügt, vorausgesetzt, Selenic wird an dem Speicherort installiert und lizenziert, auf den die Variable "SELENIC_HOME" verweist. Der Selenic Agent kann verschiedene Dinge tun, aber zu Teststabilisierungszwecken aktiviere ich nur die Selbstheilungsfunktion, mit der versucht wird, Selenium-Testprobleme im laufenden Betrieb zu identifizieren und zu beheben.

Eine Sache, die Sie sorgfältig prüfen sollten, ist, ob Ihre Selenium-Tests alle in einem Modul ausgeführt werden oder ob es Tests in mehreren Modulen gibt. Es ist üblich, dass Tests aus organisatorischen Gründen in mehrere Module aufgeteilt werden. Damit Selenic Informationen aus mehreren Testmodulen aggregieren kann, muss ein Argument "sessionId" konfiguriert werden. Im obigen Beispiel verwende ich "BUILD_TAG", eine vordefinierte Variable im Jenkins CI-System, die für diesen Zweck gut funktioniert. Unabhängig davon, welches CI-System Sie verwenden, empfehle ich, eine eindeutige Sitzungskennung unter Verwendung der von Ihrem CI-System bereitgestellten Variablen zu erstellen.

Nach dieser einzeiligen Änderung erkennt und korrigiert Selenic automatisch Teststabilitätsprobleme, wodurch jeder viel mehr Vertrauen in die vom CI-System veröffentlichten Testergebnisse hat. Es gibt jedoch noch eine weitere selenische Komponente, die ich zur Integration empfehle.

Führen Sie den Selenic Analyzer aus

Woher wissen wir, welche Probleme Selenic gefunden oder behoben hat? Gibt es Änderungen, die ich an den Selen-Tests vornehmen sollte, um die Probleme zu vermeiden, die Selenic findet? Um diese Informationen zu erhalten, führen Sie den Selenic Analyzer als weiteren Ausführungsschritt in der Pipeline aus. Dies ist eine zweite einzeilige Änderung, die jedoch immer noch trivial ist:

java -jar $ SELENIC_HOME / selenic_analyzer.jar -report target / selenic-reports -sessionId $ {BUILD_TAG}

In Jenkins CI könnte dies ungefähr so ​​aussehen:

Der Selenic Analyzer sammelt Informationen, die zuvor vom Selenic Agent protokolliert wurden, führt eine zusätzliche Analyse der Daten durch und erstellt dann einige Berichte, die dann vom CI-System archiviert werden können. Standardmäßig verarbeitet der Analysator Informationen aus der letzten Sitzung. Aus Gründen der Robustheit empfehle ich jedoch, das Argument "-sessionId" explizit mit demselben Wert zu konfigurieren, der zuvor bei der Konfiguration des Selenic Agent verwendet wurde.

Der Selenic Analyzer schreibt die Berichte standardmäßig in das aktuelle Arbeitsverzeichnis. Um die Archivierung der Berichte zu vereinfachen, sollten Sie jedoch ein Argument "-report" hinzufügen, um Selenic anzuweisen, Berichte in einen Ordner "selenic-reports" im Build-Ausgabeverzeichnis Ihres Projekts zu schreiben. Danach würden Sie einen weiteren Schritt in der Pipeline hinzufügen, um "target / selenic-reports / **" zu archivieren:

Die Berichtsdateien sind jetzt für alle Benutzer des CI-Systems verfügbar. Im Fall von Jenkins CI sind Berichte bequem über stabile URLs zugänglich:

http://{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.html

http://{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.json

Die erste URL verweist auf den Selenic HTML-Bericht, der direkt in einem Webbrowser angezeigt werden kann. Die zweite URL bezieht sich auf den JSON-Bericht, den Entwickler dem Selenic IDE-Plugin zur Verfügung stellen können, um die Empfehlungen aus dem letzten automatisierten Testlauf zu importieren.

Weitere Überlegungen

Selenic bietet viele andere Optionen, die Sie je nach Testumgebung und anderen spezifischen Anforderungen aktivieren können.

Selenic zeichnet Daten für jede Testsitzung auf. Die aufgezeichneten Daten dienen als Wissensbasis, sodass Selenic im Laufe der Zeit lernen und bessere Entscheidungen und Empfehlungen zur Selbstheilung treffen kann. Standardmäßig werden diese Daten auf dem Computer gespeichert, auf dem der Test ausgeführt wird. Wenn Sie also über einen Pool von Ausführenden verfügen, möchten Sie, dass sich diese Daten in einem freigegebenen Ordner befinden, auf den alle Ihre Ausführenden zugreifen können. Der Datenspeicherort kann explizit konfiguriert werden, indem ein Parameter "data = {path}" an den Selenic Agent und ein Argument "-data {path}" an den Selenic Analyzer übergeben werden, wobei "{path}" ein Dateisystempfad ist ein freigegebener Ordner. Unter Windows kann dies ein UNC-Pfad wie \\ Hostname \ SharedFolder sein. Die aufgezeichneten Daten werden auch auf unbestimmte Zeit aufgebaut, sofern keine Einschränkungen bestehen. Dies kann schließlich zu einer hohen Festplattenauslastung führen. Eine Begrenzung der Anzahl aufgezeichneter Testsitzungen kann konfiguriert werden, indem ein Parameter "maxSessionDaysToKeep = {num_days}" an den Selenic Agent übergeben wird. "{Num_days}" ist die Anzahl der Tage, an denen Daten aufgezeichnet wurden, und nicht die Kalendertage. Mit anderen Worten, Selenic zählt keine Tage, an denen keine Testsitzungsdaten aufgezeichnet wurden. Dies ist hilfreich, wenn Sie Ihre Tests selten oder in inkonsistenten Intervallen ausführen oder Serverausfälle hatten, bei denen Sie einige Tage lang keine Tests ausgeführt haben.

Selenic kann auch so konfiguriert werden, dass zusätzliche Diagnoseinformationen auf verschiedenen Granularitätsstufen erfasst werden. Beispielsweise kann Selenic so konfiguriert werden, dass Screenshots für jede Selenium-Aktion oder nur für fehlgeschlagene Aktionen erfasst werden. Um Screenshots zu Testfehlern zu aktivieren, können Sie dem Selenic Agent den Parameter "Screenshot = Fehler" übergeben. Screenshots für Fehler sind im vom Selenic Analyzer erstellten HTML-Bericht verfügbar.

CI/CD + Selenic = ❤

Parasoft Selenic wurde entwickelt, um die agile Entwicklung mit Selenium als Teil von CI / CD zu beschleunigen. Entwickler und Tester können produktiver sein, weniger Zeit damit verbringen, Selen-Geister zu jagen, und mehr Zeit damit, an realen Dingen zu arbeiten. Steigern Sie mit Selen das Vertrauen in Ihre Selen-Testergebnisse. Laden Sie noch heute Ihre kostenlose Testversion herunter.