Verificação, Validação e Teste de Software

Transcrição

1 Instituto de Teologia Aplicada - INTA Apresentação Gradução: Bacharelado em Ciências da Computação UVA Verificação, Validação e Software Pós-Graduação: Especialização em Engenharia de Software INTA Mestrado Acadêmico em Ciências da Computação UECE (em andamento) Atividades Profissionais Prof. Instituto Federal de Educação, Ciência e Tecnologia IFCE (atual) Prof. Universidade Estadual Vale doacaraú UVA, Campus Aracati (atual) Analista de Sistemas no Instituto Altântico Prof. Faculdade IEducare (FIED) Prof. Instituto de Pesquisa Vale do Acaraú (IVA) Prof. Raquel Silveira Títulos Certificações SCJP e CBTS 2 Introdução ao Processo de Teste Introdução ao Processo de Teste Processo de Software - Sequência de práticas que objetiva o desenvolvimento ou a evolução de sistemas de software. - Estas práticas englobam as atividades de especificação, projeto, implementação, TESTES e caracterizam-se pela interação de ferramentas, pessoas e métodos. Processo de Teste Teste é um processo de avaliar um sistema ou um componente de um sistema para verificar se ele satisfaz os requisitos especificados ou identificar diferenças entre resultados esperados e obtidos. 3 4 Introdução ao Processo de Teste Introdução ao Processo de Teste Testes realizados por desenvolvedores tendem a identificar menos problemas Testes deve um processo paralelo ao desenvolvimento Testar software não é uma tarefa simples Erros nem sempre são óbvios Erros diferentes podem ter a mesma manifestação Pré-conceitos O testador é um inimigo do desenvolvedor. A equipe de testes pode ser montada com os desenvolvedores menos qualificados, pois qualquer um pode testar sistemas. Quando estiver tudo pronto, o software seguirá para o pessoal fazer o teste. Saber que um programa não está correto não necessariamente é saber como corrigir o erro 5 6 1

2 Introdução ao Processo de Teste Objetivos Principais Objetivos dos Testes - Encontrar o maior número possível de defeitos no software. - Os documentos básicos para definir os objetivos dos testes são os requisitos do negócio. - A prática de gerar requisitos de testes a partir dos requisitos de negócio facilita de modo considerável traças objetivos capazes de cobrir todas as necessidades dos usuários. Objetivo 1. Identificar a magnitude e origem dos riscos associados ao desenvolvimento de software, minimizáveis por testes. Riscos são identificados em todo tipo de projeto. Testes podem mitigar riscos, não contigenciar! Mitigar: atuar para prevenir a ocorrência do fato Contigenciar: atuar após o fato para minimizar perdas. 7 8 Objetivos Principais Objetivos Principais Objetivo 2. Executar testes para reduzir riscos identificados. Testes positivos: Buscam cenários que funcionam como esperado. Testes negativos: Buscam cenários que quebram o software. Esforço planejado para testes Combinação de testes positivos e negativos. 100% de testes é irreal. Objetivo 3. Determinar quando os testes estão completos. Nem 8 nem 80! Poucos testes causam incerteza. Testes demasiados custam mais caros. Testes positivos são os prioritários Envolvem o teste dos requisitos do projeto. Testes negativos em sequência De acordo com a priorização Objetivos Principais Problemas Conhecidos Objetivo 4. Gerenciar testes assim como qualquer outra disciplina de Engenharia de Software. Planejar, acompanhar, formar equipe, gerenciar os recursos. Também para testes? Por quê? Testadores são escassos Assim como desenvolvedores. Alocação dos recursos de testes deve ser gerenciada com a mesma importância dos recursos de desenvolvimento. Problema do Ano 2000 (Y2K Bug) Anos:..., 19 98, 19 99, 19 00?? Testes começaram a ser levados a sério por conta da ameaça do Y2K. Como garantir que após as correções de datas, tudo ficaria funcionando corretamente? Vocês sabem do bug do ano 2038? O último registro de tempo que pode ser representado, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de

