توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول إجراء الاختبارات باستخدام Firebase Test Lab. كما تم توثيق المشكلات المعروفة. إذا لم تتمكن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية ، فانضم إلى # test-lab channel على Firebase Slack أو اتصل بدعم Firebase .
استكشاف الأخطاء وإصلاحها
عندما تحدد جهازًا ذا سعة عالية في كتالوج معمل الاختبار ، فقد تبدأ الاختبارات بشكل أسرع. عندما يكون أحد الأجهزة ذات سعة منخفضة ، فقد تستغرق الاختبارات وقتًا أطول. إذا كان عدد الاختبارات التي تم استدعاؤها أكبر بكثير من سعة الأجهزة المحددة ، فقد تستغرق الاختبارات وقتًا أطول حتى تنتهي.
قد تستغرق الاختبارات التي يتم إجراؤها على أي مستوى من مستويات سعة الجهاز وقتًا أطول بسبب العوامل التالية:
- حركة المرور ، والتي تؤثر على توفر الجهاز وسرعة الاختبار.
- أعطال الجهاز أو البنية التحتية ، والتي يمكن أن تحدث في أي وقت. للتحقق مما إذا كانت هناك بنية أساسية تم الإبلاغ عنها لـ Test Lab ، راجع لوحة معلومات حالة Firebase .
لمعرفة المزيد حول سعة الجهاز في Test Lab ، راجع معلومات سعة الجهاز لنظامي Android و iOS .
تحدث نتائج الاختبار غير الحاسمة عادةً إما بسبب عمليات الاختبار الملغاة أو أخطاء البنية التحتية.
تحدث أخطاء البنية التحتية بسبب مشكلات داخلية في Test Lab ، مثل أخطاء الشبكة أو سلوكيات الجهاز غير المتوقعة. يتقاعد Test Lab داخليًا من عمليات الاختبار التي تنتج أخطاء البنية التحتية عدة مرات قبل الإبلاغ عن نتيجة غير حاسمة ؛ ومع ذلك ، يمكنك تعطيل عمليات إعادة المحاولة هذه باستخدام failFast .
لتحديد سبب الخطأ ، اتبع الخطوات التالية:
- تحقق من حالات الانقطاع المعروفة في لوحة معلومات حالة Firebase .
أعد محاولة الاختبار في معمل الاختبار للتحقق من أنه قابل للتكرار.
حاول تشغيل الاختبار على جهاز أو نوع جهاز مختلف ، إن أمكن.
إذا استمرت المشكلة ، فاتصل بفريق Test Lab في # test-lab channel على Firebase Slack.
يمكن أن تؤدي المشاركة إلى تشغيل اختباراتك لفترة أطول عندما يتجاوز عدد الأجزاء التي حددتها عدد الأجهزة المتاحة للاستخدام في مختبر الاختبار. لتجنب هذا الموقف ، حاول التبديل إلى جهاز مختلف. لمزيد من المعلومات حول اختيار جهاز مختلف ، راجعسعة الجهاز .
عند إرسال طلب اختبار ، يتم التحقق من صحة تطبيقك أولاً ، وإعادة توقيعه ، وما إلى ذلك استعدادًا لإجراء الاختبارات على الجهاز. عادة ، تكتمل هذه العملية في أقل من بضع ثوانٍ ، ولكن يمكن أن تتأثر بعوامل مثل حجم التطبيق الخاص بك.
بعد أن يتم تحضير تطبيقك ، تتم جدولة عمليات التنفيذ التجريبية وتظل في قائمة انتظار حتى يصبح الجهاز جاهزًا لتشغيله. حتى تنتهي جميع عمليات تنفيذ الاختبار من التشغيل ، ستكون حالة المصفوفة "معلقة" (بغض النظر عما إذا كانت عمليات تنفيذ الاختبار في قائمة الانتظار أو قيد التشغيل بشكل نشط).
بعد الانتهاء من تنفيذ الاختبار ، يتم تنزيل عناصر الاختبار من الجهاز ومعالجتها وتحميلها إلى Cloud Storage. يمكن أن تتأثر مدة هذه الخطوة بكمية وحجم القطع الأثرية.
أسئلة مكررة
يقدم Firebase Test Lab حصصًا مجانية للاختبار على الأجهزة ولاستخدام Cloud APIs. لاحظ أن حصة الاختبار تستخدم خطة تسعير Firebase القياسية ، بينما لا تستخدم حصص Cloud API.
حصة الاختبار
يتم تحديد حصص الاختبار من خلال عدد الأجهزة المستخدمة لإجراء الاختبارات. تحتوي خطة Firebase Spark على حصة اختبار ثابتة دون أي تكلفة للمستخدمين. بالنسبة لخطة Blaze ، قد تزداد حصصك إذا زاد استخدامك لـ Google Cloud بمرور الوقت. إذا وصلت إلى حصة الاختبار الخاصة بك ، فانتظر حتى اليوم التالي أو قم بالترقية إلى خطة Blaze إذا كنت حاليًا تستخدم خطة Spark. إذا كنت مشتركًا بالفعل في خطة Blaze ، فيمكنك طلب زيادة الحصة. لمزيد من المعلومات ، راجع حصة الاختبار .
يمكنك مراقبة استخدام حصة الاختبار الخاصة بك في Google Cloud Console .
حصة واجهة برمجة تطبيقات Cloud Testing
تأتي Cloud Testing API مع حدّين للحصة: الطلبات في اليوم لكل مشروع ، والطلبات لكل 100 ثانية لكل مشروع. يمكنك مراقبة استخدامك في Google Cloud Console .
حصة واجهة برمجة تطبيقات نتائج أداة السحابة
تأتي واجهة Cloud Tool Results API مع حدين للحصة: استعلامات في اليوم لكل مشروع ، وطلبات بحث كل 100 ثانية لكل مشروع. يمكنك مراقبة استخدامك في Google Cloud Console .
راجع حصص Cloud API الخاصة بـ Test Lab للحصول على مزيد من المعلومات حول حدود API. إذا وصلت إلى حصة API:
أرسل طلبًا للحصول على حصص أعلى عن طريق تعديل حصصك مباشرةً في Google Cloud Console (لاحظ أنه يتم تعيين معظم الحدود على الحد الأقصى افتراضيًا) ، أو
اطلب حصصًا أعلى لواجهة برمجة التطبيقات عن طريق ملء نموذج طلب في Google Cloud Console أو عن طريق الاتصال بدعم Firebase .
من الواجهة الخلفية الخاصة بك ، يمكنك تحديد ما إذا كانت حركة المرور قادمة من أجهزة اختبار مستضافة من Firebase عن طريق التحقق من عنوان IP المصدر مقابل نطاقات IP الخاصة بنا.
لا يعمل Test Lab مع VPC-SC ، والذي يحظر نسخ التطبيقات وعناصر الاختبار الأخرى بين التخزين الداخلي لـ Test Lab وحزم نتائج المستخدمين.
لاكتشاف السلوك غير المستقر في اختباراتك ، نوصي باستخدام الخيار--num-flaky-test-calls. تتم محاسبة عمليات إعادة التشغيل Deflake أو احتسابها ضمن حصتك اليومية بنفس عمليات تنفيذ الاختبار العادية.
ضع في اعتبارك ما يلي:
- يتم تشغيل تنفيذ الاختبار بالكامل مرة أخرى عند اكتشاف عطل. لا يوجد دعم لإعادة المحاولة فقط حالات الاختبار الفاشلة.
- تمت جدولة عمليات إعادة المحاولة Deflake للتشغيل في نفس الوقت ، ولكن لا يتم ضمان تشغيلها بالتوازي ، على سبيل المثال ، عندما تتجاوز حركة المرور عدد الأجهزة المتاحة.
في حين أن بعض هذه العناصر موجودة في خارطة الطريق الخاصة بنا ، فإننا غير قادرين حاليًا على توفير الالتزام بدعم منصات الاختبار وتطوير التطبيقات هذه.
تتوفر معلومات الجهاز التفصيلية من خلال واجهة برمجة التطبيقات ويمكن الوصول إليها من عميل gcloud باستخدام الأمر description :
gcloud firebase test ios models describe MODEL
لا يتم دعم المشاركة في الأصل داخل Test Lab لنظام iOS. ومع ذلك ، يمكنك استخدام عميل Flank في حالات اختبار iOS الخاصة بـ Shard.
يعمل هذا عن طريق تعيين مفتاح OnlyTestIdentifiers والقيم في ملف .xctestrun . راجع صفحة man لـ xcodebuild.xctestrun لمزيد من التفاصيل.
مشاكل معروفة
لا يمكن لاختبار Robo تجاوز شاشات تسجيل الدخول التي تتطلب إجراءً إضافيًا من المستخدم يتجاوز إدخال بيانات الاعتماد لتسجيل الدخول ، على سبيل المثال ، إكمال اختبار CAPTCHA.
يعمل اختبار Robo بشكل أفضل مع التطبيقات التي تستخدم عناصر واجهة المستخدم من إطار عمل Android UI (بما في ذلك كائنات View و ViewGroup و WebView ). إذا كنت تستخدم اختبار Robo لممارسة التطبيقات التي تستخدم أطر عمل أخرى لواجهة المستخدم ، بما في ذلك التطبيقات التي تستخدم محرك ألعاب Unity ، فقد يتم إنهاء الاختبار دون استكشاف ما وراء الشاشة الأولى.
توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول إجراء الاختبارات باستخدام Firebase Test Lab. كما تم توثيق المشكلات المعروفة. إذا لم تتمكن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية ، فانضم إلى # test-lab channel على Firebase Slack أو اتصل بدعم Firebase .
استكشاف الأخطاء وإصلاحها
عندما تحدد جهازًا ذا سعة عالية في كتالوج معمل الاختبار ، فقد تبدأ الاختبارات بشكل أسرع. عندما يكون أحد الأجهزة ذات سعة منخفضة ، فقد تستغرق الاختبارات وقتًا أطول. إذا كان عدد الاختبارات التي تم استدعاؤها أكبر بكثير من سعة الأجهزة المحددة ، فقد تستغرق الاختبارات وقتًا أطول حتى تنتهي.
قد تستغرق الاختبارات التي يتم إجراؤها على أي مستوى من مستويات سعة الجهاز وقتًا أطول بسبب العوامل التالية:
- حركة المرور ، التي تؤثر على توفر الجهاز وسرعة الاختبار.
- أعطال الجهاز أو البنية التحتية ، والتي يمكن أن تحدث في أي وقت. للتحقق مما إذا كانت هناك بنية أساسية تم الإبلاغ عنها لـ Test Lab ، راجع لوحة معلومات حالة Firebase .
لمعرفة المزيد حول سعة الجهاز في Test Lab ، راجع معلومات سعة الجهاز لنظامي Android و iOS .
تحدث نتائج الاختبار غير الحاسمة عادةً إما بسبب عمليات الاختبار الملغاة أو أخطاء البنية التحتية.
تحدث أخطاء البنية التحتية بسبب مشكلات داخلية في Test Lab ، مثل أخطاء الشبكة أو سلوكيات الجهاز غير المتوقعة. يتقاعد Test Lab داخليًا من عمليات الاختبار التي تنتج أخطاء البنية التحتية عدة مرات قبل الإبلاغ عن نتيجة غير حاسمة ؛ ومع ذلك ، يمكنك تعطيل عمليات إعادة المحاولة هذه باستخدام failFast .
لتحديد سبب الخطأ ، اتبع الخطوات التالية:
- تحقق من حالات الانقطاع المعروفة في لوحة معلومات حالة Firebase .
أعد محاولة الاختبار في معمل الاختبار للتحقق من أنه قابل للتكرار.
حاول تشغيل الاختبار على جهاز أو نوع جهاز مختلف ، إن أمكن.
إذا استمرت المشكلة ، فاتصل بفريق Test Lab في # test-lab channel على Firebase Slack.
يمكن أن تؤدي المشاركة إلى تشغيل اختباراتك لفترة أطول عندما يتجاوز عدد الأجزاء التي حددتها عدد الأجهزة المتاحة للاستخدام في مختبر الاختبار. لتجنب هذا الموقف ، حاول التبديل إلى جهاز مختلف. لمزيد من المعلومات حول اختيار جهاز مختلف ، راجعسعة الجهاز .
عند إرسال طلب اختبار ، يتم التحقق من صحة تطبيقك أولاً ، وإعادة توقيعه ، وما إلى ذلك استعدادًا لإجراء الاختبارات على الجهاز. عادة ، تكتمل هذه العملية في أقل من بضع ثوانٍ ، ولكن يمكن أن تتأثر بعوامل مثل حجم التطبيق الخاص بك.
بعد أن يتم تحضير تطبيقك ، تتم جدولة عمليات التنفيذ التجريبية وتظل في قائمة انتظار حتى يصبح الجهاز جاهزًا لتشغيله. حتى تنتهي جميع عمليات تنفيذ الاختبار من التشغيل ، ستكون حالة المصفوفة "معلقة" (بغض النظر عما إذا كانت عمليات تنفيذ الاختبار في قائمة الانتظار أو قيد التشغيل بشكل نشط).
بعد الانتهاء من تنفيذ الاختبار ، يتم تنزيل عناصر الاختبار من الجهاز ومعالجتها وتحميلها إلى Cloud Storage. يمكن أن تتأثر مدة هذه الخطوة بكمية وحجم القطع الأثرية.
أسئلة مكررة
يقدم Firebase Test Lab حصصًا مجانية للاختبار على الأجهزة ولاستخدام Cloud APIs. لاحظ أن حصة الاختبار تستخدم خطة تسعير Firebase القياسية ، بينما لا تستخدم حصص Cloud API.
حصة الاختبار
يتم تحديد حصص الاختبار من خلال عدد الأجهزة المستخدمة لإجراء الاختبارات. تحتوي خطة Firebase Spark على حصة اختبار ثابتة دون أي تكلفة للمستخدمين. بالنسبة لخطة Blaze ، قد تزداد حصصك إذا زاد استخدامك لـ Google Cloud بمرور الوقت. إذا وصلت إلى حصة الاختبار الخاصة بك ، فانتظر حتى اليوم التالي أو قم بالترقية إلى خطة Blaze إذا كنت حاليًا تستخدم خطة Spark. إذا كنت مشتركًا بالفعل في خطة Blaze ، فيمكنك طلب زيادة الحصة. لمزيد من المعلومات ، راجع حصة الاختبار .
يمكنك مراقبة استخدام حصة الاختبار الخاصة بك في Google Cloud Console .
حصة واجهة برمجة تطبيقات Cloud Testing
تأتي Cloud Testing API مع حدّين للحصة: الطلبات في اليوم لكل مشروع ، والطلبات لكل 100 ثانية لكل مشروع. يمكنك مراقبة استخدامك في Google Cloud Console .
حصة واجهة برمجة تطبيقات نتائج أداة السحابة
تأتي واجهة Cloud Tool Results API مع حدين للحصة: استعلامات في اليوم لكل مشروع ، وطلبات بحث كل 100 ثانية لكل مشروع. يمكنك مراقبة استخدامك في Google Cloud Console .
راجع حصص Cloud API الخاصة بـ Test Lab للحصول على مزيد من المعلومات حول حدود API. إذا وصلت إلى حصة API:
أرسل طلبًا للحصول على حصص أعلى عن طريق تعديل حصصك مباشرةً في Google Cloud Console (لاحظ أنه يتم تعيين معظم الحدود على الحد الأقصى افتراضيًا) ، أو
اطلب حصصًا أعلى لواجهة برمجة التطبيقات عن طريق ملء نموذج طلب في Google Cloud Console أو عن طريق الاتصال بدعم Firebase .
من الواجهة الخلفية الخاصة بك ، يمكنك تحديد ما إذا كانت حركة المرور قادمة من أجهزة اختبار مستضافة من Firebase عن طريق التحقق من عنوان IP المصدر مقابل نطاقات IP الخاصة بنا.
لا يعمل Test Lab مع VPC-SC ، والذي يحظر نسخ التطبيقات وعناصر الاختبار الأخرى بين التخزين الداخلي لـ Test Lab وحزم نتائج المستخدمين.
لاكتشاف السلوك غير المستقر في اختباراتك ، نوصي باستخدام الخيار--num-flaky-test-calls. تتم محاسبة عمليات إعادة التشغيل Deflake أو احتسابها ضمن حصتك اليومية بنفس عمليات تنفيذ الاختبار العادية.
ضع في اعتبارك ما يلي:
- يتم تشغيل تنفيذ الاختبار بالكامل مرة أخرى عند اكتشاف عطل. لا يوجد دعم لإعادة المحاولة فقط حالات الاختبار الفاشلة.
- تمت جدولة عمليات إعادة المحاولة Deflake للتشغيل في نفس الوقت ، ولكن لا يتم ضمان تشغيلها بالتوازي ، على سبيل المثال ، عندما تتجاوز حركة المرور عدد الأجهزة المتاحة.
في حين أن بعض هذه العناصر موجودة في خارطة الطريق الخاصة بنا ، فإننا غير قادرين حاليًا على توفير الالتزام بدعم منصات الاختبار وتطوير التطبيقات هذه.
تتوفر معلومات الجهاز التفصيلية من خلال واجهة برمجة التطبيقات ويمكن الوصول إليها من عميل gcloud باستخدام الأمر description :
gcloud firebase test ios models describe MODEL
لا يتم دعم المشاركة في الأصل داخل Test Lab لنظام iOS. ومع ذلك ، يمكنك استخدام عميل Flank في حالات اختبار iOS الخاصة بـ Shard.
يعمل هذا عن طريق تعيين مفتاح OnlyTestIdentifiers والقيم في ملف .xctestrun . راجع صفحة man لـ xcodebuild.xctestrun لمزيد من التفاصيل.
مشاكل معروفة
لا يمكن لاختبار Robo تجاوز شاشات تسجيل الدخول التي تتطلب إجراءً إضافيًا من المستخدم يتجاوز إدخال بيانات الاعتماد لتسجيل الدخول ، على سبيل المثال ، إكمال اختبار CAPTCHA.
يعمل اختبار Robo بشكل أفضل مع التطبيقات التي تستخدم عناصر واجهة المستخدم من إطار عمل Android UI (بما في ذلك كائنات View و ViewGroup و WebView ). إذا كنت تستخدم اختبار Robo لممارسة التطبيقات التي تستخدم أطر عمل أخرى لواجهة المستخدم ، بما في ذلك التطبيقات التي تستخدم محرك ألعاب Unity ، فقد يتم إنهاء الاختبار دون استكشاف ما وراء الشاشة الأولى.
توفر هذه الصفحة تعليمات حول استكشاف الأخطاء وإصلاحها وإجابات للأسئلة المتداولة حول إجراء الاختبارات باستخدام Firebase Test Lab. كما تم توثيق المشكلات المعروفة. إذا لم تتمكن من العثور على ما تبحث عنه أو كنت بحاجة إلى مساعدة إضافية ، فانضم إلى # test-lab channel على Firebase Slack أو اتصل بدعم Firebase .
استكشاف الأخطاء وإصلاحها
عندما تحدد جهازًا ذا سعة عالية في كتالوج معمل الاختبار ، فقد تبدأ الاختبارات بشكل أسرع. عندما يكون أحد الأجهزة ذات سعة منخفضة ، فقد تستغرق الاختبارات وقتًا أطول. If the number of tests invoked is much larger than the capacity of the selected devices, tests can take longer to finish.
Tests running on any level device capacity level may take longer due to the following factors:
- Traffic, which affects device availability and test speed.
- Device or infrastructure failures, which can happen at any time. To check if there is a reported infrastructure for Test Lab, see the Firebase status dashboard .
To learn more about device capacity in Test Lab, see device capacity information for Android and iOS .
Inconclusive test outcomes commonly occur either because of canceled test runs or infrastructure errors.
Infrastructure errors are caused by internal Test Lab issues, like network errors or unexpected device behaviors. Test Lab internally retires test runs that produce infrastructure errors multiple times before reporting an inconclusive outcome; however, you can disable these retries using failFast .
To determine the cause of the error, follow these steps:
- Check for known outages in the Firebase status dashboard .
Retry the test in Test Lab to verify that it is reproducible.
Try running the test on a different device or device type, if applicable.
If the issue persists, contact the Test Lab team in the #test-lab channel on Firebase Slack.
Sharding can cause your tests to run longer when the number of shards you specified exceeds the number of devices available for use in Test Lab. To avoid this situation, try switching to a different device. For more information about choosing a different device, seeDevice Capacity .
When you submit a test request, your app is first validated, re-signed, etc. in preparation for running tests on a device. Normally, this process completes in less than a few seconds, but it can be affected by factors like the size of your app.
After your app is prepared, test executions are scheduled and remain in a queue until a device is ready to run it. Until all test executions finish running, the matrix status will be "Pending" (regardless of whether test executions are in the queue or actively running).
After the test execution is finished, test artifacts are downloaded from the device, processed, and uploaded to Cloud Storage. The duration of this step can be affected by the amount and size of the artifacts.
Frequently asked questions
Firebase Test Lab offers no-cost quotas for testing on devices and for using Cloud APIs. Note that the testing quota uses the standard Firebase pricing plan, while the Cloud API quotas do not.
Testing quota
Testing quotas are determined by the number of devices used to run tests. The Firebase Spark plan has a fixed testing quota at no cost to users. For the Blaze plan, your quotas might increase if your usage of Google Cloud increases over time. If you reach your testing quota, wait until the next day or upgrade to the Blaze plan if you are currently on the Spark plan. If you are already on the Blaze plan, you can request a quota increase. For more information, see Testing quota .
You can monitor your testing quota usage in the Google Cloud Console .
Cloud Testing API quota
The Cloud Testing API comes with two quota limits: requests per day per project, and requests per every 100 seconds per project. You can monitor your usage in the Google Cloud Console .
Cloud Tool Results API quota
The Cloud Tool Results API comes with two quota limits: queries per day per project, and queries per every 100 seconds per project. You can monitor your usage in the Google Cloud Console .
Refer to Cloud API quotas for Test Lab for more information on API limits. If you've reached an API quota:
Submit a request for higher quotas by editing your quotas directly in the Google Cloud Console (note that most limits are set to maximum by default), or
Request higher API quotas by filling out a request form in the Google Cloud Console or by contacting Firebase support .
From your backend, you can determine if traffic is coming from Firebase-hosted test devices by checking the source IP address against our IP ranges .
Test Lab does not work with VPC-SC, which blocks the copying of apps and other test artifacts between Test Lab's internal storage and users' results buckets.
To detect flaky behavior in your tests, we recommend using the--num-flaky-test-attemptsoption. Deflake reruns are billed or counted toward your daily quota the same as normal test executions.
Keep the following in mind:
- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.
- Deflake retry runs are scheduled to run at the same time, but are not guaranteed to run in parallel, for example, when traffic exceeds the number of available devices.
While some of these items are on our roadmap, we're currently unable to provide commitment to supporting these testing and app development platforms.
Detailed device information is available through the API and can be accessed from the gcloud client using the describe command :
gcloud firebase test ios models describe MODEL
Sharding isn't natively supported within Test Lab for iOS. However, you can use the Flank client to shard iOS test cases.
This works by setting OnlyTestIdentifiers key and values in .xctestrun file. See man page for xcodebuild.xctestrun for more details.
Known issues
Robo test cannot bypass sign-in screens that require additional user action beyond entering credentials to sign in, for example, completing a CAPTCHA.
Robo test works best with apps that use UI elements from the Android UI framework (including View , ViewGroup , and WebView objects). If you use Robo test to exercise apps that use other UI frameworks, including apps that use the Unity game engine, the test may exit without exploring beyond the first screen.