लागू करें, स्केल: वीटीबी में ऑटोटेस्ट का उपयोग करने का अनुभव

हमारा विभाजन उत्पादन वातावरण के लिए नए संस्करणों के आउटपुट के लिए पूरी तरह से स्वचालित पाइपलाइन बनाता है। बेशक, इसके लिए स्वचालित कार्यात्मक परीक्षणों की आवश्यकता होती है। कटौती के तहत - कैसे, स्थानीय मशीन पर एक धागे में परीक्षण के साथ शुरू होने की कहानी, हमें गिटलैब पृष्ठों पर एल्योर रिपोर्ट के साथ असेंबली पाइपलाइन में सेलेनॉइड पर स्व-परीक्षण के बहुप्रचलित प्रक्षेपण के लिए मिला और परिणामस्वरूप एक शांत स्वचालन उपकरण मिला है जो भविष्य का उपयोग कर सकता है टीम।

हमने कहां से शुरुआत की?

ऑटोटेस्ट्स को लागू करने और उन्हें एक पाइपलाइन में एम्बेड करने के लिए, हमें स्वचालन के लिए एक रूपरेखा की आवश्यकता थी, जिसे लचीले ढंग से हमारी आवश्यकताओं के अनुरूप बदला जा सकता है। आदर्श रूप से, मैं ऑटोटेस्ट इंजन के लिए एक एकल मानक प्राप्त करना चाहता था, जो एक पाइपलाइन में ऑटोटेस्ट्स को एम्बेड करने के लिए अनुकूलित है। कार्यान्वयन के लिए, हमने निम्नलिखित तकनीकों को चुना है:

• जावा,
  
• Maven,
  
• सेलेनियम,
  
• ककड़ी + जून 4,
  
• आकर्षण,
  
• GitLab।
  

ऐसा सेट क्यों? जावा ऑटोटेस्ट के लिए सबसे लोकप्रिय भाषाओं में से एक है, इसके अलावा, टीम के सभी सदस्य इसे बोलते हैं। सेलेनियम स्पष्ट समाधान है। ककड़ी, अन्य चीजों के अलावा, मैनुअल परीक्षण में शामिल इकाइयों द्वारा ऑटोटेस्ट के परिणामों में विश्वास बढ़ाना था।

एकल पिरोया परीक्षण

पहिया को सुदृढ़ नहीं करने के लिए, हमने गिटहब पर विभिन्न रिपॉजिटरी से अनुभव को ढांचे के आधार के रूप में लिया और उन्हें अपने लिए अनुकूलित किया। हमने ऑटोटैस्ट्स ढांचे के मूल के साथ मुख्य पुस्तकालय के लिए एक भंडार और हमारे कोर पर ऑटोटेस्ट्स को लागू करने के गोल्ड उदाहरण के साथ एक भंडार का निर्माण किया। प्रत्येक टीम को एक गोल्ड-छवि लेनी थी और उसमें परीक्षण विकसित करना था, इसे अपनी परियोजना के अनुरूप बनाना था। हमने GitLab-CI बैंक में तैनाती की, जिस पर हमने कॉन्फ़िगर किया:

• प्रत्येक परियोजना के लिए सभी लिखित ऑटोटेस्ट के दैनिक रन;
  
• विधानसभा पाइपलाइन में लॉन्च।
  

पहले तो कुछ परीक्षण हुए, और वे एक धारा में चले गए। GitLab विंडोज-रनर पर एकल-थ्रेडेड लॉन्च हमारे लिए काफी संतोषजनक था: परीक्षण ने परीक्षण बेंच को बहुत थोड़ा लोड किया और लगभग संसाधनों का उपयोग नहीं किया।

समय के साथ, ऑटोटेस्ट अधिक से अधिक हो गया, और हमने उन्हें समानांतर में चलाने के बारे में सोचा, जब एक पूर्ण रन के बारे में तीन घंटे लगने लगे। अन्य समस्याएं थीं:

• हम यह सुनिश्चित नहीं कर सके कि परीक्षण स्थिर हैं;
  
