Geekly articles weekly

Menerapkan, skala: pengalaman menggunakan autotest di VTB

Divisi kami membuat jaringan pipa yang sepenuhnya otomatis untuk mengeluarkan versi aplikasi baru ke lingkungan produksi. Tentu saja, ini memerlukan tes fungsional otomatis. Di bawah potongan - kisah tentang bagaimana, dimulai dengan pengujian dalam satu utas pada mesin lokal, kami sampai pada peluncuran uji-mandiri multitreaded di Selenoid dalam pipa perakitan dengan laporan Allure pada halaman GitLab dan sebagai hasilnya kami mendapat alat otomatisasi keren yang nantinya dapat digunakan tim.



Di mana kita mulai


Untuk mengimplementasikan autotest dan mengintegrasikannya ke dalam pipa, kami membutuhkan kerangka kerja untuk otomatisasi, yang dapat diubah secara fleksibel sesuai dengan kebutuhan kami. Idealnya, saya ingin mendapatkan standar tunggal untuk mesin autotest, yang diadaptasi untuk menyematkan autotest dalam pipa. Untuk implementasi, kami telah memilih teknologi berikut:

  • Jawa
  • Maven
  • Selenium
  • Mentimun + 4 JUNI,
  • Daya pikat
  • Gitlab



Mengapa set seperti itu? Java adalah salah satu bahasa yang paling populer untuk autotest, selain itu, semua anggota tim berbicara itu. Selenium adalah solusi yang jelas. Mentimun, antara lain, seharusnya meningkatkan kepercayaan diri pada hasil autotest oleh unit yang terlibat dalam pengujian manual.

Tes berulir tunggal


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

  • menjalankan setiap hari dari semua protes tertulis untuk setiap proyek;
  • diluncurkan di jalur perakitan.

Awalnya ada beberapa tes, dan mereka pergi dalam satu aliran. Peluncuran single-threaded pada GitLab Windows-runner cukup memuaskan bagi kami: tes sangat sedikit memuat test stand dan hampir tidak memanfaatkan sumber daya.

Seiring waktu, autotests menjadi semakin banyak, dan kami berpikir untuk menjalankannya secara paralel, ketika menjalankan penuh mulai memakan waktu sekitar tiga jam. Ada masalah lain:

  • kami tidak dapat memastikan bahwa tesnya stabil;
  • tes yang melewati beberapa kali berturut-turut pada mesin lokal terkadang jatuh ke 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>


Contoh Laporan Daya Tarik


Runner memuat selama pengujian (8 core, 8 GB RAM, 1 utas)

Plus dari pengujian single-threaded:

  • mudah dikonfigurasi dan dijalankan;
  • Peluncuran di CI praktis tidak berbeda dari peluncuran lokal;
  • tes tidak saling mempengaruhi;
  • persyaratan sumber daya pelari minimum.

Kontra dari pengujian single-threaded:

  • jangka panjang;
  • stabilisasi tes yang lama;
  • penggunaan sumber daya pelari yang tidak efisien, pemanfaatan yang sangat rendah.

Tes JVM Fork


Karena kami tidak peduli tentang kode thread-safe ketika menerapkan kerangka dasar, mentimun-jvm-parallel-plugin untuk Maven menjadi cara yang paling jelas untuk dijalankan secara paralel. Plugin ini mudah dikonfigurasikan, tetapi untuk operasi paralel yang benar dari autotests Anda perlu menjalankan di browser terpisah. Tidak ada hubungannya, saya harus menggunakan Selenoid.

Server Selenoid dinaikkan pada mesin dengan 32 core dan 24 GB RAM. Batas tersebut ditetapkan dalam 48 browser - 1,5 utas per inti dan sekitar 400 MB RAM. Akibatnya, waktu tes berkurang dari tiga jam menjadi 40 menit. Mempercepat lari membantu menyelesaikan masalah stabilisasi: sekarang kita bisa dengan cepat menjalankan autotest baru 20-30 kali sampai kita memastikan bahwa itu dilakukan secara stabil.
Kelemahan pertama dari solusinya adalah pemanfaatan sumber daya runner yang tinggi dengan sejumlah kecil paralel thread: pada 4 core dan 8 GB RAM, tes bekerja secara stabil di tidak lebih dari 6 thread. Kekurangan kedua: plugin menghasilkan kelas pelari untuk setiap skenario, tidak peduli berapa banyak yang dijalankan.

Penting! Jangan melempar variabel dengan tag di argLine , misalnya, seperti ini:

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

Jika Anda melewati tag dengan cara ini, plugin akan menghasilkan pelari untuk semua tes, yaitu mencoba menjalankan semua tes, melompati mereka segera setelah diluncurkan dan membuat banyak garpu JVM.

Benar untuk membuang variabel dengan tag ke dalam tag di pengaturan plugin, lihat contoh di bawah ini. Metode lain yang kami uji memiliki masalah yang menghubungkan plugin Allure.

Contoh run time untuk 6 tes pendek dengan pengaturan yang salah:

 [INFO] Total time: 03:17 min

