O que é equipamento de teste? (Exemplos)

Equipamento de teste em teste de software

Equipamento de teste em teste de software é uma coleção de stubs, drivers e outras ferramentas de suporte necessárias para automatizar a execução de testes. O equipamento de teste executa testes usando uma biblioteca de testes e gera relatórios de teste. O equipamento de teste contém todas as informações necessárias para compilar e executar um teste, como casos de teste, porta de implantação de destino (TDP), arquivo de origem em teste, stubs, etc.

Em termos simples, um harness envolve o componente que você deseja verificar dentro de um ambiente controlado. Módulos vizinhos ausentes são substituídos por pequenos programas fictícios, as entradas chegam de um conjunto de dados fixo e cada resultado é registrado em um log em vez de ser lido em uma tela. As seções a seguir explicam por que as equipes constroem um harness, do que ele é feito, como funciona e onde se encaixa.

Por que usar o Test Harness?

Existe um dispositivo de teste para eliminar a espera do ciclo de testes. Porque ele simula tudo o que ainda não está pronto, um teste de software A equipe pode começar a verificar o comportamento no primeiro sprint, em vez de após a integração final. O diagrama abaixo mostra onde um ambiente de teste se posiciona entre os scripts de teste e o aplicativo em teste.

• Automatize o processo de teste
• Execute conjuntos de testes de casos de teste
• Gere relatórios de teste associados
• Suporte para depuração
• Para registrar os resultados do teste para cada um dos testes
• Ajuda os desenvolvedores a medir a cobertura do código em nível de código
• Aumente a produtividade do sistema através da automação
• Melhore a qualidade dos componentes de software e aplicativos
• Para lidar com as condições complexas que os testadores acham difícil simular

Esses ganhos são mais importantes em ciclos de lançamento curtos. Quando o código é lançado várias vezes por semana, um defeito que sobrevive até a fase de integração custa muito mais para a equipe de desenvolvimento. trace mais do que um preso contra um toco no dia em que foi escrito. Essa recompensa, no entanto, só chega quando o arnês é montado com as peças certas.

Componentes principais de um chicote de teste

Um sistema de automação não é um programa único, mas sim um conjunto de partes, cada uma removendo um obstáculo que, de outra forma, impediria a execução de um teste sem supervisão.

• Scripts de teste: Instruções automatizadas que descrevem os passos a seguir e o resultado esperado, redigidas de acordo com o script de teste convenções.
• Mecanismo de execução de testes: O executor que lê os scripts em ordem, resolve as dependências e inicia a execução sequencial ou paralela.
• Repositório de dados de teste: Valores de entrada armazenados fora do script em CSV, JSON, XML ou em um banco de dados predefinido, geralmente preenchidos por testar ferramentas de geração de dados.
• Drivers: Módulos fictícios que chamam o componente em teste quando a camada superior real, como uma interface de usuário, ainda não está concluída.
• Tocos: Módulos fictícios que retornam respostas predefinidas, por exemplo, um serviço de pagamento que responde "Pagamento realizado com sucesso" sem contatar um banco.
• Validador de saída: Lógica de asserção que compara a saída real com o valor esperado e marca cada caso como aprovado ou reprovado.
• Camada de registro e geração de relatórios: Registros de data e hora, capturas de tela, saída do console e um resumo da execução que tornam cada falha evidente. traccapaz depois.

Remova qualquer uma das peças e o chicote de fios deixa de ser automático, pois algo terá que ser fornecido manualmente a cada uso.

Como funciona um chicote de teste?

Um arnês repete o mesmo ciclo a cada execução. Conhecer esse ciclo indica exatamente onde você está. teste de automação Os recursos são conectados e qual etapa está falhando quando uma execução fica vermelha.

1. Prepare o ambiente: O chicote de fios resolve a configuração do ambiente, abre conexões e carrega os dispositivos, de modo que cada execução comece a partir do mesmo estado conhecido.
2. Carregar os scripts de teste: Os scripts, parâmetros e resultados esperados são lidos do repositório. Nada é digitado em tempo de execução, o que torna uma segunda execução comparável à primeira.
3. Substitua os módulos que faltam: Os motoristas representam os chamadores que ainda não existem, e os comprovantes representam serviços inacabados, instáveis ​​ou caros de solicitar.
4. Invoque a aplicação em teste: O mecanismo de execução aciona o fluxo de trabalho descrito pelo script, seja ele uma chamada de método ou um comando. API solicitação ou interação do navegador.
5. Capture a saída real: Os valores de retorno, as cargas úteis de resposta, as linhas do banco de dados, as linhas de log e o estado da tela são todos registrados à medida que são produzidos.
6. Comparar com os resultados esperados: O validador de saída verifica cada valor capturado. Qualquer discrepância marca o caso como falho e registra tanto o valor esperado quanto o observado.
7. Registre e relate: O dispositivo grava um registro de data e hora. trace da execução e gera um relatório de aprovação/reprovação que um desenvolvedor pode ler sem precisar executar nada novamente.
8. Demolir: Os dados temporários, as conexões e o estado do stub são apagados para que o próximo caso não herde resíduos deste.