• स्थानीय मशीन पर एक पंक्ति में कई रनों से गुजरने वाले परीक्षण कभी-कभी सीआई में गिर जाते थे।
  

स्वतः संस्थापन उदाहरण:

<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 जीबी रैम, 1 थ्रेड)

एकल-पिरोया परीक्षणों के प्लस:

• कॉन्फ़िगर करने और चलाने में आसान;
  
• CI में लॉन्च व्यावहारिक रूप से स्थानीय लॉन्च से अलग नहीं है;
  
• परीक्षण एक दूसरे को प्रभावित नहीं करते हैं;
  
• न्यूनतम धावक संसाधन आवश्यकताएँ।
  

एकल-पिरोया परीक्षणों की विपक्ष:

• बहुत लंबी दौड़;
  
• परीक्षणों का लंबा स्थिरीकरण;
  
• धावक संसाधनों का अकुशल उपयोग, अत्यंत कम उपयोग।
  

जेवीएम फोर्क टेस्ट

चूंकि हमने बुनियादी ढांचे को लागू करते समय थ्रेड-सेफ कोड का ध्यान नहीं रखा था, मावेन के लिए ककड़ी-जेवीएम-समानांतर-प्लगइन समानांतर में चलने का सबसे स्पष्ट तरीका बन गया। प्लगइन को कॉन्फ़िगर करना आसान है, लेकिन ऑटोटेस्ट के सही समानांतर संचालन के लिए आपको अलग-अलग ब्राउज़रों में चलने की आवश्यकता है। कुछ नहीं करना है, मुझे सेलेनॉइड का उपयोग करना था।

सेलेनॉइड सर्वर को 32 कोर और 24 जीबी रैम के साथ एक मशीन पर उठाया गया था। सीमा 48 ब्राउज़रों में सेट की गई थी - 1.5 धागे प्रति कोर और लगभग 400 एमबी रैम। परिणामस्वरूप, परीक्षा का समय तीन घंटे से घटाकर 40 मिनट कर दिया गया। तेजी से दौड़ने से स्थिरीकरण समस्या को हल करने में मदद मिली: अब हम जल्दी से 20-30 बार नए ऑटोटेस्ट चला सकते हैं जब तक हम यह सुनिश्चित नहीं कर लेते हैं कि वे पूरी तरह से तैयार हैं।
समाधान का पहला दोष समानांतर थ्रेड्स की एक छोटी संख्या के साथ धावक संसाधनों का उच्च उपयोग था: 4 कोर और 8 जीबी रैम पर, परीक्षणों ने 6 थ्रेड्स से अधिक नहीं में सख्ती से काम किया। दूसरा माइनस: प्लगइन प्रत्येक परिदृश्य के लिए रनर क्लासेस बनाता है, चाहे कितने भी रन हों।

महत्वपूर्ण! उदाहरण के लिए, argLine में टैग के साथ एक वैरिएबल को न फेंकें:

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

यदि आप इस तरह से टैग को पास करते हैं, तो प्लगइन सभी परीक्षणों के लिए धावक उत्पन्न करेगा, अर्थात, सभी परीक्षणों को चलाने की कोशिश करें, लॉन्च के ठीक बाद उन्हें छोड़ दें और बहुत सारे जेवीएम कांटे बनाएं।

प्लगइन सेटिंग्स में टैग के साथ वेरिएबल को फेंकना सही है, नीचे उदाहरण देखें। हमारे द्वारा परीक्षण किए गए अन्य तरीकों में एल्योर प्लगइन को जोड़ने में समस्याएं हैं।

गलत सेटिंग्स के साथ 6 लघु परीक्षणों के लिए उदाहरण रन समय:

 [INFO] Total time: 03:17 min 

टेस्ट रन टाइम का एक उदाहरण यदि आप सीधे टैग को mvn पास करते हैं ...

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

एल्योर रिपोर्ट का एक उदाहरण (सबसे अस्थिर परीक्षण, 4 रेराना)

