Mit diesem Artikel eröffnen wir eine Reihe von Veröffentlichungen darüber, wie wir den Prozess des manuellen Testens eines großen Informationssystems in einem der Hauptprojekte von LANIT automatisiert haben und was daraus entstanden ist.

Der erste Teil - organisatorisch und verwaltungstechnisch - sollte in erster Linie für diejenigen nützlich sein, die für das Testen der Automatisierung verantwortlich sind und solche Systeme als Ganzes erstellen. Projektmanager, Gruppenleiter und Eigentümer von funktionalen und automatischen Testdiensten, die sich alle mit der Frage beschäftigen, wie ein kostengünstiger End-2-End-Test ihres IT-Systems erstellt werden kann, finden hier einen konkreten Plan und eine konkrete Methodik.

Quelle

Teil 1 - Organisation und Management. Warum brauchten wir Automatisierung? Organisation des Entwicklungs- und Managementprozesses. Organisation der Nutzung

Am Anfang gab es ein großes und komplexes Informationssystem (wir werden es das „System“ nennen) mit zahlreichen komplexen, langen und miteinander verbundenen Geschäftsszenarien. Alle Skripte wurden als E2E über Webschnittstellen ausschließlich im manuellen Modus getestet (es gab mehr als eineinhalb Tausend solcher Szenarien mit nur der kritischsten Priorität). Darüber hinaus mussten alle diese Szenarien mindestens einmal während der Regression jeder neuen Version oder jedes neuen Hotfixes vor dem nächsten Bereitstellungsupdate für das Produkt abgeschlossen werden.

Zu einem bestimmten Zeitpunkt, als es völlig unerträglich wurde, im manuellen Modus mit der Maus zu klicken, beschlossen wir, alles zu automatisieren. Dies haben sie durch die Entwicklung eines separaten Dienstes auf der Basis von Java + Selen + Selenid + Selenoid getan, der auch als "Test-Framework" oder einfach "Autotests" bezeichnet wird .

In der Vergangenheit wurde der Test-Framework-Code von zwei Teams entwickelt. Zunächst erstellte das erste Team einen Prototyp mit ein paar Dutzend Szenarien. Dann skalierte das zweite Team für ein Jahr den Prototyp sowohl in der Breite (Anzahl der Tests) als auch in der Tiefe (typische Codierungs- und Implementierungsmuster wurden eingeführt).

Ich bin das Team und der Teamleiter des zweiten Teams, das das Prototyp-Framework für die Skalierung übernommen hat (im Mai 2018).

Zum Zeitpunkt dieses Schreibens war die vor einem Jahr festgelegte Aufgabe abgeschlossen und das Projektteam erhielt einen stabilen Automatisierungsservice. Es war nicht umsonst, dass ich den Service hervorhob, da die Aufgabe ursprünglich nicht darin bestand, eine Anwendung zu entwickeln, sondern einen Service-Service zum Testen der Automatisierung für eine Gruppe von „Funktionstests“ bereitzustellen. Diese Funktion hat in der Folge die Organisation der Entwicklung und die Architektur des Testframeworks stark beeinflusst.

Zusammenfassung

Etwa 1.500 Testszenarien wurden automatisiert: In jedem Test wurden 200 bis 2000 Benutzeroperationen durchgeführt.

Die Gesamtkapazität des Dienstes beträgt bis zu 60 gleichzeitig arbeitende Browser, und dies ist nicht die Grenze (die Anzahl kann aufgrund virtueller Maschinen um das Fünffache erhöht werden).
Die Gesamtdauer einer vollständigen Regression beträgt nicht mehr als 3 Stunden, und der PreQA-Test beträgt weniger als eine Stunde.

Eine umfangreiche Palette von Funktionen wurde implementiert:

