این صفحه، راهنمای عیب‌یابی و پاسخ به سوالات متداول در مورد اجرای تست‌ها با Firebase Test Lab را ارائه می‌دهد. مشکلات شناخته‌شده نیز مستند شده‌اند. اگر نمی‌توانید آنچه را که به دنبالش هستید پیدا کنید یا به کمک بیشتری نیاز دارید، به کانال #test-lab در Firebase Slack بپیوندید یا با پشتیبانی Firebase تماس بگیرید.
عیب‌یابی
وقتی دستگاهی با سطح ظرفیت بالا را در کاتالوگ Test Lab انتخاب می‌کنید، ممکن است تست‌ها سریع‌تر شروع شوند. وقتی دستگاهی ظرفیت کمی دارد، ممکن است اجرای تست‌ها بیشتر طول بکشد. اگر تعداد تست‌های درخواستی بسیار بیشتر از ظرفیت دستگاه‌های انتخاب شده باشد، اتمام تست‌ها می‌تواند بیشتر طول بکشد.
آزمایش‌هایی که روی هر سطح ظرفیت دستگاه اجرا می‌شوند، ممکن است به دلیل عوامل زیر بیشتر طول بکشند:
- ترافیک، که بر دسترسی‌پذیری دستگاه و سرعت تست تأثیر می‌گذارد.
- خرابی دستگاه یا زیرساخت، که می‌تواند در هر زمانی اتفاق بیفتد. برای بررسی اینکه آیا زیرساختی برای Test Lab گزارش شده است، به داشبورد وضعیت Firebase مراجعه کنید.
برای کسب اطلاعات بیشتر در مورد ظرفیت دستگاه در Test Lab ، به اطلاعات ظرفیت دستگاه برای اندروید و iOS مراجعه کنید.
نتایج بی‌نتیجه آزمایش معمولاً یا به دلیل لغو آزمایش‌ها یا خطاهای زیرساختی رخ می‌دهد.
خطاهای زیرساختی ناشی از مشکلات داخلی Test Lab ، مانند خطاهای شبکه یا رفتارهای غیرمنتظره دستگاه هستند. Test Lab اجرای تست‌هایی را که چندین بار خطاهای زیرساختی ایجاد می‌کنند، قبل از گزارش نتیجه‌ای بی‌نتیجه، به‌طور داخلی متوقف می‌کند. با این حال، می‌توانید این تلاش‌های مجدد را با استفاده از failFast غیرفعال کنید.
برای تعیین علت خطا، مراحل زیر را دنبال کنید:
- قطعی‌های شناخته‌شده را در داشبورد وضعیت فایربیس بررسی کنید.
برای تأیید تکرارپذیری، آزمایش را در Test Lab دوباره انجام دهید.
در صورت لزوم، تست را روی دستگاه یا نوع دستگاه دیگری اجرا کنید.
اگر مشکل همچنان ادامه داشت، با تیم Test Lab در کانال #test-lab در Firebase Slack تماس بگیرید.
وقتی تعداد قطعاتی که مشخص کرده‌اید از تعداد دستگاه‌های موجود برای استفاده در Test Lab بیشتر شود، شاردینگ می‌تواند باعث طولانی‌تر شدن زمان اجرای تست‌های شما شود. برای جلوگیری از این وضعیت، سعی کنید به دستگاه دیگری تغییر دهید. برای اطلاعات بیشتر در مورد انتخاب دستگاه دیگر، بهظرفیت دستگاه .
وقتی درخواست آزمایشی ارسال می‌کنید، برنامه شما ابتدا اعتبارسنجی، دوباره امضا و غیره می‌شود تا برای اجرای آزمایش‌ها روی دستگاه آماده شود. معمولاً این فرآیند در کمتر از چند ثانیه انجام می‌شود، اما عواملی مانند اندازه برنامه شما می‌تواند بر آن تأثیر بگذارد.
پس از آماده شدن برنامه شما، اجراهای آزمایشی زمان‌بندی می‌شوند و تا زمانی که دستگاهی آماده اجرای آن باشد، در صف باقی می‌مانند. تا زمانی که اجرای همه اجراهای آزمایشی به پایان نرسد، وضعیت ماتریس "در انتظار" خواهد بود (صرف نظر از اینکه اجراهای آزمایشی در صف هستند یا به طور فعال در حال اجرا).
پس از اتمام اجرای آزمایش، مصنوعات آزمایشی از دستگاه دانلود، پردازش و در Cloud Storage آپلود می‌شوند. مدت زمان این مرحله می‌تواند تحت تأثیر مقدار و اندازه مصنوعات قرار گیرد.
عیب‌یابی مخصوص اندروید
مصنوعات اجرای تست (مانند اسکرین‌شات‌ها و فایل‌های لاگ) در Google Cloud Storage ذخیره شده و مستقیماً در کنسول Firebase رندر می‌شوند. اگر اجرای تست شما در ۹۰ روز گذشته انجام شده است، بررسی کنید که نقش‌های سطح پروژه (مالک پروژه، ویرایشگر پروژه یا مشاهده‌گر پروژه) را تعیین کرده باشید. لطفاً مطمئن شوید که Cloud Audit Logging برای پروژه یا سازمان شما فعال نباشد.
اگر اجرا بیش از ۹۰ روز پیش انجام شده باشد، به احتمال زیاد مصنوعات آزمایشی به طور خودکار حذف شده‌اند. می‌توانید پیکربندی سطل نتیجه را با کلیک روی برگه نتایج آزمایش در داشبورد Test Lab بررسی کنید. سطل نتیجه پیش‌فرض طوری پیکربندی شده است که اشیاء را به مدت ۹۰ روز نگه دارد.
برای اینکه داده‌های تست شما مدت بیشتری حفظ شوند، دستور 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 نتوانسته logcat را برای نشانگرهای شروع یا پایان مورد تست که معمولاً توسط AndroidJUnitRunner تولید می‌شوند، تجزیه کند.
موارد زیر از علل شایع این مشکل هستند:
| شرح مسئله | قطعنامه احتمالی |
|---|---|
| به دلیل وقفه زمانی، کیس آزمایشی اجرا نشد. اگر کل مدت زمان آزمایش‌ها بیشتر از وقفه زمانی مشخص شده توسط شما یا بیشتر از حداکثر وقفه زمانی باشد، Test Lab بقیه کیس‌های آزمایشی را لغو می‌کند. |
|
| پرونده آزمایشی به دلیل خروج زودهنگام یا گیر کردن، نتوانست تکمیل شود. پرونده آزمایشی ممکن است به دلیل یک استثنا یا خطای assertion که مدیریت نشده است، زودتر از موعد خارج شود. پرونده‌های آزمایشی می‌توانند در یک حلقه بی‌نهایت گیر کنند یا ممکن است قادر به ادامه کار نباشند، به عنوان مثال، اگر برنامه نمای صحیح را نشان ندهد و پرونده آزمایشی نتواند عملی را روی رابط کاربری انجام دهد. | ویدیو و logcat بررسی کنید تا ببینید آزمایش کجا متوقف شده است. |
یک اجراکننده‌ی تست سفارشی (از جمله AndroidJUnitRunner که توسعه داده شده است) به طور غیرمنتظره‌ای از کار افتاد یا نشانگرهای شروع یا پایان غیرمنتظره‌ای برای مورد تست در logcat نوشت. | کد اجرای آزمایشی خود را بررسی کنید. |
گزارش‌های بیش از حدی در logcat نوشته شده بود که باعث از کار افتادن بافر یا از کار افتادن فرآیند logcat می‌شد. | نوشتن در logcat را کاهش دهید. |
| برنامه تحت آزمایش از کار افتاد. | برنامه خود را اشکال زدایی کنید. |
سوالات متداول (FAQ)
Firebase Test Lab سهمیه‌های رایگانی برای آزمایش روی دستگاه‌ها و استفاده از APIهای ابری ارائه می‌دهد. توجه داشته باشید که سهمیه آزمایش از طرح قیمت‌گذاری استاندارد فایربیس استفاده می‌کند، در حالی که سهمیه‌های API ابری این‌طور نیستند.
سهمیه آزمایش
سهمیه‌های آزمایش بر اساس تعداد دستگاه‌هایی که برای اجرای آزمایش‌ها استفاده می‌شوند تعیین می‌شوند. طرح Firebase Spark دارای سهمیه آزمایش ثابت و رایگان برای کاربران است. در طرح Blaze، در صورت افزایش استفاده شما از Google Cloud به مرور زمان، سهمیه شما ممکن است افزایش یابد. اگر به سهمیه آزمایش خود رسیدید، تا روز بعد صبر کنید یا اگر در حال حاضر از طرح Spark استفاده می‌کنید، به طرح Blaze ارتقا دهید. اگر از قبل از طرح Blaze استفاده می‌کنید، می‌توانید درخواست افزایش سهمیه دهید. برای اطلاعات بیشتر، به سهمیه آزمایش مراجعه کنید.
شما می‌توانید میزان استفاده از سهمیه آزمایشی خود را در کنسول Google Cloud رصد کنید.
سهمیه API تست ابری
API تست ابری با دو محدودیت سهمیه ارائه می‌شود: درخواست‌ها در هر روز برای هر پروژه و درخواست‌ها در هر ۱۰۰ ثانیه برای هر پروژه. می‌توانید میزان استفاده خود را در کنسول Google Cloud نظارت کنید.
سهمیه API نتایج ابزار ابری
API نتایج ابزار ابری (Cloud Tool Results API) دو محدودیت سهمیه دارد: پرس‌وجو در هر روز برای هر پروژه، و پرس‌وجو در هر ۱۰۰ ثانیه برای هر پروژه. می‌توانید میزان استفاده خود را در کنسول Google Cloud Console) رصد کنید.
برای اطلاعات بیشتر در مورد محدودیت‌های API، به سهمیه‌های Cloud API برای Test Lab مراجعه کنید. اگر به سهمیه API رسیده‌اید:
با ویرایش سهمیه‌های خود مستقیماً در کنسول Google Cloud ، درخواست سهمیه‌های بالاتر ارسال کنید (توجه داشته باشید که اکثر محدودیت‌ها به طور پیش‌فرض روی حداکثر تنظیم شده‌اند)، یا
با پر کردن فرم درخواست در کنسول Google Cloud یا با تماس با پشتیبانی Firebase، سهمیه API بالاتری درخواست کنید.
از طریق backend خود، می‌توانید با بررسی آدرس IP منبع در برابر محدوده‌های IP ما، تشخیص دهید که آیا ترافیک از دستگاه‌های آزمایشی میزبانی‌شده توسط Firebase می‌آید یا خیر.
Test Lab با VPC-SC کار نمی‌کند، که کپی کردن برنامه‌ها و سایر مصنوعات تست را بین حافظه داخلی Test Lab و سطل‌های نتایج کاربران مسدود می‌کند.
برای تشخیص رفتار ناپایدار در تست‌هایتان، توصیه می‌کنیم از--تعداد-امتحان-امتحان-نامشخصگزینه. تکرارهای Deflake مانند اجراهای آزمایشی معمولی، در صورتحساب یا سهمیه روزانه شما محاسبه می‌شوند.
موارد زیر را در نظر داشته باشید:
- کل اجرای تست زمانی که یک شکست تشخیص داده شود، دوباره اجرا می‌شود. هیچ پشتیبانی برای تلاش مجدد فقط برای موارد تست شکست خورده وجود ندارد.
- اجرای مجدد Deflake به گونه‌ای برنامه‌ریزی شده است که همزمان اجرا شود، اما تضمینی برای اجرای موازی آن وجود ندارد، به عنوان مثال، زمانی که ترافیک از تعداد دستگاه‌های موجود بیشتر می‌شود.
سوالات متداول مخصوص iOS
اگرچه برخی از این موارد در نقشه راه ما قرار دارند، اما در حال حاضر قادر به ارائه تعهد برای پشتیبانی از این پلتفرم‌های آزمایش و توسعه اپلیکیشن نیستیم.
اطلاعات دقیق دستگاه از طریق API در دسترس است و با استفاده از دستور describe از طریق کلاینت gcloud قابل دسترسی است:
gcloud firebase test ios models describe MODEL
Sharding به صورت پیش‌فرض در Test Lab برای iOS پشتیبانی نمی‌شود. با این حال، می‌توانید از کلاینت Flank برای Shard کردن موارد آزمایشی iOS استفاده کنید.
این کار با تنظیم کلید و مقادیر OnlyTestIdentifiers در فایل .xctestrun انجام می‌شود. برای جزئیات بیشتر به صفحه man xcodebuild.xctestrun مراجعه کنید.
برای iOS 18 یا بالاتر، ما قادر به پشتیبانی از ویدیوها در نتایج نیستیم.
سوالات متداول مخصوص اندروید
بله! Test Lab از ساعت گوگل پیکسل پشتیبانی می‌کند. اکنون می‌توانید تست‌ها را روی برنامه مستقل Wear خود روی ساعت‌های گوگل پیکسل اجرا کنید. برای کسب اطلاعات بیشتر در مورد دستگاه‌های Test Lab ، به بخش تست روی دستگاه‌های موجود مراجعه کنید.
بله! Test Lab از تبلت گوگل پیکسل و گوگل پیکسل فولد پشتیبانی می‌کند. می‌توانید تست‌های خود را روی دستگاه‌های فیزیکی مستقل خود اجرا کنید. برای کسب اطلاعات بیشتر در مورد دستگاه‌های Test Lab ، به بخش تست روی دستگاه‌های موجود مراجعه کنید.
اگر برنامه خود را در Firebase آزمایش می‌کنید یا تست‌هایی را برای گزارش پیش از اجرا در Play Console اجرا می‌کنید، می‌توانید با بررسی ویژگی سیستمی firebase.test.lab در فایل MainActivity خود، تشخیص دهید که آیا یک تست روی دستگاهی که توسط Firebase میزبانی می‌شود، اجرا می‌شود یا خیر. سپس می‌توانید دستورات اضافی را بر اساس مقدار بولی برای testLabSetting اجرا کنید. برای اطلاعات بیشتر، به Modified test behaviors مراجعه کنید.
اگرچه برخی از این موارد در نقشه راه ما قرار دارند، اما در حال حاضر قادر به ارائه تعهد برای پشتیبانی از این پلتفرم‌های تست و توسعه برنامه نیستیم. با این حال، اگر برنامه خود را با چارچوبی ساخته‌اید که از Espresso پشتیبانی می‌کند (به عنوان مثال، Flutter)، می‌توانید با استفاده از Espresso یک تست ابزار دقیق بنویسید و سپس تست را در Test Lab اجرا کنید.
Test Lab صراحتاً از مبهم‌سازی یا رفع مبهم‌سازی پشتیبانی نمی‌کند. در حالی که احتمالاً برنامه اجرا خواهد شد، هرگونه داده مبهم‌سازی شده برنامه، مانند ردپاهای پشته، در گزارش‌ها به صورت مبهم‌سازی شده ظاهر می‌شوند.
بله! شما می‌توانید دستگاه تاشوی خود را در حالت‌ها و حالت‌های تاشو آزمایش کنید.
دستگاه‌های تاشو می‌توانند در حالت‌های مختلف تا شدن، مانند FLAT (کاملاً باز) یا HALF_OPENED (بین کاملاً باز و کاملاً بسته) باشند.
از سوی دیگر، حالت‌های قرارگیری شامل جهت‌گیری خاص دستگاه و حالت تاشو بودن آن هستند. به عنوان مثال، حالت روی میز که در جهت افقی حالت HALF_OPENED دارد، یا حالت کتابی که در جهت عمودی حالت HALF_OPENED دارد.
اگر در حال اجرای تست‌های ابزار دقیق هستید، می‌توانید از کتابخانه Jetpack WindowManager استفاده کنید و تست برنامه خود را روی مستندات foldables دنبال کنید تا در حالت‌ها و وضعیت‌های مختلف آزمایش کنید.
از طرف دیگر، وضعیت‌های موجود مختص دستگاه هستند و می‌توان با استفاده از 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روی دستگاه تاشو اجرا کنید.
گوگل پیکسل فولد (مدل ID 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}, ]
سامسونگ گلکسی زد فولد ۴ (شناسه مدل 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، برای استفاده از Test Lab نیازی به اضافه کردن Firebase SDK ندارید. اگر از قبل برنامه‌ای ندارید، می‌توانید یک APK را به صورت آنلاین دانلود کنید یا یک برنامه و یک APK آزمایشی را از یکی از نمونه‌های موجود در مخزن AndroidX GitHub بسازید. توجه داشته باشید که برای اجرای تست Robo فقط به فایل APK برنامه خود نیاز دارید، در حالی که یک تست Instrumentation به یک برنامه و یک APK آزمایشی که از کد منبع ساخته شده‌اند، نیاز دارد. برای اطلاعات بیشتر، درباره تست‌های Instrumented مطالعه کنید.
برای کسب اطلاعات بیشتر در مورد ویژگی‌های Test Lab ، به «شروع آزمایش برای اندروید با Firebase Test Lab مراجعه کنید.
تست تفاوت تصویر صفحه نمایش (Screenshot-diff testing ) تستی است که در آن ادعاهای تست بر اساس مقایسه تصاویر صفحه نمایش به دست آمده هنگام اجرای یک تست با تصاویر طلایی که نشان دهنده رفتار مورد انتظار هستند، انجام می‌شود. چنین تست‌هایی ممکن است در برخی از انواع دستگاه‌ها نسبت به سایرین شکننده‌تر باشند. توصیه می‌کنیم برای این نوع تست‌ها، دستگاه‌های شبیه‌ساز Arm ( *.arm ) را هدف قرار دهید. دستگاه‌های شبیه‌ساز Arm از تصاویری استفاده می‌کنند که بسیار شبیه یا یکسان با شبیه‌سازهای «عمومی» اندروید استودیو هستند.
ما همچنین توصیه می‌کنیم که کتابخانه‌های آزمایشی را بررسی کنید که می‌توانند به شما کمک کنند تا آزمایش‌های اسکرین‌شات را در صورت وجود تغییرات مورد انتظار، قوی‌تر کنید.
بله! دستگاه‌های مجازی زمانی به‌روزرسانی می‌شوند که تغییرات زیر اعمال شوند:
- به‌روزرسانی تصاویر موجود
- منسوخ شدن سطوح API قبلی
- سطوح جدید 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 در دسترس است و با استفاده از دستور describe از طریق کلاینت gcloud قابل دسترسی است:
gcloud firebase test android models describe MODEL
مشکلات شناخته شده
تست روبو نمی‌تواند از صفحات ورود به سیستم که نیاز به اقدامات اضافی کاربر فراتر از وارد کردن اعتبارنامه برای ورود دارند، مانند تکمیل یک CAPTCHA، عبور کند.
مشکلات شناخته‌شده‌ی مختص iOS
ورود خودکار با حساب گوگل در تست‌های Robo برای iOS+ (بتا) پشتیبانی نمی‌شود.
مشکلات شناخته‌شده مخصوص اندروید
تست Robo با برنامه‌هایی که از عناصر رابط کاربری چارچوب رابط کاربری اندروید (از جمله View ، ViewGroup و اشیاء WebView ) استفاده می‌کنند، بهترین عملکرد را دارد. اگر از تست Robo برای آزمایش برنامه‌هایی که از چارچوب‌های رابط کاربری دیگر، از جمله برنامه‌هایی که از موتور بازی Unity استفاده می‌کنند، استفاده می‌کنید، ممکن است تست بدون کاوش فراتر از صفحه اول خاتمه یابد.