Google is committed to advancing racial equity for Black communities. See how.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Visão geral da federação comercial

Trade Federation (Tradefed ou TF para abreviar) é 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 que roda 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, vá direto para a página Comece aqui .

Recursos

  • design modular, flexível e escalável
  • tem 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 Testando por meio do TF para obter as informações mais atualizadas sobre como executar seus testes existentes, como Instrumentação .

Casos de uso

A modularidade do Trade Federation facilita a inserção em ambientes com infraestruturas de construçã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.

Em primeiro lugar, é útil considerar a paisagem de casos de uso potenciais em termos da questão "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, o Trade Federation pode ajudar a tornar cada um de seus processos de teste eficiente, flexível e escalonável.

Dispositivo OEM

Um Device OEM constrói hardware e, muitas vezes, ajusta o sistema Android e as estruturas para funcionar bem nesse hardware. O OEM pode se esforçar para atingir esses objetivos, mantendo a estabilidade e o desempenho nos níveis de hardware e sistema, e garantindo que as mudanças na estrutura não quebrem a compatibilidade com os aplicativos existentes.

O OEM pode implementar um módulo de flashing do dispositivo que será executado durante o estágio de configuração do 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, flash e, em seguida, forçar o dispositivo a reiniciar de volta no modo de espaço do usuário. Combinado com um módulo para vincular a um sistema de construção contínua, isso permitiria ao OEM executar testes em seu dispositivo enquanto faz alterações no firmware de nível de sistema e estruturas de nível de Java.

Assim que o dispositivo estiver totalmente inicializado, o OEM poderá aproveitar os testes existentes baseados em JUnit, ou escrever novos, para verificar a funcionalidade de seu interesse. Finalmente, eles poderiam escrever um ou mais módulos de relatório de resultados para vincular aos repositórios de resultados de teste existentes ou para relatar os resultados diretamente (por exemplo, por e-mail ).

Desenvolvedor de aplicativos

Um desenvolvedor de aplicativos constrói um aplicativo que precisa rodar bem em uma variedade de versões de plataforma e 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 em uma sequência de construção contínua. Para desenvolvedores menores, ele 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 de TF em execução na mesma máquina host.

Por causa da proficiência do TF em lidar com vários dispositivos, seria fácil classificar cada resultado de teste pelo tipo de dispositivo que foi usado para aquele teste. Assim, o TF poderia gerar potencialmente 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 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 porque o criador de serviços não controla os dispositivos ou 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 podem 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 seja necessária. Além disso, a simplicidade e versatilidade da interface de relatório de resultado, ITestInvocationListener , significa que é igualmente simples representar resultados de teste arbitrários (incluindo, por exemplo, métricas de potência numéricas) no pipeline de relatório de resultado padrão.