Testes de Software. Rodrigo Paes. Apoio:

Transcrição

1 Testes de Software Rodrigo Paes Apoio:

2 Agenda Motivação Tipos de Testes Processo de Teste Artefatos Estratégias para construir casos de teste Casos de teste a partir de casos de uso Desafios da Especificação de Testes Exercício LES/PUC-Rio Slide 2 de 27

3 Introdução Apoio:

4 O Mito + + = Casos de Testes Casos de Teste Implementados Teste da Aplicação Programa Correto Teste somente sinaliza Maior Confiabilidade a presença de faltas, nunca a Testes completos de software são inviáveis Maior sua ausência! Qualidade LES/PUC-Rio Slide 4 de 27

5 Introdução Atividades controladas visando identificar problemas Envolve ações que vão do levantamento de requisitos até a execução dos testes propriamente ditos Verificar resultados encontrados X resultados esperados Localizar e documentar defeitos Maximizar a quantidade potencial de defeitos que podem ser detectados antes da entrega do produto ao cliente LES/PUC-Rio Slide 5 de 27

6 Introdução Testes devem ser realizados no decorrer do ciclo de desenvolvimento Não é uma boa prática realizar após o desenvolvimento Integrar testes no decorrer do desenvolvimento Na Abordagem XP testes são realizados antes da escrita do código de negócio LES/PUC-Rio Slide 6 de 27

7 Introdução Desvantagens: caros e demorados pouco eficientes encontram poucas falhas a cada execução pouco eficazes estatísticas mostram que encontram somente cerca de 65% de todos os problemas identificados devem ser projetados cuidadosamente visando aumentar eficiência e eficácia Entretanto... Não testar pode ser desastroso! LES/PUC-Rio Slide 7 de 27

8 Custo de Correção O custo de 1 problema é 200 vezes maior se for reparado após a implantação Estágio 0,1 a 0,2 Requisitos 0,5 Projeto 1 Codificação 2 Teste de Unidade 5 Teste de Aceitação 20 Manutenção Custo Relativo de Reparo LES/PUC-Rio Slide 8 de 27

9 Tipos de Testes Teste de Unidade Teste de Integração Teste de Regressão Teste de Sistema Teste de Aceitação Teste de Integridade de Dados e de Banco de Dados Teste Funcional Teste de Interface com o usuário Teste de desempenho Diferenças entre entre alguns alguns tipos tipos de de testes Teste de Carga testes não não são são muito muito claras claras Teste de Stress Ex.: Ex.: Teste Teste Funcional X Teste Teste de Teste de Segurança de Sistema X Teste Teste de de Aceitação Teste de Tolerância a Falhas Teste de Recuperação Você Você provavelmente deve deve ter ter em em mente Teste de Configuração mente algum algum tipo tipo de de teste teste que que não não está estánessa lista lista... LES/PUC-Rio Slide 9 de 27

10 Desenvolvimento por Iteração Planejamento Inicial Modelagem de Negócios Planejamento Avaliação Requisitos Config. e Mudanças Ambiente Análise e Projeto Implementação Distribuição Cada iteração resulta em uma versão executável Teste 24/7/2008 LES/PUC-Rio Slide 10 de 27

11 Ciclo de Vida dos Testes Iteração n Iteração n + 1 Ciclo de Vida de Desenvolvimento Planejamento do Projeto Captura de Requisitos Análise e Projeto Construção Implementação Construção Ciclo de Vida de Testes Planejamento dos testes Projeto dos testes Implementação dos Testes Rastreamento de Defeitos Execução dos Testes Avaliação dos Testes Iteração n + 2 LES/PUC-Rio Slide 11 de 27

12 Planejamento dos Testes No planejamento do projeto: Levar em consideração o esforço de teste Qual a cobertura? Estabelecer critérios de aceitação Recursos necessários Quais tipos de testes serão realizados e quando? Ver real necessidade do projeto Qual a tecnologia utilizada no projeto Gerar plano de teste LES/PUC-Rio Slide 12 de 27