3 Break! Break! Qual a proporção de testes nos projetos? Fred Brooks Trabalhou na IBM, no desenvolvimento do OS/360 Scott Berkun Trabalhou na Microsoft, no desenvolvimento de Windows, MSN e Internet Explorer. Qual a proporção que eles sugerem? Qual a proporção de testes nos projetos? Fred Brooks (IBM / 1975) 1/3 de planejamento 1/6 de codificação 1/4 de testes Scott Berkun (MS / 2005) 1/3 de projeto e gerenciamento 1/3 de implementação 1/3 de testes Princípios Princípios Lista elaborada por Everett & McLeod Jr. 1. Riscos de negócio podem ser reduzidos com testes. 2. Testes positivos e negativos contribuem com a redução de riscos. 3. Testes estáticos contribuem com testes. 4. Ferramentas de testes automatizados podem contribuir com redução de riscos. 5. Faça com que os mais altos riscos sejam a primeira prioridade de testes. 6. Faça com que os cenários de negócio mais freqüentes sejam a segunda prioridade de testes. 7. Análise estatística de padrões e características de defeitos pode ajudar na estimativa do esforço de teste. 8. Realize os testes do sistema da mesma forma como o usuários irão usá-lo. 9. Assuma que defeitos são resultado de um processo, e não da personalidade dos envolvidos. 10. Realizar teste para identificar defeitos é um investimento assim com um custo Aspectos Econômicos Aspectos Econômicos Testar é caro Comparado com o quê? Qual é o custo de NÃO testar? Incerteza sobre cobertura (fiz tudo?) Incerteza sobre qualidade (o que fiz está correto?) Qual é o custo de encontrar falhas posteriormente? Desgaste do relacionamento com clientes. Má impressão dos usuários. Remontagem do time de projeto. Software falho custa mais para usar Usuários terão dificuldade de entendimento (comportamento inconsistente). Usuários cometerão mais erros. Software falho diminui motivação Moral é atingida. Produtividade piora. Melhor para o time é receber feedback prontamente e não de forma tardia!

4 Aspectos Econômicos Aspectos Econômicos Vamos fazer as contas Um erro foi encontrado por um usuário no ambiente de produção. Então, qual é o caminho a ser feito para corrigir o problema e disponibilizar uma nova versão do sistema? 1. Usuário entra em contato (fone, , carta, fax, tíquete aberto em sistema de solicitações, etc) e informa o erro. 2. Analista reproduz o erro no ambiente de produção, e informa equipe de desenvolvimento. 3. Desenvolvedor reproduz o erro e encontra a falha. 4. Desenvolvedor corrige a falha (em geral a parte mais rápida). 5. Equipe de desenvolvimento disponibiliza nova versão do sistema. 6. Versão do sistema em produção é trocada. 7. Usuário consegue utilizar a funcionalidade corretamente agora mas então detecta outro problema! 19 Qual é o custo de encontrar falhas posteriormente? O custo de correção dos defeitos encontrados durante a produção tende a aumentar quanto mais tarde o defeito é detectado Regra 10 de Myers Requisitos Designer Implementação Teste Produção 20 Valor de Negócio Maximizar valor de negócio Testes podem (e devem) ser organizados para maximizar valor. Testes diminuem custos de manutenção. Testes diminuem custos de atualização. Alinhamento com missão do projeto. 20% das funcionalidades agregam 80% do valor. Os softwares devem atender a certos atributos de qualidade e, para isso, precisamos identificar seus objetivos ou requisitos de qualidade. Uma metodologia de qualidade muito usada no mercado é o FURPS. Suportabilidade Supportability Funcionalidade Functionality FURPS Usabilidade Usability Desempenho Perfomance Confiabilidade Reliability Exercício Rápido Para cada projeto distribuir 10 fichas entre opções de testes: Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade. Projeto 1. POS para Operadora de Cartão de Crédito Projeto 2. Aplicação de Chat para Dispositivos Móveis Atributos de qualidade

