Triển khai, quy mô: kinh nghiệm sử dụng xét nghiệm tự động tại VTB

Bộ phận của chúng tôi tạo ra các quy trình hoàn toàn tự động để khởi chạy các phiên bản ứng dụng mới vào môi trường sản xuất. Tất nhiên, điều này đòi hỏi phải kiểm tra chức năng tự động. Phần bên dưới là câu chuyện về cách bắt đầu với thử nghiệm một luồng trên máy cục bộ, chúng tôi đã đạt đến mức tự động kiểm tra đa luồng chạy trên Selenoid trong quy trình xây dựng với báo cáo Allure trên các trang GitLab và cuối cùng có được một công cụ tự động hóa thú vị rằng mọi người trong tương lai có thể sử dụng đội.

Chúng ta đã bắt đầu từ đâu?

Để triển khai các thử nghiệm tự động và tích hợp chúng vào quy trình, chúng tôi cần một khung tự động hóa có thể thay đổi linh hoạt để phù hợp với nhu cầu của chúng tôi. Lý tưởng nhất là tôi muốn có một tiêu chuẩn duy nhất cho công cụ tự động kiểm tra, được điều chỉnh để nhúng các công cụ tự động kiểm tra vào quy trình. Để triển khai, chúng tôi đã chọn các công nghệ sau:

• java,
• Maven,
• Selen,
• Dưa chuột+JUNIT 4,
• Quyến rũ,
• gitlab.

Tại sao bộ đặc biệt này? Java là một trong những ngôn ngữ phổ biến nhất cho các bài kiểm tra tự động và tất cả các thành viên trong nhóm đều nói được ngôn ngữ đó. Selenium là giải pháp rõ ràng. Dưa chuột, trong số những thứ khác, được cho là sẽ tăng cường độ tin cậy vào kết quả kiểm tra tự động của các bộ phận liên quan đến kiểm tra thủ công.

Kiểm tra luồng đơn

Để không phát minh lại bánh xe, chúng tôi đã lấy các phát triển từ nhiều kho lưu trữ khác nhau trên GitHub làm nền tảng cho khung và điều chỉnh chúng cho phù hợp với chính mình. Chúng tôi đã tạo một kho lưu trữ cho thư viện chính với cốt lõi của khung tự động kiểm tra và một kho lưu trữ có ví dụ Vàng về việc triển khai tự động kiểm tra trên lõi của chúng tôi. Mỗi đội phải lấy hình ảnh Vàng và phát triển các thử nghiệm trong đó, điều chỉnh nó cho phù hợp với dự án của họ. Chúng tôi đã triển khai nó tới ngân hàng GitLab-CI mà chúng tôi đã định cấu hình trên đó:

• chạy hàng ngày tất cả các bài kiểm tra tự động bằng văn bản cho từng dự án;
• khởi chạy trong quy trình xây dựng.

Lúc đầu có rất ít thử nghiệm và chúng được thực hiện trong một luồng. Chạy đơn luồng trên trình chạy Windows GitLab khá phù hợp với chúng tôi: các bài kiểm tra tải băng ghế thử nghiệm rất nhẹ và hầu như không sử dụng tài nguyên.

Theo thời gian, số lượng bài kiểm tra tự động ngày càng nhiều và chúng tôi đã nghĩ đến việc chạy chúng song song, khi quá trình chạy hoàn chỉnh bắt đầu mất khoảng ba giờ. Các vấn đề khác cũng xuất hiện:

• chúng tôi không thể xác minh rằng các bài kiểm tra có ổn định hay không;
• các bài kiểm tra được chạy nhiều lần liên tiếp trên máy cục bộ đôi khi bị lỗi trong CI.

Ví dụ về thiết lập autotests:

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

 
Ví dụ về báo cáo Allure

 
Tải Á hậu trong quá trình kiểm tra (8 lõi, RAM 8 GB, 1 luồng)
 
Ưu điểm của thử nghiệm đơn luồng:

• dễ dàng thiết lập và chạy;
• các lần ra mắt ở CI thực tế không khác gì các lần ra mắt tại địa phương;
• các bài kiểm tra không ảnh hưởng lẫn nhau;
• yêu cầu tối thiểu về tài nguyên của người chạy.

Nhược điểm của kiểm thử đơn luồng:

• mất rất nhiều thời gian để hoàn thành;
• ổn định lâu dài các bài kiểm tra;
• sử dụng tài nguyên người chạy không hiệu quả, mức sử dụng cực kỳ thấp.

Thử nghiệm trên các nhánh JVM