13 Boa Prática É importante fazer um bom levantamento de Requisitos Identificar os cenários O que é obrigatório Fazer protótipo de tela Tirar ambigüidades Bons casos de uso facilitam o trabalho dos testes Caso contrário, o trabalho que deveria ser realizado no levantamento de requisitos vai ser realizado no levantamento dos casos de testes. LES/PUC-Rio Slide 13 de 27

14 Projeto dos Testes Criar casos de testes Levantar dados necessários para a realização dos testes Iniciar instalação do ambiente Testes de unidade Testes de regressão... Qualidade dos casos de testes dependente da qualidade dos casos de uso levantados durante a captura dos requisitos A Iteração corrente deve levar em consideração os problemas encontrados nas iterações anteriores LES/PUC-Rio Slide 14 de 27

15 Implementação e Execução Implementação dos testes de unidade pelos desenvolvedores Testes de integração Integração contínua Testes de regressão Testes de Desempenho Testes de Vulnerabilidade... LES/PUC-Rio Slide 15 de 27

16 Rastreamento de Defeitos Teste Problema Completo Falha Relatório de Defeitos Líder de Projeto Desenvolvimento Relatórios Gerênciais Reproduzir o Problema Novo DefeIto Corrigir Problema Defeitos Abertos x Corrigidos Corrigido LES/PUC-Rio Slide 16 de 27

17 Problemas Comuns na Disciplina de Testes Não levar em consideração o esforço de teste no planejamento Usar testes como trabalho probatório para novos programadores Selecionar testadores a partir de programadores deficientes Selecionar analistas de testes sem conhecimento do domínio Associar que testadores sempre são programadores Não ter um ambiente isolado para a realização dos testes Desenvolvimento, certificação, homologação Não ter uma massa de dados trabalhada para o cenário de teste Testar tudo LES/PUC-Rio Slide 17 de 27

18 Problemas Comuns na Disciplina de Testes Reduzir apenas a testes funcionais Colocar testes de stress, segurança e carga por último (ou tarde demais) Não testar a especificação Não testar procedimentos de instalação Não priorizar áreas de risco Seguir cegamente um plano de testes LES/PUC-Rio Slide 18 de 27

19 Expectativa errada quanto aos testes Pensar que a equipe de testes é responsável por assegurar a qualidade Começar tarde demais LES/PUC-Rio Slide 19 de 27

20 Boas Práticas Os testes devem ser repetíveis e mensuráveis Deve-se prevenir a propagação de defeitos entre as fases do desenvolvimento Testes de sistemas ou funcionais devem ser executados por uma equipe preparada e independente da equipe de desenvolvimento. Devem existir ambientes isolados para a realização dos diversos tipos de teste Implementar testes automatizados Focar os testes na parte crítica do sistema (Pareto) LES/PUC-Rio Slide 20 de 27

21 Boas Práticas Identificação clara dos cenários de testes Caso de Uso Serviço Caso de Teste Implementado Cenário Contexto Inicial Conjunto de dados necessários para a realização dos testes. Os dados podem ser carregados diretamente para a base de dados do desenvolvedor ou utilizar os objetos para a chamada de métodos do serviço. Contexto Resultado Conjunto de dados que representam o resultado esperado após a execução dos testes. LES/PUC-Rio Slide 21 de 27

22 Reforço de Pontos-Chave Para cada projeto, avaliar o custo/benefício do esforço de teste a ser realizado Atividades de teste devem estar presentes em todo ciclo do projeto A qualidade do processo de teste determina o sucesso do esforço de teste É importante ter bem definido padrões e procedimentos Ter bem definido o que deve ser testado em cada fase do ciclo de vida do projeto É importante ter uma equipe capacitada As atividades de testes devem estar previstas no planejamento do projeto O resultado é a entrega de um produto de maior confiabilidade e qualidade LES/PUC-Rio Slide 22 de 27

23 Principais Tipos de Testes Apoio:

24 Principais tipos de Testes Unitário Aceitação Desempenho Vulnerabilidade LES/PUC-Rio Slide 24 de 27

