اختبار تطبيقات الجوال: دليل عملي

ما الذي يجعل اختبار الجوال مختلفاً

يعمل تطبيق الويب في متصفحات يستطيع الفريق حصرها، وعلى شبكة يستطيع الفريق افتراض استقرارها غالباً. أما تطبيق الجوال فيعمل على عتاد لا يتحكم فيه الفريق، تحت نظام تشغيل يدير حياته: النظام هو من يقرر متى يُوقَف التطبيق مؤقتاً، ومتى يُنهى لتحرير الذاكرة، ومتى يُسمح له باستخدام الشبكة في الخلفية، وأي البيانات يحق له قراءتها. ويتناول منهج ISTQB لاختبار تطبيقات الجوال (CT-MAT) هذه الأمور بوصفها التحديات الخاصة بالجوال: تنوّع الأجهزة والمنصات، والاتصال، ومحدودية الموارد، والطرق التي يستخدم بها الناس جهازاً يحملونه في كل مكان.

وبلغة ISO/IEC 25010، يرفع الجوال وزن التوافقية (التعايش مع التطبيقات الأخرى ومع النظام)، والموثوقية تحت المقاطعة، وكفاءة الأداء (البطارية والذاكرة والبيانات)، وقابلية التفاعل (الشاشات الصغيرة واللمس والاستخدام بيد واحدة)، والأمان (جهاز قد يُفقد أو يُشارَك أو يُكسر حمايته). يجب أن تبيّن استراتيجية اختبار الجوال كيف يُغطّى كل واحد من هذه الجوانب، لا أن تكتفي بالسؤال عمّا إذا كانت الميزات تعمل.

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

الأصلي ومتعدد المنصات والهجين والويب وPWA

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

• التطبيقات الأصلية (Native apps) — تُكتب لمنصة واحدة بحزمة تطويرها الخاصة (Kotlin أو Java على Android، وSwift أو Objective-C على iOS). لها وصول كامل إلى ميزات الجهاز، وتعمل أُطر اختبار المنصة (Espresso وXCUITest) عليها مباشرة. عامل كل منصة كمنتج مستقل يتشارك المتطلبات.
• التطبيقات متعددة المنصات (Cross-platform) — قاعدة شيفرة واحدة تُبنى للمنصتين (مثلاً باستخدام React Native أو Flutter). منطق العمل مشترك، لكن العرض والأذونات ولوحات المفاتيح والتكامل مع المنصة تبقى مختلفة، فكل منصة تحتاج جولة اختبار واجهة خاصة بها.
• التطبيقات الهجينة (Hybrid apps) — غلاف أصلي يستضيف محتوى ويب داخل WebView. اختبر نقطة الالتقاء: التنقل بين الشاشات الأصلية وشاشات الويب، ومشاركة الجلسة وملفات تعريف الارتباط، وزر الرجوع، ورفع الملفات والوصول إلى الكاميرا من محتوى الويب، وما يراه المستخدم عندما يفشل تحميل محتوى الويب.
• ويب الجوال (Mobile web) — موقع يُستخدم في متصفح الجوال. افحص التخطيط المتجاوب، وأهداف اللمس، ومنفذ العرض والتكبير، وتغطية لوحة المفاتيح للحقول، والفروق بين محركات متصفحات الجوال. وسلاسل وكيل المستخدم (User-Agent) في تحليلاتك تبيّن المتصفحات التي يأتي بها المستخدمون فعلاً؛ لكن كثيراً من المتصفحات صارت تقلّص إصدار النظام وطراز الجهاز في هذه السلسلة أو تثبّتهما (مثل Chrome على Android)، فخذ إصدارات الأنظمة وطرازات الأجهزة من User-Agent Client Hints أو من أداة التحليلات في تطبيقك.
• تطبيقات الويب التقدمية (PWA) — تطبيقات ويب لها ملف بيان (Web app manifest) وعامل خدمة (Service worker)، يمكن تثبيتها على الشاشة الرئيسية والعمل دون اتصال. اختبر قابلية التثبيت، والسلوك دون اتصال، وتحديث الذاكرة المؤقتة (هل يحل الإصدار الجديد محل المخزّن؟)، والإشعارات الفورية حيث تدعم المنصة إشعارات الويب لتطبيقات الويب المثبتة.

