تست بارگذاری به عنوان یک سرویس CI برای توسعه دهندگان

یکی از مشکلاتی که فروشندگان نرم‌افزار چند محصولی اغلب با آن مواجه هستند، تکرار صلاحیت‌های مهندسان - توسعه‌دهندگان، آزمایش‌کنندگان و مدیران زیرساخت - تقریباً در هر تیم است. این همچنین در مورد مهندسان گران قیمت - متخصصان در زمینه آزمایش بار صدق می کند.

مهندسان اغلب به جای انجام وظایف مستقیم خود و استفاده از تجربه منحصر به فرد خود برای ایجاد فرآیند تست بار، انتخاب روش، معیارهای بهینه و نوشتن تست های خودکار مطابق با نمایه های بار، باید زیرساخت آزمایش را از ابتدا مستقر کنند، ابزارهای بار را پیکربندی کنند و آنها را جاسازی کنند. خود را در سیستم های CI، راه اندازی نظارت و انتشار گزارش ها.

شما می توانید راه حل هایی برای برخی از مشکلات سازمانی در تست هایی که ما در Positive Technologies در استفاده می کنیم بیابید مقاله دیگری. و در این مورد، من در مورد امکان ادغام آزمایش های بار در یک خط لوله مشترک CI با استفاده از مفهوم "تست بار به عنوان یک سرویس" (تست بار به عنوان یک سرویس) صحبت خواهم کرد. شما یاد خواهید گرفت که چگونه و کدام تصاویر docker از منابع بار را می توان در خط لوله CI استفاده کرد. نحوه اتصال منابع بار به پروژه CI خود با استفاده از یک قالب ساخت. خط لوله آزمایشی برای اجرای آزمایش های بارگذاری و انتشار نتایج چگونه به نظر می رسد. این مقاله ممکن است برای مهندسان تست نرم افزار و مهندسان اتوماسیون در CI که به معماری سیستم بار خود فکر می کنند مفید باشد.

ماهیت مفهوم

مفهوم تست بار به عنوان یک سرویس به توانایی ادغام ابزارهای بارگذاری Apache JMeter، Yandex.Tank و چارچوب های خود در یک سیستم یکپارچه سازی مستمر دلخواه دلالت دارد. نسخه ی نمایشی برای GitLab CI خواهد بود، اما اصول در همه سیستم های CI مشترک است.

تست بار به عنوان یک سرویس یک سرویس متمرکز برای تست بار است. تست‌های بارگذاری در استخرهای عامل اختصاصی اجرا می‌شوند، نتایج به‌طور خودکار در GitLab Pages، Influx DB و Grafana یا در سیستم‌های گزارش تست (TestRail، ReportPortal و غیره) منتشر می‌شوند. اتوماسیون و مقیاس‌بندی به سادگی امکان‌پذیر است - با افزودن و پارامترسازی الگوی معمول gitlab-ci.yml در پروژه GitLab CI.

مزیت این رویکرد این است که کل زیرساخت CI، عوامل بار، تصاویر داکر منابع بار، خطوط لوله آزمایش و انتشار گزارش‌ها توسط یک بخش اتوماسیون متمرکز (مهندسین DevOps) نگهداری می‌شوند، در حالی که مهندسان تست بار می‌توانند تلاش خود را بر توسعه آزمایش متمرکز کنند. و تجزیه و تحلیل نتایج آنها، بدون پرداختن به مسائل زیرساختی.

برای سادگی توضیح، فرض می کنیم که برنامه یا سرور مورد نظر مورد آزمایش قبلاً مستقر و پیکربندی شده است (اسکریپت های خودکار در Python، SaltStack، Ansible و غیره می توانند برای این کار استفاده شوند). سپس کل مفهوم آزمایش بار به عنوان یک سرویس در سه مرحله قرار می گیرد: تهیه، آزمایش، انتشار گزارش. جزئیات بیشتر در نمودار (همه تصاویر قابل کلیک هستند):

مفاهیم و تعاریف اساسی در تست بار

هنگام انجام تست های بار، ما سعی می کنیم به آن پایبند باشیم استانداردها و روش شناسی ISTQB، از اصطلاحات مناسب و معیارهای توصیه شده استفاده کنید. من یک لیست کوتاه از مفاهیم و تعاریف اصلی در تست بار ارائه خواهم کرد.

