Bizim bölməmiz tətbiqlərin yeni versiyalarını istehsal mühitinə gətirmək üçün tam avtomatik boru kəmərləri yaradır. Təbii ki, bunun üçün avtomatlaşdırılmış funksional testlər lazımdır. Kəsmə altında, yerli maşında bir ipdə sınaqdan başlayaraq, GitLab səhifələrində Allure hesabatı ilə qurma boru kəmərində Selenoid avtotestlərinin çox yivli işə salınmasına necə nail olduğumuz haqqında bir hekayə var və nəticədə biz gələcək istifadəçilərin istifadə edə biləcəyi sərin avtomatlaşdırma aləti var.
Haradan başladıq
Avtotestləri həyata keçirmək və onları boru kəmərinə inteqrasiya etmək üçün bizə ehtiyaclarımıza uyğun olaraq çevik şəkildə dəyişdirilə bilən avtomatlaşdırma çərçivəsi lazım idi. İdeal olaraq, avtotestləri boru kəmərinə daxil etmək üçün uyğunlaşdırılmış avtotest mühərriki üçün vahid standart əldə etmək istəyirdim. Həyata keçirmək üçün biz aşağıdakı texnologiyaları seçdik:
- Java,
- maven,
- selenium,
- Xiyar+JUNIT 4,
- cazibədarlıq,
- gitlab.
Niyə bu xüsusi dəst? Java avtotestlər üçün ən populyar dillərdən biridir və bundan əlavə, bütün komanda üzvləri bunu bilir. Selenium açıq bir həlldir. Xiyar, digər şeylər arasında, əllə sınaqdan keçirən şöbələrin avtotestlərinin nəticələrinə inamı artırmalı idi.
Tək yivli testlər
Çarxı yenidən ixtira etməmək üçün biz GitHub-da müxtəlif depolardan inkişafları çərçivənin əsası kimi götürdük və onları özümüz üçün uyğunlaşdırdıq. Biz əsas kitabxana üçün avtotest çərçivəsinin nüvəsi və nüvəmizdə avtotestlərin həyata keçirilməsinin Qızıl nümunəsi olan repozitoriya yaratdıq. Hər bir komanda Qızıl şəkil çəkməli və onu öz layihəsinə uyğunlaşdıraraq orada testlər hazırlamalı idi. Konfiqurasiya etdiyimiz GitLab-CI bankında yerləşdirilib:
- hər bir layihə üçün bütün yazılı avtotestlərin gündəlik işə salınması;
- tikinti boru kəmərində işləyir.
Əvvəlcə sınaqlar az idi və onlar bir axınla gedirdilər. GitLab Windows runner-də tək yivli işə salınma bizə olduqca uyğun gəldi: testlər test stendini çox az yüklədi və demək olar ki, resurslardan istifadə etmədi.
Zaman keçdikcə getdikcə daha çox avtotestlər var idi və tam qaçış təxminən üç saat çəkməyə başlayanda onları paralel olaraq həyata keçirməyi düşündük. Digər problemlər də ortaya çıxdı:
- testlərin sabit olduğuna əmin ola bilmədik;
- yerli maşında ardıcıl olaraq bir neçə dəfə işləyən testlər bəzən CI-də qəzaya uğradı.
Avtotestlərin qurulmasına bir nümunə:
<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 hesabat nümunəsi
Testlər zamanı qaçış yükü (8 nüvə, 8 GB RAM, 1 ip)
Tək yivli testlərin üstünlükləri:
- quraşdırmaq və idarə etmək asandır;
- CI-də buraxılışlar yerli buraxılışlardan praktiki olaraq fərqlənmir;
- testlər bir-birinə təsir etmir;
- qaçışçı üçün minimum resurs tələbləri.
Tək yivli testlərin mənfi cəhətləri:
- tamamlamaq üçün çox vaxt lazımdır;
- testlərin uzun müddət sabitləşməsi;
- qaçış resurslarından səmərəsiz istifadə, son dərəcə aşağı istifadə.
JVM çəngəllərində sınaqlar
Baza çərçivəsini həyata keçirərkən iplik təhlükəsizliyi koduna əhəmiyyət vermədiyimiz üçün paralel işləməyin ən açıq yolu maven üçün. Plugini quraşdırmaq asandır, lakin düzgün paralel işləmə üçün avtotestlər ayrı brauzerlərdə aparılmalıdır. Ediləcək bir şey yoxdur, Selenoid istifadə etməli oldum.
Selenoid serveri 32 nüvəli və 24 GB operativ yaddaşa malik bir maşında qaldırıldı. Məhdudiyyət 48 brauzerdə müəyyən edilib - hər nüvəyə 1,5 ip və təxminən 400 MB RAM. Nəticədə test müddəti üç saatdan 40 dəqiqəyə endirilib. Qaçışları sürətləndirmək sabitlik problemini həll etməyə kömək etdi: indi biz onların stabil işlədiyinə əmin olana qədər 20-30 dəfə tez yeni avtotestlər keçirə bildik.
Həllin ilk çatışmazlığı az sayda paralel ipləri olan qaçışçıların yüksək resurs istifadəsi idi: 4 nüvədə və 8 GB operativ yaddaşda sınaqlar 6 ipdən çox olmayan sabit işləmişdir. İkinci mənfi: plagin nə qədər işə salınmasından asılı olmayaraq hər bir ssenari üçün qaçış sinifləri yaradır.
Mühüm! Etiketlənmiş dəyişəni daxil etməyin argLineməsələn, bu kimi:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Əgər etiketi bu şəkildə keçirsəniz, plagin bütün testlər üçün qaçışçılar yaradacaq, yəni işə salındıqdan dərhal sonra onları atlayaraq bütün testləri keçirməyə çalışacaq və prosesdə çoxlu JVM çəngəlləri yaradacaq.
Etiketi olan dəyişəni düzgün şəkildə daxil edin tags plagin parametrlərində, aşağıdakı nümunəyə baxın. Test etdiyimiz digər üsullarda Allure plaginini birləşdirən problemlər var.
Yanlış quraşdırma ilə 6 qısa test üçün iş vaxtı nümunəsi:
[INFO] Total time: 03:17 min
Əgər etiketi birbaşa ötürsəniz, sınaq müddətinin nümunəsi mvn... –Dcumber.options:
[INFO] Total time: 44.467 s
Avtotestlərin qurulmasına bir nümunə:
<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>
Allure hesabat nümunəsi (ən qeyri-sabit test, 4 təkrar)
Testlər zamanı qaçış yükü (8 nüvə, 8 GB RAM, 12 ip)
Pros:
- asan quraşdırma - sadəcə bir plagin əlavə etməlisiniz;
- eyni vaxtda çox sayda test aparmaq imkanı;
- 1-ci bəndə görə sınaq stabilləşməsinin sürətləndirilməsi.
Eksiler:
- çoxlu OS/konteyner tələb olunur;
- çəngəl başına yüksək resurs istehlakı;
- Plugin köhnəlib və artıq dəstəklənmir.
Qeyri-sabitliyə necə qalib gəlmək olar
Test skamyaları avtotestlərin özləri kimi mükəmməl deyil. Təəccüblü deyil ki, indi bizim bir sıra boş sınaqlarımız var. Köməyə gəldi, hansı qutudan kənar uğursuz sınaqların yenidən başlamasını dəstəkləyir. Siz plagin versiyasını ən azı 2.21-ə yeniləməli və pom faylında yenidən başlamaların sayı ilə bir sətir yazmalısınız və ya onu Mavenə arqument kimi ötürməlisiniz.
Avtotestlərin qurulmasına bir nümunə:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Və ya başlanğıcda: mvn ... -Dsurefire.rerunFailingTestsCount=2 ...
Alternativ olaraq, PowerShell skripti (PS1) üçün Maven seçimlərini təyin edin:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- qəza zamanı qeyri-sabit testi təhlil etmək üçün vaxt itirməyə ehtiyac yoxdur;
- test dəzgahının sabitlik problemlərini azalda bilər.
Eksiler:
- üzən qüsurları atlaya bilərsiniz;
- işləmə müddəti artır.
Xiyar 4 kitabxanası ilə paralel testlər
Testlərin sayı hər gün artırdı. Yenə qaçışları sürətləndirməyi düşündük. Bundan əlavə, mən tətbiqi montaj boru kəmərinə mümkün qədər çox test daxil etmək istədim. Kritik amil Maven plaginindən istifadə edərək paralel olaraq qaçış zamanı qaçışçıların çox uzun nəsli idi.
O zaman Xiyar 4 artıq buraxılmışdı, ona görə də bu versiya üçün nüvəni yenidən yazmağa qərar verdik. Buraxılış qeydlərində bizə ip səviyyəsində paralel buraxılış vəd edildi. Teorik olaraq bu belə olmalı idi:
- iplərin sayını artırmaqla avtotestlərin işini əhəmiyyətli dərəcədə sürətləndirmək;
- hər bir avtotest üçün qaçışçıların yaradılması üçün vaxt itkisini aradan qaldırın.
Çox yivli avtotestlər üçün çərçivəni optimallaşdırmaq o qədər də çətin olmadığı ortaya çıxdı. Cucumber 4 hər bir testi əvvəldən sona qədər xüsusi iplikdə keçirir, buna görə də bəzi ümumi statik şeylər sadəcə ThreadLocal dəyişənlərinə çevrildi.
Idea refactoring istifadə edərək konvertasiya edərkən əsas şey dəyişənin müqayisə edildiyi yerləri yoxlamaqdır (məsələn, null yoxlanılması). Bundan əlavə, Allure plaginini Junit Runner sinfinin annotasiyasına qoymalısınız.
Avtotestlərin qurulmasına bir nümunə:
<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>
Allure hesabat nümunəsi (ən qeyri-sabit test, 5 təkrar)
Testlər zamanı qaçış yükü (8 nüvə, 8 GB RAM, 24 ip)
Pros:
- aşağı resurs istehlakı;
- Xiyardan yerli dəstək - əlavə vasitələrə ehtiyac yoxdur;
- hər bir prosessor nüvəsi üçün 6-dan çox ip işlətmək imkanı.
Eksiler:
- kodun çox yivli icranı dəstəklədiyinə əmin olmalısınız;
- giriş həddi artır.
GitLab səhifələrində Allure hesabatları
Çox yivli buraxılışın tətbiqindən sonra biz hesabatları təhlil etməyə daha çox vaxt sərf etməyə başladıq. O zaman biz hər hesabatı GitLab-a artefakt kimi yükləməli, sonra onu endirməli, paketdən çıxarmalı idik. Çox rahat və uzun deyil. Və başqası hesabatı evdə görmək istəyirsə, o zaman eyni əməliyyatları yerinə yetirməli olacaq. Biz daha tez rəy əldə etmək istədik və çıxış yolu tapdıq - GitLab səhifələri. Bu, GitLab-ın bütün son versiyalarında qutudan kənarda mövcud olan daxili xüsusiyyətdir. Serverinizdə statik saytlar yerləşdirməyə və birbaşa keçid vasitəsilə onlara daxil olmağa imkan verir.
Allure hesabatları ilə bütün ekran görüntüləri GitLab səhifələrində hazırlanır. GitLab səhifələrində hesabat yerləşdirmək üçün skript - Windows PowerShell-də (bundan əvvəl avtotestləri işə salmalısınız):
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
Nəticə ilə
Beləliklə, Cucumber avtotest çərçivəsində Thread təhlükəsiz koduna ehtiyacınız olub olmadığını düşünürsünüzsə, indi cavab aydındır - Cucumber 4 ilə onu həyata keçirmək asandır və bununla da eyni vaxtda işləyən iplərin sayını əhəmiyyətli dərəcədə artırır. Testləri aparmağın bu üsulu ilə sual artıq Selenoid və test stendinə malik maşının işləməsi ilə bağlıdır.
Təcrübə göstərir ki, mövzularda avtotestlərin aparılması ən yaxşı performansla resurs istehlakını minimuma endirməyə imkan verir. Qrafiklərdən göründüyü kimi, iplərin 2x artması performans testlərindən keçməkdə oxşar sürətlənməyə səbəb olmur. Buna baxmayaraq, biz proqram quruluşuna 200-dən çox avtomatlaşdırılmış test əlavə edə bildik, hətta 5 təkrarla belə, təxminən 24 dəqiqə ərzində tamamlanır. Bu, onlardan tez geribildirim almağa, lazım gələrsə, dəyişikliklər etmək və proseduru yenidən təkrarlamağa imkan verir.
Mənbə: www.habr.com