IC-UNICAMP
Eliane Martins
INF 321
Avaliação dos testes
QST112
06/2001
IC-UNICAMP
Eliane Martins
Tópicos
• Análise de resultados
• Exemplos de oráculos
• Avaliação da qualidade dos testes
• Métricas de teste
• Gerenciamento de incidentes
• Análise causa-raiz
QST112
06/2001
IC-UNICAMP
Eliane Martins
Referências
R.Binder. Testing OO Systems. Addison Wesley, 1999, c.18.
A. Bartié. Garantia da Qualidade de Software. Editora Campus,
2002.
A.Spillner, T.Rossner, M.Winter, T.Linz. “Software Testing Practice:
Test Management”. RockyNook, 2007. Cap. 8
D.N.Card. Learning from Our Mistakes with Defect Causal Analysis,
2001. Slides baseados em artigo da IEEE Software, jan/1998.
M.Pezzè, M. Young. Teste e Análise de Software. Bookman. 2008,
cap. 20.
S.L.Pfleeger. Engenharia de Software. Teoria e Prática. Pearson
Educacional do Brasil / Prentice Hall. 2ª edição, 2004, cap. 8.
R.S.Pressman. Engenharia de Software. McGraw-Hill, 6ª edição,
2006. cap. 26.6.
QST112
06/2001
IC-UNICAMP
Eliane Martins
Introdução
• Dois grandes problemas em testes (manuais ou
automáticos):
– Geração dos casos de teste
– Análise dos resultados:
• A saída do sistema está conforme o especificado?
Problema do oráculo
• Oráculo: definição original
– “Função que, dado um programa P, pode determinar, para
cada entrada x, se a saída de P é igual àquela gerada por uma
versão “correta” de P” [1]
QST112
[1] Howden, W. E., Functional Program Testing & Analysis, McGraw-Hill Book Company, 1987, p43.
06/2001
IC-UNICAMP
Eliane Martins
Oráculo
especificação
entrada
falha
implementação
oráculo
saída
esperada
saída
observada
=  passou
  não passou
(defeito)
veredicto
• Oráculo = informação + procedimento
– Informação do oráculo
• Indica as saídas esperadas para cada entrada de teste
– Procedimento do oráculo
• Compara a saída observada com a esperada
QST112
06/2001 [Binder00, c.19]
IC-UNICAMP
Eliane Martins
Oráculo manual
Geração de testes
casos de
testes
Componente
em testes
resultados
veredicto
 Lento
• Resultados devem ser fornecidos em uma taxa
adequada para ser tratado por uma pessoa
 Não escalável
• Impossível tratar grande volume de dados
 Sujeito a erros
