Esta página fornece ajuda para solução de problemas e respostas a perguntas frequentes sobre a execução de testes com o Firebase Test Lab. Problemas conhecidos também são documentados. Se você não encontrar o que procura ou precisar de ajuda adicional, participe do canal #test-lab no Firebase Slack ou entre em contato com o suporte do Firebase .
Solução de problemas
Ao selecionar um dispositivo com alto nível de capacidade no catálogo do Test Lab, os testes podem iniciar mais rapidamente. Quando um dispositivo tem baixa capacidade, os testes podem demorar mais para serem executados. Se o número de testes invocados for muito maior que a capacidade dos dispositivos selecionados, os testes poderão demorar mais para serem concluídos.
Os testes executados em qualquer nível de capacidade do dispositivo podem demorar mais devido aos seguintes fatores:
- Tráfego, que afeta a disponibilidade do dispositivo e a velocidade do teste.
- Falhas de dispositivos ou infraestrutura, que podem acontecer a qualquer momento. Para verificar se existe uma infraestrutura reportada para o Test Lab, consulte o painel de status do Firebase .
Para saber mais sobre a capacidade do dispositivo no Test Lab, consulte informações de capacidade do dispositivo para Android e iOS .
Resultados de testes inconclusivos geralmente ocorrem devido a execuções de testes canceladas ou erros de infraestrutura.
Erros de infraestrutura são causados por problemas internos do Test Lab, como erros de rede ou comportamentos inesperados do dispositivo. O Test Lab descontinua internamente as execuções de testes que produzem erros de infraestrutura diversas vezes antes de relatar um resultado inconclusivo; no entanto, você pode desabilitar essas tentativas usando failFast .
Para determinar a causa do erro, siga estas etapas:
- Verifique se há interrupções conhecidas no painel de status do Firebase .
Tente novamente o teste no Test Lab para verificar se ele é reproduzível.
Tente executar o teste em um dispositivo ou tipo de dispositivo diferente, se aplicável.
Se o problema persistir, entre em contato com a equipe do Test Lab no canal #test-lab no Firebase Slack.
A fragmentação pode fazer com que seus testes sejam executados por mais tempo quando o número de estilhaços especificado exceder o número de dispositivos disponíveis para uso no Test Lab. Para evitar esta situação, tente mudar para um dispositivo diferente. Para obter mais informações sobre como escolher um dispositivo diferente, consulteDevice Capacity .
Quando você envia uma solicitação de teste, seu aplicativo é primeiro validado, assinado novamente, etc., em preparação para a execução de testes em um dispositivo. Normalmente, esse processo é concluído em menos de alguns segundos, mas pode ser afetado por fatores como o tamanho do seu aplicativo.
Depois que seu aplicativo estiver preparado, as execuções de teste serão agendadas e permanecerão em fila até que um dispositivo esteja pronto para executá-lo. Até que todas as execuções de teste terminem de ser executadas, o status da matriz será "Pendente" (independentemente de as execuções de teste estarem na fila ou em execução ativa).
Após a conclusão da execução do teste, os artefatos de teste são baixados do dispositivo, processados e enviados para o Cloud Storage. A duração desta etapa pode ser afetada pela quantidade e tamanho dos artefatos.
Os artefatos de execução de testes (como capturas de tela e arquivos de registro) são armazenados no Google Cloud Storage e renderizados diretamente no console do Firebase. Se a execução do seu teste foi realizada nos últimos 90 dias, verifique se você atribuiu funções no nível do projeto (proprietário do projeto, editor do projeto ou visualizador do projeto). Certifique-se também de que o Cloud Audit Logging não esteja habilitado para seu projeto ou organização.
Se a execução foi realizada há mais de 90 dias, provavelmente os artefatos de teste foram excluídos automaticamente. Você pode verificar a configuração do intervalo de resultados clicando na guia Resultados do teste no painel do Test Lab. O bucket de resultados padrão é configurado para reter objetos por 90 dias.
Para reter seus artefatos de teste por mais tempo, execute o comando gcloud firebase test android run com a sinalização --results-bucket e passe o nome do bucket de resultados. Para obter mais informações, visite a documentação de referência gcloud firebase test android run .
Ao executar testes de instrumentação, você poderá ver erros de teste indicando resultados parciais que contêm mensagens como Test run failed to complete. Expected x tests, received y (onde y é menor que x ). Este erro significa que o Test Lab não conseguiu analisar o logcat para marcadores de início ou fim do caso de teste que geralmente são gerados por AndroidJUnitRunner .
A seguir estão as causas comuns desse problema:
| Descrição do problema | Possível resolução |
|---|---|
| O caso de teste não foi executado devido a um tempo limite. Se a duração total dos testes for maior que o tempo limite especificado ou maior que o tempo limite máximo , o Test Lab cancelará o restante dos casos de teste. |
|
| O caso de teste não foi concluído porque foi encerrado prematuramente ou travou. O caso de teste pode ser encerrado prematuramente devido a uma exceção não detectada ou a um erro de asserção. Os casos de teste podem ficar presos em um loop infinito ou não conseguir prosseguir, por exemplo, se o aplicativo não mostrar a visualização correta e o caso de teste não conseguir executar a ação na IU. | Confira o vídeo e o logcat para investigar onde o teste parou. |
Um executor de teste personalizado (incluindo a extensão do AndroidJUnitRunner) travou inesperadamente ou gravou marcadores inesperados de início ou fim do caso de teste no logcat . | Verifique seu código do executor de teste. |
Logs excessivos foram gravados em logcat , o que sobrecarregou o buffer ou travou o processo logcat . | Reduza as gravações no logcat . |
| O aplicativo em teste travou. | Depure seu aplicativo. |
Perguntas frequentes
O Firebase Test Lab oferece cotas gratuitas para testes em dispositivos e para uso de APIs do Cloud. Observe que a cota de teste usa o plano de preços padrão do Firebase, enquanto as cotas da API Cloud não.
Cota de testes
As cotas de teste são determinadas pelo número de dispositivos usados para executar testes. O plano Firebase Spark possui uma cota fixa de testes sem nenhum custo para os usuários. Para o plano Blaze, suas cotas poderão aumentar se o uso do Google Cloud aumentar ao longo do tempo. Se você atingir sua cota de testes, espere até o dia seguinte ou atualize para o plano Blaze se você estiver atualmente no plano Spark. Se você já está no plano Blaze, pode solicitar um aumento de cota. Para obter mais informações, consulte Testando cota .
Você pode monitorar o uso da cota de teste no console do Google Cloud .
Cota da API Cloud Testing
A API Cloud Testing vem com dois limites de cota: solicitações por dia por projeto e solicitações a cada 100 segundos por projeto. Você pode monitorar seu uso no console do Google Cloud .
Cota da API Cloud Tool Results
A API Cloud Tool Results vem com dois limites de cota: consultas por dia por projeto e consultas a cada 100 segundos por projeto. Você pode monitorar seu uso no console do Google Cloud .
Consulte Cotas da API Cloud para Test Lab para obter mais informações sobre os limites da API. Se você atingiu uma cota de API:
Envie uma solicitação de cotas mais altas editando-as diretamente no console do Google Cloud (observe que a maioria dos limites é definida como máximo por padrão) ou
Solicite cotas de API mais altas preenchendo um formulário de solicitação no console do Google Cloud ou entrando em contato com o suporte do Firebase .
No back-end, você pode determinar se o tráfego vem de dispositivos de teste hospedados no Firebase verificando o endereço IP de origem em relação aos nossos intervalos de IP .
O Test Lab não funciona com VPC-SC, que bloqueia a cópia de aplicativos e outros artefatos de teste entre o armazenamento interno do Test Lab e os buckets de resultados dos usuários.
Para detectar comportamento instável em seus testes, recomendamos usar a opção--num-flaky-test-attempts. As novas execuções do Deflake são cobradas ou contabilizadas em sua cota diária da mesma forma que as execuções normais de teste.
Tenha o seguinte em mente:
- 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 novas tentativas do Deflake são programadas para execução ao mesmo tempo, mas não há garantia de execução em paralelo, por exemplo, quando o tráfego excede o número de dispositivos disponíveis.
Sim! O Test Lab oferece suporte ao Google Pixel Watch. Agora você pode executar testes em seu aplicativo Wear independente no Google Pixel Watches. Para saber mais sobre os dispositivos do Test Lab, consulte Testar em dispositivos disponíveis .
Sim! O Test Lab oferece suporte ao Google Pixel Tablet e ao Google Pixel Fold. Você pode executar seus testes em dispositivos físicos independentes. Para saber mais sobre os dispositivos do Test Lab, consulte Testar em dispositivos disponíveis .
Se você estiver testando seu aplicativo no Firebase ou executando testes para um relatório de pré-lançamento no Play Console, poderá detectar se um teste está sendo executado em um dispositivo hospedado no Firebase verificando a propriedade do sistema firebase.test.lab em seu arquivo MainActivity . Você pode então executar instruções adicionais com base no valor booleano de testLabSetting . Para obter mais informações, consulte Comportamentos de teste modificados .
Embora alguns desses itens estejam em nosso roteiro, no momento não podemos nos comprometer a oferecer suporte a essas plataformas de teste e desenvolvimento de aplicativos. No entanto, se você criou seu aplicativo com uma estrutura compatível com o Espresso (por exemplo, Flutter), poderá escrever um teste de instrumentação usando o Espresso e, em seguida, executar o teste no Test Lab.
O Test Lab não oferece suporte explícito à ofuscação ou desofuscação. Embora o aplicativo provavelmente seja executado, quaisquer dados ofuscados do aplicativo, como rastreamentos de pilha, aparecerão como ofuscados nos logs.
Sim! Você pode testar seu dispositivo dobrável em estados e posturas dobráveis .
Os dispositivos dobráveis podem estar em vários estados dobrados, como FLAT (totalmente aberto) ou HALF_OPENED (entre totalmente aberto e completamente fechado).
As posturas, por outro lado, consistem na orientação específica do dispositivo e no estado dobrável. Por exemplo, postura de mesa, que é um estado HALF_OPENED na orientação horizontal, ou postura de livro, que é um estado HALF_OPENED na orientação vertical.
Se estiver executando testes de instrumentação, você pode usar a biblioteca Jetpack WindowManager e testar seu aplicativo na documentação dobrável para testar em diferentes estados e posturas.
Alternativamente, os estados disponíveis são específicos do dispositivo e podem ser interagidos usando o adb shell command cmd device_state .
- Para listar o estado atual, execute
adb shell cmd device_state state. - Para definir ou substituir o estado atual, execute
adb shell cmd device_state state <IDENTIFIER>. - Para redefinir o estado, execute
adb shell cmd device_state state reset. - Para verificar os estados disponíveis, execute o comando
adb shell cmd device_state print-statesno dispositivo dobrável.
Google Pixel Fold (ID do modelo 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},
]
Samsung Galaxy Z Fold4 (ID do modelo 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},
]
Ao contrário de outros produtos do Firebase, você não precisa adicionar um SDK do Firebase para usar o Test Lab. Se ainda não tiver um aplicativo, você poderá baixar um APK on-line ou criar um aplicativo e um APK de teste a partir de um dos exemplos no repositório GitHub do AndroidX . Observe que você só precisa do arquivo APK do seu aplicativo para executar um teste Robo, enquanto um teste de instrumentação requer um aplicativo e um APK de teste criados a partir do código-fonte. Para obter mais informações, leia sobre testes instrumentados .
Para saber mais sobre os recursos do Test Lab, consulte Introdução aos testes para Android com o Firebase Test Lab .
O teste de diferença de captura de tela é onde as afirmações do teste são baseadas na comparação de imagens de tela obtidas durante a execução de um teste com imagens douradas que representam o comportamento esperado. Esses testes podem ser mais frágeis em alguns tipos de dispositivos do que em outros. Recomendamos direcionar dispositivos emuladores Arm ( *.arm ) para esses tipos de testes. Os dispositivos emuladores Arm usam imagens muito semelhantes ou idênticas aos emuladores "genéricos" do Android Studio.
Também recomendamos que você investigue bibliotecas de testes que possam ajudar a tornar os testes de captura de tela mais robustos na presença de alterações esperadas.
Sim! Os dispositivos virtuais são atualizados quando as seguintes alterações são feitas:
- Atualizações para imagens existentes
- Suspensão de uso de níveis anteriores de API
- Novos níveis de API do Android são adicionados
Para ativar relatórios de cobertura, adicione coverage=true ao campo environmentVariables . Se estiver usando o Android Test Orchestrator, você precisará fornecer um diretório para armazenar os resultados da cobertura:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Se não estiver usando o Orchestrator, você poderá especificar um caminho de arquivo:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
Informações detalhadas do dispositivo estão disponíveis por meio da API e podem ser acessadas no cliente gcloud usando o comando description :
gcloud firebase test android models describe MODEL
Problemas conhecidos
O teste Robo não pode ignorar telas de login que exigem ações adicionais do usuário além de inserir credenciais para entrar, por exemplo, preencher um CAPTCHA.
O teste Robo funciona melhor com aplicativos que usam elementos de UI da estrutura de UI do Android (incluindo objetos View , ViewGroup e WebView ). Se você usar o teste Robo para exercitar aplicativos que usam outras estruturas de UI, incluindo aplicativos que usam o mecanismo de jogo Unity, o teste poderá sair sem explorar além da primeira tela.