A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

QST112 06/2001 IC-UNICAMP Eliane Martins INF 321 Avaliação dos testes.

Apresentações semelhantes


Apresentação em tema: "QST112 06/2001 IC-UNICAMP Eliane Martins INF 321 Avaliação dos testes."— Transcrição da apresentação:

1 QST112 06/2001 IC-UNICAMP Eliane Martins INF 321 Avaliação dos testes

2 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

3 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, A.Spillner, T.Rossner, M.Winter, T.Linz. Software Testing Practice: Test Management. RockyNook, Cap. 8 D.N.Card. Learning from Our Mistakes with Defect Causal Analysis, 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, cap

4 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] [1] Howden, W. E., Functional Program Testing & Analysis, McGraw-Hill Book Company, 1987, p43.

5 QST112 06/2001 IC-UNICAMP Eliane Martins 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]

6 QST112 06/2001 IC-UNICAMP Eliane Martins Oráculo manual Geração de testes Componente em testes casos de 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

7 QST112 06/2001 IC-UNICAMP Eliane Martins Oráculo pré-teste Seleção de testes Componente em testes entradas de testes resultados veredicto Comparador 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

8 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

9 QST112 06/2001 IC-UNICAMP Eliane Martins 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

10 QST112 06/2001 IC-UNICAMP Eliane Martins 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 Componente em testes entradas de testes resultados veredicto Comparador saídas de referência Referência

11 QST112 06/2001 IC-UNICAMP Eliane Martins Oráculo baseado na especificação Seleção de testes Componente em testes entradas de testes resultados veredicto Comparador 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

12 QST112 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

13 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,...

14 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 Necessita de um bom gerenciamento de incidentes

15 QST112 06/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

16 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

17 QST112 06/2001 IC-UNICAMP Eliane Martins 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 Em análise Em correção Em verificação Com falhas Fechado

18 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íticae prioridade Correção imediataestiverem Fechados –Quando todos os incidentes de severidade Séria e prioridadeCorreção imediataestiverem Fechados

19 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 ) –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

20 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de estatísticas

21 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

22 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 : guia para a classificação (1995) ODC (Ortogonal Defect Classification) –Proposto em 1992 pela IBM

23 QST112 06/2001 IC-UNICAMP Eliane Martins Norma IEEE 1044 IEEE Std : Standard Classification for Software Anomalies –IEEE Std : 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

24 QST112 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)

25 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

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

27 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de busca da causa-raiz FalhaFreqüência de ocorrência ImpactoCusto de diagnóstico Vazamento de memória ModeradaSeveroAlto Vazamento de memória Não liberação de memória nos tratamentos de exceção Ferramenta de análise dinâmica

28 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de busca da causa-raiz FalhaFreqüência de ocorrência ImpactoCusto de diagnóstico Vazamento de memória ModeradaSeveroAlto 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

29 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de busca da causa-raiz FalhaFreqüência de ocorrência ImpactoCusto de diagnóstico Vazamento de memória ModeradaSeveroAlto Mais conversa com programadores Programadores não conseguem determinar o que deve ser liberado Projeto descreve gerenciamento de recursos somente para situações normais

30 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de busca da causa-raiz FalhaFreqüência de ocorrência ImpactoCusto de diagnóstico Vazamento de memória ModeradaSeveroAlto Experiência com projetos anteriores As condições de exceção foram levantadas tardiamente no projeto Projeto descreve gerenciamento de recursos somente para situações normais

31 QST112 06/2001 IC-UNICAMP Eliane Martins Exemplo de busca da causa-raiz FalhaFreqüência de ocorrência ImpactoCusto de diagnóstico Vazamento de memória ModeradaSeveroAlto Causa-raiz Projeto descreve gerenciamento de recursos somente para situações normais As condições de exceção foram levantadas tardiamente no projeto

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

33 QST112 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, ] 33


Carregar ppt "QST112 06/2001 IC-UNICAMP Eliane Martins INF 321 Avaliação dos testes."

Apresentações semelhantes


Anúncios Google