Quando o corpus de teste é grande ou o tempo de execução se torna longo, oferecemos a possibilidade de dividir os testes em vários dispositivos: sharding .
A fragmentação tem pré-requisitos para que o executor de teste ofereça suporte à fragmentação.
A maioria dos executores de teste principais já suporta sharding, portanto, nenhum trabalho adicional é necessário. Estes já suportam sharding: testes de instrumentação, testes conduzidos pelo host, GTest.
Existem dois tipos de sharding que suportamos no Tradefed: local e distribuído. Eles compartilham algumas semelhanças, então esta página descreve as propriedades comuns e, em seguida, as especificidades de cada um.
Propriedades comuns
Ambas as formas de sharding assumem as mesmas propriedades dos executores de testes: os shards precisam ser independentes e determinísticos . A primeira etapa de ambos os fragmentos é criar a lista ordenada completa dos testes e, em seguida, dividi-los em diferentes grupos/fragmentos.
A principal diferença dos formulários de sharding está na forma como 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
A fragmentação local aproveita todos os dispositivos conectados ao mesmo host, criando um pool de testes que precisam ser executados e fazendo com que cada dispositivo verifique os testes quando estiver livre (ou seja, feito com o teste anterior). Isso resulta em uma utilização otimizada do dispositivo. Também o chamamos de sharding dinâmico .
Opções
--shard-count XX
Fragmentação distribuída
Fragmentação distribuída significa que todos os dispositivos envolvidos na execução da invocação fragmentada podem residir em qualquer lugar e estar conectados a diferentes hosts físicos.
Execução
A fragmentação distribuída ocorre na construção da lista de testes e o conteúdo de cada fragmento executa apenas o fragmento solicitado no momento. Portanto, todos os fragmentos distribuídos criam a mesma lista primeiro e, em seguida, executam um subconjunto mutuamente exclusivo dela, o que resulta na execução de todos os testes.
A principal propriedade desta forma é que os fragmentos são completamente inconscientes uns dos outros e podem falhar independentemente.
A principal desvantagem é que o tamanho do shard não é necessariamente equilibrado simplesmente porque não podemos prever com antecedência o tempo de execução de cada teste em cada shard. A distribuição é feita para ter aproximadamente o mesmo número de casos de teste em cada shards.
Opções
--shard-count XX --shard-index XX
fragmentação de token
A fragmentação de token pode ser usada apenas com fragmentação local. O sinalizador é inoperante em casos de uso de fragmentação não local. Às vezes, um dos dispositivos envolvidos na fragmentação possui recursos especiais que outros não possuem, como um cartão SIM. Alguns testes podem funcionar apenas quando esse recurso especial estiver disponível e falhariam caso contrário.
A fragmentação de token é nossa solução para esses casos de uso. Os módulos de teste podem declarar qual recurso especial eles precisam em seu AndroidTest.xml e o Tradefed roteia os testes para um dispositivo que possui o recurso.
configuração XML
<option name="config-descriptor:metadata" key="token" value="SIM_CARD" />
O value do token corresponde a TokenProperty do Tradefed e está associado a um manipulador em TokenProviderHelper .
Isso permite que os módulos de teste sejam executados em dispositivos que podem executar os testes adequadamente.
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 falhará e será ignorado porque não pode ser executado corretamente.
Por exemplo, se um módulo de teste solicitar a execução de um cartão SIM, mas nenhum dispositivo tiver um cartão SIM, o módulo de teste falhará.
Implementação
Passe este sinalizador de recurso para a linha de comando principal do Tradefed:
--enable-token-sharding