اختبار الويب على الهواتف المحمولة: دليل عملي للفرق الحديثة

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

اختبار الويب المحمول يحتاج إلى أخذ المسار الكامل بين الشخص والصفحة في الاعتبار: أجهزة الجهاز، محرك المتصفح، إدخال اللمس، سلوك عرض الشاشة، شبكة الناقل، الموقع، الكوكيز، DNS، توجيه CDN، والأداء تحت الضغط. مثلت حركة المرور المحمولة 58.7% من إجمالي حركة المرور على الويب في يوليو 2019، وبحلول عام 2022، أنتجت الأجهزة المحمولة حركة مرور أكثر من سطح المكتب على 88% من أفضل 1,000 موقع و89% من أفضل 10,000 موقع، وفقًا لـ دليل HTTP Archive Web Almanac. ومع ذلك، فقط 39% من المواقع قدمت تجارب جيدة في Core Web Vitals على الأجهزة المحمولة، و23% فقط من المواقع المحمولة كانت لديها تباين لوني كافٍ في ذلك التقرير.

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

لماذا يستحق اختبار الويب المحمول استراتيجية خاصة به

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

يكشف مثال الدفع الفرنسي عن عدة ثغرات في وقت واحد. يمكن أن يؤكد اختبار CSS الاستجابة أن النافذة تناسب عرض الشاشة، ومع ذلك يفوت سلوك الكوكيز الخاص بـ Safari الذي يمنع حالة الدفع من الاستمرار. يمكن لمتصفح سطح المكتب إكمال تدفق الدفع بينما يقوم Android WebView، الذي يختلف إصدار متصفحه عبر الأجهزة والمصنعين، بعرض مسار سكريبت مختلف. يمكن لمحاكي تقليد أبعاد الشاشة دون إعادة إنتاج شبكة ناقل IPv6 فقط، أو عدم استقرار الراديو، أو البرمجيات الوسيطة على جانب الناقل.

اجتياز التخطيط ليس رحلة مستخدم

يجيب التحقق من تصميم الاستجابة على سؤال مهم: هل يتكيف الواجهة مع هذا العرض؟ لا يجيب على ما إذا كان المستخدم يمكنه إكمال المهمة.

اختبر الإجراءات التي تحمل قيمة تجارية:

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

يمكن أن يغير منع التتبع الذكي في Safari سلوك الكوكيز والتخزين. يمكن أن يكشف تفتت Android WebView عن اختلافات في JavaScript والرسم لا يظهرها محرك سطح المكتب الوحيد. هذه ليست عيوب في التصميم، لذا فإن مقارنة لقطات الشاشة وحدها لن تلتقطها.

الناقل جزء من بيئة الاختبار

يمكن أن تؤثر شبكة الناقل على حل DNS، سمعة IP، إشارات تحديد الموقع الجغرافي، التوجيه، واختيار CDN. يعني NAT من الدرجة الناقلة أيضًا أن المشتركين غير المرتبطين يمكنهم مشاركة عنوان IPv4 عام، مما يجعل حظر IP العدواني محفوفًا بالمخاطر للخدمات التي تحاول فصل الأتمتة المشبوهة عن المستخدمين المحمولين الشرعيين. يحتفظ RFC 6598 بمساحة العنوان المشتركة المستخدمة لـ NAT من الدرجة الناقلة، بينما يوضح تحليل الوكيل المحمول العملي لماذا تعقد العناوين المشتركة للناقل قرارات الحظر.

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

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

المفاهيم الأساسية التي يجب أن يعرفها كل مختبر موبايل

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

عرض الشاشة وكثافة البكسل

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

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

عوامل المستخدم لا تخبر القصة كاملة

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

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

أهداف اللمس والإيماءات

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

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

WebViews وسياسات التخزين

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

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

مقارنة بين أساليب الاختبار اليدوي والآلي

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

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

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

حيث يكسب كل نهج مكانه

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

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

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

المحاكيات هي فلتر، وليست السلطة النهائية

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

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

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

الأداء و Core Web Vitals على الهاتف المحمول

