مع هذه المقالة ، نواصل سلسلة من المنشورات حول كيفية قيامنا تلقائيًا في أحد مشاريع LANIT الرئيسية بإجراء عملية الاختبار اليدوي التلقائي (المشار إليها فيما يلي باسم autotests) لنظام معلومات كبير (يشار إليه فيما يلي باسم Systems) وما جاء منه.

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

ستجد هنا الجزء 1. (لماذا احتجنا إلى الأتمتة. تنظيم عملية التطوير والإدارة. تنظيم الاستخدام)

مصدر

العمارة والتكنولوجيا المكدس

الهيكل العام للنظام وبيئته - تصميم عالي المستوى

أهم التقنيات والمكتبات المستخدمة في المشروع:

• JavaSE8 & maven & JUnit - تطوير مكدس؛
• السيلينيوم - مكتبة لأتمتة إجراءات متصفح الويب ؛
• Selenide - وظيفة إضافية لـ Selenium ، والتي تحتوي على واجهة برمجة تطبيقات أنيقة تبسط بشكل كبير التفاعل مع المتصفح وعناصر الصفحة ؛
• Selenoid & GGR - تنفيذ Selenium Grid وموازن التحميل لتشغيل الاختبارات على خادم CI + حاويات سابقة التهيئة مع المتصفحات ؛
• ياندكس ألور - للتقارير على خادم CI.

يتم عرض رسم تخطيطي عام لمكونات الاختبار الذاتي والبنية التحتية لملفات Selenoid في المخططات أدناه ، بما في ذلك التعليقات التوضيحية:

إطار الاختبار التلقائي
تطبيق لأتمتة الانحدار واجهة المستخدم.
سلمت في شفرة المصدر. يستخدم JUnit4

run.properties
ملف التكوين لتشغيل Autotests. يحدد الاسم الشرطي للحامل المستخدم ونوع التنفيذ - محلي أو من خلال حاويات خارجية ومتغيرات أخرى.

جاذبية البرنامج المساعد
ملف قابل للتنفيذ خاص يتم تثبيته على خادم Bamboo.
ينشئ تقرير HTML للاختبار يمكن الوصول إليه من خلال خادم Bamboo.

تقرير الاختبار
تقرير HTML اختبار المتاحة من خلال خادم الخيزران.
يتم تخزينه على خادم الخيزران في نتائج الخطة في علامة تبويب منفصلة.

خيزران
يوفر إطلاق اختبار التكامل في كل من الوضع التلقائي واليدوي.
يخزن تقارير الاختبار في شكل ألور.

GGR خادم
خادم الموازن من خوادم سيلينويد.
يوفر موازنة الطلبات من autotests (RemoteWebDriver) إلى مثيلات متعددة من خوادم السيلينيوم.

عامل ميناء
خادم عامل الميناء لتشغيل حاويات خادم سيلينويد والمتصفحات.

Selenoid خادم
خادم اختبار عن بعد
يوفر إطلاق الاختبارات في حاويات الإرساء المتخصصة باستخدام متصفح "مقطوع الرأس".
ينفذ الاختبارات في الوضع المتوازي وفقًا لعدد محدد من مؤشرات الترابط المتزامنة.

Selenoid-واجهة المستخدم
خادم واجهة المستخدم لخادم Selenoid.
يسمح بمراقبة تقدم الاختبار على الفور أثناء VNC.

Selenoid-webdriver
حاوية متخصصة مع متصفح مقطوعة الرأس لإجراء الاختبارات عن بعد.
المقدمة من مستودع السلينويد.

GitLab
يخزن الكود المصدري لتطبيق Autotests.

مخطط العمل

يوضح المخطط التالي المخطط العام لخدمة AutoTests على مستوى التصميم العالي المستوى.

التثبيت والنشر

تعتمد الاختبارات التلقائية على أربعة خوادم ، أحدها هو خادم التنفيذ ، بينما توفر الثلاثة الأخرى إطلاق متصفحات مقطوعة الرأس في حاويات. توفر القوة الحالية للاختبارات التلقائية 60 تدفقات متزامنة ويمكن توسيعها إذا لزم الأمر.

