🥇 لاڳو ڪرڻ، ماپ: VTB تي آٽو ٽيسٽ استعمال ڪرڻ ۾ تجربو

اسان جي ڊويزن پيداوار جي ماحول ۾ ايپليڪيشنن جا نوان ورزن شروع ڪرڻ لاءِ مڪمل طور تي خودڪار پائپ لائنون ٺاهي ٿي. يقينا، هن کي خودڪار فنڪشنل ٽيسٽ جي ضرورت آهي. هيٺ ڏنل ڪٽ جي باري ۾ هڪ ڪهاڻي آهي ته ڪيئن، هڪ لوڪل مشين تي سنگل ٿريڊ ٽيسٽنگ سان شروع ڪندي، اسان گيٽ ليب پيجز تي ايلور رپورٽ سان گڏ بلڊ پائپ لائن ۾ Selenoid تي هلندڙ ملٽي ٿريڊ آٽو ٽيسٽ جي نقطي تي پهتاسين ۽ آخرڪار هڪ بهترين آٽوميشن ٽول حاصل ڪيو. جيڪي مستقبل جا ماڻهو ٽيمون استعمال ڪري سگهن ٿا.

اسان ڪٿان شروع ڪيو؟

آٽو ٽيسٽ کي لاڳو ڪرڻ ۽ انهن کي پائپ لائن ۾ ضم ڪرڻ لاءِ، اسان کي هڪ آٽوميشن فريم ورڪ جي ضرورت هئي جيڪا اسان جي ضرورتن مطابق لچڪدار طريقي سان تبديل ٿي سگهي. مثالي طور، مان آٽو ٽيسٽنگ انجڻ لاءِ هڪ واحد معيار حاصل ڪرڻ چاهيان ٿو، آٽو ٽيسٽ کي پائپ لائن ۾ شامل ڪرڻ لاءِ ٺاهيل. لاڳو ڪرڻ لاء اسان هيٺ ڏنل ٽيڪنالاجيون چونڊيون ٿا:

جاوا ،
ماون،
سلينيم،
ڪڪڙ + JUNIT 4،
رغبت،
گٽ لاب.

هي خاص سيٽ ڇو؟ جاوا خودڪار ٽيسٽ لاءِ مشهور ٻولين مان هڪ آهي، ۽ ٽيم جا سڀئي ميمبر ان کي ڳالهائين ٿا. Selenium واضح حل آهي. ڪڪڙ، ٻين شين جي وچ ۾، دستي جاچ ۾ شامل شعبن جي حصي تي خودڪار ٽيسٽن جي نتيجن تي اعتماد وڌائڻو هو.

سنگل ٿريڊ ٽيسٽ

ڦيٿي کي ٻيهر نه آڻڻ لاءِ، اسان GitHub تي مختلف ذخيرن مان ترقيون ورتيون جيئن فريم ورڪ جي بنياد تي ۽ انهن کي پاڻ لاءِ ترتيب ڏنو. اسان بنيادي لائبريري لاءِ آٽو ٽيسٽ فريم ورڪ جي بنيادي سان گڏ هڪ مخزن ٺاهيو ۽ اسان جي ڪور تي آٽو ٽيسٽ لاڳو ڪرڻ جي گولڊ مثال سان گڏ هڪ مخزن. هر ٽيم کي گولڊ جي تصوير وٺڻي هئي ۽ ان ۾ ٽيسٽون تيار ڪرڻيون هيون، ان کي پنهنجي پروجيڪٽ جي مطابق ٺاهيندي. اسان بينڪ ۾ 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 GB ريم، 1 موضوع)

سنگل ٿريڊ ٽيسٽ جا فائدا:

قائم ڪرڻ ۽ هلائڻ لاء آسان؛
CI ۾ لانچون عملي طور تي مقامي لانچن کان مختلف نه آهن؛
ٽيسٽ هڪ ٻئي تي اثر انداز نه ڪندا آھن؛
رنر وسيلن لاء گھٽ ۾ گھٽ گهربل.

