Divisi kita nggawe pipa otomatis kanthi otomatis kanggo ngluncurake versi aplikasi anyar menyang lingkungan produksi. Mesthi, iki mbutuhake tes fungsi otomatis. Ing ngisor potongan kasebut ana crita babagan carane, diwiwiti kanthi uji coba siji-utas ing mesin lokal, kita tekan titik autotest multi-threaded sing mlaku ing Selenoid ing pipa mbangun kanthi laporan Allure ing kaca GitLab lan pungkasane entuk alat otomatisasi sing apik. sing wong mangsa bisa nggunakake tim.
Ngendi kita miwiti?
Kanggo ngleksanakake tes otomatis lan nggabungake menyang pipa, kita butuh kerangka otomatisasi sing bisa diganti kanthi fleksibel supaya cocog karo kabutuhan. Saenipun, Aku wanted kanggo njaluk standar siji kanggo mesin autotesting, diadaptasi kanggo embedding autotests menyang pipeline. Kanggo implementasine, kita milih teknologi ing ngisor iki:
- Jawa,
- Maven,
- Selenium,
- Timun+JUNIT 4,
- daya tarik,
- GitLab.
Kenapa set khusus iki? Jawa minangka salah sawijining basa sing paling populer kanggo tes otomatis, lan kabeh anggota tim ngomongake. Selenium minangka solusi sing jelas. Timun, antara liya, mesthine nambah kapercayan ing asil tes otomatis ing bagean departemen sing melu uji coba manual.
Tes Utas tunggal
Supaya ora reinvent setir, kita njupuk pembangunan saka macem-macem repositori ing GitHub minangka basis kanggo framework lan dicocogake kanggo awake dhewe. Kita nggawe gudang kanggo perpustakaan utama kanthi inti saka kerangka autotest lan gudang kanthi conto Gold ngleksanakake autotest ing inti kita. Saben tim kudu njupuk gambar Emas lan nggawe tes ing, adaptasi karo proyeke. Kita nyebarake menyang bank GitLab-CI, sing dikonfigurasi:
- saben dina kabeh tes otomatis ditulis kanggo saben proyek;
- diluncurake ing pipa mbangun.
Ing kawitan ana sawetara tes, lan padha digawa metu ing siji stream. Utas tunggal mlaku ing pelari Windows GitLab cocog karo kita: tes kasebut ngemot bangku tes kanthi entheng lan meh ora nggunakake sumber daya.
Swara wektu, jumlah autotests dadi liyane lan liyane akeh, lan kita mikir bab mbukak ing podo karo, nalika roto lengkap wiwit njupuk bab telung jam. Masalah liyane uga muncul:
- kita ora bisa verifikasi manawa tes kasebut stabil;
- tes sing padha mbukak kaping pirang-pirang ing saurutan ing mesin lokal kadhangkala tabrakan ing CI.
Conto nyetel tes otomatis:
<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>
Tuladha laporan pisuhan
Beban pelari sajrone tes (8 intine, 8 GB RAM, 1 utas)
Pros saka tes single-threaded:
- gampang kanggo nyiyapake lan mbukak;
- diluncurake ing CI meh ora beda karo peluncuran lokal;
- tes ora mengaruhi saben liyane;
- syarat minimal kanggo sumber daya runner.
Kekurangan tes single-threaded:
- njupuk wektu dawa banget kanggo ngrampungake;
- stabilisasi tes dawa;
- panggunaan sumber daya runner sing ora efisien, panggunaan sing sithik banget.
Tes ing garpu JVM
Amarga kita ora ngurus kode aman thread nalika ngetrapake kerangka dhasar, cara sing paling jelas kanggo mlaku bebarengan yaiku kanggo Maven. Plugin kasebut gampang dikonfigurasi, nanging kanggo operasi paralel sing bener, tes otomatis kudu ditindakake ing browser sing kapisah. Ora ana apa-apa, aku kudu nggunakake Selenoid.
Server Selenoid iki dibukak ing mesin karo 32 intine lan 24 GB RAM. Watesan disetel ing 48 browser - 1,5 utas saben inti lan udakara 400 MB RAM. Akibaté, wektu tes dikurangi saka telung jam dadi 40 menit. Nyepetake lari mbantu ngatasi masalah stabilisasi: saiki kita bisa kanthi cepet nglakokake tes otomatis anyar 20-30 kaping nganti kita yakin manawa bisa mlaku kanthi andal.
Kerugian pisanan saka solusi kasebut yaiku panggunaan sumber daya pelari kanthi jumlah benang paralel sing sithik: ing 4 intine lan 8 GB RAM, tes kasebut mlaku kanthi stabil ing ora luwih saka 6 benang. Kerugian kapindho: plugin ngasilake kelas pelari kanggo saben skenario, ora ketompo carane akeh sing diluncurake.
Penting! Aja ngliwati variabel kanthi tag menyang argLine, contone, kaya iki:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Yen sampeyan ngliwati tag kanthi cara iki, plugin bakal ngasilake pelari kanggo kabeh tes, yaiku, bakal nyoba nglakokake kabeh tes, langsung diluncurake sawise diluncurake lan nggawe akeh garpu JVM.
Iku bener kanggo uncalan variabel karo tag menyang tags ing setelan plugin, ndeleng conto ing ngisor iki. Cara liya sing dites duwe masalah nyambungake plugin Allure.
Conto wektu mlaku kanggo 6 tes singkat kanthi setelan sing salah:
[INFO] Total time: 03:17 min
Conto wektu test run yen sampeyan langsung nransfer tag menyang mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Conto nyetel tes otomatis:
<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>
Conto laporan Allure (tes paling ora stabil, 4 ulangan)
Beban pelari sajrone tes (8 intine, 8 GB RAM, 12 utas)
Pros:
- persiyapan gampang - sampeyan mung kudu nambah plugin;
- kemampuan kanggo nindakake akeh tes bebarengan;
- akselerasi stabilisasi tes amarga langkah 1.
Cons:
- Multiple OS / wadhah dibutuhake;
- konsumsi sumber daya dhuwur kanggo saben garpu;
- Plugin wis lawas lan ora didhukung maneh.
Carane ngatasi kahanan kang ora tetep
Bangku tes ora cocog, kaya tes otomatis dhewe. Ora nggumunake yen kita duwe sawetara tes flacky. Teka kanggo ngluwari, sing metu saka kothak ndhukung miwiti maneh tes gagal. Sampeyan kudu nganyari versi plugin kanggo paling 2.21 lan nulis siji baris karo nomer restart ing file pom utawa pass minangka pitakonan kanggo Maven.
Conto nyetel tes otomatis:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Utawa nalika wiwitan: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Minangka pilihan, setel opsi Maven kanggo skrip PowerShell (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- ora perlu mbuwang wektu kanggo nganalisa tes sing ora stabil nalika nabrak;
- masalah stabilitas bench test bisa mitigated.
Cons:
- cacat ngambang bisa ora kejawab;
- wektu mbukak mundhak.
Tes podo karo perpustakaan Timun 4
Jumlah tes mundhak saben dina. Kita maneh mikir babagan nyepetake lari. Kajaba iku, aku pengin nggabungake pirang-pirang tes menyang pipa perakitan aplikasi. Faktor kritis yaiku generasi pelari njupuk wektu suwe banget nalika mlaku kanthi paralel nggunakake plugin Maven.
Ing wektu iku, Cucumber 4 wis dirilis, mula kita mutusake kanggo nulis ulang kernel kanggo versi iki. Ing cathetan release kita dijanjekake diluncurake paralel ing level thread. Secara teoritis iki kudune:
- kanthi nyata nyepetake tes otomatis kanthi nambah jumlah benang;
- ngilangke mundhut saka wektu ing ngasilaken balapan mlayu kanggo saben autotest.
Ngoptimalake kerangka kanggo autotes multi-threaded ternyata ora angel banget. Timun 4 nglakokake saben tes individu ing benang khusus saka wiwitan nganti rampung, mula sawetara perkara statis umum mung diowahi dadi variabel ThreadLocal.
Wangsulan: Bab ingkang utama nalika Ngonversi nggunakake alat Idea refactoring punika mriksa panggonan ngendi variabel dibandhingake (contone, mriksa null). Kajaba iku, sampeyan kudu nambah plugin Allure menyang anotasi kelas Junit Runner.
Conto nyetel tes otomatis:
<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>
Conto laporan Allure (tes paling ora stabil, 5 ulangan)
Beban pelari sajrone tes (8 intine, 8 GB RAM, 24 utas)
Pros:
- konsumsi sumber daya kurang;
- dhukungan asli saka Timun - ora ana alat tambahan sing dibutuhake;
- kemampuan kanggo mbukak luwih saka 6 Utas saben inti prosesor.
Cons:
- sampeyan kudu mesthekake yen kode ndhukung eksekusi multi-Utas;
- ambang entri mundhak.
Laporan Allure ing kaca GitLab
Sawise ngenalake eksekusi multi-threaded, kita wiwit nggunakake luwih akeh wektu kanggo nganalisa laporan. Ing wektu iku, kita kudu ngunggah saben laporan minangka artefak menyang GitLab, banjur ngundhuh lan mbongkar. Ora trep banget lan butuh wektu suwe. Lan yen wong liya pengin ndeleng laporan kasebut dhewe, mula dheweke kudu nindakake operasi sing padha. Kita pengin nampa umpan balik luwih cepet, lan nemokake solusi - kaca GitLab. Iki minangka fitur sing kasedhiya ing kabeh versi GitLab paling anyar. Ngidini sampeyan masang situs statis ing server lan ngakses liwat link langsung.
Kabeh gambar saka laporan Allure dijupuk ing kaca GitLab. Skrip kanggo nyebarake laporan menyang kaca GitLab - ing Windows PowerShell (sadurunge sampeyan kudu mbukak autotes):
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
Apa ing pungkasan
Dadi, yen sampeyan mikir apa sampeyan butuh kode aman Thread ing kerangka autotest Cucumber, saiki jawabane wis jelas - kanthi Timun 4 gampang dileksanakake, saengga bisa nambah jumlah benang sing diluncurake bebarengan. Kanthi cara tes iki, pitakonan saiki dadi babagan kinerja mesin karo Selenoid lan bangku tes.
Praktek wis nuduhake manawa tes otomatis ing benang ngidini sampeyan nyuda konsumsi sumber daya kanthi minimal kanthi kinerja sing paling apik. Kaya sing bisa dideleng saka grafik, dobel benang ora nyebabake akselerasi sing padha ing tes kinerja. Nanging, kita padha bisa kanggo nambah luwih saka 2 tes otomatis kanggo mbangun aplikasi, kang malah karo 200 reruns mlaku ing bab 5 menit. Iki ngidini sampeyan nampa umpan balik cepet saka wong-wong mau, lan, yen perlu, gawe owah-owahan lan mbaleni prosedur maneh.
Source: www.habr.com