عامل بار - یک ماشین مجازی که برنامه روی آن راه اندازی می شود - منبع بار (Apache JMeter، Yandex.Tank یا یک ماژول بار خودنویس).

هدف آزمون (هدف) - سرور یا برنامه نصب شده بر روی سرور که در معرض بارگذاری قرار می گیرد.

سناریوی تست (مورد آزمایش) - مجموعه ای از مراحل پارامتر شده: اقدامات کاربر و واکنش های مورد انتظار به این اقدامات، با درخواست ها و پاسخ های شبکه ثابت، بسته به پارامترهای مشخص شده.

نمایه یا طرح بارگذاری (نمایه) - در روش ISTQB (بخش 4.2.4، صفحه 43) پروفایل های بار معیارهایی را تعریف می کنند که برای یک آزمایش خاص و گزینه هایی برای تغییر پارامترهای بار در طول آزمایش حیاتی هستند. نمونه هایی از پروفیل ها را در شکل مشاهده می کنید.

تست - یک اسکریپت با مجموعه ای از پارامترهای از پیش تعیین شده.

طرح تست (طرح تست) - مجموعه ای از آزمایش ها و مشخصات بار.

تستران (تسترون) - یک تکرار اجرای یک تست با سناریوی بارگذاری کامل اجرا شده و گزارش دریافتی.

درخواست شبکه (درخواست) - یک درخواست HTTP که از یک عامل به یک هدف ارسال می شود.

پاسخ شبکه (پاسخ) - یک پاسخ HTTP که از هدف به عامل ارسال می شود.
کد پاسخ HTTP (وضعیت پاسخ های HTTP) - کد پاسخ استاندارد از سرور برنامه.
تراکنش یک چرخه کامل درخواست-پاسخ است. تراکنش از شروع ارسال درخواست (درخواست) تا تکمیل دریافت پاسخ (پاسخ) محاسبه می شود.

وضعیت معامله - آیا امکان تکمیل چرخه درخواست-پاسخ با موفقیت وجود داشت یا خیر. اگر در این چرخه خطایی وجود داشته باشد، کل تراکنش ناموفق در نظر گرفته می شود.

زمان پاسخگویی (تاخیر) - زمان از پایان ارسال درخواست (درخواست) تا شروع دریافت پاسخ (پاسخ).

معیارهای بارگذاری - ویژگی های سرویس بارگذاری شده و عامل بار تعیین شده در فرآیند آزمایش بار.

معیارهای اساسی برای اندازه گیری پارامترهای بار

برخی از متداول ترین موارد استفاده و توصیه شده در روش ISTQB (ص. 36، 52) معیارها در جدول زیر نشان داده شده است. معیارهای مشابه برای عامل و هدف در یک خط فهرست شده است.

معیارهای عامل بار
معیارهای سیستم یا برنامه مورد نظر در حال آزمایش تحت بار

شماره  vCPU و حافظه رم,
دیسک - ویژگی های "آهن" عامل بار
پردازنده, حافظه، استفاده از دیسک - پویایی CPU، حافظه و بارگذاری دیسک
در مرحله آزمایش معمولاً به صورت درصد اندازه گیری می شود
حداکثر مقادیر موجود

توان عملیاتی شبکه (در عامل بار) - توان عملیاتی
رابط شبکه روی سرور،
جایی که عامل بار نصب شده است.
معمولا در بایت در ثانیه (bps) اندازه گیری می شود
توان عملیاتی شبکه(در هدف) - پهنای باند رابط شبکه
در سرور مورد نظر معمولا در بایت در ثانیه (bps) اندازه گیری می شود

کاربران مجازی- تعداد کاربران مجازی
اجرای سناریوهای بار و
تقلید از اقدامات واقعی کاربر
وضعیت کاربران مجازی، گذرانده / ناموفق / کل — تعداد موفق و
وضعیت ناموفق کاربران مجازی
برای سناریوهای بار، و همچنین تعداد کل آنها.

