ProHoster > blog > administrasi > Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB

Divisi kami menciptakan jalur pipa yang sepenuhnya otomatis untuk meluncurkan aplikasi versi baru ke lingkungan produksi. Tentu saja, hal ini memerlukan pengujian fungsional otomatis. Di bawah ini adalah cerita tentang bagaimana, dimulai dengan pengujian single-thread pada mesin lokal, kami mencapai titik autotest multi-thread yang berjalan di Selenoid dalam pipeline build dengan laporan Allure di halaman GitLab dan akhirnya mendapatkan alat otomatisasi yang keren bahwa orang-orang di masa depan dapat menggunakan tim.

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB

Di mana kita memulai?

Untuk menerapkan pengujian otomatis dan mengintegrasikannya ke dalam pipeline, kami memerlukan kerangka otomatisasi yang dapat diubah secara fleksibel agar sesuai dengan kebutuhan kami. Idealnya, saya ingin mendapatkan standar tunggal untuk mesin pengujian otomatis, yang diadaptasi untuk menyematkan pengujian otomatis ke dalam pipeline. Untuk implementasi kami memilih teknologi berikut:

  • Jawa,
  • pakar,
  • selenium,
  • Mentimun+JUNI 4,
  • Daya tarik,
  • GitLab.

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB

Mengapa set khusus ini? Java adalah salah satu bahasa paling populer untuk pengujian otomatis, dan semua anggota tim berbicara dalam bahasa tersebut. Selenium adalah solusi yang jelas. Mentimun, antara lain, diharapkan dapat meningkatkan kepercayaan terhadap hasil pengujian otomatis oleh departemen yang terlibat dalam pengujian manual.

Tes berulir tunggal

Agar tidak menemukan kembali roda, kami mengambil pengembangan dari berbagai repositori di GitHub sebagai dasar kerangka kerja dan mengadaptasinya sendiri. Kami membuat repositori untuk perpustakaan utama dengan inti kerangka autotest dan repositori dengan contoh Emas dalam mengimplementasikan autotest pada inti kami. Setiap tim harus mengambil gambar Emas dan mengembangkan tes di dalamnya, menyesuaikannya dengan proyek mereka. Kami menerapkannya ke bank GitLab-CI, tempat kami mengonfigurasi:

  • pelaksanaan harian semua tes otomatis tertulis untuk setiap proyek;
  • diluncurkan di pipeline build.

Awalnya tesnya sedikit, dan dilakukan dalam satu aliran. Single-thread yang berjalan pada runner Windows GitLab sangat cocok untuk kami: pengujian memuat bangku pengujian dengan sangat ringan dan hampir tidak menggunakan sumber daya.

Seiring waktu, jumlah tes otomatis menjadi semakin banyak, dan kami berpikir untuk menjalankannya secara paralel, ketika proses penuh mulai memakan waktu sekitar tiga jam. Masalah lain juga muncul:

  • kami tidak dapat memverifikasi bahwa pengujian tersebut stabil;
  • pengujian yang dijalankan beberapa kali berturut-turut di mesin lokal terkadang mengalami error di CI.

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

 Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB
Contoh laporan daya tarik

 Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB
Beban runner selama pengujian (8 core, 8 GB RAM, 1 thread)
 
Kelebihan tes single-thread:

  • mudah diatur dan dijalankan;
  • peluncuran di CI praktis tidak berbeda dengan peluncuran lokal;
  • tes tidak saling mempengaruhi;
  • persyaratan minimum untuk sumber daya pelari.

Kerugian dari tes single-threaded:

  • membutuhkan waktu yang sangat lama untuk menyelesaikannya;
  • stabilisasi pengujian yang lama;
  • penggunaan sumber daya pelari yang tidak efisien, pemanfaatan yang sangat rendah.

Pengujian pada fork JVM

