زموږ څانګه د تولید چاپیریال کې د غوښتنلیکونو نوي نسخو پیل کولو لپاره په بشپړ ډول اتومات پایپ لاینونه رامینځته کوي. البته، دا د اتوماتیک فعالیت ازموینې ته اړتیا لري. د کټ لاندې د دې په اړه یوه کیسه ده چې څنګه په محلي ماشین کې د واحد تار ازموینې سره پیل کول، موږ د ګیټ لیب پا pagesو کې د الور راپور سره د جوړونې پایپ لاین کې په Selenoid کې د څو-تریډ شوي آټوټیسټ چلولو نقطې ته ورسیدو او په نهایت کې د عالي اتومات کولو وسیله ترلاسه کړه. چې راتلونکي خلک کولی شي ټیمونه وکاروي.
چیرته مو پیل کړی؟
د اتوماتیک ازموینې پلي کولو او په پایپ لاین کې د دوی مدغم کولو لپاره ، موږ د اتوماتیک چوکاټ ته اړتیا درلوده چې زموږ اړتیاو سره سم په انعطاف سره بدل شي. په عین حال کې، ما غوښتل چې د آټوټیسټینګ انجن لپاره یو واحد معیار ترلاسه کړم، په پایپ لاین کې د آټوټیسټونو ځای پرځای کولو لپاره تطبیق شوی. د پلي کولو لپاره موږ لاندې ټیکنالوژي غوره کړه:
- جاوا ،
- ماوین
- سیلینیم
- ککبر + JUNIT 4،
- جذب،
- ګیت لیب.
ولې دا ځانګړی سیټ؟ جاوا د اتوماتیک ازموینو لپاره یو له خورا مشهور ژبو څخه دی، او د ټیم ټول غړي یې خبرې کوي. سیلینیم روښانه حل دی. ککبر، د نورو شیانو په منځ کې، باید په لاسي ازموینې کې د ښکیلو څانګو په برخه کې د اتوماتیک ازموینو پایلو باندې باور زیات کړي.
د واحد تار شوي ازموینې
د دې لپاره چې د څرخ بیا رغونه نه وي، موږ په GitHub کې د مختلفو زیرمو څخه پرمختګونه د چوکاټ اساس په توګه اخیستي او د ځان لپاره یې تطبیق کړي. موږ د اصلي کتابتون لپاره د آټوټیسټ چوکاټ اصلي سره ذخیره جوړه کړه او زموږ په کور کې د آټوټیسټ پلي کولو د سرو زرو مثال سره ذخیره. هر ټیم باید د سرو زرو عکس واخلي او په هغې کې ازموینې رامینځته کړي، دا د دوی پروژې سره تطبیق کړي. موږ دا د GitLab-CI بانک ته ځای په ځای کړی، په کوم کې چې موږ ترتیب کړی:
- د هرې پروژې لپاره د ټولو لیکل شوي آټوټیسټونو ورځني چلول؛
- د جوړولو پایپ لاین کې پیل کوي.
په لومړي سر کې لږې ازموینې وې، او دوی په یوه جریان کې ترسره شوي. په وینډوز رنر GitLab کې د واحد تار چلول موږ ته خورا مناسب و: ازموینو د ازموینې بینچ خورا سپک بار کړ او تقریبا هیڅ سرچینې یې نه کارولې.
د وخت په تیریدو سره ، د آټوټیسټونو شمیر ډیر او ډیر شو ، او موږ د دوی په موازي توګه د چلولو په اړه فکر کاوه ، کله چې بشپړ منډې شاوخوا درې ساعته وخت ونیسي. نورې ستونزې هم څرګندې شوې:
- موږ نشو کولی تصدیق کړو چې ازموینې باثباته وې؛
- ازموینې چې په سیمه ایز ماشین کې په پرله پسې ډول څو ځله چلول شوي کله ناکله په 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 وکاروم.
د Selenoid سرور په ماشین کې د 32 کور او 24 GB رام سره په لاره اچول شوی و. حد په 48 براوزرونو کې ټاکل شوی - په هر کور کې 1,5 تارونه او شاوخوا 400 MB رام. د پایلې په توګه، د ازموینې وخت له دریو ساعتونو څخه 40 دقیقو ته راټیټ شو. د منډو ګړندی کول د ثبات ستونزه حل کولو کې مرسته کړې: اوس موږ کولی شو په چټکۍ سره نوي آټوټیسټونه 20-30 ځله ترسره کړو تر هغه چې موږ ډاډه شو چې دوی په ډاډه توګه پرمخ ځي.
د حل لومړۍ نیمګړتیا د لږ شمیر موازي تارونو سره د رنر سرچینو لوړه ګټه اخیستنه وه: په 4 کور او 8 GB RAM کې ، ازموینې له 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 جی بی ریم ، 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 …
د یو اختیار په توګه، د پاور شیل سکریپټ (PS1) لپاره د ماون اختیارونه تنظیم کړئ:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"پرو:
- د بې ثباته ازموینې په تحلیل کې د وخت ضایع کولو ته اړتیا نشته کله چې غورځیږي؛
- د ازموینې بینچ ثبات ستونزې کم کیدی شي.
ضمیمه:
- تیري نیمګړتیاوې له لاسه ورکول کیدی شي؛
- د چلولو وخت زیاتیږي.
د کاکمبر 4 کتابتون سره موازي ازموینې
د ازموینو شمیر هره ورځ وده کوي. موږ بیا د منډو چټکولو په اړه فکر وکړ. سربیره پردې ، ما غوښتل د غوښتنلیک اسمبلۍ پایپ لاین کې د امکان تر حده ډیری ازموینې مدغم کړم. مهم فاکتور دا و چې د منډو نسل ډیر وخت واخیست کله چې د ماون پلگ ان په کارولو سره موازي چلول.
په هغه وخت کې، ککمبر 4 لا دمخه خپور شوی و، نو موږ پریکړه وکړه چې د دې نسخې لپاره دانه بیا ولیکئ. په خوشې یادښتونو کې موږ سره د تار په کچه موازي لانچ ژمنه شوې وه. په نظرياتي توګه دا بايد وي:
- د تارونو شمیر په زیاتولو سره د آټوټیسټونو چلول د پام وړ ګړندي کړئ؛
- د هر آټوټیسټ لپاره د منډو جوړولو لپاره د وخت ضایع کول.
د څو اړخیزو آټوټیسټونو لپاره د چوکاټ اصلاح کول دومره ستونزمن ندي. ککبر 4 هر انفرادي ازموینه د پیل څخه تر پای پورې په وقف شوي تار کې پرمخ وړي، نو ځینې عام جامد شیان په ساده ډول د ThreadLocal تغیراتو ته بدل شوي.
اصلي شی کله چې د Idea refactoring tools په کارولو سره تبادله کول هغه ځایونه چیک کول دي چیرې چې متغیر پرتله شوی و (د مثال په توګه ، د نول لپاره چک کول). سربیره پردې ، تاسو اړتیا لرئ د جونیټ رنر ټولګي تشریح کې د الور پلگ ان اضافه کړئ.
د اتوماتیک ازموینې ترتیب کولو بیلګه:
<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 په ټولو وروستیو نسخو کې د بکس څخه بهر شتون لري. تاسو ته اجازه درکوي په خپل سرور کې جامد سایټونه ځای په ځای کړئ او دوی ته د مستقیم لینک له لارې لاسرسی ومومئ.
د Allure راپورونو ټول سکرین شاټونه د GitLab پا pagesو کې اخیستل شوي. د ګیټ لیب پا pagesو ته د راپور ځای په ځای کولو لپاره سکریپټ - په وینډوز پاور شیل کې (د دې دمخه تاسو اړتیا لرئ اتومات ازموینې پرمخ وړئ):
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
څه په پای کې
نو، که تاسو د دې په اړه فکر کوئ چې ایا تاسو د کاکمبر آټوټیسټ چوکاټ کې د تاریډ خوندي کوډ ته اړتیا لرئ، اوس ځواب څرګند دی - د کاکمبر 4 سره دا پلي کول اسانه دي، په دې توګه د پام وړ د تارونو شمیر په ورته وخت کې پیل شوی. د ازموینو د چلولو دې میتود سره ، پوښتنه اوس د Selenoid او ازموینې بنچ سره د ماشین فعالیت په اړه کیږي.
تمرین ښودلې چې په تارونو کې د اتوماتیک ازموینې چلول تاسو ته اجازه درکوي د غوره فعالیت سره لږترلږه د سرچینو مصرف کم کړئ. لکه څنګه چې د ګرافونو څخه لیدل کیدی شي، د تارونو دوه چنده کول د فعالیت په ازموینو کې د ورته سرعت لامل نه کیږي. په هرصورت ، موږ وکولی شو د غوښتنلیک جوړونې کې له 2 څخه ډیر اتومات ازموینې اضافه کړو ، کوم چې حتی د 200 بیاځلو سره په شاوخوا 5 دقیقو کې پرمخ ځي. دا تاسو ته اجازه درکوي له دوی څخه ګړندي فیډبیک ترلاسه کړئ ، او که اړتیا وي ، بدلونونه رامینځته کړئ او پروسیجر بیا تکرار کړئ.
سرچینه: www.habr.com