Trade Federation (Tradefed ou TF para abreviar) é uma estrutura de teste contínua projetada para executar testes em dispositivos Android. Por exemplo, o Tradefed é usado para executar o Compatibility Test Suite (CTS) e o Vendor Test Suite (VTS) .
Trade Federation é um aplicativo Java que é executado em um computador host e se comunica com um ou mais dispositivos Android usando ddmlib (a biblioteca por trás do DDMS) sobre adb.
Listamos alguns dos principais recursos do TF abaixo, juntamente com alguns exemplos de casos de uso. Dito isto, se você quiser ir direto e começar, pode ir direto para a página Comece aqui .
Características
- design modular, flexível e escalável
- tem suporte embutido para executar muitos tipos diferentes de testes Android: instrumentação , uiautomator , native/gtest, JUnit baseado em host, etc.
- fornece mecanismos de confiabilidade e recuperação em cima do adb
- suporta agendamento e execução de testes em vários dispositivos em paralelo
Consulte Testing Through TF para obter as informações mais atualizadas sobre como executar seus testes existentes, como Instrumentation .
Casos de uso
A modularidade do Trade Federation facilita o encaixe em ambientes com infraestruturas de criação, teste e relatórios existentes. Listamos abaixo alguns casos de uso demonstrativos em que o tradefed pode permitir práticas de teste eficientes e escaláveis.
Primeiro, é útil considerar o cenário de casos de uso em potencial em termos da pergunta "quais partes são modificáveis e quais partes são estáticas?" Por exemplo, um OEM de dispositivo pode modificar a estrutura, o sistema e o hardware, mas tem pouca ou nenhuma influência sobre os aplicativos existentes. Um desenvolvedor de aplicativos, por outro lado, pode modificar o aplicativo, 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 terá 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 de seus processos de teste eficiente, flexível e escalável.
OEM do dispositivo
Um OEM de dispositivo cria hardware e geralmente ajusta o sistema e as estruturas Android para funcionar bem nesse hardware. O OEM pode se esforçar para atingir essas metas, mantendo a estabilidade e o desempenho nos níveis de hardware e sistema, e certificando-se de que as alterações na estrutura não quebrem a compatibilidade com os aplicativos existentes.
O OEM pode implementar um módulo de flash de dispositivo que será executado durante o estágio de configuração de destino do ciclo de vida. Esse módulo teria controle total sobre o dispositivo durante seu período de execução, o que permitiria potencialmente forçar o dispositivo a entrar no carregador de inicialização, fazer flash e, em seguida, forçar o dispositivo a reinicializar novamente no modo de espaço do usuário. Combinado com um módulo para vincular a um sistema de compilação contínua, isso permitiria que o OEM executasse testes em seu dispositivo à medida que fizesse alterações no firmware no nível do sistema e nas estruturas no nível Java.
Depois que o dispositivo for totalmente inicializado, o OEM poderá aproveitar os testes existentes baseados em JUnit ou escrever novos, para verificar a funcionalidade de interesse. Por fim, eles podem escrever um ou mais módulos de relatório de resultados para vincular a repositórios de resultados de teste existentes ou para relatar resultados diretamente (por exemplo, por e-mail ).
Desenvolvedor de aplicativos
Um desenvolvedor de aplicativos cria um aplicativo que precisa funcionar bem em uma variedade de versões de plataforma e em uma variedade de dispositivos. Se surgir um problema em uma versão de plataforma e/ou dispositivo específico, a única solução é adicionar uma solução alternativa e seguir em frente. Para desenvolvedores maiores, o processo de teste pode ser incorporado a uma sequência de compilação contínua. Para desenvolvedores menores, pode ser iniciado periodicamente ou manualmente.
A maioria dos desenvolvedores de aplicativos usaria os módulos de instalação de teste apk que já existem no TF. Há uma versão que instala a partir do sistema de arquivos local , bem como uma versão que pode instalar apks baixados de um serviço de compilação . É importante observar que a última versão continuaria a funcionar corretamente com muitas 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 aquele teste. Assim, o TF poderia gerar uma matriz de compatibilidade bidimensional (ou multidimensional) para cada compilação do aplicativo.
Serviço de teste
Um serviço de teste pode, por exemplo, permitir que os desenvolvedores de aplicativos enviem aplicativos e executem testes em dispositivos instrumentados com ferramentas de medição de energia para determinar o uso de energia do aplicativo. Isso difere dos dois casos de uso anteriores, pois o construtor de serviços não controla os dispositivos ou os aplicativos que estão sendo executados.
Como o Trade Federation pode executar qualquer classe Java que implemente a interface IRemoteTest simples, é trivial escrever drivers que possam coordenar alguma peça externa de hardware com o caso de teste que está sendo executado no dispositivo. O próprio driver pode gerar Threads, enviar solicitações para outros servidores ou fazer qualquer outra coisa que possa precisar. Além disso, a simplicidade e versatilidade da interface de relatório de resultados, ITestInvocationListener , significa que é igualmente simples representar resultados de testes arbitrários (incluindo, por exemplo, métricas de potência numérica) no pipeline de relatórios de resultados padrão.