يجب أن يبدأ اختبار أداء الهاتف المحمول ببيانات حقل، وليس درجة سطح المكتب. تجمع Google Search Console قياسات المستخدمين الحقيقيين حسب أكبر رسم محتوى، التفاعل مع الرسم التالي، والتحول التراكمي للتخطيط، مما يعطي الفرق نظرة على كيفية تصرف الصفحات خارج مختبر مسيطر عليه. تعرف وثائق Core Web Vitals LCP الجيد بأنه 2.5 ثانية أو أقل، يحتاج إلى تحسين من 2.5 إلى 4 ثوانٍ، وسئ فوق 4 ثوانٍ. بالنسبة لـ INP، 200 مللي ثانية أو أقل جيدة، بينما فوق 500 مللي ثانية سيئة.

الصورة الميدانية الموثقة للهاتف المحمول مثيرة للقلق. وجدت HTTP Archive تجارب Core Web Vitals جيدة على 39% فقط من مواقع الويب المحمولة في تقريرها لعام 2022. وهذا يجعل بيانات الحقل المحمولة إشارة للإصدار، وليس زينة للتقارير.

بناء حالة مختبر قابلة للتكرار

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

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

يفصل الجدول عمدًا بين عتبات الحقل من المؤشرات الداعمة. يساعد TTFB وإجمالي وقت الحظر في تشخيص المشكلة، لكنهما لا يحلان محل Core Web Vitals الميدانية.

اقرأ الشلال، ثم أكد على الأجهزة

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

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

استخدم حلقة منضبطة:

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

اختبار يعتمد على الجغرافيا والشبكة وIP باستخدام بروكسيات الهاتف المحمول

قد يغير اختبار الجغرافيا على سطح المكتب فقط موقع IP الظاهر. يمكن أن تعتمد رحلة الهاتف المحمول أيضًا على ASN الناقل، سلوك NAT المشترك، محلل DNS، حافة CDN، مسار IPv4 أو IPv6، والدولة أو الناقل المختار. اختبر تلك الظروف معًا عندما تتعلق المسألة التجارية بالتوطين، التحكم في الوصول، التسليم، أو سلوك الشبكة المحدد.

يحدد ASN، أو رقم النظام المستقل، المشغل الذي يتحكم في كتلة IP. يخرج بروكسي الهاتف المحمول عبر اتصال خلوي، لذا يمكن أن ترى الوجهة ASN الناقل المحمول بدلاً من ASN السحابة أو الاستضافة. يضع NAT من الدرجة الناقلة، أو CGNAT، العديد من المشتركين غير المرتبطين خلف عناوين IPv4 العامة المشتركة. لذلك، يمكن أن تؤثر كتلة موجهة لجلسة مشبوهة واحدة على مستخدمي الهواتف الحقيقيين على نفس الناقل. يشرح شرح CGNAT ونظرة عامة على بصمة الهاتف المحمول هذه المشكلة المتعلقة بالعناوين المشتركة بمصطلحات عملية.

استخدم سير عمل شبكة متحكم فيه

كرر نفس الإعداد قبل كل تشغيل:

1. اختر الموقع المستهدف: حدد الدولة وعند الحاجة، ASN الناقل.
2. اختر نقطة النهاية المحمولة: استخدم نقطة نهاية 4G أو 5G متنقلة تتناسب مع سياق الناقل المقصود. Evoproxy هو خيار واحد لاختبار الشبكة المحمولة الفرنسية عندما يتطلب التدفق مسار ناقل فرنسي.
3. حدد شروط المتصفح: طبق وكيل المستخدم المقصود، وواجهة العرض، واللغة، والمنطقة الزمنية، وتكوين اللمس.
4. منع التسريبات: قم بتعطيل مسارات WebRTC التي قد تكشف عن عنوان محلي آخر، ثم تحقق من أن كل طلب يستخدم الوكيل المقصود.
5. تحقق من الخروج: سجل عنوان IP المرئي، وASN، والدولة، ومحلل DNS قبل بدء السيناريو.
6. اختر سلوك الجلسة: احتفظ بجلسة ثابتة لتسجيل الدخول، أو الخروج، أو الموافقة، أو مراجعة الإعلانات. استخدم التدوير المتحكم فيه لمهام المراقبة التي تتطلب جلسات منفصلة.

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

مطابقة الشبكة مع السؤال التجاري

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

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

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

خطة اختبار ويب محمولة نموذجية وقائمة التحقق قبل الإصدار

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

سبع مراحل لمرشح الإصدار

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

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

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

الأداء: قم بالتقاط حالة الحقل المحمول، وأعد إنتاج الفشل تحت ظروف الشبكة والـ CPU المقيدة، وتفقد LCP، وINP، وCLS، وTTFB، وTotal Blocking Time. سجل فئة الجهاز، والمسار، وحالة التخزين المؤقت، وملف تعريف الاختبار مع كل نتيجة.

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

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

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

