Mit diesem Artikel setzen wir eine Reihe von Veröffentlichungen fort, die beschreiben, wie wir in einem der wichtigsten LANIT-Projekte den automatischen Prozess des manuellen Testens (im Folgenden als Autotests bezeichnet) eines großen Informationssystems (im Folgenden als Systeme bezeichnet) automatisiert haben und was daraus entstanden ist.

Der zweite Teil der Veröffentlichung befasst sich hauptsächlich mit den Leitern der UI-End-2-End-Tests der Automatisierungsgruppen und der führenden Testautomatisierung. Hier finden sie spezifische Rezepte für die architektonische Organisation von Code und Deployment, die die massenparallele Entwicklung großer Testgruppen bei ständiger Variabilität der Testspezifikationen unterstützen. Dieser Teil enthält die vollständige Liste der für UI-Tests erforderlichen Funktionen mit einigen Implementierungsdetails sowie eine Liste der möglichen Überraschungen.

Hier finden Sie Teil 1. (Warum brauchten wir Automatisierung? Organisation des Entwicklungs- und Verwaltungsprozesses. Organisation der Nutzung)

Quelle

Architektur- und Technologie-Stapel

Allgemeine Struktur des Systems und seiner Umgebung - High Level Design

Die wichtigsten im Projekt verwendeten Technologien und Bibliotheken:

• JavaSE8 & maven & JUnit - Entwicklungsstapel;
• Selen - eine Bibliothek zur Automatisierung der Aktionen eines Webbrowsers;
• Selenide - ein Add-On für Selenium mit einer eleganten API, die die Interaktion mit dem Browser und den Seitenelementen erheblich vereinfacht.
• Selenoid & GGR - Implementierung von Selenium Grid und eines Lastenausgleichs für die Ausführung von Tests auf einem CI-Server + vorkonfigurierte Container mit Browsern;
• Yandex Allure - für Berichte auf dem CI-Server.

In den folgenden Diagrammen ist ein allgemeines Diagramm der Komponenten der Autotests und der Selenoid-Infrastruktur mit Erläuterungen dargestellt:

Autotests-Framework
Anwendung zur Automatisierung der Regression von Benutzeroberflächen.
Lieferung im Quellcode. Verwendet JUnit4

run.properties
Konfigurationsdatei zum Ausführen von Autotests. Definiert den bedingten Namen des verwendeten Standes und die Art der Ausführung - lokal oder über externe Container und andere Variablen.

Allure Plugin
Eine spezielle ausführbare Datei, die auf einem Bamboo-Server installiert wird.
Erstellt einen Test-HTML-Bericht, auf den über einen Bamboo-Server zugegriffen werden kann.

Testbericht
Test-HTML-Bericht über Bamboo Server verfügbar.
Es wird auf dem Bamboo-Server im Plan gespeichert, was zu einer separaten Registerkarte führt.

Bambus
Bietet den Start von Integrationstests im automatischen und manuellen Modus.
Speichert Testberichte im Allure-Format.

ggr-server
Server-Balancer von Selenoid-Servern.
Ermöglicht den Ausgleich von Anforderungen von Autotests (RemoteWebDriver) an mehrere Instanzen von Selenservern.

Docker
Docker-Server zum Ausführen von Selenoid-Server-Containern und -Browsern.

Selenoid-Server
Remote-Testserver
Ermöglicht den Start von Tests in speziellen Docker-Containern mit einem "kopflosen" Browser.
Führt Tests im parallelen Modus entsprechend der angegebenen Anzahl gleichzeitiger Threads durch.

Selenoid-ui
Server-Benutzeroberfläche zum Selenoid-Server.
Ermöglicht die direkte Überwachung des Testfortschritts über VNC.

Selenoid-Webtreiber
Ein spezialisierter Container mit einem headless Browser zum Ausführen von Remote-Tests.
Wird aus dem Selenoid-Repository bereitgestellt.

Gitlab
Speichert den Quellcode der Autotests-Anwendung.

Arbeitsschema

Das folgende Diagramm zeigt das allgemeine Schema des AutoTests-Dienstes auf der Entwurfsebene.

Installation und Bereitstellung