25 Teste Unitário Teste independente de uma unidade Foco: exame minucioso do código e da interface disponibilizada pela unidade Exemplos de unidades classes widgets páginas Web módulos componentes applets servlets programas no caso de programas compostos LES/PUC-Rio Slide 25 de 27

26 Teste Unitário public class Soma { int add(int a, int b) { return a + b; } } public class TestSoma { } public void testsum() { Soma adder = new Soma(); asserttrue(adder.add(1,1) == 2); asserttrue(adder.add(1,2) == 3); asserttrue(adder.add(2,2) == 4); asserttrue(adder.add(0,0) == 0); asserttrue(adder.add(-1,-2) == -3); asserttrue(adder.add(-1,1) == 0); asserttrue(adder.add(1234,988) == 2222); } LES/PUC-Rio Slide 26 de 27

27 Ferramentas Java JUnit TestNG.NET NUnit Php PhpUnit LES/PUC-Rio Slide 27 de 27

28 Boas Práticas Testes de Unidade Ambiente de Teste Desenvolvedor 01 Base de Desenvolvimento Base com Massa de Dados Repositório de Código Cenários Desenvolvedor 02 Base de Desenvolvimento LES/PUC-Rio Slide 28 de 27

29 Limitações Teste muito focado, não encontra problemas na integração dos componentes; É preciso ter um processo de registro e acompanhamento de problemas LES/PUC-Rio Slide 29 de 27

30 Teste de Aceitação Definição Controversa Aqui usaremos com o seguinte propósito: Teste caixa preta que simula a interação do usuário com o sistema; Geralmente baseado em cenários de testes extraídos dos casos de uso; LES/PUC-Rio Slide 30 de 27

31 Teste de Aceitação LES/PUC-Rio Slide 31 de 27

32 Ferramentas WEB Selenium IBM Rational Functional Tester Rational Test Manager Borland SilkCentral Test Manager HP Quality Center LES/PUC-Rio Slide 32 de 27

33 Exemplo Gravar Script Gravação usando IBM Rational Functional Tester Executar Script Execução Automatizada do Script LES/PUC-Rio Slide 33 de 27

34 Teste de Desempenho Tipo de teste utilizado para Verificação da conformidade com os requisitos não-funcionais Identificação de gargalos na arquitetura Verificação da adequação do ambiente Avaliação da escalabilidade do software Número de usuários Grande massa de dados Comparações Evoluções do mesmo software Software concorrentes LES/PUC-Rio Slide 34 de 27

35 Variações Teste Carga Teste de Stress Teste de Configuração LES/PUC-Rio Slide 35 de 27

36 Teste de Carga Variação na carga Número de usuários Número de transações Tamanho da base de dados LES/PUC-Rio Slide 36 de 27

37 Teste de Stress Situações extremas Memória limitada Espaço em disco insuficiente Falhas em servidores Número extremamente alto de usuários LES/PUC-Rio Slide 37 de 27

38 Teste de Configuração Variação na configuração do ambiente Determina a configuração mínima e ótima de Hardware e Software Efeito de adicionar ou modificar recursos computacionais Memória Disco CPU Rede Testa padrões de compatibilidade LES/PUC-Rio Slide 38 de 27

39 Riscos verificados com testes de desempenho Capacidade O sistema atende ao volume demandado em operação? Componente O componente atende aos requisitos de desempenho? O componente está contribuindo para o não cumprimento de um requisito de desempenho? Longevidade O desempenho será consistente e aceitável em 01 ano? Comparação Como o desempenho vem evoluindo no tempo? LES/PUC-Rio Slide 39 de 27

40 Riscos verificados com testes de desempenho Carga Quantos usuários a aplicação suporta adequadamente? Até quando a base de dados pode crescer? Quando a infra-estrutura de rede irá sobrecarregar? Validação Alguma SLA será violada com esta nova release do software? LES/PUC-Rio Slide 40 de 27

41 Natureza de Preocupação dos Riscos Velocidade Escalabilidade Estabilidade LES/PUC-Rio Slide 41 de 27

42 Principais Atividades de Testes Identificar Ambiente de Teste Identificar Critérios de Aceitação Contexto do Projeto Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar LES/PUC-Rio Slide 42 de 27

43 Exemplo de Teste de Desempenho: Descrição do Sistema Sistema Web Enciclopédia Colaborativa Visão: ser referência mundial no domínio de desenvolvimento de software LES/PUC-Rio Slide 43 de 27

44 Requisitos não-funcionais de desempenho RNF Tempo médio de resposta: 2 segundos RNF Tempo máximo de resposta (pico): 10 segundos RNF Vazão (throughput): Acima de 50 requisições por segundo por máquina RNF Atender a 450 mil visitantes únicos por dia LES/PUC-Rio Slide 44 de 27

45 Identificar Ambiente de Teste Identificar Ambiente de Teste Ambiente de Produção Host 01 Hardware Core 2 duo 1.8ghz 4Mb L2 Cache 4GB RAM HD 320GB Software Linux Fedora 5.0 Servidor JBoss v Utilização atual Média de utilização do processador 23,4% Média de utilização da memória RAM 60% Host 02 Hardware Core 2 duo 1.8ghz 4Mb L2 Cache 4GB RAM HD 320GB Software Microsoft Windows Server Servidor Oracle v 12.0 Utilização atual Média de utilização do processador 60% Média de utilização da memória RAM 72% Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar LES/PUC-Rio Slide 45 de 27

46 Identificar Ambiente de Teste Ambiente de Teste Host Cliente JMeter Processador: Intel Pentium D 3.0 GHz Memória RAM: 1GB Sistema Operacional: Windows XP Professional Host Servidor JBoss Processador: Intel(R) Core(TM)2 CPU 1.86GHz Memória RAM: 2GB Sistema Operacional: Linux Fedora 5.0 Host Servidor Oracle Processador: Intel(R) Core(TM)2 CPU 1.86GHz Memória RAM: 2GB Sistema Operacional: Windows XP Professional Identificar Ambiente de Teste Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar LES/PUC-Rio Slide 46 de 27

47 Identificar Ambiente de Teste Identificar Ambiente de Teste O Ambiente de Produção possui maior poder computacional do que o ambiente de testes Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar A ferramenta JMeter não monitora os recursos consumidos nos servidores É preciso uma ferramenta adicional Exemplo: Linux Sars LES/PUC-Rio Slide 47 de 27

48 Identificar critérios de aceitação Identificar Ambiente de Teste Neste caso, os critérios já foram especificados Tempo médio de resposta: 2 segundos Tempo máximo de resposta (pico): 10 segundos Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar Vazão (throughput): Acima de 50 requisições por segundo por máquina Atender a 450 mil visitantes únicos por dia Porém Qual é o pico de usuários simultâneos? Qual o tamanho da base da dados? Quais os cenários típicos? LES/PUC-Rio Slide 48 de 27

49 Planejar e Projetar os Testes Identificar Ambiente de Teste Cenários Cenário típico CDU 04: Acessar Fórum CDU 03: Acessar Página da Comunidade CDU 01: Efetuar Login CDU 12: Postar Mensagem Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar Criar 150 usuários simultâneos Sendo 01 a cada 3 segundos Executar o teste durante 02 horas LES/PUC-Rio Slide 49 de 27

50 Planejar e Projetar os Testes Identificar Ambiente de Teste Coletar Vazão média Desvio padrão da vazão Tempo de resposta médio Tempo de resposta máximo Desvio padrão do tempo de resposta Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar Dados de utilização dos recursos nos servidores Percentual de Memória utilizada Percentual de CPU utilizada LES/PUC-Rio Slide 50 de 27

51 Configurar Ambiente de Testes Identificar Ambiente de Teste Configurar o JMeter Execução dos testes Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Configurar o Linux Sar Monitoramento do servidor linux Analisar Configurar Log de Eventos do Windows Monitoramento do servidor Windows LES/PUC-Rio Slide 51 de 27

