اختبار الحمل كخدمة CI للمطورين



من المشاكل التي كثيرا ما يواجهها موردو البرامج متعددة المنتجات هي ازدواجية كفاءات المهندسين - المطورين والمختبرين ومديري البنية التحتية - في كل فريق تقريبًا. هذا ينطبق أيضًا على المهندسين باهظة الثمن - الخبراء في مجال اختبار الحمل.

بدلاً من الانخراط في مسؤولياتهم المباشرة واستخدام تجربتهم الفريدة لبناء عملية اختبار الحمل واختيار المنهجية والقياسات المثلى وكتابة الاختبارات الذاتية وفقًا لملفات تعريف التحميل ، غالبًا ما يضطر المهندسون إلى نشر بنية تحتية للاختبار من البداية وتكوين أدوات التحميل وتضمينها في أنظمة CI ، تكوين المراقبة ونشر التقارير.

يمكنك العثور على حلول لبعض المشاكل التنظيمية في الاختبار التي نستخدمها في تقنيات إيجابية في مقال آخر . وسأتحدث في هذا عن إمكانية دمج اختبارات الحمل في خط أنابيب CI شائع باستخدام مفهوم "اختبار الحمل كخدمة". سوف تتعلم كيف وأي صور إرساء لمصادر التحميل يمكن استخدامها في خط أنابيب CI ؛ كيفية توصيل مصادر الحمل بمشروع CI الخاص بك باستخدام قالب تجميع ؛ كيف يبدو الأنبوب التجريبي لتشغيل اختبارات الحمل ونشر النتائج. قد تكون هذه المقالة مفيدة لمهندسي اختبار البرمجيات ومهندسي الأتمتة في CI الذين فكروا في بنية نظام التحميل الخاص بهم.

جوهر المفهوم


يشير مفهوم اختبار الحمل كخدمة إلى القدرة على دمج أدوات التحميل Apache JMeter و Yandex.Tank والأطر المخصصة في نظام تكامل مستمر تعسفي. سيكون العرض التوضيحي لـ GitLab CI ، ولكن المبادئ مذكورة في جميع أنظمة CI.

اختبار الحمل كخدمة هو خدمة مركزية لإجراء اختبار الحمل. يتم تشغيل اختبارات التحميل في مجموعات وكلاء مخصصة ، ويتم نشر النتائج تلقائيًا في صفحات GitLab و 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) ، تحدد ملفات تعريف الحمولة المقاييس الحرجة لاختبار معين وخيارات لتغيير معلمات الحمل أثناء الاختبار. يمكنك مشاهدة أمثلة لملفات التعريف في الشكل. الاختبار عبارة عن برنامج نصي يحتوي على مجموعة معلمات محددة مسبقًا. خطة الاختبار - مجموعة الاختبار وتحميل الملف الشخصي. Testrun (testrun) - تكرار واحد لتشغيل اختبار واحد مع سيناريو تحميل تم تنفيذه بالكامل وتقرير تم استلامه. طلب شبكة (طلب) - طلب HTTP مُرسل من الوكيل إلى الهدف. استجابة شبكة (استجابة) - استجابة HTTP مرسلة من الهدف إلى الوكيل.












حالة استجابة HTTP هي رمز استجابة قياسي من خادم التطبيق.
المعاملة (المعاملة) - دورة كاملة من "الطلب - الاستجابة". يتم احتساب المعاملة من بداية إرسال طلب (طلب) إلى إكمال تلقي رد (رد).

حالة المعاملة (حالة المعاملات) - هل كان من الممكن إكمال الدورة "طلب - استجابة" بنجاح. إذا كان هناك أي خطأ في هذه الحلقة ، فإن العملية بأكملها تعتبر غير ناجحة.

زمن الاستجابة (الكمون) - الوقت من نهاية إرسال الطلب (الطلب) إلى بداية تلقي الرد (الرد).

مقاييس التحميل (المقاييس) - خصائص الخدمة المحملة ووكيل التحميل المحدد أثناء عملية اختبار الحمل.

المقاييس الأساسية لقياس معلمات الحمل


يتم عرض بعض المقاييس الأكثر شيوعًا والموصى بها في منهجية ISTQB (ص 36 ، 52) في الجدول أدناه. تظهر مقاييس مماثلة للوكيل والهدف على نفس السطر.

مقاييس عامل التحميلتم اختبار مقاييس النظام المستهدف أو التطبيق تحت الحمل
عدد   vCPU و RAM الذاكرة ،
القرص - خصائص "الحديد" وكيل الحمل
وحدة المعالجة المركزية ، استخدام الذاكرة، القرص - ديناميات تحميل المعالج والذاكرة والقرص
أثناء الاختبار. يُقاس عادةً كنسبة مئوية من
القيم القصوى المتاحة.
Network throughput (on load agent) —
,
.
(bps)
Network throughput(on target) —
. (bps)
Virtual users— ,