💡 Dica: Atualize seus stubs sempre que o módulo real for alterado. Um stub que ainda estiver respondendo com o formato do trimestre anterior exibirá uma execução bem-sucedida, enquanto a integração em produção já estará comprometida.

Um exemplo prático torna o loop concreto. Suponha que a página de finalização da compra esteja pronta, mas o gateway de pagamento não. Um driver dispara a solicitação que a interface normalmente enviaria, um stub responde primeiro com "Pagamento bem-sucedido" e depois com um tempo limite, e o validador confirma o pedido em um caso e exibe uma mensagem de nova tentativa no outro. Ambos os caminhos são verificados antes que a equipe do gateway escreva uma linha de código.

Existem dois contextos onde o Test Harness é usado

Esse mesmo mecanismo serve a dois propósitos distintos, e o vocabulário muda ligeiramente dependendo de qual deles você está usando.

1. Teste de automação: Contém o scripts de teste, parâmetros necessários para executar esses scripts e coletar resultados para analisá-los
2. Teste de integração: É usado para reunir duas unidades de código ou módulo que interagem entre si para verificar se o comportamento combinado é ou não o esperado.

Considere um módulo de login e um módulo de perfil que precisam trocar um token de usuário. No contexto da integração, um driver simula um login bem-sucedido e passa o token para a lógica de perfil, de modo que o mapeamento de dados seja estabelecido.pingA verificação de permissões e a renderização da tela podem ser verificadas antes que o serviço de autenticação real seja concluído. No contexto da automação, esse mesmo par de casos é adicionado a um conjunto de testes e executado novamente em cada build, sem que ninguém precise intervir.

Tipos de chicotes de teste

Como o software é construído em camadas, um conjunto de ferramentas geralmente é especializado para a camada que verifica. Quatro tipos abrangem quase todos os projetos.

A arnês de teste de unidade Os exercícios utilizam os menores trechos de código, como uma única função ou método, com todas as dependências substituídas por um stub. É o método mais rápido de executar e o mais barato de manter, e é por isso que... teste de unidade Geralmente, os ambientes de teste são a primeira ferramenta que uma equipe desenvolve. Testar um cálculo de impostos sem acessar o módulo de faturamento é um uso típico.

An conjunto de teste de integração Verifica se dois ou mais módulos cooperam corretamente e é a camada onde surgem as incompatibilidades de dados e as falhas de chamadas. É o mecanismo descrito em teste de integração No contexto acima, por exemplo, verifica-se se um serviço de pedidos entrega a carga útil correta a um serviço de pagamento.

A chicote de teste do sistema Gera um fluxo completo de ponta a ponta em interface, serviço e banco de dados, portanto teste do sistema É possível confirmar que as regras de negócio são válidas quando todas as camadas estão presentes. arnês de teste de regressão Em seguida, executa novamente o conjunto de testes acumulado após cada alteração, o que faz com que... teste de regressão Prático quando várias centenas de cenários precisam ser repetidos em cada mesclagem.

Ferramentas de teste de chicote

Cada um desses tipos é normalmente construído sobre uma ferramenta existente, em vez de ser desenvolvido do zero. As duas opções clássicas continuam sendo as estruturas de nível unitário:

• Junito: Ferramenta usada durante o uso Java
• Nunit: Ferramenta usada para usar Estrutura .Net

Além dessas duas, a maioria das equipes adiciona ferramentas que estendem a funcionalidade ao navegador, à camada de API ou ao perfil de carga. A tabela abaixo mapeia as opções comuns à função que cada uma desempenha.

Independentemente da combinação escolhida, o chicote de fios só se paga quando funciona sem supervisão, portanto, conecte-o a um... integração contínua emprego cedo. Um catálogo mais amplo de opções está listado no Guru99 ferramentas de teste Resumindo, uma distinção ainda causa confusão, e vale a pena esclarecê-la antes de tomar qualquer decisão.

Equipamento de teste versus estrutura de teste

Um harness e um framework de automação são frequentemente tratados como a mesma coisa, embora respondam a perguntas diferentes: o harness é o que executa um teste, enquanto o framework é a estrutura dentro da qual os testes são projetados. A tabela abaixo os compara lado a lado.

Perguntas Frequentes