A Trade Federation (Tradefed ou TF, na sigla em inglês) é um framework de teste contínuo projetado para executar testes em dispositivos Android. Por exemplo, o Tradefed é usado para executar o Compatibility Test Suite (CTS) e o Vendor Test Suite (VTS).
A Trade Federation é um aplicativo Java executado em um computador host e se comunica com um ou mais dispositivos Android usando a ddmlib (a biblioteca por trás do DDMS) pelo adb.
Listamos abaixo alguns dos principais recursos do TF e alguns casos de uso de exemplo. No entanto, se você quiser começar a usar o serviço, acesse a página Comece aqui.
Recursos
- design modular, flexível e escalonável
- tem suporte integrado para a execução de muitos tipos diferentes de testes do Android: instrumentação, uiautomator, nativo/gtest, JUnit baseado em host etc.
- fornece mecanismos de confiabilidade e recuperação em cima do adb
- oferece suporte à programação e execução de testes em vários dispositivos em paralelo
Consulte Como fazer testes com o TF para conferir as informações mais recentes sobre como executar os testes atuais, como Instrumentação.
Casos de uso
A modularidade da Trade Federation facilita a inclusão em ambientes com infraestruturas de build, teste e geração de relatórios. Listamos abaixo alguns casos de uso demonstrativos em que o tradefed pode permitir práticas de teste eficientes e escalonáveis.
Primeiro, é útil considerar o cenário de possíveis casos de uso em termos da pergunta "Quais partes são modificáveis e quais são estáticas?" Por exemplo, um OEM de dispositivo pode modificar o framework, o sistema e o hardware, mas tem pouca ou nenhuma influência sobre os aplicativos atuais. Por outro lado, um desenvolvedor de apps pode modificar o app, mas tem pouco controle sobre a maioria dos aspectos do sistema ou da estrutura.
Como resultado, uma entidade em cada caso de uso terá objetivos de teste diferentes e opções diferentes no caso de um conjunto de falhas de teste. Apesar dessas diferenças, a Trade Federation pode ajudar a tornar cada um dos processos de teste eficientes, flexíveis e escalonáveis.
OEM do dispositivo
Um OEM de dispositivo cria hardware e, muitas vezes, ajusta o sistema e os frameworks do Android para que funcionem bem nesse hardware. O OEM pode se esforçar para alcançar essas metas, mantendo a estabilidade e o desempenho nos níveis de hardware e sistema, além de garantir que as mudanças do framework não comprometam a compatibilidade com os aplicativos atuais.
O OEM pode implementar um módulo de atualização do dispositivo que será executado durante a fase de configuração do alvo do ciclo de vida. Esse módulo teria controle total sobre o dispositivo durante o período de execução, o que permitiria forçar o dispositivo a entrar no carregador de inicialização, fazer o flash e forçar o dispositivo a reiniciar de volta ao modo de espaço do usuário. Combinado com um módulo para vincular a um sistema de build contínuo, isso permite que o OEM execute testes no dispositivo à medida que faz alterações no firmware do sistema e nas frameworks do Java.
Depois que o dispositivo for totalmente inicializado, o OEM poderá aproveitar os testes baseados em JUnit existentes ou criar novos para verificar a funcionalidade de interesse. Por fim, eles podem escrever um ou mais módulos de relatórios de resultados para vincular a repositórios de resultados de teste existentes ou para informar os resultados diretamente (por exemplo, por e-mail).
um desenvolvedor de apps
Um desenvolvedor de apps cria um app que precisa funcionar bem em várias versões de plataforma e em vários dispositivos. Se um problema surgir em uma versão específica da plataforma e/ou dispositivo, o único remédio é adicionar uma solução alternativa e seguir em frente. Para desenvolvedores maiores, o processo de teste pode ser incorporado a uma sequência de build contínua. Para desenvolvedores menores, ela pode ser iniciada periodicamente ou manualmente.
A maioria dos desenvolvedores de apps usa os módulos de instalação de teste de apk que já existem no TF. Há uma versão que instala do sistema de arquivos local, bem como uma versão que pode instalar apks transferidos por download de um serviço de build. É importante observar que a versão mais recente continuaria funcionando corretamente com várias instâncias de TF em execução na mesma máquina host.
Devido à proficiência do TF em lidar com vários dispositivos, seria simples classificar cada resultado de teste pelo tipo de dispositivo usado para esse teste. Assim, o TF pode gerar uma matriz de compatibilidade bidimensional (ou multidimensional) para cada build do aplicativo.
Serviço de testes
Um serviço de teste pode, por exemplo, permitir que os desenvolvedores de apps enviem apps e executem testes em dispositivos com ferramentas de medição de energia para determinar o consumo de energia do app. Isso é diferente dos dois casos de uso anteriores, porque o criador de serviços não controla os dispositivos ou os aplicativos que estão sendo executados.
Como a Trade Federation pode executar qualquer classe Java que implemente a interface
simples IRemoteTest, é
fácil escrever drivers que podem coordenar algum hardware externo com o caso de teste
que está sendo executado no dispositivo. O driver em si pode gerar linhas de execução, enviar solicitações para outros
servidores ou fazer qualquer outra coisa que possa ser necessária. Além disso, a simplicidade e a versatilidade da
interface de relatórios de resultados,
ITestInvocationListener, significa que é igualmente simples
representar resultados de teste arbitrários (incluindo, por exemplo, métricas de potência numérica) no
pipeline padrão de relatórios de resultados.