יישום, קנה מידה: ניסיון בשימוש בבדיקות אוטומטיות ב-VTB

החטיבה שלנו יוצרת צינורות אוטומטיים לחלוטין להשקת גרסאות חדשות של יישומים לתוך סביבת הייצור. כמובן, זה דורש בדיקות פונקציונליות אוטומטיות. מתחת לחיתוך יש סיפור על איך, החל מבדיקת חוט בודד במכונה מקומית, הגענו לנקודה של בדיקה אוטומטית מרובה חוטים הפועלת על Selenoid בצנרת הבנייה עם דוח Allure בדפי GitLab ובסופו של דבר קיבלנו כלי אוטומציה מגניב שאנשים עתידיים יוכלו להשתמש בצוותים.

מאיפה התחלנו?

כדי ליישם בדיקות אוטומטיות ולשלב אותן בצנרת, היינו צריכים מסגרת אוטומציה שניתן לשנות בגמישות כדי להתאים לצרכים שלנו. באופן אידיאלי, רציתי לקבל תקן יחיד עבור מנוע הבדיקה האוטומטית, המותאם להטמעת בדיקות אוטומטיות בצינור. ליישום בחרנו בטכנולוגיות הבאות:

• ג'אווה,
• מייבן,
• סֵלֶנִיוּם,
• מלפפון+ג'וניט 4,
• קֶסֶם,
• GitLab.

למה דווקא הסט הזה? Java היא אחת השפות הפופולריות ביותר לבדיקות אוטומטיות, וכל חברי הצוות דוברים אותה. סלניום הוא הפתרון הברור. מלפפון, בין היתר, היה אמור להגביר את האמון בתוצאות של בדיקות אוטומטיות מצד מחלקות העוסקות בבדיקות ידניות.

בדיקות עם הברגה בודדת

כדי לא להמציא את הגלגל מחדש לקחנו פיתוחים ממאגרים שונים ב-GitHub כבסיס למסגרת והתאמנו אותם לעצמנו. יצרנו מאגר עבור הספרייה הראשית עם הליבה של מסגרת הבדיקה האוטומטית ומאגר עם דוגמה של זהב של הטמעת בדיקות אוטומטיות בליבה שלנו. כל צוות היה צריך לקחת את תמונת הזהב ולפתח בה מבחנים, להתאים אותה לפרויקט שלו. פרסנו את זה לבנק GitLab-CI, שבו הגדרנו:

• ריצות יומיות של כל הבדיקות האוטומטיות הכתובות עבור כל פרויקט;
• השקות בצנרת הבנייה.

בהתחלה היו מעט בדיקות, והם בוצעו בזרם אחד. ריצה עם פתיל בודד על רץ Windows GitLab התאימה לנו למדי: הבדיקות העמיסו את ספסל הבדיקה בקלילות רבה ולא השתמשו כמעט במשאבים.

עם הזמן, מספר הבדיקות האוטומטיות גדל יותר ויותר, וחשבנו להפעיל אותן במקביל, כאשר ריצה מלאה החלה לארוך כשלוש שעות. בעיות נוספות הופיעו גם:

• לא יכולנו לוודא שהבדיקות היו יציבות;
• בדיקות שהופעלו מספר פעמים ברציפות במכונה המקומית קרסו לפעמים ב-CI.

דוגמה להגדרת בדיקות אוטומטיות:

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

 
דוגמה לדוח פיתוי

 
עומס רץ במהלך בדיקות (8 ליבות, 8 GB RAM, חוט אחד)
 
היתרונות של מבחנים עם חוט יחיד:

• קל להגדיר ולהפעיל;
• ההשקות ב-CI כמעט ואינן שונות מהשקות מקומיות;
• בדיקות אינן משפיעות אחת על השנייה;
• דרישות מינימום למשאבי רצים.

חסרונות של בדיקות חוט יחיד:

• לוקח הרבה מאוד זמן להשלים;
• ייצוב ארוך של בדיקות;
• שימוש לא יעיל במשאבי הרצים, ניצול נמוך במיוחד.

בדיקות על מזלגות JVM