52 Implementar Identificar Ambiente de Teste Criação do Script Jmeter Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes <jmetertestplan version="1.2" properties="1.8"> <hashtree> <TestPlan guiclass="testplangui" testclass="testplan" testname="futpedia Test Plan" enabled="true"> <boolprop name="testplan.functional_mode">false</boolprop> <stringprop name="testplan.comments"></stringprop> <stringprop name="testplan.user_define_classpath"></stringprop> <boolprop name="testplan.serialize_threadgroups">false</boolprop> <elementprop name="testplan.user_defined_variables" elementtype="arguments" guiclass="argumentspanel" testclass="arguments" testname="user Defined Variables" enabled="true"> <collectionprop name="arguments.arguments"/> </elementprop> </TestPlan> <hashtree> <ThreadGroup guiclass="threadgroupgui" testclass="threadgroup" testname="futpedia Cenário Navegaçao Comum" enabled="true"> <boolprop name="threadgroup.scheduler">true</boolprop> <stringprop name="threadgroup.num_threads">150</stringprop> <stringprop name="threadgroup.duration">7200</stringprop> <stringprop name="threadgroup.delay"></stringprop> <longprop name="threadgroup.start_time"> </longprop> <stringprop name="threadgroup.on_sample_error">continue</stringprop> <stringprop name="threadgroup.ramp_time">450</stringprop> Implementar Executar Analisar Executar Relógios sincronizados Máquinas reiniciadas Aplicações que podem influenciar paradas LES/PUC-Rio Slide 52 de 27

53 Analisar Identificar Ambiente de Teste Vazão Requisito: 50/s ou 3.000/min Alcançado: 786/s ou /min Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar Throughput/Min melhor Throughput/Min meta LES/PUC-Rio Slide 53 de 27

54 Analisar Identificar Ambiente de Teste Tempo de resposta máximo Requisito: 10 segundos Alcançado: 2,37 segundos Tempo de resposta médio Requisito: 2 segundos Alcançado: 0,2 segundos Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar Analisar Tempo de Resposta (milis) médio Tempo de Resposta (milis) médio LES/PUC-Rio Slide 54 de 27

55 Analisar Identificar Ambiente de Teste Utilização de recursos no host servidor de aplicações % Memória Utilizada Identificar Critérios de Aceitação Planejar e Projetar os Testes Configurar Ambiente de Testes Implementar Executar 70 Analisar % Memória Utilizada % cpu used % cpu used LES/PUC-Rio Slide 55 de 27

56 Ponteiros para Ferramentas JMeter Grátis e Simples Não monitora o uso de recursos nos servidores A ferramenta de análise gráfica não funciona com arquivos de Logs grandes IBM Rational Performance Tester Integrada ao Eclipse Coleta dados do uso dos recursos ou se integra com: Tivolli Windows Performance Monitor UNIX rstatd monitor. Permite fazer drilldown Borland SilkPerformer Drilldown Coleta dados do uso dos recursos SoapUI WebServices LES/PUC-Rio Slide 56 de 27

57 Teste de Segurança/Vulnerabilidade A grande maioria dos sites possuem vulnerabilidades 90% dos sites estão vulneráveis a ataques na camada de aplicação (Watchfire) 78% das vulnerabilidades são facilmente exploradas em aplicações web (Symantec) 80% das organizações irão vivenciar um incidente de segurança de aplicação até 2010 (Gartner) Aplicações WEB são alvos valiosíssimos para hackers Informações pessoais, cartões de crédito, roubo de identidade, fraudes diversas, pichações online No Brasil, 13% das empresas que sofrem perdas financeiras com ataques virtuais têm um prejuízo médio que ultrapassa a barreira do R$ 1 milhão Revista Dinheiro, 2000 (dados de uma pesquisa da Módulo Security) LES/PUC-Rio Slide 57 de 27

58 Custos de falhas na segurança Atenção da mídia / danos à marca Custos de monitoramento/comunicação Custos legais Auditorias Processos dos clientes Perdas dos clientes... LES/PUC-Rio Slide 58 de 27

