Bölümümüz, uygulamaların yeni sürümlerini üretim ortamına başlatmak için tam otomatik işlem hatları oluşturur. Elbette bunun için otomatikleştirilmiş fonksiyonel testler gerekir. Kesimin altında, yerel bir makinede tek iş parçacıklı testle başlayarak, GitLab sayfalarındaki bir Allure raporuyla derleme hattında Selenoid üzerinde çalışan çok iş parçacıklı otomatik test noktasına nasıl ulaştığımız ve sonunda harika bir otomasyon aracına nasıl sahip olduğumuza dair bir hikaye var. gelecekteki insanların ekipleri kullanabileceğini.
Nereden başladık?
Otomatik testleri uygulamak ve bunları üretim hattına entegre etmek için ihtiyaçlarımıza uyacak şekilde esnek bir şekilde değiştirilebilecek bir otomasyon çerçevesine ihtiyacımız vardı. İdeal olarak, otomatik test motoru için, otomatik testleri ardışık düzene yerleştirmek üzere uyarlanmış tek bir standart elde etmek istedim. Uygulama için aşağıdaki teknolojileri seçtik:
- Java,
- Uzman,
- Selenyum,
- Salatalık+HAZİRAN 4,
- cazibe,
- GitLab.
Neden bu özel set? Java, otomatik testler için en popüler dillerden biridir ve tüm ekip üyeleri bunu konuşur. Selenyum bariz çözümdür. Salatalığın, diğer şeylerin yanı sıra, manuel testlerle ilgilenen departmanlar açısından otomatik testlerin sonuçlarına olan güveni artırması gerekiyordu.
Tek iş parçacıklı testler
Tekerleği yeniden icat etmemek için GitHub'daki çeşitli depolardan geliştirmeleri çerçevenin temeli olarak aldık ve kendimize uyarladık. Otomatik test çerçevesinin çekirdeğini içeren ana kitaplık için bir depo ve çekirdeğimizde otomatik testlerin uygulanmasına ilişkin Altın bir örnek içeren bir depo oluşturduk. Her takımın Altın imajını alıp üzerinde testler geliştirip projelerine uyarlaması gerekiyordu. Bunu yapılandırdığımız GitLab-CI bankasına dağıttık:
- her proje için tüm yazılı otomatik testlerin günlük çalıştırılması;
- derleme hattında başlatılır.
İlk başta birkaç test vardı ve bunlar tek bir akışta gerçekleştirildi. Windows çalıştırıcısı GitLab'da tek iş parçacıklı çalışma bize oldukça uygundu: testler, test tezgahını çok hafif bir şekilde yükledi ve neredeyse hiç kaynak kullanmadı.
Zamanla otomatik testlerin sayısı giderek arttı ve tam çalışma yaklaşık üç saat sürmeye başladığında bunları paralel olarak çalıştırmayı düşündük. Başka sorunlar da ortaya çıktı:
- testlerin stabil olduğunu doğrulayamadık;
- Yerel makinede arka arkaya birkaç kez çalıştırılan testler bazen CI'da çöküyordu.
Otomatik testleri ayarlama örneği:
<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 raporu örneği
Testler sırasında koşucu yükü (8 çekirdek, 8 GB RAM, 1 iş parçacığı)
Tek iş parçacıklı testlerin artıları:
- kurulumu ve çalıştırılması kolaydır;
- CI'daki lansmanlar pratik olarak yerel lansmanlardan farklı değil;
- testler birbirini etkilemez;
- koşucu kaynakları için minimum gereksinimler.
Tek iş parçacıklı testlerin dezavantajları:
- tamamlanması çok uzun zaman alıyor;
- testlerin uzun süreli stabilizasyonu;
- koşucu kaynaklarının verimsiz kullanımı, son derece düşük kullanım.
JVM çatalları üzerinde testler
Temel çerçeveyi uygularken iş parçacığı güvenli kodla ilgilenmediğimiz için paralel çalışmanın en belirgin yolu şuydu: Maven için. Eklentinin yapılandırılması kolaydır ancak doğru paralel çalışma için otomatik testlerin ayrı tarayıcılarda çalıştırılması gerekir. Yapacak bir şey yok, Selenoid kullanmak zorunda kaldım.
Selenoid sunucusu 32 çekirdekli ve 24 GB RAM'e sahip bir makinede başlatıldı. Sınır, çekirdek başına 48 iş parçacığı ve yaklaşık 1,5 MB RAM olmak üzere 400 tarayıcı olarak belirlendi. Sonuç olarak test süresi üç saatten 40 dakikaya düşürüldü. Çalıştırmaları hızlandırmak stabilizasyon sorununun çözülmesine yardımcı oldu: Artık yeni otomatik testleri, güvenilir bir şekilde çalıştıklarından emin olana kadar hızlı bir şekilde 20-30 kez çalıştırabiliyorduk.
Çözümün ilk dezavantajı, az sayıda paralel iş parçacığına sahip koşucu kaynaklarının yüksek kullanımıydı: 4 çekirdek ve 8 GB RAM üzerinde testler, en fazla 6 iş parçacığında kararlı bir şekilde gerçekleştirildi. İkinci dezavantaj: Eklenti, kaç tanesi başlatılırsa başlatılsın her senaryo için koşucu sınıfları oluşturur.
Önemli! Etiketleri olan bir değişkeni iletmeyin arglineörneğin şu şekilde:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Etiketi bu şekilde iletirseniz, eklenti tüm testler için koşucular oluşturacaktır, yani tüm testleri çalıştırmaya çalışacak, lansmandan hemen sonra bunları atlayacak ve birçok JVM çatalı oluşturacaktır.
Etiketli bir değişkeni içine atmak doğrudur etiketler eklenti ayarlarında aşağıdaki örneğe bakın. Test ettiğimiz diğer yöntemlerde Allure eklentisine bağlanmada sorunlar yaşanıyor.
Yanlış ayarlarla 6 kısa test için çalışma süresi örneği:
[INFO] Total time: 03:17 min
Etiketi doğrudan aktarırsanız test çalıştırma süresi örneği mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
Otomatik testleri ayarlama örneği:
<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 raporu örneği (en dengesiz test, 4 tekrar)
Testler sırasında koşucu yükü (8 çekirdek, 8 GB RAM, 12 iş parçacığı)
Artıları:
- kolay kurulum - sadece bir eklenti eklemeniz yeterlidir;
- aynı anda çok sayıda testi gerçekleştirme yeteneği;
- Adım 1 sayesinde test stabilizasyonunun hızlandırılması.
Eksileri:
- Birden fazla işletim sistemi/kapsayıcı gerekli;
- her çatal için yüksek kaynak tüketimi;
- Eklenti güncel değil ve artık desteklenmiyor.
İstikrarsızlığın üstesinden nasıl gelinir?
Test tezgahları, tıpkı otomatik testler gibi ideal değildir. Bir takım hatalı testlerimizin olması şaşırtıcı değil. Kurtarmaya geldi, başarısız testlerin yeniden başlatılmasını destekler. Eklenti sürümünü en az 2.21'e güncellemeniz ve pom dosyasına yeniden başlatma sayısını içeren bir satır yazmanız veya bunu Maven'e argüman olarak iletmeniz gerekir.
Otomatik testleri ayarlama örneği:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Veya başlangıçta: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Bir seçenek olarak PowerShell betiği (PS1) için Maven seçeneklerini ayarlayın:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Artıları:
- dengesiz bir testi çöktüğünde analiz etmek için zaman harcamanıza gerek yok;
- test tezgahı stabilite sorunları hafifletilebilir.
Eksileri:
- yüzen kusurlar gözden kaçabilir;
- çalışma süresi artar.
Cucumber 4 kütüphanesi ile paralel testler
Test sayısı her geçen gün arttı. Tekrar koşuları hızlandırmayı düşündük. Ayrıca uygulama derleme hattına mümkün olduğunca çok sayıda testi entegre etmek istedim. Kritik faktör, Maven eklentisini kullanarak paralel koşarken koşucu neslinin çok uzun sürmesiydi.
O zamanlar Cucumber 4 zaten yayınlanmıştı, bu yüzden çekirdeği bu sürüm için yeniden yazmaya karar verdik. Sürüm notlarında bize iş parçacığı düzeyinde paralel başlatma sözü verildi. Teorik olarak bu şöyle olmalıydı:
- İş parçacığı sayısını artırarak otomatik testlerin çalışmasını önemli ölçüde hızlandırın;
- Her otomatik test için koşucu oluşturmada zaman kaybını ortadan kaldırın.
Çok iş parçacıklı otomatik testler için çerçeveyi optimize etmenin o kadar da zor olmadığı ortaya çıktı. Cucumber 4, her bir testi baştan sona özel bir iş parçacığı üzerinde çalıştırır, bu nedenle bazı yaygın statik şeyler basitçe ThreadLocal değişkenlerine dönüştürülür.
Idea yeniden düzenleme araçlarını kullanarak dönüştürme yaparken asıl şey, değişkenin karşılaştırıldığı yerleri kontrol etmektir (örneğin, null olup olmadığını kontrol etmek). Ayrıca Junit Runner sınıfının açıklamasına Allure eklentisini de eklemeniz gerekiyor.
Otomatik testleri ayarlama örneği:
<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 raporu örneği (en dengesiz test, 5 tekrar)
Testler sırasında koşucu yükü (8 çekirdek, 8 GB RAM, 24 iş parçacığı)
Artıları:
- düşük kaynak tüketimi;
- Cucumber'dan yerel destek - ek araç gerekmez;
- işlemci çekirdeği başına 6'dan fazla iş parçacığı çalıştırma yeteneği.
Eksileri:
- kodun çok iş parçacıklı yürütmeyi desteklediğinden emin olmanız gerekir;
- giriş eşiği artar.
GitLab sayfalarındaki Allure raporları
Çok iş parçacıklı yürütmeyi kullanıma sunduktan sonra raporları analiz etmeye çok daha fazla zaman ayırmaya başladık. O zamanlar her raporu bir yapı olarak GitLab'a yüklememiz, ardından indirip paketini açmamız gerekiyordu. Çok kullanışlı değil ve uzun zaman alıyor. Ve eğer bir başkası raporu kendisi görüntülemek isterse, o zaman aynı işlemleri yapması gerekecektir. Daha hızlı geri bildirim almak istedik ve bir çözüm bulduk: GitLab sayfaları. Bu, GitLab'ın tüm yeni sürümlerinde kullanıma hazır olan yerleşik bir özelliktir. Statik siteleri sunucunuza dağıtmanıza ve bunlara doğrudan bir bağlantı aracılığıyla erişmenize olanak tanır.
Allure raporlarının tüm ekran görüntüleri GitLab sayfalarında alınmıştır. Raporu Windows PowerShell'de GitLab sayfalarına dağıtmaya yönelik komut dosyası (bundan önce otomatik testleri çalıştırmanız gerekir):
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
Sonucu ile bu
Dolayısıyla, Cucumber otomatik test çerçevesinde Thread güvenli koduna ihtiyacınız olup olmadığını düşünüyorsanız, artık cevap açıktır - Cucumber 4 ile bunu uygulamak kolaydır, böylece aynı anda başlatılan iş parçacıklarının sayısı önemli ölçüde artar. Bu test çalıştırma yöntemiyle artık soru, Selenoidli makinenin ve test tezgahının performansıyla ilgili hale geliyor.
Uygulama, iş parçacığı üzerinde otomatik testler çalıştırmanın, en iyi performansla kaynak tüketimini en aza indirmenize olanak sağladığını göstermiştir. Grafiklerden de görülebileceği üzere ipliklerin ikiye katlanması performans testlerinde benzer bir hızlanmaya yol açmıyor. Ancak, uygulama derlemesine 2'den fazla otomatik test eklemeyi başardık; bu testler, 200 yeniden çalıştırmayla bile yaklaşık 5 dakikada gerçekleştirilir. Bu, onlardan hızlı geri bildirim almanıza ve gerekirse değişiklik yapıp işlemi tekrarlamanıza olanak tanır.
Kaynak: habr.com