Nia dividado kreas plene aŭtomatajn duktojn por lanĉi novajn versiojn de aplikoj en la produktadmedion. Kompreneble, ĉi tio postulas aŭtomatigitajn funkciajn testojn. Sub la tranĉo estas rakonto pri kiel, komencante kun unufadena testado sur loka maŝino, ni daŭriĝis al multfadenaj aŭtotestoj kurantaj sur Selenoid en la konstrua dukto kun Allure-raporto sur GitLab-paĝoj kaj fine akiris bonegan aŭtomatigan ilon, kiu estontaj homoj povas uzi teamojn.
De kie ni komencis?
Por efektivigi aŭtotestojn kaj integri ilin en la dukto, ni bezonis aŭtomatigan kadron, kiu povus esti flekseble ŝanĝita por konveni niajn bezonojn. Ideale, mi volis akiri ununuran normon por la aŭtotesta motoro, adaptita por enigi aŭtotestojn en la dukto. Por efektivigo ni elektis la jenajn teknologiojn:
- Java,
- Maven,
- Seleno,
- Kukumo+JUNIO 4,
- Allogo,
- GitLab.
Kial ĉi tiu aparta aro? Java estas unu el la plej popularaj lingvoj por aŭtomataj testoj, kaj ĉiuj teamanoj parolas ĝin. Seleno estas la evidenta solvo. Kukumo, interalie, laŭsupoze pliigis fidon je la rezultoj de aŭtomatigitaj testoj fare de fakoj implikitaj en manlibrotestado.
Unufadenaj provoj
Por ne reinventi la radon, ni prenis evoluojn de diversaj deponejoj sur GitHub kiel bazon por la kadro kaj adaptis ilin por ni mem. Ni kreis deponejon por la ĉefa biblioteko kun la kerno de la aŭtotest-kadro kaj deponejon kun Ora ekzemplo de efektivigado de aŭtotestoj sur nia kerno. Ĉiu teamo devis preni la Oran bildon kaj evoluigi testojn en ĝi, adaptante ĝin al sia projekto. Ni deplojis ĝin al la banko GitLab-CI, sur kiu ni agordis:
- ĉiutagaj kuroj de ĉiuj skribitaj aŭtotestoj por ĉiu projekto;
- lanĉas en la konstrua dukto.
Komence estis malmultaj provoj, kaj ili estis faritaj en unu rivereto. Unufadena funkciado sur la Vindoza kuristo GitLab sufiĉe bone konvenis al ni: la testoj ŝarĝis la testbenkon tre malpeze kaj uzis preskaŭ neniujn rimedojn.
Kun la tempo, la nombro da aŭtotestoj fariĝis pli kaj pli multnombra, kaj ni pensis pri rulado de ili paralele, kiam plena kurado komencis daŭri ĉirkaŭ tri horojn. Aliaj problemoj ankaŭ aperis:
- ni ne povis kontroli, ke la testoj estas stabilaj;
- provoj kiuj estis rulitaj plurfoje en vico sur la loka maŝino foje kraŝis en CI.
Ekzemplo de agordo de aŭtotestoj:
<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>
Ekzemplo de raporto Allure
Kura ŝarĝo dum testoj (8 kernoj, 8 GB RAM, 1 fadeno)
Avantaĝoj de unufadenaj testoj:
- facile agordi kaj kuri;
- lanĉoj en CI preskaŭ ne diferencas de lokaj lanĉoj;
- provoj ne influas unu la alian;
- minimumaj postuloj por kurantaj rimedoj.
Malavantaĝoj de unufadenaj testoj:
- prenu tre longan tempon por kompletigi;
- longa stabiligo de provoj;
- malefika uzo de kurantaj rimedoj, ekstreme malalta utiligo.
Testoj sur JVM-forkoj
Ĉar ni ne zorgis pri faden-sekura kodo dum la efektivigo de la baza kadro, la plej evidenta maniero funkcii paralele estis por Maven. La kromaĵo estas facile agordebla, sed por ĝusta paralela funkciado, aŭtotestoj devas esti rulitaj en apartaj retumiloj. Estas nenio por fari, mi devis uzi Selenoid.
La Selenoid-servilo estis lanĉita sur maŝino kun 32 kernoj kaj 24 GB da RAM. La limo estis fiksita je 48 retumiloj - 1,5 fadenoj per kerno kaj ĉirkaŭ 400 MB da RAM. Kiel rezulto, la testtempo estis reduktita de tri horoj al 40 minutoj. Plirapidigi la kurojn helpis solvi la stabiligan problemon: nun ni povis rapide ruli novajn aŭtotestojn 20–30 fojojn ĝis ni certiĝus, ke ili funkcias fidinde.
La unua malavantaĝo de la solvo estis la alta utiligo de kurantaj rimedoj kun malgranda nombro da paralelaj fadenoj: sur 4 kernoj kaj 8 GB da RAM, la testoj kuris stabile en ne pli ol 6 fadenoj. La dua malavantaĝo: la kromaĵo generas kurantajn klasojn por ĉiu scenaro, negrave kiom da ili estas lanĉitaj.
Grava! Ne pasu variablon kun etikedoj al argLine, ekzemple, jene:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Se vi pasas la etikedon tiamaniere, la kromaĵo generos kuristojn por ĉiuj testoj, tio estas, ĝi provos ruli ĉiujn testojn, preterlasante ilin tuj post lanĉo kaj kreante multajn JVM-forkojn.
Estas ĝuste ĵeti variablon kun etikedo enen etikedoj en la aldonaĵagordoj, vidu ekzemplon sube. Aliaj metodoj, kiujn ni testis, havas problemojn por konekti la kromprogramon Allure.
Ekzemplo de rultempo por 6 mallongaj provoj kun malĝustaj agordoj:
[INFO] Total time: 03:17 min
Ekzemplo de prova rultempo se vi rekte translokigas la etikedon al mvn... –Dcucumber.opcioj:
[INFO] Total time: 44.467 s
Ekzemplo de agordo de aŭtotestoj:
<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>
Ekzemplo de Allure-raporto (la plej malstabila testo, 4 reruligoj)
Kura ŝarĝo dum testoj (8 kernoj, 8 GB RAM, 12 fadenoj)
Pros:
- facila agordo - vi nur bezonas aldoni kromprogramon;
- la kapablo samtempe plenumi grandan nombron da provoj;
- akcelo de testa stabiligo danke al paŝo 1.
Kons:
- Multoblaj OS/ujoj necesas;
- alta konsumo de rimedoj por ĉiu forko;
- La kromaĵo estas malmoderna kaj ne plu subtenata.
Kiel venki malstabilecon
Testbenkoj ne estas idealaj, same kiel la aŭtotestoj mem. Ne estas surprize, ke ni havas kelkajn malklarajn provojn. Venis al la savo, kiu el la skatolo subtenas rekomenci malsukcesajn testojn. Vi devas ĝisdatigi la kromprogramon al almenaŭ 2.21 kaj skribi unu linion kun la nombro da rekomencoj en la pom-dosiero aŭ transdoni ĝin kiel argumenton al Maven.
Ekzemplo de agordo de aŭtotestoj:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Aŭ dum ekfunkciigo: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Kiel opcio, agordu Maven-opciojn por la PowerShell-skripto (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- ne necesas malŝpari tempon analizante malstabilan teston kiam ĝi kraŝas;
- testbenko-stabilecproblemoj povas esti mildigitaj.
Kons:
- flosantaj difektoj povas esti maltrafitaj;
- rultempo pliiĝas.
Paralelaj provoj kun la Biblioteko Kukumo 4
La nombro da testoj kreskis ĉiutage. Ni denove pensis pri rapidigo de la kuroj. Krome, mi volis integri kiel eble plej multajn provojn en la aplikaĵan asembleodukton. La kritika faktoro estis, ke la generacio de kuristoj daŭris tro longe kiam kuris paralele uzante la aldonaĵon Maven.
Tiutempe, Kukumo 4 jam estis publikigita, do ni decidis reverki la kernon por ĉi tiu versio. En la eldonnotoj ni estis promesitaj paralela lanĉo ĉe la fadennivelo. Teorie ĉi tio devus estinti:
- signife akceli la funkciadon de aŭtotestoj pliigante la nombron da fadenoj;
- elimini la perdon de tempo dum generado de kuristoj por ĉiu aŭtotesto.
Optimumigi la kadron por multfadenaj aŭtotestoj montriĝis ne tiel malfacila. Kukumo 4 kuras ĉiun individuan teston sur dediĉita fadeno de komenco ĝis fino, do iuj komunaj senmovaj aferoj estis simple konvertitaj al ThreadLocal variabloj.
La ĉefa afero, kiam oni konvertas uzante Ideajn refaktorajn ilojn, estas kontroli la lokojn, kie la variablo estis komparita (ekzemple, kontrolante nulon). Krome, vi devas aldoni la Allure kromaĵon al la Junit Runner klaso komentario.
Ekzemplo de agordo de aŭtotestoj:
<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>
Ekzemplo de Allure-raporto (la plej malstabila testo, 5 reruligoj)
Kura ŝarĝo dum testoj (8 kernoj, 8 GB RAM, 24 fadenoj)
Pros:
- malalta konsumo de rimedoj;
- denaska subteno de Kukumo - ne necesas aldonaj iloj;
- la kapablo funkcii pli ol 6 fadenojn per procesoro-kerno.
Kons:
- vi devas certigi, ke la kodo subtenas multfadenan ekzekuton;
- la enira sojlo pliiĝas.
Allure raportas sur GitLab-paĝoj
Post enkonduko de multfadena ekzekuto, ni komencis pasigi multe pli da tempo analizante raportojn. Tiutempe, ni devis alŝuti ĉiun raporton kiel artefakto al GitLab, poste elŝuti ĝin kaj malpakigi ĝin. Ĝi ne estas tre oportuna kaj daŭras longan tempon. Kaj se iu alia volas vidi la raporton mem, tiam ili devos fari la samajn operaciojn. Ni volis ricevi komentojn pli rapide, kaj ni trovis solvon - GitLab-paĝoj. Ĉi tio estas enkonstruita funkcio, kiu haveblas el la skatolo en ĉiuj lastatempaj versioj de GitLab. Ebligas al vi disfaldi senmovajn retejojn sur via servilo kaj aliri ilin per rekta ligo.
Ĉiuj ekrankopioj de Allure-raportoj estis prenitaj sur GitLab-paĝoj. Skripto por deploji la raporton al GitLab-paĝoj - en Windows PowerShell (antaŭ tio vi devas ruli aŭtotestojn):
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
Kio estas la rezulto
Do, se vi pensis ĉu vi bezonas Thread-sekuran kodon en la aŭtotest-kadro de Cucumber, nun la respondo estas evidenta - kun Kukumo 4 estas facile efektivigi ĝin, tiel signife pliigante la nombron da fadenoj lanĉitaj samtempe. Kun ĉi tiu metodo de ekzekuto de provoj, la demando nun fariĝas pri la agado de la maŝino kun Selenoid kaj la testbenko.
Praktiko montris, ke ruli aŭtomatajn provojn sur fadenoj permesas redukti la konsumon de rimedoj al minimumo kun la plej bona rendimento. Kiel videblas el la grafikaĵoj, duobligado de fadenoj ne kondukas al simila akcelo en agado-testoj. Tamen, ni povis aldoni pli ol 2 aŭtomatigitajn testojn al la aplikaĵo, kiu eĉ kun 200 reruligoj funkcias en ĉirkaŭ 5 minutoj. Ĉi tio ebligas al vi ricevi rapidajn sugestojn de ili, kaj, se necese, fari ŝanĝojn kaj ripeti la proceduron denove.
fonto: www.habr.com