Nesta página, você encontra ajuda para solucionar problemas e respostas a perguntas frequentes sobre a execução de testes com a plataforma de dispositivos para desenvolvedores. Caso você não encontre o que procura ou precise de ajuda, entre em contato com nossa equipe.
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 da plataforma de dispositivos para desenvolvedores, 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 a Plataforma de dispositivos para desenvolvedores, consulte o painel Google Cloud Personalized Service Health.
Para saber mais sobre a capacidade do dispositivo na Developer Device Platform, consulte o Catálogo de dispositivos.
Por que os resultados do teste foram inconclusivos?
Os resultados inconclusivos geralmente acontecem devido a erros de infraestrutura
ou testes cancelados. Além de PASSED e FAILED, a Developer Device Platform
pode retornar ERROR, TIMED_OUT e CANCELLED.
Os erros de infraestrutura são causados por problemas internos da plataforma de dispositivos para desenvolvedores, como erros de rede ou comportamentos inesperados em dispositivos. A plataforma de dispositivos para desenvolvedores tenta novamente os testes que produzem erros de infraestrutura várias vezes antes de informar um resultado inconclusivo.
Para determinar a causa do erro, faça o seguinte:
- Procure por falhas conhecidas no painel Integridade do serviço do Google Cloud.
Repita o teste na plataforma de dispositivos para desenvolvedores para verificar se ele pode ser reproduzido.
Faça o teste em outro tipo de dispositivo, se aplicável. Consulte o Catálogo de dispositivos para mais informações.
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 na plataforma de dispositivos para desenvolvedores. Para evitar essa situação, limite a contagem de dispositivos à contagem de fragmentos. Para mais informações sobre como escolher um dispositivo diferente, consulte o Catálogo 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.
Por que meu teste está demorando muito?
Após a conclusão da execução do teste, os artefatos de teste são transferidos por download do dispositivo, processados e enviados para o Cloud Storage. A duração desta etapa pode ser afetada pela quantidade e pelo tamanho dos artefatos.
Solução de problemas específicos do Android
O app não retorna dados e não consegue localizar as capturas de tela
Os artefatos de execução do teste (como capturas de tela e arquivos de registro) são armazenados no Cloud Storage e renderizados diretamente no console do Google Cloud . Verifique se você atribuiu papéis para envolvidos no projeto.
Além disso, a Plataforma de dispositivos para desenvolvedores tem um agente de serviço dedicado que usa as próprias credenciais, e não as suas, para:
- Ler e gravar em buckets e objetos do Cloud Storage
- Baixar arquivos de entrada do Cloud Storage para o sistema interno
- Fazer upload de arquivos do sistema interno para o bucket de saída do Cloud Storage
É possível que você tenha acesso a um bucket do Cloud Storage e a um arquivo, mas que esse bucket seja de um projeto Google Cloud diferente daquele usado no DDP. Portanto, a conta de serviço da plataforma de dispositivos para desenvolvedores não tem acesso a ele.
Você também pode ter outros controles de acesso em intervalos individuais. Consulte Execução no dispositivo para saber como incluir arquivos com seus testes.
Por que estou recebendo resultados parciais ou ausentes do caso de teste de instrumentação?
Ao executar testes de instrumentação, você pode notar que o total de casos de teste é menor do que o esperado. Isso geralmente acontece porque a plataforma do dispositivo de desenvolvimento não consegue analisar o logcat para encontrar os marcadores de início ou término do caso de teste que geralmente são gerados por AndroidJUnitRunner.
Algumas causas comuns desse problema são as seguintes:
| Descrição do problema | Possível soluçã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 que o tempo limite máximo, a plataforma de dispositivos do desenvolvedor vai cancelar o restante dos casos de teste. |
|
| O caso de teste não foi concluído porque foi interrompido prematuramente ou teve problemas. O caso de teste pode ser encerrado prematuramente devido a uma exceção não identificada ou a um erro de declaração. Os casos de teste podem ficar travados em um loop infinito ou não continuar, por exemplo, se o app não mostrar a visualização correta e o caso de teste não puder realizar a ação na interface. |
Verifique o vídeo e o logcat para investigar onde o teste
foi interrompido.
|
Um executor de testes personalizados, incluindo a extensão de AndroidJUnitRunner, falhou
de forma inesperada ou escreveu em logcat marcadores inesperados de início ou fim dos casos de teste.
|
Verifique o código do executor de testes. |
Registros em excesso gravados em logcat, que sobrecarregaram o buffer ou travaram
o processo logcat.
|
Reduza as gravações para logcat.
|
| O app em teste sofreu uma falha. | Depurar o app. |
Perguntas frequentes
Onde posso encontrar informações sobre os preços da Developer Device Platform?
Consulte Perguntas sobre preços e faturamento para mais detalhes.
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
na CLI da plataforma de dispositivos para desenvolvedores com o comando device-run devices describe <device-id>:
gcloud beta device-run devices describe DEVICE_ID
Como faço para descobrir se o tráfego que chega ao back-end é proveniente da plataforma de dispositivos para desenvolvedores?
No seu back-end, é possível determinar se o tráfego vem de dispositivos de teste hospedados na plataforma de dispositivos para desenvolvedores ao verificar o endereço IP de origem em nossos intervalos de IP.
A Developer Device Platform funciona com o VPC Service Controls?
A plataforma de dispositivos para desenvolvedores 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 da plataforma de dispositivos para desenvolvedores e os buckets de resultados dos usuários.
Como reduzir testes instáveis na plataforma de dispositivos para desenvolvedores?
Para detectar comportamentos instáveis nos testes, recomendamos o uso da opção
--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:
- Por padrão, o DDP executa a nova tentativa em sequência para economizar custos. Os usuários precisam definir
--flaky-test-parallel-retrypara execução paralela. - A flag
--flaky-test-retry-leveldefine se a nova tentativa será feita no nívelshardoutestindividual e tem como padrãoshard. Defina comotestpara reduzir o tamanho e a duração do teste de nova tentativa.
Perguntas frequentes específicas do iOS
A plataforma de dispositivos para desenvolvedores 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.
Por que meu teste para iOS não tem vídeos nos resultados?
O suporte a vídeos nos resultados está previsto para o iOS 18 ou versões mais recentes.
Perguntas frequentes específicas do Android
A Developer Device Platform é compatível com dispositivos wearable?
Sim. A plataforma de dispositivos para desenvolvedores é compatível com o Google Pixel Watch. Agora você pode executar testes no app para Wear OS independente nos dispositivos Google Pixel Watch. Para saber mais sobre os dispositivos da Developer Device Platform, consulte o Catálogo de dispositivos.
A Developer Device Platform é compatível com os dispositivos Google mais recentes?
Sim. A plataforma de dispositivos para desenvolvedores é compatível com o Google Pixel Tablet e o Google Pixel Fold. É possível executar testes em dispositivos físicos independentes. Para saber mais sobre os dispositivos disponíveis na Developer Device Platform, consulte o Catálogo de dispositivos.
A plataforma de dispositivos para desenvolvedores 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. No entanto, se você criou seu app com um framework que tem suporte ao Espresso, como o Flutter, é possível programar um teste de instrumentação usando o Espresso e depois executar o experimento na plataforma de dispositivos para desenvolvedores.
A plataforma de dispositivos para desenvolvedores oferece suporte a testes de apps ofuscados, por exemplo, com o ProGuard ou o R8?
A plataforma de dispositivos para desenvolvedores não oferece suporte explícito à ofuscação ou desofuscação. Embora o app provavelmente seja executado, todos os dados ofuscados, como stack traces, vão aparecer como ofuscados nos registros.
Posso usar meu dispositivo dobrável em diferentes estados e posições dobráveis ao testar na plataforma de dispositivos para desenvolvedores?
Sim. É possível testar seu dispositivo dobrável em estados e posturas dobráveis.
Os dispositivos dobráveis podem estar em vários estados dobráveis, como FLAT (totalmente aberto) ou HALF_OPENED (entre totalmente abertos e completamente fechados).
Por outro lado, as posições consistem em orientação específica do dispositivo e estado
dobrável. Por exemplo, a posição de mesa, que é um estado HALF_OPENED na orientação horizontal, ou a posição de livro, que é um estado HALF_OPENED na orientação vertical.
Se você estiver executando testes de instrumentação, use a biblioteca Jetpack WindowManager e siga a documentação Como testar seu app em dispositivos dobráveis para testar diferentes estados e posturas.
Como alternativa, os estados disponíveis são específicos do dispositivo e podem ser usados para interagir com 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 (código 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},
]
Posso testar a plataforma de dispositivos para desenvolvedores se eu não tiver um app?
Ao contrário de outros produtos da plataforma de dispositivos para desenvolvedores, não é necessário adicionar um SDK da plataforma de dispositivos para desenvolvedores para usar a plataforma. Se você ainda não tiver um app, faça o download de um APK ou crie um aplicativo e um APK de teste usando uma das amostras no repositório do AndroidX no GitHub. Um teste de instrumentação requer um app e um APK de teste criados com base no código-fonte. Para mais informações, leia sobre Testes de instrumentação.
Para saber mais sobre os recursos da Developer Device Platform, consulte a visão geral do produto DDP.
Quais são os melhores dispositivos para testes de diferença entre capturas de tela?
Os testes de diferença entre capturas de tela têm base nas comparações de imagens
de tela coletadas ao executar um teste com golden images que representam o comportamento
esperado. Esses testes podem ser mais frágeis em alguns tipos de dispositivos do que em outros. Recomendamos segmentar
dispositivos com um emulador de ARM (*.arm) para esses tipos de teste. Os dispositivos com um emulador de ARM usam
imagens muito semelhantes ou idênticas aos emuladores genéricos do Android Studio.
Também recomendamos que você investigue as bibliotecas de teste que podem ajudar a tornar os testes de captura de tela mais robustos para lidar com mudanças esperadas.
A Developer Device Platform atualiza dispositivos virtuais?
Sim. Os dispositivos virtuais são atualizados quando as seguintes mudanças são feitas:
- Atualizações para imagens atuais
- Descontinuação de níveis anteriores de API
- Novos níveis da API do Android foram adicionados
Como faço para ativar os relatórios de cobertura?
Para ativar os relatórios de cobertura, adicione coverage=true ao
campo additional-test-options.
Se você estiver usando o Android Test Orchestrator, forneça um caminho de diretório para
armazenar os resultados de cobertura:
--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/
Se você não usa o Orchestrator, então pode especificar um caminho de arquivo:
--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec
Como faço login em um app para Wear sem um smartphone?
Se o app normalmente exigir um smartphone para fazer login, crie uma variante de build que pule o login e use um token incorporado no build de teste ou leia arquivos no disco normalmente enviados usando a flag --other-files-to-push.