Autotests basieren auf vier Servern, von denen einer der Ausführungsserver ist und die anderen drei den Start von Headless-Browsern in Containern ermöglichen. Die aktuelle Leistung von Autotests bietet 60 simultane Streams und kann bei Bedarf erweitert werden.

Das aktuelle Bereitstellungsdiagramm ist im folgenden Diagramm dargestellt. Wenn Sie nicht mehr als 20 Browser gleichzeitig benötigen (Testthreads), ist es durchaus möglich, alles auf einen Server 12 Kernel + 24 RAM zu setzen. Wir begannen mit dieser Konfiguration, aber als die Anforderungen an die Leistung von Autotests zunahmen, stellten wir empirisch fest, dass die stabilste und kostengünstigste Konfiguration ein „typischer“ 12-Kernel + 24-RAM-Server ist.

Nach unserer Erfahrung sollte für Testsysteme mit einer Webschnittstelle auf Angular die akzeptable Konfiguration des Containers mit dem Browser der Kernelboden + GB Arbeitsspeicher sein. Eine kleinere Konfiguration verlangsamt den Browser und kann sogar zu nicht identifizierbaren Abstürzen führen.

Code Struktur und Organisation

Bevor ich zur Struktur und Organisation des Codes übergehe, werde ich noch einmal die Richtlinien und Einschränkungen auflisten, die letztendlich die Richtung für die Entwicklung der Architektur bestimmt haben:

• Eine große Anzahl komplexer End-to-End-Testskripte. Hohe Entwicklungsintensität;
• hohe Volatilität der Testszenarien (deren Variabilität);
• hohe kontinuierliche Geschwindigkeit der Szenariobereitstellung (Entwicklung und Überarbeitung);
• Erstqualifikation von Entwicklern von Autotests;
• Hohe geplante Entwicklung von Entwicklern.

Auf der Grundlage des Vorstehenden sind die wichtigsten architektonischen Treiber die folgenden:

• Sicherstellung eines stark strukturierten Codes für einfache Lesbarkeit und Verwaltbarkeit;
• maximale Trennung und Isolation zwischen Anwendungsimplementierungen spezifischer Tests und übergreifenden Klassen gemeinsamer Funktionalität;
• Maximale Reduzierung der erforderlichen Abhängigkeiten zur Erleichterung des Wechsels;
• Angemessene Wiederverwendung von Code auf der Ebene übergreifender Klassen mit akzeptabler möglicher Code-Duplizierung auf der Ebene unabhängiger Testgruppen (funktionale Subsysteme), um Abhängigkeiten zu verringern und Konflikte auf Entwicklungsebene zusammenzuführen;
• Ablehnung komplexer Frameworks wie spring, aspectJ, um die Zeit für den "Einstieg" neuer Entwickler in das Projekt zu verkürzen.

Im Allgemeinen ermöglichte dieser Architekturansatz die Implementierung einer unabhängigen schnellen Entwicklung unter Bedingungen hoher Variabilität von Szenarien mit einem praktisch kontinuierlichen Prozess der Bereitstellung neuer Tests für das Produktivsystem. Architektur und jetzt erfolgreich die "Last und Verfeinerung" trotz der Tatsache, dass das System bereits mehr als 1.500 Geschäftsszenarien implementiert hat.

Die allgemeine Codestruktur und Beschreibungen der wichtigsten spezifischen Lösungen sind nachstehend aufgeführt.

Allgemeine Codestruktur und Entwicklungsmuster

Die allgemeine Struktur der Codeorganisation basiert auf einer „geschichteten“ Architektur (siehe Diagramm), die im Allgemeinen das von Selenium-Entwicklern empfohlene Seitenmuster übernimmt. Wir haben dieses Muster erweitert, indem wir der Basis eine Ebene von Webelementen hinzugefügt und die Ebene des Testszenarios hervorgehoben haben:

• Testklassenstufe
• Test-Szenario-Ebene
• Webseitenebene
• Webelementebene
• Test-Framework (durch Dimmen im Diagramm dargestellt).

Jede Ebene in diesem Schema hat bestimmte Verantwortlichkeiten und Funktionen. Funktionale Überschneidungen zwischen Layern oder unzulässige Abhängigkeiten zwischen ihnen waren nicht zulässig und waren der Hauptgrund für die Rückgabe des Commits zur Überarbeitung im Rahmen einer Codeüberprüfung vor der Zusammenführungsanforderung.

