ہمارا ڈویژن پروڈکشن ماحول میں ایپلی کیشنز کے نئے ورژن شروع کرنے کے لیے مکمل طور پر خودکار پائپ لائنز بناتا ہے۔ یقینا، اس کے لیے خودکار فنکشنل ٹیسٹ کی ضرورت ہے۔ کٹ کے نیچے اس بارے میں ایک کہانی ہے کہ کس طرح، ایک مقامی مشین پر سنگل تھریڈ ٹیسٹنگ کے ساتھ شروع کرتے ہوئے، ہم گٹ لیب کے صفحات پر ایلور رپورٹ کے ساتھ سیلینائیڈ پر چلنے والے ملٹی تھریڈڈ آٹو ٹیسٹ کے مقام تک پہنچے اور آخر کار ایک زبردست آٹومیشن ٹول حاصل کیا۔ تاکہ مستقبل کے لوگ ٹیموں کو استعمال کرسکیں۔
ہم نے کہاں سے شروع کیا؟
آٹو ٹیسٹس کو لاگو کرنے اور انہیں پائپ لائن میں ضم کرنے کے لیے، ہمیں ایک آٹومیشن فریم ورک کی ضرورت تھی جسے ہماری ضروریات کے مطابق لچکدار طریقے سے تبدیل کیا جا سکے۔ مثالی طور پر، میں آٹو ٹیسٹنگ انجن کے لیے ایک واحد معیار حاصل کرنا چاہتا تھا، جو پائپ لائن میں آٹو ٹیسٹس کو سرایت کرنے کے لیے ڈھال لیا گیا تھا۔ عمل درآمد کے لیے ہم نے درج ذیل ٹیکنالوجیز کا انتخاب کیا:
- جاوا ،
- ماون،
- سیلینیم،
- کھیرا + JUNIT 4،
- رغبت
- گٹ لیب۔
یہ مخصوص سیٹ کیوں؟ جاوا خودکار ٹیسٹوں کے لیے مقبول ترین زبانوں میں سے ایک ہے، اور ٹیم کے تمام اراکین اسے بولتے ہیں۔ سیلینیم واضح حل ہے۔ کھیرا، دیگر چیزوں کے علاوہ، دستی جانچ میں شامل محکموں کی جانب سے خودکار ٹیسٹوں کے نتائج پر اعتماد بڑھانا تھا۔
سنگل تھریڈڈ ٹیسٹ
پہیے کو دوبارہ ایجاد نہ کرنے کے لیے، ہم نے فریم ورک کی بنیاد کے طور پر GitHub پر مختلف ذخیروں سے پیش رفت لی اور انہیں اپنے لیے ڈھال لیا۔ ہم نے مرکزی لائبریری کے لیے آٹوٹیسٹ فریم ورک کے ساتھ ایک ذخیرہ بنایا اور اپنے کور پر آٹو ٹیسٹس کو نافذ کرنے کی سنہری مثال کے ساتھ ایک ذخیرہ بنایا۔ ہر ٹیم کو گولڈ امیج لینا تھا اور اس میں ٹیسٹ تیار کرنا تھا، اسے اپنے پروجیکٹ کے مطابق ڈھالنا تھا۔ ہم نے اسے GitLab-CI بینک میں تعینات کیا، جس پر ہم نے ترتیب دیا:
- ہر پروجیکٹ کے لیے تمام تحریری آٹو ٹیسٹس کے روزانہ چلتے ہیں؛
- تعمیر پائپ لائن میں شروع.
پہلے کچھ ٹیسٹ تھے، اور وہ ایک ہی سلسلے میں کیے گئے تھے۔ ونڈوز رنر گٹ لیب پر سنگل تھریڈڈ رننگ ہمارے لیے کافی موزوں تھی: ٹیسٹوں نے ٹیسٹ بینچ کو بہت ہلکے سے لوڈ کیا اور تقریباً کوئی وسائل استعمال نہیں کیے تھے۔
وقت گزرنے کے ساتھ، آٹو ٹیسٹس کی تعداد زیادہ سے زیادہ ہوتی گئی، اور ہم نے انہیں متوازی طور پر چلانے کے بارے میں سوچا، جب مکمل دوڑ میں تقریباً تین گھنٹے لگنے لگے۔ دیگر مسائل بھی سامنے آئے:
- ہم اس بات کی تصدیق نہیں کر سکے کہ ٹیسٹ مستحکم تھے۔
- مقامی مشین پر لگاتار کئی بار چلنے والے ٹیسٹ بعض اوقات 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 فورکس پر ٹیسٹ
چونکہ ہم نے بیس فریم ورک کو لاگو کرتے وقت تھریڈ سیف کوڈ کا خیال نہیں رکھا، اس لیے متوازی طور پر چلانے کا سب سے واضح طریقہ تھا Maven کے لئے. پلگ ان کو ترتیب دینا آسان ہے، لیکن درست متوازی آپریشن کے لیے، الگ الگ براؤزرز میں آٹو ٹیسٹس چلائے جانے چاہئیں۔ کرنے کو کچھ نہیں ہے، مجھے Selenoid استعمال کرنا پڑا۔
Selenoid سرور 32 کور اور 24 GB RAM والی مشین پر لانچ کیا گیا تھا۔ حد 48 براؤزرز پر رکھی گئی تھی - 1,5 تھریڈز فی کور اور تقریباً 400 MB RAM۔ نتیجتاً، ٹیسٹ کا وقت تین گھنٹے سے کم کر کے 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 کی بدولت ٹیسٹ اسٹیبلائزیشن کی سرعت۔
Cons:
- ایک سے زیادہ OS/کنٹینرز کی ضرورت ہے۔
- ہر کانٹے کے لئے اعلی وسائل کی کھپت؛
- پلگ ان پرانا ہے اور مزید تعاون یافتہ نہیں ہے۔
عدم استحکام پر قابو پانے کا طریقہ
ٹیسٹ بینچ مثالی نہیں ہیں، بالکل اسی طرح جیسے خود خود ٹیسٹ کرتے ہیں۔ یہ تعجب کی بات نہیں ہے کہ ہمارے پاس بہت سارے فلیکی ٹیسٹ ہیں۔ بچاؤ کے لیے آیا، جو باکس سے باہر ناکام ٹیسٹوں کو دوبارہ شروع کرنے کی حمایت کرتا ہے۔ آپ کو پلگ ان ورژن کو کم از کم 2.21 میں اپ ڈیٹ کرنے اور پوم فائل میں دوبارہ شروع ہونے کی تعداد کے ساتھ ایک لائن لکھنے کی ضرورت ہے یا اسے 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 …
ایک اختیار کے طور پر، PowerShell اسکرپٹ (PS1) کے لیے Maven کے اختیارات سیٹ کریں:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"پیشہ:
- غیر مستحکم ٹیسٹ کے کریش ہونے پر اس کا تجزیہ کرنے میں وقت ضائع کرنے کی ضرورت نہیں؛
- ٹیسٹ بینچ استحکام کے مسائل کو کم کیا جا سکتا ہے.
Cons:
- تیرتے نقائص کو یاد کیا جا سکتا ہے؛
- چلانے کا وقت بڑھتا ہے.
ککڑی 4 لائبریری کے ساتھ متوازی ٹیسٹ
ٹیسٹوں کی تعداد روز بروز بڑھتی گئی۔ ہم نے پھر سے رنز کی رفتار بڑھانے کے بارے میں سوچا۔ اس کے علاوہ، میں درخواست اسمبلی پائپ لائن میں زیادہ سے زیادہ ٹیسٹوں کو ضم کرنا چاہتا تھا۔ اہم عنصر یہ تھا کہ ماون پلگ ان کا استعمال کرتے ہوئے متوازی طور پر دوڑنے والوں کی نسل میں بہت زیادہ وقت لگتا تھا۔
اس وقت، ککڑی 4 پہلے ہی جاری کیا گیا تھا، لہذا ہم نے اس ورژن کے لئے دانا کو دوبارہ لکھنے کا فیصلہ کیا. ریلیز نوٹس میں ہم سے تھریڈ لیول پر متوازی لانچ کا وعدہ کیا گیا تھا۔ نظریاتی طور پر یہ ہونا چاہئے:
- دھاگوں کی تعداد میں اضافہ کرکے آٹوٹیسٹ کے چلانے کو نمایاں طور پر تیز کرنا؛
- ہر آٹو ٹیسٹ کے لیے رنر پیدا کرنے میں وقت کے ضیاع کو ختم کریں۔
ملٹی تھریڈڈ آٹو ٹیسٹس کے لیے فریم ورک کو بہتر بنانا اتنا مشکل نہیں تھا۔ کھیرا 4 ہر انفرادی ٹیسٹ کو شروع سے آخر تک ایک مخصوص دھاگے پر چلاتا ہے، اس لیے کچھ عام جامد چیزوں کو صرف ThreadLocal متغیرات میں تبدیل کر دیا گیا۔
آئیڈیا ری فیکٹرنگ ٹولز کا استعمال کرتے ہوئے کنورٹ کرتے وقت اہم چیز ان جگہوں کی جانچ کرنا ہے جہاں متغیر کا موازنہ کیا گیا تھا (مثال کے طور پر، null کی جانچ کرنا)۔ اس کے علاوہ، آپ کو جنیٹ رنر کلاس تشریح میں ایلور پلگ ان شامل کرنے کی ضرورت ہے۔
آٹو ٹیسٹس ترتیب دینے کی مثال:
<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 سے زیادہ تھریڈ چلانے کی صلاحیت۔
Cons:
- آپ کو یہ یقینی بنانا ہوگا کہ کوڈ ملٹی تھریڈ پر عمل درآمد کو سپورٹ کرتا ہے۔
- داخلے کی حد بڑھ جاتی ہے۔
GitLab صفحات پر رغبت کی رپورٹس
ملٹی تھریڈڈ ایگزیکیوشن متعارف کرانے کے بعد، ہم نے رپورٹس کا تجزیہ کرنے میں زیادہ وقت صرف کرنا شروع کیا۔ اس وقت، ہمیں ہر رپورٹ کو بطور نمونہ GitLab پر اپ لوڈ کرنا پڑتا تھا، پھر اسے ڈاؤن لوڈ کرکے پیک کھولنا پڑتا تھا۔ یہ بہت آسان نہیں ہے اور اس میں کافی وقت لگتا ہے۔ اور اگر کوئی اور اپنے لیے رپورٹ دیکھنا چاہتا ہے، تو اسے وہی آپریشن کرنے کی ضرورت ہوگی۔ ہم تیزی سے تاثرات وصول کرنا چاہتے تھے، اور ہمیں ایک حل مل گیا - GitLab صفحات۔ یہ ایک بلٹ ان فیچر ہے جو 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
نتیجہ ہے کہ
لہذا، اگر آپ اس بارے میں سوچ رہے تھے کہ آیا آپ کو کھیرے کے آٹوٹیسٹ فریم ورک میں تھریڈ سیف کوڈ کی ضرورت ہے، تو اب جواب واضح ہے - Cucumber 4 کے ساتھ اسے لاگو کرنا آسان ہے، اس طرح بیک وقت لانچ ہونے والے تھریڈز کی تعداد میں نمایاں اضافہ ہوتا ہے۔ ٹیسٹ چلانے کے اس طریقے کے ساتھ، سوال اب Selenoid اور ٹیسٹ بینچ والی مشین کی کارکردگی کے بارے میں بنتا ہے۔
پریکٹس سے ثابت ہوا ہے کہ تھریڈز پر آٹو ٹیسٹ چلانے سے آپ بہترین کارکردگی کے ساتھ وسائل کی کھپت کو کم سے کم کر سکتے ہیں۔ جیسا کہ گراف سے دیکھا جا سکتا ہے، دھاگوں کو دوگنا کرنے سے کارکردگی کے ٹیسٹوں میں یکساں سرعت نہیں آتی۔ تاہم، ہم ایپلیکیشن کی تعمیر میں 2 سے زیادہ خودکار ٹیسٹ شامل کرنے میں کامیاب رہے، جو کہ 200 ری رن کے ساتھ بھی تقریباً 5 منٹ میں چلتے ہیں۔ یہ آپ کو ان سے فوری رائے حاصل کرنے کی اجازت دیتا ہے، اور اگر ضروری ہو تو تبدیلیاں کریں اور طریقہ کار کو دوبارہ دہرائیں۔
ماخذ: www.habr.com