قائمة تحقق تناسب تذكرة

الصق هذه العناصر القابلة للتحقق في Jira أو GitHub:

• تغطية الجهاز: اختبر فئات الأجهزة المدعومة لنظامي iOS وAndroid.
• تغطية المتصفح: قم بتشغيل Safari وChrome المحمولين بشكل مستقل على Android.
• تغطية WebView: تحقق من كل مسار متصفح مضمن يستخدمه المنتج.
• سلوك واجهة العرض: أكد علامة الميتا الخاصة بواجهة العرض ونقاط الانكسار المتجاوبة.
• كثافة البكسل: تحقق من حدة الصورة وعرض النص على الشاشات عالية الكثافة.
• أهداف اللمس: تحقق من أن عناصر التحكم الأساسية توفر على الأقل 44 بكسل CSS في 44.
• الإيماءات: اختبر السحب، والتمرير، وقفل التمرير، وسلوك القرص، والضغط الطويل حيثما ينطبق.
• الاتجاه: قم بالتدوير أثناء التحميل، والنماذج، والخروج، وتشغيل الوسائط.
• المناطق الآمنة: تحقق من الشقوق، والزوايا المدورة، وإدخالات المتصفح أو الجهاز السفلي.
• لوحة المفاتيح: اختبر التركيز، والملء التلقائي، والتحقق، وإغلاق لوحة المفاتيح.
• الحالة غير المتصلة: أكد الرسائل المفيدة والاسترداد الآمن بعد إعادة الاتصال.
• الروابط العميقة: تحقق من سلوك نقل التطبيق والعودة.
• مسارات الدفع: تحقق من الإذن، ومعالجة التسليم، وتوجيه الوجهة حيثما تم استخدامه.
• الدفع: قم بعرض وإكمال ورقة الدفع على المتصفحات المحمولة المستهدفة.
• الكوكيز: تحقق من الموافقة، والمصادقة، وحالة السلة، وإعادة التوجيه.
• اللغة: اختبر اللغة، والعملة، والتاريخ، والمحتوى الإقليمي.
• الشبكة: قم بتشغيل سيناريوهات مستقرة، ومقيدة، ومقطوعة، وشبكة الناقل.
• الجغرافيا: تحقق من سلوك الدولة والناقل من خلال نقطة نهاية متنقلة معتمدة.
• حالة الوكيل: سجل عنوان IP الخارج، وASN، ومحلل DNS، ووضع الجلسة.
• منع التسريبات: تحقق من WebRTC ومسارات أخرى للكشف غير المقصود عن الشبكة.
• LCP: سجل حالة الحقل وأعد إنتاج الفشل المحمول في المختبر.
• INP: قم بتجربة الكتابة، والتصفية، والقوائم، وتفاعلات الخروج.
• CLS: أعد التحميل مع الموافقة، والتخصيص، واللافتات، والصور المتأخرة.
• الوصول: تحقق من التباين، وترتيب التركيز، والتكبير، والتسميات، والمعالم.
• التراجع: أكد مالك النشر، ومحفز التراجع، ومسار الاسترداد.

جمع كل شيء معًا وتجنب الأخطاء الشائعة

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

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

اجعل المصفوفة مرتبطة بالأدلة

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

راقب هذه الأخطاء المحددة:

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

عادة الإصدار: سجل الحالة الأولى التي كشفت عن العيب، وليس فقط عنوان العيب. "فشل الخروج" أقل فائدة من "فشل الخروج على متصفح سفاري المحمول، مسار مزود الخدمة الفرنسي، استؤنف بعد الخلفية."

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

يوفر Evoproxy اتصال 4G/LTE المحمول مع خيارات توجيه موجهة نحو البلد ومزود الخدمة، والتحكم في الجلسات، والوصول عبر HTTP أو SOCKS5 لاختبار ضمان الجودة القائم على المتصفح، والتحقق من الإعلانات، والبحث المحلي، وغيرها من سير العمل المعتمدة للاختبار. قم بزيارة Evoproxy لتقييم إعداد وكيل المحمول الذي يتناسب مع ظروف الشبكة المستهدفة الخاصة بك وإضافة فحوصات جغرافية قابلة للتكرار إلى عملية اختبار الويب على الهاتف المحمول الخاصة بك.