الحفاظ على الجودة الشاملة من خلال الاختبار البصري

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

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

من خلال إضافة اختبار بصري آلي ، يمكننا القضاء على تلك الاختبارات غير المستقرة ، ورفع مستوى خطوط أنابيب الاختبار لدينا التي توفر تلك التغطية (والمزيد) من خلال الاستفادة من مقارنات الصور الذكية باستخدام لقطات شاشة لموقعنا أو تطبيقنا.

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

نظرة سريعة على بعض أنواع الاختبارات الآلية

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

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

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

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

دعنا نلقي نظرة على الشكل الذي تبدو عليه بعض استراتيجيات الاختبار هذه في الممارسة العملية.

وحدة التجارب

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

 function myBusinessLogic(pricePerItem, quantity, discount) { const subtotal = pricePerItem * quantity; return subtotal - ( discount * subtotal ); } expect(myBusinessLogic(2, 4, .1)).toEqual(7.2);

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

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

اختبار التكامل

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

 cy.get('.add-to-cart').click(); cy.url().should('contain', 'cart'); cy.get('.cart li').contains('My Item');

قد يكون من الممكن تمامًا أن يعمل مكون واجهة المستخدم الصغير الخاص بك كما هو متوقع من تلقاء نفسه. قد يتم تشغيل الأحداث التركيبية بشكل صحيح في مثيل onClick. قد يعمل هذا الرمز الذي يغلف طلبات واجهة برمجة التطبيقات (API) بشكل مثالي مع بعض البيانات المزيفة. ولكن قد تكون هناك فجوات بين هاتين القطعتين تعملان معًا قد لا تكتشفها اختبارات الوحدة الخاصة بك.

تعتبر اختبارات الاندماج طريقة مقنعة لاختبار طلبك ، ولكن يمكنك أن تأخذ هذه الخطوة إلى الأمام وأنت تتطلع إلى اختبار "كل الأشياء".

اختبار شامل

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

 cy.visit('/products'); cy.get('.product a[href="/product/1234"]').click() cy.url().should('contain', 'product/1234'); ... cy.get('.order-button').click(); cy.url().should('contain', 'receipt'); cy.get('.receipt li').contains('My Item');

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

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

الاستفادة من الأنواع المختلفة للاختبارات

هناك مجموعة متنوعة من العقليات التي تصف عمومًا عدد الاختبارات التي يجب أن تمضي وقتًا في كتابتها من كل نوع.

جاء مايك كوهن بمفهوم "هرم الاختبار" في كتابه النجاح مع رشيق .

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

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

في بيئات التطوير الحديثة ، لدينا الكثير من الأدوات المدهشة تحت تصرفنا مثل Cypress و Selenium و Playwright والتي يمنح كل منها المطورين ومهندسي ضمان الجودة القدرة على كتابة الاختبارات التي تتفاعل بسهولة مع متصفحات مثل Chrome و Firefox.

باستخدام Cypress ، قد تبدو كتابة اختبار ينقر على زر أمرًا بسيطًا مثل:

 cy.get('#my-button').click()

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

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

ولكن بغض النظر عن مزيج الاختبارات التي تجريها ، فإن هذه الاختبارات الآلية التي تتفاعل فقط مع DOM (نموذج كائن المستند) وتختبرها تفتقد إلى جزء كبير من اللغز: كيف يرى زوار موقعك هذا التطبيق بصريًا.

ما أنواع الاختبارات التقليدية التي لا تلتقطها

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

ما أعنيه بذلك هو أنهم لا يختبرون ما يراه زائر تطبيقك بالفعل.

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

هذا لا يختبر أشياء مثل ما إذا كان النص على صفحتك مقروءًا أم لا. هل أضاف شخص ما تغيير CSS أدى بطريق الخطأ إلى تعويم كل الأشياء إلى اليسار وقلبها رأسًا على عقب؟

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

من الناحية الواقعية ، لا يمكننا توقع توفير تغطية كاملة بنسبة 100٪ لكل تفاصيل واجهة المستخدم مع الاختبار التقليدي. بين عدد لا حصر له من حالات التطبيق وحقيقة أننا نضيف دائمًا ميزات جديدة ، فإنه ببساطة لا يتسع.

هذا ما يقودنا إلى عنوان هذه القصة: الاختبار البصري .

ما هو الاختبار البصري؟

يلتقط Visual Testing المخرجات المرئية (مثل لقطة شاشة) لتطبيق ويقارنه بنفس التطبيق في وقت آخر.

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

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

أنواع الاختبارات المرئية

الشيء المثير للاهتمام حول الاختبار المرئي هو أن هناك طرقًا مختلفة للتعامل مع هذا الأمر.

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

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

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

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

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

حيث يساعد الاختبار البصري

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

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

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

كيف يعمل الاختبار البصري؟

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

مقارنات الصور

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

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

مع وضع ذلك في الاعتبار ، سترغب في التقاط لقطة شاشة في كل خطوة على الطريق. على سبيل المثال ، إذا كنت تختبر متجرًا عبر الإنترنت ، فقد ترغب في إضافة خطوات لما يلي:

• قائمة المنتجات المحملة على الصفحة ؛
• صفحة المنتج بعد اختيار منتج واحد ؛
• واجهة مستخدم عربة التسوق على الصفحة بعد إضافة منتج إلى عربة التسوق ؛
• صفحة عربة التسوق بعد التنقل إلى العربة ؛
• واجهة مستخدم الدفع والشحن بمجرد دخول تدفق الخروج ؛
• صفحة الاستلام عند الشراء الناجح.

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