• lokale Nutzung (Echtzeitausführung) und Remote (über Bambuspläne);
• Begrenzung der Zusammensetzung laufender Tests durch Filter;
• einen detaillierten Bericht mit den Ergebnissen jedes Schritts des Testszenarios (über das Allure-Framework);
• Herunterladen und Hochladen von Dateien von / in den Browser, gefolgt von der Überprüfung der Ergebnisse ihrer Verarbeitung hinsichtlich Format und Inhalt der Dateien;
• Abrechnung und Steuerung der asynchronen Natur der Winkelschnittstelle. Einschließlich der Kontrolle von blockierten Anforderungen (ausstehende Anforderung) zwischen Angular- und REST-Diensten;
• Kontrolle von Browserprotokollen;
• Video-Testaufzeichnung;
• Entfernen des Schnappschusses der Seite zum Zeitpunkt des "Sturzes" des Tests;
• Ereignisübertragung in ELK;
• viel mehr über die kleinen Dinge ...

Warum wurde das alles gebraucht?

Zu Beginn war der Zweck des Systems recht einfach und klar.

Stellen Sie sich vor, Sie verfügen über ein großes Registrierungssystem für die Verwaltung einer Vielzahl von Dokumenten und deren Lebenszyklus, die einige hundert Geschäftsprozesse bereitstellen. Darüber hinaus gibt es Millionen von Menschen, Lieferanten - Zehntausende, Dienstleistungen - Tausende, komplexe Dokumente, einschließlich Framework und Vorlage, und die Bereitstellung von Geschäftsprozessen wird auf Hunderte verschiedener Arten bereitgestellt ...

All dies führt zu anderthalb Tausend Testszenarien, und dies ist nur die höchste Priorität und nur positiv.

Während des Automatisierungsprozesses wurden verschiedene Nuancen entdeckt, die die Verwendung verschiedener Lösungen erforderten.

Beispielsweise kann ein Skript bis zu Hunderte von separaten Vorgängen enthalten, darunter interessante wie: „Laden Sie eine EXCEL-Datei mit Daten herunter und überprüfen Sie, ob das System jeden Datensatz aus der Datei verarbeitet“ (um dieses Problem zu lösen, waren mehrere Schritte erforderlich, um die Daten vorzubereiten und das Ergebnis des Ladens zu überprüfen System). Und jetzt fügen wir die Einschränkung der Wiederverwendung von Testdaten hinzu: Die Testdaten für den erfolgreichen Abschluss der meisten Testszenarien sollten "frisch" sein und zuvor nicht in ähnlichen Szenarien verwendet werden (während der Tests ändert sich der Status der Daten im System, sodass sie nicht wiederverwendet werden können die gleichen Schecks).

Quelle

Irgendwann schien das manuelle Testen des Systems als Teil der Regression nicht mehr kostengünstig und schnell genug zu sein, und sie beschlossen, es über die Webbenutzeroberfläche zu automatisieren.

Mit anderen Worten, die Funktionstestgruppe öffnet die "Seite", wählt die "Testgruppe" aus und drückt die "Ausführen" -Taste (wir haben Bamboo verwendet). Dann emulieren Autotests (im Folgenden als Autotests bezeichnet. Das erstellte Produkt zum Testen im Allgemeinen festlegen) automatisch die Aktionen der Benutzer im System über den Browser (drücken Sie die erforderlichen Schaltflächen, geben Sie Werte in die Felder ein usw.) und zeigen Sie nach Abschluss einen detaillierten Bericht über alle an Schritte und abgeschlossene Aktionen und Ergebnisse der Überprüfung (Entsprechung der erwarteten Reaktion des Systems auf sein tatsächliches Verhalten).

Insgesamt ist der Zweck von Autotests die Automatisierung manueller E2E-Tests. Dies ist ein „externes“ System, das nicht am Entwicklungsprozess des zu testenden Systems teilnimmt und in keiner Weise mit den von den Entwicklern verwendeten Einheiten- oder Integrationstests verbunden ist.

Ziele

Es war notwendig, die Arbeitskosten für die Durchführung von End-2-End-Tests erheblich zu senken und die Geschwindigkeit vollständiger und reduzierter Regressionen in Bezug auf das Volumen zu erhöhen.

Die Aufgaben

Die Hauptaufgabe der Entwicklung wurde sehr einfach formuliert - in den nächsten 6 Monaten 1000 Testszenarien mit höchster Priorität zu automatisieren.

Die vorhergesagte Anzahl grundlegender Testaktionen lag zwischen 100 und 300, was uns ungefähr 200.000 Testmethoden mit 10 bis 20 Codezeilen ergab, ohne die allgemeinen und zusätzlichen Klassen von Helfern, Datenanbietern und Datenmodellen zu berücksichtigen.

