Android وiOS للمختبِرين

لماذا يهم

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

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

Android وiOS من مقعد المختبِر

يعمل Android (من Google) على أجهزة من شركات مصنّعة كثيرة. فنواة النظام مفتوحة المصدر، وتضيف الشركات المصنّعة طبقاتها الخاصة، ويمكن تثبيت التطبيقات من Google Play أو من متاجر أخرى أو مباشرةً من ملف APK، ولهذا يتسلّم المختبِرون عادةً نسخ التصحيح (Debug Builds) على شكل ملفات. وتوفّر المنصة فعل رجوع على مستوى النظام كله، ونموذج أذونات وقت التشغيل (Runtime Permissions)، وانتشاراً واسعاً جداً لإصدارات النظام والعتاد.

أما iOS (من Apple) فلا يعمل إلا على أجهزة iPhone، مع iPadOS على أجهزة iPad. تتحكم Apple في العتاد والنظام وأدوات البناء (Xcode، الذي يحتاج إلى جهاز Mac) وقناة التوزيع الرئيسية، وهي App Store (ولا يُسمح بمتاجر تطبيقات بديلة إلا في بعض المناطق، مثل الاتحاد الأوروبي). وتصل التطبيقات إلى المختبِرين عبر TestFlight أو عبر ملفات تعريف (Provisioning Profiles) مرتبطة بأجهزة مسجّلة. ولا يوجد زر رجوع في النظام، والموارد المحمية مثل الكاميرا والموقع تحتاج إلى غرض مُعلن، ويصدر إصدار iOS الجديد لكل الأجهزة المدعومة في اليوم نفسه.

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

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

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

الأذونات: حوار واحد وقاعدتان مختلفتان

على المنصتين يحتاج المورد المحمي (الكاميرا والموقع والميكروفون وجهات الاتصال والصور والإشعارات) إلى موافقة المستخدم عبر حوار نظام لا يستطيع التطبيق تنسيقه ولا تخطّيه. والفرق في التسلسل. في Android تُطلب الأذونات في وقت التشغيل منذ Android 6.0؛ ويمكن للتطبيق أن يسأل مجدداً بعد الرفض الأول، لكن منذ Android 11 يجعل الرفض الثاني النظام يتوقف عن عرض الحوار، فعلى التطبيق أن يوفّر طريقاً إلى الإعدادات. وأضاف Android 11 أيضاً منح «هذه المرة فقط» للموقع والميكروفون والكاميرا، وأضاف Android 12 الموقع التقريبي، وجعل Android 13 نشر الإشعارات إذناً من أذونات وقت التشغيل. كما يمكن لنظام Android أن يعيد ضبط أذونات تطبيق لم يُستخدم منذ شهور.

أما في iOS فيعرض النظام حوار كل إذن مرة واحدة. وبعد الرفض لا يستطيع التطبيق عرضه مجدداً أبداً؛ فعلى المستخدم تغيير الإعداد في تطبيق «الإعدادات»، وعلى التطبيق أن يشرح ذلك. والموارد مثل الكاميرا والميكروفون والموقع والصور وجهات الاتصال تحتاج إلى نص غرض (Purpose String) في إعدادات التطبيق (مثل NSCameraUsageDescription)؛ وإذا كان مفقوداً فشل الوصول وقد يتعطّل التطبيق، وترفض مراجعة App Store البناء. ويضيف الموقع خيار «السماح مرة واحدة»، الذي تنتهي صلاحيته عندما يتوقف استخدام التطبيق فيمكن للتطبيق أن يسأل مجدداً لاحقاً، ومفتاح الموقع الدقيق؛ ويمكن قصر الصور على عناصر مختارة، وكانت الإشعارات تحتاج إلى إذن دائماً، ويحتاج التتبع عبر التطبيقات إلى طلب App Tracking Transparency المنفصل.

وتغيير إذن من الإعدادات والتطبيق في الخلفية قد يُنهي عملية التطبيق: فينهيها Android عند إلغاء إذن، وينهيها iOS عند تغيير كثير من إعدادات الخصوصية، مثل الكاميرا، منحاً أو إلغاءً. فتكون العودة إلى التطبيق عندئذٍ بدء تشغيل بارداً (Cold Start)، أي يُشغَّل التطبيق من جديد في عملية جديدة، ويجب أن يستعيد موضع المستخدم. ويسرد الدليل المصاحب لسيناريوهات اختبار تطبيقات الجوال سيناريوهات الأذونات العامة؛ وقواعد المنصة أعلاه تعطيك النتيجة المتوقعة لكل منها.