מכיוון שלא הקפדנו על קוד בטוח בשרשור בעת הטמעת מסגרת הבסיס, הדרך הברורה ביותר לרוץ במקביל הייתה cucumber-jvm-parallel-plugin עבור מייבן. קל להגדיר את התוסף, אך לצורך פעולה מקבילה נכונה, יש להפעיל בדיקות אוטומטיות בדפדפנים נפרדים. אין מה לעשות, הייתי צריך להשתמש בסלנואיד.

שרת הסלנואיד הושק במכונה בעלת 32 ליבות ו-24 ג'יגה-בייט של זיכרון RAM. המגבלה נקבעה ל-48 דפדפנים - 1,5 שרשורים לכל ליבה וכ-400 מגה-בייט של זיכרון RAM. כתוצאה מכך, זמן הבדיקה צומצם משלוש שעות ל-40 דקות. האצת הריצות עזרה לפתור את בעיית הייצוב: כעת נוכל להריץ במהירות בדיקות אוטומטיות חדשות 20-30 פעמים עד שהיינו בטוחים שהן פועלות בצורה מהימנה.
החיסרון הראשון של הפתרון היה ניצול גבוה של משאבי ראנר עם מספר קטן של פתילים מקבילים: על 4 ליבות ו-8 GB של זיכרון RAM, הבדיקות רצו ביציבות בלא יותר מ-6 פתילים. החיסרון השני: התוסף מייצר כיתות רצים לכל תרחיש, לא משנה כמה מהם יופעלו.

חשוב! אל תעביר משתנה עם תגים ל argLine, למשל, כך:

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

אם תעבירו את התג בצורה זו, התוסף יפיק רצים לכל הבדיקות, כלומר ינסה להריץ את כל הבדיקות, ידלג עליהן מיד לאחר ההשקה וייצור מזלגות רבים של JVM.

נכון לזרוק לתוכו משתנה עם תג תיוגים בהגדרות הפלאגין, ראה דוגמה למטה. לשיטות אחרות שבדקנו יש בעיות בחיבור התוסף Allure.

דוגמה לזמן ריצה עבור 6 בדיקות קצרות עם הגדרות שגויות:

[INFO] Total time: 03:17 min

דוגמה לזמן ריצת בדיקה אם אתה מעביר ישירות את התג אל mvn... –Dcucumber.options:

[INFO] Total time: 44.467 s

דוגמה להגדרת בדיקות אוטומטיות:

<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 (הבדיקה הכי לא יציבה, 4 שידורים חוזרים)

עומס רץ במהלך בדיקות (8 ליבות, 8 GB RAM, 12 פתילים)
 
יתרונות:

• הגדרה קלה - אתה רק צריך להוסיף תוסף;
• היכולת לבצע בו זמנית מספר רב של בדיקות;
• האצת ייצוב הבדיקה הודות לשלב 1. 

חסרונות:

• נדרשות מספר מערכות הפעלה/מכולות;
• צריכת משאבים גבוהה עבור כל מזלג;
• התוסף מיושן ואינו נתמך עוד. 

איך להתגבר על חוסר יציבות 

ספסלי בדיקה אינם אידיאליים, בדיוק כמו הבדיקות האוטומטיות עצמן. אין זה מפתיע שיש לנו מספר מבחנים פגומים. בא להציל תוסף maven surefire, אשר מחוץ לקופסה תומך בהפעלה מחדש של בדיקות שנכשלו. עליך לעדכן את גרסת הפלאגין ל-2.21 לפחות ולכתוב שורה אחת עם מספר ההתחלות מחדש בקובץ ה-pom או להעביר אותה כארגומנט ל-Maven.

דוגמה להגדרת בדיקות אוטומטיות:

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

או בהפעלה: mvn … -Dsurefire.rerunFailingTestsCount=2 …
כאפשרות, הגדר אפשרויות של Maven עבור סקריפט PowerShell (PS1):

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

יתרונות:

• אין צורך לבזבז זמן בניתוח מבחן לא יציב כאשר הוא קורס;
• ניתן להקל על בעיות יציבות ספסל הבדיקה.

חסרונות:

• ניתן לפספס פגמים צפים;
• זמן הריצה גדל.

בדיקות מקבילות עם ספריית המלפפון 4

