ProHoster > Blog > Pentadbiran > Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB

Bahagian kami mencipta saluran paip automatik sepenuhnya untuk melancarkan versi baharu aplikasi ke dalam persekitaran pengeluaran. Sudah tentu, ini memerlukan ujian fungsi automatik. Di bawah potongan adalah cerita tentang bagaimana, bermula dengan ujian satu benang pada mesin tempatan, kami mencapai tahap autotest berbilang benang yang dijalankan pada Selenoid dalam saluran paip binaan dengan laporan Allure pada halaman GitLab dan akhirnya mendapat alat automasi yang hebat bahawa orang masa depan boleh menggunakan pasukan.

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB

Di mana kita bermula?

Untuk melaksanakan autoujian dan menyepadukannya ke dalam perancangan, kami memerlukan rangka kerja automasi yang boleh diubah secara fleksibel untuk memenuhi keperluan kami. Sebaik-baiknya, saya ingin mendapatkan satu standard untuk enjin autoujian, disesuaikan untuk membenamkan autoujian ke dalam saluran paip. Untuk pelaksanaan kami memilih teknologi berikut:

  • Jawa,
  • Maven,
  • selenium,
  • Timun+JUNIT 4,
  • memikat,
  • GitLab.

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB

Kenapa set khusus ini? Java ialah salah satu bahasa yang paling popular untuk ujian automatik, dan semua ahli pasukan bercakap itu. Selenium adalah penyelesaian yang jelas. Timun, antara lain, sepatutnya meningkatkan keyakinan terhadap keputusan ujian automatik di pihak jabatan yang terlibat dalam ujian manual.

Ujian berulir tunggal

Untuk tidak mencipta semula roda, kami mengambil perkembangan daripada pelbagai repositori di GitHub sebagai asas untuk rangka kerja dan menyesuaikannya untuk diri kami sendiri. Kami mencipta repositori untuk perpustakaan utama dengan teras rangka kerja autoujian dan repositori dengan contoh Emas untuk melaksanakan autoujian pada teras kami. Setiap pasukan perlu mengambil imej Emas dan membangunkan ujian di dalamnya, menyesuaikannya dengan projek mereka. Kami mengerahkannya ke bank GitLab-CI, yang kami konfigurasikan:

  • larian harian semua autotest bertulis untuk setiap projek;
  • pelancaran dalam saluran paip binaan.

Pada mulanya terdapat beberapa ujian, dan ia dijalankan dalam satu aliran. Jalanan berbenang tunggal pada pelari Windows GitLab sangat sesuai untuk kami: ujian memuatkan bangku ujian dengan sangat ringan dan hampir tidak menggunakan sumber.

Lama kelamaan, bilangan autoujian menjadi semakin banyak, dan kami berfikir untuk menjalankannya secara selari, apabila larian penuh mula mengambil masa kira-kira tiga jam. Masalah lain juga muncul:

  • kami tidak dapat mengesahkan bahawa ujian itu stabil;
  • ujian yang dijalankan beberapa kali berturut-turut pada mesin tempatan kadangkala terhempas di CI.

Contoh menyediakan autotest:

<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>

 Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB
Contoh laporan memikat

 Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB
Muatan pelari semasa ujian (8 teras, 8 GB RAM, 1 utas)
 
Kebaikan ujian berbenang tunggal:

  • mudah untuk disediakan dan dijalankan;
  • pelancaran dalam CI boleh dikatakan tidak berbeza dengan pelancaran tempatan;
  • ujian tidak menjejaskan satu sama lain;
  • keperluan minimum untuk sumber pelari.

Kelemahan ujian berulir tunggal:

  • mengambil masa yang sangat lama untuk disiapkan;
  • penstabilan panjang ujian;
  • penggunaan sumber pelari yang tidak cekap, penggunaan yang sangat rendah.

Ujian pada garpu JVM

Memandangkan kami tidak menjaga kod selamat benang semasa melaksanakan rangka kerja asas, cara yang paling jelas untuk dijalankan selari ialah timun-jvm-selari-plugin untuk Maven. Pemalam ini mudah untuk dikonfigurasikan, tetapi untuk operasi selari yang betul, autotest mesti dijalankan dalam penyemak imbas yang berasingan. Tiada apa yang perlu dilakukan, saya terpaksa menggunakan Selenoid.

