اختبار عبر المتصفحات عالي التأثير وبأقل جهد ممكن

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

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

مزيد من القراءة على SmashingMag:

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

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

سياق الكلام

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

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

ما هو هدفك؟

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

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

أول شيء أريدك أن تستخلصه من هذا المقال هو أن هذين الهدفين يتعارضان مع بعضهما البعض .

من ناحية أخرى ، أعلم أنه يمكنني التحقق من تجربة ما يقرب من 50٪ من جمهورنا في المملكة المتحدة فقط عن طريق الاختبار في Chrome (سطح المكتب) و Chrome (Android) و Safari (iOS 9). من ناحية أخرى ، إذا كان هدفي هو العثور على الأخطاء ، فأنا أرغب في إلقاء تطبيق الويب الخاص بي على المتصفحات الأكثر إشكالية التي يتعين علينا دعمها بنشاط: في حالتنا ، IE8 ومتصفح Android الأصلي 2.

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

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

ماذا تفعل عندما تجد خللًا متأخرًا في مرحلة اختبار الذيل الطويل؟

1. تجاهل الخطأ.
2. أصلح الخطأ وأتمنى ألا تكون قد كسرت أي شيء.
3. أصلح الخطأ وأعد الاختبار في جميع المتصفحات المختبرة مسبقًا.

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

لذلك نجد أنفسنا في موقف Catch-22: لتحقيق أقصى قدر من الكفاءة ، نريد إصلاح جميع الأخطاء قبل أن نبدأ الاختبار عبر المتصفحات ، لكن لا يمكننا معرفة الأخطاء الموجودة حتى نبدأ في الاختبار.

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

هجوم ثلاثي المراحل

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

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

يمكنك إحضار نفس الاستراتيجية العسكرية والانضباط للاختبار عبر المستعرضات:

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

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

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

الإعداد: تعرف على عدوك

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

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

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

تبسيط إحصائيات استخدام المتصفح

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

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

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

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

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

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

متصفحات سطح المكتب

المتصفحات المحمولة

المتصفحات داخل التطبيق

عند الانتهاء ، يجب أن يبدو جدول البيانات الخاص بك على هذا النحو قليلاً (تجاهل عمود "الأولوية" في الوقت الحالي - سنصل إلى ذلك لاحقًا):

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

أنت الآن جاهز للشروع في هجوم من ثلاث مراحل.

1. الاستطلاع: البحث عن الأخطاء الملغومة للمتصفح

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

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

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

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

فيما يلي قائمة مختصرة بالأشياء التي يمكنك القيام بها في متصفح التطوير الخاص بك لاكتشاف الأخطاء غير المرتبطة بالمتصفح:

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

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

يكون كسول. إصلاح الخلل المحاذية للمتصفح. ثم يمكننا الانتقال إلى المرحلة الثانية من الهجوم.

2. غارة: اختبر في المتصفحات عالية الخطورة أولاً

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

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

التحليل الإحصائي لتوزيع الأخطاء

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

لنفترض أننا نختبر المحتوى الخاص بنا بترتيب تصاعدي للمخاطر: متصفح منخفض المخاطر ، ومتصفح متوسط ​​المخاطر ، ومتصفح عالي المخاطر. إذا كان ذلك يساعدك على تصور ذلك ، فقد يتم تعيين هذه المتصفحات إلى Google Chrome و IE 9 و IE 6 على التوالي.

اختبار المتصفح منخفض المخاطر (Chrome) أولاً ، سنجد الخلل رقم 2 ونصلحه. عندما ننتقل إلى متصفح Medium Risk ، تم إصلاح الخطأ رقم 2 بالفعل ، لكننا اكتشفنا خطأً جديدًا: # 4. لقد قمنا بتغيير الكود الخاص بنا لإصلاح الخطأ - ولكن كيف يمكننا التأكد من أننا لم نكسر الآن شيئًا ما في متصفح منخفض المخاطر؟ لا يمكننا أن نكون متأكدين تمامًا ، لذلك يتعين علينا العودة والاختبار في ذلك المتصفح مرة أخرى للتحقق من أن كل شيء لا يزال يعمل كما هو متوقع.

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

