التنفيذ ، النطاق: تجربة استخدام الاختبارات التلقائية في VTB

يقوم قسمنا بإنشاء خطوط أنابيب أوتوماتيكية بالكامل لإخراج إصدارات جديدة من التطبيقات إلى بيئة الإنتاج. بالطبع ، هذا يتطلب اختبارات وظيفية الآلي. تحت القص - قصة كيف ، بدءًا من الاختبار في مؤشر ترابط واحد على الجهاز المحلي ، وصلنا إلى الإطلاق متعدد الخيوط للاختبارات الذاتية على Selenoid في خط التجميع مع تقرير Allure على صفحات GitLab ونتيجة لذلك ، حصلنا على أداة أتمتة رائعة يمكن أن تستخدمها المستقبل فريق.

من أين بدأنا؟

لتنفيذ الاختبارات الذاتية ودمجها في خط الأنابيب ، كنا بحاجة إلى إطار عمل للتشغيل الآلي ، والذي يمكن تغييره بمرونة ليناسب احتياجاتنا. من الناحية المثالية ، كنت أرغب في الحصول على معيار واحد للمحرك autotest ، تم تكييفها لتضمين autotests في خط أنابيب. للتنفيذ ، اخترنا التقنيات التالية:

• جافا،
  
• مخضرم،
  
• السيلينيوم،
  
• خيار + يونيو 4 ،
  
• ألور،
  
• GitLab.
  

لماذا هذه المجموعة؟ تعد Java واحدة من أكثر اللغات شعبية في الاختبارات التلقائية ، بالإضافة إلى أن جميع أعضاء الفريق يتحدثون بها. السيلينيوم هو الحل الواضح. كان من المفترض أن يزيد الخيار ، من بين أشياء أخرى ، الثقة في نتائج الاختبارات الذاتية من قبل الوحدات المشاركة في الاختبار اليدوي.

اختبارات مترابطة واحدة

من أجل عدم إعادة اختراع العجلة ، أخذنا التطورات من مستودعات مختلفة على GitHub كأساس للإطار وتكييفها لأنفسنا. أنشأنا مستودعًا للمكتبة الرئيسية مع جوهر إطار الاختبار التلقائي ومستودعًا بمثال ذهبي لتطبيق الاختبارات التلقائية على أساسنا. كان على كل فريق التقاط صورة ذهبية وتطوير الاختبارات فيها وتكييفها مع مشروعهم. لقد نشرنا في بنك GitLab-CI ، حيث قمنا بتكوينه:

• يعمل يوميا لجميع autotests المكتوبة لكل مشروع.
  
• تطلق في خط أنابيب التجميع.
  

في البداية كانت هناك اختبارات قليلة ، وذهبوا في تيار واحد. كان الإطلاق ذو الخيوط الفردية على GitLab Windows-runner مرضيًا للغاية بالنسبة لنا: لقد حملت الاختبارات طفيفًا على منصة الاختبار ولم تستخدم الموارد تقريبًا.

بمرور الوقت ، أصبحت الاختبارات التلقائية أكثر فأكثر ، وفكرنا في تشغيلها بشكل متوازٍ ، عندما بدأ التشغيل الكامل يستغرق حوالي ثلاث ساعات. كانت هناك مشاكل أخرى:

• لم نتمكن من التأكد من أن الاختبارات مستقرة ؛
  
• الاختبارات التي مرت عدة أشواط على التوالي على الجهاز المحلي وقعت في بعض الأحيان إلى 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 جيجابايت من ذاكرة الوصول العشوائي ، 1 موضوع)

إيجابيات الاختبارات أحادية الخيوط:

• من السهل تكوين وتشغيل.
  
• عمليات الإطلاق في CI لا تختلف عملياً عن عمليات الإطلاق المحلية ؛
  
• الاختبارات لا تؤثر على بعضها البعض.
  
• الحد الأدنى من متطلبات الموارد عداء.
  

سلبيات الاختبارات أحادية الخيوط:

• المدى الطويل جدا ؛
  
• استقرار طويل من الاختبارات.
  
• الاستخدام غير الفعال للموارد عداء ، واستخدام منخفضة للغاية.
  

اختبارات شوكة JVM

نظرًا لأننا لم نهتم بالكود الآمن للخيط عند تنفيذ الإطار الأساسي ، أصبح الخيار-jvm-parallel-plugin الخاص بـ Maven الطريقة الأكثر وضوحًا للتشغيل بشكل متوازٍ. المكوّن الإضافي سهل التهيئة ، لكن من أجل التشغيل المتوازي الصحيح للاختبارات التلقائية ، يلزمك تشغيلها في متصفحات منفصلة. لا شيء يجب القيام به ، وكان علي استخدام سيلينويد.

تم رفع خادم Selenoid على جهاز به 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" 

إذا قمت بتمرير العلامة بهذه الطريقة ، فإن المكون الإضافي سينشئ متسابقين لجميع الاختبارات ، أي محاولة إجراء جميع الاختبارات ، وتخطيها مباشرة بعد إطلاقها وإنشاء الكثير من شوكات 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> 

مثال على تقرير ألور (أكثر الاختبارات غير المستقرة ، 4 رييرانا)

حمل عداء أثناء الاختبارات (8 مراكز ، 8 جيجابايت من ذاكرة الوصول العشوائي ، 12 موضوع)

الايجابيات:

• إعداد بسيط - تحتاج فقط إلى إضافة البرنامج المساعد ؛
  
• القدرة على إجراء عدد كبير من الاختبارات في وقت واحد ؛
  
• تثبيت أسرع للاختبارات بفضل الادعاء 1.
  

سلبيات:

• متعددة OS / الحاويات المطلوبة ؛
  
• استهلاك موارد مرتفع لكل شوكة ؛
  
• تم إهمال المكون الإضافي ولم يعد مدعومًا.
  

كيفية التغلب على عدم الاستقرار

منصات الاختبار ليست مثالية ، وكذلك اختبارات السيارات نفسها. ليس من المستغرب ، حصلنا على عدد من الاختبارات الرقيقة. جاء المساعد الإضافي المؤكّد لإطلاق النار ، والذي يدعم إعادة تشغيل الاختبارات الساقطة. تحتاج إلى تحديث إصدار البرنامج المساعد إلى 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> 

أو عند بدء التشغيل: mvn ... -Dsurefire.rerunFailingTestsCount = 2 ...
بدلاً من ذلك ، قم بتعيين خيارات Maven للبرنامج النصي PowerShell (PS1):

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

الايجابيات:

• لا حاجة لإضاعة الوقت في تحليل اختبار غير مستقر عند تعطله ؛
  
• يمكنك تهدئة مشاكل الاستقرار لمقعد الاختبار.
  

سلبيات:

• يمكنك تخطي العيوب العائمة.
  
• يتم زيادة وقت التشغيل.
  

اختبارات موازية مع مكتبة الخيار 4

نما عدد الاختبارات كل يوم. فكرنا مرة أخرى في تسريع الأشواط. بالإضافة إلى ذلك ، أردت دمج أكبر عدد ممكن من الاختبارات في تجميع خط أنابيب التطبيق. كان العامل الحاسم هو الجيل الطويل جدًا من المتسابقين عند الركض بالتوازي باستخدام البرنامج المساعد Maven.

تم إصدار الخيار 4 بالفعل في ذلك الوقت ، لذلك قررنا إعادة كتابة النواة لهذا الإصدار. في ملاحظات الإصدار ، وعدنا بإطلاق مواز على مستوى الخيط. من الناحية النظرية ، ينبغي أن يكون هذا:

• تسريع تشغيل autotests عن طريق زيادة عدد مؤشرات الترابط؛
  