Virtual users status, Passed/Failed/Total —

, .

,
, .
,
Requests per second (minute)— ( ).

: .
Responses per second (minute)
— ( ).

:

HTTP responses status
, .
, 200 OK ,
404 —
Latency ( ) —
(request) (response).
(ms)
Transaction response time— ,
« — ».
(request)
(response).

( )
: ,
, , , 90- .

.
,
,
Transactions per second (minute)
(),

.
Transactions status , Passed / Failed / Total —
, .





المخطط الأساسي لاختبار الحمل بسيط للغاية ويتكون من ثلاث مراحل رئيسية ، سبق أن أشرت إليها: التحضير - الاختبار - التقرير ، أي إعداد أهداف الاختبار وتحديد المعلمات لمصادر التحميل ، ثم إجراء اختبارات الحمل ، وأخيرًا ، إنشاء ونشر تقرير حول الاختبار. ملاحظات للمخطط:





  • اختبار QA - خبير اختبار الإجهاد ،
  • الهدف هو التطبيق الهدف الذي تحتاج إلى معرفة سلوكه تحت الحمل.

مصنف الكيانات والمراحل والخطوات في الرسم التخطيطي


المراحل والخطواتماذا يحدثماذا يوجد عند المدخلما هو الناتج
التحضير: مرحلة إعداد الاختبار
معلمات التحميلإعداد وتهيئة معلمات تحميل
المستخدم واختيار المقاييس وإعداد خطة اختبار (ملف تعريف التحميل)





-
VM




Env




:
, ,

LoadAgents,
.
-
-
(, JM )



Test: . , GitLab CI
Load
-



-



RunAgents




-
Logs«»
:
,

,


Metrics«»
Report:
Generator

«»


,





«»
,

,
Publish


«»
,



,

CI-


دعنا ننتقل إلى الجزء العملي. أريد أن أوضح كيف قمنا بتطبيق مفهوم اختبار الحمل كخدمة في بعض المشاريع في إيجابية التقنيات .

أولاً ، بمساعدة مهندسي DevOps ، أنشأنا مجموعة وكلاء مخصصة في GitLab CI لتشغيل اختبارات الحمل. لكي لا نربكهم في قوالب مع الآخرين ، مثل تجمعات التجميع ، أضفنا علامات إلى هؤلاء الوكلاء ، العلامات : تحميل. يمكنك استخدام أي علامات واضحة أخرى. يتم تعيينهم أثناء تسجيل GitLab CI Runners.

كيف تعرف الطاقة المطلوبة بالأجهزة؟ يمكن حساب خصائص وكلاء التحميل - كمية كافية من vCPU وذاكرة الوصول العشوائي والقرص - على أساس أن Docker و Python (لـ Yandex.Tank) وعامل GitLab CI و Java (لـ Apache JMeter) يجب أن يعملوا على العامل. بالنسبة لـ Java ، توصي JMeter أيضًا باستخدام 512 ميجابايت على الأقل من ذاكرة الوصول العشوائي ، وكحد أقصى 80٪ من الذاكرة المتاحة .

وبالتالي ، بناءً على خبرتنا ، نوصي باستخدام ما لا يقل عن 4 vCPU و 4 GB RAM و 60 GB SSD لوكلاء التحميل. يتم تحديد النطاق الترددي لبطاقة الشبكة بناءً على متطلبات ملف تعريف التحميل.

نحن نستخدم بشكل رئيسي مصدري تحميل - صور عامل إرساء Apache JMeter و Yandex.Tank.

ياندكس تانك- هذه هي أداة المصدر المفتوح لـ Yandex لاختبار الإجهاد. وتستند بنيتها المعيارية إلى مولد طلب HTTP غير المتزامن عالي الأداء القائم على النتائج Phantom. يحتوي الخزان على مراقبة مدمجة لموارد الخادم الذي تم اختباره باستخدام بروتوكول SSH ، يمكنه إيقاف الاختبار تلقائيًا وفقًا للظروف المحددة ، ويمكنه إخراج النتائج إلى كل من وحدة التحكم وفي شكل رسوم بيانية ، يمكنك توصيل الوحدات الخاصة بك بها لتوسيع الوظائف. بالمناسبة ، استخدمنا تانك عندما لم يكن سائدًا بعد. في مقالة " Yandex.Tank وأتمتة اختبار التحميل " ، يمكنك قراءة قصة كيف استخدمناها في عام 2013 لإجراء اختبار تحميل جدار الحماية التطبيقي PT Appllication - أحد منتجات شركتنا.

