이 페이지에서는 Firebase Test Lab을 사용한 테스트 실행과 관련하여 자주 묻는 질문에 대한 답변과 문제 해결 도움말을 제공합니다. 알려진 문제에 대해서도 문서화되어 있습니다. 원하는 내용을 찾을 수 없거나 추가 도움말이 필요하면 Firebase Slack의 #test-lab 채널에 가입하거나 Firebase 지원팀에 문의하세요.
문제 해결
테스트를 실행하는 데 시간이 오래 걸리는 이유는 무엇인가요?
Test Lab 카탈로그에서 용량 수준이 높은 기기를 선택하면 테스트가 더 빠르게 시작될 수 있습니다. 기기의 용량이 부족하면 테스트 실행 시간이 길어질 수 있습니다. 호출된 테스트의 수가 선택한 기기의 용량보다 훨씬 크면 테스트를 완료하는 데 시간이 더 오래 걸릴 수 있습니다
다음과 같은 요인으로 인해 기기 용량 수준에서 실행되는 테스트가 더 오래 걸릴 수 있습니다.
트래픽: 기기 가용성 및 테스트 속도에 영향을 미칩니다.
기기 또는 인프라 장애: 언제든지 발생할 수 있습니다. Test Lab에 대해 보고된 인프라 장애가 있는지 확인하려면 Firebase 상태 대시보드를 참조하세요.
Test Lab의 기기 용량에 관한 자세한 내용은 Android 및 iOS의 기기 용량 정보를 참고하세요.
불충분한 테스트 결과가 표시되는 이유는 무엇인가요?
불충분한 테스트 결과는 일반적으로 테스트 실행 취소 또는 인프라 오류 때문에 발생합니다.
인프라 오류는 네트워크 오류나 예상치 못한 기기 동작과 같은 Test Lab 내부 문제로 인해 발생합니다. Test Lab은 불충분한 결과를 보고하기 전에 인프라 오류를 여러 번 유발한 테스트 실행을 내부적으로 재시도하지만 failFast를 사용하여 이러한 재시도를 사용 중지할 수 있습니다.
문제가 지속되면 Firebase Slack의 #test-lab 채널에서 Test Lab팀에 문의하세요.
샤딩으로 인해 테스트가 더 오래 실행되는 이유는 무엇인가요?
지정된 샤드 수가 Test Lab에서 사용할 수 있는 기기 수를 초과할 경우 샤딩으로 인해 테스트가 더 오래 실행될 수 있습니다. 이러한 상황을 방지하려면 다른 기기로 전환해 보세요. 다른 기기 선택에 관한 자세한 내용은
기기 용량
테스트를 시작하는 데 시간이 오래 걸리는 이유는 무엇인가요?
테스트 요청을 제출하면 기기에서 테스트를 실행하기 위해 먼저 앱을 검증하고 다시 서명하는 등의 준비 과정을 거칩니다. 일반적으로 이 프로세스는 몇 초 이내에 완료되지만 앱의 크기와 같은 요소에 영향을 받을 수 있습니다.
앱이 준비되면 테스트 실행이 예약되고 기기에서 테스트를 실행할 준비가 될 때까지 큐에 남아 있습니다. 모든 테스트 실행이 완료될 때까지 매트릭스는 '대기 중' 상태가 됩니다(테스트 실행이 큐에 있는지 또는 현재 실행 중인지는 관계없음).
테스트를 완료하는 데 시간이 오래 걸리는 이유는 무엇인가요?
테스트 실행이 완료되면 기기에서 테스트 아티팩트를 다운로드하여 처리한 다음 Cloud Storage에 업로드합니다. 이 단계에 소요되는 시간은 아티팩트의 양과 크기에 영향을 받을 수 있습니다.
자주 묻는 질문(FAQ)
Test Lab의 무료 할당량은 어떻게 되나요? 할당량이 부족하면 어떻게 해야 하나요?
Firebase Test Lab은 기기에서 테스트를 수행하고 Cloud API를 사용하는 데 필요한 무료 할당량을 제공합니다. 테스트 할당량에는 Cloud API 할당량과 달리 스탠더드 Firebase 요금제가 사용됩니다.
테스트 할당량
테스트 할당량은 테스트 실행에 사용되는 기기 수에 따라 결정됩니다.
Firebase Spark 요금제는 사용자에게 정해진 테스트 할당량을 무료로 제공합니다. Blaze 요금제에서는 시간이 지남에 따라 Google Cloud 사용량이 증가하면 할당량이 증가할 수 있습니다. 테스트 할당량에 도달한 경우 다음 날까지 기다리거나 현재 Spark 요금제를 사용 중인 경우 Blaze 요금제로 업그레이드하세요.
이미 Blaze 요금제를 사용 중이면 할당량 상향 조정을 요청할 수 있습니다.
자세한 내용은 테스트 할당량을 참조하세요.
Google Cloud 콘솔에서 직접 할당량을 수정하여 할당량 상향 조정 요청을 제출합니다. 기본적으로 대부분의 한도는 최댓값으로 설정됩니다.
Google Cloud 콘솔에서 요청 양식을 작성하거나 Firebase 지원팀에 연락하여 API 할당량 상향 조정을 요청합니다.
내 백엔드에 도달하는 트래픽이 Test Lab에서 출발했는지 확인하려면 어떻게 해야 하나요?
백엔드에서 Google IP 범위와 소스 IP 주소를 대조하면 트래픽이 Firebase에서 호스팅되는 테스트 기기에서 출발했는지 확인할 수 있습니다.
Test Lab은 VPC-SC와 함께 작동하나요?
Test Lab은 Test Lab 내부 스토리지와 사용자 결과 버킷 간에 앱 및 기타 테스트 아티팩트의 복사를 차단하는 VPC-SC와 함께 작동하지 않습니다.
Test Lab에서 불안정한 테스트를 감지하려면 어떻게 해야 하나요?
테스트에서 불안정한 동작을 감지하려면
--num-flaky-test-attempts
옵션을 사용하는 것이 좋습니다. 불안정 제거 재실행도 일반 테스트 실행과 마찬가지로 요금이 청구되거나 일일 할당량에 반영됩니다.
다음 사항에 유의하세요.
실패가 감지되면 전체 테스트 실행이 다시 실행됩니다. 실패한 테스트 사례만 재시도하는 기능은 지원되지 않습니다.
불안정 제거 재시도는 동시에 실행되도록 예약되지만 트래픽이 가용 기기 수를 초과하는 경우 등에는 동시에 실행되지 않을 수 있습니다.
Test Lab에서 Appium, Flutter/FlutterDriver, ReactNative/Jest, Cucumber가 지원되나요?
일부는 로드맵에 포함되어 있기는 하지만 현재로서는 이러한 테스트 및 앱 개발 플랫폼 지원을 약속할 수 없습니다.
해상도 등의 기기 세부정보는 어디에서 찾을 수 있나요?
자세한 기기 정보는 API를 통해 제공되며 describe 명령어를 사용하여 gcloud 클라이언트에서 액세스할 수 있습니다.
gcloud firebase test ios models describe MODEL
iOS 테스트에서 샤딩을 사용할 수 있나요?
샤딩은 iOS용 Test Lab 내에서 기본적으로 지원되지는 않습니다. 하지만 Flank 클라이언트를 사용하여 iOS 테스트 사례를 샤딩할 수 있습니다.
.xctestrun 파일에서 OnlyTestIdentifiers 키와 값을 설정하면 됩니다.
자세한 내용은 xcodebuild.xctestrun의 man 페이지를 참고하세요.
iOS 테스트 결과에 동영상이 누락된 이유는 무엇인가요?
iOS 18 이상에서는 검색 결과에 동영상이 표시되지 않습니다.
알려진 문제
로그인 보안문자
Robo 테스트는 로그인을 위해 사용자 인증 정보 입력 이외에 보안문자 입력 등의 추가적인 사용자 작업이 필요한 로그인 화면을 우회하지 못합니다.
UI 프레임워크 지원
Robo 테스트는 Android UI 프레임워크의 UI 요소(View, ViewGroup, WebView 객체 포함)를 사용하는 앱과 가장 잘 작동합니다. Unity 게임 엔진을 사용하는 앱을 포함하여 다른 UI 프레임워크를 사용하는 앱을 Robo 테스트로 시험하면 테스트가 첫 화면에서 종료될 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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"]]