• استبعاد ضياع الوقت لتوليد العدائين لكل autotest.
  

لم يكن تحسين إطار الاختبارات التلقائية متعددة الخيوط أمرًا صعبًا للغاية. يقوم الخيار 4 بإجراء كل اختبار فردي في سلسلة رسائل مخصصة من البداية إلى النهاية ، لذلك تم تحويل بعض الأشياء الثابتة الشائعة إلى متغيرات ThreadLocal.
الشيء الرئيسي عند التحويل باستخدام أدوات إعادة تكوين Idea هو التحقق من الأماكن التي تمت مقارنة المتغير فيها (على سبيل المثال ، التحقق من وجود قيمة خالية). بالإضافة إلى ذلك ، تحتاج إلى تقديم المكون الإضافي 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> 

مثال على تقرير ألور (أكثر الاختبارات غير المستقرة ، 5 ريانات)

حمل عداء أثناء الاختبارات (8 مراكز ، 8 جيجابايت من ذاكرة الوصول العشوائي ، 24 موضوع)

الايجابيات:

• انخفاض استهلاك الموارد ؛
  
• دعم محلي من Cucumber - لا توجد أدوات إضافية مطلوبة ؛
  
• القدرة على تشغيل أكثر من 6 سلاسل في قلب المعالج.
  

سلبيات:

• تحتاج إلى التأكد من أن الكود يدعم التنفيذ متعدد الخيوط ؛
  
• يزيد عتبة الدخول.
  

جاذبية التقارير في صفحات GitLab

بعد إدخال الإطلاق متعدد مؤشرات الترابط ، بدأنا في قضاء المزيد من الوقت في تحليل التقارير. في ذلك الوقت ، اضطررنا إلى تحميل كل تقرير كأداة في GitLab ، ثم تنزيله وإلغاء حزمه. انها ليست مريحة جدا وطويلة. وإذا أراد شخص آخر رؤية التقرير في المنزل ، فسيحتاج إلى القيام بنفس العمليات. أردنا الحصول على التعليقات بشكل أسرع ، وكان هناك مخرج - صفحات GitLab. هذه ميزة مضمّنة متوفرة خارج الصندوق في جميع الإصدارات الحديثة من GitLab. يتيح لك نشر مواقع ثابتة على الخادم الخاص بك والوصول إليها عبر رابط مباشر.

تم إجراء جميع لقطات الشاشة مع تقارير Allure في صفحات GitLab. البرنامج النصي لنشر التقرير على صفحات 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 

ما هي النتيجة

لذا ، إذا كنت تفكر فيما إذا كنت بحاجة إلى رمز آمن لمؤشر الترابط في إطار عمل الخيار التلقائي ، فإن الإجابة الآن واضحة - مع تطبيق Cucumber 4 ، من السهل تنفيذه ، مما يؤدي إلى زيادة عدد الخيوط التي يتم إطلاقها في وقت واحد بشكل ملحوظ. مع هذه الطريقة لتشغيل الاختبارات ، فإن السؤال يدور بالفعل حول أداء الجهاز باستخدام Selenoid ومقعد الاختبار.

أظهرت الممارسة أن إجراء الاختبارات التلقائية على سلاسل العمليات يمكن أن يقلل من استهلاك الموارد بأفضل أداء. كما يتضح من الرسوم البيانية ، فإن الزيادة في التدفقات بمقدار ضعفين لا تؤدي إلى تسارع مماثل في اجتياز اختبارات الأداء. ومع ذلك ، تمكنا من إضافة أكثر من 200 اختبار تلقائي إلى مجموعة التطبيقات ، والتي حتى مع 5 ريانات يمكن إكمالها في غضون 24 دقيقة تقريبًا. يتيح لك ذلك تلقي تعليقات سريعة منهم ، وإذا لزم الأمر ، قم بإجراء التغييرات وكرر الإجراء مرة أخرى.