Karena kami tidak menangani kode thread-safe saat mengimplementasikan kerangka dasar, cara paling jelas untuk menjalankannya secara paralel adalah mentimun-jvm-paralel-plugin untuk Maven. Plugin ini mudah dikonfigurasi, tetapi untuk pengoperasian paralel yang benar, pengujian otomatis harus dijalankan di browser terpisah. Tidak ada yang bisa dilakukan, saya harus menggunakan Selenoid.

Server Selenoid diluncurkan pada mesin dengan 32 core dan RAM 24 GB. Batasannya ditetapkan pada 48 browser - 1,5 thread per inti dan sekitar 400 MB RAM. Hasilnya, waktu tes dikurangi dari tiga jam menjadi 40 menit. Mempercepat proses membantu memecahkan masalah stabilisasi: sekarang kami dapat dengan cepat menjalankan tes otomatis baru sebanyak 20–30 kali hingga kami yakin bahwa tes tersebut berjalan dengan andal.
Kelemahan pertama dari solusi ini adalah tingginya pemanfaatan sumber daya runner dengan jumlah thread paralel yang sedikit: pada 4 core dan RAM 8 GB, pengujian berjalan secara stabil di tidak lebih dari 6 thread. Kerugian kedua: plugin menghasilkan kelas pelari untuk setiap skenario, tidak peduli berapa banyak skenario yang diluncurkan.

Penting! Jangan meneruskan variabel dengan tag ke argLine, misalnya seperti ini:

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

Jika Anda meneruskan tag dengan cara ini, plugin akan menghasilkan pelari untuk semua pengujian, yaitu mencoba menjalankan semua pengujian, melewatkannya segera setelah peluncuran dan membuat banyak fork JVM.

Benar untuk memasukkan variabel dengan tag ke dalamnya tag di pengaturan plugin, lihat contoh di bawah. Metode lain yang kami uji mengalami masalah saat menghubungkan plugin Allure.

Contoh waktu berjalan untuk 6 tes singkat dengan pengaturan yang salah:

[INFO] Total time: 03:17 min

Contoh waktu uji coba jika Anda langsung mentransfer tag ke mvn... –Dtimun.pilihan:

[INFO] Total time: 44.467 s

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

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTB
Contoh laporan Allure (tes paling tidak stabil, 4 kali tayangan ulang)

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTBPemuatan pelari selama pengujian (8 core, 8 GB RAM, 12 thread)
 
Pro:

  • pengaturan mudah - Anda hanya perlu menambahkan plugin;
  • kemampuan untuk melakukan sejumlah besar tes secara bersamaan;
  • percepatan stabilisasi pengujian berkat langkah 1. 

Cons:

  • Diperlukan beberapa OS/kontainer;
  • konsumsi sumber daya yang tinggi untuk setiap fork;
  • Plugin ini sudah usang dan tidak lagi didukung. 

Bagaimana mengatasi ketidakstabilan 

Bangku tes tidaklah ideal, sama seperti tes otomatis itu sendiri. Tidak mengherankan jika kita menghadapi sejumlah pengujian yang lemah. Datang untuk menyelamatkan plugin jitu maven, yang mendukung memulai ulang pengujian yang gagal. Anda perlu memperbarui versi plugin ke setidaknya 2.21 dan menulis satu baris dengan jumlah restart di file pom atau meneruskannya sebagai argumen ke Maven.

Contoh pengaturan 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 saat memulai: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Sebagai opsi, atur opsi Maven untuk skrip PowerShell (PS1): 

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

Pro:

  • tidak perlu membuang waktu menganalisis tes yang tidak stabil ketika crash;
  • masalah stabilitas bangku tes dapat dikurangi.

Cons:

  • cacat mengambang bisa terlewatkan;
  • waktu berjalan meningkat.

Tes paralel dengan perpustakaan Mentimun 4

Jumlah tes bertambah setiap hari. Kami kembali berpikir untuk mempercepat lari. Selain itu, saya ingin mengintegrasikan pengujian sebanyak mungkin ke dalam jalur perakitan aplikasi. Faktor kritisnya adalah pembuatan pelari memakan waktu terlalu lama saat dijalankan secara paralel menggunakan plugin Maven.