• اطلب في السياق: يجب أن يظهر الحوار عند استخدام الميزة، بعد شرح قصير، لا عند أول تشغيل.
• الرفض: تتراجع الميزة بسلاسة مع رسالة واضحة وزر «فتح الإعدادات» يعمل؛ ولا حلقة من الحوارات.
• المنح لاحقاً من الإعدادات: تعمل الميزة عند العودة دون إعادة تثبيت.
• الامتثال للمتجر: يطابق السبب الذي يقدّمه التطبيق لكل إذن ما تفعله الميزة (نص الغرض في iOS؛ وفي Google Play الإقرار المطلوب للأذونات الحساسة مثل الموقع في الخلفية)؛ فالمراجعون في المتجرين يرفضون الشروح الغامضة أو المفقودة.

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

مثال تطبيقي: إذن الكاميرا في مسار الدفع برمز QR

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

• TC-1 (المنصتان): تثبيت جديد، اضغط «مسح»: ورقة شرح ثم حوار النظام؛ امنح الإذن: تفتح الكاميرا ضمن المسار نفسه.
• TC-2 (Android 11 فأحدث): ارفض مرة واضغط «مسح» مجدداً: يظهر حوار النظام مرة أخرى؛ ارفض ثانيةً واضغط «مسح» للمرة الثالثة: لا حوار، ويعرض التطبيق خيار الإدخال اليدوي وزر «فتح الإعدادات» الذي يصل إلى صفحة أذونات التطبيق.
• TC-3 (iOS): ارفض مرة واضغط «مسح» مجدداً: لا حوار من النظام؛ يعرض التطبيق الإدخال اليدوي و«فتح الإعدادات»؛ امنح الإذن من الإعدادات وعد: أُعيد تشغيل التطبيق و«مسح» تفتح الكاميرا.
• TC-4 (Android 11 فأحدث): اختر «هذه المرة فقط»، ادفع، اترك التطبيق مدة، ثم عد واضغط «مسح»: يظهر الحوار مجدداً بدلاً من إخفاق صامت.
• TC-5 (المنصتان): ألغِ إذن الكاميرا من الإعدادات وشاشة الدفع مفتوحة، ثم عد: يُعاد تشغيل التطبيق بسلامة دون تعطّل، وتُستعاد حالة الدفع المعلّقة أو تُلغى بوضوح.
• TC-6 (المنصتان): مع رفض الإذن، يُكمل إدخال الرمز اليدوي عملية دفع، فلا يعطّل الرفض هدف العمل أبداً.

Camera permission for "Scan a QR code to pay"

Permission state               Android 11+                   iOS
--------------------------------------------------------------------------------------
Never asked                    system dialog on request      system dialog on request
Denied once, asked again       dialog shown again            no dialog: route to Settings
Denied twice, asked again      no dialog: route to Settings  no dialog: route to Settings
"Only this time" granted       expires soon after leaving    not offered for the camera
Revoked in Settings while open process ends, relaunch        process ends, relaunch
Purpose text                   explain before the dialog     NSCameraUsageDescription

جرّبها: مولّد حالات الاختبار

التنقل للخلف: رجوع النظام مقابل رجوع التطبيق

في Android فعل رجوع على مستوى النظام: زر في التنقل بثلاثة أزرار، ومنذ Android 10 إيماءة السحب من الحافة في التنقل بالإيماءات. يُسلَّم هذا الفعل إلى ما يظهر على الشاشة، والتطبيق هو من يقرر معناه: إغلاق الحوار، أو العودة إلى الشاشة السابقة، أو الرجوع صفحة داخل WebView، أو مغادرة التطبيق إذا كان في شاشته الأولى. ويميّز Android أيضاً بين «لأعلى» (Up)، وهو السهم في شريط التطبيق الذي ينتقل صعوداً في تسلسل التطبيق، و«رجوع» (Back) الذي يتتبع خطوات المستخدم عكسياً؛ وبعد رابط عميق (Deep Link)، وهو رابط يفتح شاشة محددة داخل التطبيق، قد يقود الاثنان إلى مكانين مختلفين. ويمكن لإصدارات Android الأحدث أيضاً أن تعرض معاينة لوجهة الرجوع قبل اكتمال الإيماءة (الرجوع التنبؤي، Predictive Back) في التطبيقات التي تدعمها، فتنكشف الوجهة الخاطئة فوراً.

