Khắc phục sự cố trong Phòng thử nghiệm & Câu hỏi thường gặp
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Trang này cung cấp thông tin trợ giúp khắc phục sự cố và giải đáp các câu hỏi thường gặp về việc chạy thử nghiệm bằng Firebase Test Lab. Các vấn đề đã biết cũng được ghi lại. Nếu bạn không tìm thấy nội dung mình cần hoặc cần được trợ giúp thêm, hãy tham gia kênh #test-lab trên Firebase Slack hoặc liên hệ với Nhóm hỗ trợ Firebase.
Khắc phục sự cố
Tại sao thử nghiệm của tôi mất quá nhiều thời gian để chạy?
Khi bạn chọn một thiết bị có mức dung lượng cao trong danh mục Test Lab, các kiểm thử có thể bắt đầu nhanh hơn. Khi thiết bị có dung lượng thấp, các kiểm thử có thể mất nhiều thời gian hơn để chạy. Nếu số lượng kiểm thử được gọi lớn hơn nhiều so với khả năng của các thiết bị đã chọn, thì các kiểm thử có thể mất nhiều thời gian hơn để hoàn tất.
Các kiểm thử chạy ở bất kỳ cấp độ nào về dung lượng thiết bị đều có thể mất nhiều thời gian hơn do các yếu tố sau:
Lưu lượng truy cập, ảnh hưởng đến khả năng truy cập vào thiết bị và tốc độ kiểm thử.
Thiết bị hoặc cơ sở hạ tầng gặp sự cố, có thể xảy ra bất cứ lúc nào. Để kiểm tra xem có cơ sở hạ tầng nào được báo cáo cho Test Lab hay không, hãy xem trang tổng quan về trạng thái của Firebase.
Để tìm hiểu thêm về dung lượng thiết bị trong Test Lab, hãy xem thông tin về dung lượng thiết bị cho Android và iOS.
Tại sao tôi nhận được kết quả thử nghiệm không thể đưa ra kết luận?
Kết quả kiểm thử không kết luận được thường xảy ra do các lần chạy kiểm thử bị huỷ hoặc lỗi cơ sở hạ tầng.
Lỗi cơ sở hạ tầng là do các vấn đề nội bộ Test Lab gây ra, chẳng hạn như lỗi mạng hoặc hành vi không mong muốn của thiết bị. Test Lab sẽ tự động huỷ các lần chạy thử nghiệm tạo ra lỗi cơ sở hạ tầng nhiều lần trước khi báo cáo kết quả không xác định; tuy nhiên, bạn có thể tắt các lần thử lại này bằng cách sử dụng failFast.
Để xác định nguyên nhân gây ra lỗi, hãy làm theo các bước sau:
Thử lại kiểm thử trong Test Lab để xác minh rằng kiểm thử có thể tái tạo.
Hãy thử chạy kiểm thử trên một thiết bị hoặc loại thiết bị khác (nếu có).
Nếu vấn đề vẫn tiếp diễn, hãy liên hệ với nhóm Test Lab trong kênh#test-lab trên Firebase Slack.
Tại sao việc phân đoạn lại khiến các kiểm thử của tôi chạy lâu hơn?
Phân đoạn có thể khiến các chương trình kiểm thử của bạn chạy lâu hơn khi số lượng phân đoạn mà bạn chỉ định vượt quá số lượng thiết bị có thể sử dụng trong Test Lab. Để tránh tình trạng này, hãy thử chuyển sang một thiết bị khác. Để biết thêm thông tin về cách chọn một thiết bị khác, hãy xem phần
Dung lượng thiết bị.
Tại sao quá trình kiểm thử của tôi mất nhiều thời gian để bắt đầu?
Khi bạn gửi một yêu cầu kiểm thử, trước tiên, ứng dụng của bạn sẽ được xác thực, ký lại, v.v. để chuẩn bị chạy các kiểm thử trên một thiết bị. Thông thường, quá trình này hoàn tất trong vòng vài giây, nhưng có thể bị ảnh hưởng bởi các yếu tố như kích thước của ứng dụng.
Sau khi ứng dụng của bạn được chuẩn bị, các lần thực thi kiểm thử sẽ được lên lịch và vẫn nằm trong hàng đợi cho đến khi một thiết bị sẵn sàng chạy ứng dụng đó. Cho đến khi tất cả các lần thực thi kiểm thử hoàn tất, trạng thái ma trận sẽ là "Đang chờ xử lý" (bất kể các lần thực thi kiểm thử có nằm trong hàng đợi hay đang chạy hay không).
Tại sao quá trình kiểm thử của tôi mất nhiều thời gian để hoàn tất?
Sau khi quá trình thực thi kiểm thử hoàn tất, các cấu phần phần mềm kiểm thử sẽ được tải xuống từ thiết bị, xử lý và tải lên Cloud Storage. Thời lượng của bước này có thể bị ảnh hưởng bởi số lượng và kích thước của các cấu phần phần mềm.
Câu hỏi thường gặp
Test Lab có những hạn mức miễn phí nào? Tôi nên làm gì nếu hết giấy phép?
Firebase Test Lab cung cấp hạn mức miễn phí để kiểm thử trên các thiết bị và để sử dụng Cloud API. Xin lưu ý rằng hạn mức kiểm thử sử dụng gói giá tiêu chuẩn của Firebase, trong khi hạn mức Cloud API thì không.
Hạn mức kiểm thử
Hạn mức kiểm thử được xác định bằng số lượng thiết bị dùng để chạy kiểm thử.
Gói Spark của Firebase có hạn mức kiểm thử cố định mà người dùng không phải trả phí. Đối với gói Blaze, hạn mức của bạn có thể tăng lên nếu mức sử dụng Google Cloud của bạn tăng theo thời gian. Nếu bạn đạt đến hạn mức kiểm thử, hãy đợi đến ngày hôm sau hoặc nâng cấp lên gói Blaze nếu bạn đang dùng gói Spark.
Nếu đang sử dụng gói Blaze, bạn có thể yêu cầu tăng hạn mức.
Để biết thêm thông tin, hãy xem phần Kiểm thử hạn mức.
Cloud Testing API có 2 hạn mức: số yêu cầu mỗi ngày cho mỗi dự án và số yêu cầu mỗi 100 giây cho mỗi dự án. Bạn có thể theo dõi mức sử dụng trong bảng điều khiển Google Cloud.
Hạn mức Cloud Tool Results API
Cloud Tool Results API có 2 hạn mức: số lượng truy vấn mỗi ngày cho mỗi dự án và số lượng truy vấn mỗi 100 giây cho mỗi dự án. Bạn có thể theo dõi mức sử dụng trong bảng điều khiển Google Cloud.
Gửi yêu cầu tăng hạn mức bằng cách chỉnh sửa hạn mức ngay trong bảng điều khiển Google Cloud (lưu ý rằng theo mặc định, hầu hết các hạn mức đều được đặt ở mức tối đa), hoặc
Yêu cầu tăng hạn mức truy cập API bằng cách điền vào biểu mẫu yêu cầu trong bảng điều khiển Google Cloud hoặc bằng cách liên hệ với Nhóm hỗ trợ Firebase.
Làm cách nào để biết lưu lượng truy cập đến phần phụ trợ của tôi có phải đến từ Test Lab hay không?
Từ phần phụ trợ, bạn có thể xác định xem lưu lượng truy cập có đến từ các thiết bị kiểm thử do Firebase lưu trữ hay không bằng cách kiểm tra địa chỉ IP nguồn dựa trên dải IP của chúng tôi.
Test Lab có hoạt động với VPC-SC không?
Test Lab không hoạt động với VPC-SC. VPC-SC sẽ chặn việc sao chép ứng dụng và các cấu phần phần mềm kiểm thử khác giữa bộ nhớ trong của Test Lab và các nhóm kết quả của người dùng.
Làm cách nào để phát hiện các kiểm thử không ổn định trong Test Lab?
Để phát hiện hành vi không ổn định trong các kiểm thử, bạn nên sử dụng lựa chọn
--num-flaky-test-attempts
. Các lần chạy lại để loại bỏ lỗi sẽ được tính phí hoặc tính vào hạn mức hằng ngày của bạn giống như các lần thực thi kiểm thử thông thường.
Hãy ghi nhớ những điều sau:
Toàn bộ quá trình thực thi kiểm thử sẽ chạy lại khi phát hiện thấy lỗi. Không có tính năng hỗ trợ thử lại chỉ các trường hợp kiểm thử không thành công.
Các lần chạy thử lại để loại bỏ lỗi không ổn định được lên lịch chạy cùng lúc, nhưng không đảm bảo chạy song song, chẳng hạn như khi lưu lượng truy cập vượt quá số lượng thiết bị có sẵn.
Test Lab có hỗ trợ Appium, Flutter/FlutterDriver, ReactNative/Jest hay Cucumber không?
Mặc dù một số mục này nằm trong lộ trình của chúng tôi, nhưng hiện tại chúng tôi không thể cam kết hỗ trợ các nền tảng thử nghiệm và phát triển ứng dụng này.
Tôi có thể tìm thông tin chi tiết về thiết bị (chẳng hạn như độ phân giải) ở đâu?
Thông tin chi tiết về thiết bị có trong API và có thể truy cập từ ứng dụng gcloud bằng lệnh mô tả:
gcloud firebase test ios models describe MODEL
Tôi có thể sử dụng tính năng phân đoạn với các kiểm thử iOS không?
Phân đoạn không được hỗ trợ nguyên bản trong Test Lab cho iOS. Tuy nhiên, bạn có thể sử dụng ứng dụng Flank để phân đoạn các trường hợp kiểm thử iOS.
Cách này hoạt động bằng cách đặt khoá và giá trị OnlyTestIdentifiers trong tệp .xctestrun.
Hãy xem trang man để biết thêm thông tin về xcodebuild.xctestrun.
Tại sao kết quả kiểm thử trên iOS của tôi lại thiếu video?
Đối với iOS 18 trở lên, chúng tôi không thể hỗ trợ video trong kết quả.
Các vấn đề đã biết
Hình ảnh xác thực khi đăng nhập
Thử nghiệm bằng robot không thể bỏ qua những màn hình đăng nhập yêu cầu người dùng thực hiện thêm hành động ngoài việc nhập thông tin đăng nhập để đăng nhập, ví dụ: hoàn tất CAPTCHA.
Hỗ trợ khung giao diện người dùng
Thử nghiệm bằng Robo hoạt động hiệu quả nhất với những ứng dụng sử dụng các phần tử giao diện người dùng trong khung giao diện người dùng Android (bao gồm cả các đối tượng View, ViewGroup và WebView). Nếu bạn sử dụng Kiểm thử bằng Robo để thực thi các ứng dụng dùng những khung giao diện người dùng khác, bao gồm cả các ứng dụng dùng công cụ trò chơi Unity, thì quá trình kiểm thử có thể thoát mà không khám phá thêm ngoài màn hình đầu tiên.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-09-05 UTC."],[],[],null,["\u003cbr /\u003e\n\niOS Android \n\nThis page provides troubleshooting help and answers to frequently asked\nquestions about running tests with Firebase Test Lab. Known issues are also\ndocumented. If you can't find what\nyou're looking for or need additional help, join the [#test-lab\nchannel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack or contact [Firebase\nsupport](https://support.google.com/firebase/contact/support).\n\nTroubleshooting\n\n\u003cbr /\u003e\n\nWhy is my test taking so long to run?\n\n\u003cbr /\u003e\n\nWhen you select a device with a high capacity level in the Test Lab\ncatalog, tests may start faster. When a\ndevice has low capacity, tests might take longer to run. If the number of\ntests invoked is much larger than the capacity of the selected devices, tests\ncan take longer to finish.\n\n\nTests running on any level device capacity level may take longer due to the\nfollowing factors:\n\n- Traffic, which affects device availability and test speed.\n- 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](https://status.firebase.google.com/summary).\n\n\nTo learn more about device capacity in Test Lab, see device capacity\ninformation for [Android](https://firebase.google.com/docs/test-lab/android/available-testing-devices#device-capacity) and [iOS](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device-capacity).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy am I receiving inconclusive test results?\n\n\u003cbr /\u003e\n\nInconclusive test outcomes commonly occur either because of canceled test runs\nor infrastructure errors.\n\nInfrastructure errors are caused by internal Test Lab issues, like network\nerrors or unexpected device behaviors. Test Lab internally retires test runs\nthat produce infrastructure errors multiple times before reporting an\ninconclusive outcome; however, you can disable these retries using\n[failFast](/docs/test-lab/reference/testing/rest/v1/projects.testMatrices#TestMatrix.FIELDS.fail_fast).\n\nTo determine the cause of the error, follow these steps:\n\n1. Check for known outages in the [Firebase status dashboard](https://status.firebase.google.com/summary).\n2. Retry the test in Test Lab to verify that it is reproducible.\n\n | **Note:** Test Lab does not charge you for infrastructure errors.\n3. Try running the test on a different device or device type, if applicable.\n\nIf the issue persists, contact the Test Lab team in the\n[#test-lab channel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy did sharding make my tests run\nlonger?\n\n\u003cbr /\u003e\n\nSharding can cause your tests to run longer when the number of shards you\nspecified exceeds the number of devices available for use in Test Lab. To\navoid this situation, try switching to a different device. For more information\nabout choosing a different device, see\n\n[Device Capacity](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device_capacity).\n\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to start?\n\n\u003cbr /\u003e\n\nWhen you submit a test request, your app is first validated, re-signed, etc. in\npreparation for running tests on a device. Normally, this process completes in\nless than a few seconds, but it can be affected by factors like the size of your\napp.\n\nAfter your app is prepared, test executions are scheduled and remain in a queue\nuntil a device is ready to run it. Until all test executions finish running,\nthe matrix status will be \"Pending\" (regardless of whether test executions are\nin the queue or actively running).\n| **Note:** The time your test spends waiting for an available device does not count toward your billing time.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to finish?\n\n\u003cbr /\u003e\n\nAfter the test execution is finished, test artifacts are downloaded from the\ndevice, processed, and uploaded to Cloud Storage. The duration of this step can\nbe affected by the amount and size of the artifacts.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nFrequently asked questions\n\n\u003cbr /\u003e\n\nWhat are the no-cost quotas\nfor Test Lab? What should I do if I run out?\n\n\u003cbr /\u003e\n\nFirebase Test Lab offers no-cost quotas for testing on devices and for using\nCloud APIs. Note that the testing quota uses the standard Firebase pricing plan,\nwhile the Cloud API quotas do not.\n\n- **Testing quota**\n\n Testing quotas are determined by the number of devices used to run tests.\n The Firebase Spark plan has a fixed testing quota at no cost to users. For\n the Blaze plan, your quotas might increase if your usage of Google Cloud\n increases over time. If you reach your testing quota, wait until the next\n day or upgrade to the Blaze plan if you are currently on the Spark plan.\n If you are already on the Blaze plan, you can request a quota increase.\n For more information, see\n [Testing quota](/docs/test-lab/usage-quotas-pricing#testing-quota).\n\n You can monitor your testing quota usage in the [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Testing API quota**\n\n The Cloud Testing API comes with two quota limits: requests per day per\n project, and requests per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Tool Results API quota**\n\n The Cloud Tool Results API comes with two quota limits: queries per day per\n project, and queries per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/toolresults.googleapis.com/quotas).\n\n Refer to [Cloud API quotas for Test Lab](/docs/test-lab/usage-quotas-pricing#cloud-api-quota)\n for more information on API limits. If you've reached an API quota:\n - Submit a request for higher quotas by\n [editing your quotas](https://cloud.google.com/docs/quota#requesting_higher_quota)\n directly in the Google Cloud console (note that most limits are set to\n maximum by default), or\n\n - Request higher API quotas by filling out a request form in the\n Google Cloud console or by contacting\n [Firebase support](https://support.google.com/firebase/contact/support).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I find out if the\ntraffic reaching my backend is coming from Test Lab?\n\n\u003cbr /\u003e\n\nFrom your backend, you can determine if traffic is coming from Firebase-hosted\ntest devices by checking the source IP address against our\n[IP ranges](https://firebase.google.com/docs/test-lab/android/get-started#ip-blocks).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab work with\nVPC-SC?\n\n\u003cbr /\u003e\n\nTest Lab does not work with VPC-SC, which blocks the\ncopying of apps and other test artifacts between Test Lab's internal\nstorage and users' results buckets.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I detect flaky tests in\nTest Lab?\n\n\u003cbr /\u003e\n\nTo detect flaky behavior in your tests, we recommend using the\n\n[--num-flaky-test-attempts](https://cloud.google.com/sdk/gcloud/reference/firebase/test/ios/run#--num-flaky-test-attempts)\n\noption. Deflake reruns are billed or counted toward your daily quota the same as\nnormal test executions.\n\nKeep the following in mind:\n\n- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.\n- 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.\n\n| **Note:** Infrastructure errors are independent from the deflake feature and don't trigger deflake reruns.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab support\nAppium, Flutter/FlutterDriver, ReactNative/Jest, or Cucumber?\n\n\u003cbr /\u003e\n\nWhile some of these items are on our roadmap, we're currently unable to provide\ncommitment to supporting these testing and app development platforms.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhere can I find device details,\nlike resolution, etc.?\n\n\u003cbr /\u003e\n\nDetailed device information is available through the API and can be accessed\nfrom the gcloud client using the\n[describe command](https://cloud.google.com/sdk/gcloud/reference/firebase/test/android/models/describe):\n\n`gcloud firebase test ios models describe `\u003cvar translate=\"no\"\u003eMODEL\u003c/var\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nCan I use sharding with iOS tests?\n\n\u003cbr /\u003e\n\nSharding isn't natively supported within Test Lab for iOS. However, you can\nuse the [Flank](https://flank.github.io/flank/) client to shard iOS test cases.\n| **Note:** Using Flank iOS sharding creates separate test matrices for each shard.\n\nThis works by setting `OnlyTestIdentifiers` key and values in `.xctestrun` file.\nSee `man` page for `xcodebuild.xctestrun` for more details.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is my iOS test missing videos in the\nresults?\n\n\u003cbr /\u003e\n\nFor iOS 18 or later, we are not able to support videos in the results.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown issues\n\n\u003cbr /\u003e\n\nSign-in Captchas\n\n\u003cbr /\u003e\n\nRobo test cannot bypass sign-in screens that require\nadditional user action beyond entering credentials to sign in, for example,\ncompleting a CAPTCHA.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nUI framework support\n\n\u003cbr /\u003e\n\nRobo test works best with apps that use UI elements from the Android UI\nframework (including `View`, `ViewGroup`, and `WebView`\nobjects). If you use Robo test to exercise apps that use other UI\nframeworks, including apps that use the Unity game engine, the test may exit\nwithout exploring beyond the first screen.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e"]]