5 Funcionalidade Usabilidade De acordo com a especificação funcional. - Teste funcional - regressão - volume Facilidade de uso do sistema pelos usuários. - interface; - usabilidade Confiabilidade Desempenho Confiabilidade do sistema, a permanência de operação, a integridade dos dados, a confiabilidade da estrutura e da aplicação. - estrutura - estresse Velocidade de processamento da informação. - avaliação de desempenho ou benchmark - contenção - Perfil de desempenho Suportabilidade Exercício Rápido Capacidade do programa de funcionar em diversos ambientes diferentes. - instalação - configuração Um software foi entregue ao cliente e o cliente solicita uma nova modificação. A equipe do desenvolvimento elabora uma nova release contendo a modificação solicitada, antes de entregar o software é necessária a realização de testes? Qual(is) o(s) tipo(s) de teste deve ser realizado nesta situação?

6 Garantia de Qualidade versus Controle de Qualidade Garantia de Qualidade: Um processo que assegura que o produto foi produzido conforme os processos organizacionais. Verificação = Validação? Controle de Qualidade: Um processo que assegura que o produto funcione conforme os requisitos Verificação Processo de avaliação de um sistema ou componente para determinar se os artefatos produzidos satisfazem às especificações determinadas. Estamos construindo o produto corretamente? Validação Processo de avaliação para determinar se o sistema atende as necessidades e requisitos dos usuários. Estamos construindo o produto certo? 33 Análise de Requisitos Sistema Verificação (Garantia de Qualidade) Arquitetura Módulos Construção Unidade Componente Teste Sistêmico Aceitação Validação (Controle de Qualidade) 34 Análise de Requisitos Revisão técnica Aceitação Análise de Requisitos Projeto do Teste de Aceitação Projeto Prematuro de Testes Sistema Teste Sistêmico Sistema Projeto do Teste Sistêmico Verificação (Garantia de Qualidade) Arquitetura Módulos Unidade Componente Validação (Controle de Qualidade) Arquitetura Módulos Projeto do Teste de Integração Projeto do Teste de Unidade Construção Construção

7 Análise de Requisitos Sistema Arquitetura Módulos Projeto do Teste de Aceitação Projeto do Teste Sistêmico Projeto do Teste de Integração Projeto do Teste de Unidade Componente Unidade Aceitação Teste Sistêmico Construção Introdução ao Processo de Teste Introdução ao Processo de Teste Modelo de integração entre os processos de desenvolvimento e teste TESTE DESENVOLVIMENTO Revisões de código: Podem reduzir 20% a 30% dos defeitos. Especificação (1) (2) Entrega Verificação Teste unitário integração e sistema aceitação Desenho lógico e físico Construção Implantação Entrega Testes unitários: Podem reduzir 30% a 50% dos defeitos dos programas. Testes de sistemas: Podem reduzir 30% a 50% dos defeitos remanescentes Ciclo de Vida do Processo de Teste Projeto prematuro dos testes Ao projetar testes, problemas são encontrados. Problemas encontrados cedo são mais baratos de corrigir. Problemas mais significativos são encontrados primeiro. Então que tal verificar logo? testes pode impactar os requisitos

8 Ciclo de Vida do Processo de Teste Planejamento Antes de planejar Defina a estratégia de teste da organização (ou do negócio). Identifique as pessoas a serem envolvidas. Examine os requisitos e/ou especificações funcionais (artefatos de entrada para os testes). Estabeleça a organização e a infra-estrutura do ambiente de testes. Defina quais serão os entregáveis e a estrutura dos relatórios Planejamento Planejamento Por que o Plano de Teste é importante? - O Plano de Teste é uma maneira de documentar o projeto de testes. - Guia para orientar nos seguintes aspectos: - Repetição - Controle - Cobertura Plano de Testes 1. Introdução - Itens de software e funcionalidades a serem testadas. - Referências a plano de projeto, plano de QA, políticas e padrões organizacionais, plano de configuração. 2. Itens de teste - Listagem de itens de teste (versões ou revisões de sistemas, fases de desenvolvimento). - Como o sistema chega aos testadores (DVD, Internet, Intranet, Repositório do projeto) - Referências a documentação ou outros tipos de materiais de apoio Planejamento Planejamento Plano de Testes 3. Escopo - Identificar especificações funcionais 4. Não escopo - Razões para exclusão 5. Abordagem - Técnicas e ferramentas - Identificar o grau de cobertura e outros critérios. - Identificar restrições de ambiente, recursos humanos, prazos. 47 Plano de Testes 6. Critérios de execução - Definição de sucesso. - Definição de falha. 7. Critérios de interrupção e continuação - Interrupção: Caso a condição seja satisfeita, os testes (ou parte deles) devem ser interrompidos. - Continuação: sanada a condição de interrupção, quais atividades precisam ser re-feitas antes de retomar as atividades interrompidas. 48 8