يظهر مخطط النشر الحالي في الرسم البياني التالي. بشكل عام ، إذا كنت لا تحتاج إلى أكثر من 20 متصفحًا متزامنًا (اختبار مؤشرات الترابط) ، فمن الممكن تمامًا وضع كل شيء على خادم واحد 12 Kernels + 24 RAM. لقد بدأنا بهذا التكوين ، ولكن مع زيادة متطلبات قوة الاختبارات الذاتية ، اكتشفنا تجريبياً أن التكوين الأكثر استقرارًا وفعالية من حيث التكلفة هو خادم 12 Kernel + 24 RAM "نموذجي".

في تجربتنا ، بالنسبة لأنظمة الاختبار المزودة بواجهة ويب على Angular ، يجب أن يكون التكوين المقبول للحاوية مع المستعرض هو kernel floor + GB من الذاكرة. تكوين أصغر يبطئ المتصفح ويمكن أن يؤدي إلى تعطل غير معروف.

هيكل رمز وتنظيم

قبل الانتقال إلى بنية التعليمات البرمجية وتنظيمها ، سأذكر مرة أخرى السياسات والقيود التي حددت في نهاية المطاف اتجاه تطور الهندسة المعمارية:

• وهناك عدد كبير من البرامج النصية اختبار نهاية إلى نهاية معقدة. كثافة عالية للتنمية ؛
• تقلبات عالية لسيناريوهات الاختبار (تباينها) ؛
• سرعة مستمرة عالية لإيصال السيناريو (التطوير والمراجعة) ؛
• المؤهلات الأولية لمطوري الاختبارات الذاتية ؛
• تطوير عالية المخطط للمطورين.

بناءً على ما تقدم ، فإن الدوافع المعمارية الرئيسية هي:

• ضمان كود منظم للغاية لسهولة القراءة وسهولة الإدارة ؛
• أقصى فصل وعزل بين تطبيقات تطبيق الاختبارات المحددة والفئات الشاملة للوظائف المشتركة ؛
• الحد الأقصى من التبعيات المطلوبة لسهولة التغيير ؛
• إعادة استخدام معقولة للشفرة على مستوى الطبقات الشاملة مع ازدواجية محتملة للشفرة على مستوى مجموعات الاختبار المستقلة (النظم الفرعية الوظيفية) لتقليل التبعيات ودمج التعارضات على مستوى التطوير ؛
• رفض الأطر المعقدة مثل spring ، sidesJ لتقليل وقت "دخول" المطورين المبتدئين إلى المشروع.

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

وترد أدناه بنية الكود العام ووصف الحلول الرئيسية المحددة.

هيكل الكود العام وأنماط التطوير

يعتمد الهيكل العام لتنظيم الكود على بنية "ذات طبقات" (انظر الشكل) ، والتي ترث عمومًا نمط الصفحة الموصى به من قبل مطوري السيلينيوم. لقد وسعنا هذا النمط بإضافة مستوى من عناصر الويب إلى القاعدة وإبراز مستوى سيناريو الاختبار:

• مستوى فئة الاختبار
• مستوى سيناريو الاختبار
• مستوى صفحة الويب
• مستوى عنصر الويب
• اختبار الإطار (كما هو موضح يعتم في الرسم التخطيطي).

كل مستوى في هذا المخطط لديه مجموعة محددة من المسؤوليات والوظائف. لم يُسمح بالتقاطع الوظيفي بين الطبقات أو التبعيات غير المشروعة بينهما وكان السبب الرئيسي وراء عودة الالتزام بالمراجعة كجزء من مراجعة الكود قبل طلب الدمج.

بالإضافة إلى ذلك ، تم إصلاح بنية "الطبقات" في تقسيم الكود إلى حزم (انظر الشكل أدناه).

