تختبر الفريق التطبيق طوال دورة السبرينت، وتصدر النسخة - وبعد أسبوع تتدفق الشكاوى إلى الدعم: "في مدينتي السعر مختلف"، "الإشعار لم يصل"، "لا أستطيع الدفع بالبطاقة". السبب دائمًا واحد تقريبًا: جميع الاختبارات تمت من خلال IP مؤسسي واحد، بينما يدخل المستخدمون الحقيقيون من مناطق وشبكات ومشغلين آخرين. في هذه المقالة، سنستعرض 7 سيناريوهات QA محددة، والتي من المستحيل فحصها بدون تغيير عنوان IP، وسنوضح كيفية إعداد بنية تحتية للاختبار باستخدام الوكيل.
لماذا يعتبر IP المكتبي منطقة عمياء لـ QA
معظم تطبيقات الهواتف المحمولة اليوم تتخذ قرارات بناءً على عنوان IP: تحدد بلد المستخدم، لغة الواجهة، العملة، طرق الدفع المتاحة، مجموعة الميزات وحتى سعر الاشتراك. عندما يختبر قسم QA بالكامل من مكتب واحد مع IP ثابت من مركز بيانات أو شبكة مؤسسية، يحصل التطبيق دائمًا على نفس الرد من الخلفية - كما لو كان جميع المختبرين في نقطة واحدة من العالم.
نتيجة لذلك، الأخطاء التي تعتمد على الموقع الجغرافي، أو الوقت في المنطقة الزمنية، أو مشغل الاتصالات، أو نوع الاتصال، لا تتكرر ببساطة في بيئة الاختبار. تظهر فقط في الإنتاج - عندما يرى المستخدم من كازاخستان الأسعار بالروبل، أو لا يحصل المستخدم الألماني على إشعار بسبب حجب GCM في شبكته، أو لا يستطيع العميل الإندونيسي الدفع بالبطاقة لأن مزود الدفع لمنطقته غير متصل. تصحيح مثل هذا الخطأ بعد الإصدار يكلف أضعاف ما يكلفه اكتشافه في مرحلة QA.
الحل هو محاكاة التنوع الجغرافي والشبكي الحقيقي للمستخدمين قبل الإصدار. لهذا السبب، يستخدم مهندسو QA بشكل متزايد خوادم الوكيل: فهي تسمح "بنقل" جهاز الاختبار أو المحاكي إلى أي بلد أو مدينة أو حتى مشغل اتصالات دون الحاجة إلى السفر فعليًا إلى هناك أو شراء عشرات بطاقات SIM.
السيناريو 1: المحتوى الجغرافي والأسعار الإقليمية
معظم التطبيقات التي تقدم اشتراكات (بث، لياقة بدنية، تعليم) تظهر أسعارًا مختلفة في دول مختلفة - وهذا ما يسمى بتحديد الأسعار الجغرافي. إذا كان QA يتحقق من عملية الاشتراك فقط من خلال IP محلي، فلا يمكن التأكد من أن السعر للمستخدم من تركيا أو البرازيل أو الهند يتم عرضه بشكل صحيح، بالعملة الصحيحة ومع التقريب الصحيح.
نفس المشكلة مع كتالوجات المحتوى: مكتبة الأفلام أو المنتجات أو العروض غالبًا ما تكون إقليمية. يجب "الظهور" فعليًا في البلد المطلوب لرؤية نفس الشاشة التي يراها المستخدم الحقيقي. من الملائم استخدام الوكلاء السكنية لهذا النوع من الفحوصات - حيث تعطي IP لمستخدمين حقيقيين من بلد معين، وتعتبر الخلفية الطلب كحركة عضوية عادية، وليس كطلب من مركز بيانات.
تحقق عملي: نقوم بتشغيل سيناريو الاشتراك في 8-10 أسواق رئيسية (الولايات المتحدة، ألمانيا، البرازيل، الهند، تركيا، اليابان، نيجيريا، الإمارات العربية المتحدة)، نلتقط لقطات شاشة للأسعار والعملات، ونتحقق من قائمة أسعار المنتج. هذا يغطي معظم الشكاوى من نوع "لماذا لدي سعر مختلف".
السيناريو 2: الحجب الجغرافي وقيود الوصول
تطبيقات التكنولوجيا المالية، خدمات البث وبعض الألعاب تحجب الوصول من دول معينة لأسباب قانونية أو ترخيص. يجب على QA التأكد من أن التطبيق يعمل حيث ينبغي، وأيضًا أنه يرفض الوصول بشكل صحيح (وليس مع تعطل) حيث لا ينبغي.
خطأ نموذجي: بدلاً من الشاشة الأنيقة "الخدمة غير متاحة في منطقتك"، يرى المستخدم شاشة بيضاء أو محمل لا نهائي - لأن المطورين اختبروا فقط المسار السعيد من دولة مسموح بها. يتطلب فحص الحجب الجغرافي اتصالًا متسلسلًا من عدة ولايات محظورة، وهو ما لا يمكن تحقيقه باستخدام بطاقات SIM الحية والرحلات، بينما يستغرق عبر الوكيل 10-15 دقيقة لكل دولة.
لهذا السيناريو، تناسب الوكلاء مع تحديد جغرافي دقيق على مستوى المدينة، وليس فقط الدولة - من المهم التحقق ليس من "ألمانيا بشكل عام"، ولكن من أراضٍ محددة، إذا كانت الترخيص مقيدة بمنطقة داخل الدولة.
السيناريو 3: A/B وإطلاقات تدريجية حسب الدول
يتم إعداد علامات الميزات وإطلاقات تدريجية تقريبًا دائمًا مع الربط بالموقع الجغرافي: يتم تفعيل الميزة الجديدة أولاً في كندا، وبعد أسبوع في أستراليا، ثم في كل مكان. إذا كانت فريق QA موجودًا فعليًا في دولة واحدة، فلا يمكنهم في الأساس رؤية النسخة الجديدة قبل بقية المناطق، حتى تصل العلامة إليهم.
لاختبار الميزة قبل الإصدار العالمي، يجب تغيير الموقع الجغرافي إلى دولة المرحلة الأولى من الإطلاق. هذه واحدة من أكثر المهام شيوعًا التي تحلها الوكلاء بالتعاون مع متصفحات مكافحة الكشف أو محاكيات الأجهزة - نقوم بتغيير IP إلى الدولة المطلوبة، وإعادة تشغيل جلسة التطبيق، ونرى الميزة قبل المستخدمين الآخرين ونتمكن من العثور على الأخطاء قبل أن تصل العلامة إلى 100% من الجمهور.
نقطة مهمة: لاختبارات A/B، تحتاج إلى "تسجيل" ثابت لـ IP طوال دورة الاختبار - يجب ألا تتنقل الجلسة بين الدول بين الطلبات، وإلا ستختلط الخلفية بين شروط التجربة وتظهر إما المجموعة الضابطة أو التجريبية.
السيناريو 4: التوطين والإشعارات
يعتمد نص الإشعار، ووقت إرساله، وحتى حقيقة التسليم غالبًا على الموقع الجغرافي للجهاز. في بعض الدول، تعمل مزودات الإشعارات (Firebase، APNs، بوابات SMS المحلية) مع تأخيرات أو عبر مسارات بديلة - وما يتم تسليمه بشكل ممتاز في بيئة الاختبار من المكتب في موسكو، قد لا يصل إلى المستخدم في إندونيسيا بسبب حجب مزودي الإشعارات المحددين من قبل مزود الاتصالات المحلي.
أيضًا، يتم تحفيز توطين الواجهة غالبًا بناءً على IP، وليس فقط على لغة النظام: يمكن أن يرى المستخدم الذي لديه لغة هاتف إنجليزية، ولكن IP من فرنسا، واجهة مختلطة - عناوين باللغة الفرنسية، وأزرار باللغة الإنجليزية. هذه الأخطاء غير مرئية بنسبة 100% إذا كان جميع QA يختبرون من منطقة جغرافية واحدة.
العملية الموصى بها: نأخذ 5-7 لغات من الأسواق ذات الأولوية للمنتج، ونتصل عبر الوكيل مع IP المناسب، ونغير لغة النظام على الجهاز/المحاكي ونسجل النصوص وأشكال التواريخ/الأرقام التي يعرضها التطبيق. عدم تطابق IP الدولة ولغة النظام هو حالة إلزامية منفصلة، وغالبًا ما يتم نسيانها.
السيناريو 5: طرق الدفع وأنظمة مكافحة الاحتيال
مجموعة طرق الدفع المتاحة في تطبيق الهاتف المحمول تعتمد تقريبًا دائمًا على الدولة: في منطقة واحدة، يتوفر الدفع بالبطاقة وApple Pay، في أخرى - فقط المحافظ المحلية (Mercado Pago، Boleto، UPI، QIWI)، وفي ثالثة - الدفع عبر مشغل الاتصالات. إذا لم يتمكن QA من الاتصال من الدولة المطلوبة، فإن نصف سيناريوهات الدفع تبقى غير مختبرة حتى الإنتاج، حيث ثمن الخطأ هو فقدان الإيرادات والشكاوى إلى الدعم.
ألم منفصل - أنظمة مكافحة الاحتيال لمزودي الدفع. يقومون بتقييم مخاطر المعاملة أيضًا بناءً على IP: الطلب من IP مركز البيانات سيحصل تقريبًا على رفض أو تحقق إضافي 3D-Secure، حتى لو كانت البطاقة صالحة تمامًا. هذا يشوه نتائج الاختبار: يرى QA رفض الدفع ويبلغ عن خطأ للمطورين، على الرغم من أن المشكلة ليست في الكود، بل في أن IP الاختبار يبدو مشبوهًا لتقييم مكافحة الاحتيال.
لسيناريوهات الدفع، من الأفضل استخدام الوكلاء السكنية أو الوكلاء المحمولة - فهي تبدو كحركة طبيعية لمستخدم حقيقي ولا تحفز تفعيل أنظمة مكافحة الاحتيال، مما يعطي صورة أكثر دقة لسلوك تدفق الدفع.
السيناريو 6: السلوك في الشبكات المحمولة للمشغلين
يمكن أن يعمل التطبيق بشكل ممتاز في Wi-Fi المكتبي بسرعة 200 ميجابت في الثانية، لكنه قد يتصرف بشكل مختلف تمامًا في شبكة المحمول 3G/4G مع اتصال غير مستقر، وNAT-Proxy من المشغل وزمن تأخير مرتفع. يجب التحقق من مهلات الطلبات، وإعادة المحاولات، وتدهور جودة الفيديو/الصوت، وعمل وضع عدم الاتصال - كل ذلك يجب التحقق منه في ظروف قريبة من الإنترنت المحمول، وليس في شبكة مكتبية مستقرة.
تعقيد إضافي: بعض مشغلي الاتصالات يستخدمون وكلاء وCGNAT خاصين بهم، مما يجعل الخادم يرى ليس IP الحقيقي للمستخدم، بل IP مشترك للمشغل، يمر عبره الآلاف من المشتركين في نفس الوقت. يؤثر هذا على تحديد المعدلات والموقع الجغرافي بناءً على IP - قد "يعتقد" التطبيق أن المستخدم موجود في مدينة أخرى غير المدينة التي هو فيها فعليًا.
لإعادة إنتاج هذا السلوك، تحتاج إلى وكلاء محمولين، يتصلون بالإنترنت عبر بطاقات SIM حقيقية من المشغلين في الدولة المطلوبة - مما يعطي صورة دقيقة عن NAT، وزمن التأخير، والسرعة، والتي لا يمكن الحصول عليها من IP مركز البيانات العادي.
السيناريو 7: تحديد المعدلات والحماية من الروبوتات
العديد من واجهات برمجة التطبيقات الخلفية لتطبيقات الهواتف المحمولة تحد من عدد الطلبات من IP واحد (تحديد المعدلات) وتستخدم حماية ضد الروبوتات، مشابهة لـ CAPTCHA أو التحليل السلوكي. إذا كانت فريق QA يقوم بتشغيل اختبارات تلقائية من IP مؤسسي واحد، بعد فترة، يبدأ الخادم في الرد بأخطاء 429 أو حظر الطلبات تمامًا - وتفشل الاختبارات ليس بسبب خطأ في التطبيق، بل لأن الخلفية اعتبرت حركة الاختبار هجومًا.
هذا مهم بشكل خاص للاختبارات التحميلية والرجعية، عندما تحتاج إلى تنفيذ مئات الطلبات المتماثلة في فترة قصيرة (تسجيل، تسجيل دخول، إضافة إلى السلة). توزيع الطلبات بين IPs مختلفة عبر مجموعة من الوكلاء يسمح بتحميل واجهة برمجة التطبيقات بشكل عادل دون تشويه النتائج بسبب تفعيل حماية مكافحة الاحتيال.
للاختبار الآلي الجماعي، غالبًا ما يكون من الأفضل استخدام وكلاء مراكز البيانات - فهي أسرع وأرخص عند كميات كبيرة من الطلبات، ولا يكون التحديد الجغرافي في هذا السيناريو حرجًا مثل السرعة والاستقرار في الاتصال.
الأدوات وإعداد الوكيل لـ QA
لإجراء QA يدوي على المحاكيات (محاكي Android Studio، محاكي Xcode)، يتم إعداد الوكيل من خلال إعدادات الشبكة للنظام: تحدد IP ورقم منفذ خادم الوكيل، واسم المستخدم وكلمة المرور إذا كانت هناك حاجة للمصادقة. بالنسبة للأجهزة الحقيقية، تتوفر إعدادات مماثلة في اتصال Wi-Fi من خلال "الإعدادات المتقدمة → الوكيل → يدوي".
لالتقاط وتحليل الحركة بين التطبيق والخلفية، يستخدم مهندسو QA Charles Proxy أو Proxyman - كلا الأداتين تسمحان بتمرير حركة التطبيق عبر وكيل خارجي ورؤية جميع الطلبات HTTP/HTTPS، ورؤوس الموقع الجغرافي، واستجابات الخادم في نفس الوقت. هذا مفيد للتشخيص: من السهل رؤية أي IP وأي بلد "يراه" الخلفية في لحظة الطلب.
للاختبار الآلي عبر Appium أو Espresso، يتم تحديد الوكيل في القدرات المطلوبة للجلسة أو من خلال إعدادات النظام للجهاز قبل بدء مجموعة الاختبار. تدعم المنصات السحابية لاختبار تطبيقات الهواتف المحمولة (BrowserStack، Sauce Labs) أيضًا الاتصال بوكلاء مخصصين، مما يسمح بتشغيل نفس سيناريو الاختبار التلقائي من دول مختلفة دون الحاجة إلى أجهزة فعلية في كل نقطة في العالم.
إذا كان هناك إصدار ويب من التطبيق في الفريق أو إذا كان من الضروري اختبار عدة حسابات مع مواقع جغرافية مختلفة في نفس الوقت، فمن الملائم استخدام متصفحات مكافحة الكشف (Dolphin Anty، AdsPower، Multilogin) - حيث يتم ربط كل ملف تعريف بوكلاء منفصلين، ويمكن لمهندس QA الاحتفاظ بـ 5-10 جلسات مفتوحة من دول مختلفة في نفس الوقت دون ارتباك في الكوكيز والذاكرة المؤقتة.
ما هو نوع الوكيل الذي يجب اختياره لكل سيناريو
| سيناريو QA | نوع الوكيل الموصى به | لماذا |
|---|---|---|
| الأسعار الجغرافية والمحتوى | سكنية | تبدو كحركة مستخدم عادي، لا تحفز حماية ضد الروبوتات |
| الحجب الجغرافي | سكنية | تحديد جغرافي دقيق على مستوى المدينة/المنطقة |
| A/B والإطلاقات | سكنية / مركز البيانات | جلسة مستقرة طوال دورة الاختبار |
| الإشعارات والتوطين | محمولة | تعكس الظروف الحقيقية للتسليم عبر المشغلين |
| المدفوعات ومكافحة الاحتيال | سكنية / محمولة | مخاطر منخفضة من تفعيل خاطئ لأنظمة مكافحة الاحتيال |
| الشبكات المحمولة للمشغلين | محمولة | بطاقات SIM حقيقية من المشغلين، محاكاة دقيقة لـ NAT وزمن التأخير |
| تحديد المعدلات / اختبارات التحميل | مراكز البيانات | سرعة عالية وتكلفة منخفضة عند كميات كبيرة من الطلبات |
قائمة التحقق قبل الإصدار
قبل إطلاق النسخة في الإنتاج، قم بمراجعة قائمة قصيرة من الفحوصات المتعلقة بالموقع الجغرافي والشبكة - فهذا يغطي معظم الأخطاء المذكورة أعلاه:
- تم التحقق من الأسعار وعملة الاشتراك على الأقل في 5 أسواق رئيسية للمنتج
- تم التحقق من العرض الصحيح لشاشة الحجب الجغرافي في الدول المحظورة
- تم اختبار علامة الميزات في دولة المرحلة الأولى من الإطلاق قبل الإصدار العالمي
- تم التحقق من الإشعارات مع IP ولغة النظام من تركيبات دول مختلفة
- تم التحقق من طرق الدفع المتاحة لكل منطقة رئيسية بشكل منفصل
- تم اختبار تدفق الدفع بدون تفعيل خاطئ لأنظمة مكافحة الاحتيال
- تم اختبار التطبيق في ظروف الشبكة المحمولة (3G/4G)، وليس فقط Wi-Fi
- لا تفشل الاختبارات التلقائية بسبب تحديد المعدلات عند التشغيل المتوازي من IP واحد
الخاتمة
يعيش تطبيق الهاتف المحمول في عشرات الدول والشبكات والأنظمة البيئية للدفع في نفس الوقت، بينما يجلس فريق QA فعليًا في مكتب واحد مع IP واحد. هذا الفجوة بين الجمهور الحقيقي وظروف الاختبار هي التي تولد معظم الأخطاء "غير المفسرة" التي تصل إلى الإنتاج. السيناريوهات السبعة أعلاه - الأسعار الجغرافية، الحجب الجغرافي، إطلاقات A/B، الإشعارات والتوطين، المدفوعات، الشبكات المحمولة للمشغلين وتحديد المعدلات - تغطي الجزء الرئيسي من هذه المخاطر.
إذا كانت فريقك تختبر تطبيقًا يعمل مع المحتوى الإقليمي، أو الأسعار، أو المدفوعات، فمن الحكمة تضمين الوكلاء السكنية في مجموعة الاختبار لمحاكاة المستخدمين الحقيقيين، وللسيناريوهات المتعلقة بالاتصالات المحمولة وتسليم الإشعارات - الوكلاء المحمولة المرتبطة بمشغلين محددين. هذا يسمح بالعثور على الأخطاء الحرجة في مرحلة QA، وليس بعد شكاوى المستخدمين في المتاجر.