بخش ما خطوط لوله کاملاً خودکار را برای راه اندازی نسخه های جدید برنامه ها در محیط تولید ایجاد می کند. البته این نیاز به تست های عملکردی خودکار دارد. در زیر برش داستانی در مورد این است که چگونه، با شروع آزمایش تک رشته ای روی یک ماشین محلی، ما به سمت تست های خودکار چند رشته ای که روی Selenoid اجرا می شوند در خط لوله ساخت با گزارش Allure در صفحات GitLab و در نهایت به یک ابزار اتوماسیون جالب رسیدیم. افراد آینده می توانند از تیم ها استفاده کنند.
از کجا شروع کردیم؟
برای پیاده‌سازی تست‌های خودکار و ادغام آنها در خط لوله، به یک چارچوب اتوماسیون نیاز داشتیم که بتوان آن را به طور انعطاف‌پذیر تغییر داد تا مطابق با نیازهای ما باشد. در حالت ایده‌آل، من می‌خواستم یک استاندارد واحد برای موتور تست خودکار دریافت کنم که برای تعبیه تست‌های خودکار در خط لوله سازگار باشد. برای پیاده سازی تکنولوژی های زیر را انتخاب کردیم:
- جاوا ،
- Maven ،
- سلنیوم،
- خیار + JUNIT 4،
- جذابیت،
- GitLab
چرا این مجموعه خاص؟ جاوا یکی از محبوب ترین زبان ها برای تست های خودکار است و همه اعضای تیم به آن صحبت می کنند. سلنیوم راه حل واضحی است. خیار، در میان چیزهای دیگر، قرار بود اعتماد به نتایج آزمایش‌های خودکار را از سوی بخش‌های درگیر در آزمایش دستی افزایش دهد.
تست های تک رشته ای
برای اینکه چرخ را دوباره اختراع نکنیم، پیشرفت‌هایی را از مخازن مختلف در 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
از آنجایی که هنگام پیاده‌سازی چارچوب پایه به کدهای ایمن رشته توجه نکردیم، واضح‌ترین راه برای اجرای موازی این بود. برای Maven پیکربندی این افزونه آسان است، اما برای عملکرد موازی صحیح، تست های خودکار باید در مرورگرهای جداگانه اجرا شوند. کاری نیست، مجبور شدم از سلنوئید استفاده کنم.
سرور سلنوئید روی دستگاهی با 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>
نمونه ای از گزارش Allure (بی ثبات ترین تست، 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 تبدیل شدند.
نکته اصلی هنگام تبدیل با استفاده از ابزار Refactoring Idea این است که مکان هایی را که متغیر مقایسه شده است بررسی کنید (مثلاً بررسی null). علاوه بر این، باید افزونه 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>
نمونه ای از گزارش Allure (بی ثبات ترین تست، 5 تکرار)
بار دونده در طول آزمایش (8 هسته، 8 گیگابایت رم، 24 رشته)
مزایا:
- مصرف کم منابع؛
- پشتیبانی بومی از Cucumber - بدون نیاز به ابزار اضافی.
- توانایی اجرای بیش از 6 رشته در هر هسته پردازنده.
منفی:
- شما باید مطمئن شوید که کد از اجرای چند رشته ای پشتیبانی می کند.
- آستانه ورود افزایش می یابد.
گزارش های Allure در صفحات 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 در چارچوب خودکار تست Cucumber نیاز دارید، اکنون پاسخ واضح است - با Cucumber 4 پیاده‌سازی آن آسان است، در نتیجه تعداد موضوعات راه‌اندازی همزمان به طور قابل توجهی افزایش می‌یابد. با این روش اجرای تست ها، سوال در مورد عملکرد دستگاه با سلنوئید و میز تست است.
تمرین نشان داده است که اجرای تست‌های خودکار روی رشته‌ها به شما این امکان را می‌دهد که مصرف منابع را با بهترین عملکرد به حداقل ممکن کاهش دهید. همانطور که از نمودارها مشاهده می شود، دو برابر شدن نخ ها منجر به شتاب مشابهی در تست های عملکرد نمی شود. با این حال، ما توانستیم بیش از 2 تست خودکار را به ساخت اپلیکیشن اضافه کنیم که حتی با 200 تکرار در حدود 5 دقیقه اجرا می شود. این به شما این امکان را می دهد که بازخورد سریعی از آنها دریافت کنید و در صورت لزوم تغییراتی ایجاد کنید و دوباره این روش را تکرار کنید.
منبع: www.habr.com