So stellte sich heraus, dass unter Berücksichtigung der Zeitbeschränkungen (130 Arbeitstage) mindestens 10 Tests pro Tag durchgeführt werden mussten und gleichzeitig die Relevanz der durchgeführten Selbsttests unter Berücksichtigung der im System auftretenden Änderungen sichergestellt werden musste (das System entwickelt sich aktiv).

Nach Schätzungen von Experten betrug der Arbeitsaufwand für die Entwicklung eines Autotests 4 bis 8 Stunden. Wir haben also mindestens ein Team von 5 Personen (in Wirklichkeit hatte das Team auf dem Höhepunkt der Entwicklung von Autotests mehr als 10 Automatisierungsingenieure).

Verständlich waren auch die Aufgaben, die gelöst werden mussten.

• Prozesse und Befehle konfigurieren:
• Definieren Sie den Prozess der Interaktion mit dem Kunden (Funktionstestgruppe), legen Sie das Testfallbeschreibungsformat als Eingabe für das Automatisierungsteam fest.
• den Entwicklungs- und Wartungsprozess organisieren;
• ein Team bilden.
  
• Entwickeln Sie Autotests mit den folgenden Funktionen:
• Klicken Sie automatisch auf die Schaltflächen im Browser und überprüfen Sie vorab, ob Elemente und die erforderlichen Informationen auf der Seite vorhanden sind.
• Arbeiten mit komplexen Elementen wie Yandex.Map;
• um das Laden automatisch generierter Dateien in das System sicherzustellen, um das Herunterladen von Dateien vom System mit Überprüfung ihres Formats und Inhalts sicherzustellen.
• Stellen Sie einen Datensatz aus den Browser-Screenshots, Videos und internen Protokollen bereit.
• Um die Integration in externe Systeme wie einen Mailserver zu ermöglichen, überprüft das Task Tracking System (JIRA) die Integrationsprozesse zwischen dem getesteten System und externen Systemen.
• Bereitstellung eines dokumentierten Berichts über alle ergriffenen Maßnahmen, einschließlich einer Anzeige der eingegebenen und überprüften Werte sowie aller erforderlichen Investitionen.
• Führen Sie im parallelen Modus Tests mit dem erforderlichen Volumen durch.
• Stellen Sie Autotests in der vorhandenen Infrastruktur bereit.
• Verfeinern Sie die bereits automatisierten Testskripte des Konsonantenzielkonzepts (Verfeinerungsgeschwindigkeit - etwa 50 Tests pro Woche Sprint).

Wie ich in der Einleitung erwähnt habe, hatten wir zu Beginn einen funktionierenden MVP-Prototyp, der von einem anderen Team implementiert wurde. Dieser musste von 20 auf 1000 Tests erhöht werden, um neue Funktionen hinzuzufügen und eine akzeptable Skalierbarkeit und Flexibilität bei Änderungen sicherzustellen.

Das Vorhandensein eines funktionierenden Prototyps am Eingang gab uns einen technologischen Stapel, der Folgendes umfasste: Java SE8, JUnit4, Selen + Selenid + Selenoid, Bambus als „Läufer“ von Tests und als „Erbauer“ von Allure-Berichten. Da der Prototyp einwandfrei funktionierte und die erforderlichen Grundfunktionen bereitstellte, haben wir beschlossen, den technologischen Stack nicht zu ändern, sondern uns auf die Entwicklung der Skalierbarkeit der Lösung, die Erhöhung der Stabilität und die Entwicklung fehlender erforderlicher Funktionen zu konzentrieren.

Grundsätzlich sah alles machbar und optimistisch aus. Darüber hinaus haben wir die Aufgaben zu einem bestimmten Zeitpunkt vollständig bewältigt.

Im Folgenden werden die einzelnen technologischen und prozessualen Aspekte der Entwicklung von AutoTests beschrieben.

Beschreibung der Autotests. User Stories und Features

Quelle

Autotests implementieren die folgenden User Stories im Kontext ihrer Verwendung durch die Testgruppe:

• manuelle Testautomatisierung;
• automatische vollständige Regression;
• Qualitätskontrolle von Baugruppen in der CI \ CD-Kette.

