عیب یابی آزمایشگاه تست & سوالات متداول

این صفحه راهنمایی عیب‌یابی و پاسخ به سؤالات متداول در مورد اجرای آزمایش‌ها با Firebase Test Lab را ارائه می‌دهد. مسائل شناخته شده نیز مستند شده است. اگر نمی‌توانید چیزی را که به دنبالش هستید پیدا کنید یا به کمک بیشتری نیاز دارید، به کانال #test-lab در Firebase Slack بپیوندید یا با پشتیبانی Firebase تماس بگیرید.

عیب یابی

وقتی دستگاهی با ظرفیت بالا را در کاتالوگ Test Lab انتخاب می‌کنید، آزمایش‌ها ممکن است سریع‌تر شروع شوند. وقتی دستگاهی ظرفیت پایینی دارد، آزمایش‌ها ممکن است بیشتر طول بکشد. اگر تعداد تست‌های فراخوانی شده بسیار بیشتر از ظرفیت دستگاه‌های انتخاب‌شده باشد، پایان آزمایش‌ها ممکن است بیشتر طول بکشد.

آزمایش‌هایی که در هر سطح ظرفیت دستگاه اجرا می‌شوند به دلیل عوامل زیر ممکن است بیشتر طول بکشد:

  • ترافیک، که بر در دسترس بودن دستگاه و سرعت تست تأثیر می گذارد.
  • خرابی دستگاه یا زیرساخت، که ممکن است در هر زمانی رخ دهد. برای بررسی اینکه آیا زیرساخت گزارش شده برای Test Lab وجود دارد یا خیر، به داشبورد وضعیت Firebase مراجعه کنید.

برای کسب اطلاعات بیشتر در مورد ظرفیت دستگاه در Test Lab ، به اطلاعات ظرفیت دستگاه برای Android و iOS مراجعه کنید.

نتایج آزمایش غیرقابل قطعی معمولاً به دلیل اجرای آزمایشی لغو شده یا خطاهای زیرساخت رخ می دهد.

خطاهای زیرساخت ناشی از مشکلات داخلی Test Lab ، مانند خطاهای شبکه یا رفتارهای غیرمنتظره دستگاه است. Test Lab به صورت داخلی اجرای آزمایشی را که خطاهای زیرساختی را چندین بار قبل از گزارش یک نتیجه غیرقطعی ایجاد می کند، بازنشسته می کند. با این حال، می‌توانید این تلاش‌های مجدد را با استفاده از failFast غیرفعال کنید.

برای تعیین علت خطا، مراحل زیر را دنبال کنید:

  1. قطعی های شناخته شده را در داشبورد وضعیت Firebase بررسی کنید.

  2. آزمایش را در Test Lab دوباره امتحان کنید تا تأیید کنید که تکرارپذیر است.

  3. در صورت وجود، آزمایش را روی دستگاه یا نوع دستگاه دیگری اجرا کنید.

اگر مشکل همچنان ادامه داشت، با تیم Test Lab در کانال #test-lab در Firebase Slack تماس بگیرید.

هنگامی که تعداد خرده‌هایی که مشخص کرده‌اید از تعداد دستگاه‌های موجود برای استفاده در Test Lab بیشتر شود، شارد کردن می‌تواند باعث طولانی‌تر شدن آزمایش‌های شما شود. برای جلوگیری از این وضعیت، سعی کنید به دستگاه دیگری بروید. برای اطلاعات بیشتر در مورد انتخاب یک دستگاه دیگر، رجوع کنیدظرفیت دستگاه

وقتی درخواست آزمایشی ارسال می‌کنید، ابتدا برنامه شما اعتبارسنجی می‌شود، مجدداً امضا می‌شود و غیره در آماده‌سازی برای اجرای آزمایش‌ها روی دستگاه. به طور معمول، این فرآیند در کمتر از چند ثانیه کامل می شود، اما می تواند تحت تأثیر عواملی مانند اندازه برنامه شما قرار گیرد.

پس از آماده شدن برنامه، اجرای آزمایشی برنامه ریزی می شود و تا زمانی که دستگاهی برای اجرای آن آماده شود، در یک صف باقی می ماند. تا زمانی که اجرای همه آزمایش‌ها به پایان برسد، وضعیت ماتریس "در انتظار" خواهد بود (صرف نظر از اینکه اجرای آزمایش در صف باشد یا به طور فعال اجرا شود).

پس از اتمام اجرای آزمایش، مصنوعات آزمایشی از دستگاه دانلود، پردازش و در Cloud Storage آپلود می‌شوند. مدت زمان این مرحله می تواند تحت تاثیر مقدار و اندازه مصنوعات باشد.