سنگل ٿريڊ ٽيسٽ جا نقصان:

مڪمل ڪرڻ لاء تمام ڊگهو وقت وٺي؛
ٽيسٽ جي ڊگهي استحڪام؛
رنر وسيلن جو غير موثر استعمال، انتهائي گهٽ استعمال.

JVM فورڪس تي ٽيسٽ

جيئن ته اسان بنيادي فريم ورڪ کي لاڳو ڪرڻ وقت ٿريڊ-سيف ڪوڊ جو خيال نه رکيو، متوازي ۾ هلائڻ جو سڀ کان واضح طريقو هو. cucumber-jvm-parallel-plugin Maven لاء. پلگ ان کي ترتيب ڏيڻ آسان آهي، پر صحيح متوازي آپريشن لاء، آٽو ٽيسٽ کي الڳ برائوزرن ۾ هلائڻ گهرجي. ڪرڻ لاء ڪجھ به ناهي، مون کي Selenoid استعمال ڪرڻو پيو.

Selenoid سرور هڪ مشين تي 32 ڪور ۽ 24 GB ريم سان شروع ڪيو ويو. حد مقرر ڪئي وئي 48 برائوزرن تي - 1,5 ٿريڊس في ڪور ۽ اٽڪل 400 MB رام. نتيجي طور، ٽيسٽ جو وقت ٽن ڪلاڪن کان 40 منٽن تائين گھٽجي ويو. رن کي تيز ڪرڻ سان اسٽيبلائيزيشن جي مسئلي کي حل ڪرڻ ۾ مدد ملي ٿي: ھاڻي اسان جلدي 20-30 ڀيرا نوان آٽو ٽيسٽ هلائي سگھون ٿا جيستائين اسان کي پڪ ٿي وڃي ته اھي معتبر طور ھلندا آھن.
حل جي پهرين خرابي رنر وسيلن جو تمام گهڻو استعمال هو، ٿوري تعداد ۾ متوازي موضوعن سان: 4 ڪور ۽ 8 GB جي ريم تي، ٽيسٽ 6 کان وڌيڪ موضوعن سان مستحڪم طور تي ڪم ڪيو. ٻيو نقصان: پلگ ان هر منظرنامي لاءِ رنر ڪلاس ٺاهي ٿو، ان کان سواءِ انهن مان ڪيترا لانچ ڪيا ويا آهن.

اھم! ٽيگ سان گڏ متغير کي پاس نه ڪريو آرگ لائنمثال طور، هن طرح:

<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 GB ريم، 12 موضوع)

پرو:

آسان سيٽ اپ - توهان کي صرف هڪ پلگ ان شامل ڪرڻ جي ضرورت آهي؛
هڪ ئي وقت ۾ وڏي تعداد ۾ ٽيسٽ ڪرڻ جي صلاحيت؛
ٽيسٽ اسٽيبلائيزيشن جي تيز رفتار قدم 1 جي مهرباني.

ڪن

گھڻن او ايس / ڪنٽينر گهربل؛
هر ڪانٽو لاء اعلي وسيلن جو استعمال؛
پلگ ان پراڻو آھي ۽ ھاڻي سپورٽ ناھي.

عدم استحڪام کي ڪيئن ختم ڪجي

ٽيسٽ بينچ مثالي نه آهن، جهڙوڪ خودڪار ٽيسٽ پاڻ کي. اها تعجب جي ڳالهه ناهي ته اسان وٽ ڪيترائي فلڪي ٽيسٽ آهن. بچاءَ لاءِ آيو maven surefire پلگ ان، جيڪو باڪس کان ٻاهر ناڪام ٽيسٽ کي ٻيهر شروع ڪرڻ جي حمايت ڪري ٿو. توھان کي پلگ ان ورزن کي گھٽ ۾ گھٽ 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 …
هڪ اختيار جي طور تي، پاور شيل اسڪرپٽ (PS1) لاءِ Maven جا اختيار مقرر ڪريو:

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