Pelayan Selenoid telah dilancarkan pada mesin dengan 32 teras dan 24 GB RAM. Had ditetapkan pada 48 pelayar - 1,5 utas setiap teras dan kira-kira 400 MB RAM. Akibatnya, masa ujian dikurangkan daripada tiga jam kepada 40 minit. Mempercepatkan larian membantu menyelesaikan masalah penstabilan: kini kami boleh menjalankan autoujian baharu 20–30 kali dengan pantas sehingga kami yakin ia berjalan dengan pasti.
Kelemahan pertama penyelesaian adalah penggunaan tinggi sumber pelari dengan sebilangan kecil benang selari: pada 4 teras dan 8 GB RAM, ujian berjalan dengan stabil dalam tidak lebih daripada 6 utas. Kelemahan kedua: pemalam menjana kelas pelari untuk setiap senario, tidak kira berapa banyak daripada mereka yang dilancarkan.

Penting! Jangan hantar pembolehubah dengan teg kepada argLine, sebagai contoh, seperti ini:

<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"

Jika anda melepasi teg dengan cara ini, pemalam akan menjana pelari untuk semua ujian, iaitu, ia akan cuba menjalankan semua ujian, melangkaunya serta-merta selepas pelancaran dan mencipta banyak garpu JVM.

Adalah betul untuk membuang pembolehubah dengan tag ke dalam tags dalam tetapan pemalam, lihat contoh di bawah. Kaedah lain yang kami uji menghadapi masalah menyambung pemalam Allure.

Contoh masa berjalan untuk 6 ujian pendek dengan tetapan yang salah:

[INFO] Total time: 03:17 min

Contoh masa ujian dijalankan jika anda memindahkan terus teg ke mvn... –Dcucumber.options:

[INFO] Total time: 44.467 s

Contoh menyediakan autotest:

<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>

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTB
Contoh laporan Allure (ujian yang paling tidak stabil, 4 tayangan semula)

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTBMuatan pelari semasa ujian (8 teras, 8 GB RAM, 12 utas)
 
Kelebihan:

  • persediaan mudah - anda hanya perlu menambah pemalam;
  • keupayaan untuk melakukan sejumlah besar ujian secara serentak;
  • pecutan penstabilan ujian berkat langkah 1. 

Cons:

  • Berbilang OS/bekas diperlukan;
  • penggunaan sumber yang tinggi untuk setiap garpu;
  • Pemalam sudah lapuk dan tidak lagi disokong. 

Bagaimana untuk mengatasi ketidakstabilan 

Bangku ujian tidak sesuai, sama seperti ujian automatik itu sendiri. Tidak menghairankan bahawa kita mempunyai beberapa ujian yang lemah. Datang untuk menyelamatkan pemalam maven surefire, yang di luar kotak menyokong memulakan semula ujian yang gagal. Anda perlu mengemas kini versi pemalam kepada sekurang-kurangnya 2.21 dan menulis satu baris dengan bilangan permulaan semula dalam fail pom atau menyerahkannya sebagai hujah kepada Maven.

Contoh menyediakan autotest:

   	
<plugin>
        	
<groupId>org.apache.maven.plugins</groupId>
  	
      <artifactId>maven-surefire-plugin</artifactId>
        	
<version>2.21.0</version>
        	
<configuration>
           	
….
            	
<rerunFailingTestsCount>2</rerunFailingTestsCount>
            	
….
            	
</configuration>
</plugin>

Atau semasa permulaan: mvn ... -Dsurefire.rerunFailingTestsCount=2 ...
Sebagai pilihan, tetapkan pilihan Maven untuk skrip PowerShell (PS1): 

  
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"

Kelebihan:

  • tidak perlu membuang masa menganalisis ujian yang tidak stabil apabila ia ranap;
  • masalah kestabilan bangku ujian boleh dikurangkan.

Cons:

  • kecacatan terapung boleh terlepas;
  • masa larian bertambah.

Ujian selari dengan perpustakaan Cucumber 4