परीक्षण के दौरान रनर लोड (8 कोर, 8 जीबी रैम, 12 थ्रेड)

पेशेवरों:

• सरल सेटअप - आपको बस प्लगइन जोड़ने की आवश्यकता है;
  
• एक साथ बड़ी संख्या में परीक्षण करने की क्षमता;
  
• 1 का दावा करने के लिए परीक्षण के तेजी से स्थिरीकरण।
  

विपक्ष:

• कई ओएस / कंटेनरों की आवश्यकता;
  
• उच्च संसाधन खपत प्रति कांटा;
  
• प्लगइन अपदस्थ है और अब समर्थित नहीं है।
  

अस्थिरता को कैसे हराया जाए

टेस्ट स्टैंड बिल्कुल सही नहीं हैं, क्योंकि ऑटो टेस्ट खुद होते हैं। आश्चर्य की बात नहीं, हमें कई तरह के उतार-चढ़ाव भरे परीक्षण मिले। मावेन अचूक प्लगइन बचाव के लिए आया था, जो बॉक्स से बाहर गिरा परीक्षणों को फिर से शुरू करने का समर्थन करता है। आपको प्लगइन संस्करण को कम से कम 2.21 में अपडेट करना होगा और पोम फ़ाइल में पुनरारंभ की संख्या के साथ एक पंक्ति लिखना होगा या मावेन के तर्क के रूप में पास करना होगा।

स्वतः संस्थापन उदाहरण:

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

या स्टार्टअप पर: mvan ... -Dureurefire.rerunFailingTestsCount = 2 ...
वैकल्पिक रूप से, PowerShell स्क्रिप्ट (PS1) के लिए मावेन विकल्प सेट करें:

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

पेशेवरों:

• जब यह दुर्घटनाग्रस्त हो जाए तो अस्थिर परीक्षण का समय बर्बाद करने की कोई आवश्यकता नहीं है;
  
• आप परीक्षण बेंच की स्थिरता समस्याओं को सुचारू कर सकते हैं।
  

विपक्ष:

• आप अस्थायी दोषों को छोड़ सकते हैं;
  
• रन टाइम बढ़ाया जाता है।
  

ककड़ी 4 लाइब्रेरी के साथ समानांतर टेस्ट

हर दिन परीक्षणों की संख्या बढ़ी। हमने फिर से तेजी से रन बनाने के बारे में सोचा। इसके अलावा, मैं एप्लिकेशन के पाइपलाइन असेंबली में अधिक से अधिक परीक्षणों को एकीकृत करना चाहता था। मावेन प्लगइन का उपयोग करके समानांतर में चलने पर एक महत्वपूर्ण कारक धावकों की बहुत लंबी पीढ़ी थी।

ककड़ी 4 उस समय पहले से ही जारी थी, इसलिए हमने इस संस्करण के लिए कर्नेल को फिर से लिखने का फैसला किया। रिलीज नोट्स में, हमें थ्रेड स्तर पर एक समानांतर लॉन्च का वादा किया गया था। सैद्धांतिक रूप से, यह होना चाहिए था:

• थ्रेड्स की संख्या में वृद्धि करके ऑटोटेस्ट्स की गति को काफी तेज करें;
  
• प्रत्येक ऑटोटेस्ट के लिए रनर्स बनाने के लिए समय की हानि को बाहर करें।
  

बहु-थ्रेडेड ऑटोटेस्ट के लिए रूपरेखा का अनुकूलन करना इतना मुश्किल नहीं था। ककड़ी 4 प्रत्येक व्यक्तिगत परीक्षण को शुरू से अंत तक एक समर्पित धागे में चलाता है, इसलिए कुछ सामान्य स्थिर चीजों को केवल थ्रेडलोक चर में परिवर्तित किया गया था।
आइडिया रिफैक्टरिंग टूल्स के साथ परिवर्तित होने पर मुख्य बात उन जगहों की जांच करना है जहां चर की तुलना की गई थी (उदाहरण के लिए, नल के लिए जाँच)। इसके अलावा, आपको जूनिन रनर वर्ग के एनोटेशन में एल्योर प्लगइन को प्रस्तुत करना होगा।