Zusätzlich wurde bei der Aufteilung des Codes in Pakete eine „geschichtete“ Struktur festgelegt (siehe Abbildung unten).

Ein solches Schema ermöglichte es, alle Subsysteme (von denen es wesentlich mehr als im Schema gab) zwischen Entwicklern aufzuteilen, und infolgedessen war es möglich, mit einer praktisch verschwindenden Anzahl von Zusammenführungskonflikten unabhängig voneinander zu entwickeln.

Das folgende Diagramm zeigt die allgemeine Struktur der Implementierung der Testklasse und das Verteilungsschema für die Implementierung der Projektpakete.

Testklassenstufe

Die Testklassenstufe enthält eine einzelne Klasse für einen bestimmten Einzeltest (der Test wird im Testmanagementsystem als lineare Folge von Testskripten beschrieben). Die Testklasse ist eine Junit-Klasse mit der @ Test-Annotation der entsprechenden Methode. Im Allgemeinen implementiert eine Testklasse nur eine Testmethode.

Jede Testklasse erbt von einer Basisklasse, deren Aufgabe es ist, alle TestRules in RuleChain zu initialisieren, dh eine Testinfrastruktur zu initialisieren, z. B. einen Webtreiber zu initialisieren, temporäre Verzeichnisse festzulegen und andere universelle Util-Handler.

Die Testklasse ist verantwortlich für die Organisation der Ausführung des Testszenarios durch:

1. Initialisierung von Testgeschäftsdaten (Testszene),
2. sequentieller Aufruf einzelner Testskripte (Actions) gemäß dem gewünschten Szenario mit Übertragung initialisierter Testdaten ab Schritt 2.

Darüber hinaus sollte in Schritt 2 eine lineare Sequenz ohne Verzweigungen oder Entscheidungspunkte vorhanden sein. Die Klassenimplementierungsvorlage ist unten dargestellt.

Testfallstufe

Die Testfallstufe ist für die Implementierung spezifischer Testfälle wie beschrieben verantwortlich. Ein Testszenario ist in diesem Zusammenhang eine Folge von Vorgängen, die ein Benutzer auf einem System durch Interaktion mit Elementen auf Anwendungswebseiten ausführt.

Das Hauptziel der Testfallklasse:

• Führen Sie die angegebene Sequenz des Testskripts aus, indem Sie auf die Methoden der unteren Klassen von Page zugreifen
  
  o übertragene Testszenendaten,
  o Von Webseiten empfangene Daten (aus Seitenklassen);
• Führen Sie die erforderlichen Geschäftstests für den Testerfolg im Kontext des Geschäftsmodells und der Testszene durch. Mit anderen Worten, die Testfallklasse prüft NICHT das Markup, die Verfügbarkeit und die Zugänglichkeit von Elementen, sondern arbeitet nach dem Geschäftsmodell der Testszene und führt tatsächlich Geschäftstests durch.

Die Testfallklasse ist als "funktionale Schnittstelle" organisiert:

• enthält nur eine öffentliche Methode "apply" (@ Step), die:
  
  o Bereitstellung der Implementierung des Skripts als Aufruf einer Folge von "Aktionen" (Methoden, die von den Page-Klassen bereitgestellt werden),
  o akzeptiert alle erforderlichen Geschäftsobjekte als Eingabe, erstellt jedoch KEINE Geschäftsobjekte selbst und interagiert NICHT direkt mit etwas anderem als Page-Klassen.
• enthält X private Methoden (@ Step), von denen jede einen bestimmten separaten Schritt des Testskripts implementiert (wie in TMS - Test Management System beschrieben);
• Interagiert nicht mit anderen Aktivitäten (ruft keine Methoden auf), auch nicht mit Aktivitäten eines ähnlichen Subsystems.
• akzeptiert keine Eingaben und verarbeitet keine Anmeldedaten. Mit anderen Worten, weiß nichts über die Rollen, von denen es gestartet wird.

Mit dieser Klassenorganisation können Sie:

• Bereitstellen eines selbstdokumentierenden Berichts. Jede Methode entspricht einem bestimmten Punkt in der Testspezifikation und ist mit der Allure-Annotation @ Step versehen.
• Verwenden Sie die Testskriptklassen in verschiedenen Tests erneut, da das Testskript 1) keine Testszene erstellt und 2) nicht vom Login des Benutzers abhängt (der Login-Relogin-Vorgang wird auf Testklassenebene durchgeführt). 3) Der Test ist nicht von anderen Klassen abhängig Scripting.

Webseitenebene

Die Webseitenebene ist ein klassisches Seitenmuster zum Testen in Selen. Die Seitenklasse enthält Definitionen bestimmter Webelemente und eine Reihe öffentlicher Methoden zum Ausführen bestimmter Gruppenaktionen im Kontext von Testfallschritten.

Die Seitenklasse ist direkt dafür verantwortlich, Geschäftsdaten in bestimmte Oberflächenelemente einzugeben, mit dem Webtreiber zusammenzuarbeiten (z. B. JS zu starten) und dementsprechend Formate zu testen und das Layout und die Struktur der Webseite auf grundlegende Überprüfungen zu überprüfen, z gefunden / nicht verfügbar und der Artikel enthält nicht den erforderlichen Wert.

Die Seitenklasse enthält auch keine anderen Seiten und deren Methoden und kann nicht auf diese zugreifen. Außerdem führen die Seitenklassen keine Geschäftsüberprüfungen durch, sondern beschränken sich im Allgemeinen nur auf strukturelle Überprüfungen auf der Ebene der Webelemente und stellen die von den Seiten empfangenen Daten auf der Ebene des Testskripts bereit.

Webelementebene

Die Webelementschicht enthält eine Bibliothek von finiten Elementen, die sich auf einer Webseite befinden können. Es enthält sowohl spezifische Grundelemente als auch komplexere Konglomerate, die aus mehreren Elementen bestehen, die wir Widgets nennen. Beispiele für Widgets können Konstruktionen wie "Pajinatoren", globale Menüs, verschiedene Frames und modale Fenster, komplexe Elemente wie YandexMap oder Youtube Player sein. Webelemente organisieren die Komposition mit bestimmten Seitenklassen und wissen auch nichts über andere Elemente.

Wenn das Projekt eine Art globale eindeutige Identifikation aller Schnittstellenelemente mit ihrer ID aufweist, ist es im Allgemeinen sinnvoll, die Ebene der Webelemente als globale Bibliothek mit der Anforderung bestimmter Elemente nach ihrer ID über die Factory- oder \ xml-Konfigurationsklassen in der Spring-Bibliothek zu organisieren. Dies ist aber nicht in jedem Projekt möglich.

Testframework

Das Konzept der Entwicklung von Autotests, wie es in der obigen Abbildung dargestellt ist, basiert auf der Idee eines Frameworks, in dem eine Reihe von Systemfunktionen für alle Autotests bereitgestellt wird. Sie sind nahtlos integriert und ermöglichen Autotest-Entwicklern, sich auf bestimmte Aspekte der Geschäftsimplementierung von Testklassen zu konzentrieren.

Das Framework enthält die folgenden Funktionsblöcke:

• Regeln - Initialisierung und Finalisierung von Testinfrastrukturkomponenten als Initialisierung von WebDriver und Empfang eines Videotests (nachstehend ausführlicher beschrieben);
• WebDriverHandlers - Hilfsfunktionen für die Arbeit mit einem Webtreiber wie das Ausführen von Java Script oder den Zugriff auf Browser-Protokolle. Implementiert als eine Reihe statischer zustandsloser Methoden;
• WebElements - eine Bibliothek typischer Webelemente oder ihrer Gruppen, enthält die erforderliche funktionsübergreifende Funktionalität und das typische Verhalten. In unserem Fall beinhaltet diese Funktionalität eine mögliche Überprüfung des Abschlusses von asynchronen Vorgängen auf der Seite des Webbrowsers. Implementiert als Erweiterung von Webelementen aus den Bibliotheken Selenium und Selenide.

Initialisierung der Testumgebung. Regeln

