O Rigor na captura de casos de teste para testes de unidade

Question

Vamos dizer que temos uma simples função definida em uma pseudo-linguagem.

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

Podemos passar uma lista não-ordenada de números e um booleano especificar em ordem crescente ou decrescente ordem de classificação.Em contrapartida, temos uma lista ordenada de números.

Na minha experiência, algumas pessoas são melhores em captar condições de contorno do que outros.A questão é, "Como você sabe quando você está 'concluído' a captura de casos de teste"?

Podemos começar a listagem de casos e algumas pessoa inteligente irá, sem dúvida, pensar 'mais um' caso que não é abrangido por qualquer uma das anteriores.

Answer 1

Não perca muito tempo tentando pensar todos boundry condição.Os testes não ser capaz de pegar todos bug primeira vez.A ideia é ter testes que são muito bom, e , em seguida, a cada vez que um bug não superfície, escrever um novo teste especificamente para que o bug de modo que você nunca ouvir de novo.

Outra observação que quero fazer sobre ferramentas de cobertura de código.Em uma linguagem como C# ou Java, onde o seu tem muitos get/set e métodos semelhantes, você deve não fotografar para uma cobertura de 100%.Isso significa que você está desperdiçando tempo demais escrevendo testes para triviais de código.Você apenas quer uma cobertura de 100% sobre a complexa lógica de negócios.Se o seu total codebase é mais perto de 70 a 80% de cobertura, você está fazendo um bom trabalho.Se a sua ferramenta de cobertura de código permite que várias métricas de cobertura, o melhor é o "bloco de cobertura", que mede a cobertura de 'blocos básicos'.Outros tipos de método e classe de cobertura (que não dão a você o máximo de informações) e da linha de cobertura (que é muito fino).

Answer 2

Como você sabe quando você está 'concluído' a captura de casos de teste?

Você não.Você não pode chegar a 100%, exceto para o mais trivial dos casos.Também 100% de cobertura (de linhas, caminhos, condições...) não lhe atingiu todas as condições de contorno.

Mais importante ainda, os casos de teste não são de escrita-e-esquecer. A cada vez que você encontrar um bug, escrever um ensaio adicional. Verificação falhar com o programa original, verifique passa com o programa corrigido e adicioná-lo ao seu conjunto de teste.

Um trecho de A Arte de Teste de Software por Glenford J.Myers:

1. Se uma condição de entrada especifica um intervalo de valores, escrever casos de teste para as extremidades do intervalo, e o inválido de entrada de casos de teste para situações além das extremidades.
2. Se uma condição de entrada especifica um número de valores, escrever casos de teste para o número mínimo e máximo de valores e uma por baixo e além desses valores.
3. Use diretriz 1 para cada condição da saída.
4. Use diretriz 2 para cada condição da saída.
5. Se a entrada ou saída de um programa é um conjunto ordenado concentrar a atenção sobre o primeiro e o último elementos do conjunto.
6. Além disso, usar sua criatividade para a busca de outras condições de contorno

(Eu tenho colado apenas o mínimo, por motivos de direitos autorais.)

Pontos 3.e 4.acima são muito importantes.As pessoas tendem a se esqueça de condições de contorno para as saídas.5.é OK.6.realmente não ajuda :-)

Curta exame

Isso é mais difícil do que parece.Myers oferece este teste:

O programa lê três valores inteiros a partir de um diálogo de entrada.Os três valores representam os comprimentos dos lados de um triângulo.O programa exibe uma mensagem que indica se o triângulo é escaleno, isósceles ou equilátero.

Lembre-se que um triângulo escaleno é aquele em que não há dois lados são iguais, enquanto que um triângulo isósceles tem dois lados iguais, e de um triângulo equilátero tem três lados de igual comprimento.Além disso, os ângulos opostos a lados iguais de um triângulo isósceles também são iguais (também segue-se que os lados opostos iguais os ângulos de um triângulo são iguais), e todos os ângulos de um triângulo são iguais.

Escreva a sua casos de teste.Quantas você tem?Myers pergunta 14 perguntas sobre o conjunto de teste e relatórios profissionais altamente qualificados e programas de média de 7,8 dos 14.

Answer 3

Do ponto de vista prático, vou criar uma lista de testes que eu acredito que deve passar antes da sua aceitação.Eu testar essas e automatizar sempre que possível.Com base na quantidade de tempo que eu estimado para a tarefa ou quanto tempo eu tenho dado, eu estender a minha cobertura de teste para incluir itens que devem passar antes da sua aceitação.Claro, a linha entre o deve e deve é subjetivo.Depois disso, eu atualização de testes automatizados como bugs são descobertos.

Answer 4

@Keith

Eu acho que você acertou em cheio, a cobertura de código é importante para olhar se você quiser ver como é "feito", mas eu acho que 100% é um pouco irreal, um objetivo.Esforçando-se para 75-90% vai lhe dar uma boa cobertura, sem ir ao mar...não teste para o puro amor de acertar 100%, porque naquele momento você está apenas desperdiçando seu tempo.

Answer 5

Uma boa ferramenta de cobertura de código realmente ajuda.

Cobertura de 100% não significa que ele definitivamente é devidamente testado, mas é um bom indicador.

Para .Net NCover é muito bom, mas não é open source.

---

@Mike Stone - Sim, talvez, que deve ter sido "cobertura" - temos o objetivo de 80% mínimo, passado cerca de 95% é geralmente de retornos decrescentes, especialmente se você tiver o cinto 'n' chaves de código.