स्वतः संस्थापन उदाहरण:

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

लुभाना रिपोर्ट का एक उदाहरण (सबसे अस्थिर परीक्षण, 5 रेरन)

परीक्षण के दौरान रनर लोड (8 कोर, 8 जीबी रैम, 24 थ्रेड)

पेशेवरों:

• कम संसाधन की खपत;
  
• ककड़ी से मूल समर्थन - कोई अतिरिक्त उपकरण की आवश्यकता नहीं;
  
• प्रोसेसर कोर पर 6 से अधिक धागे चलाने की क्षमता।
  

विपक्ष:

• आपको यह सुनिश्चित करने की आवश्यकता है कि कोड बहु-थ्रेडेड निष्पादन का समर्थन करता है;
  
• प्रवेश सीमा बढ़ जाती है।
  

GitLab पृष्ठों में एल्योर रिपोर्ट

मल्टीथ्रेडेड लॉन्च की शुरुआत के बाद, हमने रिपोर्ट का विश्लेषण करने में अधिक समय बिताना शुरू किया। उस समय, हमें प्रत्येक रिपोर्ट को GitLab में एक विरूपण साक्ष्य के रूप में अपलोड करना था, फिर इसे डाउनलोड करें, इसे अनपैक करें। यह बहुत सुविधाजनक और लंबा नहीं है। और अगर कोई अन्य व्यक्ति घर पर रिपोर्ट देखना चाहता है, तो उसे वही ऑपरेशन करने की आवश्यकता होगी। हम तेजी से प्रतिक्रिया प्राप्त करना चाहते थे, और एक रास्ता था - गिटलैब पेज। यह एक बिल्ट-इन फीचर है जो कि GitLab के सभी हाल के संस्करणों में बॉक्स से बाहर उपलब्ध है। आपको अपने सर्वर पर स्थिर साइटें तैनात करने और उन्हें सीधे लिंक के माध्यम से एक्सेस करने की अनुमति देता है।

GureLab पृष्ठों में Allure रिपोर्ट वाले सभी स्क्रीनशॉट बनाए गए थे। रिपोर्ट को GitLab पृष्ठों पर लागू करने की स्क्रिप्ट Windows PowerShell (इससे पहले कि आपको ऑटोटेस्ट चलाने की आवश्यकता है):

 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 

परिणाम क्या है?

तो, यदि आप इस बारे में सोच रहे थे कि क्या आपको ककड़ी ऑटोटेस्ट फ्रेमवर्क में थ्रेड सेफ कोड की आवश्यकता है, तो अब जवाब स्पष्ट है - ककड़ी 4 के साथ इसे लागू करना आसान है, जिससे एक साथ लॉन्च किए गए थ्रेड्स की संख्या में काफी वृद्धि हुई है। परीक्षण चलाने की इस पद्धति के साथ, सवाल पहले से ही सेलेनॉइड और टेस्ट बेंच के साथ मशीन के प्रदर्शन के बारे में है।

अभ्यास से पता चला है कि थ्रेड पर ऑटो-परीक्षण चलाने से सर्वश्रेष्ठ प्रदर्शन पर संसाधन की खपत कम हो सकती है। जैसा कि रेखांकन से देखा जा सकता है, प्रवाह में 2 गुना वृद्धि प्रदर्शन परीक्षणों के समान त्वरण का कारण नहीं बनती है। फिर भी, हम एप्लिकेशन असेंबली में 200 से अधिक स्वचालित परीक्षण जोड़ने में सक्षम थे, जो कि 5 ररनों के साथ भी लगभग 24 मिनट में पूरा हो जाता है। यह आपको उनसे त्वरित प्रतिक्रिया प्राप्त करने की अनुमति देता है, और यदि आवश्यक हो, तो परिवर्तन करें और प्रक्रिया को फिर से दोहराएं।