جرّبها: محلّل User-Agent

تجزؤ الأجهزة وإصدارات الأنظمة والشاشات

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

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

• حجم الشاشة ونسبة الأبعاد — هواتف صغيرة، وهواتف طويلة، وأجهزة لوحية، وأجهزة قابلة للطي مطوية ومفتوحة، وتقسيم الشاشة وتعدد النوافذ.
• الكثافة — تستخدم التخطيطات وحدات مستقلة عن الكثافة (dp على Android وpoints على iOS)؛ افحص الصور بحثاً عن الضبابية والنصوص بحثاً عن القص في الكثافات المنخفضة والعالية.
• القواطع وأشرطة النظام — محتوى مخفي تحت شريط الحالة أو فتحة الكاميرا أو مؤشر الشاشة الرئيسية.
• الاتجاه — العمودي والأفقي والتدوير نفسه: هل تحتفظ الشاشة بحالتها وبما أدخله المستخدم؟ ويشترط معيار نجاح WCAG 2.2 رقم 1.3.4 الاتجاه (Orientation) ألا يُقيَّد المحتوى باتجاه واحد إلا إذا كان ذلك الاتجاه ضرورياً.
• السلوك المتجاوب — في ويب الجوال وPWA افحص نقاط التوقف ومنفذ العرض والتمرير الأفقي والتكبير؛ وفي التطبيقات تأكد أن التخطيط يتكيف بدلاً من أن يتمدد.
• طبقات الشركات المصنّعة — تحسين بطارية شديد، وشاشات أذونات مخصصة، وحوارات نظام معدّلة على بعض أجهزة Android.

استراتيجية الأجهزة: المحاكيات والأجهزة الحقيقية ومزارع الأجهزة

لا يستطيع أي فريق الاختبار على كل جهاز، فاستراتيجية الأجهزة قرار مبني على المخاطر. وهي تجيب عن ثلاثة أسئلة: أي البيئات مهمة (من البيانات لا من الآراء)، وأي نوع من الأجهزة يحتاجه كل اختبار، وكم مرة تُختبر كل تركيبة.

محاكيات Android (Emulators) ومحاكيات iOS (Simulators) سريعة ومجانية وقابلة للبرمجة — مثالية للتطوير ولخط التكامل المستمر (CI). لكنها لا تعيد إنتاج كل شيء: الأداء والسلوك الحراري الحقيقيين، واستنزاف البطارية، والكاميرا والمستشعرات، وعتاد القياسات الحيوية، والشبكات الخلوية، وتخصيصات الشركات المصنّعة، وأجزاء من مسار الإشعارات الفورية. ومحاكي iOS ليس محاكياً للعتاد أصلاً: فهو يشغّل تطبيقاً مبنياً للحاسوب المضيف، فيكون أبعد عن عتاد الجهاز الحقيقي. الأجهزة الحقيقية ضرورية قبل الإصدار للأداء والبطارية والكاميرا وBluetooth وNFC والمدفوعات والقياسات الحيوية وكل ما يمس طبقة الشركة المصنّعة. أما مزارع الأجهزة السحابية (Device farms) فتؤجّر أجهزة حقيقية (ومحاكيات) عن بُعد لتشغيل حزم آلية أو جلسات يدوية — تغطية واسعة دون شراء مختبر وصيانته.

ابنِ مصفوفة الأجهزة من تحليلاتك أنت: اسرد إصدارات الأنظمة وطرازات الأجهزة وفئات الشاشات، وفي ويب الجوال المتصفحات، مرتبةً حسب حصتها من المستخدمين النشطين. غطِّ الأجهزة التي تحمل معظم حركتك، وأقدم إصدار نظام ما زلت تدعمه، وأحدث إصدار (ونسخته التجريبية)، وشاشة صغيرة وأخرى كبيرة، وأي عائلة أجهزة تسببت في حوادث. ثم اجمع بقية المعاملات — اللغة والاتجاه والشبكة وحجم الخط — بالاختيار الثنائي (Pairwise) بدلاً من الضرب الكامل لكل التركيبات.

