Get best of the week

Warum sind wir zu Selenide gewechselt, indem wir mehr als 200 neue Autotests geschrieben haben?

Hallo, ich bin ein Testautomatisierungstool für eines der Projekte eines großen Unternehmens. In diesem Artikel werde ich erklären, warum wir uns entschieden haben, von Serenity zu Selenide zu wechseln. Wir haben eine große Aufgabe, und obwohl das Ändern des technologischen Stapels einige Zeit in Anspruch nahm, hat es sich später mehr als bezahlt gemacht, indem das Schreiben von Tests beschleunigt und eine Regression durchgeführt wurde.

Bild

Bevor wir zum Punkt kommen, ein wenig über die Aufgabe als Ganzes.

Leider kann ich die Details des Projekts gemäß den Bestimmungen der NDA nicht offenlegen. In der Tat sind dies einige der Tools für ein Callcenter eines großen Unternehmens - Anrufweiterleitung, Trennung der Betreiber nach Anrufthema usw. in einer schönen Benutzeroberfläche. Die Schnittstelle ist übrigens nicht nur für Bediener vorgesehen, sondern auch für Controller, die ausgewählte Anrufe abhören und auswerten. Vor allem gibt es ein System zur Differenzierung von Rechten und ein Admin-Panel, mit dem Sie alle integrierten Funktionen konfigurieren können - von der Telefonie bis zu den Bewertungen, die den Controllern zur Verfügung stehen.

Das gesamte Funktionsvolumen ist in mehrere Projekte unterteilt: Telefonie, Benutzerpanel und Admin-Panel. Alle drei Projekte befinden sich in aktiver Entwicklung. Meine Aufgabe ist es, das Testen dieser Projekte im weiteren Sinne des Wortes zu automatisieren.

Für einige der entwickelten Funktionen gab es bereits automatische Tests, aber der Spezialist, der sie entwickelt hat, hat das Unternehmen verlassen, sodass eine gewisse technische Pflicht zur Automatisierung der Tests bestand. Insgesamt wurden ungefähr 50 Autotests geschrieben, aber die überwiegende Mehrheit von ihnen ist völlig veraltet, weil Die Funktionalität ist weit fortgeschritten. Daher bestand die Aufgabe zunächst darin, all dies zu aktualisieren.

Stapelaktualisierung


Bestehende Autotests wurden mithilfe der Serenity-Bibliothek geschrieben. Tatsächlich mussten sie erneut umgeschrieben werden, sodass es keinen Sinn machte, an den bestehenden Entwicklungen festzuhalten. Die Bibliothek selbst war mir vertraut, aber ich persönlich halte sie nicht für ein optimales Werkzeug. Nachdem ich den Arbeitsaufwand verstanden hatte, entschied ich mich von Anfang an, zu Selenide zu wechseln.

Selenid ist ein ziemlich beliebtes Werkzeug, für das es viele vorgefertigte Lösungen gibt. Einige der Funktionen von Selenide sind auch für Analoga verfügbar - Atlas, Selen, HTMLElements usw. Aber jeder von ihnen passte auf seine Weise nicht zu uns.

Selen ist die Basis von Selenid. Aber für unsere Zwecke ist es zu niedrig. Es macht keinen Sinn, das Rad neu zu erfinden, wenn es eine fertige Lösung gibt.

Atlas erschien vor kurzem. Es ist roh genug und hat keine Groovy-Unterstützung.
HtmlElements ist gut für alle, aber veraltet und wird nicht unterstützt. Es gibt auch JDI, aber es gibt Multithreading-Probleme.

Serenity, die zuvor für das Projekt verwendet wurde, war zu umständlich. Alles darin ist so miteinander verbunden, dass wir ein Dutzend Klassen neu schreiben mussten, um einen neuen Ereignishandler oder Interceptor hinzuzufügen (und dies führte nicht jedes Mal zum Erfolg). Außerdem konnte Surenity Allure, den aktuellen Branchen- und Unternehmensstandard für die Erstellung von Testberichten, nicht verbinden.

In Selenide ist aus Sicht der Automatisierung alles viel einfacher. Zum Beispiel müssen die Schritte nicht separat beschrieben werden - Anhängen an Methoden usw. Da die Allure-Unterstützung sofort verfügbar ist, werden alle Aktionen im Zusammenhang mit der Arbeit mit Webelementen automatisch in den Testbericht aufgenommen.

Natürlich unterstützt Selenide PageFactory, Page Object und PageElement. Dies macht den Code besser lesbar. Außerdem gibt es interne Erwartungen für den Moment, in dem das Element angezeigt wird. Es muss nicht explizit angegeben werden, dass Sie den Test einige Sekunden lang anhalten müssen, bevor Sie fortfahren (das Zeitlimit ist in den Konfigurationen festgelegt). Explizite Erwartungen existieren separat - Sie können das Zeitlimit für die erforderlichen Elemente in jedem Testschritt explizit neu definieren.

Praktischerweise verfügt Selenide über eine ganze Reihe verschiedener vorgefertigter Methoden.

Da ich zu Beginn des Übergangs von Serenity zu Selenide allein im Team war, bestand der zusätzliche Vorteil darin, dass ich bereits über ausreichende Erfahrungen mit Selenide und Groovy verfügte, sodass ich schnell vorgefertigte Lösungen implementieren und anschließend weniger Aufwand aufwenden konnte, um sie zu unterstützen.

Der Übergang war fast schmerzlos. Wir haben Selenide in Zusammenarbeit mit Allure implementiert. Mit Allure können Sie lesbare und sogar etwas schöne Berichte erstellen, die deutlich zeigen, welche Schritte mit welchem ​​Fehler gefallen sind. Standardmäßig können Sie Screenshots von Webseiten an Berichte anhängen. Wir fügen sogar ein Video des Laufs, den Quellcode der Seite, die Protokolle des Browsers und den Webtreiber hinzu.

