segunda-feira, 6 de janeiro de 2014

Roteiros de Teste Unitário - "Pequenas partes que garantem a qualidade"

De acordo com a definição do ISTQB (International Software Testing Qualification Board), o Teste Unitário (ou teste de componente) corresponde ao teste realizado com os componentes individuais de um software, considerando componente como um item mínimo de software que pode ser testado isoladamente. Trata-se de uma parte importantíssima do teste de software, pois garante que a menor unidade do sistema está funcionando corretamente considerando diversas possibilidades de entrada de dados.

Na prática, podemos entender como trechos de código específicos, consistências, métodos, rotinas, chamadas a outros módulos, entre outros testes que podem existir dentro de um item de software. Lembrando que há uma distinção de testes unitários para linguagens de plataforma distribuída (Por exemplo.: .NET, Java, PHP) e para Mainframe que basicamente se restringe a testes existentes em componentes construídos na linguagem Cobol. A quantidade de tipos distintos de itens de teste e componentes é muito maior na plataforma distribuída.

Portanto, vamos nos ater a um exemplo específico de uma classe do projetoCalculoSimples.


No roteiro de teste unitário, teremos uma cobertura mínima de 6 casos de teste (5 casos de sucesso e 1 de erro) e a variação da quantidade dependerá das entradas dos parâmetros que resultarão em saídas específicas.

É comum considerarmos no mínimo um caso de teste de execução com sucesso e todos os outros casos referentes à situações de erro, porém o ideal é criar casos de teste para todos as possibilidades e desvios lógicos existentes no componente. Neste caso específico só há uma situação de erro descrita, porém se  tivéssemos definido mais tratamentos, todos deveriam ser considerados no Roteiro de Teste Unitário. Já as chamadas dos métodos InserirValor() e TransacaoXAB01() serão considerados somente em nível de integração, pois fazem referência a outras classes.

Talvez você esteja se questionando como esta classe será testada, uma vez que este teste se refere a menor unidade do sistema e as demais partes que se relacionam com este componente talvez ainda não tenham sido construídas. Para isto, deve-se criar um componente Driver, ou seja, um componente controlador que irá realizar a chamada desta classe. Em algumas situações também pode-se criar um stub que é um dispositivo que serve para simular um componente chamado pelo programa principal, caso fosse o escopo do teste.

O ideal é que todo roteiro de teste ao ser criado considere algumas premissas básicas para que o teste seja executado com sucesso.:

 - Possibilidade de Automação
 - Possibilidade de Reprodução e Repetibilidade
 - Facilidade na Implementação
 - Execução Ágil
 - Possibilidade de Reuso / Uso Futuro

Minimamente todo roteiro de teste unitário deve conter as seguintes colunas.:

 - Número Sequencial do Caso/Item de teste
 - Condição que o caso de teste irá testar
 - Dados de entrada que possibilitarão o teste
 - Resultado esperado do teste
 - Local físico/lógico que o teste será executado
 - Status do teste
 - Observações pertinentes ao teste

No mercado existem diversos frameworks e técnicas de teste unitário que abordaremos detalhadamente em outros posts.

No imagem a seguir, pode-se visualizar um exemplo contendo o dois casos unitários modelados (1 positivo e 1 negativo) da classe Matemática.



Testar é garantir a informação!

Nenhum comentário:

Postar um comentário