Trade Federation (Tradefed ou TF, abreviadamente) é uma estrutura de teste contínuo projetada para executar testes em dispositivos Android. Por exemplo, Tradefed é usado para executar o Compatibility Test Suite (CTS) e o Vendor Test Suite (VTS) .
Trade Federation é um aplicativo Java 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, junto com alguns exemplos de casos de uso. Dito isso, se você quiser começar imediatamente, pode ir direto para a página Comece aqui .
Características
- design modular, flexível e escalável
- possui suporte integrado para executar muitos tipos diferentes de testes Android: instrumentação , uiautomator , nativo/gtest, JUnit baseado em host, etc.
- fornece confiabilidade e mecanismos de recuperação além do adb
- suporta agendamento e execução de testes em vários dispositivos em paralelo
Consulte Teste por meio de TF para obter informações mais atualizadas sobre como executar testes existentes, como Instrumentação .
Casos de uso
A modularidade do Trade Federation facilita a integração em ambientes com infraestruturas existentes de construção, teste e geração de relatórios. Listamos abaixo alguns casos de uso demonstrativos onde o tradefed poderia permitir práticas de teste eficientes e escalá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 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 dos seus processos de teste eficientes, flexíveis e escaláveis.
OEM do dispositivo
Um OEM de dispositivo cria hardware e muitas vezes 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 garantindo que as alterações na estrutura não prejudiquem a compatibilidade com os aplicativos existentes.
O OEM poderia implementar um módulo de atualização 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 no bootloader, piscar e, em seguida, forçar o dispositivo a reinicializar novamente no modo de espaço do usuário. Combinado com um módulo para conectar-se a um sistema de construção contínua, isso permitiria que o OEM executasse testes em seu dispositivo à medida que fazia alterações no firmware de nível de sistema e nas estruturas de nível Java.
Depois que o dispositivo estiver totalmente inicializado, o OEM poderá aproveitar os testes existentes baseados em JUnit ou escrever novos para verificar a funcionalidade de interesse. Finalmente, eles poderiam escrever um ou mais módulos de relatórios de resultados para vincular aos repositórios de resultados de testes existentes ou para relatar os 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 vários 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 em uma sequência de construçã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 pode ser instalada 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 TF arbitrárias em execução na mesma máquina host.
Devido à proficiência da TF em lidar com múltiplos dispositivos, seria simples classificar cada resultado de teste pelo tipo de dispositivo usado para aquele teste. Assim, o TF poderia potencialmente gerar uma matriz de compatibilidade bidimensional (ou multidimensional) para cada construção do aplicativo.
Serviço de teste
Um serviço de teste pode, por exemplo, permitir que 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 porque 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 ser necessária. Além disso, a simplicidade e versatilidade da interface de relatório de resultados, ITestInvocationListener , significa que também é simples representar resultados de testes arbitrários (incluindo, por exemplo, métricas de potência numérica) no pipeline de relatório de resultados padrão.