59 A realidade Segurança Gastos 75% dos ataques são na camada de aplicação WEB 2/3 de todas as aplicações web estão vulneráveis LES/PUC-Rio Slide 59 de 27

60 OWASP Top Ten LES/PUC-Rio Slide 60 de 27

61 Solução Inserir preocupações de segurança no ciclo de desenvolvimento Mudança no Processo de Desenvolvimento Utilizar ferramentas para automatizar parte do processo Testes de Segurança (testes funcionais, desempenho... ) Treinamento contínuo Priorização de vulnerabilidades Técnicas de codificação segura Inserir Testes de Segurança LES/PUC-Rio Slide 61 de 27

62 Ferramentas Caixa Preta Camada WEB Microsiga SAP Legado Aplicação de Negócio Caixa Branca Bases Coorporativas LES/PUC-Rio Slide 62 de 27

63 Ferramentas Caixa Preta IBM Rational Appscan Caixa Branca Fortify Source Code Analysis Suite LES/PUC-Rio Slide 63 de 27

64 Processos de Teste Apoio:

65 Rational Unified Process: Processo de Teste LES/PUC-Rio Slide 65 de 27

66 Rational Unified Process: Processo de Teste LES/PUC-Rio Slide 66 de 27

67 Definir Missão de Avaliação Objetivos Principais Identificar o foco dos testes para a iteração; Estabelecer consenso com os envolvidos sobre as metas correspondentes; Fazer/atualizar o Plano de Testes Exemplo A unidade e o sistema do Sistema de Mensagens do Collegiate Sports serão testados. A interação dos subsistemas será testada da seguinte maneira: Gerenciamento de Conteúdo em Mensagens Gerenciamento de Conteúdo em Relatórios As seguintes interfaces de sistema serão testadas: Sistema de Mensagens do Collegiate Sports no Servidor Web WebNewsOnLine existente Sistema de Mensagens do Collegiate Sports nos gateways de mensagens Os testes mais críticos serão os de carga e desempenho. Eles serão executados da seguinte maneira: Criaremos um cenário de teste que gerará números de páginas cada vez maiores, até Criaremos também um cenário de teste que receberá conteúdo novo no sistema na velocidade de um item a cada 20 segundos. Por fim, simularemos cargas de assinantes simultâneos cada vez maiores, até LES/PUC-Rio Slide 67 de 27

68 Verificar abordagem de Teste Objetivos Principais Verificar o quanto antes que a Abordagem de Teste pretendida funcionará e produzirá resultados valiosos Estabelecer a infra-estrutura básica para possibilitar e dar suporte à Abordagem do Teste Obter comprometimento da equipe de desenvolvimento para fornecer e dar suporte à testabilidade exigida para atingir a Abordagem de Teste Identificar escopo, fronteiras, limitações e restrições de cada técnica LES/PUC-Rio Slide 68 de 27

69 Validar Estabilidade do Build Objetivos Principais Tomar uma decisão para aceitar o Build como adequado para uso nos testes seguintes ou realizar mais testes em um Build anterior Geralmente feito através de testes de regressão LES/PUC-Rio Slide 69 de 27

70 Testar e Avaliar Objetivos Principais Testar e Avaliar Registrar as informações necessárias para diagnosticar e resolver os problemas identificados Fornecer feedback nas áreas de risco potencial LES/PUC-Rio Slide 70 de 27

71 extreme Programming (XP) Você terá dúvidas se o seu código faz efetivamente o que você gostaria que ele fizesse Testes Unitários Você terá dúvidas se o que você acha sobre como sistema deve funcionar é realmente como o usuário espera que ele funcione Testes de Aceitação Também conhecido como Teste Funcional, Teste Caixa-Preta, Teste de Aplicação... LES/PUC-Rio Slide 71 de 27

72 De Forma Geral Planejar Testes Plano de Teste Projetar Executar Testes Casos de Teste Registrar problemas e resultados LES/PUC-Rio Slide 72 de 27