أما iOS فليس فيه رجوع من النظام. فالعودة مهمة التطبيق: زر الرجوع في أعلى يسار شريط التنقل، والسحب التفاعلي من الحافة اليسرى داخل مكدس التنقل (Navigation Stack) (وينتقل الاثنان إلى الجهة اليمنى في اللغات التي تُكتب من اليمين إلى اليسار مثل العربية)، وسحب الورقة (Sheet) لأسفل لإغلاقها، والتبويبات التي يحتفظ كل منها بسجله الخاص. وعندما يُفتح التطبيق من تطبيق آخر، يعرض شريط الحالة رابط «الرجوع إلى» ذلك التطبيق. وشريط التنقل المخصص الذي يعطّل سحب الحافة بصمت، أو الورقة التي يمكن إغلاقها وفيها بيانات نموذج غير محفوظة، عيبان نموذجيان في iOS وحده.

• لكل شاشة، اكتب ما يجب أن يفعله الرجوع على كل منصة ثم نفّذه: الوجهة، وما يحدث للبيانات غير المحفوظة.
• الرجوع في الشاشة الجذرية: يغادر Android التطبيق (أو يعرض «اضغط رجوع مرة أخرى للخروج»)؛ وفي iOS المكافئ هو إيماءة الشاشة الرئيسية، التي تضع التطبيق في الخلفية فقط.
• الرجوع وطلب قيد التنفيذ («ادفع» أو «إرسال»): يجب ألا يُرسل الفعل مرتين وألا تضيع النتيجة.
• الرجوع بعد التدوير، وبعد حوار إذن، وبعد العودة من الخلفية، وبعد رابط عميق: يجب أن يبقى المكدس سليماً.
• شاشات WebView في Android: يجب أن يتحرك الرجوع أولاً عبر سجل الصفحة ثم يغادر WebView.

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

المتاجر والإصدارات وإصدارات النظام

ينشر Google Play التطبيق من حزمة Android App Bundle، ويوفّر مسارات اختبار داخلية ومغلقة ومفتوحة قبل الإنتاج، وطرحاً مرحلياً (Staged Rollout) إلى نسبة من المستخدمين يمكن إيقافه، وتقرير ما قبل الإطلاق الذي يشغّل البناء على مجموعة أجهزة ويبلّغ عن الأعطال. وخارج Play يمكن تثبيت ملف APK مباشرةً، وتُباع بعض الأجهزة دون خدمات Google أصلاً. أما App Store فيأخذ بناءً مرفوعاً من Xcode؛ ويوزّعه TestFlight على ما يصل إلى 100 مختبِر داخلي و10,000 مختبِر خارجي (تنتهي صلاحية البناء بعد 90 يوماً، ويمرّ أول بناء يُرسَل إلى المختبِرين الخارجيين بمراجعة تجريبية)، وتفحص مراجعة App Store بناء الإنتاج، ويوزّع الإصدار المرحلي (Phased Release) التحديث على سبعة أيام ويمكن إيقافه مؤقتاً. ولا يعيد أي من المتجرين المستخدمين الذين حدّثوا إلى البناء السابق: فتوقف الطرح أو تعلّقه وتنشر بناءً مُصلَحاً برقم نسخة أعلى.

يفحص المتجران الصفحة التعريفية مقابل التطبيق: إعلانات الخصوصية (قسم «أمان البيانات» في Play، وتسميات «خصوصية التطبيق» في App Store)، والأسباب المقدَّمة للأذونات، ولقطات الشاشة، والميزات التي يستطيع المراجع الوصول إليها فعلاً. ورفض المراجعة عيب في الإصدار، لذا اختبر الصفحة التعريفية ومسار المراجع داخل التطبيق قبل التقديم، بما في ذلك حساب الاختبار الذي سيستخدمه المراجع.

وتتصرف إصدارات النظام بطريقة مختلفة على المنصتين. يعرّف Android إصداراته بمستوى API (فنظام Android 15 هو API 35)؛ وتصل التحديثات إلى الأجهزة عبر الشركات المصنّعة، فتبقى عدة إصدارات مستخدمة لسنوات. ويعلن تطبيقك أدنى إصدار يُثبَّت عليه (minSdkVersion) والإصدار الذي يتبنّى سلوكه (targetSdkVersion)؛ ويشترط Google Play هدفاً حديثاً، ورفعه يفعّل تغييرات السلوك لتطبيقك، مما يجعل رفع الهدف حدثاً يستدعي الاختبار. أما في iOS فتطرح Apple إصداراً واحداً لكل الأجهزة المدعومة في اليوم نفسه، دون شركة مصنّعة وسيطة، مع نسخة تجريبية عامة كل صيف؛ وتعلن التطبيقات هدف نشر (Deployment Target)، وبعض تغييرات السلوك لا تسري إلا بعد إعادة بناء التطبيق بحزمة SDK الجديدة، فإصدار Xcode الجديد حدث يستدعي الاختبار أيضاً.