پرو:

هڪ غير مستحڪم ٽيسٽ جي تجزيي ۾ وقت ضايع ڪرڻ جي ضرورت ناهي جڏهن اهو حادثو ٿئي ٿو؛
ٽيسٽ بينچ جي استحڪام جي مسئلن کي گھٽائي سگھجي ٿو.

ڪن

سچل عيب ياد ڪري سگهجي ٿو؛
هلائڻ جو وقت وڌي ٿو.

ڪڪمبر 4 لائبريري سان متوازي ٽيسٽ

ٽيسٽن جو تعداد هر روز وڌندو ويو. اسان وري رن کي تيز ڪرڻ بابت سوچيو. ان کان علاوه، مان چاهيان ٿو ته ممڪن طور تي ڪيترن ئي تجربن کي ايپليڪيشن اسيمبليء جي پائپ لائن ۾ ضم ڪرڻ. نازڪ عنصر اهو هو ته ڊوڙندڙن جو نسل تمام ڊگهو ٿي ويو جڏهن متوازي ۾ هلندي Maven پلگ ان استعمال ڪندي.

ان وقت، ڪڪڙ 4 اڳ ۾ ئي جاري ڪيو ويو هو، تنهنڪري اسان هن نسخي لاء ڪنييل کي ٻيهر لکڻ جو فيصلو ڪيو. رليز نوٽس ۾ اسان کي واعدو ڪيو ويو هو ته سلسلي جي سطح تي متوازي لانچ. نظرياتي طور تي اهو هجڻ گهرجي:

خاص طور تي آٽو ٽيسٽ جي هلائڻ کي تيز ڪرڻ سان سلسلا جو تعداد وڌائي؛
هر آٽو ٽيسٽ لاءِ رنرز پيدا ڪرڻ تي وقت جي نقصان کي ختم ڪريو.

گھڻن موضوعن واري آٽو ٽيسٽ لاء فريم ورڪ کي بهتر ڪرڻ ايترو ڏکيو نه ٿيو. ڪڪڙ 4 هر هڪ انفرادي ٽيسٽ کي شروع کان آخر تائين وقف ٿيل ٿريڊ تي هلائي ٿو، تنهنڪري ڪجهه عام جامد شيون صرف ThreadLocal variables ۾ تبديل ڪيون ويون.
Idea refactoring tools کي استعمال ڪندي تبديل ڪرڻ وقت بنيادي شيءِ انهن هنڌن کي چيڪ ڪرڻ آهي جتي متغير جو مقابلو ڪيو ويو هو (مثال طور، null جي چڪاس ڪرڻ). اضافي طور تي، توهان کي شامل ڪرڻ جي ضرورت آهي Allure پلگ ان جونٽ رنر ڪلاس جي تشريح ۾.

خودڪار ٽيسٽ قائم ڪرڻ جو مثال:

 
<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 GB ريم، 24 موضوع)

پرو:

گھٽ وسيلن جي واپرائڻ؛
ڪڪڙ مان اصلي مدد - اضافي اوزار جي ضرورت ناهي؛
في پروسيسر ڪور کان وڌيڪ 6 موضوعن کي هلائڻ جي صلاحيت.

ڪن

توھان کي پڪ ڪرڻ جي ضرورت آھي ته ڪوڊ گھڻن موضوعن جي عمل کي سپورٽ ڪري ٿو.
داخلا جي حد وڌائي ٿي.

GitLab صفحن تي رغبت جون رپورٽون