Die Implementierungsdetails und Architekturentscheidungen werden in Teil 2 - Technisch erörtert . Architektur und technischer Stack. Implementierungsdetails und technische Überraschungen .

Automatisches und manuelles Testen (User Stories)

Als Tester möchte ich den Ziel-E2E-Test durchführen, der ohne meine direkte Teilnahme (im automatischen Modus) durchgeführt wird, und mir einen detaillierten Bericht im Kontext der durchgeführten Schritte einschließlich der eingegebenen Daten und der erhaltenen Ergebnisse sowie Folgendes zur Verfügung stellen.

• Vor Beginn des Tests sollten verschiedene Zielstände ausgewählt werden können.
• sollte in der Lage sein, die Zusammensetzung der laufenden Tests von allen implementierten zu verwalten;
• Am Ende des Tests müssen Sie ein Video des Tests vom Browserbildschirm abrufen.
• Wenn der Test abstürzt, müssen Sie einen Screenshot des aktiven Browserfensters erhalten.

Automatische vollständige Regression

Als Testgruppe möchte ich alle Tests jeden Abend auf einem bestimmten Prüfstand im automatischen Modus durchführen, einschließlich aller Funktionen des "automatischen manuellen Tests".

Qualitätskontrolle der Baugruppe in der CI \ CD-Kette

Als Testgruppe möchte ich automatische Tests der bereitgestellten Aktualisierungen des Systems auf einem dedizierten preQA-Stand durchführen, bevor ich die Ziel-Teststände für die Funktionstests aktualisiere, die später für Funktionstests verwendet wurden.

Grundfunktionen implementiert

Quelle

Hier finden Sie eine kurze Übersicht über die wichtigsten implementierten Funktionen von AutoTests, die sich als wichtig oder einfach nützlich erwiesen haben. Details zur Implementierung einiger interessanter Funktionen finden Sie im zweiten Teil des Artikels.

Lokale und Remote-Verwendung

Die Funktion bot zwei Optionen zum Ausführen von Autotests - lokal und remote.

Im lokalen Modus führte der Tester den erforderlichen Autotest an seinem Arbeitsplatz durch und konnte gleichzeitig beobachten, was im Browser geschah. Der Start erfolgte durch das "grüne Dreieck" in IntelliJ IIDEA -). Die Funktion war zu Beginn des Projekts sehr nützlich für Debugging und Demonstrationen, wird aber jetzt nur noch von den Entwicklern von Autotests verwendet.

Im Remote-Modus startet der Tester den Autotest über die Schnittstelle des Bamboo-Plans mit den Parametern der Zusammensetzung der laufenden Tests, einem Stand und einigen anderen Parametern.

Die Funktion wurde mit der Umgebungsvariablen MODE = REMOTE | LOCAL implementiert, je nachdem, welcher lokale oder entfernte Webbrowser in der Selenoid- Cloud initialisiert wurde.

Begrenzung der Zusammensetzung laufender Tests nach Filter

Die Funktion ermöglicht es, die Zusammensetzung der laufenden Tests im Remote-Verwendungsmodus für Benutzer zu beschränken und die Testzeit zu verkürzen. Es wird eine zweistufige Filtration verwendet. Der erste Schritt blockiert die Ausführung von Tests basierend auf der Variablen FILTER_BLOCK und wird hauptsächlich verwendet, um große Gruppen von Tests von der Ausführung auszuschließen. Im zweiten Schritt werden nur Tests übersprungen, die mit der Variablen FILTER übereinstimmen.

Der Wert der Filter wird als Satz regulärer Ausdrücke REGEXP1, ..., REGEXPN angegeben, die nach dem Prinzip "ODER" angewendet werden.

Beim Starten im manuellen Modus wurde der Tester aufgefordert, eine spezielle Umgebungsvariable als Liste regulärer Ausdrücke festzulegen, die auf die spezielle Annotation @ Filter (String value) anwendbar sind, mit der alle Testmethoden in den Testklassen kommentiert wurden. Für jeden Test ist diese Anmerkung eindeutig und basiert auf einer Reihe von Tags, die durch einen Unterstrich getrennt sind. Wir verwenden die folgende Mindestvorlage SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT}, wobei das DEFAULT-Tag für Tests vorgesehen ist, die in der automatischen Nachtregression enthalten sind.

