Resumo: Cobertura e Adequação do Teste de Unidade
Software Unit Test Coverage and Adequacy
Hong Zhu, Patrick A. V. Hall, John H. R. May
Christian Reis
<kiko@async.com.br>
Resumo:
Este artigo (
Zhu et al., 1997) faz um levantamento dos critérios
existentes para medir a qualidade do teste de unidade. Além disso,
oferece uma classificação destes critérios, fazendo um resumo dos
métodos existentes para esta classificação.
Das diversas fases associadas à Engenharia de Software, o Teste é a
fase indispensável para validar e verificar sistemas em desenvolvimento.
Desde o estabelecimento desta noção, tem-se feito grande volume de
pesquisa em torno deste assunto. Uma das questões mais importantes na
execução de um teste é caracterizar quais (e quantos) testes são
suficientes para garantir qualidade do produto. Este artigo faz um
levantamento e discussão dos diversos critérios apresentados
acadêmicamente.
Critérios para teste se apóiam em alguns conceitos básicos:
- Cobertura de comandos: um parâmetro de quantas linhas do programa
são verificadas em um teste.
- Cobertura de decisão: é uma noção de quantos desvios são
verificados por um teste.
- Cobertura de caminho: especifica, dos caminhos possíveis
de um software, quantos são cobertos na execução de um teste.
- Adequação à mutação: analisa quanto o teste é sensível à
inserção de falhas artificiais no software.
Um critério de teste é o que define quais propriedades precisam ser
testadas para garantir inexistência de erros. Como é impossível garantir
inexistência, o conceito é utilizado, na prática, para definir uma
qualidade mínima que será validada pelo teste.
Podemos dividir os critérios de diversas formas: pela fonte da
informação usada para especificar o teste, pelo uso exclusivo da
interface para gerar os testes, e pela forma com que o teste é realmente
conduzido. Utilizando esta última forma para classificar os critérios,
o artigo faz uma análise de cada uma.
Critérios baseados na estrutura do software especificam o teste em
termos da cobertura de um conjunto de elementos do software ou
especificação. Estes critérios podem ser, por sua vez, divididos em dois
grupos:
- Baseados no Programa: estes incluem critérios de
adequação de controle de fluxo, que analisam o grafo de
execução de um programa; critérios de adequação baseados no
fluxo de dados, que analisam os caminhos que o código percorre
entre a inicialização dos dados e os pontos onde são alterados e lidos;
e critérios de adequação baseados em uma combinação dos dois
tipos, que usam relações de dependência entre os comandos e os seus
dados operandos.
- Baseados na Especificação: além de permitir a verificação
da corretidão das saídas de um programa, a especificação pode ajudar a
escolher casos de teste e medir a adequação dos critérios de teste.
Estes critérios focam na especificação, e ignoram o programa em
si. Há duas formas básicas se especificar formalmente um software: uma,
baseada em modelo, como especificações escritas em Z ou VDM, e
outra baseada em propriedades algebraicas, que especificam
quais equações as operações do programa devem obedecer.
Testes baseados em falhas focam em detectar falhas no software:
critérios de teste baseados em falhas utilizam uma medida da capacidade
destes testes efetivamente encontrarem uma falha. Há uma série de formas
diferentes de se aplicar estes testes e estabelecer critérios:
- Introdução de Erros: esta técnica envolve introduzir
erros no software e executar o teste, amostrando dos erros resultantes
quantos provieram das falhas introduzidas. As falhas em geral são inseridos
manualmente.
- Teste de Mutação: envolve criar uma coleção de versões do
software que diferem entre si e aplicar a bateria de testes. A
amostragem da saída dará uma proporção de falhas em relação ao original.
- Teste de Perturbação: este método foca em considerar
falhas que ocorrem em um um espaço de erros, e gerar funções de
perturbação para este programa; são posteriormente executados os
variantes perturbados e analisados os erros encontrados.
- O modelo RELAY: faz comparação entre o software com
falhas e uma variante hipoteticamente perfeita, e localiza as menores
unidades possíveis do programa que possuem uma falha; é feito, então,
uma análise iterativa destas regiões sensíveis.
- Teste de Mutação de Especificação: são implantados falhas
na especificação, e após execução de testes no software, são verificados
quais erros provieram das alterações introduzidas.
Estes critérios se focam em analisar o teste do programa em certos
pontos propensos a erros de acordo com nossa experiência. Se apóia na
idéia de particionar o domínio de entrada e saída e obter regiões
equivalentes para o teste.
- Partição de Entrada baseado na Especificação: a partir da
especificação, são determinadas regiões de equivalência; estas são em
geral separadas manualmente, embora tentativas existam de automatizar o
processo.
- Partição de Entrada baseado no Programa: analisando o
resultado do processamento de diferentes partes do programa, podem ser
determinados sub-domínios equivalentes; em geral, estes equivalem aos
caminhos do programa.
- Análise de Barreira: se concentra em selecionar N casos de
teste nas fronteiras de um espaço de entrada, e um caso de teste externo
a esta fronteira. O objetivo é determinar se as barreiras são
suficientes.
- Análise Funcional: enfatiza a corretidão dentro
de cada sub-domínio; deve ser usada para complementar a Análise de
Barreira e não isoladamente.
- Habilidade de detecção de Falhas
É uma medida bastante direta da efetividade de um critério de teste. É
feita de algumas formas diferentes: fazendo experimentos estatísticos em
cima dos dados dos testes, executando simulações dos testes em si com
entradas controladas, e fazendo análise formal dos relacionamentos entre
critérios de adequação, provando que a relação vale ou não para todos os
critérios usados.
- Confiabilidade do Software
É difícil fazer uma análise objetiva da confiabilidade do software
diretamente. Existem pesquisas na área que concluem que é mais difícil
de se obter certeza de confiabilidade usando teste randômico do que
teste de partição.
- Custo do Teste
Existem experimentos realizados analisando o custo do testo com caminhos
não-executáveis, e há evidencias de que verificar o custo de testar
através do número de casos de teste pode ainda vir a fornecer uma imagem
do custo total.
Além das formas apresentadas para avaliar o uso dos critérios descritos
no artigo, existe uma terceira forma de estudar as propriedades do
critério. Esta forma se concentra em estabelecer as propriedades
fundamentais da adequação de teste, e verificar se estas propriedades
são verificáveis para cada critério. Os autores acreditam que o estudo
axiomático pode melhorar bastante a compreensão da adequação do teste;
existe uma série de estudos desenvolvidos no sentido.
O artigo fez uma revisão ampla de critérios para avaliar a qualidade de
um teste e formas de compará-los. Embora o assunto ainda seja bastante
controverso, é provável que, com a adoção de um framework de
Garantia de Qualidade baseado em ISO9001, a aceitação de formas mais
formais de medidas do processo de teste seja maior.
-
Zhu, H., Hall, P. A. V. and May, J. H. R.: 1997, Software unit test coverage
and adequacy, ACM Computing Surveys 29(4), 367-427.
-
Christian Reis
2000-09-14