O ciclo de vida de um teste executado usando o Trade Federation é composto por quatro estágios separados, projetados em torno de interfaces formalmente definidas.
Interfaces definidas
- Build Provider : Fornece uma compilação para testar, baixando os arquivos apropriados, se necessário.
- Preparador de destino : prepara o ambiente de teste, possivelmente incluindo a instalação do software e a configuração do dispositivo.
- Teste : Executa o(s) teste(s) e reúne os resultados do teste. Este pode ser qualquer teste JUnit, embora nossa interface IRemoteTest seja projetada especificamente para funcionar bem no ambiente Trade Federation.
- Ouvinte de invocação de teste (relatório de resultados) : ouve os resultados do teste, geralmente com a finalidade de encaminhar os resultados do teste para um repositório ou exibi-los ao executor de testes.
A entidade de teste fundamental no TF é uma configuração (config). Uma configuração é um arquivo XML que declara os componentes do ciclo de vida de um teste.
Essa separação do ciclo de vida do teste visa permitir a reutilização. Usando esse design, o Desenvolvedor pode criar um Teste uma vez e, em seguida, o Integrador pode criar diferentes Configurações para executar esse Teste em diferentes ambientes. Por exemplo, eles podem criar uma configuração que executará um teste em uma máquina local e despejará o resultado em stdout. Eles poderiam então criar uma segunda Configuração que executaria o mesmo teste, mas usaria um Ouvinte de Invocação de Teste diferente para armazenar os resultados do teste em um banco de dados. Uma terceira configuração pode ser projetada para executar esse teste continuamente de um laboratório de teste em algum lugar.
É conveniente observar aqui que um Configuration junto com seus argumentos de linha de comando (conforme fornecido pelo Test Runner) é conhecido como Command . Quando o TF emparelha um comando com um ITestDevice e o executa, o objeto subsequente é conhecido como Invocation . Resumindo, uma Invocação engloba uma execução completa de teste TF, em todo o seu ciclo de vida.
Componentes de configuração adicionais
- Device Recovery : mecanismo para recuperar a comunicação do dispositivo em caso de perda.
- Logger : coleta dados de log do tradefed.
Saída de palco e erros
Cada estágio de uma invocação é executado sequencialmente e tem um objetivo específico. Esta seção descreve as saídas e erros usuais de cada estágio.
Construir provedor
Esse estágio cria e gera um objeto IBuildInfo que contém todas as referências de arquivos necessárias para configurar e executar os testes.
O erro mais comum neste estágio é uma falha ao baixar ou encontrar os arquivos solicitados.
Um erro neste estágio resulta em reportar diretamente o erro e nenhum teste sendo executado.
Preparação do alvo
Este estágio configura os estados necessários para o destino em testes. Este estágio pode alterar a configuração do dispositivo ou do host conforme necessário para a chamada de teste fornecida.
Erros comuns neste estágio geralmente envolvem falha na configuração do dispositivo em um determinado estado (por exemplo, falha na atualização) e falha em encontrar os arquivos necessários para a configuração.
Um erro neste estágio resulta na execução da limpeza do destino, no relatório do erro e na não execução de testes.
Testes
Esta etapa executa os testes solicitados no alvo previamente preparado e relata todos os resultados da execução dos testes.
Erros comuns neste estágio geralmente envolvem a indisponibilidade do alvo em teste ou algum erro causando a execução parcial dos testes. Esses erros são problemas de infraestrutura que afetam a própria execução do teste, em oposição a uma falha de um único caso de teste.
Um erro neste estágio resulta na interrupção da execução do teste, na execução da limpeza do destino, no relatório do erro e na obtenção de resultados parciais.
Relatório de resultados
Esta etapa relata os resultados e erros para os serviços configurados (por exemplo, servidores e arquivos locais).
Embora os relatores de resultados individuais possam ter erros, eles estão isolados uns dos outros (um relator não vê erros de outro). Esses erros afetam apenas os relatórios de resultados de um relator individual e os erros podem ser visualizados nos logs.