O que é teste de módulo? Definição, Exemplos

Por: Thomas Hamilton Thomas Hamilton
Hours Atualização do

⚡ Resumo Inteligente

O teste de módulos verifica subprogramas, sub-rotinas, classes e procedimentos individuais, em vez do programa completo, de modo que os defeitos surgem dentro de um pequeno bloco de código bem compreendido, onde permanecem baratos de localizar e corrigir.

  • 🎯 Objetivo: O objetivo é expor os erros em um módulo, não demonstrar que o módulo funciona.
  • ⚪ Orientação: A técnica é predominantemente do tipo "caixa branca", complementada por casos "caixa preta" extraídos das especificações.
  • ⏩ Paralelismo: Vários módulos podem ser testados ao mesmo tempo, o que reduz o tempo total de teste.
  • 🔗 Dois métodos: Os módulos são combinados de forma incremental, passo a passo, ou de forma não incremental, em uma única passagem.
  • 🧰 Andaimes: Os drivers fornecem dados de teste para um módulo, enquanto os módulos stub representam os módulos que ele chama.
  • 🆚 Propriedade: Os testadores escrevem testes de módulo após a codificação, enquanto os desenvolvedores escrevem testes unitários durante a codificação.
  • ⚠️ desafios: Trabalho não incremental, dublês de teste mal interpretados e depuração frequente consomem a maior parte do esforço.
Saiba Mais

Explicação sobre testes de módulos, incluindo métodos, drivers, stubs e comparações.

O que é teste de módulo?

teste de módulo É um tipo de teste de software que verifica subprogramas, sub-rotinas, classes ou procedimentos individuais em um programa. Em vez de testar o programa de software inteiro de uma só vez, o teste de módulos recomenda testar os blocos de construção menores do programa.

O teste de módulos é em grande parte orientado a testes de caixa branca. O objetivo do teste de módulos não é demonstrar o funcionamento correto do módulo, mas sim demonstrar a presença de um erro nele. Essa inversão é importante: uma execução que não encontra nada confirmou muito pouco, enquanto uma execução que expõe um defeito cumpriu seu papel.

Os testes em nível de módulo também permitem a introdução de paralelismo no processo de teste, pois criam a oportunidade de testar vários módulos simultaneamente, em vez de esperar por uma compilação completa.

Por que fazer testes de módulo

Recomenda-se o teste de módulos porque ele altera a economia da detecção de defeitos.

  • A probabilidade de identificar erros ou bugs em partes menores de um programa aumenta.
  • Vários módulos podem ser testados simultaneamente, e, portanto, essa abordagem suporta testes paralelos.
  • A complexidade dos testes pode ser gerenciada facilmente, uma vez que cada módulo é analisado individualmente.
  • Um defeito encontrado dentro de um módulo é tracÉ possível trabalhar com uma pequena quantidade de código, o que reduz drasticamente o tempo de depuração.

Como fazer testes de módulo?

Criando um caso de teste é o segmento importante do teste de módulo. Ao projetar casos de teste para um teste de módulo, um testador precisa levar duas coisas em consideração.

  • Especificação do módulo
  • O código fonte do módulo

Analise a lógica do módulo usando um ou mais dos seguintes métodos: caixa branca métodos e, em seguida, complementar esses casos de teste aplicando caixa-preta métodos para a especificação do módulo. Valores realistas são tão importantes quanto os caminhos escolhidos, portanto, prepare o dados de teste Ao lado dos casos, e não posteriormente.

Após a elaboração dos casos de teste, o próximo passo é combinar os módulos para teste. O método utilizado é um... incrementais não incremental método.

  • Método não incremental — todos os módulos são testados independentemente. Primeiro, todos os módulos são combinados e, em seguida, o programa inteiro é testado.
  • método incremental — Cada módulo é testado primeiro e, em seguida, adicionado gradualmente à coleção testada. O processo realiza um novo teste passo a passo.
  • Dentro dos testes incrementais, existem duas abordagens: de cima para baixo e de baixo para cima teste.
  • Para executar o módulo com os dados selecionados, é necessário um driver para fornecer os dados de teste, monitorar a execução e capturar os resultados.

A escolha entre os dois métodos representa um equilíbrio entre o esforço de configuração e a facilidade de diagnóstico.

Aspecto método incremental Método não incremental
Densidades Um módulo de cada vez, adicionado a uma coleção testada. Todos os módulos foram combinados e testados em conjunto.
É necessário um andaime. Mais pilotos e esboços, escritos progressivamente Menos dublês de teste, já que módulos reais estão presentes.
Isolamento obrigatório Forte — um ponto de falha no módulo recém-adicionado Fraco — uma falha pode ter origem em qualquer lugar
Melhor adequado para Construções de grande porte com muitos módulos interagindo entre si Programas pequenos com poucos módulos e baixo acoplamento.

ARTIGOS RELACIONADOS

Drivers e stubs em testes de módulos

O driver mencionado acima é metade de um par. Como um módulo em teste raramente está no início ou no fim da cadeia de chamadas, os testadores substituem o que estiver faltando em qualquer um dos lados por um código fictício.

  • Dirigir — substitui o módulo de chamada acima daquele em teste. Ele fornece os dados de teste, invoca o módulo, monitora a execução e captura os resultados. O teste bottom-up depende dos drivers, pois os módulos de nível inferior ficam prontos antes dos de nível superior.
  • Stub — substitui um módulo chamado abaixo daquele que está sendo testado. Ele aceita a chamada e retorna uma resposta fixa e conhecida para que o módulo em teste possa completar seu caminho. O teste de cima para baixo depende de stubs, porque os módulos de nível superior ficam prontos primeiro.

