O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Visão geral da Federação do Comércio

A Trade Federation (Tradefed ou TF para abreviar) é uma estrutura de teste contínua projetada para executar testes em dispositivos Android. Por exemplo, Tradefed é usado para executar o CTS (Compatibility Test Suite) e o Vendor Test Suite (VTS) .

A 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 abaixo alguns dos principais recursos do TF, juntamente com alguns exemplos de casos de uso. Dito isto, se você quiser ir direto ao assunto e começar, pode ir direto para a página Iniciar aqui .

Recursos

  • design modular, flexível e escalável
  • foi desenvolvido para executar muitos tipos diferentes de testes do Android: instrumentação , uiautomator , native / gtest, JUnit baseada em host, etc.
  • fornece mecanismos de confiabilidade e recuperação além 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 Instrumentação .

Casos de uso

A modularidade da Trade Federation torna fácil a inserção em ambientes com infra-estruturas de compilação, teste e geração de relatórios existentes. Listamos abaixo alguns casos de uso demonstrativos nos quais o tradefed pode 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 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 usuário terá objetivos de teste diferentes e opções diferentes no caso de um conjunto de falhas de teste. Apesar dessas diferenças, a Federação do Comércio 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 do Android para rodar 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 alterações na estrutura não quebrem a compatibilidade com os aplicativos existentes.

O OEM pode implementar um módulo intermitente do dispositivo que será executado durante o estágio Configuração do Destino do ciclo de vida . Esse módulo teria controle completo sobre o dispositivo durante seu período de execução, o que permitiria potencialmente forçar o dispositivo ao carregador de inicialização, piscar e forçar o dispositivo a reiniciar novamente no modo de espaço do usuário. Combinado com um módulo para conectar-se a um sistema de compilação contínuo, isso permitiria que o OEM executasse testes em seus dispositivos à medida que fazia alterações no firmware no nível do sistema e nas estruturas no nível do 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 seu interesse. Por fim, eles poderiam escrever um ou mais módulos de relatório de resultados para vincular-se aos repositórios de resultados de testes existentes ou para reportar resultados diretamente (por exemplo, por email ).

Desenvolvedor de aplicativos

Um desenvolvedor de aplicativos cria um aplicativo que precisa executar bem em uma variedade de versões de plataforma e vários dispositivos. Se surgir um problema em uma versão e / ou dispositivo de plataforma específica, o único remédio é adicionar uma solução alternativa e seguir em frente. Para desenvolvedores maiores, o processo de teste pode ser incorporado em 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 é instalada a partir do sistema de arquivos local , bem como uma versão que pode instalar aplicativos baixados de um serviço de compilação . É importante observar que a última versão continuaria funcionando corretamente com arbitrariamente 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 fácil classificar cada resultado do teste pelo tipo de dispositivo usado para esse teste. Assim, o TF poderia potencialmente 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 para o aplicativo. Isso difere dos dois casos anteriores, na medida em que o construtor de serviços não controla os dispositivos ou aplicativos que estão sendo executados.

Como a Trade Federation pode executar qualquer classe Java que implemente a interface simples IRemoteTest , é trivial escrever drivers que possam coordenar alguma parte externa do 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 ele possa precisar. 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 numéricas de potência) no pipeline de relatório de resultados padrão.