به طور کلی انتظار می رود که همه کاربران بتوانند تکمیل کنند
تمام وظایف شما در نمایه بار مشخص شده است.
هر گونه خطا به این معنی است که یک کاربر واقعی قادر به انجام آن نخواهد بود
هنگام کار با سیستم مشکل خود را حل کنید

درخواست در ثانیه (دقیقه)- تعداد درخواست های شبکه در هر ثانیه (یا دقیقه).

یکی از ویژگی های مهم یک عامل بار این است که تعداد درخواست هایی که می تواند ایجاد کند.
در واقع این یک تقلید از دسترسی کاربران مجازی به اپلیکیشن است
پاسخ در ثانیه (دقیقه)
- تعداد پاسخ های شبکه در هر ثانیه (یا دقیقه).

یک ویژگی مهم سرویس هدف: چقدر است
تولید و ارسال پاسخ به پرس و جو با
عامل بارگیری

وضعیت پاسخ HTTP- تعداد کدهای مختلف پاسخ
از سرور برنامه دریافت شده توسط عامل بار.
به عنوان مثال، 200 OK به معنای تماس موفق است،
و 404 - که منبع پیدا نشد

تاخیر (زمان پاسخ) - زمان از پایان
ارسال یک درخواست (درخواست) قبل از شروع دریافت پاسخ (پاسخ).
معمولا در میلی ثانیه (ms) اندازه گیری می شود

زمان پاسخگویی تراکنش- زمان یک تراکنش کامل،
تکمیل چرخه درخواست-پاسخ
این زمان از شروع ارسال درخواست (درخواست) است.
تا پایان دریافت پاسخ (پاسخ).

زمان تراکنش را می توان بر حسب ثانیه (یا دقیقه) اندازه گیری کرد.
از چند جهت: حداقل را در نظر بگیرید،
حداکثر، متوسط ​​و مثلاً صدک 90.
حداقل و حداکثر قرائت شدید هستند
وضعیت عملکرد سیستم
صدک نود بیشترین استفاده را دارد،
همانطور که بیشتر کاربران را نشان می دهد،
به راحتی در آستانه عملکرد سیستم کار می کند

تراکنش در ثانیه (دقیقه) - تعداد کامل
تراکنش در ثانیه (دقیقه)،
یعنی درخواست چقدر توانسته بپذیرد و
درخواست ها را پردازش کنید و پاسخ ها را صادر کنید.
در واقع این توان عملیاتی سیستم است

وضعیت معامله ، گذشت / ناموفق / کل - تعداد
موفقیت آمیز، ناموفق و تعداد کل تراکنش ها.

برای کاربران واقعی ناموفق
معامله در واقع به معنای
ناتوانی در کار با سیستم تحت بار

نمودار شماتیک تست بار

مفهوم تست بار بسیار ساده است و شامل سه مرحله اصلی است که قبلاً به آنها اشاره کردم: تهیه-تست-گزارشیعنی تهیه اهداف تست و تنظیم پارامترها برای منابع بار و سپس اجرای تست های بار و در پایان تولید و انتشار گزارش تست.

یادداشت های شماتیک:

• QA.Tester متخصص در تست بار است،
• Target برنامه هدفی است که می خواهید رفتار آن را تحت بار بدانید.

طبقه بندی موجودیت ها، مراحل و مراحل در نمودار

مراحل و مراحل
چه اتفاقی می افتد
آنچه در ورودی است
خروجی چیست

آماده سازی: مرحله آماده سازی برای آزمایش

LoadParameters
تنظیم و مقداردهی اولیه
کاربر
پارامترهای بار،
انتخاب معیارها و
تهیه طرح آزمون
(بارگذاری نمایه)
گزینه های سفارشی برای
مقداردهی اولیه عامل بار
طرح تست
هدف از آزمایش

VM
استقرار ابر
ماشین مجازی با
ویژگی های مورد نیاز
تنظیمات VM برای عامل بار
اسکریپت های اتوماسیون برای
ساخت VM
VM پیکربندی شده است
ابر

انو
راه اندازی و آماده سازی سیستم عامل
محیط برای
کار عامل بارگذاری
تنظیمات محیطی برای
عامل بارگذاری
اسکریپت های اتوماسیون برای
تنظیمات محیط
محیط آماده شده:
سیستم عامل، خدمات و برنامه های کاربردی،
لازم برای کار
عامل بارگذاری