Die Funktion wird durch eine benutzerdefinierte Erweiterung der Klasse org.junit.runners.BlockJUnit4ClassRunner implementiert (Details werden in Teil 2-1 der Fortsetzung dieses Artikels angegeben).

Dokumentation des Berichts mit den Ergebnissen für alle Schritte

Die Testergebnisse werden für alle Testaktionen (Schritte) mit allen erforderlichen Informationen angezeigt, die im Allure Framework verfügbar sind . Sie aufzulisten macht keinen Sinn. Sowohl auf der offiziellen Website als auch im gesamten Internet gibt es genügend Informationen. Es gab keine Überraschungen bei der Verwendung des Allure Frameworks, und im Allgemeinen empfehle ich es zur Verwendung.

Die Hauptfunktionen sind:

• Anzeige jedes Testschritts (der Name des Schritts entspricht seinem Namen in der Testspezifikation - Testskript);
• Anzeigen von Schrittparametern in einer für Menschen lesbaren Form (durch die erforderliche Implementierung der toString-Methode aller übertragenen Werte);
• Anhängen von Screenshots, Videos und verschiedenen zusätzlichen Dateien an den Bericht;
• Klassifizierung von Tests nach Typen und Subsystemen sowie Verknüpfung des Autotests mit der Testspezifikation im Test Link-Testfallmanagementsystem durch Verwendung spezieller Anmerkungen.

Laden Sie Dateien vom / in den Browser herunter und laden Sie sie hoch, um sie anschließend zu überprüfen und zu analysieren

Das Arbeiten mit Dateien ist ein äußerst wichtiger Aspekt von Testskripten. Es war notwendig, sowohl verschiedene Dateien hochzuladen als auch herunterzuladen.

Das Herunterladen von Dateien implizierte zunächst das Laden dynamisch generierter EXCEL-Dateien in das System gemäß dem Kontext der Ausführung des Testskripts. Der Download wurde mit Standardmethoden implementiert, die von Selen-Tools bereitgestellt wurden.

Das Hochladen von Dateien implizierte das Herunterladen von Dateien durch Drücken der Schaltfläche im Browser in ein lokales Verzeichnis und die anschließende Übertragung dieser Datei auf den Server, auf dem die AutoTests ausgeführt wurden (den Server, auf dem der Remote-Bamboo-Agent installiert war). Außerdem wurde diese Datei analysiert und hinsichtlich Format und Inhalt analysiert. Die Hauptdateitypen waren EXCEL- und PDF-Dateien.

Die Implementierung dieser Funktion stellte sich als nicht triviale Aufgabe heraus, vor allem aufgrund des Mangels an Standardfunktionen für die Dateiverwaltung: Derzeit wird die Funktion nur für den Chrome-Browser über die Service-Seite "chrome: // downloads /" implementiert.

Ich werde Sie im zweiten Teil ausführlich über die Implementierungsdetails informieren.

Abrechnung und Kontrolle der Asynchronität der Angular-Schnittstelle. Ausstehende Anforderungssteuerung zwischen Angular- und REST-Diensten

Da das Objekt unserer Tests auf Angular basierte, mussten wir lernen, mit der Asynchronität des Frontends und der Zeitüberschreitungen zu „kämpfen“.

Im Allgemeinen verwenden wir zusätzlich zu org.openqa.selenium.support.ui.FluentWait eine speziell entwickelte Wartemethode, die Javascript auf „unvollständige“ Interaktionen mit Front-End-REST-Diensten überprüft. Basierend auf diesem dynamischen Zeitlimit erhalten Tests Informationen darüber, ob sie folgen sollen dann etwas länger warten.

Unter dem Gesichtspunkt der Funktionalität konnten wir den Zeitaufwand für die Durchführung der Tests erheblich reduzieren, da statische Erwartungen abgelehnt wurden, bei denen es nicht möglich ist, den Abschluss der Operation anders zu bestimmen. Darüber hinaus konnten wir so „hängende“ REST-Services mit Leistungsproblemen definieren. Sie haben beispielsweise einen REST-Service abgefangen, für den die Anzahl der auf der Seite angezeigten Einträge auf 10.000 Elemente festgelegt wurde.

Informationen über den "eingefrorenen" REST-Dienst mit allen Parametern seines Aufrufs, aufgrund derer der Test aus infrastrukturellen Gründen "fällt", werden zu den Ergebnissen des abgebrochenen Tests hinzugefügt und zusätzlich als Ereignis in ELK gesendet. Auf diese Weise können Sie die erkannten Probleme sofort an die entsprechenden Entwicklungsteams des Systems übertragen.

Browser-Protokollsteuerung

Die Browser-Protokollsteuerungsfunktion wurde hinzugefügt, um Fehler auf den SEVERE-Level-Seiten zu steuern und zusätzliche Informationen für abgebrochene Tests zu erhalten, z. B. um Fehler wie "... Ressource konnte nicht geladen werden: Der Server hat mit dem Status 500 (Interner Serverfehler) geantwortet" zu überwachen.

Die Zusammensetzung der Seitenverarbeitungsfehler im Browser wird auf jedes Testergebnis angewendet und zusätzlich als Ereignisse im ELK entladen.

Videoaufzeichnung des Tests und Entfernen des Schnappschusses der Seite zum Zeitpunkt des "Sturzes" des Tests

Funktionen werden implementiert, um das Diagnostizieren und Parsen von abgelegten Tests zu vereinfachen.

Die Videoaufzeichnung wird für den ausgewählten Remote-Testlaufmodus separat aktiviert. Das Video wird als Anhang zu den Ergebnissen im Allure-Bericht angehängt.
Ein Screenshot wird automatisch erstellt, wenn der Test abstürzt, und die Ergebnisse werden auch auf den Allure-Bericht angewendet.

Weitergabe von Ereignissen an ELK

Die Funktion zum Senden von Ereignissen an ELK ist implementiert, um eine statistische Analyse des allgemeinen Verhaltens von AutoTests und der Stabilität des Testobjekts zu ermöglichen. Im Moment wurden das Senden von Ereignissen über den Abschluss von Tests mit den Ergebnissen und der Dauer sowie Browserfehler der SEVERE-Ebene und aufgezeichnete "eingefrorene" REST-Services implementiert.

Entwicklungsorganisation

Quelle

Entwicklungsteam

Wir brauchten also mindestens 5 Entwickler. Fügen Sie eine weitere Person hinzu, um ungeplante Abwesenheiten auszugleichen. Wir erhalten 6. Plus einen Teamleiter, der für die Querschnittsfunktionalität und die Codeüberprüfung verantwortlich ist.

Daher mussten 6 Java-Entwickler hinzugezogen werden (in Wirklichkeit waren auf dem Höhepunkt der Entwicklung von Autotests mehr als 10 Automatisierungsingenieure im Team).

Angesichts der allgemeinen Marktlage und eines relativ einfachen technologischen Stacks bestand das Team hauptsächlich aus Praktikanten, von denen die meisten entweder gerade ihren Abschluss an einer Universität gemacht hatten oder im letzten Jahr waren. Tatsächlich suchten wir Leute mit Grundkenntnissen in Java. Bevorzugt wurden manuelle Testspezialisten, die Programmierer werden möchten, und motivierte Kandidaten mit (unbedeutender) Entwicklungserfahrung, die künftig Programmierer werden wollten.

, ( 2 – . . ).

, , . CodeRush . .

. , , «» .

() . code review merge request ( GitLab). code review «» ( ) .

– . / , .

ode review , , () - , . ode review .

code review , .

: , , , , . , , , / .

« », - -. -.

, . sprint retrospective event.

- ( ) , stakeholder .

– . , , . , - . .

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

- - ( : - – , - , — , ). , - / : « - ( )».

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

, . master, -. - - code review.

, – , .

Eigenschaften:

(+) ;
(+) ;
(+) «» ;
(-) ();
(-) hotfix .

.

Entwickler

• MASTER.
• .
• FEATURE .
• , « » rebase.
• Gitlab merge request . merge request- :
• — «Jira»;
• — Bamboo.

GateKeeper ( )

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

– – UI end-2-end -. , - . UI - . , .