يقوم قسمنا بإنشاء خطوط أنابيب أوتوماتيكية بالكامل لجلب إصدارات جديدة من التطبيقات إلى بيئة الإنتاج. بالطبع ، هذا يتطلب اختبارات وظيفية آلية. يوجد تحت القص قصة حول كيف ، بدءًا من الاختبار في مؤشر ترابط واحد على جهاز محلي ، وصلنا إلى إطلاق متعدد الخيوط للاختبارات التلقائية على Selenoid في خط أنابيب التجميع مع تقرير Allure على صفحات GitLab ، ونتيجة لذلك ، نحن حصلت على أداة أتمتة رائعة يمكن للمستخدمين في المستقبل استخدامها. أوامر.
من أين بدأنا
لتنفيذ الاختبارات التلقائية ودمجها في خط الأنابيب ، احتجنا إلى إطار عمل آلي يمكن تغييره بمرونة حسب احتياجاتنا. من الناحية المثالية ، كنت أرغب في الحصول على معيار واحد لمحرك الاختبار التلقائي ، تم تكييفه لتضمين الاختبارات التلقائية في خط الأنابيب. للتنفيذ ، اخترنا التقنيات التالية:
- جافا،
- مخضرم ،
- السيلينيوم،
- خيار + يونيو 4 ،
- إغراء،
- جيت لاب.
لماذا هذه المجموعة بالذات؟ تعد Java واحدة من أكثر اللغات شيوعًا للاختبارات التلقائية ، وإلى جانب ذلك ، يعرفها جميع أعضاء الفريق. السيلينيوم هو الحل الواضح. كان من المفترض أن يؤدي الخيار ، من بين أمور أخرى ، إلى زيادة الثقة في نتائج الاختبارات التلقائية من الأقسام المشاركة في الاختبار اليدوي.
اختبارات مترابطة واحدة
من أجل عدم إعادة اختراع العجلة ، أخذنا التطورات من مستودعات مختلفة على GitHub كأساس لإطار العمل وقمنا بتكييفها لأنفسنا. أنشأنا مستودعًا للمكتبة الرئيسية مع جوهر إطار عمل الاختبار التلقائي ومستودعًا به مثال ذهبي لتنفيذ الاختبارات التلقائية على جوهرنا. كان على كل فريق التقاط صورة ذهبية وتطوير الاختبارات فيها ، وتكييفها مع مشروعهم. تم النشر في بنك GitLab-CI ، حيث قمنا بتكوينه:
- الإطلاق اليومي لجميع الاختبارات التلقائية المكتوبة لكل مشروع ؛
- يعمل في خط أنابيب البناء.
في البداية ، كان هناك عدد قليل من الاختبارات ، وذهبوا في جدول واحد. كان التشغيل أحادي الخيط على 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
نظرًا لأننا لم نهتم برمز مؤشر الترابط الآمن عند تنفيذ إطار العمل الأساسي ، فإن الطريقة الأكثر وضوحًا للتشغيل بالتوازي كانت للخبير. من السهل إعداد المكون الإضافي ، ولكن من أجل التشغيل المتوازي الصحيح ، يجب تشغيل الاختبارات التلقائية في متصفحات منفصلة. لا شيء لأفعله ، كان علي استخدام السيلينويد.
تم رفع خادم 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 ... خيارات الخيار:
[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 على الأقل وكتابة سطر واحد مع عدد مرات إعادة التشغيل في ملف 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"الايجابيات:
- لا داعي لإضاعة الوقت في تحليل اختبار غير مستقر عند تعطله ؛
- يمكن أن يخفف من مشاكل استقرار مقاعد البدلاء.
سلبيات:
- يمكنك تخطي العيوب العائمة ؛
- يزيد وقت التشغيل.
اختبارات موازية مع مكتبة Cucumber 4
زاد عدد الاختبارات كل يوم. فكرنا مرة أخرى في تسريع الجري. بالإضافة إلى ذلك ، أردت تضمين أكبر عدد ممكن من الاختبارات في خط أنابيب تجميع التطبيق. كان العامل الحاسم هو الجيل الطويل جدًا من المتسابقين عند الجري بالتوازي باستخدام البرنامج المساعد Maven.
في ذلك الوقت ، تم إصدار Cucumber 4 بالفعل ، لذلك قررنا إعادة كتابة النواة لهذا الإصدار. في ملاحظات الإصدار ، تلقينا وعودًا بإطلاق موازٍ على مستوى سلسلة المحادثات. من الناحية النظرية ، كان ينبغي أن يكون هذا:
- تسريع تشغيل الاختبارات التلقائية بشكل كبير من خلال زيادة عدد الخيوط ؛
- القضاء على ضياع الوقت لتوليد العدائين لكل اختبار تلقائي.
اتضح أنه ليس من الصعب للغاية تحسين إطار عمل الاختبارات التلقائية متعددة الخيوط. يقوم Cucumber 4 بتشغيل كل اختبار في سلسلة مخصصة من البداية إلى النهاية ، لذلك تم تحويل بعض الأشياء الثابتة الشائعة ببساطة إلى متغيرات ThreadLocal.
الشيء الرئيسي عند التحويل باستخدام Idea refactoring هو التحقق من الأماكن التي تمت فيها مقارنة المتغير (على سبيل المثال ، التحقق من وجود قيمة خالية). بالإضافة إلى ذلك ، تحتاج إلى وضع المكون الإضافي 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 خيطًا)
الايجابيات:
- انخفاض استهلاك الموارد ؛
- دعم محلي من الخيار - لا توجد حاجة إلى أدوات إضافية ؛
- القدرة على تشغيل أكثر من 6 خيوط لكل نواة معالج.
سلبيات:
- تحتاج إلى التأكد من أن الكود يدعم التنفيذ متعدد الخيوط ؛
- يزيد عتبة الدخول.
تقارير الجاذبية في صفحات 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 safe في إطار Cucumber autotest ، فإن الإجابة الآن واضحة - مع Cucumber 4 من السهل تنفيذها ، وبالتالي زيادة كبيرة في عدد الخيوط التي تعمل في وقت واحد. باستخدام طريقة إجراء الاختبارات هذه ، فإن السؤال يدور بالفعل حول أداء الجهاز باستخدام السيلينويد ومنضدة الاختبار.
أظهرت الممارسة أن تشغيل الاختبارات التلقائية على سلاسل الرسائل يسمح لك بتقليل استهلاك الموارد إلى الحد الأدنى مع أفضل أداء. كما يتضح من الرسوم البيانية ، لا تؤدي زيادة 2x في الخيوط إلى تسارع مماثل في اجتياز اختبارات الأداء. ومع ذلك ، تمكنا من إضافة أكثر من 200 اختبار آلي إلى بنية التطبيق ، والتي ، حتى مع إعادة التشغيل 5 ، يتم الانتهاء منها في حوالي 24 دقيقة. يتيح لك ذلك الحصول على تعليقات سريعة منهم ، وإذا لزم الأمر ، قم بإجراء التغييرات وكرر الإجراء مرة أخرى.
المصدر: www.habr.com