LoadAgents
نصب، پیکربندی و پارامترسازی
عامل بارگیری
یا دانلود یک تصویر داکر از
منبع بار از پیش تنظیم شده
بارگیری تصویر داکر منبع
(YAT، JM یا چارچوب خودنویس)
تنظیمات
عامل بارگذاری
راه اندازی و آماده است
به کار عامل بار

تست: مرحله اجرای آزمایش های بار. منابع، عوامل بار هستند که در استخرهای عامل اختصاصی برای GitLab CI مستقر شده اند

بار
راه اندازی Load Agent
با طرح آزمون منتخب
و پارامترهای بار
گزینه های کاربر
برای مقداردهی اولیه
عامل بارگذاری
طرح تست
هدف از آزمایش
لاگ های اجرایی
تست های بارگذاری
گزارش های سیستم
دینامیک تغییرات در معیارهای هدف و عامل بار

Agents را اجرا کنید
اجرای مامور
تعداد زیادی اسکریپت تست
با توجه به
بارگذاری نمایه
تعامل عامل بار
به منظور آزمایش
طرح تست
هدف از آزمایش

سیاههها
مجموعه ای از سیاهههای مربوط به "خام".
در طول تست بار:
سوابق فعالیت عامل بارگذاری،
وضعیت هدف آزمایشی
و VM که عامل را اجرا می کند

لاگ های اجرایی
تست های بارگذاری
گزارش های سیستم

متریک
جمع آوری معیارهای "خام" در طول آزمایش

دینامیک تغییرات در معیارهای هدف
و عامل بارگذاری

گزارش: مرحله تهیه گزارش آزمون

مولد
پردازش جمع آوری شد
سیستم بارگیری و
سیستم نظارت "خام"
متریک ها و لاگ ها
تشکیل گزارش در
فرم قابل خواندن توسط انسان
با عناصر امکان پذیر است
تحلیل گران
لاگ های اجرایی
تست های بارگذاری
گزارش های سیستم
دینامیک تغییرات در معیارها
عامل هدف و بارگذاری
سیاهههای مربوط به "خام" پردازش شده
در قالبی مناسب برای
آپلود در حافظه خارجی
گزارش بار استاتیک،
قابل خواندن برای انسان

منتشر کردن
انتشار گزارش
در مورد بار
تست در خارجی
خدمات
فرآوری شده "خام"
سیاهههای مربوط به فرمت مناسب
برای تخلیه به خارجی
مخازن
ذخیره شده در خارجی
گزارش های ذخیره سازی در
بار، مناسب
برای تجزیه و تحلیل انسانی

اتصال منابع بار در قالب CI

بیایید به بخش عملی آن برویم. من می خواهم نحوه انجام برخی پروژه ها را در شرکت نشان دهم فناوری های مثبت ما مفهوم تست بار را به عنوان یک سرویس پیاده سازی کرده ایم.

ابتدا، با کمک مهندسان DevOps خود، یک مجموعه اختصاصی از عوامل در GitLab CI برای اجرای آزمایش‌های بار ایجاد کردیم. برای اینکه آنها را در قالب ها با دیگران اشتباه نگیریم، مانند استخرهای مونتاژ، برچسب هایی را به این عوامل اضافه کردیم. برچسب ها: بار. می توانید از هر برچسب قابل فهم دیگری استفاده کنید. میپرسند در حین ثبت نام GitLab CI Runners.

چگونه از طریق سخت افزار قدرت مورد نیاز را دریابیم؟ ویژگی های عوامل بار - تعداد کافی vCPU، RAM و دیسک - را می توان بر اساس این واقعیت محاسبه کرد که داکر، پایتون (برای Yandex.Tank)، عامل GitLab CI، جاوا (برای Apache JMeter) باید روی عامل اجرا شوند. . برای جاوا تحت JMeter نیز توصیه می شود از حداقل 512 مگابایت رم استفاده کنید و به عنوان حد بالایی، 80 درصد حافظه موجود.

بنابراین، بر اساس تجربه ما، توصیه می کنیم از حداقل 4 vCPU، 4 گیگابایت رم، 60 گیگابایت SSD برای عوامل بار استفاده کنید. توان عملیاتی کارت شبکه بر اساس الزامات پروفایل بار تعیین می شود.