مثل هذا المخطط جعل من الممكن تقسيم جميع النظم الفرعية (التي كان هناك أكثر بكثير منها في المخطط) بين المطورين ، ونتيجة لذلك ، جعل من الممكن تطوير بشكل مستقل مع عدد تختفي عمليا من تعارضات الدمج.

يوضح الرسم البياني أدناه الهيكل العام لتنفيذ فئة الاختبار ومخطط التوزيع لتنفيذ حزم المشروع.

اختبار مستوى الصف

يتضمن مستوى فئة الاختبار فئة واحدة لاختبار فردي معين (يتم وصف الاختبار في نظام إدارة الاختبار كتسلسل خطي لنصوص الاختبار). فئة الاختبار هي فئة Junit مع تعليق توضيحي @ للطريقة المقابلة. بشكل عام ، تطبق فئة الاختبار طريقة اختبار واحدة فقط.

يرث كل فئة اختبار من فئة أساسية تتمثل مهمتها في تهيئة كافة TestRules في RuleChain ، أي تهيئة بنية تحتية للاختبار مثل تهيئة برنامج تشغيل ويب ، وإعداد أدلة مؤقتة ، ومعالجات الاستخدام العام الأخرى.

فئة الاختبار هي المسؤولة عن تنظيم تنفيذ سيناريو الاختبار من خلال:

1. تهيئة بيانات أعمال الاختبار (مشهد الاختبار) ،
2. استدعاء متسلسل لنصوص اختبار فردية (إجراءات) وفقًا للسيناريو المطلوب مع نقل بيانات الاختبار التي تمت تهيئتها إليها من الخطوة 2.

علاوة على ذلك ، في الخطوة 2 يجب أن يكون هناك تسلسل خطي بدون أي فروع أو نقاط قرار. يظهر قالب تنفيذ الفصل أدناه.

اختبار حالة المستوى

مستوى حالة الاختبار مسؤول عن تنفيذ حالات اختبار محددة كما هو موصوف. سيناريو الاختبار في هذا السياق هو سلسلة من العمليات التي يقوم بها المستخدم على نظام ما من خلال التفاعل مع العناصر الموجودة في صفحات الويب الخاصة بالتطبيق.

الهدف الرئيسي لفئة حالة الاختبار:

• تنفيذ التسلسل المحدد للنص البرمجي للاختبار من خلال الوصول إلى أساليب الفئات الدنيا من الصفحة ، باستخدام
  
  o بيانات مشهد الاختبار المنقولة ،
  البيانات الواردة من صفحات الويب (من فئات الصفحة) ؛
• قم بإجراء اختبارات العمل المطلوبة لنجاح الاختبار في سياق نموذج العمل ومشهد الاختبار. بمعنى آخر ، لا تتحقق فئة حالة الاختبار من علامات العناصر وتوافرها وإمكانية الوصول إليها ، ولكنها تعمل على نموذج الأعمال الخاص بمشهد الاختبار ، وتجري بالفعل اختبارات العمل.

يتم تنظيم فئة حالة الاختبار باعتبارها "واجهة وظيفية":

• يحتوي على طريقة عامة واحدة فقط "تطبيق" (@ Step) ، وهي:
  
  o يوفر تنفيذ البرنامج النصي كاستدعاء لسلسلة من "الإجراءات" (الأساليب التي توفرها فئات الصفحة) ،
  o يقبل جميع كائنات الأعمال الضرورية كمدخلات ، بينما لا يخلق أي كائنات أعمال نفسه ولا يتفاعل مباشرة مع أي شيء آخر غير فئات الصفحة ؛
• يحتوي على طرق خاصة X (@ Step) ، تنفذ كل منها خطوة منفصلة محددة من البرنامج النصي للاختبار (كما هو موضح في TMS - Test Management System) ؛
• لا يتفاعل (لا يستدعي الأساليب) مع أنشطة أخرى ، وحتى أنشطة نظام فرعي مماثل ؛
• لا يقبل الإدخال ولا يعمل على بيانات تسجيل الدخول. بمعنى آخر ، لا يعرف شيئًا عن الأدوار التي تم إطلاقه منها.

تسمح لك هذه المنظمة الصفية بما يلي:

• تقديم تقرير التوثيق الذاتي. تتوافق كل طريقة مع نقطة محددة في مواصفات الاختبار ويتم تعليقها بواسطة الشرح @ Step ؛
• إعادة استخدام فئات البرامج النصية للاختبار في اختبارات مختلفة ، نظرًا لأن النص البرمجي للاختبار 1) لا يُنشئ مشهد اختبار و 2) لا يعتمد على تسجيل دخول المستخدم (يتم تنفيذ عملية إعادة تسجيل الدخول على مستوى فئة الاختبار) 3) ، لا يعتمد الاختبار على الفئات الأخرى -stsenariev.

مستوى صفحة الويب

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

فئة الصفحة مسؤولة بشكل مباشر عن إدخال بيانات العمل في عناصر واجهة محددة ، والعمل مع برنامج تشغيل الويب (بدء تشغيل JS ، على سبيل المثال) ، وبناءً على ذلك ، اختبار التنسيقات ، والتحقق من تخطيط وهيكل صفحة الويب عن عمليات التحقق الأساسية مثل: العنصر ليس موجود / غير متوفر والعنصر لا يحتوي على القيمة المطلوبة.

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

مستوى عنصر الويب

تتضمن طبقة عنصر الويب مكتبة من العناصر المحددة التي قد تكون على صفحة ويب. وهو يتضمن كلاً من الأوليات المحددة والتكتلات الأكثر تعقيدًا ، والتي تتكون من عدة عناصر نسميها عناصر واجهة المستخدم. يمكن أن تكون أمثلة الأدوات المصغّرة مثل "pajinators" ، والقوائم العالمية ، والأطر المختلفة والنوافذ المشروطة ، والعناصر المعقدة مثل YandexMap أو Youtube player. تنظم عناصر الويب التكوين باستخدام فئات صفحات محددة ولا تعرف أيضًا أي شيء عن العناصر الأخرى.

بشكل عام ، إذا كان للمشروع نوع من التعريف العالمي الفريد لجميع عناصر الواجهة بمعرفها ، فمن المنطقي تنظيم مستوى عناصر الويب كمكتبة عالمية مع طلب عناصر محددة بمعرفها من خلال فئات التكوين الخاصة بالمصنع أو \ xml في مكتبة الربيع. ولكن ليس في كل مشروع هذا ممكن.

إطار الاختبار

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

يتضمن الإطار الكتل الوظيفية التالية:

• القواعد - تهيئة مكونات البنية التحتية للاختبار ووضع اللمسات الأخيرة عليها كتهيئة WebDriver وتلقي اختبار فيديو (كما هو موضح بمزيد من التفاصيل أدناه) ؛
• WebDriverHandlers - وظائف المساعد للعمل مع برنامج تشغيل ويب مثل تنفيذ Java Script أو الوصول إلى سجلات المتصفح. نفذت كمجموعة من أساليب الحالة الثابتة الساكنة ؛
• WebElements - تحتوي مكتبة عناصر الويب النموذجية أو مجموعاتها على وظائف الوظائف المشتركة المطلوبة والسلوك المعتاد. في حالتنا ، تشتمل هذه الوظيفة على فحص محتمل لإكمال العمليات غير المتزامنة على جانب متصفح الويب. تم تطبيقه كملحقات لعناصر الويب من مكتبات Selenium و Selenide.

تهيئة بيئة الاختبار. قواعد

الفئة الأساسية لجميع فئات الاختبار هي BaseTest ، حيث يتم توريث جميع فئات الاختبار. تعرف فئة BaseTest "عداء" Junit للاختبارات و RuleChain المستخدمة ، كما هو موضح أدناه. يتم الوصول من فئات اختبار التطبيق إلى الوظائف التي توفرها فئات القواعد من خلال الطرق الثابتة لفئات القواعد باستخدام معرف مؤشر الترابط "مؤشر الترابط" كمفتاح.