وفي المثال التوضيحي أدناه تُقسَّم المصفوفة إلى ثلاث طبقات. الطبقة 1 (Tier 1) أجهزة حقيقية تُختبر مع كل إصدار: الأجهزة التي تحمل أكبر حصة من الجلسات، وأقدم إصدار Android مدعوم على جهاز اقتصادي بشبكة بطيئة. والطبقة 2 (Tier 2) تُختبر أيضاً مع كل إصدار، على المحاكيات أو في مزرعة أجهزة: تكبير الخط إلى 200% مع واجهة RTL، وiPhone بشاشة صغيرة مع أكبر حجم Dynamic Type، وiPad بتقسيم الشاشة. والطبقة 3 (Tier 3) لا تُختبر إلا قبل الإصدارات الكبرى، في مزرعة أجهزة: بقية الطرازات التي تتجاوز حصتها 1% من الجلسات، وجهاز قابل للطي، وجهاز لوحي.

Example device matrix (illustrative; build yours from your analytics)

Tier 1 — every release, real devices
  Android latest   · Samsung mid-range · 6.4"  · ar-SA · 4G     (largest share of sessions)
  iOS latest       · iPhone standard   · 6.1"  · ar-SA · Wi-Fi
  Android oldest supported · budget device, 3 GB RAM · en-IN · slow 3G

Tier 2 — every release, emulators/simulators or device farm
  Android latest   · Pixel · font scale 200% · RTL
  iOS latest − 1   · small-screen iPhone · largest Dynamic Type size
  iPadOS latest    · Split View · landscape

Tier 3 — before major releases, device farm
  long tail: remaining models above 1% of sessions, one foldable, one tablet

Combination rule
  language × orientation × network × font size → pairwise set, not the full product

جرّبها: مولّد الاختبار الزوجي (Pairwise) جرّبها: محلّل User-Agent

ماذا تختبر على الجوال: خريطة المخاطر

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

• التثبيت والتحديث وإلغاء التثبيت — تثبيت نظيف، وتحديث من كل إصدار قديم مدعوم مع ترحيل البيانات، وإعادة التثبيت بعد الحذف، ومسح بيانات التطبيق، والنسخ الاحتياطي والاستعادة.
• الأذونات — الطلب الأول، والرفض، والرفض الدائم، والسحب من إعدادات النظام أثناء عمل التطبيق، والمنح لمرة واحدة.
• المقاطعات — المكالمات الواردة، والإشعارات، والمنبهات، والتبديل بين التطبيقات، وقفل الشاشة، وتحذيرات انخفاض البطارية، وإنهاء النظام للتطبيق في الخلفية.
• الشبكة — من Wi-Fi إلى الشبكة الخلوية والعكس، وانعدام الاتصال، ووضع الطيران، والاتصالات البطيئة والمتقطعة، وبوابات الشبكات المقيدة (Captive portals)، والتغييرات دون اتصال التي يجب أن تتزامن عند عودة الاتصال.
• الجهاز والعرض — أحجام الشاشات، والاتجاه، والوضع الداكن، وتكبير الخط، ولوحة المفاتيح على الشاشة، والإيماءات، والأجهزة القابلة للطي، وتعدد النوافذ.
• الموارد — استنزاف البطارية، والمعالج، والذاكرة (التسرب والإنهاء بسبب نقص الذاكرة)، والتخزين (امتلاء القرص وتضخم الذاكرة المؤقتة)، واستهلاك البيانات على الشبكة الخلوية.
• الإشعارات الفورية (Push notifications) — الوصول والتطبيق في المقدمة أو في الخلفية أو بعد إنهائه، والانتقال بالنقر إلى الشاشة الصحيحة، والسلوك عند تعطيل الإشعارات.
• إمكانية الوصول والتوطين والأمان والامتثال لمتطلبات المتجر — تُغطّى أدناه وفي أدلتها الخاصة.