الآن دعنا نفكر في ما كان سيحدث إذا اختبرنا المحتوى الخاص بنا بترتيب تنازلي للمخاطر.

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

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

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

إصلاح الخلل في المتصفحات السيئة يجعل شفرتك أكثر مرونة في المتصفحات الجيدة

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

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

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

تحديد المتصفحات الإشكالية

إذن ما هو المتصفح عالي الخطورة؟ الإجابة غامضة بعض الشيء وتعتمد على ميزات المتصفح التي يستخدمها تطبيقك. إذا كان JavaScript يستخدم indexOf ، فقد ينكسر في IE 8. إذا كان تطبيقك يستخدم position: fixed ، فستحتاج إلى التحقق منه في Safari على iOS 7.

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

الشيء المفيد بشأن الأخطاء التي تجدها في المتصفحات التي بها مشكلات هو أنها غالبًا ما تنتشر. إذا كان هناك خطأ في IE9 ، فمن المحتمل أن الخطأ موجود أيضًا في IE8. إذا كان هناك شيء يبدو غير تقليدي في Safari على نظام iOS 7 ، فمن المحتمل أن يبدو أكثر وضوحًا على iOS 6. هل لاحظت وجود نمط هنا؟ تميل المتصفحات القديمة إلى أن تكون مشكلة. من المفترض أن يساعدك ذلك في الوصول إلى قائمة جيدة من المتصفحات التي بها مشكلات.

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

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

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

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

نوّع متصفحاتك ذات المشاكل

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

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

على الرغم من أن هذه يمكن أن تختلف من مشروع إلى آخر ، فإليك المتصفحات التي أختارها حاليًا والتي بها مشكلات:

• IE 8 على جهاز Windows XP VM ؛
• متصفح Android 2 الأصلي على جهاز لوحي يعمل بنظام Android متوسط ​​المدى ؛
• Safari على iPhone 4 يعمل بنظام iOS 6 ؛
• Opera mini (فقط يستحق الاختبار مع المحتوى الذي يجب أن يعمل بدون JavaScript ، مثل datapics).

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

3. التخليص: فحص الصحة

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

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

تحديد أولويات المتصفحات

النهج البسيط والواضح الآن هو العودة إلى الاختبار التقليدي عبر المتصفحات ، من خلال معالجة كل متصفح بترتيب تنازلي لحصة السوق. إذا كان سطح مكتب Chrome يمثل أعلى نسبة من مشاركة متصفح جمهورك ، متبوعًا بـ Safari على نظام التشغيل iOS 8 ، يليه IE11 ، فمن المنطقي الاختبار بهذا الترتيب ، أليس كذلك؟

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

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

هذه شجرة قراراتنا:

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

كما ترى في جدول البيانات سابقًا في هذه المقالة ، لدينا عدد قليل من متصفحات P1. حقيقة أنه يمكننا التحقق من تجربة أكثر من 70٪ من جمهورنا بهذه السرعة تعني أنه ليس لدينا عذرًا كبيرًا لعدم إعادة الاختبار في تلك المتصفحات إذا تغيرت قاعدة التعليمات البرمجية. بينما ننتقل إلى متصفحي P2 و P3 ، يتعين علينا بذل جهد متزايد باستمرار للتحقق من تجربة حجم الجمهور المتناقص باستمرار ، لذلك يتعين علينا وضع نماذج اختبار أكثر واقعية للمتصفحات ذات الأولوية الأقل. كمبدأ توجيهي:

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

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

ملخص: هجوم ثلاثي المراحل

بمجرد بذل جهد لمعرفة عدوك ( تبسيط إحصائيات جمهورك وتجميع المتصفحات في الأولويات ) ، يمكنك الهجوم في ثلاث خطوات:

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