QST112
06/2001
IC-UNICAMP
Eliane Martins
Oráculo pré-teste
Seleção de testes
entradas
de testes
Componente
em testes
resultados
Comparador
veredicto
saídas esperadas
• As saídas esperadas são produzidas antes da execução
dos testes
• As saídas esperadas podem ser incorporadas aos
casos de testes para permitir a comparação automática
QST112
06/2001
IC-UNICAMP
Eliane Martins
Oráculo pré-teste: geração das saídas
• Manual
• Automática:
– Simulação
– Uso de assertivas embutidas no código
• do software em teste
• do caso de teste
– Uso de um algoritmo que produza os valores
esperados para cada entrada
– Uso da especificação
QST112
06/2001
import junit.framework.TestCase;
import IC-UNICAMP
Calculadora;
public class CalculadoraTest extends TestCase {
private Calculadora calc_div;
private Calculadora calc_mult;
Eliane Martins
Exemplo: JUnit
Cria classe de teste
public TestCalc(String arg0) {
super(arg0);
protected void setup(){
calc_div = new Calculadora();
calc_mult = new Calculadora ();
}
public static void main(String[] args) {
junit.textui.TestRunner.run(CalculadoraTest.class);
public void testDivisao() {
float resultado;
resultado = calc_div.divisao(1.0/5.0);
assertEquals(resultado, 0.2);
Cria objetos em teste
Executa classe de teste
Compara com resultado
esperado
Termina o teste
}
protected void teardown(){
calc_div = null;
QST112
06/2001
IC-UNICAMP
Eliane Martins
Oráculo baseado em comparação
Seleção
de testes
entradas de testes
Componente
em testes
Referência
resultados
saídas de
referência
Comparador
veredicto
• Baseia-se no uso de uma referência (golden
standard):
– Sistema legado, implementação de terceiros, variante, ...
• Usado em ferramentas de captura e repetição
QST112
06/2001
IC-UNICAMP
Eliane Martins
Oráculo baseado na especificação
Seleção de testes
entradas
de testes
Componente
em testes
Especificação
resultados
Comparador
veredicto
saídas esperadas
• Baseia- se na especificação para derivar saídas esperadas
• Se existe modelo formal:
– Derivação de casos de testes com saídas esperadas  análise
durante a execução
QST112
– Comparação com modelo após a execução  análise
post-mortem
06/2001
IC-UNICAMP
Eliane Martins
Avaliação dos testes
• Serve para estabelecer:
– Critério de término dos testes
– Avaliação da qualidade dos testes
– Melhorias do processo
QST112
06/2001
IC-UNICAMP
Eliane Martins
Critérios de término dos testes
• Quando terminam os testes?
• Critérios típicos:
Cobertura dos testes (requisitos ou código)
Qualidade do produto: nro de falhas encontradas,
criticidade dos defeitos, taxa de defeitos, ...
Risco residual: nro de casos de teste não
executados, nro de falhas eliminadas, cobertura
incompleta, ...
Custos: atingiu topo dos custos e/ou recursos
permitidos, esgotou prazo, ...
QST112
06/2001
IC-UNICAMP
Eliane Martins
Avaliação da qualidade dos testes
• Obtenção de métricas:
– Número de falhas e defeitos
• Associar com tamanho e complexidade do sw
–
–
–
–
Número de casos de teste especificados
Número de casos de teste bloqueados
Número de casos de teste executados
Cobertura de código, de funcionalidades, de telas,
de plataformas, ...
– Nro de falhas “escapadas”
• Falhas cuja presença é revelada pelo cliente

QST112
Necessita de um bom gerenciamento de incidentes06/2001
IC-UNICAMP
Eliane Martins
Gerenciamento de incidentes
• Necessário para:
– Agilizar correções
– Avaliar qualidade dos testes
• Auxilia na melhoria da qualidade do processo
– Análise de causa-raiz
QST112
06/2001
IC-UNICAMP
Eliane Martins
Registro de Incidentes
• Banco de dados centralizado para relato de
incidentes:
– Erros em partes testadas do sistema, manual do
usuário, especificação ou outros
– Correções feitas pelos desenvolvedores
– Comentários feitos pelos desenvolvedores sobre
os incidentes registrados
– Acesso controlado
– Geração de relatórios
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de ciclo de vida de incidentes
Novo
Rejeitado
Em
observação
Aberto
• Incidentes
passam por
vários estados
desde que entram
no sistema até à
resolução do
problema
Em
análise
Com
falhas
Em
correção
Em
verificação
Fechado
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de critério de término
• As informações do registro de incidentes
servem para determinar quando terminar os
testes:
– Quando todos os incidentes de severidade
“Crítica”e prioridade “Correção imediata”estiverem
“Fechados”
– Quando todos os incidentes de severidade “Séria”
e prioridade“Correção imediata”estiverem
“Fechados”
QST112
06/2001
IC-UNICAMP
Eliane Martins
Uso de ferramentas
• Uma ferramenta de gerenciamento ou rastreio de
incidentes é preferível ao uso de papel ou planilha
– Melhor controle do workflow de incidentes
– Acesso aos registros pode ser controlado de acordo com o
papel dos envolvidos
– Mudanças de status podem ser automaticamente
comunicadas aos envolvidos (ex.: via e-mail)
– Possibilidade de conectar a ferramenta com outras utilizadas
ao longo do desenvolvimento, o que melhora a
rastreabilidade e o acompanhamento do progresso do
desenvolvimento
– Geração de estatísticas para acompanhamento da qualidade
do produto
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de estatísticas
2
24
40
18
6
11
Novo
Em análise
Em correção
Em verificação
Fechado
Rejeitado
QST112
06/2001
IC-UNICAMP
Eliane Martins
Classificação de incidentes
• Hoje em dia existem diversos sistemas para registro
de incidentes (ou anomalias)
– grande heterogeneidade dos dados coletados
• Um esquema de classificação preciso das anomalias
detectadas:
– Ajuda a uniformizar as informações coletadas ao longo de
todo o ciclo de vida do software
– Guardar histórico das falhas e defeitos encontrados:
• Ajuda a direcionar os testes
• Permite melhoria da qualidade do processo
QST112
06/2001
IC-UNICAMP
Eliane Martins
Padrões de classificação
• Norma IEEE 1044: padrão para classificação
de anomalias de software (1993)
– IEEE 1044.1: guia para a classificação (1995)
• ODC (Ortogonal Defect Classification)
– Proposto em 1992 pela IBM
QST112
06/2001
IC-UNICAMP
Eliane Martins
Norma IEEE 1044
• IEEE Std 1044-1993: Standard Classification for Software
Anomalies
– IEEE Std 1044.1-1995: Guide to Classification for Software
Anomalies
• Objetivo:
– Classificar as anomalias reportadas nos registros de incidentes
• Aplicável ao longo de todo o ciclo de vida
• Adaptável
• Classifica:
–
–
–
–
As anomalias, seus graus de severidade e impacto
Atividades que levaram à detecção da anomalia
Ações necessárias para resolução da anomalia QST112
Como dispor dos registros após o término
06/2001
IC-UNICAMP
Eliane Martins
ODC – Análise de Falhas
• Feita em duas fases:
– Quando as falhas são corrigidas, registra-se:
• Alvo: indica o artefato que está sendo corrigido (ex.: projeto,
código)
• Tipo: indica o gênero da falha, e pode também indicar sua
natureza:
– Omissão: falta algo
– Incorreção: algo está errado
– Extra: sobra algo
• Fonte: origem dos componentes com falha (feito em casa,
biblioteca, carregado de outra plataforma ou COTS)
• Idade: tempo de existência do componente com falha (código
original, novo, reescrito ou corrigido)
QST112
06/2001
IC-UNICAMP
Eliane Martins
Melhoria do processo de desenvolvimento
• Muitas das falhas que ocorrem com freqüência
têm origem no processo de desenvolvimento
– Ex.: falta de experiência com o ambiente de
desenvolvimento pode levar a falhas no tratamento de
exceções
• Associar estas falhas ao processo é difícil
• A análise do histórico de falhas serve para
rastrear suas causas, fornecendo informações
importantes para a melhoria do processo
Análise de causa-raiz
QST112
06/2001
IC-UNICAMP
Eliane Martins
Análise de causa-raiz
• Também chamada de RCA (Root-Cause Analysis)
• Desenvolvida inicialmente na indústria de
energia nuclear, mais tarde estendida para o sw
• Examina informações sobre incidentes
• Visa identificar causas das falhas de modo que
estas possam ser evitadas ou reveladas mais
cedo
• Realizadas:
– Quando a situação sai do controle (corretiva)
– Como parte da melhoria do processo (preventiva)
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de busca da causa-raiz
Falha
Freqüência de
ocorrência
Impacto
Custo de
diagnóstico
Vazamento de
memória
Moderada
Severo
Alto
Vazamento
de memória
Não liberação de
memória nos
tratamentos de
exceção
Ferramenta de análise dinâmica
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de busca da causa-raiz
Falha
Freqüência de
ocorrência
Impacto
Custo de
diagnóstico
Vazamento de
memória
Moderada
Severo
Alto
Não liberação de
memória nos
tratamentos de
exceção
Programadores não
conseguem
determinar o que
deve ser liberado
Conversa com programadores
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de busca da causa-raiz
Falha
Freqüência de
ocorrência
Impacto
Custo de
diagnóstico
Vazamento de
memória
Moderada
Severo
Alto
Programadores não
conseguem
determinar o que
deve ser liberado
Projeto descreve
gerenciamento de
recursos somente
para situações
normais
Mais conversa com programadores
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de busca da causa-raiz
Falha
Freqüência de
ocorrência
Impacto
Custo de
diagnóstico
Vazamento de
memória
Moderada
Severo
Alto
Projeto descreve
gerenciamento de
recursos somente
para situações
normais
As condições de
exceção foram
levantadas
tardiamente no
projeto
Experiência com projetos anteriores
QST112
06/2001
IC-UNICAMP
Eliane Martins
Exemplo de busca da causa-raiz
Falha
Freqüência de
ocorrência
Impacto
Custo de
diagnóstico
Vazamento de
memória
Moderada
Severo
Alto
Projeto descreve
gerenciamento de
recursos somente
para situações
normais
As condições de exceção
foram levantadas
tardiamente no projeto
Causa-raiz
QST112
06/2001
IC-UNICAMP
Eliane Martins
Sumário - RCA
• RCA é fácil de implementar e tem baixo custo:
– 1,5% do custo do sw (incluindo a realização das
ações)
• Melhora a qualidade do produto e do processo
• Reação favorável do pessoal envolvido
• Empregado com sucesso em empresas como
IBM, Lucent
• Pode ser aplicado em qqr processo que tenha
controle sobre defeitos e falhas
QST112
(David Card 2001)
06/2001
IC-UNICAMP
Eliane Martins
Sumário - RCA
• As propostas de melhoria se focalizam nas
poucas causas vitais (princípio de Pareto ou
80/20)
• Em resumo:
“Deve-se gastar o tempo focalizando as
coisas que realmente importam, mas primeiro
esteja certo de que se sabe o que realmente
importa.”
[Pressman06, 26.6.1]
QST112
3306/2001