Typical mobile defects (illustrative bug titles)

- Address form loses entered data after rotating the device (Android)
- App crashes on resume after camera permission is revoked in Settings (iOS)
- Order submitted twice when the network drops during "Place order" and the user retries
- Update from 3.8 to 4.0 signs every user out (stored session not migrated)
- Tapping an order notification opens the home screen instead of the order
- "Pay" button hidden behind the keyboard on small screens
- Checkout total truncated at the largest system font size
- Offline edits silently overwritten after reconnecting

جرّبها: مولّد سيناريوهات الاختبار جرّبها: مولّد انتقالات الحالات

الواجهة الخلفية للجوال: الواجهات البرمجية والإصدارات ومعالجة الأخطاء

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

مسألتان خاصتان بالجوال تستحقان اختبارات خاصة بهما. الأولى هي تفاوت الإصدارات: المستخدمون يحدّثون متأخرين، فيجب أن تستمر الواجهة الخلفية في خدمة كل إصدار ما زلت تدعمه، وكل تغيير في API يحتاج إلى فحص مقابل أقدم عميل مدعوم. والثانية هي الشبكة المعادية: الطلبات تُعاد وتتكرر وتنقطع في منتصفها. يجب أن تكون نقاط نهاية الطلبات والمدفوعات متساوية الأثر (Idempotent)، وأن يعرض التطبيق حالة واضحة عندما تكون نتيجة الطلب مجهولة.

• استدعِ كل نقطة نهاية يستخدمها التطبيق بحقول صحيحة وغير صحيحة وناقصة، وتحقق من الاستجابات مقابل المخطط.
• اجعل التطبيق يواجه الاستجابات 401 و403 و404 و409 و429 و500 و503 والاستجابات البطيئة؛ وافحص الرسالة والتعافي على الشاشة.
• دع رمز الوصول ينتهي والتطبيق في الخلفية، ثم استأنفه: يجب أن يجدّد التطبيق الرمز بصمت أو يطلب من المستخدم تسجيل الدخول، لا أن ينهار أو يدخل في حلقة.
• افحص أحجام الحمولات: الاستجابات الكبيرة تكلّف وقتاً وبيانات على الشبكات الخلوية.
• قبل كل إصدار للواجهة الخلفية، شغّل أقدم إصدار مدعوم من التطبيق عليها.

جرّبها: مختبِر REST API جرّبها: محاكي رموز حالة API جرّبها: مولّد استجابات خطأ وهمية جرّبها: محلّل حجم الاستجابة

إمكانية الوصول على الجوال

لمنصات الجوال تقنياتها المساعدة الخاصة، ويجب اختبار التطبيق بها: TalkBack على Android وVoiceOver على iOS (قارئا شاشة يُداران بالإيماءات)، والوصول بالمفاتيح البديلة (Switch access)، والتكبير، وتكبير نص النظام (حجم الخط على Android والنص الديناميكي Dynamic Type على iOS). وتنطبق WCAG 2.2 على محتوى الجوال كما على الويب — ومعايير نجاح مثل 1.3.4 الاتجاه (Orientation) و2.5.1 إيماءات المؤشر (Pointer Gestures) و2.5.8 حجم الهدف (الحد الأدنى) (Target Size (Minimum)) وثيقة الصلة بواجهات اللمس — وتضيف إرشادات Android وApple الخاصة بإمكانية الوصول توقعات ملموسة.

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