Die Schlüsselklasse für alle Testklassen ist BaseTest, von der alle Testklassen geerbt werden. Die BaseTest-Klasse definiert den Junit-Test-Runner und die verwendete RuleChain, wie unten gezeigt. Der Zugriff von Anwendungstestklassen auf Funktionen, die von Regelklassen bereitgestellt werden, erfolgt über die statischen Methoden von Regelklassen unter Verwendung der Thread-ID "thread" als Schlüssel.

Details zur Implementierung von Basisklassen für das Autotest-Framework werden im nächsten Teil des Artikels gezeigt: siehe Teil 2-1. Basisklassenimplementierung für alle Tests und JUnit ChainRule.

Ergebnisse über Allure-Berichte dokumentieren.

Für detaillierte Berichte zu den durchgeführten Tests wird das Allure Framework verwendet, das über das Allure Plugin in Bamboo integriert ist. Dies bietet bestimmten Testkonsumenten (Funktionstest-Team) die Möglichkeit, nicht nur Daten über einen bestimmten Testabsturz zu erhalten, sondern auch einen fallengelassenen Test im manuellen Modus einfach wiederherzustellen und gegebenenfalls zu wiederholen.

Zur Dokumentation des Prüfberichts wird folgende Funktionalität verwendet:

• Allure- und Junit-Anmerkungen zum Markieren des Berichts anhand der Schritte des Testskripts sowie eine statische Beschreibung der Metadaten für den Test;
• Bieten Sie Anhänge an, um dem Bericht zusätzliche Informationen wie einen Videotest, einen Screenshot, die Ergebnisse zusätzlicher Diagnosetests zu den Ursachen des Absturzes sowie Webbrowser-Protokolle hinzuzufügen, die in den / aus dem Dateibrowser heruntergeladen wurden.

Die folgenden Allure- und Junit-Annotationen werden zum Markieren des Berichts verwendet.

• Auf der Testklassenebene:
  
  o @ Feature - der Name des funktionalen Subsystems, zu dem der Test gehört;
  o @ Story - der Name eines bestimmten Testfalls;
  o @ Owner - der Name des Entwicklers, der zuletzt Änderungen am Test vorgenommen hat;
  o @ TmsLink - Link zur Testbeschreibung im verwendeten „Test Management System“.
• Auf der Testmethodenebene (@ Test) der Testklasse:
  
  o @ DisplayName - vollständiger Name des Testskripts. Es unterscheidet sich von @ Story dadurch, dass Sie dieselben Skripte verwenden können, die sich nur in der Zusammensetzung der Testszene unterscheiden.
• Auf der Ebene der Methoden, die den spezifischen Schritten des Testszenarios entsprechen:
  
  o @ Step - Der aussagekräftige Name des Testschritts, der die geschäftliche Essenz des Geschehens widerspiegelt.

Die Benennung der Testschritte durch @ Step ermöglicht es Ihnen, einen detaillierten Bericht zu erstellen, der alle im Testszenario beschriebenen Schritte und Elemente vollständig wiederholt. Auf diese Weise können Benutzer von Autotests den Verlauf des Testszenarios auf einfache Weise nachverfolgen und den Inzidenzpunkt bestimmen.

Im Allgemeinen erwies sich die Verwendung des Allure Frameworks als sehr nützlich und einfach, mit Ausnahme einiger Funktionen, die sich auf die enorme Datenmenge beziehen, die in unserem Fall für eine große Anzahl langer komplexer Testskripten generiert wird (weiter unten im Abschnitt "Rückblick" beschrieben).

Was hätte auf Anhieb anders gemacht werden können? Verwenden Sie Spring Framework

Obwohl wir uns bei der Implementierung von Autotests absichtlich geweigert haben, Spring Core zu verwenden, halte ich seine Verwendung im Allgemeinen für gerechtfertigt und funktionsfähig. Der implementierte Prototyp zeigte, dass die Verwendung von Spring Core für die folgenden Aufgaben funktioniert (obwohl wir es natürlich nicht vollständig getestet haben):

• Initialisierung der Testszene;
• Initialisierung von Webseiten und Elementen.

Das einzige Merkmal ist die Notwendigkeit, den "Standard" -Umfangskontext der Prototypebene zu verwenden.