مصنوعات اجرای آزمایش (مانند اسکرین شات ها و فایل های گزارش) در Google Cloud Storage ذخیره می شوند و مستقیماً در کنسول Firebase رندر می شوند. اگر اجرای آزمایشی شما در 90 روز گذشته انجام شده است، بررسی کنید که نقش‌های سطح پروژه (مالک پروژه، ویرایشگر پروژه یا نمایشگر پروژه) را تعیین کرده‌اید. لطفاً همچنین مطمئن شوید که Cloud Audit Logging برای پروژه یا سازمان شما فعال نیست.

اگر این اجرا بیش از 90 روز پیش انجام شده باشد، به احتمال زیاد مصنوعات آزمایشی به طور خودکار حذف شده اند. می‌توانید پیکربندی سطل نتایج را با کلیک کردن روی برگه نتایج تست در داشبورد Test Lab بررسی کنید. سطل نتایج پیش‌فرض به گونه‌ای پیکربندی شده است که اشیاء را به مدت 90 روز حفظ کند.

برای حفظ مصنوعات آزمایشی خود، دستور gcloud firebase test android run با flag --results-bucket اجرا کنید و نام سطل نتیجه را ارسال کنید. برای اطلاعات بیشتر، از مستندات مرجع gcloud firebase test android run دیدن کنید.

هنگامی که تست‌های ابزار دقیق را اجرا می‌کنید، ممکن است خطاهای آزمایشی را مشاهده کنید که نشان‌دهنده نتایج جزئی است که حاوی پیام‌هایی مانند Test run failed to complete. Expected x tests, received y (که y کمتر از x است). این خطا به این معنی است که Test Lab نتوانست logcat را برای نشانگرهای شروع یا پایان مورد آزمایشی که معمولاً توسط AndroidJUnitRunner تولید می‌شوند، تجزیه کند.

موارد زیر دلایل رایج این مشکل هستند:

شرح موضوع وضوح ممکن
پرونده آزمایشی به دلیل مهلت زمانی اجرا نشد. اگر مدت زمان کل آزمایش‌ها بیشتر از یک مهلت زمانی باشد که مشخص کرده‌اید یا بیشتر از حداکثر مهلت زمانی باشد، Test Lab بقیه موارد آزمایش را لغو می‌کند.
  • مدت زمان ماتریس را افزایش دهید تا مطمئن شوید که تمام تست‌ها می‌توانند کامل شوند.
  • اگر قبلاً این کار را نکرده‌اید، آزمایش‌ها را تقسیم کنید تا هر قطعه زیر مجموعه‌ای از آزمایش‌ها را اجرا کند و در مدت زمان کوتاه‌تری کامل شود.
  • اگر قبلاً اشتراک گذاری را فعال کرده اید، تعداد خرده ها را افزایش دهید.
مورد آزمایشی تکمیل نشد زیرا زودتر از موعد خارج شد یا گیر کرد. مورد آزمایشی ممکن است به دلیل یک استثنا یا خطای ادعایی پیش از موعد خارج شود. موارد آزمایشی ممکن است در یک حلقه بی نهایت گیر کنند یا ممکن است نتوانند ادامه دهند، برای مثال، اگر برنامه نمای درستی را نشان ندهد و مورد آزمایشی نتواند این عمل را در رابط کاربری انجام دهد. برای بررسی محل توقف آزمایش، ویدیو و logcat را بررسی کنید.
یک اجراکننده آزمایشی سفارشی (از جمله AndroidJUnitRunner در حال توسعه) به طور غیرمنتظره ای خراب شد یا نشانگرهای شروع یا پایان مورد آزمایشی غیرمنتظره را برای logcat نوشت. کد دونده آزمایشی خود را بررسی کنید.
گزارش‌های بیش از حد در logcat نوشته شد که بافر را تحت تأثیر قرار داد یا فرآیند logcat خراب کرد. کاهش نوشتن به logcat .
برنامه تحت آزمایش از کار افتاد. برنامه خود را اشکال زدایی کنید.

سوالات متداول

Firebase Test Lab سهمیه های بدون هزینه ای را برای آزمایش بر روی دستگاه ها و برای استفاده از Cloud API ارائه می دهد. توجه داشته باشید که سهمیه آزمایشی از طرح قیمت گذاری استاندارد Firebase استفاده می کند، در حالی که سهمیه های Cloud API از این استفاده نمی کنند.

  • سهمیه آزمون

    سهمیه های تست بر اساس تعداد دستگاه های مورد استفاده برای اجرای آزمایش ها تعیین می شود. طرح Firebase Spark دارای سهمیه آزمایشی ثابت و بدون هزینه برای کاربران است. برای طرح Blaze، اگر استفاده شما از Google Cloud در طول زمان افزایش یابد، ممکن است سهمیه‌های شما افزایش یابد. اگر به سهمیه آزمایش خود رسیدید، تا روز بعد صبر کنید یا اگر در حال حاضر در طرح Spark هستید، به پلن Blaze ارتقا دهید. اگر قبلاً در طرح Blaze هستید، می توانید درخواست افزایش سهمیه کنید. برای اطلاعات بیشتر، به تست سهمیه مراجعه کنید.

    می‌توانید میزان استفاده از سهمیه آزمایشی خود را در کنسول Google Cloud نظارت کنید.

  • سهمیه Cloud Testing API

    Cloud Testing API دارای دو محدودیت سهمیه است: درخواست در روز برای هر پروژه و درخواست در هر 100 ثانیه در هر پروژه. می توانید استفاده خود را در کنسول Google Cloud نظارت کنید.

  • سهمیه Cloud Tool Results API

    Cloud Tool Results API دارای دو محدودیت سهمیه است: پرس و جو در روز در هر پروژه و پرس و جو در هر 100 ثانیه در هر پروژه. می توانید استفاده خود را در کنسول Google Cloud نظارت کنید.

    برای اطلاعات بیشتر در مورد محدودیت های API، به سهمیه های Cloud API برای Test Lab مراجعه کنید. اگر به سهمیه API رسیده اید:

    • با ویرایش سهمیه‌های خود مستقیماً در کنسول Google Cloud ، درخواست سهمیه‌های بالاتر را ارسال کنید (توجه داشته باشید که اکثر محدودیت‌ها به طور پیش‌فرض روی حداکثر تنظیم شده‌اند)، یا

    • با پر کردن فرم درخواست در کنسول Google Cloud یا با تماس با پشتیبانی Firebase ، سهمیه های API بالاتر را درخواست کنید.

از پشتیبان خود، می توانید با بررسی آدرس IP منبع در برابر محدوده IP ما، تعیین کنید که آیا ترافیک از دستگاه های آزمایشی میزبان Firebase می آید یا خیر.

Test Lab با VPC-SC کار نمی‌کند، که کپی کردن برنامه‌ها و سایر مصنوعات آزمایشی را بین حافظه داخلی Test Lab و سطل‌های نتایج کاربران مسدود می‌کند.

برای تشخیص رفتار پوسته پوسته شدن در آزمایشات خود، توصیه می کنیم از آن استفاده کنید-تست-تست-تست-شلیک-تعدادگزینه تکرارهای Deflake مانند اجرای آزمون های معمولی صورتحساب یا در سهمیه روزانه شما محاسبه می شود.

موارد زیر را در نظر داشته باشید:

  • کل اجرای آزمایش با تشخیص شکست دوباره اجرا می شود. هیچ پشتیبانی برای امتحان مجدد فقط موارد آزمایش ناموفق وجود ندارد.
  • اجرای مجدد Deflake برنامه ریزی شده است که همزمان اجرا شوند، اما تضمینی برای اجرای موازی ندارند، به عنوان مثال، زمانی که ترافیک از تعداد دستگاه های موجود بیشتر باشد.

بله! Test Lab از Google Pixel Watch پشتیبانی می کند. اکنون می‌توانید آزمایش‌هایی را روی برنامه Wear مستقل خود در ساعت‌های Google Pixel اجرا کنید. برای کسب اطلاعات بیشتر درباره دستگاه‌های Test Lab ، به تست در دستگاه‌های موجود مراجعه کنید.

بله! Test Lab از تبلت پیکسل گوگل و گوگل پیکسل فولد پشتیبانی می کند. می‌توانید آزمایش‌های خود را روی دستگاه‌های فیزیکی مستقل خود اجرا کنید. برای کسب اطلاعات بیشتر درباره دستگاه‌های Test Lab ، به تست در دستگاه‌های موجود مراجعه کنید.

اگر برنامه خود را در Firebase آزمایش می‌کنید یا آزمایش‌هایی را برای گزارش پیش از راه‌اندازی در Play Console اجرا می‌کنید، می‌توانید با بررسی ویژگی سیستم firebase.test.lab در فایل MainActivity خود، تشخیص دهید که آیا آزمایشی روی دستگاه میزبان Firebase اجرا می‌شود یا خیر. سپس می توانید دستورات اضافی را بر اساس مقدار بولی برای testLabSetting اجرا کنید. برای اطلاعات بیشتر، رفتارهای آزمایشی اصلاح شده را ببینید.

در حالی که برخی از این موارد در نقشه راه ما قرار دارند، در حال حاضر نمی‌توانیم تعهدی برای پشتیبانی از این پلتفرم‌های آزمایش و توسعه برنامه ارائه کنیم. با این حال، اگر برنامه خود را با چارچوبی ساخته‌اید که از اسپرسو پشتیبانی می‌کند (مثلاً فلاتر)، می‌توانید با استفاده از اسپرسو یک تست ابزار دقیق بنویسید و سپس آن را در Test Lab اجرا کنید.

Test Lab صریحاً از مبهم سازی یا deobfuscation پشتیبانی نمی کند. در حالی که برنامه احتمالاً اجرا می شود، هر گونه داده مبهم برنامه، مانند ردیابی پشته، به صورت مبهم در گزارش ها ظاهر می شود.

بله! می‌توانید دستگاه تاشو خود را در حالت‌ها و وضعیت‌های تاشو آزمایش کنید.

دستگاه‌های تاشو می‌توانند در حالت‌های تا شده مختلفی مانند 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 روی دستگاه تاشو اجرا کنید.
Google Pixel Fold (شناسه مدل felix ) Samsung Galaxy Z Fold4 (شناسه مدل q4q ) 
$ 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},
]
$ 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، برای استفاده از Test Lab نیازی به افزودن Firebase SDK ندارید. اگر قبلاً برنامه ای ندارید، می توانید یک APK را به صورت آنلاین دانلود کنید یا یک برنامه و یک APK آزمایشی را از یکی از نمونه های موجود در مخزن AndroidX GitHub بسازید. توجه داشته باشید که برای اجرای تست Robo فقط به فایل APK برنامه خود نیاز دارید، در حالی که تست ابزار دقیق به یک برنامه و یک APK آزمایشی نیاز دارد که از کد منبع ساخته شده باشند. برای اطلاعات بیشتر، در مورد تست های ابزاری بخوانید.

برای کسب اطلاعات بیشتر درباره ویژگی‌های Test Lab ، به شروع آزمایش برای Android با Firebase Test Lab مراجعه کنید.

آزمایش تفاوت عکس صفحه جایی است که ادعاهای آزمایش بر اساس مقایسه تصاویر صفحه به دست آمده در حین اجرای آزمایش با تصاویر طلایی نشان دهنده رفتار مورد انتظار است. چنین آزمایش‌هایی ممکن است در برخی از انواع دستگاه‌ها نسبت به سایرین شکننده‌تر باشند. ما توصیه می‌کنیم دستگاه‌های شبیه‌ساز Arm ( *.arm ) را برای این نوع آزمایش‌ها مورد هدف قرار دهید. دستگاه‌های شبیه‌ساز بازو از تصاویری استفاده می‌کنند که بسیار شبیه یا مشابه شبیه‌سازهای «عمومی» Android Studio هستند.

همچنین توصیه می‌کنیم کتابخانه‌های آزمایشی را که می‌توانند به قوی‌تر کردن تست‌های اسکرین شات در حضور تغییرات مورد انتظار کمک کنند، بررسی کنید.

بله! هنگامی که تغییرات زیر ایجاد می شود، دستگاه های مجازی به روز می شوند:

  1. به روز رسانی تصاویر موجود
  2. منسوخ شدن سطوح API قبلی
  3. سطوح جدید 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 با استفاده از دستور describe به آن دسترسی داشت:

gcloud firebase test android models describe MODEL

مسائل شناخته شده

تست Robo نمی‌تواند صفحه‌های ورود به سیستم را که به عملکرد کاربر اضافی فراتر از وارد کردن اعتبارنامه‌ها برای ورود به سیستم، برای مثال تکمیل یک CAPTCHA، نیاز دارند، دور بزند.

تست Robo با برنامه‌هایی که از عناصر UI از چارچوب Android UI استفاده می‌کنند (از جمله View ، ViewGroup ، و WebView ) بهترین کار را انجام می‌دهد. اگر از تست Robo برای تمرین برنامه‌هایی که از چارچوب‌های رابط کاربری دیگر استفاده می‌کنند، از جمله برنامه‌هایی که از موتور بازی Unity استفاده می‌کنند، استفاده می‌کنید، ممکن است تست بدون کاوش در صفحه اول خارج شود.