Um caso de teste concretiza a integração. Se um módulo de cálculo de pagamento estiver concluído, mas a tela de finalização da compra que o chama ainda não, um driver envia ao módulo um conjunto de totais de pedidos e registra o resultado. Se o serviço de consulta de impostos que o módulo chama também não estiver concluído, um protótipo retorna uma taxa de imposto fixa para que o cálculo ainda seja executado. Nenhuma das partes da estrutura de suporte é enviada; ambas são descartadas assim que os módulos reais chegam, e é por isso que a incompreensão dos protótipos é listada posteriormente como um desafio recorrente.

Exemplos de dicas para teste de módulo

Aqui estão algumas dicas a serem consideradas antes de realizar os testes de módulo.

  • RevVeja os casos de teste antes de usá-los.
  • Evite confusão sobre a origem das discrepâncias.
  • Utilize ferramentas de teste automatizadas.
  • Analise as variáveis ​​que devem permanecer inalteradas.
  • Troque os módulos entre os testadores para evitar autotestes.
  • Reutilize os casos de teste.

A quinta dica tem mais peso do que seu tamanho sugere. Um desenvolvedor que testa apenas o módulo recém-escrito repete as mesmas premissas que produziram o defeito; portanto, alternar os módulos entre as pessoas é um dos ganhos de qualidade mais baratos disponíveis.

Teste de unidade versus teste de módulo

Os dois termos são usados ​​de forma intercambiável em muitas equipes, embora a autoria e o escopo sejam diferentes.

Teste de módulo Teste de Unidade
Os testes de módulo são uma coleção de testes escritos por um testador depois que algum código foi escrito por um desenvolvedor Testes unitários são uma coleção de testes escritos por um desenvolvedor durante o processo de desenvolvimento de software.
O teste de módulos pode envolver a combinação de testes unitários. Os testes unitários podem testar unidades isoladamente.

Teste de módulo vs. teste de componente vs. teste de integração

O teste de módulos também fica próximo a dois níveis vizinhos que são fáceis de confundir com ele. A tabela os separa pelo que está sendo testado e quem normalmente realiza o teste.

Aspecto teste de módulo Teste de componentes Teste de integração
Em teste Um subprograma, classe ou procedimento Um componente independente com suas dependências imediatas. As interfaces entre módulos combinados
Proprietário habitual Testador, após a escrita do código testador Testador de integração
andaime Motoristas e canhotos Esboços para dependências externas Progressivamente menos testes duplos
Defeito exposto Erro lógico dentro do módulo Erro de comportamento no componente Erro de interface e passagem de dados

Em uso diário teste de componentes e os testes de módulos são frequentemente tratados como a mesma atividade, enquanto teste de integração Só começa depois que cada módulo individual for aprovado por si só.

Desafios no teste de módulo

Esses são os desafios que as equipes enfrentam com mais frequência quando os testes de módulo são introduzidos.

  • Testes não incrementais requerem mais trabalho — Combinar tudo primeiro significa que uma única falha pode fazer com que os testadores revisem todo o programa.
  • Teste de mal-entendido duplica — um stub que retorna um valor irrealista produz uma sequência verde que não prova nada.
  • Depurar testes frequentemente — O código de estrutura básica traz seus próprios defeitos, e o tempo gasto corrigindo um driver é tempo que não é gasto testando o módulo.
  • Precisa entender o código — A orientação de caixa branca significa que um testador que não consegue ler o módulo não pode criar casos significativos para ele.

Perguntas Frequentes

A família xUnit abrange a maioria das linguagens, com bibliotecas de simulação que fornecem os stubs e uma ferramenta de cobertura que mostra quais caminhos foram alcançados. A escolha segue a linguagem do módulo, não o nível de teste.

Um modelo lê o código-fonte do módulo, enumera as ramificações e propõe uma solução para cada uma, incluindo valores limite que uma análise manual geralmente não detecta. RevA visualização continua sendo necessária, porque os casos gerados afirmam o que o código faz, em vez do que a especificação exige.

Sim, e é no desenvolvimento de código que esses assistentes têm melhor desempenho, já que um driver ou stub é um código repetitivo com uma estrutura conhecida. Os valores retornados ainda precisam de uma decisão humana, porque um stub com aparência plausível pode ocultar o próprio defeito que está sendo procurado.

O suficiente para que cada ramificação e cada limite no módulo tenham sido exercitados pelo menos uma vez. Uma meta percentual por si só é enganosa, porque uma alta cobertura de instruções ainda pode deixar resultados de decisão inteiros sem serem testados.

Após a compilação de um módulo e antes que suas interfaces sejam exercitadas em conjunto, realiza-se o primeiro nível de teste aplicado ao código entregue. Por isso, os defeitos detectados nessa etapa nunca chegam às fases de integração ou de sistema.

Siga o código existente. A abordagem de cima para baixo é adequada para projetos em que a lógica de controle é escrita primeiro e os módulos inferiores são implementados automaticamente; a abordagem de baixo para cima é adequada para projetos em que os módulos de utilitários são implementados primeiro e os drivers os chamam.

O módulo compila sem erros, sua especificação está disponível, suas dependências estão presentes ou foram definidas, e os dados de teste estão prontos. Começar sem a especificação transforma o exercício em uma descrição do código.

Os testes nunca podem provar que um módulo não tem defeitos, apenas que ele sobreviveu aos casos testados. Portanto, projetar execuções que tentam quebrar o módulo retorna mais informações do que projetar execuções que se espera que sejam bem-sucedidas.

Resuma esta postagem com: