في الرابع عشر من كانون الأول (ديسمبر) ، في اجتماع حاشد في سانت بطرسبرغ ، تحدثت أنا (أرتيم سوكوفيتس) ، مع زميلي ، ديمتري ماركيلوف ، عن البنية التحتية الحالية لاختبارات السيارات في سبيرتيك. رواية خطابنا في هذا المنصب.
ما هو السيلينيوم
السيلينيوم هو أداة أتمتة مستعرض الويب. اليوم ، هذه الأداة هي المعيار لأتمتة WEB.
هناك العديد من العملاء لمختلف لغات البرمجة التي تدعم واجهة برمجة تطبيقات Selenium Webdriver. من خلال WebDriver API ، من خلال بروتوكول JSON Wire ، يحدث تفاعل مع برنامج تشغيل المتصفح المحدد ، والذي بدوره يعمل مع متصفح حقيقي بالفعل ، ويقوم بتنفيذ الإجراءات التي نحتاجها.
اليوم ، الإصدار الثابت من العميل هو Selenium 3.X.
بالمناسبة ، وعد سيمون ستيوارت بتقديم سيلينيوم 4.0 في مؤتمر
سيلينيوم كونف اليابان .
السيلينيوم جريد
في عام 2008 ، أعلن Philippe Hanrigou عن GREN Selenium GRID لبناء بنية تحتية للاختبارات الذاتية بدعم من المتصفحات المختلفة.
يتكون السيلينيوم GRID من محور والعقد (العقد). العقدة هي مجرد عملية جافا. يمكن أن يكون على نفس الجهاز مع Hub ، يمكن أن يكون على جهاز آخر ، يمكن أن يكون في حاوية Docker. المحور هو في الأساس موازن للاختبارات التلقائية ، والذي يحدد العقدة التي يجب إرسال تنفيذ اختبار معين إليها. يمكنك توصيل المحاكيات المحمولة به.
يتيح لك Selenium GRID إجراء اختبارات على أنظمة تشغيل مختلفة وإصدارات مختلفة من المتصفحات. كما أنه يوفر وقتًا كبيرًا عند تشغيل عدد كبير من الاختبارات الذاتية ، إذا تم تشغيل الاختبارات الذاتية بالتوازي باستخدام برنامج maven-surfire-plugin أو آلية موازية أخرى.
بالطبع ، السيلينيوم جريد له عيوبه. عند استخدام التطبيق القياسي ، يتعين على المرء أن يواجه المشاكل التالية:
- إعادة التشغيل المستمر للمحور والعقدة. إذا لم يتم استخدام لوحة الوصل والعقدة لفترة طويلة ، ثم مع اتصال لاحق ، تكون المواقف ممكنة عندما ، عند إنشاء جلسة على عقدة ، تقع هذه الجلسة نفسها في مهلة. لاستعادة العمل ، مطلوب إعادة تشغيل ؛
- الحد من عدد العقد. تعتمد اعتمادا كبيرا على الاختبارات وإعدادات الشبكة. دون الرقص مع الدف ، يبدأ في التباطؤ مع عشرات العقد المتصلة ؛
- وظائف هزيلة.
- استحالة التحديث دون توقف كامل للخدمة.
بنية AutoTest الأولية في SberTech
في وقت سابق في SberTech كان هناك البنية التحتية التالية لاختبارات واجهة المستخدم التلقائي. بدأ المستخدم التجميع على Jenkins ، الذي ، باستخدام البرنامج المساعد ، التفت إلى OpenStack لتخصيص الجهاز الظاهري. تم اختيار VMs مع "صورة" خاصة والمتصفح المطلوب ، وعندها فقط تم تشغيل الاختبارات التلقائية على هذا VM.
إذا كنت ترغب في إجراء اختبارات في متصفحات Chrome أو FireFox ، فإن حاويات Docker كانت قائمة. ولكن عند العمل مع IE ، كان عليك رفع VM "نظيف" ، والذي استغرق ما يصل إلى 5 دقائق. لسوء الحظ ، يعد Internet Explorer متصفحًا ذا أولوية في شركتنا.
كانت المشكلة الرئيسية أن هذا النهج استغرق الكثير من الوقت عند تشغيل autotests في IE. اضطررت إلى فصل الاختبارات على الأجنحة وبدء التجمعات بالتوازي لتحقيق بعض التخفيض في الوقت على الأقل. بدأنا في التفكير في التحديث.
متطلبات البنية التحتية الجديدة
من خلال زيارة مؤتمرات مختلفة حول الأتمتة والتطوير و DevOps (Heisenbug و SQA Days و CodeOne و SeleniumConf وغيرها) ، قمنا تدريجياً بتكوين قائمة من متطلبات البنية التحتية الجديدة:
- تقليل الوقت لإجراء اختبارات الانحدار ؛
- توفير نقطة إدخال واحدة لعمليات الاختبار التلقائي ، مما سيسهل تصحيح الأخطاء الخاص بهم لأخصائي التشغيل الآلي. لا توجد حالات نادرة عندما يعمل كل شيء محليًا ، وبمجرد وصول الاختبارات إلى خط الأنابيب - السقوط المستمر.
- لتوفير التوافق عبر المستعرض وأتمتة المحمول (اختبارات Appium).
- التزم بالبنية السحابية للبنك: يجب إدارة حاويات السفن في OpenShift.
- تقليل الذاكرة واستهلاك وحدة المعالجة المركزية.
لمحة موجزة عن الحلول الحالية
بعد تحديد المهام ، قمنا بتحليل الحلول الحالية في السوق. الأشياء الرئيسية التي
درسناها كانت منتجات فريق
Aerokube (سيلينويد و مون) ، حلول الفلاب (مختبر ألفا) ،
جي دبليو- جرييد (أفيتو) و
زالينيوم .
كان العيب الرئيسي لـ Selenoid هو عدم وجود دعم لـ OpenShift (غلاف على Kubernetes). حول قرار الفلاب هناك
مقال عن حبري . اتضح أن يكون نفس شبكة السيلينيوم. تم توضيح حل Avito في
المقالة . لقد رأينا التقرير الخاص به في مؤتمر هايسنبوج. كما كان سلبيات أننا لم نحب. Zalenium هو مشروع مفتوح المصدر ، كما أنه لا يخلو من المشاكل.
إيجابيات وسلبيات الحلول التي نظرنا فيها ملخصة في الجدول:
نتيجة لذلك ، اخترنا منتجًا من Aerokube - Selenoid.
سيلينويد مقابل مون
لمدة أربعة أشهر ، استخدمنا Selenoid لأتمتة النظام البيئي سبيربنك. هذا حل جيد ، لكن البنك يتجه نحو OpenShift ، ونشر Selenoid في OpenShift ليس مهمة تافهة. إن الدقة هي أن Selenoid في Kubernetes يتحكم في مرسى الأخير ، و Kubernetes لا يعرف شيئًا عن ذلك ولا يمكنه المزاح بشكل صحيح العقد الأخرى. بالإضافة إلى ذلك ، يتطلب Selenoid في Kubernetes GGR (Go Grid Router) حيث يكون موازنة التحميل عرجاء.
بعد أن جربنا استخدام Selenoid ، أصبحنا مهتمين بأداة Moon المدفوعة ، والتي تركز بشكل خاص على العمل مع Kubernetes ولديها عدد من المزايا بالمقارنة مع Selenoid المجانية. لقد تم تطويره منذ عامين الآن ويسمح لك بنشر البنية التحتية لاختبار واجهة مستخدم Selenium دون إنفاق الأموال على مهندسي DevOps الذين لديهم معرفة سرية حول كيفية نشر Selenoid في Kubernetes. هذه ميزة مهمة - جرّب ترقية نظام سيلينويد دون توقف وتقليل السعة عند إجراء الاختبارات؟
لم يكن القمر هو الخيار الوحيد. على سبيل المثال ، يمكنك أن تأخذ Zalenium المذكورة أعلاه ، ولكن في الواقع هو نفس شبكة السيلينيوم. يحتوي على قائمة كاملة من الجلسات داخل لوحة الوصل المخزنة داخلها ، وإذا تعطل المركز ، ثم تنتهي الاختبارات. على هذه الخلفية ، يفوز مون بسبب حقيقة أنه لا يوجد لديه حالة داخلية ، وبالتالي فإن سقوط واحدة من النسخ المتماثلة لها غير محسوس بشكل عام. القمر لديه كل شيء "برشاقة" - يمكن إعادة تشغيله دون خوف ، دون انتظار نهاية الجلسة.
يحتوي الزالينيوم على قيود أخرى. على سبيل المثال ، لا يدعم الحصة النسبية. لا يمكنك وضع نسختين منه لموازن التحميل ، لأنه لا يعرف كيفية توزيع حالته بين "رأسين" أو أكثر. وبشكل عام ، من الصعب البدء في مجموعته. يستخدم Zalenium PersistentVolume لتخزين البيانات: سجلات واختبارات الفيديو المسجلة ، ولكن هذا يتعلق بشكل رئيسي بالأقراص الموجودة في السحب ، وليس S3 الأكثر تحملاً للأخطاء.
اختبار البنية التحتية للسيارات
البنية التحتية الحالية باستخدام Moon و OpenShift هي كما يلي:
يمكن للمستخدم إجراء الاختبارات محليًا واستخدام خادم CI (في حالتنا ، Jenkins ، ولكن قد يكون هناك آخرون). في كلتا الحالتين ، نستخدم RemoteWebDriver للوصول إلى OpenShift ، حيث يتم نشر الخدمة التي تحتوي على عدة نسخ متماثلة من القمر. علاوة على ذلك ، تتم معالجة الطلب الذي تتم الإشارة إلى المستعرض الذي نحتاج إليه في Moon ، ونتيجة لذلك يبدأ Kubernetes API في تكوين موقد مع هذا المستعرض. ثم يقوم مون بإرسال طلبات مباشرة إلى الحاوية ، حيث تمر الاختبارات.
في نهاية الجولة ، تنتهي الجلسة ، تحت يتم حذف ، يتم تحرير الموارد.
قم بتشغيل Internet Explorer
بالطبع ، كانت هناك بعض الصعوبات. كما ذكرنا سابقًا ، المتصفح المستهدف بالنسبة لنا هو Internet Explorer - تستخدم معظم تطبيقاتنا مكونات ActiveX. بما أننا نستخدم OpenShift ، فإن حاويات Docker الخاصة بنا تعمل على RedHat Enterprise Linux. وبالتالي ، فإن السؤال الذي يطرح نفسه: كيفية بدء تشغيل Internet Explorer في حاوية Docker عندما يكون الجهاز المضيف على نظام Linux؟
شارك فريق من فريق تطوير Moon قرارهم بإطلاق Internet Explorer و Microsoft Edge.
عيب هذا الحل هو أن الحاوية Docker يجب أن تعمل في وضع متميز. لذلك ، يستغرق تهيئة الحاوية 10 ثوانٍ باستخدام Internet Explorer بعد بدء الاختبار ، وهو أسرع بـ 30 مرة من استخدام البنية الأساسية السابقة.
استكشاف الأخطاء وإصلاحها
في الختام ، نود أن نشارككم حلولًا لبعض المشكلات التي واجهناها أثناء نشر المجموعة وتكوينها.
المشكلة الأولى هي توزيع صور الخدمة. عندما يبدأ القمر في إنشاء المتصفح ، بالإضافة إلى الحاوية مع المتصفح ، يتم إطلاق حاويات خدمة إضافية - مسجل ، مدافع ، مسجل فيديو.
يتم إطلاق كل هذا في جراب واحد. وإذا لم يتم تخزين صور هذه الحاويات في العقد ، فسيتم تسليمها من لوحة Docker. في هذه المرحلة ، سقط كل شيء بالنسبة لنا ، لأنه تم استخدام الشبكة الداخلية. لذلك ، وضع الرجال من Aerokube هذا الإعداد بسرعة في تهيئة الخريطة. إذا كنت تستخدم أيضًا شبكة داخلية ، فننصحك بإدخال هذه الصور في السجل وتحديد المسار الخاص بها في خريطة تكوين moon-config. في ملف service.json ، تحتاج إلى إضافة قسم الصور:
"images": { "videoRecorder": "ufs-selenoid-cluster/moon-video-recorder:latest", "defender": "ufs-selenoid-cluster/defender:latest", "logger": "ufs-selenoid-cluster/logger:latest" }
تم تحديد المشكلة التالية بالفعل في بداية الاختبارات. تم إنشاء البنية الأساسية بأكملها ديناميكيًا ، لكن الاختبار تعطل بعد 30 ثانية بسبب الخطأ التالي:
Driver info: org.openqa.selenium.remote.RemoteWebDriver Org.openqa.selenium.WebDriverException: <html><body><h1>504 Gateway Time-out</h1> The server didn't respond in time.
لماذا حدث هذا؟ الحقيقة هي أن الاختبار من خلال RemoteWebDriver يشير في البداية إلى طبقة التوجيه OpenShift ، المسؤولة عن التفاعل مع البيئة الخارجية. دور هذه الطبقة هو Haproxy ، الذي يعيد توجيه الطلبات إلى الحاويات التي نحتاج إليها. في الممارسة العملية ، تحول الاختبار إلى هذه الطبقة ، وتم إعادة توجيهه إلى الحاوية الخاصة بنا ، والتي كان من المفترض أن تنشئ متصفحًا. لكنه لم يستطع تكوينها ، حيث نفدت الموارد. لذلك ، دخل الاختبار في قائمة الانتظار ، وبعد 30 ثانية أسقطه الخادم الوكيل حسب المهلة ، لأنه افتراضياً كان هذا الفاصل الزمني.
كيفية حل هذا؟ تحول كل شيء إلى أنه بسيط للغاية - كان عليك فقط إعادة تعريف التعليق التوضيحي haproxy.router.openshift.io/timeout لجهاز التوجيه الخاص بنا.
$oc annotate route moon --overwrite haproxy.router.openshift.io/timeout=10m
الحالة التالية هي العمل مع تخزين متوافق مع S3. يمكن لـ Moon تسجيل ما يحدث في الحاوية باستخدام المستعرض. على عقدة واحدة ، ترتفع حاويات الخدمة مع المستعرض ، واحدة منها عبارة عن مسجل فيديو. يقوم بتسجيل كل ما يحدث في الحاوية وبعد نهاية الجلسة يرسل البيانات إلى وحدة التخزين المتوافقة مع S3. لإرسال البيانات إلى مثل هذا التخزين ، يلزمك تحديد عنوان url وكلمات مرور الإقبال واسم السلة في الإعدادات.
يبدو أن كل شيء بسيط. أدخلنا البيانات وبدأنا في تشغيل الاختبارات ، لكن لم تكن هناك ملفات في المستودع. بعد تحليل السجلات ، أدركنا أن العميل اعتاد أن يتفاعل مع S3 أقسم لعدم وجود شهادات ، لأننا في حقل url حددنا العنوان لـ S3 مع https. يتمثل الحل في تحديد وضع http غير محمي أو إضافة شهاداتك إلى الحاوية. يكون الخيار الأخير أكثر صعوبة إذا كنت لا تعرف ما هو موجود في الحاوية وكيف يعمل كل شيء.
وأخيرا ...
يمكن تكوين كل حاوية مستعرض بشكل مستقل - كل المعلمات المتوفرة موجودة في وثائق Moon. دعنا ننتبه إلى الإعدادات المخصصة مثل المميز و nodeSelector.
هناك حاجة لهذا الغرض. يجب تشغيل الحاوية مع Internet Explorer ، كما ذكر أعلاه ، فقط في الوضع المميز. يتم توفير التشغيل في الوضع المطلوب من خلال العلامة المميزة بالإضافة إلى إصدار حقوق تشغيل هذه الحاويات لحساب الخدمة.
لتشغيل على عقد منفصلة ، تحتاج إلى تسجيل nodeSelector:
"internet explorer": { "default": "latest", "versions": { "latest": { "image": "docker-registry.default.svc:5000/ufs-selenoid-cluster/windows:7", "port": "4444", "path": "/wd/hub", "nodeSelector": { "kubernetes.io/hostname": "nirvana5.ca.sbrf.ru" }, "volumes": ["/var/lib/docker/selenoid:/image"], "privileged": true } } }
آخر نصيحة. تتبع عدد جلسات العمل. نعرض جميع الإصدارات في غرافانا:
إلى أين نذهب؟
نحن لسنا راضين عن كل شيء في البنية التحتية الحالية ، والحل لا يمكن حتى الآن أن يسمى كاملة. في المستقبل القريب ، نخطط لتثبيت IE في Docker ، والحصول على واجهة مستخدم "غنية" في Moon ، وأيضًا اختبار Appium للاختبارات التلقائية المتنقلة.