ملٽي ٿريڊ ايگزيڪيوشن کي متعارف ڪرائڻ کان پوءِ، اسان رپورٽن جو تجزيو ڪرڻ ۾ گهڻو وقت گذارڻ شروع ڪيو. ان وقت، اسان کي هر رپورٽ کي GitLab تي هڪ نموني طور اپلوڊ ڪرڻو هو، پوء ان کي ڊائونلوڊ ڪريو ۽ ان کي کوليو. اهو تمام آسان ناهي ۽ گهڻو وقت وٺندو آهي. ۽ جيڪڏھن ڪو ٻيو پنھنجي لاءِ رپورٽ ڏسڻ گھري، پوءِ انھن کي ساڳيون ئي آپريشنون ڪرڻيون پونديون. اسان تيزيءَ سان موٽ حاصل ڪرڻ چاهيون ٿا، ۽ اسان هڪ حل ڳولي لڌو - GitLab صفحا. هي هڪ تعمير ٿيل خصوصيت آهي جيڪا دٻي کان ٻاهر موجود آهي GitLab جي سڀني تازي ورزن ۾. توهان کي توهان جي سرور تي جامد سائيٽن کي ترتيب ڏيڻ جي اجازت ڏئي ٿي ۽ انهن کي سڌو لنڪ ذريعي رسائي ڪريو.

Allure رپورٽن جا سڀئي اسڪرين شاٽ ورتيون ويون GitLab صفحن تي. GitLab صفحن تي رپورٽ کي ترتيب ڏيڻ لاء اسڪرپٽ - ونڊوز پاور شيل ۾ (ان کان اڳ توهان کي خودڪار ٽيسٽ هلائڻ جي ضرورت آهي):

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

آخر ۾ ڇا ٿيو

تنهن ڪري، جيڪڏهن توهان اهو سوچي رهيا آهيو ته ڇا توهان کي Cucumber autotest فريم ورڪ ۾ ٿريڊ محفوظ ڪوڊ جي ضرورت آهي، هاڻي جواب واضح آهي - Cucumber 4 سان ان کي لاڳو ڪرڻ آسان آهي، انهي سان گڏ هڪ ئي وقت شروع ٿيندڙ ٿريڊن جو تعداد خاص طور تي وڌي ٿو. ٽيسٽ هلائڻ جي هن طريقي سان، سوال هاڻي Selenoid ۽ ٽيسٽ بينچ سان مشين جي ڪارڪردگي بابت آهي.

مشق ڏيکاريو ويو آهي ته ٿريڊز تي هلندڙ آٽو ٽيسٽ توهان کي بهترين ڪارڪردگي سان گهٽ ۾ گهٽ وسيلن جي استعمال کي گهٽائڻ جي اجازت ڏئي ٿو. جيئن ته گراف مان ڏسي سگھجي ٿو، ٿريڊز کي ٻيڻو ڪرڻ سان ڪارڪردگي ٽيسٽن ۾ هڪ جهڙي تيز رفتاري نه ٿي ٿئي. جڏهن ته، اسان ايپليڪيشن جي تعمير ۾ 2 کان وڌيڪ خودڪار ٽيسٽ شامل ڪرڻ جي قابل هئا، جيڪي 200 ريرن سان گڏ تقريبا 5 منٽن ۾ هلندا آهن. اهو توهان کي انهن کان تڪڙو موٽ حاصل ڪرڻ جي اجازت ڏئي ٿو، ۽، جيڪڏهن ضروري هجي ته، تبديليون ڪريو ۽ طريقيڪار کي ٻيهر ورجايو.

جو ذريعو: www.habr.com

لاڳو ڪريو، پيماني تي: VTB تي خودڪار ٽيسٽ استعمال ڪرڻ جو تجربو

اسان ڪٿان شروع ڪيو؟

سنگل ٿريڊ ٽيسٽ

JVM فورڪس تي ٽيسٽ

عدم استحڪام کي ڪيئن ختم ڪجي

ڪڪمبر 4 لائبريري سان متوازي ٽيسٽ

GitLab صفحن تي رغبت جون رپورٽون

آخر ۾ ڇا ٿيو

تبصرو شامل ڪريو جواب منسوخ