Das Migrieren vorhandener Tests erforderte einen minimalen Aufwand. Was Serenity hat, was Selenide hat, sind PageObjects mit @ FindBy-Annotationen. Serenity und Allure verwenden dieselben Step-Annotationen. Ich musste das Modell aktualisieren, die Verschachtelung der Elemente ineinander, die Reihenfolge der Aufrufe der Testschritte. Einige Tests wurden vollständig gelöscht, andere wurden von Grund auf neu geschrieben, und irgendwo genügte es, nur die Locators zu aktualisieren. Tatsächlich ist das Verschieben zu einer trivialen Aufgabe geworden, mit der die meisten Benutzeroberflächenautomaten beim Entwerfen einer Webanwendung konfrontiert sind.

Test Update


Nach der Aktualisierung des technologischen Stacks nahmen sie die Tests selbst auf. Ein Teil dieser Arbeiten wurde übrigens bereits im Rahmen des Übergangs zu einem neuen Stack abgeschlossen.

Angesichts der akkumulierten Verzögerung hinter der Funktionalität von Projekten müssten sie ohnehin noch neu geschrieben werden - dies ist zeitlich rentabler, als nach Inkonsistenzen in einem solchen Codevolumen zu suchen.

Insgesamt wurden derzeit etwa 220 Autotests sowohl für das Front-End als auch für das Back-End geschrieben. Der Schwerpunkt bei der Weiterentwicklung liegt auf dem Backend, da die meisten Funktionselemente im Frontend bereits an Autotests beteiligt sind. Gleichzeitig ändert es sich ständig. Je mehr Tests im Front-End erscheinen, desto mehr Kräfte müssen für ihre Unterstützung aufgewendet werden.

Mit unendlichen Zeitressourcen versuchen wir immer, die Anstrengungen auf das zu lenken, was es uns ermöglicht, die Arbeitskosten für den Support zu senken und die maximale Funktionalität abzudecken. Jetzt lag die Abdeckung der Autotests leicht über 50%.


Die umgeschriebenen Tests zu Selenide sind aufgrund der wiederholten Wiederverwendung des Codes kompakter und genauer geworden - alles dank der Funktionen der Bibliothek selbst.

Bei der Aktualisierung der Tests haben wir berücksichtigt, dass sie gleichzeitig ausgeführt werden müssen (in mehreren Threads). Tests wurden zuvor auf separaten virtuellen Maschinen ausgeführt. Durch den Übergang zu Selenide konnten wir die Aufgabe jedoch noch weiter parallelisieren und in mehreren Threads ausführen.

Grob gesagt erhöhte der Übergang zu einem neuen Framework die Anzahl der gleichzeitig gestarteten Threads von 3 auf 8 und die anschließende Optimierung von Tests auf bis zu 50. Infolgedessen werden 100 UI-Tests in nur 10 Minuten ausgeführt.


Multithreading ist übrigens ein weiterer Vorteil, für den wir uns für Selenide entschieden haben. Dies ist keine große Schicht Boilerplate, Sie schreiben ein Minimum an Code. Es gibt keine überflüssige Schrift, die Selen benötigt, um das Projekt für den Start vorzubereiten. Alles, was Sie zum Ausführen der Tests benötigen, ist bereits im Lieferumfang enthalten.

Parallel zum Aktualisieren und Schreiben neuer Tests führte ich Schulungen für die Mitarbeiter der Testabteilung durch, um ihnen zu helfen, vom manuellen zum Full-Stack-Test zu wechseln, sodass es im Automatisierungsregiment des Projekts ankam. Der verwendete Technologie-Stack hat eine niedrigere Einstiegsschwelle, und das Internet ist voll von Dokumentationen und Videos zur Lösung bestimmter Probleme. Einen Monat später kamen einige Tester hinzu, die Aufgaben im Zusammenhang mit der Automatisierung ausführen konnten.

Bereits als ganzes Team konnten wir Regressionstests optimieren. Wenn die Regression früher 7 Tage vom Team gedauert hat, werden jetzt die gleichen Aufgaben 4 Tage lang ausgeführt, d. H. Wir haben die Testzeit um fast das Zweifache reduziert.

Es stehen viele Szenarien bevor, die noch automatisiert werden müssen. Wir haben die Rauchtests fast vollständig automatisiert, aber jetzt haben wir zu den arbeitsintensivsten Testszenarien gewechselt. Dies wird dazu beitragen, die Rückgriffszeiten weiter zu verkürzen.

Natürlich werden wir eine Testinfrastruktur entwickeln. Pläne zur Einführung eines Mock-Servers. Jetzt testen wir alles auf einem realen Stand und generieren Testdaten. Es braucht Zeit und Ressourcen. Mit dem Mock-Server können Sie Autotests ohne diese vorbereitende Vorbereitung ausführen (wir haben über den Mock-Server für ein anderes Projekt geschrieben ).

Wir planen auch die Implementierung eines Autotest-Datensatzes, damit Sie ein TestRail-Skript basierend auf einem Werkstück schreiben können, das Sie erhalten, indem Sie direkt auf eine Oberfläche in einem Browser klicken. Am Ausgang erhalten wir eine Art Autotest-Prototyp.

Artikelautor: Yuri Kudryavtsev, Spezialist für automatisierte Softwaretests.

PS Wir veröffentlichen unsere Artikel auf mehreren Websites der Runet. Abonnieren Sie unsere Seiten auf VK , FB , Instagram oder dem Telegrammkanal , um mehr über alle unsere Veröffentlichungen und andere Maxilect-Nachrichten zu erfahren.

More articles:


All Articles