Eis Divisioun erstellt voll automatesch Pipelines fir nei Versioune vun Uwendungen an d'Produktiounsëmfeld ze lancéieren. Natierlech erfuerdert dëst automatiséiert funktionell Tester. Ënnert dem Schnëtt ass eng Geschicht iwwer wéi, ugefaange mat Single-Thread Testen op enger lokaler Maschinn, mir de Punkt vum Multi-threaded Autotest erreecht hunn, deen op Selenoid an der Baupipeline leeft mat engem Allure Bericht op GitLab Säiten a schliisslech e coolt Automatisatiounsinstrument kruten datt zukünfteg Leit Teams benotze kënnen.
Wou hu mer ugefaang?
Fir Autotester ëmzesetzen an an d'Pipeline z'integréieren, brauche mir en Automatisatiounskader, dee flexibel geännert ka ginn fir eise Besoinen ze passen. Idealerweis wollt ech en eenzege Standard fir den Autotestmotor kréien, adaptéiert fir Autotester an d'Pipeline z'integréieren. Fir d'Ëmsetzung hu mir déi folgend Technologien gewielt:
- Java,
- Maven,
- Selen,
- Gurken+JUNIT 4,
- Allure,
- GitLab.
Firwat dëse spezielle Set? Java ass eng vun de beléifste Sprooche fir automatiséiert Tester, an all Teammember schwätzen et. Selenium ass déi offensichtlech Léisung. Gurken, ënner anerem, sollt d'Vertrauen an d'Resultater vun automatiséierten Tester op der Säit vun den Departementer, déi an der manueller Tester involvéiert sinn, erhéijen.
Single threaded Tester
Fir d'Rad net nei ze erfannen, hu mir Entwécklungen aus verschiddene Repositories op GitHub als Basis fir de Kader geholl an se fir eis selwer ugepasst. Mir hunn e Repository fir d'Haaptbibliothéik erstallt mam Kär vum Autotest Kader an e Repository mat engem Gold Beispill fir Autotester op eisem Kär ëmzesetzen. All Team huet missen d'Gold-Bild huelen an Tester dran entwéckelen, et un hire Projet adaptéieren. Mir hunn et op d'GitLab-CI Bank ofgesat, op där mir konfiguréiert hunn:
- deeglech Laf vun all schrëftlech autotests fir all Projet;
- lancéiert am Bau Pipeline.
Am Ufank waren et wéineg Tester, a si goufen an engem Stroum duerchgefouert. Single-threaded Lafen um Windows Leefer GitLab passt eis ganz gutt: d'Tester hunn d'Testbänk ganz liicht gelueden a bal keng Ressourcen benotzt.
Mat der Zäit gouf d'Zuel vun den Autotester ëmmer méi vill, a mir hu geduecht, se parallel ze lafen, wann e komplette Laf ongeféier dräi Stonnen ugefaang huet. Aner Probleemer sinn och opgetrueden:
- mir konnten net verifizéieren datt d'Tester stabil waren;
- Tester, déi e puer Mol hannereneen op der lokaler Maschinn lafen, sinn heiansdo am CI erofgefall.
Beispill fir Autotester opzestellen:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<skipTests>${skipTests}</skipTests>
<testFailureIgnore>false</testFailureIgnore>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>io.qameta.allure</groupId>
<artifactId>allure-maven</artifactId>
<version>2.9</version>
</plugin>
</plugins>
Allure Bericht Beispill
Runner Belaaschtung während Tester (8 Kären, 8 GB RAM, 1 Fuedem)
Virdeeler vun Single-threaded Tester:
- einfach ze installéieren an ze lafen;
- lancéiert am CI sinn praktesch net anescht aus lokal lancéiert;
- Tester beaflossen net all aner;
- Minimum Ufuerderunge fir Leefer Ressourcen.
Nodeeler vun Single-threaded Tester:
- huelen eng ganz laang Zäit ze kompletéieren;
- laang Stabiliséierung vun Tester;
- ineffizient Notzung vun Leefer Ressourcen, extrem niddereg Notzung.
Tester op JVM Gabel
Well mir net ëm thread-séchere Code gekëmmert hunn beim Implementéiere vum Basiskader, war de offensichtlechste Wee fir parallel ze lafen. fir Maven. De Plugin ass einfach ze konfiguréieren, awer fir eng korrekt parallel Operatioun mussen Autotester an getrennten Browser lafen. Et gëtt näischt ze maachen, ech hu misse Selenoid benotzen.
De Selenoid Server gouf op enger Maschinn mat 32 Cores an 24 GB RAM gestart. D'Limite gouf op 48 Browser gesat - 1,5 Threads pro Kär an ongeféier 400 MB RAM. Als Resultat gouf d'Testzäit vun dräi Stonnen op 40 Minutten reduzéiert. D'Beschleunegung vun de Runen huet gehollef de Stabiliséierungsproblem ze léisen: elo konnte mir séier nei Autotester 20-30 Mol ausféieren bis mir sécher waren datt se zouverlässeg lafen.
Den éischten Nodeel vun der Léisung war déi héich Notzung vu Leeferressourcen mat enger klenger Unzuel vu parallele thread: op 4 Cores an 8 GB RAM hunn d'Tester stabil an net méi wéi 6 thread gelaf. Den zweeten Nodeel: de Plugin generéiert Leeferklassen fir all Szenario, egal wéi vill vun hinnen lancéiert ginn.
Wichteg! Gitt keng Variabel mat Tags un argLinn, zum Beispill, esou:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Wann Dir de Tag op dës Manéier passéiert, generéiert de Plugin Leefer fir all Tester, dat heescht, et wäert probéieren all Tester auszeféieren, se direkt nom Start ze sprangen a vill JVM Gabel ze kreéieren.
Et ass richteg eng Variabel mat engem Tag anzewerfen Tags an de Plugin-Astellungen, kuckt Beispill hei drënner. Aner Methoden, déi mir getest hunn, hu Probleemer mam Allure Plugin ze verbannen.
Beispill vun Laafzäit fir 6 kuerz Tester mat falschen Astellungen:
[INFO] Total time: 03:17 min
Beispill vun Test Laf Zäit wann Dir direkt den Tag Transfert un mvn... –Dcucumber.optiounen:
[INFO] Total time: 44.467 s
Beispill fir Autotester opzestellen:
<profiles>
<profile>
<id>parallel</id>
<build>
<plugins>
<plugin>
<groupId>com.github.temyers</groupId>
<artifactId>cucumber-jvm-parallel-plugin</artifactId>
<version>5.0.0</version>
<executions>
<execution>
<id>generateRunners</id>
<phase>generate-test-sources</phase>
<goals>
<goal>generateRunners</goal>
</goals>
<configuration>
<tags>
<tag>${TAGS}</tag>
</tags>
<glue>
<package>stepdefs</package>
</glue>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
<forkCount>12</forkCount>
<reuseForks>false</reuseForks>
<includes>**/*IT.class</includes>
<testFailureIgnore>false</testFailureIgnore>
<!--suppress UnresolvedMavenProperty -->
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar" -Dcucumber.options="--plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm TagPFAllureReporter --plugin pretty"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
Beispill vun engem Allure Bericht (deen onbestännegsten Test, 4 Wiederholungen)
Runner Belaaschtung während Tester (8 Kären, 8 GB RAM, 12 Threads)
Pros:
- einfache Setup - Dir musst just e Plugin addéieren;
- d'Fäegkeet fir gläichzäiteg eng grouss Zuel vun Tester auszeféieren;
- Beschleunegung vun der Teststabiliséierung duerch Schrëtt 1.
Muecht:
- Multiple OS / Container erfuerderlech;
- héije Ressourceverbrauch fir all Gabel;
- De Plugin ass veroudert an net méi ënnerstëtzt.
Wéi Instabilitéit ze iwwerwannen
Testbänke sinn net ideal, sou wéi d'Autotester selwer. Et ass net iwwerraschend datt mir eng Zuel vu flacky Tester hunn. Komm zur Rettung, déi aus der Këscht ënnerstëtzt d'neustart vun gescheiterten Tester. Dir musst d'Plugin-Versioun op d'mannst 2.21 aktualiséieren an eng Zeil mat der Zuel vun de Restarts an der Pom-Datei schreiwen oder als Argument un Maven weiderginn.
Beispill fir Autotester opzestellen:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Oder beim Startup: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Als Optioun, setze Maven Optiounen fir de PowerShell Skript (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- keng Noutwendegkeet Zäit ze verschwenden fir en onbestänneg Test ze analyséieren wann et crasht;
- Testbänk Stabilitéitsproblemer kënne reduzéiert ginn.
Muecht:
- schwiewend Mängel kënne verpasst ginn;
- lafen Zäit vergréissert.
Parallel Tester mat der Cucumber 4 Bibliothéik
D'Zuel vun den Tester ass all Dag gewuess. Mir hu rem geduecht fir d'Lafen ze beschleunegen. Zousätzlech wollt ech sou vill Tester wéi méiglech an d'Applikatiounsmontage Pipeline integréieren. De kritesche Faktor war datt d'Generatioun vu Leefer ze laang gedauert huet wann se parallel mam Maven Plugin lafen.
Zu där Zäit war Cucumber 4 scho verëffentlecht ginn, also hu mir décidéiert de Kernel fir dës Versioun ëmzeschreiwen. An de Verëffentlechungsnotizen goufe mir parallele Start um threadniveau versprach. Theoretesch sollt dëst gewiescht sinn:
- d'Ausféierung vun Autotester wesentlech beschleunegen andeems d'Zuel vun de thread eropgeet;
- eliminéiert de Verloscht vun Zäit op Generéiere Leefer fir all autotest.
D'Optimiséierung vum Kader fir Multi-threaded Autotester huet sech net sou schwéier gewisen. Cucumber 4 fiert all eenzelnen Test op engem speziellen Fuedem vun Ufank bis Enn, sou datt e puer allgemeng statesch Saachen einfach an ThreadLocal Variablen ëmgewandelt goufen.
Den Haapt Saach beim Ëmwandlung mat Idea Refactoring Tools ass d'Plazen ze kontrolléieren wou d'Variabel vergläicht gouf (zum Beispill d'Check op Null). Zousätzlech musst Dir den Allure Plugin der Junit Runner Klass Annotatioun addéieren.
Beispill fir Autotester opzestellen:
<profile>
<id>parallel</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<useFile>false</useFile>
<testFailureIgnore>false</testFailureIgnore>
<parallel>methods</parallel>
<threadCount>6</threadCount>
<perCoreThreadCount>true</perCoreThreadCount>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
Beispill vun engem Allure Bericht (deen onbestännegsten Test, 5 Wiederholungen)
Runner Belaaschtung während Tester (8 Kären, 8 GB RAM, 24 Threads)
Pros:
- niddereg Ressource Konsum;
- gebierteg Ënnerstëtzung vu Gurken - keng zousätzlech Tools erfuerderlech;
- d'Fäegkeet fir méi wéi 6 Threads pro Prozessorkär ze lafen.
Muecht:
- Dir musst sécher sinn datt de Code Multi-threaded Ausféierung ënnerstëtzt;
- d'Entrée Schwell erop.
Allure bericht op GitLab Säiten
Nodeems mir Multi-threaded Ausféierung agefouert hunn, hu mir ugefaang vill méi Zäit ze verbréngen fir Berichter ze analyséieren. Zu där Zäit hu mir all Bericht als Artefakt op GitLab missen eropluede, dann eroflueden an auspacken. Et ass net ganz bequem an dauert laang. A wann een aneren de Rapport fir sech selwer kucke wëll, da musse se déiselwecht Operatiounen maachen. Mir wollte méi séier Feedback kréien, a mir hunn eng Léisung fonnt - GitLab Säiten. Dëst ass eng agebaute Feature déi aus der Këscht an all rezent Versioune vu GitLab verfügbar ass. Erlaabt Iech statesch Siten op Ärem Server z'installéieren an Zougang zu hinnen iwwer en direkten Link.
All Screenshots vun Allure Berichter goufen op GitLab Säiten geholl. Skript fir de Bericht op GitLab Säiten z'installéieren - a Windows PowerShell (virdrun musst Dir Autotester ausféieren):
New-Item -ItemType directory -Path $testresulthistory | Out-Null
try {Invoke-WebRequest -Uri $hst -OutFile $outputhst}
Catch{echo "fail copy history"}
try {Invoke-WebRequest -Uri $hsttrend -OutFile $outputhsttrnd}
Catch{echo "fail copy history trend"}
mvn allure:report
#mvn assembly:single -PzipAllureReport
xcopy $buildlocationtargetsiteallure-maven-plugin* $buildlocationpublic /s /i /Y
Wat am Enn
Also, wann Dir denkt ob Dir Thread Safe Code am Cucumber Autotest Kader braucht, elo ass d'Äntwert offensichtlech - mat Cucumber 4 ass et einfach ze implementéieren, an doduerch d'Zuel vun de Threads déi gläichzäiteg lancéiert ginn wesentlech erhéicht. Mat dëser Method fir Tester ze lafen, gëtt d'Fro elo iwwer d'Performance vun der Maschinn mat Selenoid an der Testbank.
Praxis huet gewisen datt Autotester op Threads lafen erlaabt Iech Ressourceverbrauch op e Minimum mat der beschter Leeschtung ze reduzéieren. Wéi aus de Grafike gesi ka ginn, féiert d'Verdueblung vun Threads net zu enger ähnlecher Beschleunegung bei Leeschtungstester. Wéi och ëmmer, mir konnten méi wéi 2 automatiséiert Tester fir d'Applikatioun Build addéieren, déi souguer mat 200 Reruns an ongeféier 5 Minutten lafen. Dëst erlaabt Iech séier Feedback vun hinnen ze kréien, an, wann néideg, Ännerungen ze maachen an d'Prozedur erëm ze widderhuelen.
Source: will.com