Vì chúng tôi không quan tâm đến mã an toàn luồng khi triển khai khung cơ sở nên cách rõ ràng nhất để chạy song song là dưa chuột-jvm-song song-plugin cho Maven. Plugin rất dễ cấu hình, nhưng để hoạt động song song chính xác, các bài kiểm tra tự động phải được chạy trong các trình duyệt riêng biệt. Không có gì để làm, tôi phải sử dụng Selenoid.

Máy chủ Selenoid được ra mắt trên máy có 32 lõi và 24 GB RAM. Giới hạn được đặt ở 48 trình duyệt - 1,5 luồng trên mỗi lõi và khoảng 400 MB RAM. Kết quả là thời gian thử nghiệm đã giảm từ ba giờ xuống còn 40 phút. Việc tăng tốc độ chạy đã giúp giải quyết vấn đề ổn định: giờ đây chúng tôi có thể nhanh chóng chạy thử nghiệm tự động mới 20–30 lần cho đến khi chắc chắn rằng chúng chạy đáng tin cậy.
Hạn chế đầu tiên của giải pháp là việc sử dụng nhiều tài nguyên của người chạy với số lượng luồng song song nhỏ: trên 4 lõi và 8 GB RAM, các bài kiểm tra chạy ổn định với không quá 6 luồng. Nhược điểm thứ hai: plugin tạo ra các lớp người chạy cho từng kịch bản, bất kể chúng được khởi chạy bao nhiêu.

Quan trọng! Không chuyển một biến có thẻ vào argLine, ví dụ như thế này:

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

Nếu bạn chuyển thẻ theo cách này, plugin sẽ tạo các trình chạy cho tất cả các thử nghiệm, nghĩa là nó sẽ cố gắng chạy tất cả các thử nghiệm, bỏ qua chúng ngay sau khi khởi chạy và tạo nhiều nhánh JVM.

Việc ném một biến có thẻ vào là đúng thẻ trong cài đặt plugin, xem ví dụ bên dưới. Các phương pháp khác mà chúng tôi đã thử nghiệm đều gặp sự cố khi kết nối plugin Allure.

Ví dụ về thời gian chạy cho 6 bài kiểm tra ngắn với cài đặt không chính xác:

[INFO] Total time: 03:17 min

Ví dụ về thời gian chạy thử nghiệm nếu bạn chuyển trực tiếp thẻ sang mvn... –Dcucumber.options:

[INFO] Total time: 44.467 s

Ví dụ về thiết lập autotests:

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

Ví dụ về báo cáo Allure (thử nghiệm không ổn định nhất, 4 lần chạy lại)

Tải Á hậu trong quá trình kiểm tra (8 lõi, RAM 8 GB, 12 luồng)
 
Ưu điểm:

• thiết lập dễ dàng - bạn chỉ cần thêm một plugin;
• khả năng thực hiện đồng thời một số lượng lớn các bài kiểm tra;
• tăng tốc ổn định thử nghiệm nhờ bước 1. 

Nhược điểm:

• Cần có nhiều hệ điều hành/container;
• tiêu thụ tài nguyên cao cho mỗi nhánh;
• Plugin đã lỗi thời và không còn được hỗ trợ. 

Làm thế nào để vượt qua sự bất ổn 

Bàn thử nghiệm không lý tưởng, giống như bản thân các bài kiểm tra tự động. Không có gì đáng ngạc nhiên khi chúng ta có một số thử nghiệm không ổn định. Đã đến giải cứu plugin chắc chắn của maven, tính năng này hỗ trợ khởi động lại các thử nghiệm không thành công. Bạn cần cập nhật phiên bản plugin lên ít nhất 2.21 và viết một dòng ghi số lần khởi động lại trong tệp pom hoặc chuyển nó làm đối số cho Maven.

Ví dụ về thiết lập autotests:

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

Hoặc khi khởi động: mvn … -Dsurefire.rerunFailingTestsCount=2 …
Là một tùy chọn, hãy đặt tùy chọn Maven cho tập lệnh PowerShell (PS1):

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

Ưu điểm:

• không cần lãng phí thời gian để phân tích một bài kiểm tra không ổn định khi nó gặp sự cố;
• vấn đề về độ ổn định của băng ghế thử nghiệm có thể được giảm nhẹ.

Nhược điểm:

• khuyết tật nổi có thể bị bỏ qua;
• thời gian chạy tăng lên.

Kiểm tra song song với thư viện Cucumber 4