Initialisierung der Testszene. In Autotests wird die Testszene durch die klassische Methode initialisiert, Klasseninstanzen direkt in der Testklasse über eine einfache neue oder Objektfactory zu erstellen. Hier ist es durchaus sinnvoll, die Initialisierung entweder über Konfigurationsklassen oder über externe XML- oder Dateidateien zu verwenden. Die Vorteile sind folgende: 1) Vereinfacht den Überprüfungscode, da Änderungen an der Testszene nicht mehr für Schlüsselklassen gelten. 2) Ermöglicht das Anschließen verschiedener Testszenen für verschiedene Stände oder andere Bedingungen. Jetzt wird Punkt 2 bei uns nicht verwendet.

Initialisierung von Webseiten und Elementen. Das Einfügen von Web-Klassen und Web-Elementen funktioniert aufgrund der verzögerten Initialisierung von Selenid-Web-Elementen.

Somit wird es möglich, eine Bibliothek von Webelementen und -seiten gemäß einer bestimmten globalen Spezifikation der Benutzeroberfläche zu erstellen und im Code Links zu diesen Elementen nicht über den absoluten Pfad und die ID, sondern über die Projekt-ID gemäß der Spezifikation zu erhalten.

Ich muss gleich sagen, dass ich dies nicht sehr sorgfältig getestet habe, sondern mich auf eine Testimplementierung der "Seiten" des Logins und der "Infoseite" des Nutzers nach diesem Prinzip beschränkt habe.

Rückblick. Überraschungen

Hier habe ich die unerwarteten Überraschungen beschrieben, die während der Entwicklung des Projekts aufgetreten sind, sowie einige Überlegungen darüber, was hätte besser gemacht werden können, wenn „nicht“.

Selen-freundliches Frontend-Markup (Angular)

Eine der schwerwiegendsten Überraschungen war das „schwebende“ Seitenlayout, das dazu führte, dass die Tests nach der Aktualisierung von Angular-Anwendungen zurückgingen, weil Selen die Elemente aufgrund ihrer ID (ID, Klasse oder ID) nicht finden konnte ng-Modell) oder Pfade (für XPath). Dies führte zu einer Instabilität der Tests und der Mehrdeutigkeit der Gründe für den Sturz.

Leider stellte sich heraus, dass dieses Problem im Allgemeinen nicht lösbar ist. Wir haben dies mit organisatorischen Maßnahmen umgangen: 1) Zu Beginn des Tests eines neuen Kandidaten für die Freigabe konzentrieren sich alle Entwickler von Autotests auf die schnelle Eliminierung und Verfeinerung hinsichtlich der Bearbeitung der Werte von Webelement-Locators. 2) Am Ende haben wir relativen XPath verwendet, der leider die Leistung überhaupt nicht verbessert.

– , - .

«download»

«» :

• «» ( ) – «» . ;
• «» ( Bamboo) «» solenoid : selenoid-host.example.com:4444/download/{SESSION_ID}/{FILE_NAME}

.

. , , . , .

. , «» . , , , , , - ( ) - .

, , , . .

, . «» , , , .

. , . (~ 1000 ) 6 .

Selenoid-ggr . junit 20 ( Selenoid-) 60 ( ), . «» , 60 .

, , , 3-4 , preQA-. . , , AWS c , Selenoid- , AWS Selenoid, in/out .
, , E2E . preQA.

«»

, 60 60 .

«Timeline» « » ( ). , .


Es gab zwei Gründe. Der beginnende „Plug“ wurde durch den Massenappell an den Autorisierungsdienst und das persönliche Konto verursacht. Alle Browser starten gleichzeitig die Anmeldung und überlasten den Dienst auf der Prüfstandsseite.

Die folgenden „Spalten“ standen in Zusammenhang mit der Tatsache, dass unsere Testklassen nach Subsystemen in Ordnern abgelegt und von junit fast gleichzeitig ausgeführt wurden, wodurch ein bestimmtes funktionales Subsystem des Standes geladen und die Leistungsgrenze der Standkonfiguration überschritten wurde.

Wir haben das erste Problem gelöst, indem wir die Anmeldeskriptmethode in den Balancer eingebunden haben, wodurch die maximale Anzahl der Anmeldevorgänge auf eine bestimmte Konstante begrenzt wurde.