Saat itu Cucumber 4 sudah dirilis, jadi kami memutuskan untuk menulis ulang kernel untuk versi ini. Dalam catatan rilis kami dijanjikan peluncuran paralel di tingkat thread. Secara teoritis ini seharusnya:

  • secara signifikan mempercepat jalannya tes otomatis dengan meningkatkan jumlah thread;
  • menghilangkan hilangnya waktu dalam menghasilkan pelari untuk setiap autotest.

Mengoptimalkan kerangka kerja untuk pengujian otomatis multi-utas ternyata tidak terlalu sulit. Mentimun 4 menjalankan setiap pengujian individual pada thread khusus dari awal hingga akhir, sehingga beberapa hal statis umum dikonversi ke variabel ThreadLocal. 
Hal utama saat mengonversi menggunakan alat pemfaktoran ulang Idea adalah memeriksa tempat perbandingan variabel (misalnya, memeriksa nol). Selain itu, Anda perlu menambahkan plugin Allure ke anotasi kelas Junit Runner.

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

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTBContoh laporan Allure (tes paling tidak stabil, 5 kali tayangan ulang)

Implementasi, skala: pengalaman menggunakan pengujian otomatis di VTBBeban runner selama pengujian (8 core, 8 GB RAM, 24 thread)

Pro:

  • konsumsi sumber daya yang rendah;
  • dukungan asli dari Mentimun - tidak diperlukan alat tambahan;
  • kemampuan untuk menjalankan lebih dari 6 thread per inti prosesor.

Cons:

  • Anda perlu memastikan bahwa kode tersebut mendukung eksekusi multi-thread;
  • ambang masuk meningkat.

Laporan daya tarik di halaman GitLab

Setelah memperkenalkan eksekusi multi-thread, kami mulai menghabiskan lebih banyak waktu untuk menganalisis laporan. Saat itu, kami harus mengunggah setiap laporan sebagai artefak ke GitLab, lalu mengunduhnya dan membongkarnya. Ini sangat tidak nyaman dan memakan waktu lama. Dan jika orang lain ingin melihat sendiri laporannya, mereka perlu melakukan operasi yang sama. Kami ingin menerima masukan lebih cepat, dan kami menemukan solusinya - halaman GitLab. Ini adalah fitur bawaan yang langsung tersedia di semua versi terbaru GitLab. Memungkinkan Anda menyebarkan situs statis di server Anda dan mengaksesnya melalui tautan langsung.

Semua tangkapan layar laporan Allure diambil di halaman GitLab. Skrip untuk menyebarkan laporan ke halaman GitLab - di Windows PowerShell (sebelumnya Anda perlu menjalankan tes otomatis):

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

Jadi, jika Anda berpikir apakah Anda memerlukan kode aman Thread dalam kerangka autotest Mentimun, sekarang jawabannya sudah jelas - dengan Cucumber 4 mudah diterapkan, sehingga secara signifikan meningkatkan jumlah thread yang diluncurkan secara bersamaan. Dengan metode menjalankan tes ini, pertanyaannya adalah tentang kinerja mesin dengan Selenoid dan bangku tes.

Praktek telah menunjukkan bahwa menjalankan tes otomatis pada thread memungkinkan Anda mengurangi konsumsi sumber daya seminimal mungkin dengan kinerja terbaik. Seperti yang dapat dilihat dari grafik, penggandaan thread tidak menghasilkan akselerasi serupa dalam pengujian kinerja. Namun, kami dapat menambahkan lebih dari 2 pengujian otomatis ke pembuatan aplikasi, yang bahkan dengan 200 kali pengulangan akan berjalan dalam waktu sekitar 5 menit. Hal ini memungkinkan Anda menerima umpan balik cepat dari mereka, dan, jika perlu, membuat perubahan dan mengulangi prosedurnya lagi.

Sumber: www.habr.com

Tambah komentar