أعد هذا المقال آنا آنا تشي وكسينيا كيسميش .أحد الأسباب وراء قيامنا بنشاط باختبار تخطيطات ، كان كالعادة أشعل النار. لقد صعدنا إلى خطأ بدأ يظهر بعد التحديث التالي لـ Chrome. اتضح أنه خلال 3 ساعات ، لا يمكن للمستخدمين تحويل الأموال من الحساب من خلال الحساب الشخصي لبنك الإنترنت الخاص بنا. وكل ذلك يرجع إلى حقيقة أنه في الإصدار الجديد من المتصفح ترك شكل تحويل الأموال من حساب إلى آخر النافذة.
البق مماثلة غير ضارة. على سبيل المثال ، ظهرت علامة تجارية معروفة للملابس أيضًا. نظرًا لعدم كفاية اختبار التصميم ، شاهد مستخدمو موقع هذه العلامة التجارية ، بدلاً من زر "معرفة المزيد" ، "تعلم الألم ...".
بطبيعة الحال ، فإن النقش الموجود على الزر قريب من الحقيقة ، فالأسعار هناك مؤلمة حقًا ، لكن من الواضح أن هذا ليس ما قصده منشئو الموقع. بشكل عام ، يجب مراقبة وتصحيح مثل هذه اللحظات ، بغض النظر عن سببها - إزعاج أو ابتسامة.
وإدراكًا لهذه المشكلات ، قمنا بتطبيق ممارسة المراجعة الإلزامية للتصميم من قِبل مصممي منتجاتنا ، لكنها لم تكن موجودة. اتضح أن ليس لدى جميع الفرق مصمم مخصص ، أو ليس لديهم وقت كافي ، أو الأسوأ من ذلك ، لا يمكن للجهة الأمامية أو المصمم التوصل إلى نهج مشترك في تخطيط صفحة أو نموذج أو عنصر.
دون التفكير مرتين ، انطلقنا للبحث عن خيارات لكيفية تقليل عدد عيوب التخطيط ومواجهة Front VS Designer إلى الحد الأدنى. بعد دراسة الممارسات والأدوات الممكنة لأتمتة تخطيطات الاختبار وجمع المخاريط ، قمنا بتنفيذ النهج التالي.
باختصار عنا:
الآن نقوم بتطوير منتج واحد ، يعمل به أكثر من 20 فريق سكروم ، كل منها مسؤول عن وظيفة معينة ، بينما نحاول الحفاظ على نمط وتصميم واحد للمنتج نفسه - عرض مرئي ، تخطيط العناصر الرئيسية ، إلخ.
فيما يتعلق بتوزيع المستخدمين حسب المتصفح ، يستخدم المستخدمون اليوم (يتم تقريب القيم):
- 60 ٪ كروم
- 30 ٪ - فايرفوكس ،
- 10 ٪ - المتصفحات الأخرى.
نحن نختبر الوظائف بمساعدة أكيتا BDD-framework (Java + Cucumber + Selenide) ، كتبنا عنها هنا .
بادئ ذي بدء ، أردنا حل المشكلة مع الاتفاقات بين الجبهة والمصمم. في المرحلة الأولية من إنشاء نموذج للحساب الوظيفي ، يصف كل من الجهة الأمامية والمصمم "العقد". في هذا العقد ، يصفون جميع الترتيبات لترتيب العناصر ، أنماطها ، المسافة ، إلخ. نتيجةً لذلك ، عند اكتشاف عدم تطابق التصميم مع تخطيط الصفحة ، لن يتعين على اللاعبين أن يكتشفوا لفترة طويلة من المناسب ومن المسؤول.
يصفون ترتيباتهم في ملف galen-spec.
ما هو جالين المواصفات؟
من أجل أتمتة اختبار التخطيط وبالتالي تقليل عدد العيوب ، قررنا تطبيق أداة Galen Framework. يعتمد على ملف. spec فقط (المواصفات أو ، كما أطلقنا عليها ، "العقد"). ويتكامل بسهولة مع اختبارات السيلينيوم.
بعد أن يصمم المصمم والجهة الأمامية "العقد" ، يقوم المختبر بتكوين ملف .spec بناءً عليه ، وفقًا لمتطلبات Galen. يستخدم الإطار لغته الخاصة لكتابة مواصفات التحقق.
ماذا يتكون ملف. spec من؟
منطقيا ، يمكن تقسيمها إلى قسمين:
1. تعريفات الكائننحن هنا بحاجة إلى تحديد الكائنات الموجودة على صفحتنا - الرأس والتذييل والقائمة والمحتوى ، إلخ. بشكل عام ، ندرج العناصر الرئيسية التي سنقوم بفحصها ، ومنحهم أسماء وتحديد المواقع.
objects - العناصر في الصفحة (يمكنك استخدام CSS ، XPATH ، ID)
2. عند تحديد المواقع ، يجب تحديد أنماط ومواصفات كائنات محددة. لهذا ، نستخدم جزء من
مواصفات مواصفات الكائن ، حيث نصف بالتفصيل ، على سبيل المثال ، أن كتلة النص الخاصة بنا (نص الوصف) موجودة داخل نموذج الوصف ، أسفل الرأس وتحتوي على نص معين.
القسم الرئيسي - يصفobjects المعلمات الخاصة بكل عنصر تم وصفه.
* تعتبر لغة galen spec حساسة للمسافة البادئة في القسم الرئيسي ، لذلك انتبه جيدًا لهذا ولاحظ علامات التبويب :)وبالتالي ، فإن "العقد" ، المبرم بين الأمام والمصمم ونقل إلى لغة جالين ، يسمح لنا بالتحقق التلقائي من موقع العناصر ومحتواها الداخلي ، وكذلك القدرة على التكيف والتوافق عبر المستعرض.
مثال سريع البدء
- نحن نصف عناصر صفحة معينة ونقوم بالتحقق من ملفات. spec باستخدام لغة Galen Spec ، ونضع المواصفات في الحزمة.
- نضيف لقطات الشاشة المرجعية إلى حزمة المواصفات / الصور
- نحن نعمل على BDD ، لذلك قد يبدو البرنامج النصي في ملف .feature بشيء من هذا القبيل:
- تشغيل اختبار البرنامج النصي من خلال عداء الخيار المعتاد.
في هذا السيناريو ، نتحقق من الصفحة الرئيسية لـ GitHub. في الخطوة الأخيرة أضفنا التحقق من التصميم. اختبارات مماثلة يمكن أن تكمل الاختبارات الوظيفية الحالية ، أو تشغيلها بشكل منفصل. إذا تم العثور على أي عدم تطابق في التخطيط ، فسنحصل على صورة بالنتيجة المتوقعة والنتيجة ، بالإضافة إلى الفرق فيها. هذا كله يعلق على تقرير الديوث.
الفرق في التقارير كما يلي:
خطأ = خطأ {[لا يبدو العنصر ". /akita-testing-template/src/test/resources/specs/images/registration-form.png". هناك 10.47 ٪ بكسل متطابقة ولكن الحد الأقصى المسموح به هو 10 ٪]نرى هنا أن عملية الفحص قد فشلت ، حيث تختلف الصور بأكثر من 10٪ وكل اختلافات الألوان هذه ، باستثناء التعبئة السوداء ، هذا هو الفرق بين العناصر.
إذا كانت العناصر متطابقة تمامًا ، فسيتم عرض الفرق باللون الأسود.
السؤال الأكثر شيوعًا هو ، أين يمكنني الحصول على لقطة شاشة مرجعية؟
الإجابة: نحن نأخذ المعيار إما من المصمم ، أو عن طريق إجراء اختبارات على بيئة prodov ، والتي نعتبرها المعيار. نحصل على صور لبناتنا من هناك ، والتي سنقوم بمقارنتها ، ونضعها في مجلد الصور ، حيث ستسحب المواصفات الروابط إليها.
ماذا وصلنا إلى استخدام هذا النهج
- تمكنت من تقليل عدد اختبارات الدخان ووقتها بنحو 20 ٪ بسبب حقيقة أن التحقق من بعض الأشكال والعناصر المماثلة قد انهار في اختبار واحد ، والذي يتحقق المكون البصري ويكشف على الفور التناقضات
- الآن يمكننا التأكد من أن تطبيقاتنا يتم عرضها بشكل صحيح في المتصفحات المحددة
- أعلم أن القدرة على التكيف على ما يرام وليس مفترق
- جاء إلى مراجعة التصميم التلقائي.
يمكنك قراءة الوثائق المتعلقة بترجمة ملفات galen-spec هنا - دليل
galen-spec-language .
تحدثنا عن الجوانب الفنية للعمل مع Galen Framework ، وقدراتها وعمليات الفحص الأساسية في معسكر السيلينيوم الأخير ، وسوف نكتب على المدونة.
القدرة على استخدام galen-spec والخطوات الجديدة للتحقق من التصميم الذي اتخذناه في
مكتبة Akita ، حيث يوجد
قالب لبداية سريعة ، ونجري أيضًا
محادثة برقية حيث يمكنك توجيه أسئلة تهمك.
وسوف نجيب.