Bilangan ujian meningkat setiap hari. Kami sekali lagi memikirkan tentang mempercepatkan larian. Di samping itu, saya ingin menyepadukan seberapa banyak ujian yang mungkin ke dalam saluran paip pemasangan aplikasi. Faktor kritikal ialah penjanaan pelari mengambil masa terlalu lama apabila berlari secara selari menggunakan pemalam Maven.

Pada masa itu, Cucumber 4 telah pun dikeluarkan, jadi kami memutuskan untuk menulis semula kernel untuk versi ini. Dalam nota keluaran kami dijanjikan pelancaran selari pada peringkat benang. Secara teorinya ini sepatutnya:

  • mempercepatkan perjalanan autotest dengan meningkatkan bilangan benang;
  • menghapuskan kehilangan masa untuk menjana pelari untuk setiap autotest.

Mengoptimumkan rangka kerja untuk autotest berbilang benang ternyata tidak begitu sukar. Cucumber 4 menjalankan setiap ujian individu pada benang khusus dari awal hingga akhir, jadi beberapa perkara statik biasa ditukarkan kepada pembolehubah ThreadLocal. 
Perkara utama apabila menukar menggunakan alat pemfaktoran semula Idea adalah untuk menyemak tempat di mana pembolehubah itu dibandingkan (contohnya, menyemak nol). Selain itu, anda perlu menambah pemalam Allure pada anotasi kelas Junit Runner.

Contoh menyediakan autotest:

 
<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>

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTBContoh laporan Allure (ujian paling tidak stabil, 5 tayangan semula)

Laksanakan, skala: pengalaman menggunakan ujian automatik di VTBMuatan pelari semasa ujian (8 teras, 8 GB RAM, 24 utas)

Kelebihan:

  • penggunaan sumber yang rendah;
  • sokongan asli daripada Timun - tiada alat tambahan diperlukan;
  • keupayaan untuk menjalankan lebih daripada 6 benang bagi setiap teras pemproses.

Cons:

  • anda perlu memastikan bahawa kod tersebut menyokong pelaksanaan berbilang benang;
  • ambang kemasukan meningkat.

Laporan memikat pada halaman GitLab

Selepas memperkenalkan pelaksanaan berbilang benang, kami mula menghabiskan lebih banyak masa menganalisis laporan. Pada masa itu, kami perlu memuat naik setiap laporan sebagai artifak ke GitLab, kemudian memuat turunnya dan membongkarnya. Ia tidak begitu mudah dan mengambil masa yang lama. Dan jika orang lain mahu melihat laporan itu sendiri, maka mereka perlu melakukan operasi yang sama. Kami mahu menerima maklum balas dengan lebih pantas, dan kami menemui penyelesaian - halaman GitLab. Ini ialah ciri terbina dalam yang tersedia di luar kotak dalam semua versi terkini GitLab. Membolehkan anda menggunakan tapak statik pada pelayan anda dan mengaksesnya melalui pautan terus.

Semua tangkapan skrin laporan Allure telah diambil pada halaman GitLab. Skrip untuk menggunakan laporan ke halaman GitLab - dalam Windows PowerShell (sebelum ini anda perlu menjalankan autotest):

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

Dengan keputusan bahawa 

Jadi, jika anda memikirkan sama ada anda memerlukan kod selamat Thread dalam rangka kerja autotest Cucumber, kini jawapannya jelas - dengan Cucumber 4 adalah mudah untuk melaksanakannya, sekali gus meningkatkan bilangan utas yang dilancarkan serentak dengan ketara. Dengan kaedah menjalankan ujian ini, persoalannya ialah tentang prestasi mesin dengan Selenoid dan bangku ujian.

Amalan telah menunjukkan bahawa menjalankan autotest pada urutan membolehkan anda mengurangkan penggunaan sumber kepada minimum dengan prestasi terbaik. Seperti yang dapat dilihat daripada graf, penggandaan benang tidak membawa kepada pecutan yang sama dalam ujian prestasi. Walau bagaimanapun, kami dapat menambah lebih daripada 2 ujian automatik pada binaan aplikasi, yang walaupun dengan 200 tayangan semula dijalankan dalam kira-kira 5 minit. Ini membolehkan anda menerima maklum balas pantas daripada mereka, dan, jika perlu, buat perubahan dan ulangi prosedur sekali lagi.

Sumber: www.habr.com

Tambah komen