في المراحل الأولى من التطوير ، يمكنك الحصول على الاختبار اليدوي وفقًا لخطة اختبار معينة. ولكن مع ظهور البنية المعيارية ، عندما تتمكن العديد من فرق التطوير من إجراء تغييرات في نفس الوقت ، هناك زيادة أسية في عدد البرامج النصية للاختبار. إبعادهم يدويًا يصبح أصعب وأصعب.
في هذه المقالة ، سنتحدث عن كيف نقوم في Virto Commerce بأتمتة الاختبار لسيناريوهات الأعمال الهامة.
لماذا كل هذا؟
سأعطي مثالاً من تجربتنا - تعديل صغير على غرار CSS جعل الزر "إضافة منتج إلى سلة التسوق" لم يعد مرئيًا على جهاز الجوال. للأسف ، في هذا النموذج ، تم اختباره وضرب الإصدار. هناك العديد من هذه الأمثلة حيث تؤدي الوظائف الجديدة والتصحيحات والتصحيحات الطفيفة إلى كسر سيناريوهات الأعمال المهمة. لسوء الحظ ، غالبًا ما نتعرف عليها بعد الإصدارات ومن العملاء. لتجنب ذلك ، بدأنا منذ أكثر من عامين في تنفيذ اختبار E2E كجزء من عملية التطوير. بعد ذلك ، تم تحديد معظم الأخطاء في مرحلة التطوير ، وليس في بيئة القتال.
تقوم E2E باختبار سيناريو الأعمال من البداية إلى النهاية. يحاكي اختبار E2E إجراءات المستخدم الحقيقية في متصفح حقيقي ، تمامًا كما سيستخدم المستخدم الحقيقي الحل.
نستخدم اختبارات E2E:
- للسيطرة على الانحدار
- لوصف النظام
- للاندماج في CI / CD
وهذا يشمل التأكد من أن جميع الوحدات تعمل وتعمل بشكل صحيح ومتوقع.
تتيح لنا اختبارات E2E تغطية أقسام التطبيق التي لم يتم التحقق منها بواسطة اختبارات الوحدة والتكامل. هذا يرجع إلى حقيقة أن اختبارات الوحدة واختبارات التكامل تغطي الأجزاء الفردية من التطبيق واختبار جزء معزول من الوظيفة. حتى إذا كانت هذه الأجزاء تعمل بشكل جيد من تلقاء نفسها ، فلا يمكنك التأكد تمامًا مما إذا كانت ستعمل معًا. وبالتالي ، فإن وجود مجموعة من اختبارات E2E في أعلى الوحدة والتكامل يسمح لنا باختبار الحل بالكامل بأكثر طريقة كاملة.
تستغرق كتابة اختبارات E2E وتشغيلها وقتًا وموارد. تقدم Google ، على سبيل المثال ، فصلًا بنسبة 70/20/10: اختبارات الوحدة بنسبة 70٪ و 20٪ اختبارات التكامل و 10٪ اختبارات E2E. ستكون التركيبة الدقيقة مختلفة لكل مشروع ، ولكن بشكل عام يجب أن تحافظ على شكل الهرم.
اختبارات E2E ليست بسيطة وتبدو في البداية مكلفة لتطويرها وصيانتها. في Virto Commerce ، نعمل باستمرار على تبسيط التطوير وتقليل تكلفة دعم اختبارات E2E عند إصدار إصدارات جديدة. نأمل أن تساعدك حلولنا في تبسيط استخدام E2E في مشاريعك.
قصة مستخدم جيدة - إنها جاهزة تقريبًا لاختبار E2E
يمكنك غالبًا أن تسمع أن كتابة اختبارات E2E تستغرق بعض الوقت ؛ فمن الصعب الحفاظ عليها. نعم ، هذا هو الحال ، ليس من السهل الحفاظ عليهم بنفس طريقة التوثيق. لماذا لا تجعلهم جزءًا من عملية التطوير وكتابة الوثائق ، وبالتالي التقاط سيناريوهات الأعمال.
يبدأ إنشاء E2E بوصف لقصة المستخدم. مدى دقة إعداد الوصف في هذه المرحلة ، سيكون من السهل جدًا على فريق التطوير كتابة اختبار E2E الذي سيثبت أن جميع الأنظمة تعمل بشكل صحيح عند تنفيذ هذا السيناريو.
مثال على قصة مستخدم لزر لإضافة عنصر إلى سلة التسوق:
GIVEN I am signed in to the storefront AND Some product page is open (/product-name) AND my cart is empty WHEN I click to the "Add" button on the item with the following parameters: THEN I should see a dropdown menu where I can choose from 1 to 10+
ثم يتحول إلى الاختبار التالي:
بعد مرور بعض الوقت ، يمكن للكُتّاب التقنيين أو فريق تطوير جديد ، بدلاً من قراءة الوثائق ، استخدام الاختبارات من أجل تشغيل البرامج النصية التي يتم تنفيذها ومشاهدتها في مستعرض حقيقي أو تسجيل دروس فيديو تلقائيًا.
سهل - تثبيت وتكوين المنقلة
كأداة اختبار ، اخترنا Protractor ، وهو نظام أتمتة اختبار E2E مفتوح المصدر تم تطويره خصيصًا لتطبيقات الويب AngularJS.
Protractor هو برنامج Node.js مبني على قمة WebDriverJS. يعمل المنقلة كمدمج للحلول يجمع بين التقنيات القوية مثل Node.js و Jasmine و Selenium و Mocha و Cucumber و Web.
يعرف المنقلة عن AngularJS ، مما يجعل من السهل كتابة الاختبارات دون قضاء الوقت في انتظار إطلاق مشروع AngularJS ، وتحديث الصفحة ، وما إلى ذلك ... تُظهر التجربة أن عتبة إدخال المطور منخفضة جدًا.
استخدم npm لتثبيت Protractor عالميًا:
npm install -g protractor
مدير webdriver هو أداة تجعل من السهل تكوين مثيل لـ Selenium Server. خادم السيلينيوم - سيتم استخدامه لنقل الأوامر بين الاختبار والبيئة الحقيقية.
قم بتشغيل هذا الأمر لتثبيت أو تنزيل:
webdriver-manager update
وركض:
webdriver-manager start
يقوم هذا الأمر بتشغيل Selenium Server وفتح نافذة لعرض السجل. سيرسل منقلة الطلبات إلى هذا الخادم للتحكم في المتصفح.
المنقلة على استعداد للذهاب. يمكن العثور على وصف أكثر تفصيلاً للخطوات الأساسية لكتابة الاختبارات على
الموقع الرئيسي .
الهيكل الصحيح للمشروع
تكون اختبارات E2E دائمًا في نفس المستودع مثل التطبيق أو السمة.
رفضنا استخدام خدمات اختبار E2E الخارجية ، لأنه مع البساطة الظاهرة ، تعقّد الخدمات بدء الاختبارات على الجهاز المحلي والصيانة اللاحقة. يقع الرمز والاختبارات في أماكن مادية مختلفة ، مما يؤدي إلى حقيقة أن المطورين ينسون تحديثها.
يؤدي العثور على رمز التطبيق والاختبار في مستودع واحد إلى تسهيل صيانة المشروع وصيانته.
يمكن
العثور على مثال أساسي
هنا .
يقوم المشروع بإنشاء مجلد E2E للبنية التالية ، والذي يستخدم كائنات الصفحة لتنظيم الاختبارات.
E2E/ |--cart | |--cart.pageObject.js | |--*.spec.js |--home | |--home.pageObject.js | |--*.spec.js |--conf.js
- conf.js - ملف التكوين موجود في الجذر
- لكل كائن واجهة يتم إنشاء المجلد الخاص به ، والذي يوجد فيه
- ملف pageObject لوصف العناصر في الصفحة
- العديد من ملفات المواصفات - حيث توجد الاختبارات
في المشروع استخدام:
- baseUrl - الذي يسمح لك باستخدام الاختبار لاختبار البيئات المختلفة
- المعلمات - التي تُستخدم للعثور على العناصر الأساسية في الصفحة أو ملء النماذج
github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L21
github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L29يمكن لمسؤول تكنولوجيا المعلومات بعد ذلك تغيير هذه المعلمات عند تكوين التشغيل في Jenkins ، في الوضع التلقائي لبيئات DEV و QA.
protractor conf.js --baseUrl=https://some-url.azurewebsites.net/--params.api.endpoint=https://some-admin-url.azurewebsites.net
تحسين البحث عن العناصر في الصفحة
يقدم المنقلة طرقًا مرنة للغاية للعثور على العناصر في الصفحة:
- بواسطة
- بواسطة النموذج
- بواسطة
- by.className
- عن طريق cs
- بواسطة. select ()
- by.partialButtonText ()
- ...
ولكن في المشاريع الأخيرة ، توصلنا إلى النموذج الذي يتم فيه تمييز العناصر التي تشارك في الاختبار بفئة خاصة مع البادئة المنقلة. في الاختبار ، تم العثور على هذه العناصر بواسطة byclassName.
هذا يبسط صيانة الاختبارات وإجراء التغييرات ، لذلك يمكن للمبرمج أو الأدوات الآلية تحديد أن العنصر الذي يشارك في اختبار E2E قد تغير.
ما المتصفحات التي نختبرها
بشكل افتراضي ، يتم تكوين جميع العمليات لتشغيل الاختبارات في متصفح Chrome. كما تظهر تجربتنا في استخدام اختبارات E2E في Chrome ، فإنها تسمح لنا بتحديد معظم المشاكل وفي نفس الوقت لا تعقد كتابة الاختبارات.
إذا كنت بحاجة إلى اختبار في متصفحات متعددة ، فهذا يتم من ناحية بسيطة للغاية ، من ناحية أخرى هناك صعوبات في التكوين ووجود أخطاء في تنفيذ برامج التشغيل للمتصفحات المختلفة.
في مشاريع العملاء المختلفة ، قمنا باختبار أيضًا في Firefox و Safari و IE. تقوم اختبارات Firefox في الواقع بتكرار النتائج في Chrome. لكن إطلاق E2E في Safari و IE يتطلب تكوين النظام ، وفتح المنافذ ، وتعطيل الأمان وتحرير التسجيل ، ولكن هذا سمح لكشف الكثير من المشاكل تلقائيًا في العرض وعدم توافق البرامج النصية في التطبيق.
لإضافة اختبار في المتصفح ، تحتاج إلى تنزيل وتثبيت
WebDriver اللازمة.وإضافة قسم جديد متعدد القدرات في ملف التكوين:
exports.config = { … multiCapabilities: [ { 'browserName' : 'chrome' }, { 'browserName' : 'firefox' } ], … }
نظرًا لأن تطبيقات الويب الحديثة تدعم العمل بدرجات دقة مختلفة ، يجب أن يؤخذ هذا في الاعتبار عند كتابة الاختبارات.
يسمح لك المنقلة بإجراء اختبارات لدرجات دقة الشاشة المختلفة.
للقيام بذلك ، هناك خيار لتعيين حجم الشاشة من خلال browser.driver.manage (). Window (). SetSize. في هذا المثال ، قمنا بتعيين حجم الشاشة على 1600 × 800.
exports.config = { … capabilities: { 'browserName': 'chrome' }, onPrepare: function() { browser.driver.manage().window().setSize(1600, 800)
أو من خلال قسم القدرات المتعددة في ملف التكوين. في هذا المثال ، سنجري اختبارات في متصفح Chrome لثلاث درجات دقة مختلفة.
multiCapabilities: [ { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1920,1080'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1680,1050'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1600,900'] }, specs: ['specs.js'] }]
E2E جزء من الوثائق.
مرة أخرى ، تعتبر E2E جيدة كعنصر توثيق ، مما يوضح ما قام به فريق التطوير. يمكن لفريق تطوير جديد أو كاتب فني إجراء الاختبارات ومشاهدة البرامج النصية التي تم تنفيذها مباشرة. لذلك ، قم بتوثيق كيف يمكن لموظف جديد تشغيل هذه الاختبارات.
تكامل CI / CD
يجب أن تكون أي اختبارات ذات صلة وتشغيلها بشكل دوري. إذا لم يتم ذلك ، فلا يجب أن تضيع وقتك في كتابة الاختبارات ، فستصبح عديمة القيمة في غضون أسبوعين ، وسيكون من الأسهل إعادة كتابتها من الصفر.
لقد اتخذنا خطوة مهمة في دمج اختبارات E2E في CI / CD وفي جعل E2E جزءًا من عملية النشر.
يتيح لك الدمج في CI / CD تشغيل اختبارات E2E تلقائيًا لبيئات DEV و QA لتقديم تعليقات وإضافة رؤية مفادها أن النظام لا يزال يعمل حتى بعد إجراء تغيير بسيط. وإذا تم كسر القرار ، فاعطِ معلومات متى ومتى حدث هذا التغيير.
أولاً ، يتم بدء الاختبارات عندما يتم تحديث إحدى الوحدات ويتم إدخال الإصدار الجديد في بيئة ضمان الجودة.
ثانيًا ، يتم تشغيل اختبارات E2E ليلاً وفقًا لجدول زمني في بيئات DEV و QA في الوضع التلقائي.
ثالثًا ، إذا لزم الأمر ، يمكن للمطورين أنفسهم تشغيل الاختبارات على النحو المطلوب.
بناءً على نتائج الإطلاق ، يتلقى جميع المشاركين في المشروع من فريق التطوير إلى العميل بريدًا إلكترونيًا يتضمن تقرير HTML عن نتائج الاختبار.
من المهم ملاحظة التوافر الإلزامي للمعلومات حول نتيجة الاختبار لفريق المشروع بأكمله. وهذا يعطي الثقة لفريق التطوير من ناحية وإدارة توقعات العملاء من ناحية أخرى. يمكن لفريق التطوير إجراء التغييرات بشكل أسرع ، مع إدراك أن سيناريوهات العمل الرئيسية تعمل. ويتلقى العميل معلومات حول جودة المشروع ، حيث يتم تحديد معظم المشكلات قبل الإصدار. وحتى إذا تم تحديد المشكلة من خلال الاختبار وتم تأجيل الإصدار ، فعندئذ تظهر معلومات حول ما تم كسره بالضبط وكيف تسير بعد ذلك عملية العمل على التصحيح.
لإنشاء التقارير ، نستخدم الإصدار المعدل من البرنامج المساعد protractor-jasmine2-html-reporter (https://github.com/VirtoCommerce/protractor-jasmine2-html-reporter). ينشئ هذا المكون الإضافي تقرير HTML ويدرج لقطات شاشة للعناصر المضمنة.
تثبيته بسيط للغاية:
- تثبيت المراسل-جاسمين 2-أتش تي أم أل-مراسل
- مضيفا منقلة-ياسمين 2-أتش تي أم أل-مراسل إلى مشروع
- تقرير الاتصال على طريقة التحضير
var HtmlScreenshotReporter = require('protractor-jasmine2-html-reporter'); var reporter = new HtmlScreenshotReporter(self.options); var name = browser.suite; self.options.reportTitle = name + '-report.html'; jasmine.getEnv().addReporter(reporter);
تحسين العملية باستمرار
العمل باستمرار في فريق لتقليل التكاليف وزيادة سرعة تطوير ودعم اختبارات E2E.
تدريب ومراجعة عملية كتابة الاختبار. تعرف على المكونات والخدمات الجديدة التي يمكن استخدامها.
على سبيل المثال ، نحن ندرس خيار اتصال الخيار. الخيار هو أداة لإجراء الاختبارات المؤتمتة المكتوبة بلغة بسيطة.
الاستنتاجات
اختبارات E2E ليست بهذه البساطة وتبدو مكلفة في البداية للحفاظ عليها ، لكنها ذات قيمة كبيرة لأنها مؤشر على صحة سيناريوهات الأعمال الهامة.
من تجربة استخدام اختبارات E2E في مشروع Virto Commerce ، يمكننا استخلاص الاستنتاجات التالية:
- تعد كتابة E2E جزءًا من عملية التطوير. وهي مهمة جدًا لأنها تختبر عمل العمليات التجارية والحل الكامل. تم اكتشاف عدد كبير من الأخطاء في مرحلة DEV و QA ، وليس في بيئة القتال.
- يجب أن تكون الاختبارات والرمز في نفس المستودع وأن تكون متاحة للمطور.
- تعتمد جودة اختبار E2E على وصف قصة المستخدم ؛ إذا تمت كتابتها بشكل صحيح ، فمن الأسهل على فريق التطوير إنشاء اختبار E2E.
- يمكن أن تعمل اختبارات E2E كوثائق وتسجيلات نصية.
- يجب تشغيل اختبارات E2E بشكل مستمر وتلقائي في بيئات DEV و QA. إذا لم تتم عملية الإطلاق تلقائيًا ، فلا يجب أن تضيع الوقت في الاختبارات ، فستصبح عديمة القيمة في غضون أسبوعين.
- يجب أن تكون نتائج الاختبار متاحة لجميع المشاركين في المشروع. وهذا يعطي صورة لما يحدث.
- E2E ليس حلاً لجميع المشاكل بنسبة 100٪. اتبع قاعدة 70/20/10: 70٪ اختبارات الوحدة ، 20٪ اختبارات التكامل و 10٪ اختبارات E2E
- العمل باستمرار في فريق لتقليل التكاليف وزيادة سرعة تطوير ودعم اختبارات E2E.
المراجع
www.protractortest.orgمنقلة لـ AngularJS - لم تكن كتابة الاختبارات من طرف إلى آخر ممتعة للغايةgithub.com/angular/protractor/blob/master/docs/page-objects.mdgithub.com/VirtoCommerce/vc-storefront/tree/master/VirtoCommerce.Storefront.Test/e2eما عليك سوى قول لا للمزيد من الاختبارات
الشاملة للاختبار
test.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html