Dabeşa me ji bo destpêkirina guhertoyên nû yên sepanan di hawîrdora hilberînê de lûleyên bi tevahî otomatîk diafirîne. Bê guman, ev ceribandinên fonksiyonê yên otomatîkî hewce dike. Li jêr qutkirinê çîrokek heye ku çawa, bi ceribandina yek-têlekê ya li ser makîneyek herêmî dest pê kir, em gihîştin nuqteya ototesta pir-tehlî ku li ser Selenoid-ê di lûleya çêkirinê de bi raporek Allure li ser rûpelên GitLab-ê tê xebitandin û di dawiyê de amûrek otomatîkî ya xweş peyda kir. ku mirovên pêşerojê dikarin tîm bikar bînin.
Me ji ku dest pê kir?
Ji bo bicihanîna ceribandinên otomatê û entegrekirina wan di boriyê de, me hewceyê çarçoveyek otomasyonê bû ku bi nermî were guheztin li gorî hewcedariyên me. Bi îdeal, min dixwest ku standardek yekane ji bo motora ceribandina otomatîkî bistînim, ku ji bo vegirtina testên otomatê di nav boriyê de hatî adaptekirin. Ji bo pêkanîna me teknolojiyên jêrîn hilbijart:
- Java,
- Maven,
- Selenium,
- Xiyar+JUNÎT 4,
- Dilkişîn,
- GitLab.
Çima ev set taybetî? Java yek ji zimanên herî populer e ji bo ceribandinên otomatîkî, û hemî endamên tîmê pê diaxivin. Selenium çareseriya eşkere ye. Xiyar, di nav tiştên din de, diviyabû ku bawerî bi encamên ceribandinên otomatîkî yên ji hêla beşên ku beşdarî ceribandina destan in zêde bike.
Testên yek-têkilî
Ji bo ku em çerxê ji nû ve îcad nekin, me pêşkeftinên ji depoyên cihêreng ên li ser GitHub-ê wekî bingehek çarçovê girt û wan ji xwe re adapte kir. Me ji bo pirtûkxaneya sereke depoyek bi bingehê çarçoweya ototestê û depoyek bi mînakek Zêrîn a pêkanîna testên xweser li ser bingeha xwe çêkir. Her tîm neçar bû ku wêneya Zêrîn bigire û di wê de ceribandinan pêş bixe, bi projeya xwe re biguncîne. Me ew li ser banka GitLab-CI, ya ku me mîheng kir, bicîh kir:
- ji bo her projeyê hemî ceribandinên xweser ên nivîskî yên rojane diçin;
- di lûleya çêkirinê de dest pê dike.
Di destpêkê de çend ceribandin hebûn, û ew di yek rê de hatin kirin. Rêvekirina yek-têlê li ser gerîdeya Windows-ê ya GitLab bi me re pir xweş tê: ceribandinan doşka testê pir sivik bar kirin û hema bêje ti çavkanî bikar neanîn.
Bi demê re, hejmara ototestan her ku çû pirtir bû, û em fikirîn ku wan paralel bimeşînin, dema ku bazdanek tam dest pê kir bi qasî sê demjimêran dirêj kir. Pirsgirêkên din jî xuya bûn:
- me nekarî verast bikin ku ceribandin stabîl bûn;
- testên ku çend caran li pey hev li ser makîneya herêmî hatin bezandin, carinan di CI de têk çûn.
Mînaka sazkirina testên xweser:
<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>
Mînaka rapora Allure
Di dema ceribandinan de barkirina runner (8 naverok, 8 GB RAM, 1 mijar)
Awantajên testên yek-têkilî:
- sazkirin û xebitandin hêsan e;
- destpêkirinên li CI bi pratîkî ji destpêkirinên herêmî ne cûda ne;
- îmtîhan bandorê li hev nakin;
- pêdiviyên herî kêm ji bo çavkaniyên runner.
Dezawantajên testên yek-têkilî:
- ji bo temamkirina demek pir dirêj digire;
- stabilîzasyona dirêj a ceribandinan;
- karanîna bêserûber a çavkaniyên bezê, karanîna pir kêm.
Testên li ser forkên JVM
Ji ber ku me gava pêkanîna çarçoweya bingehîn guh neda koda ewledar, awayê herî eşkere ji bo meşandina paralel bû. ji bo Maven. Pêvek hêsan e ku meriv mîheng bike, lê ji bo xebata paralel a rast, divê testên otomatîkî di gerokên cihêreng de werin meşandin. Tiştek ku ez bikim tune, neçar bûm ku Selenoid bikar bînim.
Pêşkêşkara Selenoid li ser makîneyek bi 32 core û 24 GB RAM hate destpêkirin. Sînor li ser 48 gerokan hate danîn - 1,5 mijarên serê bingehîn û nêzîkê 400 MB RAM. Wekî encamek, dema ceribandinê ji sê saetan daket 40 hûrdeman. Zûtirkirina rêveçûnan alîkariya çareserkirina pirsgirêka stabilîzasyonê kir: naha me dikaribû tavilê 20-30 caran ototestên nû bimeşînin heya ku em piştrast bûn ku ew pêbawer dimeşin.
Yekem kêmasiya çareseriyê karanîna zêde ya çavkaniyên bezê bi hejmareke piçûk mijarên paralel bû: li ser 4 core û 8 GB RAM, ceribandin bi domdarî di 6 mijaran de ne zêdetir derbas bûn. Kêmasiya duyemîn: pêvek ji bo her senaryoyê dersên bezê diafirîne, çuqas ji wan têne destpêkirin.
Girîng! Guherbarek bi etîketan derbas neke argLine, bo nimûne, bi vî rengî:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ger hûn etîketê bi vî rengî derbas bikin, pêvek dê ji bo hemî ceribandinan bazdan biafirîne, ango, ew ê hewl bide ku hemî ceribandinan bimeşîne, tavilê piştî destpêkirinê wan berde û gelek forkên JVM biafirîne.
Rast e ku meriv guhêrbarek bi etîketekê bavêje nav tags di mîhengên pêvekê de, mînaka jêrîn bibînin. Rêbazên din ên ku me ceribandin di girêdana pêveka Allure de pirsgirêk hene.
Mînak dema xebitandinê ji bo 6 ceribandinên kurt ên bi mîhengên nerast:
[INFO] Total time: 03:17 min
Mînaka dema xebitandina ceribandinê heke hûn rasterast etîketê veguhezînin mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Mînaka sazkirina testên xweser:
<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>
Nimûneya raporek Allure (testa herî bêhêz, 4 dubarekirin)
Di dema ceribandinan de barkirina runner (8 core, 8 GB RAM, 12 kêşan)
Pros:
- sazkirina hêsan - hûn tenê hewce ne ku pêvekek lê zêde bikin;
- şiyana ku meriv bi hevdemî hejmareke mezin ceribandinan pêk bîne;
- lezkirina stabilîzasyona testê bi saya gava 1.
Bawer:
- Gelek OS / konteynir hewce ne;
- serfkirina çavkaniyê ya bilind ji bo her fork;
- Pêvek kevn e û êdî nayê piştgirî kirin.
Meriv çawa bêîstiqrariyê derbas dike
Bendên testê ne îdeal in, mîna ku ototest bixwe. Ne ecêb e ku me çend ceribandinên şikestî hene. Ji bo rizgariyê hat, ya ku ji qutiyê ji nû ve destpêkirina ceribandinên têkçûyî piştgirî dike. Pêdivî ye ku hûn guhertoya pêvekê bi kêmî ve 2.21 nûve bikin û yek rêzek bi hejmara nûvekirinan di pelê pom de binivîsin an wê wekî argumanek ji Maven re derbas bikin.
Mînaka sazkirina testên xweser:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
An jî di destpêkê de: mvn… -Dsurefire.rerunFailingTestsCount=2…
Wekî vebijark, vebijarkên Maven ji bo skrîpta PowerShell (PS1) saz bikin:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- ne hewce ye ku wextê wenda bikin ji bo analîzkirina ceribandinek bêîstiqrar dema ku ew têk diçe;
- Pirsgirêkên îstîqrara beşê ceribandinê dikarin bêne kêm kirin.
Bawer:
- kêmasiyên herikîn dikarin ji bîr nebin;
- dema xebitandinê zêde dibe.
Testên paralel bi pirtûkxaneya Cucumber 4 re
Hejmara testan her roj zêde dibû. Em dîsa li ser lezkirina bazdan fikirîn. Digel vê yekê, min dixwest ku bi qasî ku gengaz be ceribandinan di lûleya meclîsa serîlêdanê de yek bikim. Faktora krîtîk ev bû ku nifşa bazdan dema ku paralel bi karanîna pêveka Maven dimeşîne pir dirêj girt.
Wê demê, Cucumber 4 berê hatibû berdan, ji ber vê yekê me biryar da ku em kernelê ji bo vê versiyonê ji nû ve binivîsin. Di notên berdanê de ji me re soza destpêkirina paralel di asta mijarê de hat dayîn. Di teorîk de divê ev bûya:
- bi zêdekirina hejmara mijaran bi girîngî lezkirina xebitandina ototestan;
- ji bo her ototestê windabûna demê li ser hilberîna bezê hilweşînin.
Optimîzekirina çarçoweya ji bo ototestên pir-mijarî ne ew çend dijwar bû. Xiyar 4 her ceribandinek kesane li ser mijarek veqetandî ji destpêkê heya dawiyê dimeşîne, ji ber vê yekê hin tiştên statîk ên hevpar bi hêsanî veguheztin guhêrbarên ThreadLocal.
Tişta sereke dema veguheztina bi karanîna amûrên refaktorkirina Idea ev e ku meriv cîhên ku guhêrbar lê hatî berhev kirin kontrol bikin (mînakî, kontrolkirina null). Wekî din, hûn hewce ne ku pêveka Allure li annotasyona pola Junit Runner zêde bikin.
Mînaka sazkirina testên xweser:
<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>
Nimûneya raporek Allure (testa herî bêhêz, 5 dubarekirin)
Di dema ceribandinan de barkirina runner (8 core, 8 GB RAM, 24 kêşan)
Pros:
- mezaxtina çavkaniyê kêm;
- Piştgiriya xwecî ji Xiyarê - tu amûrên zêde hewce nake;
- şiyana xebitandina zêdetirî 6 mijaran li ser bingehek pêvajoyê.
Bawer:
- Pêdivî ye ku hûn pê ewle bibin ku kod bi darvekirina pir-mijarî piştgirî dike;
- sînorê têketinê zêde dibe.
Raporên Allure li ser rûpelên GitLab
Piştî danasîna darvekirina pir-mijarî, me dest bi analîzkirina raporan pir zêdetir wext kir. Wê demê, me neçar ma ku her raporê wekî hunerek li GitLab bar bikin, dûv re wê dakêşin û jê pak bikin. Ew ne pir hêsan e û demek dirêj digire. Û heger kesek din bixwaze raporê ji xwe re bibîne, wê hingê ew ê hewce bike ku heman operasyonan bikin. Me xwest ku em zûtir bersiv bistînin, û me çareseriyek dît - Rûpelên GitLab. Ev taybetmendiyek çêkirî ye ku di hemî guhertoyên dawî yên GitLab de ji hundurê qutiyê peyda dibe. Destûrê dide we ku hûn malperên statîk li ser servera xwe bicîh bikin û bi girêdanek rasterast bigihîjin wan.
Hemî dîmenên raporên Allure li ser rûpelên GitLab hatine girtin. Skrîpta ji bo bicihkirina raporê li ser rûpelên GitLab - di Windows PowerShell de (berî vê yekê hûn hewce ne ku ceribandinên otomatîkî bimeşînin):
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
Di dawiyê de çi ye
Ji ber vê yekê, heke hûn difikirîn ka gelo hûn hewceyê koda ewledar a Mijara di çarçoveya xweseriya Xiyarê de ne, naha bersiv eşkere ye - bi Cucumber 4 re pêkanîna wê hêsan e, bi vî rengî hejmara mijarên ku di heman demê de hatine destpêkirin bi girîngî zêde dike. Bi vê rêbazê ceribandinên xebitandinê re, pirs naha di derbarê performansa makîneya bi Selenoid û bendera ceribandinê de dibe.
Pratîk destnîşan kir ku ceribandinên otomatîkî yên li ser mijaran rê dide we ku hûn bi performansa çêtirîn vexwarina çavkaniyê bi kêmanî kêm bikin. Wekî ku ji grafikan tê dîtin, ducarkirina têlan di ceribandinên performansê de rê nade bilezbûnek wekhev. Lêbelê, me karî zêdetirî 2 ceribandinên otomatîkî li avakirina serîlêdanê zêde bikin, ku tewra bi 200 dubareyan re di nav 5 hûrdeman de dimeşîne. Ev dihêle hûn ji wan re bertekên bilez bistînin, û ger hewce be, guhertinan bikin û prosedurê dîsa dubare bikin.
Source: www.habr.com