• مسار التثبيت: اختبر البناء الذي سيحصل عليه المستخدمون (مسار المتجر أو TestFlight)، لا نسخة التصحيح من المطور فقط.
• مسار التحديث: ثبّت نسخة الإنتاج السابقة واستخدمها ثم حدّث؛ يجب أن تبقى البيانات والجلسات.
• مجموعة الأنظمة: أحدث إصدار ونسخته التجريبية، وأقدم إصدار مدعوم، وطبقات الشركات المصنّعة التي تحمل معظم حركة مستخدميك؛ وتكشف أدوات التحليلات ولوحات المتاجر وتقارير التعطّل أي إصدارات النظام تصل فعلاً، أما سلاسل User-Agent في حركة الويب فأقل فائدة، لأن Chrome على Android وSafari منذ iOS 26 يعلنان إصدار نظام مُجمَّداً (يحوّل الدرس التالي هذا إلى مصفوفة).
• التحديث الإجباري: عندما يتوقف الخادم عن دعم نسخة قديمة، يجب أن يقول التطبيق ذلك ويربط إلى المتجر؛ ويوفّر Android أيضاً تحديثات داخل التطبيق.

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

عدّة المختبِر على كل منصة

أما الاختبار على محاكي Android (Emulator) أو محاكي iOS (Simulator) أو جهاز حقيقي فقرار من استراتيجية الأجهزة يغطيه دليل اختبار الجوال؛ ويفترض هذا القسم أن لديك بناءً وجهازاً أو محاكياً واحداً على الأقل لكل منصة. في Android العدّة هي adb (جسر تصحيح Android، ضمن أدوات منصة SDK)، وتُستخدم عبر USB بعد تفعيل «خيارات المطوّر» (Developer Options) بالنقر على رقم البناء سبع مرات في الإعدادات وتشغيل «تصحيح أخطاء USB». ويُثبَّت ملف APK بالأمر adb install؛ أما حزمة Android App Bundle (AAB) فلا تُثبَّت مباشرةً، فاطلب ملف APK شاملاً (Universal)، أو ابنِ من الحزمة ملفات APK للجهاز بأداة bundletool، أو ارفعها إلى «مشاركة التطبيقات الداخلية» (Internal App Sharing) في Play التي تعيد رابط تثبيت. وتحمل مسارات الاختبار في Play مرشحي الإصدار الموقّعين تماماً كالإنتاج.

وفي iOS يصل البناء إلى جهاز حقيقي عبر TestFlight (دعوة أو رابط عام)، أو بناءً للتطوير أو مخصصاً (Ad Hoc) يسرد ملف تعريفه المعرّف الفريد للجهاز (UDID) ويُثبَّت من نافذة «Devices and Simulators» في Xcode؛ ومنذ iOS 16 يحتاج تشغيل بناء موقّع للتطوير إلى تشغيل «وضع المطوّر» (Developer Mode) في «الخصوصية والأمن». ويُدار محاكي iOS من جهاز Mac بالأمر xcrun simctl: تثبيت تطبيق، أو فتح رابط عميق، أو إعادة ضبط إذن، أو تسجيل الشاشة. وثمة نوعان من إعدادات المطوّر يستحقان مكاناً في كل خطة اختبار. الأول «عدم الاحتفاظ بالأنشطة» (Don’t keep activities) في Android، الذي يدمّر كل شاشة لحظة مغادرتها، فيكشف ضياع حالة النماذج والتعطّل عند العودة. والثاني إبطاء الشبكة (Network Throttling): إذ يحاكي Network Link Conditioner في iOS (في الإعدادات ثم «المطوّر»، ويظهر بعد استخدام الجهاز مع Xcode) الشبكةَ البطيئة أو الفاقدة للحزم أو المتعطّلة، وتضبط عناصر التحكم في الشبكة في محاكي Android نوع شبكة أبطأ أو إشارة ضعيفة أو انقطاع اتصال البيانات، وتضيف إصدارات Android الحديثة أيضاً حداً لمعدل تنزيل الشبكة (Network download rate limit) في خيارات المطوّر على الجهاز الحقيقي.

