Quando o corpus de teste é grande ou o tempo de execução é longo, oferecemos a possibilidade de dividir os testes em vários dispositivos: fragmentação.
A fragmentação tem pré-requisitos para que o executor de teste ofereça suporte a ela.
A maioria dos principais executores de testes já aceita fragmentação, portanto trabalho é obrigatório. Eles já oferecem suporte à fragmentação: testes de instrumentação, testes orientados pelo host e GTest.
Há dois tipos de fragmentação compatíveis com o Tradefed: local e distribuído. Elas têm algumas semelhanças, então esta página descreve as propriedades comuns e, em seguida, as especificidades de cada uma delas.
Propriedades comuns
As duas formas de fragmentação assumem as mesmas propriedades dos executores de testes: fragmentos precisam ser independentes e deterministas. A primeira etapa das duas fragmentações para criar a lista ordenada completa dos testes e dividi-los em diferentes grupos/fragmentos.
A principal diferença entre os formatos de fragmentação é a maneira como eles executam os testes. Mais detalhes nas seções abaixo.
Fragmentação local
Fragmentação local significa que todos os dispositivos envolvidos na execução da invocação fragmentada estão conectados ao mesmo host físico.
Execução
O sharding local aproveita todos os dispositivos conectados ao mesmo host, criando um pool de testes que precisam ser executados e fazendo com que cada teste de sondagem de dispositivo seja executado quando estiver livre (ou seja, concluído com o teste anterior). Isso resulta em uma utilização otimizada do dispositivo. Também a chamamos fragmentação dinâmica.
Opções
--shard-count XX
Fragmentação distribuída
Sharding distribuído significa que todos os dispositivos envolvidos na execução da invocação fragmentada podem estar em qualquer lugar e ser conectados a diferentes hosts físicos.
Execução
O sharding distribuído ocorre ao criar a lista de testes, e o conteúdo de cada shard executa apenas o shard solicitado no momento. Assim, todos os fragmentos distribuídos criam a mesma lista primeiro e, em seguida, executam um subconjunto exclusivamente exclusivo, o que resulta na execução de todos os testes.
A propriedade principal desse formulário é que os fragmentos não têm conhecimento total e podem falhar de forma independente.
A principal desvantagem é que o comprimento do fragmento não é necessariamente equilibrado porque não podemos prever com antecedência o tempo de execução de cada teste em cada fragmento. A distribuição precisa ter aproximadamente o mesmo número de casos de teste. em cada fragmento.
Opções
--shard-count XX --shard-index XX
Fragmentação de token
A fragmentação de tokens só pode ser usada com fragmentação local. A sinalização é inoperacionais em casos de uso de fragmentação não locais. Às vezes, um dos dispositivos envolvidos na fragmentação têm recursos especiais que outras pessoas não têm, carda. Alguns testes só funcionam quando esse recurso especial está disponível e falham de outra forma.
A fragmentação de tokens é a nossa solução para esses casos de uso. Os módulos de teste podem
declarar de qual recurso especial eles precisam na AndroidTest.xml;
O Tradefed encaminha os testes para um dispositivo que tem o recurso.
Configuração de XML
<option name="config-descriptor:metadata" key="token" value="SIM_CARD" />
O value do token corresponde ao
TokenProperty do Tradefed
e está associado a um gerenciador em
TokenProviderHelper.
Isso permite que os módulos de teste sejam executados em dispositivos que possam para executar os testes.
E se nenhum dispositivo puder executar o teste?
Se nenhum dispositivo disponível tiver o recurso correspondente ao módulo de teste, o módulo de teste vai falhar e ser ignorado porque não pode ser executado corretamente.
Por exemplo, se um módulo de teste solicitar um chip para ser executado, mas nenhum dispositivo tiver um chip, o módulo de teste vai falhar.
Implementação
Transmita essa flag de recurso para a linha de comando principal do Tradefed:
--enable-token-sharding