9 Planejamento Planejamento Plano de Testes 8. Entregáveis - Plano de Testes. - Especificações de testes. - Relatórios. 9. Ambiente de teste - Espaço físico, equipamentos (hardware). - Ferramentas de software. Plano de Testes 10. Papéis e responsabilidades - Gestão - Projeto - Especificação - - Registro - Validação - Resolução de problemas - Fornecimento de produtos para os testes Planejamento Elaboração Dimensões do teste Tipo de teste (O que testar) 2ª funcionalidade interface desempenho usabilidade volume... Exercício rápido Como você testaria uma calculadora? Funcional Técnica de Teste (Como testar) 3ª Estrutural 1ª Estágio ou níveis de teste (Quando testar) unidade integração sistema aceitação Elaboração Elaboração -Um dos documentos contidos na fase de Elaboração é a Especificação de Caso de Teste. Este documento deve conter: Identificação das condições do teste (pré e pós condições) Identificação dos casos de teste (o que testar) Detalhamento da massa de entrada Especificação das configurações de ambiente Definir o tipo de implementação (automática ou manual) 53 Exemplo de elaboração de caso de teste Especificação do sistema: Autenticação de Usuário. Autenticação Login Senha OK Esqueceu a senha? LIMPAR Efetuar o login na aplicação com um login válido e senha de, no mínimo 6 (seis) caracteres. 54 9

10 Elaboração Elaboração Exemplo de elaboração de caso de teste Do requisito do cliente, podemos criar as seguintes idéias de teste: Exemplo de elaboração de caso de teste Título: Senha Inválida Ambiente: Windows XP Pré-Condições: - Possuir um usuário válido. Passo 1. O usuário inicia a aplicação. 2. O usuário preenche os campos Login e Senha conforme as idéias de teste. Resultado Esperado Verificar se os campos são preenchidos corretamente. 3. O usuário seleciona Efetuar Login. Verificar se quando o usuário informa uma senha menor que 6 caracteres, o sistema exibe a mensagem: Senha inválida.. 4. O usuário confirma a mensagem Elaboração Exercício rápido Em uma operação de Saque, quais casos de testes poderiam ser identificados? Como seria o detalhamento de um desses casos de teste? Revisão Técnica Objetivo Prevenir defeitos no produto final. Porquê? Removem defeitos do produto em todo o ciclo de vida. Como? Encontrando defeitos em produtos intermediários Revisão Técnica Requisitos - Requisitos funcionais e não funcionais. - Casos de uso. Análise e Projeto Código - Análise Automatizada - Técnicas 59 Revisão Técnica Requisitos Workshop de Requisitos - Apresentação do escopo e não-escopo do projeto para interessados - Trabalho preliminar de modelagem das necessidades - Requisitos - Caso de uso - Não Escopo - Restrições - Premissas - Técnica barata, e pode ser realizada em vários ciclos - Gera comprometimento dos participantes da reunião 60 10

11 Revisão Técnica Arquitetura Arquitetura é importante Então deve ser analisada Arquitetura é caro de se mudar É mais barato analisar cedo Arquitetura afeta o projeto inteiro Pessoas interessadas precisam ser envolvidas. Requisitos podem ser elicitados cedo Arquitetura precisa ser desenhada alinhada com estes. 61 Revisão Técnica Código Análise estática de código FindBugs, FxCop Grande base de anti-padrões Personalizáveis: crie suas próprias regras para padrões próprios. Inspeção manual Inspeção Revisão por Par 62 Revisão Técnica Código Inspeção Revisão Técnica Código Revisão por Par - Dois envolvidos somente: - Autor e Revisor Processo simples: 1 Autor prepara artefato e envia para Revisor 2 Revisor realiza revisão invidualmente 3 Revisor registra problemas ( , ferramenta própria, post-it,...) 4 Autor corrige problemas 5 Revisor verifica correções 6 Pronto! E se... autor e revisor discordarem? - Bom, deve ter um líder ou gerente nesse projeto, ok? - Não tem mágica, escala o conflito (assim como qualquer outro) Revisão Técnica Código O que procurar? O código executa corretamente os fluxos básicos associados? O código executa corretamente os fluxos alternativos associados? Outros aspectos Cumpre padrões de arquitetura (e.g. MVC)? Trechos complexos estão comentados? (análise estática ajuda aqui) Testes unitários estão feitos? Documentação/legibilidade estão boas? Tratamento de erros foi realizado corretamente?... Categorias de teste caixa branca (White box) caixa preta (Black box)

12 Caixa Branca Testes de unidade de código; Testam parte da solução; São escritos e mantidos pelo programador e devem estar sempre atualizados. Caixa Branca Quando construímos um teste de unidade, o principal desafio é isolar a classe ou trecho de código que está sendo testado, para que nenhuma outra classe do sistema seja envolvida no teste e influencie no resultado esperado Cobertura dos testes Cobertura dos testes Dificilmente consegue-se 100% de cobertura de testes. Quanto maior cobertura dos testes na aplicação, maior a confiabilidade nas alterações e novos recursos. Aplicações cobertas por bons testes propiciam: -Facilidade de manutenção; - Menos problemas e relação de custos em manutenção Testes de caixa preta Baseado no executável do sistema/componente. Testes funcionais; Testes de aceitação; Análise estática e análise dinâmica Estática Compreende métodos usados para determinar ou estimar qualidade de software, que não envolvem a execução do produto. Dinâmica Compreende métodos que envolvem execução do produto, com dados reais e ambiente real ou simulado

13 Tipos de Testes Testes Unitários Testes de Integração Testes Sistêmicos Testes de Aceitação Testes Unitários Baixo nível Feito por programadores Mais foco nos detalhes Tratamento de erros Completude e corretude de interfaces Níveis Módulos Componentes Classes\arquivos Testes Unitários Teste Unitário Testes Unitários - Planejamento - Como a estratégia e projeto de teste se aplica a unidade a ser testada? - Identificar outros componentes de software que estarão interagindo com a unidade). Teste Unitário Testes Unitários - Especificação - Caso de teste: Objetivo, Estado inicial, Entrada, Resultado esperado. - Testes precisam ser repetíveis. Teste Unitário Testes Unitários - - Casos de testes são executados. - Manuais e/ou Automatizados. - Definição de cobertura % de cobertura é impraticável. Teste Unitário