القطع الفنية

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

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

في حالة Cypress و Applitools ، كان Cypress يتنقل عبر كل صفحة ، حيث يقوم تطبيق Applitools SDK باستخراج لقطة من DOM ، وإرسال تلك اللقطة إلى سحابة Applitools ، حيث ستنشئ أخيرًا لقطات شاشة للمقارنة.

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

التكامل مع أطر الاختبار الحالية

مثل تكامل Cypress و Applitools أعلاه ، عادةً ما يكون للتكامل احتكاك منخفض. يمكن دمج الكثير من منصات الاختبار المرئي المتاحة مباشرةً في أطر الاختبار الحالية ، ويعتمد الأمر في الغالب على مجموعات SDK المتوفرة لديها.

 cy.visit('/product/1234'); cy.eyesOpen({ appName: 'Online Store', testName: 'Product Page' }); cy.eyesCheckWindow(); cy.eyesClose();

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

أتمتة الاختبارات

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

تسمح لك حلول CI / CD التقليدية مثل Jenkins أو Travis CI بإجراء اختباراتك في بيئاتها جنبًا إلى جنب مع بقية خط أنابيب التكامل والنشر. تعد أدوات مثل GitHub Actions الجديدة نسبيًا في مجال الأتمتة ، حيث توفر آلية مماثلة لبيئات CI / CD التقليدية ، ولكن داخل مستودع GitHub الحالي. هذا يجعله فوزًا سهلاً عند محاولة إجراء الاختبارات ومهام التعليمات البرمجية الأخرى تلقائيًا ، حيث لا تحتاج إلى نظام جديد تمامًا ولكن بدلاً من ذلك تستخدم أدواتك الحالية.

 name: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - run: npm ci - run: npm test

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

ما هي فوائد الفحص البصري؟

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

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

رمز أقل للمحافظة عليه

عند الدمج مع نظام أساسي للاختبار المرئي ، ستتمحور غالبية التعليمات البرمجية حول شيئين: التفاعلات ولقطات الشاشة.

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

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

الاختبارات أقل هشاشة

وباستخدام لقطات الشاشة هذه كآلية للتأكيد ، ستكون اختباراتك أقل هشاشة وهشاشة.

إذا كنت تكتب تأكيدًا مقابل جزء معين من DOM ، مثل استخدام معرف أو محدد تم إنشاؤه تلقائيًا ، فأنت تخاطر باختبار كسر مع أي تغيير في هذا المكون.

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

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

اختبار ما يستخدمه الناس في الواقع

عند الحديث عن اختبار الشكل المرئي ، عند الاختبار المرئي ، فأنت تختبر ما يراه زوارك أو عملاؤك بالفعل.

لا يؤدي استخدام HTML الدلالي المناسب إلى جعل مشروعك قابلاً للاستخدام تلقائيًا. تغيير صغير في CSS (مثل z-index) يمكن أن يغير تمامًا قابلية الاستخدام وكيف يبدو شيء ما.

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

يوصى بالقراءة : إدارة CSS Z-Index في المشاريع الكبيرة

اختبار الأشياء التي لم تفكر في اختبارها

أنت أيضًا تحصل على تغطية لأجزاء مختلفة من طلبك لم تفكر حتى في اختبارها.

ضع في اعتبارك قائمة الاختبارات التي لديك في مجموعتك ، تلك هي الاختبارات التي فكرت في كتابتها أو كتابتها لأنك واجهت خطأ سابقًا. ماذا عن باقي التطبيق؟

ستلتقط لقطة الشاشة هذه مزيدًا من التفاصيل والسياق الذي ربما لم تتضمنه اختباراتك الأخرى.

ماذا لا يغطي الاختبار البصري؟

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

اختبار منطق الأعمال القائم على البيانات

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

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

اختبار API شامل

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

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

الشروع في الاختبار البصري

كأداة أخرى في حزامنا ، يمكن أن يساعد الاختبار المرئي حقًا في توفير مستوى آخر من التغطية التي تساعدنا في الحفاظ على مستوى عالٍ من الجودة لتطبيقاتنا ، ولكن من أين نبدأ؟

تناسب دورة حياة التنمية

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

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

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

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

لحسن الحظ ، هناك الكثير من الخيارات لكل من الخدمة التي تستخدمها ، ولكن أيضًا نقاط التكامل لاستخدام هذه الخدمات.

الحلول المتاحة للاختبار البصري

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

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

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

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

دمج الاختبارات المرئية

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

وخير مثال على ذلك إذا كنت قد أعددت بالفعل وتشغيلًا باستخدام Cypress:

 it('should log into the application', () => { cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.get('h1').contains('Dashboard'); });

إذا كنت تجري بالفعل اختبارات برمجية ، فيمكنك ببساطة إجراء اختبار مرئي لتوفير طبقة أخرى من التغطية.

 it('should log into the application', () => { cy.eyesOpen({ appName: 'My App', testName: 'Login' }); cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.eyesCheckWindow(); cy.eyesClose(); });

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

 npm install @applitools/eyes-storybook --save-dev npx eyes-storybook

في النهاية ، السؤال الأكبر هو ما هو إطار الاختبار الذي تريد استخدامه وما إذا كانت الخدمة التي تريد استخدامها تدعم هذا الإطار.

الاستخدامات الإبداعية للاختبار البصري

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

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

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