73 Artefatos Apoio:

74 Principais Artefatos Plano de Teste Caso de teste Matriz de rastreabilidade Registro de Problema LES/PUC-Rio Slide 74 de 27

75 Plano de Teste Missão de Avaliação e Motivação dos Testes Itens-alvo dos Testes Resumo dos Testes Planejados Abordagem dos Testes Técnicas e Tipos de Teste Teste de Integridade de Dados e de Banco de Dados Teste de Função Teste de Ciclos de Negócios Teste da Interface do Usuário Determinação do Perfil de Desempenho Teste de Carga Teste de Stress Teste de Volume Teste de Segurança e de Controle de Acesso Teste de Tolerância a Falhas e de Recuperação Teste de Configuração Teste de Instalação Produtos Liberados Sumários de Avaliação de Testes Relatórios da Cobertura de Teste Relatórios da Qualidade Perceptível Registros de Incidentes e Solicitações de Mudança Conjunto de Testes de Regressão e Scripts de Teste de Suporte Resultados Detalhados dos Testes Matrizes de Rastreabilidade Necessidades Ambientais Hardware Básico do Sistema Elementos de Software Básicos do Ambiente de Teste Ferramentas de Produtividade e de Suporte Configurações do Ambiente de Teste Riscos, Dependências, Suposições e Restrições Importante! LES/PUC-Rio Slide 75 de 27

76 Caso de Teste Estrutura geral: ID - Identificação única do caso de teste Descrição - Breve e objetiva. Pré-requisitos - necessários antes da execução do teste. Entradas - Dados de teste a serem passados ao sistema Passos - Instruções de como realizar o teste Resultados esperados - como o sistema deve reagir de acordo com os passos do teste Resultados obtidos como o sistema de fato reagiu. Sucesso/Fracasso - resultado da comparação entre o resultado esperado e o obtido (em fila, bloqueado, em andamento, em alerta, fechado, não realizado,...) LES/PUC-Rio Slide 76 de 27

77 Matriz de Rastreabilidade Rastreabilidade e análise de impacto Os casos de uso e demais requisitos podem ter um ou mais casos de testes associados Pode haver relacionamentos de n:n Mudanças nos requisitos geram mudanças nos casos de teste LES/PUC-Rio Slide 77 de 27

78 Boa Prática Definir um processo onde esta rastreabilidade seja realizada de forma direta Requisito 1 Requisito 7 CDU CDT Script de Teste Automatizado LES/PUC-Rio Slide 78 de 27

79 Registro de problema Artefato (construto) nome versão data quem como: caso de teste uso outros, ex. desenvolvimento de outro artefato Tipo do problema reportado código consulta documentação especificação (design) sugestão LES/PUC-Rio Slide 79 de 27

80 Registro de problema Severidade Possíveis danos provocados pelo problema É possível continuar a usar? sim, se evitar a região problemática sim, usando outra seqüência de trabalho sim, se desprezar alguns resultados sim, pois somente incomoda É reprodutível? Identificação do problema Descrição do problema e como produzi-lo Sugestão de solução LES/PUC-Rio Slide 80 de 27

81 Registro de problema Solução descrição da solução artefatos criados, alterados, eliminados versões resultantes possíveis causas das faltas identificadas FAP - Ficha de acompanhamento de problemas registra o problema e a evolução da solução até ter sido completamente resolvido LES/PUC-Rio Slide 81 de 27

82 Estados de uma FAP Início aprovada Em solução emergencial não aprovada Aguardando análise protelada falha grave Aguardando solução emergencial dados insuficientes Aguardando informação Em análise autorizada Aguardando solução suspensa Sendo resolvida Aguardando informação dados insuficientes não aprovada concluída Aguradando aprovação cancelada já resolvida recusada Fim aprovada Sendo controlada LES/PUC-Rio Slide 82 de 27

83 Estratégias para Construir Casos de Teste Apoio:

84 Derivação a partir da especificação Caos de Uso Casos de Testes Testes Funcionais x Código LES/PUC-Rio Slide 84 de 27