מספר המבחנים גדל מדי יום. שוב חשבנו להאיץ את הריצות. בנוסף, רציתי לשלב כמה שיותר בדיקות בצינור הרכבת האפליקציה. הגורם הקריטי היה שדור הרצים לקח יותר מדי זמן כאשר ריצה במקביל באמצעות תוסף Maven.

באותו זמן, Cucumber 4 כבר שוחרר, אז החלטנו לשכתב את הליבה לגרסה זו. בהערות השחרור הובטח לנו השקה מקבילה ברמת השרשור. תיאורטית זה צריך להיות:

• להאיץ משמעותית את הפעלת הבדיקות האוטומטיות על ידי הגדלת מספר השרשורים;
• לחסל את אובדן הזמן ביצירת רצים עבור כל בדיקה אוטומטית.

אופטימיזציה של המסגרת עבור בדיקות אוטומטיות עם ריבוי הליכות התבררה כל כך לא קשה. Cucumber 4 מריץ כל בדיקה בנפרד על שרשור ייעודי מתחילתו ועד סופו, כך שכמה דברים סטטיים נפוצים פשוט הומרו למשתני ThreadLocal. 
הדבר העיקרי בעת המרה באמצעות כלי Refactoring של Idea הוא לבדוק את המקומות שבהם המשתנה הושווה (לדוגמה, בדיקת null). בנוסף, עליך להוסיף את התוסף Allure להערת הכיתה Junit Runner.

דוגמה להגדרת בדיקות אוטומטיות:

 
<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 (הבדיקה הכי לא יציבה, 5 שידורים חוזרים)

עומס רץ במהלך בדיקות (8 ליבות, 8 GB RAM, 24 פתילים)

יתרונות:

• צריכת משאבים נמוכה;
• תמיכה מקומית ממלפפון - אין צורך בכלים נוספים;
• היכולת להריץ יותר מ-6 פתילים לכל ליבת מעבד.

חסרונות:

• עליך לוודא שהקוד תומך בביצוע ריבוי הליכים;
• סף הכניסה עולה.

Allure מדווח בדפי GitLab

לאחר שהכנסנו ביצוע מרובה-פתיל, התחלנו להשקיע הרבה יותר זמן בניתוח דוחות. באותו זמן, היינו צריכים להעלות כל דוח כחפץ ל- GitLab, ואז להוריד אותו ולפרוק אותו. זה לא מאוד נוח ולוקח הרבה זמן. ואם מישהו אחר רוצה לראות את הדוח בעצמו, אז הוא יצטרך לבצע את אותן פעולות. רצינו לקבל פידבק מהר יותר, ומצאנו פתרון - דפי GitLab. זוהי תכונה מובנית הזמינה מהקופסה בכל הגרסאות האחרונות של GitLab. מאפשר לך לפרוס אתרים סטטיים בשרת שלך ולגשת אליהם באמצעות קישור ישיר.

כל צילומי המסך של דוחות Allure צולמו בדפי GitLab. סקריפט לפריסת הדוח לדפי GitLab - ב-Windows PowerShell (לפני זה עליך להפעיל בדיקות אוטומטיות):

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

והתוצאה הוא ש 

אז, אם חשבתם אם אתם צריכים קוד בטוח של Thread במסגרת הבדיקה האוטומטית של Cucumber, כעת התשובה ברורה - עם Cucumber 4 קל ליישם אותו, ובכך להגדיל משמעותית את מספר השרשורים שהופעלו בו זמנית. בשיטה זו של הפעלת בדיקות, השאלה הופכת כעת לגבי הביצועים של המכונה עם סלנואיד וספסל הבדיקה.

התרגול הראה שהפעלת בדיקות אוטומטיות על שרשורים מאפשרת לך להפחית את צריכת המשאבים למינימום עם הביצועים הטובים ביותר. כפי שניתן לראות מהגרפים, הכפלת חוטים אינה מביאה לתאוצה דומה במבחני ביצועים. עם זאת, הצלחנו להוסיף יותר מ-2 בדיקות אוטומטיות לבניית האפליקציה, שאפילו עם 200 שידורים חוזרים פועלים תוך כ-5 דקות. זה מאפשר לקבל מהם משוב מהיר, ובמידת הצורך לבצע שינויים ולחזור על ההליך שוב.

מקור: www.habr.com