INF 321 Avaliação dos testes

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

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.

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.

Oráculo Oráculo = informação + procedimento oráculo especificação implementação entrada saída esperada saída observada =  passou   não passou (defeito) falha oráculo 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 Terminologia da D.Richardson, Aha e Mailey 92 [Binder00, c.19]

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

Oráculo pré-teste Seleção de testes entradas de testes resultados Componente em testes 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

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 No JUnit tem comparador que permite inclusive comparar objetos, caso a saída gerada seja um objeto.

Exemplo: JUnit Cria classe de teste Cria objetos em teste 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; Exemplo: JUnit Cria classe de teste Cria objetos em teste Executa classe de teste Compara com resultado esperado Termina o teste

Oráculo baseado em comparação Seleção de testes entradas de testes saídas de referência Referência Componente em testes resultados 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

Oráculo baseado na especificação Seleção de testes entradas de testes resultados Componente em testes Comparador veredicto Especificação 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

Avaliação dos testes Serve para estabelecer: Critério de término dos testes Avaliação da qualidade dos testes Melhorias do processo

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, ... Testes geralmente são realizados no final do projeto. A tendência de ser abortado prematuramente é grande, devido a tempo curto ou escassez de recursos. Para evitar esse risco, o fim dos testes deve ser planejado e fazer parte do plano de testes.

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

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

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 Um bom processo de testes deve usar um BD de incidentes para centralizar todos os problemas ocorridos, seja durante os testes ou náo.

Exemplo de ciclo de vida de incidentes Incidentes passam por vários estados desde que entram no sistema até à resolução do problema Novo Rejeitado Em observação Aberto Em análise Novo: registro criado por testadores, desenvolveodres, clientes, etc Aberto: ? Em observação: o registro está em análise por autores, gerentes O autor pode declarar um incidente como Rejeitado. Em Análise: registro está sendo analisado pelo Autor Em correção: o Autor reconheceu o incidente como falha e Em Verificação: as correções voltam a ser verificadas (revisores ou testadores) Somente o executor dos testes pode mudar o status para Fechado Em correção Com falhas Fechado Em verificação

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”

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

Exemplo de estatísticas

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

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

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

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)

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

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)

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 Vazamento de memória Ferramenta de análise dinâmica

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 A memória não era liberada por falta de informação dos programadores: o que deve ser liberado após o tratamento de exceções? Conversa com programadores

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 Conversando mais uma vez com a equipe de desenvolvimento, o grupo de RCA descobre que havia um erro de projeto: só havia descrição de gerenciamento de recursos para situações normais, não fornecendo portanto informação suficiente para a implementação dos tratadores de exceção. Mais conversa com programadores

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

Exemplo de busca da causa-raiz Falha Freqüência de ocorrência Impacto Custo de diagnóstico Vazamento de memória Moderada Severo Alto As condições de exceção foram levantadas tardiamente no projeto Projeto descreve gerenciamento de recursos somente para situações normais Causa-raiz

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)

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]