85 Derivação a partir da especificação Passo a passo geral: 1. Entenda o documento de requisitos que você possui 2. Sub-divida cada requisito em requisitos atômicos que melhorem a testabilidade 3. Para cada requisito: 3.1 Decida qual ou quais técnicas de teste são mais adequadas 3.2 Escreva os casos de teste 4. Mantenha uma matriz de rastreabilidade entre os requisitos e os casos de teste LES/PUC-Rio Slide 85 de 27

86 Como derivar os casos de teste para o código fonte? Nem sempre um programa pequeno significa baixa complexidade Critérios Caixa fechada: dependem exclusivamente da especificação Exemplo: testes de aceitação Caixa aberta: dependem da estrutura do código executável Exemplos nos próximos slides LES/PUC-Rio Slide 86 de 27

87 Cobertura de instruções A: x && y Cada comando deve ser executado pelo menos uma vez B: P1 Escolher x e y : x && y => true x e z : x z => true C: x z D: P2 LES/PUC-Rio Slide 87 de 27

88 Cobertura de arestas A: x && y Cada aresta deve ser percorrida pelo menos uma vez Escolher B: P1 x e y : x && y => false x e y : x && y => true C: x z D: P2 x e z : x z => false antes de executar P2 pela primeira vez (0 ciclos) x e z : x z => true, e false imediatamente após a primeira execução de P2 (1 ciclo) x e z : x z => true, e false após n > 1 execuções de P2 (n ciclos) LES/PUC-Rio Slide 88 de 27

89 Cobertura de expressões Cobertura de arestas mais: A: x && y B: P1 cada expressão é testada de tantas maneiras quantas forem os elementos das tabelas de verdade x T T F F y T F T F C: x z x && y T F F F x T T F F D: P2 z T F T F x z T T T F LES/PUC-Rio Slide 89 de 27

90 Derivação a partir da especificação (caixa fechada) Passo a passo aplicado: Caso de uso (1) (2) (3) (3.1) (3.2) (4) Obtenha a especificação detalhada do caso de uso Determine um conjunto de cenários possíveis Para cada cenário... Utilize particionamentos e limites Crie casos de testes combinando os particionamentos e limites aos cenários associados Relacione: caso de uso cenários cenário casos de teste LES/PUC-Rio Slide 90 de 27

91 Derivação a partir da especificação Passo a passo aplicado: Requisito não funcional (1) (2) (3) (3.1) (3.2) (4) Obtenha métricas, respectivos valores possíveis e valores desejados. Analise possíveis requisitos conflitantes. Determine um níveis de serviço a serem atendidos Para cada nível... Selecione técnicas adequadas de medição Crie casos de testes para as possíveis medições Relacione: requisito não funcional níveis de serviço nível de serviço medições medição casos de teste LES/PUC-Rio Slide 91 de 27

92 Derivação de Casos de Teste a Partir de Casos de Uso Apoio:

93 Derivação a partir da especificação Passo a passo aplicado: Caso de uso (1) (2) (3) (3.1) (3.2) (4) Obtenha a especificação detalhada do caso de uso Determine um conjunto de cenários possíveis Para cada cenário... Utilize particionamentos e limites Crie casos de testes combinando os particionamentos e limites aos cenários associados Relacione: caso de uso cenários cenário casos de teste LES/PUC-Rio Slide 93 de 27

94 Casos de Uso Estrutura de um Caso de Uso: Pré-Condições Fluxo Principal Fluxos Alternativos Fluxos de Exceção Pós Condições Relacionamentos Includes Extends LES/PUC-Rio Slide 94 de 27

95 Diagrama de Casos de Uso Sacar Depositar $1,000 Empregado do banco Depositar Depositar acima de $10,000 Depositar com número de conta inválido Chefe de caixa Caixa Extornar débito Proprietário da conta From Selecting Test Cases Based on User Priorities by by John D. McGregor and Melissa L. Major in March, 2000 Software Developers Magazine LES/PUC-Rio Slide 95 de 27