السجلات هي دليلك. يكتب Android كل شيء في logcat: لكل سطر وقت ومعرّف عملية وأولوية من V (مفصّل) إلى F (قاتل) ووسم (Tag)؛ ويبثّه الأمر adb logcat، ويقصره الخيار --pid على تطبيقك، ويجمع adb bugreport السجلات الكاملة مع آثار ANR في ملف مضغوط واحد للمطور. وANR (التطبيق لا يستجيب) هو حوار «لا يستجيب» الذي يعرضه Android عندما يبقى الخيط الرئيسي (Main Thread) للتطبيق، وهو الذي يرسم الشاشة ويعالج النقرات، محجوباً، مثلاً نحو خمس ثوانٍ دون معالجة الإدخال. ويتابع Play معدلي التعطّل وANR في Android vitals، حيث يُعدّ معدل التعطّل الملحوظ للمستخدم فوق 1.09% أو معدل ANR فوق 0.47% سلوكاً سيئاً قد يقلّل ظهور التطبيق في Google Play. أما iOS فيحتفظ بسجل موحّد تقرؤه مباشرةً في تطبيق Console على جهاز Mac والجهاز موصول، أو في وحدة تحكم Xcode عندما يشغّل Xcode التطبيق. وتبقى سجلات التعطّل (ملفات .ips) على الجهاز في الإعدادات ثم «الخصوصية والأمن» ثم «التحليلات والتحسينات» ثم «بيانات التحليلات»، ويجمع Organizer في Xcode سجلات التعطّل المُحلَّلة رمزياً (Symbolicated)، أي التي تُرجمت فيها عناوين الذاكرة إلى أسماء الدوال، من مستخدمي TestFlight وApp Store الذين يشاركونها. وليس في iOS حوار ANR: فمراقب النظام (Watchdog) يُنهي التطبيق الذي يحجب الخيط الرئيسي أو يبدأ ببطء شديد، ويظهر ذلك في سجل التعطّل برمز الاستثناء 0x8badf00d.

• حالات الإذن بأمر واحد: adb shell pm grant وpm revoke في Android (والإلغاء يُنهي عملية التطبيق كما في الإعدادات)، وsimctl privacy grant وrevoke وreset في محاكي iOS؛ وليس في simctl privacy خدمة للكاميرا، فحالات الكاميرا مثل المثال التطبيقي تحتاج إلى iPhone حقيقي؛ أما «لم يُطلب» على جهاز حقيقي فتعني إزالة التثبيت وإعادته.
• تسجيل الشاشة: adb shell screenrecord أو المسجّل المدمج في الإعدادات السريعة (Android 11 فأحدث)، مع تفعيل «إظهار النقرات» (Show taps) في خيارات المطوّر ليظهر كل نقر؛ ومسجّل مركز التحكم في iOS، أو QuickTime على جهاز Mac عبر الكابل، أو simctl io recordVideo في المحاكي.
• أرفق بكل عيب خاص بالمنصة: مقتطف logcat أو تقرير الخطأ في Android، وسجل التعطّل أو مقتطف Console في iOS، وتسجيل الإيماءة أو الحوار. ويستطيع مختبِرو TestFlight أيضاً إرسال لقطة شاشة مع تعليق من داخل التطبيق التجريبي.
• التقاط logcat طويل، وسطوره تحمل معرّف العملية لا اسم حزمة تطبيقك؛ وتعبير نمطي يُبقي فقط سطور معرّف عملية تطبيقك ذات الأولويات W وE وF يحوّله إلى مرفق مقروء.

# Android (adb from the SDK platform tools; USB debugging on)
adb devices                                  # the phone is listed as "device"
adb install -r app-debug.apk                 # install or update the build
adb shell pm grant com.example.pay android.permission.CAMERA
adb shell pm revoke com.example.pay android.permission.CAMERA
adb logcat --pid=$(adb shell pidof -s com.example.pay)   # your running app only
adb bugreport bugreport.zip                  # full logs and ANR traces
adb shell screenrecord /sdcard/scan.mp4      # Ctrl+C stops it; then:
adb pull /sdcard/scan.mp4

# iOS Simulator (xcrun simctl, from Xcode on a Mac)
xcrun simctl install booted Pay.app
xcrun simctl privacy booted reset location com.example.pay   # back to "never asked"
xcrun simctl openurl booted "pay://scan"
xcrun simctl io booted recordVideo scan.mp4

جرّبها: أداة اختبار Regex

أسئلة شائعة

المراجع

• 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 الرسمية للاختبار: أنواع الاختبارات ونطاقاتها، والاختبارات المحلية مقابل المُجهَّزة على الجهاز، وأفضل الممارسات.
• Android vitalsAndroid Developers (Google)مقاييس جودة التطبيقات التي يجمعها Google Play من أجهزة المستخدمين — ومنها معدّلا الأعطال وعدم الاستجابة (ANR) كما يلحظهما المستخدم ضمن المؤشرات الأساسية — وحدود السلوك السيئ التي تؤثر في ظهور التطبيق.