• لكل عنصر تفاعلي تسمية منطوقة ذات معنى، ودور، وحالة؛ والأزرار المكوّنة من أيقونة فقط هي الإخفاق المعتاد.
• ترتيب التنقل بالسحب في TalkBack أو VoiceOver يتبع الترتيب المرئي والمنطقي، بما في ذلك في التخطيطات من اليمين إلى اليسار.
• يكبُر النص مع إعداد النظام دون قص أو تداخل أو أزرار مبتورة؛ اختبر عند أكبر الأحجام.
• أهداف اللمس كبيرة بما يكفي ومتباعدة: تحدد إرشادات Apple للواجهات ‏44×44 نقطة حجماً افتراضياً لعناصر التحكم في iOS ‏(و28×28 نقطة حداً أدنى)، وتوصي إرشادات Android بما لا يقل عن 48×48 dp.
• للإيماءات المخصصة بديل بسيط مثل زر، ولا تعتمد أي وظيفة على هز الجهاز أو إمالته وحدهما.
• التباين يبقى كافياً في الوضعين الفاتح والداكن.

أمان الجوال: نظرة سريعة على MASVS وMASTG

يحدد معيار OWASP للتحقق من أمان تطبيقات الجوال (MASVS) ما يجب أن يفعله تطبيق الجوال الآمن، ويصف دليل OWASP لاختبار أمان تطبيقات الجوال (MASTG) كيفية التحقق من ذلك. ويجمع MASVS ضوابطه في مجالات: التخزين، والتشفير، والمصادقة، والاتصال الشبكي، والتفاعل مع المنصة، وجودة الشيفرة، والصمود أمام الهندسة العكسية، والخصوصية. فريق ضمان الجودة الوظيفي لا يحل محل تقييم أمني متخصص للجوال، لكنه يستطيع فحص الأساسيات في كل إصدار ومعرفة متى يستدعي مختصاً.

• التخزين — لا كلمات مرور ولا رموز ولا بيانات شخصية بنص صريح في ملفات التطبيق أو التفضيلات أو السجلات أو لقطات الشاشة المخزنة؛ مكان الأسرار هو Keystore أو Keychain في المنصة. افحص ما يبقى على الجهاز بعد تسجيل الخروج.
• الشبكة — كل الحركة عبر TLS، دون رجوع إلى HTTP الصريح، وأخطاء الشهادات تُرفض لا تُتجاهل.
• المصادقة والجلسة — الرموز تنتهي صلاحيتها، وتسجيل الخروج يُنهي الجلسة على الخادم لا على الجهاز فقط؛ وفتح القفل بالقياسات الحيوية مرتبط بجلسة صالحة على الخادم.
• التفاعل مع المنصة — الروابط العميقة (Deep links) والمكوّنات المكشوفة للتطبيقات الأخرى تتحقق من مدخلاتها؛ والشاشات الحساسة تُخفى في معاينة مبدّل التطبيقات حيث تتطلب المخاطر ذلك.
• الخصوصية — تُطلب الأذونات عند الحاجة فقط وتُشرح في سياقها؛ والبيانات المجمعة تطابق إفصاحات الخصوصية في المتجر.

إرشادات جودة المنصات والجاهزية للمتجر

تنشر المنصتان ما تعدّانه تطبيقاً عالي الجودة، وهذه الوثائق قوائم فحص جيدة. تضع إرشادات Google لجودة التطبيقات الأساسية (Core app quality) في Android معايير أساسية للتجربة المرئية، والوظائف، والأداء والاستقرار، والخصوصية والأمان، مع الاختبارات المستخدمة للتحقق منها. وتصف إرشادات Apple لواجهات المستخدم (Human Interface Guidelines) السلوك المتوقع لواجهات iOS — التنقل وعناصر التحكم والتخطيط وإمكانية الوصول — وتصف إرشادات مراجعة App Store ما يجب أن يستوفيه التطبيق ليُقبل.

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

• التنقل للخلف — زر الرجوع أو إيماءته في Android وإيماءة السحب للرجوع في iOS تتصرف بشكل متوقع في كل شاشة.
• استعادة الحالة — يعود التطبيق إلى حيث كان المستخدم بعد نقله إلى الخلفية أو إنهائه.
• الاستقرار — لا انهيارات ولا حوارات «التطبيق لا يستجيب» (ANR) في المسارات الأساسية.
• بدء التشغيل — البدء البارد حتى شاشة قابلة للاستخدام مقبول على أضعف جهاز تدعمه.
• صفحة المتجر — لقطات الشاشة وإفصاحات الخصوصية ونصوص الغرض من الأذونات تطابق التطبيق.

