Deildin okkar býr til fullsjálfvirkar leiðslur til að setja nýjar útgáfur af forritum inn í framleiðsluumhverfið. Þetta krefst auðvitað sjálfvirkra virkniprófa. Fyrir neðan klippinguna er saga um hvernig við, sem byrjaði með einsþræðisprófun á staðbundinni vél, náðum þeim áfanga að fjölþráða sjálfvirka prófun var keyrð á Selenoid í smíðunarpípunni með Allure skýrslu á GitLab síðum og fengum að lokum flott sjálfvirkniverkfæri að framtíðarfólk geti notað lið.
Hvar byrjuðum við?
Til að innleiða sjálfvirkar prófanir og samþætta þær í leiðsluna þurftum við sjálfvirkniramma sem hægt var að breyta á sveigjanlegan hátt til að henta þörfum okkar. Helst vildi ég fá einn staðal fyrir sjálfvirka prófunarvélina, aðlagað til að fella sjálfvirkar prófanir inn í leiðsluna. Til innleiðingar völdum við eftirfarandi tækni:
- Java,
- Maven,
- Selen,
- Gúrka+JUNIT 4,
- Allure,
- GitLab.
Hvers vegna þetta tiltekna sett? Java er eitt vinsælasta tungumálið fyrir sjálfvirk próf og allir liðsmenn tala það. Selen er augljós lausn. Gúrka átti meðal annars að auka traust á niðurstöðum sjálfvirkra prófa af hálfu deilda sem sinna handvirkum prófum.
Einþráðar prófanir
Til þess að finna ekki upp hjólið að nýju tókum við þróun frá ýmsum geymslum á GitHub sem grunn að rammanum og aðlöguðum þær að okkur sjálfum. Við bjuggum til geymslu fyrir aðalsafnið með kjarna sjálfprófunarrammans og geymslu með gulldæmi um innleiðingu sjálfvirkra prófana á kjarnanum okkar. Hvert lið þurfti að taka Gullmyndina og þróa próf í henni og laga hana að verkefninu sínu. Við sendum það í GitLab-CI bankann, sem við stilltum á:
- daglegar keyrslur allra skriflegra sjálfvirkra prófana fyrir hvert verkefni;
- kynnir í smíðum.
Í fyrstu voru fáar prófanir og voru þær framkvæmdar í einum straumi. Einþráður keyrsla á Windows hlauparanum GitLab hentaði okkur nokkuð vel: prófin hlóðu prófunarbekkinn mjög létt og notuðu nánast engin úrræði.
Með tímanum fjölgaði sjálfvirkum prófunum og við hugsuðum að keyra þau samhliða þegar full keyrsla fór að taka um þrjár klukkustundir. Önnur vandamál komu einnig fram:
- við gátum ekki sannreynt að prófin væru stöðug;
- prófanir sem voru keyrðar nokkrum sinnum í röð á staðbundinni vél hrundu stundum í CI.
Dæmi um að setja upp sjálfvirkar prófanir:
<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 skýrslu dæmi
Hleðsla á hlaupara meðan á prófunum stendur (8 kjarna, 8 GB vinnsluminni, 1 þráður)
Kostir við einþráða próf:
- auðvelt að setja upp og keyra;
- kynningar í CI eru nánast ekkert frábrugðnar staðbundnum kynningum;
- próf hafa ekki áhrif á hvert annað;
- lágmarkskröfur um hlauparaauðlindir.
Ókostir við einþráðar prófanir:
- taka mjög langan tíma að klára;
- langur stöðugleiki prófana;
- óhagkvæm nýting hlauparaauðlinda, afar lítil nýting.
Prófanir á JVM gafflum
Þar sem við sáum ekki um þráð-öruggan kóða við innleiðingu grunnramma, var augljósasta leiðin til að keyra samhliða fyrir Maven. Auðvelt er að stilla viðbótina, en fyrir rétta samhliða notkun verður að keyra sjálfvirkar prófanir í aðskildum vöfrum. Það er ekkert að gera, ég þurfti að nota Selenoid.
Selenoid miðlarinn var settur á vél með 32 kjarna og 24 GB af vinnsluminni. Takmarkið var sett við 48 vafra - 1,5 þræði á kjarna og um 400 MB af vinnsluminni. Þess vegna var prófunartíminn styttur úr þremur klukkustundum í 40 mínútur. Að flýta hlaupunum hjálpaði til við að leysa stöðugleikavandamálið: nú gátum við keyrt nýjar sjálfvirkar prófanir 20–30 sinnum þar til við vorum viss um að þær virkuðu á áreiðanlegan hátt.
Fyrsti galli lausnarinnar var mikil nýting á hlauparaauðlindum með fáum samhliða þráðum: á 4 kjarna og 8 GB af vinnsluminni gengu prófin stöðugt í ekki meira en 6 þræði. Annar ókosturinn: viðbótin býr til hlauparaflokka fyrir hverja atburðarás, sama hversu margir þeirra eru settir af stað.
Mikilvægt! Ekki senda breytu með merkjum til argLínatd svona:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Ef þú framhjá merkinu á þennan hátt mun viðbótin búa til hlaupara fyrir öll próf, það er, það mun reyna að keyra öll próf, sleppa þeim strax eftir ræsingu og búa til marga JVM gaffla.
Rétt er að henda breytu með merki inn í Tags í stillingum viðbótarinnar, sjá dæmi hér að neðan. Aðrar aðferðir sem við prófuðum eiga í vandræðum með að tengja Allure viðbótina.
Dæmi um keyrslutíma fyrir 6 stuttar prófanir með rangar stillingar:
[INFO] Total time: 03:17 min
Dæmi um prófunartíma ef þú flytur merkið beint á mvn... –Gúrka.valkostir:
[INFO] Total time: 44.467 s
Dæmi um að setja upp sjálfvirkar prófanir:
<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>
Dæmi um Allure skýrslu (óstöðugasta prófið, 4 endursýningar)
Hleðsla á hlaupara meðan á prófunum stendur (8 kjarna, 8 GB vinnsluminni, 12 þræðir)
Kostir:
- auðveld uppsetning - þú þarft bara að bæta við viðbót;
- getu til að framkvæma fjölda prófana samtímis;
- hröðun á stöðugleika prófunar þökk sé skrefi 1.
Gallar:
- Mörg stýrikerfi/ílát krafist;
- mikil auðlindanotkun fyrir hvern gaffal;
- Viðbótin er úrelt og ekki lengur studd.
Hvernig á að sigrast á óstöðugleika
Prófunarbekkir eru ekki tilvalin, rétt eins og sjálfvirkar prófanir sjálfar. Það kemur ekki á óvart að við höfum fjölda lélegra prófana. Kom til bjargar, sem úr kassanum styður endurræsingu á misheppnuðum prófum. Þú þarft að uppfæra viðbótaútgáfuna í að minnsta kosti 2.21 og skrifa eina línu með fjölda endurræsinga í pom skránni eða senda það sem rök til Maven.
Dæmi um að setja upp sjálfvirkar prófanir:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Eða við ræsingu: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Sem valkostur skaltu stilla Maven valkosti fyrir PowerShell handritið (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Kostir:
- engin þörf á að eyða tíma í að greina óstöðugt próf þegar það hrynur;
- Hægt er að draga úr stöðugleikavandamálum á prófunarbekknum.
Gallar:
- hægt er að missa af fljótandi galla;
- keyrslutími eykst.
Samhliða próf með Cucumber 4 bókasafninu
Prófunum fjölgaði með hverjum deginum. Við hugsuðum aftur um að flýta hlaupunum. Að auki vildi ég samþætta eins mörg próf og mögulegt er í samsetningarleiðslan fyrir forritið. Mikilvægi þátturinn var sá að kynslóð hlaupara tók of langan tíma þegar hlaupið var samhliða með Maven viðbótinni.
Á þeim tíma hafði Cucumber 4 þegar verið gefið út, svo við ákváðum að endurskrifa kjarnann fyrir þessa útgáfu. Í útgáfuskýringunum var okkur lofað samhliða kynningu á þræðistigi. Fræðilega hefði þetta átt að vera:
- flýta verulega fyrir keyrslu sjálfvirkra prófana með því að fjölga þráðum;
- koma í veg fyrir tímatap við að búa til hlaupara fyrir hvert sjálfvirkt próf.
Það reyndist ekki svo erfitt að fínstilla rammann fyrir fjölþráða sjálfvirkar prófanir. Cucumber 4 keyrir hvert einstakt próf á sérstökum þræði frá upphafi til enda, þannig að sumum algengum kyrrstæðum hlutum var einfaldlega breytt í ThreadLocal breytur.
Aðalatriðið þegar þú umbreytir með því að nota Idea refactoring verkfæri er að athuga þá staði þar sem breytan var borin saman (til dæmis að athuga með núll). Að auki þarftu að bæta Allure viðbótinni við Junit Runner bekkjarskýringuna.
Dæmi um að setja upp sjálfvirkar prófanir:
<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>
Dæmi um Allure skýrslu (óstöðugasta prófið, 5 endursýningar)
Hleðsla hlaupara meðan á prófunum stendur (8 kjarna, 8 GB vinnsluminni, 24 þræðir)
Kostir:
- lítil auðlindanotkun;
- innfæddur stuðningur frá agúrka - engin viðbótarverkfæri krafist;
- getu til að keyra meira en 6 þræði á hvern örgjörvakjarna.
Gallar:
- þú þarft að tryggja að kóðinn styðji fjölþráða framkvæmd;
- inngöngumörk hækkar.
Allure segir frá GitLab síðum
Eftir að hafa kynnt margþráða framkvæmd fórum við að eyða miklu meiri tíma í að greina skýrslur. Á þeim tíma þurftum við að hlaða upp hverri skýrslu sem grip í GitLab, síðan hlaða henni niður og pakka henni upp. Það er ekki mjög þægilegt og tekur langan tíma. Og ef einhver annar vill skoða skýrsluna sjálfur, þá verður hann að gera sömu aðgerðir. Við vildum fá endurgjöf hraðar og við fundum lausn - GitLab síður. Þetta er innbyggður eiginleiki sem er fáanlegur strax í öllum nýlegum útgáfum af GitLab. Gerir þér kleift að dreifa kyrrstæðum síðum á netþjóninum þínum og fá aðgang að þeim með beinum hlekk.
Öll skjáskot af Allure skýrslum voru tekin á GitLab síðum. Forskrift til að dreifa skýrslunni á GitLab síður - í Windows PowerShell (áður en þetta þarftu að keyra sjálfvirkar prófanir):
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
Með þeim afleiðingum að
Svo ef þú varst að velta því fyrir þér hvort þú þurfir Þráðaröryggiskóða í sjálfvirka prófunarrammanum Cucumber, þá er svarið augljóst - með Cucumber 4 er auðvelt að innleiða hann og þar með fjölga þráðum sem eru opnir samtímis verulega. Með þessari aðferð til að keyra prófana verður spurningin núna um frammistöðu vélarinnar með Selenoid og prófunarbekknum.
Æfingin hefur sýnt að að keyra sjálfvirkar prófanir á þræði gerir þér kleift að draga úr auðlindanotkun í lágmarki með bestu frammistöðu. Eins og sést á línuritunum leiðir tvöföldun þráða ekki til svipaðrar hröðunar í frammistöðuprófum. Hins vegar gátum við bætt meira en 2 sjálfvirkum prófum við forritagerðina, sem jafnvel með 200 endursýningar keyra á um það bil 5 mínútum. Þetta gerir þér kleift að fá skjót viðbrögð frá þeim og, ef nauðsyn krefur, gera breytingar og endurtaka ferlið aftur.
Heimild: www.habr.com