سيتم عرض تفاصيل تنفيذ الفئات الأساسية لإطار الاختبار التلقائي في الجزء التالي من المقالة: انظر الجزء 2-1. تطبيق الطبقة الأساسية لجميع الاختبارات و JUnit ChainRule.

توثيق النتائج من خلال تقارير جاذبية.

للحصول على تقارير مفصلة عن الاختبارات التي أجريت ، يتم استخدام Allure Framework ، ومتكامل مع Bamboo من خلال Allure Plugin . يوفر هذا فرصة للمستهلكين المعينين للاختبار (فريق الاختبار الوظيفي) ليس فقط لتلقي البيانات حول حقيقة تعطل اختبار معين ، ولكن أيضًا لاستعادة الاختبار المكرر بسهولة ، وإذا لزم الأمر ، كرره في الوضع اليدوي.

لتوثيق تقرير الاختبار ، يتم استخدام الوظيفة التالية:

• التعليقات التوضيحية Allure و Junit لترميز التقرير بخطوات البرنامج النصي للاختبار ، بالإضافة إلى الوصف الثابت لبيانات التعريف للاختبار ؛
• قم بجذب المرفقات من أجل إرفاق التقرير بمعلومات إضافية مثل اختبار الفيديو ، لقطة الشاشة ، نتائج تشخيصات إضافية لأسباب التعطل ، سجلات متصفح الويب التي تم تنزيلها من / إلى مستعرض الملف.

يتم استخدام التعليقات التوضيحية Allure و Junit التالية لترميز التقرير.

• على مستوى فئة الاختبار:
  
  o @ Feature - اسم النظام الفرعي الوظيفي الذي ينتمي إليه الاختبار ؛
  o @ Story - اسم حالة اختبار محددة ؛
  o @ Owner - اسم المطور الذي أجري آخر التغييرات في الاختبار ؛
  o @ TmsLink - رابط إلى وصف الاختبار في "نظام إدارة الاختبار" المستخدم.
• عند مستوى طريقة الاختبار (@ Test) لفئة الاختبار:
  
  o @ DisplayName - الاسم الكامل للبرنامج النصي للاختبار. يختلف عن @ Story لأنه يتيح لك مشاركة البرامج النصية نفسها ، والتي تختلف فقط في تكوين مشهد الاختبار ؛
• على مستوى الطرق التي تتوافق مع الخطوات المحددة لسيناريو الاختبار:
  
  o @ Step - الاسم الحقيقي لخطوة الاختبار التي تعكس جوهر العمل لما يحدث.

تتيح لك تسمية خطوات الاختبار من خلال @ Step إنشاء تقرير مفصل يكرر تمامًا جميع الخطوات والعناصر الموضحة في سيناريو الاختبار. يتيح ذلك لمستخدمي الاختبارات الذاتية تتبع مسار سيناريو الاختبار بسهولة ويساعد في تحديد نقطة الإصابة.

بشكل عام ، أثبت استخدام Allure Framework أنه مفيد وسهل للغاية ، باستثناء بعض الميزات المتعلقة بالكمية الضخمة من البيانات التي يتم إنشاؤها في حالتنا لعدد كبير من البرامج النصية للاختبارات المعقدة الطويلة (الموصوفة لاحقًا في قسم "الاستعادة").

ما الذي ربما كان يمكن القيام به بشكل مختلف على الفور؟ استخدام ربيع الإطار

على الرغم من حقيقة أنه عند تنفيذ الاختبارات الذاتية ، فقد رفضنا عن قصد استخدام Spring Core ، بشكل عام ، أعتبر استخدامها مبررًا وعاملًا. أظهر النموذج الأولي المطبق أن استخدام Spring Core يعمل للمهام التالية (على الرغم من أننا بالطبع لم نختبره بالكامل):

• تهيئة مشهد الاختبار ؛
• تهيئة صفحات الويب والعناصر.

الميزة الوحيدة هي الحاجة إلى استخدام سياق النطاق "الافتراضي" لمستوى النموذج الأولي.