الأتمتة وCI وبوابات الإصدار

تتبع أتمتة الجوال الهرم نفسه الذي يتبعه أي منتج (انظر دليل الاختبار اليدوي مقابل الآلي): اختبارات وحدة سريعة وكثيرة، وطبقة متينة من اختبارات API على الواجهة الخلفية، ومجموعة أصغر من اختبارات الواجهة للرحلات الحرجة. تستخدم طبقة الواجهة أطر المنصات — Espresso لـ Android وXCUITest لـ iOS — أو Appium الذي يقود المنصتين عبر بروتوكول WebDriver. وتعتمد اختبارات الواجهة المستقرة على معرّفات إمكانية الوصول (Accessibility identifiers) كمحددات، وعلى مزامنة الإطار بدلاً من الانتظار الثابت، وعلى حالة جهاز مضبوطة. ويقارن الدليل المرافق عن أتمتة اختبار الجوال بين الأطر ويسرد مصادر عدم الاستقرار.

في CI شغّل اختبارات الوحدة واختبارات الدخان (Smoke) على المحاكيات مع كل تغيير، وحزمة أوسع على أجهزة حقيقية في مزرعة أجهزة كل ليلة أو قبل الإصدار؛ واحتفظ بالفيديو ولقطات الشاشة وسجلات الجهاز لكل إخفاق. ولأن إصدار الجوال لا يمكن التراجع عنه فوراً، فإن خط الاختبار الأخير يكون حول المتجر: التوزيع الداخلي والتجريبي أولاً (TestFlight على iOS ومسارات الاختبار في Google Play)، ثم طرح مرحلي يصل إلى نسبة صغيرة من المستخدمين قبل الجميع، مع مراقبة معدلات الانهيار وANR وأخطاء API في كل خطوة. وكثيراً ما يكون مفتاح عن بُعد يعطّل ميزة معطوبة أسرع إصلاح متاح.

• بوابة — لا مجموعة انهيارات جديدة في البناء التجريبي خلال فترة المراقبة المتفق عليها.
• بوابة — أقدم إصدار مدعوم من التطبيق ما زال يجتاز فحوص الدخان لـ API مقابل الواجهة الخلفية الجديدة.
• الطرح — أوقفه مؤقتاً إذا انخفض معدل الجلسات الخالية من الانهيار أو معدل نجاح مسار أساسي عن الحد المتفق عليه.

الأسئلة الشائعة

المراجع

• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019منهج ISTQB التخصصي لاختبار تطبيقات الجوال: أنواع التطبيقات وتحديات الأجهزة والمنصات وأنواع الاختبار والأدوات.
• Core app quality guidelinesAndroid Developers (Google)معايير Google الأساسية لجودة تطبيقات Android — التجربة المرئية والوظائف والأداء والخصوصية والأمان — مع الاختبارات المستخدمة للتحقق منها.
• Test apps on AndroidAndroid Developers (Google)إرشادات Android الرسمية للاختبار: أنواع الاختبارات ونطاقاتها، والاختبارات المحلية مقابل المُجهَّزة على الجهاز، وأفضل الممارسات.
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationمتطلبات OWASP الأمنية لتطبيقات الجوال، مجمّعة في مجالات ضبط مثل التخزين والتشفير والمصادقة والشبكة والتفاعل مع المنصة.
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP Foundationدليل الاختبار المرافق لـ MASVS: تقنيات وحالات اختبار للتحقق من أمان تطبيقات الجوال.
• Accessibility — Human Interface GuidelinesAppleإرشادات Apple لتصميم إمكانية الوصول في iOS وغيره: VoiceOver والنص الديناميكي والتباين وأهداف اللمس والحركة.
• Appium DocumentationAppium (OpenJS Foundation)التوثيق الرسمي لأتمتة التطبيقات الأصلية والهجينة وتطبيقات الويب على iOS وAndroid.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).