Contoh waktu uji coba jika Anda langsung memberikan tag ke mvn ... –Dcucumber.options :

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


Contoh laporan Allure (tes paling tidak stabil, 4 rerana)

Runner memuat selama pengujian (8 core, 8 GB RAM, 12 utas)

Pro:

  • pengaturan sederhana - Anda hanya perlu menambahkan plugin;
  • kemampuan untuk secara bersamaan melakukan sejumlah besar tes;
  • stabilisasi tes yang lebih cepat berkat klaim 1.

Cons:

  • diperlukan banyak OS / wadah;
  • konsumsi sumber daya yang tinggi per garpu;
  • Pengaya sudah usang dan tidak lagi didukung.

Bagaimana cara mengalahkan instabilitas


Stand tes tidak sempurna, seperti halnya tes otomatis sendiri. Tidak mengherankan, kami mendapat sejumlah tes yang konyol. Plugin maven surefire datang untuk menyelamatkan , yang di luar kotak mendukung restart tes jatuh. Anda perlu memperbarui versi plugin untuk setidaknya 2,21 dan menulis satu baris dengan jumlah restart di file pom atau lulus sebagai argumen untuk 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 startup: mvn ... -Dsurefire.rerunFailingTestsCount = 2 ...
Atau, 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;
  • Anda dapat memuluskan masalah stabilitas bangku tes.

Cons:

  • Anda dapat melewati cacat mengambang;
  • run time meningkat.

Tes Paralel dengan Perpustakaan Mentimun 4



Jumlah tes bertambah setiap hari. Kami berpikir lagi tentang mempercepat lari. Selain itu, saya ingin mengintegrasikan sebanyak mungkin tes ke dalam rakitan pipa aplikasi. Faktor penting adalah generasi pelari yang terlalu lama saat berjalan secara paralel menggunakan plugin Maven.

Mentimun 4 sudah dirilis pada waktu itu, jadi kami memutuskan untuk menulis ulang kernel untuk versi ini. Dalam catatan rilis, kami dijanjikan peluncuran paralel di tingkat utas. Secara teoritis, ini seharusnya:

  • secara signifikan mempercepat proses autotest dengan meningkatkan jumlah utas;
  • mengecualikan hilangnya waktu untuk menghasilkan pelari untuk setiap autotest.

Mengoptimalkan kerangka kerja untuk autotest multi-utas tidak terlalu sulit. Mentimun 4 menjalankan setiap tes individu dalam utas khusus dari awal hingga akhir, sehingga beberapa hal statis umum hanya dikonversi ke variabel ThreadLocal.
Hal utama ketika mengkonversi dengan alat refactoring Idea adalah untuk memeriksa tempat-tempat di mana variabel dibandingkan (misalnya, memeriksa nol). Selain itu, Anda perlu merender plugin Allure dalam 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>

Contoh laporan Allure (tes paling tidak stabil, 5 reranes)

Runner memuat selama pengujian (8 core, 8 GB RAM, 24 utas)

Pro:

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

Cons:

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

Laporan daya pikat di halaman GitLab


Setelah peluncuran multithreaded, kami mulai menghabiskan lebih banyak waktu untuk menganalisis laporan. Pada saat itu, kami harus mengunggah setiap laporan sebagai artefak di GitLab, lalu mengunduhnya, membukanya. Tidak nyaman dan panjang. Dan jika orang lain ingin melihat laporan itu di rumah, maka dia harus melakukan operasi yang sama. Kami ingin mendapatkan umpan balik lebih cepat, dan ada jalan keluar - halaman GitLab. Ini adalah fitur bawaan yang tersedia di luar kotak di semua versi terbaru GitLab. Memungkinkan Anda untuk menyebarkan situs statis di server Anda dan mengaksesnya melalui tautan langsung.

Semua tangkapan layar dengan laporan Allure dibuat di halaman GitLab. Script untuk menyebarkan laporan ke halaman GitLab adalah untuk Windows PowerShell (sebelum itu Anda perlu menjalankan autotests):

 New-Item -ItemType directory -Path $testresult\history | 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 $buildlocation\target\site\allure-maven-plugin\* $buildlocation\public /s /i /Y

Apa hasilnya


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

Praktik telah menunjukkan bahwa menjalankan tes otomatis pada ulir dapat meminimalkan konsumsi sumber daya pada kinerja terbaik. Seperti yang dapat dilihat dari grafik, peningkatan 2 kali lipat dalam aliran tidak mengarah ke akselerasi yang sama dalam melewati tes kinerja. Namun demikian, kami dapat menambahkan lebih dari 200 tes otomatis ke rakitan aplikasi, yang bahkan dengan 5 rerans dapat diselesaikan dalam waktu sekitar 24 menit. Ini memungkinkan Anda untuk menerima umpan balik cepat dari mereka, dan jika perlu, melakukan perubahan dan ulangi prosedur lagi.

Source: https://habr.com/ru/post/id473950/

More articles:


All Articles