Số lượng bài kiểm tra tăng lên mỗi ngày. Chúng tôi lại nghĩ đến việc tăng tốc độ chạy. Ngoài ra, tôi muốn tích hợp càng nhiều thử nghiệm càng tốt vào quy trình lắp ráp ứng dụng. Yếu tố quan trọng là việc tạo ra các Á hậu mất quá nhiều thời gian khi chạy song song bằng plugin Maven.

Lúc đó Cucumber 4 đã được phát hành nên chúng tôi quyết định viết lại kernel cho phiên bản này. Trong ghi chú phát hành, chúng tôi đã hứa sẽ khởi chạy song song ở cấp luồng. Về mặt lý thuyết nó phải có:

• tăng tốc đáng kể việc chạy thử nghiệm tự động bằng cách tăng số lượng luồng;
• loại bỏ sự lãng phí thời gian trong việc tạo đường chạy cho mỗi lần kiểm tra tự động.

Việc tối ưu hóa khung cho các bài kiểm tra tự động đa luồng hóa ra không quá khó. Cucumber 4 chạy từng thử nghiệm riêng lẻ trên một luồng chuyên dụng từ đầu đến cuối, do đó, một số nội dung tĩnh phổ biến đã được chuyển đổi đơn giản thành các biến ThreadLocal. 
Điều chính khi chuyển đổi bằng cách sử dụng các công cụ tái cấu trúc Idea là kiểm tra những vị trí mà biến được so sánh (ví dụ: kiểm tra giá trị rỗng). Ngoài ra, bạn cần thêm plugin Allure vào chú thích lớp Junit Runner.

Ví dụ về thiết lập autotests:

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

Ví dụ về báo cáo Allure (thử nghiệm không ổn định nhất, 5 lần chạy lại)

Tải Á hậu trong quá trình kiểm tra (8 lõi, RAM 8 GB, 24 luồng)

Ưu điểm:

• tiêu thụ tài nguyên thấp;
• hỗ trợ riêng từ Cucumber - không cần công cụ bổ sung;
• khả năng chạy hơn 6 luồng trên mỗi lõi bộ xử lý.

Nhược điểm:

• bạn cần đảm bảo rằng mã hỗ trợ thực thi đa luồng;
• ngưỡng đầu vào tăng lên.

Báo cáo lôi cuốn trên các trang GitLab

Sau khi giới thiệu tính năng thực thi đa luồng, chúng tôi bắt đầu dành nhiều thời gian hơn cho việc phân tích báo cáo. Vào thời điểm đó, chúng tôi phải tải từng báo cáo lên GitLab dưới dạng một tạo phẩm, sau đó tải xuống và giải nén. Nó không thuận tiện lắm và mất nhiều thời gian. Và nếu người khác muốn tự mình xem báo cáo thì họ sẽ cần thực hiện các thao tác tương tự. Chúng tôi muốn nhận được phản hồi nhanh hơn và chúng tôi đã tìm ra giải pháp - trang GitLab. Đây là một tính năng tích hợp sẵn có sẵn trong tất cả các phiên bản GitLab gần đây. Cho phép bạn triển khai các trang web tĩnh trên máy chủ của mình và truy cập chúng thông qua liên kết trực tiếp.

Tất cả ảnh chụp màn hình của báo cáo Allure được chụp trên trang GitLab. Tập lệnh triển khai báo cáo lên các trang GitLab - trong Windows PowerShell (trước đó, bạn cần chạy tự động kiểm tra):

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

Với kết quả là 

Vì vậy, nếu bạn đang suy nghĩ về việc liệu bạn có cần mã an toàn Thread trong khung tự động kiểm tra Cucumber hay không, thì câu trả lời đã rõ ràng - với Cucumber 4, thật dễ dàng triển khai mã này, do đó tăng đáng kể số lượng luồng được khởi chạy đồng thời. Với phương pháp chạy thử nghiệm này, câu hỏi bây giờ trở thành về hiệu suất của máy với Selenoid và bàn thử nghiệm.

Thực tiễn đã chỉ ra rằng việc chạy thử nghiệm tự động trên các luồng cho phép bạn giảm mức tiêu thụ tài nguyên xuống mức tối thiểu với hiệu suất tốt nhất. Như có thể thấy từ biểu đồ, việc nhân đôi luồng không dẫn đến khả năng tăng tốc tương tự trong các bài kiểm tra hiệu suất. Tuy nhiên, chúng tôi có thể thêm hơn 2 thử nghiệm tự động vào bản dựng ứng dụng, thậm chí với 200 lần chạy lại cũng mất khoảng 5 phút. Điều này cho phép bạn nhận được phản hồi nhanh chóng từ họ và nếu cần, hãy thực hiện các thay đổi và lặp lại quy trình.

Nguồn: www.habr.com