ما عمدتا از دو منبع بار استفاده می کنیم - تصاویر Apache JMeter و Yandex.Tank docker.

Yandex.Tank یک ابزار منبع باز از Yandex برای تست بار است. معماری ماژولار آن بر اساس تولید کننده درخواست HTTP مبتنی بر ضربه ناهمزمان با کارایی بالا فانتوم است. مخزن دارای نظارت داخلی بر منابع سرور تحت آزمایش از طریق پروتکل SSH است، می تواند به طور خودکار تست را در شرایط مشخص متوقف کند، می تواند نتایج را هم در کنسول و هم به صورت نمودار نمایش دهد، می توانید ماژول های خود را به هم متصل کنید. به آن برای گسترش عملکرد. به هر حال، ما از Tank زمانی استفاده کردیم که هنوز جریان اصلی آن نبود. در مقاله "Yandex.Tank و اتوماسیون تست بار» می توانید داستان نحوه انجام آزمایش بار با آن را در سال 2013 بخوانید فایروال برنامه PT یکی از محصولات شرکت ما است.

آپاچی جی متر یک ابزار تست بار منبع باز از آپاچی است. می توان از آن به همان اندازه برای آزمایش برنامه های وب استاتیک و پویا استفاده کرد. JMeter از تعداد زیادی پروتکل و راه‌های تعامل با برنامه‌ها پشتیبانی می‌کند: HTTP، HTTPS (Java، NodeJS، PHP، ASP.NET، و غیره)، سرویس‌های وب SOAP / REST، FTP، TCP، LDAP، SMTP(S)، POP3( S) ) و IMAP(S)، پایگاه های داده از طریق JDBC، می توانند دستورات پوسته را اجرا کنند و با اشیاء جاوا کار کنند. JMeter دارای یک IDE برای ایجاد، اشکال زدایی و اجرای برنامه های آزمایشی است. همچنین یک CLI برای عملیات خط فرمان در هر سیستم عامل سازگار با جاوا (Linux، Windows، Mac OS X) وجود دارد. این ابزار می تواند به صورت پویا یک گزارش تست HTML ایجاد کند.

برای سهولت استفاده در شرکت ما، برای توانایی خود تسترها برای تغییر و افزودن محیط، ساخت‌هایی از تصاویر docker از منابع بارگذاری در GitLab CI با انتشار در داخلی ساختیم. ثبت داکر در Artifactory. این باعث می شود که اتصال آنها در خطوط لوله برای آزمایش بار سریعتر و آسانتر شود. نحوه انجام فشار docker به رجیستری از طریق GitLab CI - ببینید دستورالعمل.

ما این فایل داکر اصلی را برای Yandex.Tank گرفتیم:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

و برای Apache JMeter این یکی:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

می توانید نحوه عملکرد سیستم یکپارچه سازی مداوم ما را در مقاله بخوانید "اتوماسیون فرآیندهای توسعه: چگونه ایده های DevOps را در Positive Technologies پیاده سازی کردیم'.

الگو و خط لوله

نمونه ای از قالب برای انجام تست های بار در پروژه موجود است بار آزمایشیاست. به فایل readme می توانید دستورالعمل استفاده از قالب را بخوانید. در خود قالب (فایل .gitlab-ci.yml) یادداشت هایی در مورد مسئولیت هر مرحله وجود دارد.

این الگو بسیار ساده است و سه مرحله آزمایش بار شرح داده شده در نمودار بالا را نشان می دهد: تهیه، آزمایش و انتشار گزارش. مسئول این امر است مراحل: تهیه، آزمایش و گزارش.