أباتشي جيميترهي أداة مفتوحة المصدر لإجراء اختبار ضغط أباتشي. يمكن استخدامه بشكل جيد على حد سواء لاختبار تطبيقات الويب الثابتة والديناميكية. يدعم JMeter عددًا كبيرًا من البروتوكولات وطرق التفاعل مع التطبيقات: HTTP و HTTPS (Java و NodeJS و PHP و ASP.NET وما إلى ذلك) و SOAP / REST Webservices و FTP و TCP و LDAP و SMTP (S) و POP3 (S) ) وقواعد بيانات IMAP (S) من خلال JDBC ، يمكنها تنفيذ أوامر shell والعمل مع كائنات Java. يمتلك JMeter IDE لإنشاء خطط الاختبار وتصحيحها وتنفيذها. هناك أيضًا CLI للعمل في سطر الأوامر في أي نظام تشغيل Java متوافق (Linux و Windows و Mac OS X). يمكن للأداة إنشاء تقرير اختبار HTML ديناميكيًا.

لسهولة الاستخدام داخل شركتنا ، من أجل قدرة المختبرين على تغيير البيئة وإضافتها ، قمنا بعمل صور لرسو السفن لمصادر التحميل على GitLab CI مع نشرها في سجل عامل الميناء الداخلي في Artifactory . وبهذه الطريقة ، يصبح توصيلها في خطوط الأنابيب أسرع وأسهل لإجراء اختبارات الحمل. كيفية جعل docker push في التسجيل عبر GitLab CI - راجع التعليمات .

ملف Docker الأساسي لـ Yandex.Tank أخذنا هذا:

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

وبالنسبة إلى Apache JMeter هذا:

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

يمكنك قراءة كيفية عمل نظام التكامل المستمر في مقالة " أتمتة عمليات التطوير: كيف قمنا بتنفيذ أفكار DevOps في التقنيات الإيجابية ".

قالب وخط الأنابيب


يتوفر نموذج مثال لإجراء اختبارات الحمل في مشروع التحميل التجريبي . يمكنك قراءة التعليمات الخاصة باستخدام القالب في ملف المستند التمهيدي . في القالب نفسه ( ملف .gitlab-ci.yml ) هناك ملاحظات حول ما هي المسؤولة عن هذه الخطوة أو تلك.

النموذج بسيط للغاية ويوضح المراحل الثلاث لاختبار الحمل الموضحة أعلاه في الرسم البياني: إعداد التقارير واختبارها ونشرها. المسئول عن ذلك دليل المراحل : الإعداد والاختبار والتقرير .

  1. Prepare . , - docker registry: Test. .
  2. Test , . : Yandex.Tank, Apache JMeter, . job-. :

    : CI- . , bash-. , — QA-. . ./tests.
  3. Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .

    , :
    :

في مثال توضيحي ، يبدو خط الأنابيب الذي يحتوي على اختبارات تحميل ومصدري تحميل (يمكنك تعطيل غير ضروري) على النحو التالي : يمكن لـ Apache JMeter إنشاء تقرير HTML بحد ذاته ، لذا من الأفضل حفظه في صفحات GitLab باستخدام الأدوات العادية. هذا ما يبدو عليه تقرير Apache JMeter: في العرض التوضيحي لـ Yandex.Tank ، سترى فقط تقريرًا نصيًا مزيفًا في قسم صفحات GitLab. أثناء الاختبار ، يمكن للخزان حفظ النتائج في قاعدة بيانات InfluxDB ، ومن هناك يمكن عرضها ، على سبيل المثال ، في Grafana (يتم إجراء التكوين في الملف ./tests/example-yandextank-test.yml ). هذا ما يبدو عليه تقرير تانك في جرافانا:











ملخص


تحدثت في المقالة عن مفهوم "اختبار الحمل كخدمة" (اختبار الحمل كخدمة). تتمثل الفكرة الرئيسية في استخدام البنية التحتية لتجمعات مسبقة التكوين من وكلاء التحميل ، صور عامل إرساء لمصادر التحميل ، وأنظمة إعداد التقارير وخطوط الأنابيب التي تجمعهم في GitLab CI استنادًا إلى نموذج .gitlab-ci.yml بسيط (مثال بالإشارة ). كل هذا مدعوم من قبل فريق صغير من مهندسي الأتمتة ويتم نسخه بناءً على طلب فرق المنتج. آمل أن يساعدك هذا في إعداد وتنفيذ مخطط مماثل في شركتك. شكرآ لك على أهتمامك!

PS أريد أن أقول شكراً جزيلاً لزملائي سيرجي كوربانوف ونيكولاي يوسيف ، للمساعدة التقنية في تنفيذ مفهوم اختبار الحمل كخدمة في شركتنا.

المؤلف :تيمور جيلمولين - نائب. رئيس عمليات التكنولوجيا والتطوير (DevOps) ، التقنيات الإيجابية

All Articles