Em sentido estrito, não é justo fazer reivindicações até que a qualidade do conjunto de testes seja estabelecida. A aprovação em 100% dos testes não é significativa se a maioria dos testes for trivial ou repetitiva entre si.
A questão é: Na história do projeto, algum desses testes descobriu bugs? O objetivo de um teste é encontrar erros. E se não o fizeram, falharam como testes. Em vez de melhorar a qualidade do código, eles podem estar apenas fornecendo uma falsa sensação de segurança.
Para aprimorar seus projetos de teste, você pode usar (1) técnicas de caixa branca, (2) técnicas de caixa preta e (3) teste de mutação.
(1) Aqui estão algumas boas técnicas de caixa branca para aplicar aos seus projetos de teste. Um teste de caixa branca é construído com código-fonte específico em mente. Um aspecto importante do teste da caixa branca é a cobertura do código:
- Toda função é chamada? [Cobertura funcional]
- Toda declaração é executada? [Cobertura de declarações - A cobertura funcional e a cobertura de declarações são muito básicas, mas são melhores que nada]
- Para cada decisão (como
ifou while), você tem um teste que o força a ser verdadeiro e outro que o força a ser falso? [Cobertura de decisão]
- Para cada condição que é uma conjunção (usos
&&) ou disjunção (usos ||), cada subexpressão tem um teste em que é verdadeiro / falso? [Cobertura da condição]
- Cobertura de loop: Você tem um teste que força 0 iterações, 1 iteração, 2 iterações?
- É cada
break um de um loop é coberto?
(2) As técnicas de caixa preta são usadas quando os requisitos estão disponíveis, mas o código em si não é. Isso pode levar a testes de alta qualidade:
- Seus testes de caixa preta cobrem várias metas de teste? Você deseja que seus testes sejam "gordos": eles não apenas testam o recurso X, mas também Y e Z. A interação de diferentes recursos é uma ótima maneira de encontrar bugs.
- O único caso em que você não deseja testes "gordos" é quando está testando uma condição de erro. Por exemplo, testando entrada de usuário inválida. Se você tentou atingir várias metas inválidas de teste de entrada (por exemplo, um CEP inválido e um endereço inválido), é provável que um caso esteja ocultando o outro.
- Considere os tipos de entrada e forme uma "classe de equivalência" para os tipos de entrada. Por exemplo, se seu código testar para ver se um triângulo é equilátero, o teste que usa um triângulo com lados (1, 1, 1) provavelmente encontrará os mesmos tipos de erros que os dados de teste (2, 2, 2) e (3, 3, 3) encontrará. É melhor gastar seu tempo pensando em outras classes de informações. Por exemplo, se seu programa lida com impostos, convém fazer um teste para cada faixa de imposto. [Isso é chamado de particionamento de equivalência.]
- Casos especiais são frequentemente associados a defeitos. Seus dados de teste também devem ter valores de limite, como aqueles acima, acima ou abaixo das bordas de uma tarefa de equivalência. Por exemplo, ao testar um algoritmo de classificação, você desejará testar com uma matriz vazia, uma matriz de elemento único, uma matriz com dois elementos e, em seguida, uma matriz muito grande. Você deve considerar casos de fronteira não apenas para entrada, mas também para saída. [Esta é uma análise de valor-limite de chamadas.]
- Outra técnica é "Erro de adivinhação". Você sente que, se tentar alguma combinação especial, poderá interromper o programa? Então tente! Lembre-se: seu objetivo é encontrar erros, não confirmar que o programa é válido . Algumas pessoas têm o dom de adivinhar erros.
(3) Por fim, suponha que você já tenha muitos testes agradáveis para cobertura de caixa branca e técnicas aplicadas de caixa preta. O que mais você pode fazer? É hora de testar seus testes . Uma técnica que você pode usar é o Teste de Mutação.
Sob teste de mutação, você faz uma modificação em (uma cópia) do seu programa, na esperança de criar um bug. Uma mutação pode ser:
Alterar uma referência de uma variável para outra variável; Inserir a função abs (); Alterar menor que para maior que; Excluir uma declaração; Substitua uma variável por uma constante; Excluir um método de substituição; Exclua uma referência a um super método; Alterar ordem dos argumentos
Crie várias dúzias de mutantes, em vários locais do seu programa [o programa ainda precisará ser compilado para testar]. Se seus testes não encontrarem esses erros, agora você precisará escrever um teste que possa encontrar o erro na versão mutada do seu programa. Depois que um teste encontra o bug, você mata o mutante e pode tentar outro.
Adendo : Esqueci de mencionar este efeito: os bugs tendem a se agrupar . O que isso significa é que quanto mais erros você encontrar em um módulo, maior a probabilidade de encontrar mais erros. Portanto, se você tem um teste que falha (ou seja, o teste é bem-sucedido, já que o objetivo é encontrar erros), não apenas você deve corrigi-lo, mas também deve escrever mais testes para o módulo, usando o comando técnicas acima.
Enquanto você encontrar bugs a uma taxa constante, os esforços de teste devem continuar. Somente quando houver um declínio na taxa de novos bugs encontrados, você deve ter certeza de que fez bons esforços de teste para essa fase de desenvolvimento.