1. صحنه آماده باید برای پیش پیکربندی اهداف آزمایشی یا بررسی در دسترس بودن آنها استفاده شود. محیط برای منابع بارگذاری نیازی به پیکربندی ندارد، آنها به عنوان تصاویر داکر از پیش ساخته شده اند و در رجیستری داکر ارسال می شوند: فقط نسخه مورد نظر را در مرحله تست مشخص کنید. اما شما می توانید آنها را بازسازی کنید و تصاویر اصلاح شده خود را بسازید.
2. صحنه تست برای تعیین منبع بار، اجرای آزمایش‌ها و ذخیره مصنوعات آزمایشی استفاده می‌شود. می‌توانید هر منبع باری را انتخاب کنید: Yandex.Tank، Apache JMeter، خودتان یا همه با هم. برای غیرفعال کردن منابع غیرضروری، کافی است کار را نظر دهید یا آن را حذف کنید. نقاط ورودی برای منابع بار:
   • پارامترهای راه اندازی برای Yandex.Tank در قسمت مشخص شده است./tests/yandextank.sh,
   • پارامترهای راه اندازی Apache JMeter در فایل مشخص شده است ./tests/jmeter.sh.

   توجه: الگوی پیکربندی اسمبلی برای تنظیم تعامل با سیستم CI استفاده می شود و به معنای قرار دادن منطق تست در آن نیست. برای تست ها، نقطه ورود مشخص شده است، جایی که اسکریپت کنترل bash در آن قرار دارد. روش اجرای تست ها، تولید گزارش ها و خود اسکریپت های تست باید توسط مهندسان QA پیاده سازی شود. در نسخه آزمایشی، برای هر دو منبع بار، از درخواست صفحه اصلی Yandex به عنوان ساده ترین آزمایش استفاده می شود. اسکریپت ها و پارامترهای تست در دایرکتوری هستند ./تست ها.

3. در صحنه گزارش شما باید نحوه انتشار نتایج آزمایش به دست آمده در مرحله تست را در حافظه های خارجی، به عنوان مثال، در صفحات GitLab یا سیستم های گزارش ویژه توضیح دهید. صفحات GitLab مستلزم این است که دایرکتوری ./public خالی نباشد و حداقل حاوی یک فایل index.html پس از پایان تست ها باشد. می توانید در مورد تفاوت های ظریف سرویس GitLab Pages مطالعه کنید. по ссылке.

   نمونه هایی از نحوه صادرات داده ها:

   • از JMeter به صفحات GitLab,
   • از Yandex.Tank به InfluxDB و Grafana.

   دستورالعمل نصب پست:

   • استاتیک HTML در صفحات GitLab,
   • به InfluxDB و سپس به گرافانا.

در مثال آزمایشی، خط لوله با آزمایش های بار و دو منبع بار (می توانید منبع غیر ضروری را غیرفعال کنید) به این صورت است:

Apache JMeter می تواند خود یک گزارش HTML ایجاد کند، بنابراین ذخیره آن در صفحات GitLab با استفاده از ابزارهای استاندارد سودآورتر است. گزارش Apache JMeter به این صورت است:

در نمونه آزمایشی برای Yandex.Tank، فقط خواهید دید گزارش متنی جعلی در بخش GitLab Pages. در حین آزمایش، Tank می تواند نتایج را در پایگاه داده InfluxDB ذخیره کند و از آنجا می توان آنها را به عنوان مثال در Grafana نمایش داد (پیکربندی در فایل انجام می شود. ./tests/example-yandextank-test.yml). گزارش تانک در گرافانا اینگونه است:

خلاصه

در مقاله، من در مورد مفهوم "تست بار به عنوان یک سرویس" (بار تست به عنوان یک سرویس) صحبت کردم. ایده اصلی استفاده از زیرساخت مجموعه های از پیش پیکربندی شده عوامل بار، تصاویر داکر از منابع بار، سیستم های گزارش دهی و خط لوله ای است که آنها را در GitLab CI بر اساس یک الگوی ساده .gitlab-ci.yml ترکیب می کند (به عنوان مثال по ссылке). همه اینها توسط تیم کوچکی از مهندسان اتوماسیون پشتیبانی می شود و به درخواست تیم های محصول تکرار می شود. امیدوارم این به شما در تهیه و اجرای یک طرح مشابه در شرکتتان کمک کند. از توجه شما متشکرم

PS می خواهم از همکارانم سرگئی کوربانوف و نیکولای یوسف برای کمک فنی در اجرای مفهوم آزمایش بار به عنوان یک سرویس در شرکت ما تشکر کنم.

نویسنده: تیمور گیلمولین - قائم مقام رئیس فناوری ها و فرآیندهای توسعه (DevOps) در Positive Technologies

منبع: www.habr.com