14 Testes Unitários - Registro - Identificação das unidades testadas. - Resultados gerados, comparados com resultados esperados. - Falhas/erros são registrados e informados. - Verificar critérios de cobertura do projeto. Teste Unitário Testes Unitários - Verificação de completude - Avaliação dos resultados comparados com os critérios de completude. - Se não atingir... - re-análise se é preciso mais Teste Unitário Testes de Integração - Importante em sistemas modularizados - Os módulos funcionam corretamente juntos? - Foco - Comunicação entre casos de usos. - Comunicação entre classes. - Planejamento da integração está intimamente atrelado ao desenho da arquitetura e das fases do projeto. - Estratégia: - Big-bang ou Incremental 81 Testes de Integração - Big-Bang - Na teoria: - Se eu já testei as unidades isoladamente, porque eu não junto tudo de uma só vez? Vou ganhar tempo! - Onde está o erro aqui? - Assumiu que não existem defeitos... - Na prática - Fica difícil isolar defeitos (qual unidade falhou?) - Fica difícil re-testar após correções - No final, leva mais tempo. 82 Testes de Integração - Incremental - Componentes / Módulos são combinados aos poucos - Baseline 1: Componete A - Baseline 2: Componente A e C - Baseline 3: Componente A, B e C - Vantagens: - Mais fácil de isolar problemas. - Mais fácil de re-testar correções. Testes Sistêmicos - Funcionais - Testes projetados de acordo com a documentação de cenários de uso existente - Casos de uso - Executado por grupo independente! - Primeiro passo - Rascunhar um caso de teste para os cenário principal e alternativos - Segundo passo - Inserir detalhes como intervalos, regras de negócio, valores de validação - Na hora de executar - Seguir o roteiro que é definido nos casos de testes

15 Testes Sistêmicos - Tentem a próxima coisa! - Quando estiver testando, não pare, não retorne ao começo Faça o que o usuário fará em seguida! - Exemplo: - Tela de modificação de senha. Testes Sistêmicos Não Funcionais - Desempenho: - Grande massa de dados ou usuários - Picos de utilização ou acesso - Robustez: - Sistema não pára de funcionar ao longo do tempo - Ex.:Impressoras fiscais, sites de comércio eletrônico - Segurança: - Importante para sistemas com dados sensíveis - Não envolve só infra-estrutura Testes Sistêmicos Não Funcionais - Usabilidade: - Verifica se a interface é fácil de usar e intuitiva - Quase sempre subjetivo, por isso deve envolver o usuário sempre que possível - Pode ser objetivo também: - Exemplo: 1-buyclick da Amazon - Navegação por teclado - Acessibilidade - Internacionalização: - Sistema precisa trabalhar com múltiplas línguas - Vai testar só com o português ou inglês? - Os textos cabem nos espaços da interface? 87 Testes Sistêmicos Priorização Está acabando o tempo, o que priorizo? Testes positivos Verifique até onde já foram realizados os testes Do que sobrou, o que agrega mais ao cliente? Testes positivos abrangem as funcionalidades que mais agregam ao cliente Testes negativos Verifique até onde já foram realizados os testes Qual o tipo de erro mais recorrente? Ataque os erros mais comuns 88 Processo de Teste Testes de Aceitação Teste realizado pelos usuários. Garantir que tudo o que foi definido nos requisitos tenha sido incluído no produto. Em alguns casos, os testadores auxiliam os usuários a executar essa atividade. Testes de Verificação Espeficicação de Requisitos Verificação de Requisitos Modelagem do Software Verificação da Modelagem REVISÕES Software Finalizado Validação do Sistema Testes de Validação CAIXA PRETA CAIXA BRANCA Software Finalizado Validação / Aceite Codificação Verificação do Código Unidade Desenvolvida Validação da Unidade Unidades Finalizadas Validação da Integração

16 Registro dos Problemas Identificados no Teste Trabalho da Disciplina Caso ocorra algum erro, reportamos um defeito com os seguintes dados: Sumário Passo para reprodução Severidade Ambiente Além de registrar os problemas, ao final de cada fase é necessário realizar um relatório sumarizando a quantidade de problemas identificados e verificar a necessidade de um reteste. Descrição: Montar um Plano de Teste para os seguintes sistemas: 1. Sistema de Controle Acadêmico 2. Sistema de Controle de Estoque 3. Sistema de Locação de Automóveis 4. Sistema de Clínica Odontológica 5. Sistema de Transação Monetária Itens do Plano de Teste: 1. Introdução, 2. Itens de teste, 3. Escopo, 4. Não escopo, 5. Abordagem, 6. Critérios de execução, 7. Critérios de interrupção e continuação, 8. Entregáveis, 9. Ambiente de Teste, 10. Papéis e Responsabilidades