qst112 06/2001 ic-unicamp eliane martins inf 321 avaliação dos testes

QST112

06/2001

IC-UNICAMP Eliane Martins

INF 321

Avaliação dos testes

QST112

06/2001


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


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


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]

[1] Howden, W. E., Functional Program Testing & Analysis, McGraw-Hill Book Company, 1987, p43.

QST112

06/2001


Oráculo

• 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

especificação

implementação

entrada

saída esperada

saída observada

= passou não passou (defeito)

falha

oráculo

veredicto

[Binder00, c.19]

QST112

06/2001


Oráculo manual

Geração de testes

Componente em testes

casos de testes

resultadosveredicto

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


Oráculo pré-teste

Seleção de testes


entradas de testes

resultadosveredictoComparador

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


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


Exemplo: JUnit

import junit.framework.TestCase;import Calculadora;

public class CalculadoraTest extends TestCase {

private Calculadora calc_div; private Calculadora calc_mult;

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);

} protected void teardown(){ calc_div = null; calc_mult = null; }

Compara com resultado esperado

Cria classe de teste

Cria objetos em teste

Executa classe de teste

Termina o teste

QST112

06/2001


Oráculo baseado em comparação

• 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

Seleção de testes


entradas de testes


saídas de referência

Referência

QST112

06/2001


Oráculo baseado na especificação

Seleção de testes


entradas de testes


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

– Comparação com modelo após a execução análise post-mortem

Especificação

QST112

06/2001


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


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


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

Necessita de um bom gerenciamento de incidentes

QST112

06/2001


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


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


Exemplo de ciclo de vida de incidentes• Incidentes

passam por vários estados desde que entram no sistema até à resolução do problema

Novo

Aberto

Rejeitado Em

observação

Emanálise

Em correção

Em verificação

Com falhas Fechado

QST112

06/2001


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


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


Exemplo de estatísticas

40

11618

242

Novo

Em análise

Em correção

Em verificação

Fechado

Rejeitado

QST112

06/2001


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


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


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– Como dispor dos registros após o término

QST112

06/2001


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


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


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


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

Ferramenta de análise dinâmica

QST112

06/2001







Não liberação de memória nos tratamentos de exceção

Conversa com programadores

Programadores não conseguem determinar o que deve ser liberado

QST112

06/2001







Mais conversa com programadores

Programadores não conseguem determinar o que deve ser liberado

Projeto descreve gerenciamento de recursos somente para situações normais

QST112

06/2001







Experiência com projetos anteriores

As condições de exceção foram levantadas tardiamente no projeto


QST112

06/2001







Causa-raiz


As condições de exceção foram levantadas

tardiamente no projeto

QST112

06/2001


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(David Card 2001)

QST112

06/2001


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]

33

qst112 06/2001 ic-unicamp eliane martins inf 321 avaliação dos testes

Documents