@Step(":    ")     public void apply(User user) {     try {         LoadCounter.get(); //   .              try {                 applyLogin(user); //          } catch (Throwable t) {             throw t; //                   } finally {             LoadCounter.release(); //            }         } catch (LoadCounterException e) { //                  throw new StandRuntimeException("Can not get loadcounter for Login action.", e);     }     } 

Das zweite Problem wurde gelöst, indem die Option für zufällige Testläufe aktiviert wurde, über die das junit maven-Plugin verfügt.

    <plugin>               <groupId>org.apache.maven.plugins</groupId>                <artifactId>maven-surefire-plugin</artifactId>         <version>….</version>            <configuration>                <!-- Defines the order the tests will be run in. Supported values are "alphabetical",                     "reversealphabetical", "random","hourly", "failedfirst", "balanced" and "filesystem". -->                <runOrder>random</runOrder>                … 

Es muss angemerkt werden, dass diese Probleme damit zusammenhängen, dass wir aufgrund begrenzter Ressourcen nicht die Möglichkeit hatten, die Leistung des Prüfstands zu steigern, und auch, weil diese Ressourcen die meiste Zeit im Leerlauf waren.

Im Allgemeinen hat sich herausgestellt, dass das eingebaute E2E-System der Web-UI-Selbsttests gut zum Testen der Ersatzlast und zum Überprüfen der Leistung und Stabilität des gesamten getesteten Systems verwendet werden kann.

Hohe Belastung des Bamboo-Servers und seines Speichers

Wenn Sie viele Tests mit einer großen Anzahl von Vorgängen haben (z. B. die Anzahl der durch Step protokollierten Vorgänge zwischen 200 und 2000 mit einer Anzahl von Tests von etwa 1300), wird das Volumen des Allure-Berichts mehr als bedeutend. Wenn Sie hier auch verschiedene Anhänge wie Screenshots und hochgeladene / hochgeladene Dateien hinzufügen, dann geht das Volumen schon auf Hunderte von Megabyte. Beispiel: Bei einer nächtlichen Regression von 900 Tests beträgt die Datenmenge, die allein in Bamboo Allure hochgeladen wird, ungefähr 600 MB.

Es ist klar, dass die Entwickler von DevOps nicht begeistert sind von einer solchen Intensität, bei der Speicherplatz verbraucht wird, und aktiv Unzufriedenheit ausdrücken, insbesondere im Zusammenhang mit der Notwendigkeit, Daten für mindestens ein Jahr zu speichern.

Wir sehen einen Ausweg aus dieser Situation, indem wir einen externen Server zum Speichern und Verarbeiten von Berichten verwenden, z. B. Allure Enterprise. Dieser Server ist bereits bezahlt, aber wir können dieses Problem lösen. Wir arbeiten derzeit daran, Allure Enterprise zu testen und in unser Projekt zu integrieren.

Fortsetzung folgt

Im nächsten Artikel werden meine Kollegen die Geschichte fortsetzen und die faszinierende Geschichte des Testens von Webdiensten mit Smartbear SoapUI Pro beschreiben. Den Kräften zweier Automatisierungsingenieure gelang es, rund 500 Testskripte zu automatisieren, wozu ich ein zusätzliches Framework implementieren musste, das die Funktionalität der Standard-SOAP-UI-Funktionen erheblich erweitert, aber dazu später mehr.

Dieser Artikel wurde in Zusammenarbeit mit dem Projektmanager und dem Eigentümer des kotalesssk- Produkts verfasst.

Teil 1. Organisatorisch und leitend. Warum brauchten wir Automatisierung? Organisation des Entwicklungs- und Managementprozesses. Organisation der Nutzung
Teil 2. Technische. Architektur und technischer Stapel. Implementierungsdetails und technische Überraschungen
Teil 2-1. Basisklassenimplementierung für alle Tests und JUnit ChainRule
Teil 2-2. Implementierung des Vorgangs zum Hochladen einer Datei aus einem Container mit einem Browser in ein Testframework. Suchen Sie nach dem Namen der vom Browser heruntergeladenen Datei