توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول إجراء الاختبارات باستخدام Firebase Test Lab. يتم أيضًا توثيق المشكلات المعروفة. إذا لم تتمكن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية، فانضم إلى قناة #test-lab على Firebase Slack أو اتصل بدعم Firebase .
استكشاف الأخطاء وإصلاحها
عند تحديد جهاز ذي مستوى سعة عالٍ في كتالوج Test Lab، قد تبدأ الاختبارات بشكل أسرع. عندما تكون سعة الجهاز منخفضة، قد يستغرق تشغيل الاختبارات وقتًا أطول. إذا كان عدد الاختبارات التي تم استدعاؤها أكبر بكثير من سعة الأجهزة المحددة، فقد تستغرق الاختبارات وقتًا أطول حتى تنتهي.
قد تستغرق الاختبارات التي يتم إجراؤها على أي مستوى من سعة الجهاز وقتًا أطول بسبب العوامل التالية:
- حركة المرور، والتي تؤثر على توفر الجهاز وسرعة الاختبار.
- فشل الجهاز أو البنية التحتية، والذي يمكن أن يحدث في أي وقت. للتحقق مما إذا كانت هناك بنية أساسية تم الإبلاغ عنها لـ Test Lab، راجع لوحة معلومات حالة Firebase .
لمعرفة المزيد حول سعة الجهاز في Test Lab، راجع معلومات سعة الجهاز لنظامي التشغيل Android و iOS .
عادةً ما تحدث نتائج الاختبار غير الحاسمة إما بسبب إلغاء عمليات الاختبار أو أخطاء في البنية التحتية.
تنجم أخطاء البنية الأساسية عن مشكلات داخلية في Test Lab، مثل أخطاء الشبكة أو سلوكيات الجهاز غير المتوقعة. يقوم Test Lab داخليًا بإيقاف عمليات التشغيل الاختبارية التي تنتج أخطاء في البنية التحتية عدة مرات قبل الإبلاغ عن نتيجة غير حاسمة؛ ومع ذلك، يمكنك تعطيل عمليات إعادة المحاولة هذه باستخدام FailFast .
لتحديد سبب الخطأ، اتبع الخطوات التالية:
- تحقق من حالات الانقطاع المعروفة في لوحة معلومات حالة Firebase .
أعد محاولة الاختبار في Test Lab للتأكد من إمكانية تكراره.
حاول إجراء الاختبار على جهاز أو نوع جهاز مختلف، إن أمكن.
إذا استمرت المشكلة، فاتصل بفريق Test Lab في قناة #test-lab على Firebase Slack.
يمكن أن تؤدي المشاركة إلى تشغيل اختباراتك لفترة أطول عندما يتجاوز عدد الأجزاء التي حددتها عدد الأجهزة المتاحة للاستخدام في Test Lab. لتجنب هذا الموقف، حاول التبديل إلى جهاز مختلف. لمزيد من المعلومات حول اختيار جهاز مختلف، راجع سعة الجهاز.
عند إرسال طلب اختبار، يتم أولاً التحقق من صحة تطبيقك وإعادة توقيعه وما إلى ذلك استعدادًا لإجراء الاختبارات على الجهاز. عادةً، تكتمل هذه العملية في أقل من بضع ثوانٍ، ولكنها قد تتأثر بعوامل مثل حجم تطبيقك.
بعد إعداد تطبيقك، تتم جدولة عمليات تنفيذ الاختبار وتبقى في قائمة الانتظار حتى يصبح الجهاز جاهزًا لتشغيله. حتى تنتهي جميع عمليات تنفيذ الاختبار من التشغيل، ستكون حالة المصفوفة "معلقة" (بغض النظر عما إذا كانت عمليات تنفيذ الاختبار في قائمة الانتظار أو قيد التشغيل بشكل نشط).
بعد الانتهاء من تنفيذ الاختبار، يتم تنزيل عناصر الاختبار من الجهاز ومعالجتها وتحميلها إلى Cloud Storage. يمكن أن تتأثر مدة هذه الخطوة بمقدار وحجم القطع الأثرية.
يتم تخزين عناصر تنفيذ الاختبار (مثل لقطات الشاشة وملفات السجل) في Google Cloud Storage ويتم عرضها مباشرة في وحدة تحكم Firebase. إذا تم تنفيذ الاختبار خلال آخر 90 يومًا، فتأكد من تعيين أدوار على مستوى المشروع (مالك المشروع، أو محرر المشروع، أو عارض المشروع). يرجى أيضًا التأكد من عدم تمكين تسجيل التدقيق السحابي لمشروعك أو مؤسستك.
إذا تم تنفيذ التنفيذ منذ أكثر من 90 يومًا، فمن المرجح أن يتم حذف عناصر الاختبار تلقائيًا. يمكنك التحقق من تكوين مجموعة النتائج بالنقر فوق علامة التبويب نتائج الاختبار في لوحة معلومات Test Lab. تم تكوين مجموعة النتائج الافتراضية للاحتفاظ بالكائنات لمدة 90 يومًا.
للاحتفاظ بعناصر الاختبار الخاصة بك لفترة أطول، قم بتشغيل الأمر gcloud firebase test android run
مع العلامة --results-bucket
وقم بتمرير اسم مجموعة النتائج. لمزيد من المعلومات، قم بزيارة الوثائق المرجعية gcloud firebase test android run
.
عند تشغيل اختبارات الأجهزة، قد ترى أخطاء اختبار تشير إلى نتائج جزئية تحتوي على رسائل مثل Test run failed to complete. Expected x tests, received y
(حيث y
أقل من x
). يعني هذا الخطأ أن Test Lab لم يتمكن من تحليل السجل لعلامات بداية حالة الاختبار أو نهايتها التي يتم إنشاؤها عادةً بواسطة AndroidJUnitRunner .
فيما يلي الأسباب الشائعة لهذه المشكلة:
وصف المشكلة | القرار المحتمل |
---|---|
لم يتم تشغيل حالة الاختبار بسبب انتهاء المهلة. إذا كانت المدة الإجمالية للاختبارات أطول من المهلة التي حددتها أو أطول من الحد الأقصى للمهلة ، فسيقوم Test Lab بإلغاء بقية حالات الاختبار. |
|
فشلت حالة الاختبار في إكمالها لأنها خرجت قبل الأوان أو توقفت. قد يتم إنهاء حالة الاختبار قبل الأوان بسبب حدوث استثناء أو خطأ في التأكيد لم يتم اكتشافه. يمكن أن تتعطل حالات الاختبار في حلقة لا نهائية أو قد لا تتمكن من المتابعة، على سبيل المثال، إذا لم يعرض التطبيق العرض الصحيح وتعذر على حالة الاختبار تنفيذ الإجراء على واجهة المستخدم. | تحقق من الفيديو logcat للتحقق من مكان توقف الاختبار. |
تعطل مشغل اختبار مخصص (بما في ذلك توسيع AndroidJUnitRunner) بشكل غير متوقع أو كتب علامات بداية أو نهاية حالة اختبار غير متوقعة إلى logcat . | تحقق من رمز عداء الاختبار الخاص بك. |
تمت كتابة سجلات زائدة إلى logcat ، مما أدى إلى إرهاق المخزن المؤقت أو تعطل عملية logcat . | تقليل عمليات الكتابة إلى logcat . |
تعطل التطبيق قيد الاختبار. | تصحيح أخطاء التطبيق الخاص بك. |
أسئلة مكررة
يقدم Firebase Test Lab حصصًا مجانية للاختبار على الأجهزة واستخدام Cloud APIs. لاحظ أن حصة الاختبار تستخدم خطة تسعير Firebase القياسية، في حين أن حصص Cloud API لا تستخدمها.
اختبار الحصص
يتم تحديد حصص الاختبار حسب عدد الأجهزة المستخدمة لإجراء الاختبارات. تحتوي خطة Firebase Spark على حصة اختبار ثابتة دون أي تكلفة على المستخدمين. بالنسبة لخطة Blaze، قد تزيد حصصك إذا زاد استخدامك لـ Google Cloud بمرور الوقت. إذا وصلت إلى حصة الاختبار الخاصة بك، فانتظر حتى اليوم التالي أو قم بالترقية إلى خطة Blaze إذا كنت مشتركًا حاليًا في خطة Spark. إذا كنت مشتركًا بالفعل في خطة Blaze، فيمكنك طلب زيادة الحصة. لمزيد من المعلومات، راجع اختبار الحصة النسبية .
يمكنك مراقبة استخدام حصة الاختبار الخاصة بك في وحدة تحكم Google Cloud .
حصة API للاختبار السحابي
تأتي واجهة برمجة تطبيقات Cloud Testing مع حدين للحصص: الطلبات يوميًا لكل مشروع، والطلبات لكل 100 ثانية لكل مشروع. يمكنك مراقبة استخدامك في وحدة تحكم Google Cloud .
حصة واجهة برمجة التطبيقات لنتائج أداة السحابة
تأتي Cloud Tool Results API مع حدين للحصص: الاستعلامات يوميًا لكل مشروع، والاستعلامات لكل 100 ثانية لكل مشروع. يمكنك مراقبة استخدامك في وحدة تحكم Google Cloud .
راجع حصص Cloud API الخاصة بـ Test Lab للحصول على مزيد من المعلومات حول حدود واجهة برمجة التطبيقات. إذا وصلت إلى حصة API:
أرسل طلبًا للحصول على حصص أعلى عن طريق تعديل حصصك مباشرةً في وحدة تحكم Google Cloud (لاحظ أنه يتم تعيين معظم الحدود على الحد الأقصى افتراضيًا)، أو
اطلب حصصًا أعلى لواجهة برمجة التطبيقات (API) عن طريق ملء نموذج طلب في وحدة تحكم Google Cloud أو عن طريق الاتصال بدعم Firebase .
من الواجهة الخلفية لديك، يمكنك تحديد ما إذا كانت حركة المرور تأتي من أجهزة الاختبار المستضافة على Firebase عن طريق التحقق من عنوان IP المصدر مقابل نطاقات IP الخاصة بنا.
لا يعمل Test Lab مع VPC-SC، الذي يحظر نسخ التطبيقات وعناصر الاختبار الأخرى بين وحدة التخزين الداخلية لـ Test Lab ومجموعات نتائج المستخدمين.
للكشف عن السلوك غير المستقر في اختباراتك، نوصي باستخدام الخيار--num-flaky-test-attempts. تتم محاسبة عمليات إعادة تشغيل Deflake أو احتسابها ضمن حصتك اليومية تمامًا مثل عمليات تنفيذ الاختبار العادية.
ضع في اعتبارك ما يلي:
- يتم تشغيل تنفيذ الاختبار بالكامل مرة أخرى عند اكتشاف فشل. لا يوجد دعم لإعادة محاولة حالات الاختبار الفاشلة فقط.
- تتم جدولة عمليات إعادة محاولة Deflake للتشغيل في نفس الوقت، ولكن ليس من المضمون تشغيلها بالتوازي، على سبيل المثال، عندما تتجاوز حركة المرور عدد الأجهزة المتاحة.
نعم! يدعم Test Lab ساعة Google Pixel Watch. يمكنك الآن إجراء اختبارات على تطبيق Wear المستقل الخاص بك على Google Pixel Watches. لمعرفة المزيد حول أجهزة Test Lab، راجع الاختبار على الأجهزة المتاحة .
نعم! يدعم Test Lab جهاز Google Pixel Tablet وGoogle Pixel Fold. يمكنك إجراء اختباراتك على أجهزتك الفعلية المستقلة. لمعرفة المزيد حول أجهزة Test Lab، راجع الاختبار على الأجهزة المتاحة .
إذا كنت تختبر تطبيقك في Firebase أو تجري اختبارات لتقرير الإطلاق المسبق في Play Console، فيمكنك اكتشاف ما إذا كان يتم تشغيل اختبار على جهاز يستضيف Firebase من خلال التحقق من خاصية النظام firebase.test.lab
في ملف MainActivity
الخاص بك. يمكنك بعد ذلك تنفيذ عبارات إضافية بناءً على القيمة المنطقية لـ testLabSetting
. لمزيد من المعلومات، راجع سلوكيات الاختبار المعدلة .
على الرغم من وجود بعض هذه العناصر في خريطة الطريق الخاصة بنا، إلا أننا غير قادرين حاليًا على توفير الالتزام بدعم منصات الاختبار وتطوير التطبيقات هذه. ومع ذلك، إذا قمت بإنشاء تطبيقك باستخدام إطار عمل يدعم Espresso (على سبيل المثال، Flutter)، فيمكنك كتابة اختبار الأجهزة باستخدام Espresso ثم تشغيل الاختبار في Test Lab.
لا يدعم Test Lab بشكل صريح التشويش أو إزالة التشويش. على الرغم من أنه من المحتمل أن يتم تشغيل التطبيق، فإن أي بيانات مبهمة للتطبيق، مثل تتبعات المكدس، ستظهر على أنها مبهمة في السجلات.
نعم! يمكنك اختبار جهازك القابل للطي في الحالات والأوضاع القابلة للطي .
يمكن أن تكون الأجهزة القابلة للطي في حالات مطوية مختلفة، مثل FLAT
(مفتوحة بالكامل) أو HALF_OPENED
(بين مفتوحة بالكامل ومغلقة بالكامل).
من ناحية أخرى، تتكون الأوضاع من اتجاه محدد للجهاز وحالة قابلة للطي. على سبيل المثال، وضع سطح الطاولة، وهو حالة HALF_OPENED
في الاتجاه الأفقي، أو وضع الكتاب، وهو حالة HALF_OPENED
في الاتجاه الرأسي.
إذا كنت تقوم بإجراء اختبارات الأجهزة، فيمكنك استخدام مكتبة Jetpack WindowManager ومتابعة اختبار تطبيقك على وثائق قابلة للطي لاختبار الحالات والمواقف المختلفة.
وبدلاً من ذلك، تكون الحالات المتاحة خاصة بالجهاز ويمكن التفاعل معها باستخدام adb shell command cmd device_state
.
- لسرد الحالة الحالية، قم بتشغيل
adb shell cmd device_state state
. - لتعيين الحالة الحالية أو تجاوزها، قم بتشغيل
adb shell cmd device_state state <IDENTIFIER>
. - لإعادة تعيين الحالة، قم بتشغيل
adb shell cmd device_state state reset
. - للتحقق من الحالات المتاحة، قم بتشغيل الأمر
adb shell cmd device_state print-states
على الجهاز القابل للطي.
جوجل بيكسل فولد (معرف الموديل felix
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
سامسونج جالاكسي Z فولد 4 (معرف الموديل q4q
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
على عكس منتجات Firebase الأخرى، لا تحتاج إلى إضافة Firebase SDK حتى تتمكن من استخدام Test Lab. إذا لم يكن لديك تطبيق بالفعل، فيمكنك تنزيل APK عبر الإنترنت أو إنشاء تطبيق واختبار APK من أحد العينات الموجودة في مستودع AndroidX GitHub . لاحظ أنك تحتاج فقط إلى ملف APK الخاص بتطبيقك لتشغيل اختبار Robo، بينما يتطلب اختبار الأجهزة كلاً من التطبيق وAPK الاختباري المنشأ من التعليمات البرمجية المصدر. لمزيد من المعلومات، اقرأ عن الاختبارات المجهزة .
لمعرفة المزيد حول ميزات Test Lab، راجع بدء اختبار Android باستخدام Firebase Test Lab .
اختبار فرق لقطة الشاشة هو المكان الذي تعتمد فيه تأكيدات الاختبار على مقارنة صور الشاشة التي تم الحصول عليها أثناء تشغيل الاختبار بالصور الذهبية التي تمثل السلوك المتوقع. قد تكون مثل هذه الاختبارات أكثر هشاشة في بعض أنواع الأجهزة من غيرها. نوصي باستهداف أجهزة محاكي Arm ( *.arm
) لهذه الأنواع من الاختبارات. تستخدم أجهزة محاكي Arm صورًا مشابهة جدًا أو مطابقة لمحاكيات Android Studio "العامة".
نوصي أيضًا بالتحقق من مكتبات الاختبار التي يمكن أن تساعد في جعل اختبارات لقطات الشاشة أكثر قوة في حالة وجود تغييرات متوقعة.
نعم! يتم تحديث الأجهزة الافتراضية عند إجراء التغييرات التالية:
- تحديثات على الصور الموجودة
- إهمال مستويات API السابقة
- تمت إضافة مستويات Android API جديدة
لتمكين تقارير التغطية، قم بإضافة coverage=true
إلى حقل environmentVariables
. إذا كنت تستخدم Android Test Orchestrator، فستحتاج إلى توفير دليل لتخزين نتائج التغطية:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
إذا كنت لا تستخدم Orchestrator، فيمكنك تحديد مسار الملف:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
تتوفر معلومات الجهاز التفصيلية من خلال واجهة برمجة التطبيقات (API) ويمكن الوصول إليها من عميل gcloud باستخدام أمر الوصف :
gcloud firebase test android models describe MODEL
مشاكل معروفة
لا يمكن لاختبار Robo تجاوز شاشات تسجيل الدخول التي تتطلب إجراءً إضافيًا من المستخدم يتجاوز إدخال بيانات الاعتماد لتسجيل الدخول، على سبيل المثال، إكمال اختبار CAPTCHA.
يعمل اختبار Robo بشكل أفضل مع التطبيقات التي تستخدم عناصر واجهة المستخدم من إطار عمل Android UI (بما في ذلك كائنات View
و ViewGroup
و WebView
). إذا كنت تستخدم اختبار Robo لتمرين التطبيقات التي تستخدم أطر عمل أخرى لواجهة المستخدم، بما في ذلك التطبيقات التي تستخدم محرك اللعبة Unity، فقد يتم إنهاء الاختبار دون الاستكشاف خارج الشاشة الأولى.