تهيئة المشهد الاختبار. في الاختبارات التلقائية ، تتم تهيئة مشهد الاختبار بالطريقة الكلاسيكية لإنشاء مثيلات الفئة مباشرة في فئة الاختبار من خلال مصنع جديد بسيط أو كائن. من المنطقي هنا استخدام التهيئة إما من خلال فئات التكوين ، أو من خلال ملفات XML أو ملفات خارجية. تتمثل المزايا فيما يلي: 1) تبسيط رمز المراجعة ، نظرًا لأن التغييرات التي تطرأ على مشهد الاختبار لم تعد تنطبق على فئات المفاتيح ، 2) تتيح لك توصيل مشاهد اختبار مختلفة لمواقف مختلفة أو شروط أخرى. الآن لا يتم استخدام النقطة 2 معنا.

تهيئة صفحات الويب والعناصر. يعمل حقن فصول صفحات الويب وعناصر الويب بحكم التهيئة البطيئة لعناصر الويب السيلينيدي.

وبالتالي ، يصبح من الممكن إنشاء مكتبة لعناصر الويب وصفحاتها وفقًا لمواصفات عالمية معينة لواجهة المستخدم وتلقيها في روابط التعليمات البرمجية لهذه العناصر ليس بالمسار والمُعرّف المطلقين ، ولكن بواسطة معرف المشروع وفقًا للمواصفات.

يجب أن أقول على الفور أنني لم أختبر هذا الأمر بعناية فائقة ، وفي الواقع ، حصرت نفسي في تنفيذ اختبار "لصفحات" تسجيل الدخول وصفحة "معلومات" للمستخدم على هذا المبدأ.

بأثر رجعي. مفاجآت

وصفت هنا المفاجآت غير المتوقعة التي نشأت أثناء تطوير المشروع ، بالإضافة إلى بعض الاعتبارات حول ما كان يمكن القيام به بشكل أفضل إن لم يكن "لا".

العلامات الأمامية الصديقة للسيلينيوم (الزاوي)

واحدة من أخطر المفاجآت التي واجهناها هي تخطيط الصفحة "العائمة" ، مما أدى إلى حقيقة أنه بعد تحديث التطبيقات Angular ، سقطت الاختبارات لأن السيلينيوم لم يتمكن من العثور على العناصر بسبب معرفهم (معرف ، فئة أو نانوغرام نموذج) أو مسارات (ل XPath). وأدى ذلك إلى عدم استقرار الاختبارات وغموض أسباب السقوط.

لسوء الحظ ، تبين أن هذه المشكلة غير قابلة للحل بشكل عام. لقد تجاوزناها بالتدابير التنظيمية: 1) في بداية اختبار مرشح جديد للنشر ، يركز جميع مطوري الاختبارات الذاتية على الإزالة السريعة والتنقيح من حيث تحرير قيم محددات عناصر الويب ؛ 2) في النهاية ، توصلنا إلى استخدام XPath النسبي ، والذي ، للأسف ، لا يحسن الأداء على الإطلاق.

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

اسم ملف مفقود لملف "التنزيل"

"لتحميل" الملفات من النظام قيد الاختبار ، نستخدم الحلول التالية:

• بالنسبة إلى وضع التشغيل "المحلي" (التشغيل مباشرة على الكمبيوتر الشخصي العامل) - عند تهيئة المستعرض "المحلي" ، يتم تمرير اسم المجلد المحلي المؤقت إليه كمعلمة. بعد ذلك ، يتم قراءة الملف مباشرة من المجلد المحلي لتحليله لاحقًا ؛
• بالنسبة إلى الوضع "البعيد" (عبر Bamboo) ، تم "نقل" الملف من الحاوية مع المستعرض من خلال ميزة خادم الملف اللولبي: selenoid-host.example.com:4444/download/{SESSION_ID►/{FILE_NAME}

يتم وصف التفاصيل في الوثائق .

بالنسبة لكلا الوضعين ، للوصول إلى الملف ، كان من الضروري معرفة اسم الملف. كانت هذه مفاجأة ، لأننا لم نتمكن من معرفة اسم الملف الذي سيتم تنزيله على القرص في الحاوية. يمكن تنظيم كيفية تنظيم تنزيل الملف من الحاوية باستخدام المتصفح إلى الاختبارات التلقائية في الجزء التالي من المقالة.

اختبار انسداد قاعدة البيانات

انسداد قواعد بيانات الاختبار التي واجهناها بسرعة كبيرة. بادئ ذي بدء ، كان هذا بسبب حقيقة أنه من أجل "نظافة" اجتياز سيناريوهات الاختبار ، تم إنشاء بيئة الاختبار بشكل حيوي على الموقف نفسه. على سبيل المثال ، للتحقق من وظيفة إضافة كائن مستخدم A إلى حسابه الشخصي ، نحتاج بالتسلسل لإنشاء مستخدم جديد ، عقد مزيف ، كائن A ، ووضعه في عنوان محدد ، وفقط بعد إتمام جميع البرامج النصية للاختبار الأولي (التي تم فيها إنشاء مشهد الاختبار) اختبار البرنامج النصي لربط الكائن A بالمستخدم.

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

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

مدة اختبار عالية

لقد واجهنا هذه المشكلة بشكل غير متوقع أثناء نمو عدد الاختبارات المنفذة في وقت واحد. أعتقد أننا فقط لم نفكر في ذلك. الوقت المستغرق لإكمال مجموعة كاملة من الاختبارات (حوالي 1000 اختبار كامل) بدأ يقترب من علامة حرجة تبلغ 6 ساعات.

لزيادة عدد الاختبارات الجارية في وقت واحد ، تحولنا إلى Selenoid-ggr . هذا سمح لنا برفع عدد مؤشرات الترابط junit من 20 (خادم Selenoid واحد) إلى 60 (ثلاثة خوادم) ، وبعد ذلك واجهنا أداء طاولة الاختبار. "فجأة" اتضح أن مقعد الاختبار يعمل بثبات مع ما لا يزيد عن 60 جلسة متزامنة.

بالطبع ، يمكن زيادة الإنتاجية من خلال الموارد ، ولكن المشكلة هي أن كل هذه الموارد مطلوبة بشكل حصري لمدة 3-4 ساعات عند إجراء اختبار ليلي كامل أو اختبار دوري مسبق للجودة. بقية الوقت الموارد خاملا. هنا ، بالطبع ، تأتي AWS فورًا بتأجير خادم كل ساعة ، خاصةً أن حل Selenoid يتوافق تمامًا مع هذا النهج ، ولكن إذا كان موقفك غير موجود في نفس منطقة AWS مع Selenoid ، فيمكنك الدخول إلى الداخل والخارج.
في أي حال ، ينبغي النظر في مسألة التوسع والأداء لكل من خوادم الاختبار ومقعد الاختبار نفسه عند بناء أنظمة الاختبار الذاتي مع عدد كبير من اختبارات E2E من بداية المشروع. لهذا ، يجدر الاعتماد على متطلبات الحد الأقصى لوقت العبور من الانحدار الكامل و QQA.

بدء "العاصفة" مع التنفيذ المتزامن لعدد كبير من الاختبارات

كانت حوادث تعطل العمل الجماعي التي لا يمكن تفسيرها هي المفاجأة التالية التي واجهناها بعد زيادة عدد دورات الاختبار المتزامنة إلى 60 مسارًا في 60 متصفحًا.

في تقرير "الجدول الزمني" ، بدا وكأنه "أشرطة حمراء" (في الصورة أدناه). اتضح أن ذلك كان بسبب القيود في أداء الخدمات الفردية داخل منصة الاختبار.


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

تحولت "الأعمدة" اللاحقة إلى أنها مرتبطة بحقيقة أن فئات الاختبار موجودة في مجلدات بواسطة النظام الفرعي وتشغيلها في وقت واحد تقريبًا ، وبالتالي تحميل نظام فرعي وظيفي محدد للحامل وتجاوز حد الأداء لتكوين الحامل.

لقد حللنا المشكلة الأولى عن طريق التفاف طريقة البرنامج النصي لتسجيل الدخول في الموازن ، والتي حدت من الحد الأقصى لعدد عمليات تسجيل الدخول إلى ثابت معين.

@Step(":    ")     public void apply(User user) {     try {         LoadCounter.get(); //   .              try {                 applyLogin(user); //          } catch (Throwable t) {             throw t; //                   } finally {             LoadCounter.release(); //            }         } catch (LoadCounterException e) { //                  throw new StandRuntimeException("Can not get loadcounter for Login action.", e);     }     } 

تم حل المشكلة الثانية عن طريق تشغيل خيار التشغيل العشوائي للاختبار ، والذي يحتوي عليه البرنامج المساعد junit maven.

    <plugin>               <groupId>org.apache.maven.plugins</groupId>                <artifactId>maven-surefire-plugin</artifactId>         <version>….</version>            <configuration>                <!-- Defines the order the tests will be run in. Supported values are "alphabetical",                     "reversealphabetical", "random","hourly", "failedfirst", "balanced" and "filesystem". -->                <runOrder>random</runOrder>                … 

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

بشكل عام ، اتضح أن نظام الاختبار الذاتي المدمج E2E web-UI يمكن استخدامه جيدًا لاختبار الحمل البديل وفحص أداء واستقرار النظام الذي تم اختباره ككل.

تحميل عالي على خادم الخيزران وتخزينه

إذا كان لديك العديد من الاختبارات مع عدد كبير من العمليات (على سبيل المثال ، فإن عدد العمليات المسجلة من خلال Step هو من 200 إلى 2000 مع عدد الاختبارات حوالي 1300) ، يصبح حجم تقرير ألور أكبر من اللازم. إذا أضفت هنا أيضًا العديد من المرفقات مثل لقطات الشاشة والملفات التي تم تحميلها / تحميلها ، فستذهب وحدة التخزين بالفعل إلى مئات ميغابايت. على سبيل المثال ، الآن من أجل الانحدار الليلي لـ 900 اختبار ، يبلغ مقدار البيانات التي يتم تحميلها إلى Bamboo Allure لوحده حوالي 600 ميغابايت.

من الواضح أن مهندسي DevOps ليسوا متحمسين لمثل هذه الكثافة من تناول مساحة القرص والتعبير عن عدم الرضا بنشاط ، خاصة فيما يتعلق بالحاجة إلى تخزين البيانات لمدة عام على الأقل.

نرى طريقة للخروج من هذا الموقف باستخدام خادم خارجي لتخزين التقارير ومعالجتها ، على سبيل المثال ، Allure Enterprise. هذا الخادم مدفوع بالفعل ، ولكنه يسمح لنا بحل هذه المشكلة. نعمل حاليًا على اختبار ودمج Allure Enterprise في مشروعنا.

أن تستمر

في المقالة التالية ، سيواصل زملائي القصة ويصفون التاريخ الرائع لاختبار خدمات الويب باستخدام Smartbear SoapUI Pro. تمكنت قوى مهندسي الأتمتة من أتمتة حوالي 500 نص برمجي للاختبار ؛ ولهذا الغرض ، اضطررت إلى تنفيذ إطار إضافي يعمل على توسيع وظائف وظائف SOAP UI القياسية بشكل كبير ، ولكن المزيد حول ذلك لاحقًا.

كُتِب هذا المقال بالتعاون مع مدير المشروع ومالك منتج kotalesssk .

الجزء 1. التنظيمية والإدارية. لماذا نحتاج الأتمتة. تنظيم عملية التطوير والإدارة. تنظيم الاستخدام
الجزء 2. التقنية. الهندسة المعمارية والمكدس الفني. تفاصيل التنفيذ والمفاجآت الفنية
الجزء 2-1. تطبيق الطبقة الأساسية لجميع الاختبارات و JUnit ChainRule
الجزء 2-2. تنفيذ عملية تحميل ملف من حاوية مع متصفح إلى إطار اختبار. ابحث عن اسم الملف الذي تم تنزيله بواسطة المتصفح