Solução de problemas do Test Lab e Perguntas frequentes
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página fornece ajuda para solução de problemas e respostas a perguntas frequentes sobre a execução de testes com Firebase Test Lab. Os problemas conhecidos também estão
documentados. Caso você não encontre o que
procura ou precise de ajuda, entre no canal #test-lab
do
Slack para o Firebase ou entre em contato com o suporte da plataforma.
Solução de problemas
Por que meu teste está demorando tanto para ser executado?
Quando você seleciona um dispositivo com um nível alto de capacidade no catálogo de Test Lab,
os testes podem começar mais rapidamente. Quando um
dispositivo tem baixa capacidade, os testes podem levar mais tempo para serem executados. Se o número de
testes invocados for muito maior do que a capacidade dos dispositivos selecionados, os testes
poderão levar mais tempo para serem concluídos.
Os testes executados em qualquer nível de capacidade do dispositivo podem demorar mais por causa dos
fatores a seguir:
Tráfego, que afeta a disponibilidade do dispositivo e a velocidade de teste.
Falhas no dispositivo ou na infraestrutura, que podem acontecer a qualquer momento. Para verificar
se há uma infraestrutura relatada para Test Lab, consulte
Painel de status do Firebase.
Para saber mais sobre a capacidade de dispositivos em Test Lab, consulte a capacidade do dispositivo
para Android e iOS.
Por que os resultados do teste foram inconclusivos?
Os resultados inconclusivos geralmente acontecem devido a erros de infraestrutura
ou testes cancelados.
Os erros de infraestrutura são causados por problemas internos do Test Lab, como erros de rede
ou comportamentos inesperados em dispositivos. O Test Lab desativa internamente os testes
que produzem erros de infraestrutura várias vezes antes de relatar um
resultado inconclusivo. No entanto, é possível desativar essas tentativas usando a opção
failFast.
Repita o teste em Test Lab para verificar se é possível reproduzir.
Faça o teste em outro tipo de dispositivo, se aplicável.
Se o problema persistir, entre em contato com a equipe do Test Lab no
canal #test-lab no
Slack do Firebase.
Por que a fragmentação deixou meus testes mais
demorados?
A fragmentação pode fazer com que os testes sejam executados por mais tempo
quando o número de fragmentos especificado exceder o número de dispositivos disponíveis para uso no Test Lab. Para
evitar essa situação, tente usar outro dispositivo. Para mais informações
sobre como escolher um dispositivo diferente, consulte
Capacidade de dispositivos.
Por que está demorando muito
para o início do meu teste?
Quando solicitação de teste é enviada, o app é validado, assinado novamente etc. para
se preparar para executar testes em um dispositivo. Normalmente, esse processo é concluído
em menos de alguns segundos, mas pode ser afetado por fatores como o tamanho
do app.
Depois que o app estiver preparado, as execuções de teste são programadas e permanecem em uma fila
até que um dispositivo esteja pronto para a execução. Até que todas as execuções de teste terminem,
o status da matriz será "Pendente", independentemente de estarem na fila
ou sendo ativamente executadas.
Por que meu teste está demorando
muito?
Após a conclusão da execução do teste, é feito o download dos artefatos de teste no
dispositivo, processado e enviado para Cloud Storage. A duração desta etapa pode
ser afetada pela quantidade e pelo tamanho dos artefatos.
Perguntas frequentes
Quais são as cotas sem custos financeiros
para Test Lab? O que devo fazer se minha cota acabar?
O Firebase Test Lab oferece cotas sem custos financeiros para testes em dispositivos e para uso em
APIs do Cloud. A cota de teste usa o plano de preços padrão do Firebase,
ao contrário das cotas da API do Cloud.
Cota de teste
As cotas de testes são determinadas pelo número de dispositivos usados para executar testes.
O plano Spark do Firebase tem uma cota de testes fixa sem custo para os usuários. No
plano Blaze, suas cotas poderão aumentar se o uso do Google Cloud
crescer com o tempo. Se você alcançar o limite da sua cota de testes, aguarde até o
próximo dia ou faça upgrade para o plano Blaze se estiver no plano Spark.
Você poderá solicitar um aumento de cota caso já esteja no plano Blaze.
Para mais informações, consulte
Cota de teste.
A API Cloud Testing vem com dois limites de cota: solicitações diárias
e a cada 100 segundos, ambas por projeto. Você pode monitorar
o uso no
console do Google Cloud.
Cota da API Cloud Tool Results
A API Cloud Tool Results tem dois limites de cota: consultas diárias e a
cada 100 segundos, ambas por projeto. Você pode monitorar
o uso no
console do Google Cloud.
Consulte Cotas da API Cloud para Test Lab
para mais informações sobre os limites da API. Se você tiver alcançado o limite de uma cota de API:
Envie uma solicitação de aumento.
Para fazer isso, edite suas cotas
diretamente no console do Google Cloud. A maioria dos limites está definida como o
máximo por padrão;
ou solicite mais cota de API preenchendo um formulário no
Console do Google Cloud ou entrando
em contato com o
suporte do Firebase.
Como faço para descobrir se
o tráfego que chega ao back-end é proveniente de Test Lab?
No seu back-end, é possível determinar se o tráfego vem de dispositivos de teste hospedados pelo Firebase
ao verificar o endereço IP de origem em nossos
intervalos de IP.
O Test Lab funciona com
VPC-SC?
O Test Lab não funciona com o VPC SC, que bloqueia a
atividade de cópia de apps e outros artefatos de teste entre o armazenamento interno
do Test Lab e os buckets de resultados dos usuários.
Como detectar testes instáveis no
Test Lab?
Para detectar comportamentos instáveis nos testes, recomendamos o uso de
--num-flaky-test-attempts
. As novas execuções de flakes são faturadas ou contadas em relação à cota diária da mesma forma
que as execuções de teste normais.
Lembre-se:
Toda a execução do teste é executada novamente quando uma falha é detectada. Não há
suporte para repetir apenas casos de teste com falha.
As execuções de nova tentativa de despacho são programadas
para serem executadas ao mesmo tempo, mas não há garantia de que serão executadas em paralelo, por exemplo, quando o tráfego
exceder o número de dispositivos disponíveis.
O Test Lab tem suporte para
Appium, Flutter/FlutterDriver, ReactNative/Jest ou Cucumber?
Embora alguns desses itens estejam em nossos planos, não podemos garantir
compromisso de suporte com essas plataformas de testes e desenvolvimento de apps.
Onde posso encontrar detalhes
do dispositivo, como resolução etc.?
As informações detalhadas do dispositivo estão disponíveis na API e podem ser acessadas
no cliente gcloud usando o
comando "describe":
gcloud firebase test ios models describe MODEL
Posso usar a fragmentação com testes de iOS?
A fragmentação não tem suporte nativo no Test Lab para iOS. Porém, é possível
usar o cliente Flank para fragmentar casos de teste do iOS.
Para isso, defina a chave e os valores de OnlyTestIdentifiers no arquivo .xctestrun.
Consulte a página man de xcodebuild.xctestrun para saber mais.
Por que meu teste para iOS não tem vídeos nos
resultados?
No iOS 18 ou versões mais recentes, não é possível usar vídeos nos resultados.
Problemas conhecidos
Captchas de login
O teste Robo não pode ignorar as telas de login que exigem ação adicional do usuário além da inserção de credenciais para fazer login (como a conclusão de um CAPTCHA.
Suporte à estrutura de interface
O teste Robo funciona melhor com apps que usam elementos de IU do framework de IU do Android (incluindo objetos View, ViewGroup e WebView). Se ele for usado para testar apps que utilizam outras estruturas, incluindo o mecanismo de jogos Unity, ele provavelmente será encerrado sem passar da primeira tela.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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"]]
