Estratégias de Teste de Software Fabrício de Sousa
O que é Teste? Processo de executar um programa com a intenção de descobrir um erro Um teste bem-sucedido é aquele que revela um erro ainda não descoberto. 2
Testes 3
Estratégias de Teste Roteiro que descreve os passos a serem conduzidos Esforço, tempo e recursos necessários Planejamento Projeto de casos de testes Execução Coleta e avaliação dos dados 4
Processo de Teste 5
Estratégias de Teste Revisões Formais antes do início do teste Diferentes técnicas de teste são adequadas em diferentes momentos Começa de dentro para fora, em direção a integração de todo o sistema Quem faz o teste Programador Engenheiro de teste 6
Processo de Teste 7
Testes Testes x Depuração Testes de baixo nível Verifica se pequeno segmento do código foi implementada corretamente Testes de alto nível Valida as principais funções do sistema 8
9
Verificação e Validação (V&V) Verificação Garante que o software implementa corretamente uma função especifica Validação Garante que o software construído corresponde aos requisitos do usuário 10
Garantia da Qualidade de Software (SQA) Revisões técnicas Auditoria de qualidade Configuração Monitoramento de desempenho Simulação de estudo de viabilidade Revisão de documentação Revisão da base de dados Análise de algoritmos Teste de usabilidade Teste de qualificação Teste de instalação 11
Teste x Qualidade Você não pode testar a qualidade. Se ela não estiver lá antes de você começar a testar, ela não estará lá quando terminar de testar A qualidade é incorporada durante o processo de ES Aplicação adequada de métodos e ferramentas, revisões técnicas e gerencia e medições sólidas, levam à qualidade, confirmada durante o teste 12
Organização do Teste Quem deve testar? Programador Quem conhece o programa melhor do que eles? Interesse oculto em demonstrar que o programa está livre de erros, funciona de acordo com os requisitos do cliente e será completado no cronograma e dentro do orçamento 13
Organização do Teste Análise,projeto de software e implementação Tarefa construtiva Testes Tarefa destrutiva Programador tem amor a cria não quer achar erro Faz teste para mostrar que o programa funciona Infelizmente os erros estão presentes Se ele não descobrir o cliente irá descobrir 14
15
Verdadeiro ou Falso? O programador não deve fazer teste? O programa deve ser entregue as estranhos para testar? O engenheiro de teste se envolve com o projeto apenas quando os passos de testes forem começar? Todas são falsas 16
Grupo Independente de Teste Indepent Test Group ITG São pagos para encontrar erros Trabalha juntamente com o ES É interessante que já esteja envolvido no projeto durante a fase de análise e o projeto As vezes, pertence a uma Organização de Qualidade de Software Grau de independência 17
Estratégia de Teste Teste de Unidade Concentra-se em cada unidade (funcionalidade) Teste de Integração Foco no projeto e na arquitetura Teste de Validação Os requisitos estabelecidos são validados com relação ao software construído Teste de Sistema Software e os outros elementos do sistema são testados com um todo. Hardware, pessoal, banco de dados, etc. 18
Relação entre o processo de desenvolvimento e uma estratégia de software 19
Processo de Teste 20
Quando saberemos que é hora de parar de testar? 21
Quando saberemos que é hora de parar de testar? Você nunca para de testar A tarefa simplesmente passa de você, ES, para o seu cliente Cada vez que o cliente/usuário executa o programa, ele está sendo testado Resposta um tanto cínica Devemos parar quando o tempo acabar ou quando o dinheiro acaba. 22
Métricas Uso de métricas Teoria da confiabilidade do software Modelos de falhas do software em função do tempo de execução
Que diretrizes levam a uma estratégia de software bemsucedida? Especifique os requisitos do produto de um modo quantificável muito antes do teste começar. Embora o principal objetivo seja encontrar erros, serve para avaliar outras características de qualidade: portabilidade, manutenibilidade e usabilidade 24
Que diretrizes levam a uma estratégia de software bemsucedida? (cont.) Enuncie explicitamente os objetivos do teste Efetividade do teste Cobertura do teste Tempo médio entre falhas Custo de encontrar e consertar defeitos Densidade restante de defeitos Frequencia de ocorrência de defeitos Número de horas de testes 25
Que diretrizes levam a uma estratégia de software bemsucedida? (cont.) Entenda os usuários do software e desenvolva um perfil de cada categoria de usuário Uso de cenário do caso de uso Desenvolva um plano de teste que enfatize teste de ciclo rápido 2% do esforço projeto de incrementos de funcionalidade 26
Que diretrizes levam a uma estratégia de software bemsucedida? (cont.) Construir software robusto que é projetado para testar a si próprio Técnicas anti-defeitos Automação de testes Teste de regressão Use revisões técnicas formais efetivas como filtro antes do teste Revisões técnicas reduzem a quantidade de erros 27
Que diretrizes levam a uma estratégia de software bemsucedida? (cont.) Conduza revisões técnicas formais para avaliar a estratégia de teste e os casos de testes propriamente ditos Descobre inconsistências Omissões e Erros gritantes Poupa tempo e aperfeiçoa a qualidade do produto 28
Que diretrizes levam a uma estratégia de software bemsucedida? (cont.) Desenvolva uma abordagem de aperfeiçoamento contínuo para o processo de teste A estratégia de teste deve ser medida As métricas coletadas durante os testes devem ser usados com parte de uma abordagem estatística de controle do processo 29
Testar apenas com base nos requisitos perceptíveis ao usuário final é como inspecionar um edifício com base no trabalho feito pelo decorador de interiores, em detrimento das fundações, da estrutura e dos encanamentos Boris Beizer 30
Estratégias de teste para Software Convencional Esperar o sistema terminar e só então começar os testes? ES pode conduzir testes diariamente sempre que um novo código for implementado? Escolha que fica entre os dois extremos Visão incremental dos testes Teste de Unidade Teste de Integração 31
Teste de Unidade Focaliza o esforço de verificação na menor unidade de projeto de software Componente ou módulo do software Todos os caminhos independentes Devemos garantir que todos os comandos tenham sidos executados pelo menos uma vez As condições limites são testados Todos s caminhos de manipulação de erros são testados 32
33
Teste de Unidade O teste seletivo de caminhos de execução é uma tarefa essencial Casos de testes Descobrir erros devidos cálculos errados Comparações incorretas Fluxo de controle inadequado Erros mais comuns no cálculo Precedência aritmética mal entendida ou incorreta Operações em modo misto Inicialização incorreta Falta de precisão 34
Teste de Unidade Comparações e fluxo de controle estão intimamente aclopados Freqüentemente ocorre mudança de fluxo após uma comparação Casos de testes devem descobrir erros de: Comparação de tipos de dados diferentes Operadores ou precedência lógica incorreta Expectativa de igualdade quando o erro de precisão torna a igualdade improvável Comparação incorreta de variáveis Dentre outras... 35
Teste de Unidade Testes nos limites Uma das tarefas mais importante O Software freqüentemente falha no seus limites: N-ésimo termo elemento do vetor é processado i-ésima repetição de um ciclo com i passagens é chamado Bons casos de testes Valores de dados Acima Abaixo Máximo Mínimo No intervalo...provavelmente descobrirão erros 36
Teste de Unidade Antidefeitos Condições de erro são antecipados e caminhos de manipulação de erros são estabelecidos para direcionar ou claramente terminar o processo quando um erro claramente ocorre 37
Teste de Unidade Mensagens de erros Problemas: A descrição do erro é ininteligível O erro mencionado não corresponde ao erro encontrado A condição de erro provoca a intervenção do sistema antes da manipulação do erro Processamento da condição de exceção está incorreto Descrição do erro não fornece informação suficiente para ajudar na localização da causa do erro 38
Procedimentos de teste de Unidade Normalmente considerado um apêndice ao passo de codificação Pode ser iniciado antes ( preferência programação ágil) Depois que o código ter sido gerado 39
Como testar componentes? Componente não é um programa isolado Software para um pseudocontrolador (driver) Software para um pseudocontrolado (stub) Pseudocontrolador Nada mais é do que um programa principal Aceita dados do caso de teste, passa tais dado ao componente ( a ser testado) e imprime os resultados relevantes Pseudocontrolado Servem para substituir módulos que são chamados ao componente a ser testado 40
Como testar componentes? Pseudocontroladores e pseudocontrolados Despesas extras São softwares que precisam ser escritos, mas não entregue com o produto final do software Infelzimente muitos não são testados Solução: deixar para o teste de integração 41
42
Teste de Integração Se todos eles funcionam individualmente, por que você duvida que vão funcionar quando colocados em conjunto? O problema é sem dúvida, colocá-los juntosinterfaces Dados podem ser perdidos através de uma interface Um módulo pode ter um efeito imprevisto ou adverso sobre outro Subfunções quando combinadas podem não produzir o resultado a função principal desejada 43
Teste de Integração Tendência de tentar integração nãoincremental Abordagem big-bang Todos os componentes são combinados com antecedência O programa inteiro é combinado de uma só vez Usualmente resulta num CAOS Conjunto de erros é encontrado A correção é difícil porque o isolamento das causas é complicado pelo vasto programa inteiro Novos erros aparecem 44
Teste de Integração Integração incremental Antítese da big-bang Programa é construído e testado em pequenos incrementos Erros são mais fáceis de isolar e corrigir 45
Estratégias de integração incrementais Integração descendente Integração Ascendente Teste de regressão Teste fumaça 46
Integração descendente Top-down Movimento de cima para baixo na hierarquia Primeiro módulo principal Posteriormente os subordinados são incorporados Primeiro em profundidade ou Primeiro em largura 47
48
Integração Ascendente Bottom-up Inicia a construção e teste de módulos atômicos Necessidade de pseudocontroladores são eliminados 49
Teste de regressão Cada vez que um módulo é adicionado o software se modifica Funções que funcionavam impecavelmente não mais funcionam Reexecução de algum subconjunto de teste que já foi conduzido para garantir que as modificações não propagassem efeitos colaterais indesejáveis 50
Teste de regressão Pode ser conduzido: Manualmente Reexecutando um subconjunto de todos os casos de teste Ferramentas automatizadas de captação/reexecução Capta casos de testes e resultados para subsequente reexecução e comparação 51
Teste Fumaça Projetos de prazo crítico Freqüência diária de teste Exercita o sistema inteiro de ponta a ponta Não precisa ser exaustivo Deve ser capaz de expor os problemas principais 52
Teste Fumaça: Vantagens O risco de integração é minimizado A qualidade do produto final é aperfeiçoada Diagnóstico e correção de erros são simplificados Progresso é fácil de avaliar 53
Teste Sandwiche Testes descendentes Níveis mais alto Testes ascendentes Níveis subordinados 54
Módulo Crítico Aborda vários requisitos do software Alto nível de controle É complexo ou propenso a erros Requisitos de desempenho bem definidos»devem ser testados tão cedo possível 55
Documentação do teste de Integração Especificação de teste Plano de teste Procedimento de teste Parte da configuração do software Dividido em fases 56
Fases de Testes Integridade da Interface Validade funcional Conteúdo informacional Projetados para descobrir erros associados com estruturas de dados locais ou globais Desempenho Definição de datas iniciais e finais Ambiente e recursos de testes são descritos Técnicas de teste 57
Fases de Testes Plano detalhado do teste Os testes de cada fase de integração Lista de todos os casos de testes Resultados esperados Relatório de Teste Histórico dos resultados reais do teste 58
O melhor testador não é aquele que encontra mais erros...o melhor testador é aquele que corrige a maior parte dos erros Cem Kaner et al 59
Teste de Validação Começa no fim do teste de Integração Se torna bem sucedido quando funciona de modo esperado pelo cliente 60
61
Critérios do Teste de Validação Séries de testes Demonstram conformidade com os requisitos Plano de testes Valida Características comportamentais, requisitos de desempenho, usabilidade, etc. 62
Teste Alfa Feito no ambiente do desenvolvedor com os usuários finais Desenvolvedor olhando sobre os ombros dos cliente Registrando erros e problemas de uso Ambiente controlado 63
Teste Beta Feito no ambiente dos usuários finais O desenvolvedor geralmente não está presente O cliente registra todos os problemas que são encontrados e relata ao ES 64
Teste de Sistema O software é apenas um elemento de um sistema baseado em computador Incorporado a: Hardware, pessoal e Informação Não são conduzidos apenas por ES 65
Teste Grande problema: Dedo-duro Erro descoberto e cada desenvolvedor culpa o outro 66
Teste de Sistema ES deve antecipar problemas potenciais Antecipar problemas potenciais Projetar caminhos de manipulação de erros Testes que simulem maus dados Registrar os resultados dos testes Participar do planejamento e projeto de teste 67
Teste de Sistema Teste de Recuperação Teste de Segurança Teste de Estresse Teste de Desempenho 68
Teste de Recuperação Deve ser tolerante a falhas Deve ser corrigido dentro de um curto período de tempo Teste que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada 69
Teste de Recuperação Verifica-se se: Se a recuperação é automática Reinicialização Mecanismo de verificação Recuperação dos dados e o reinício Se a recuperação requer intervenção humana Tempo médio de reparo 70
Teste de Segurança Informações confidenciais Alvo para invasões Hackers Empregados descontentes tentam invadir por segurança Indivíduos desonestos que buscam ganhos pessoais ilícitos 71
Teste de Segurança Verifica-se se os mecanismos de proteção incorporadores vão proteger de invasão imprópria Teste em relação à invulnerabilidade Desempenha o papel do individuo que quer invadir o sistema Vale tudo! Tentar obter senhas de funcionários externos Atacar o sistema com software especifico Causar erros no sistema de propósito 72
Teste de Estresse Os demais testes testam o sistema sob condições normais do programa Teste de Estresse é projetado para submeter a situações anormais Demanda recursos em quantidade, freqüência ou volume anormais 73
Teste de Estresse: exemplos Gerar dez interrupção, quando a média é uma ou duas Velocidade de entrada aumentada em ordem de grandeza Caso de teste que exigem um máximo de memória ou recursos Busca excessiva 74
Teste de Desempenho Sistemas de tempo real e embutidos Desempenho é inaceitável Testa o desempenho na sua execução Pode ser feito desde o teste de unidade O verdadeiro desempenho é medido com o término do projeto 75
Teste de Desempenho Freqüentemente acoplado ao teste de estresse Mede a utilização de recursos Processador Registra eventos (intervenções) 76
A arte de depuração É a ação que resulta na correção do erro Pode e deve ser um processo ordenado Ainda é excessivamente uma arte 77
78
Processo de Depuração Ocorre em conseqüência do teste 1. Execução do Casos de testes 2. Resultados comparados A depuração terá dois possíveis resultados A causa será encontrada e corrigida A causa não será encontrada 79
Processo de Depuração Sintomas e causas geograficamente remotos Sintoma pode desaparecer quando outro erro for corrigido Sintoma pode ser causado por não-erros (ex.imprecisões de arredondamentos) Sintoma causado por erro humano 80
Depuração: Considerações psicológicas É uma das partes mais frustrantes da programação Elevada ansiedade e má vontade em aceitar a possibilidade de erros Felizmente, há um suspiro de alívio e uma diminuição de tensão quando o defeito é finalmente corrigido. 81
Abordagens de depuração Táticas de depuração Força bruta Rastreamento Eliminação da causa 82
Força Bruta Método mais comum Menos eficiente Deixe o computador encontrar o erro Listagem de memória Rastreadores de execução Comandos de saída 83
Rastreamento O código é rastreado manualmente até que o lugar da causa seja encontrado Muitas linhas de código Tarefa mais complexa 84
Eliminação da causa Os dados relacionados à ocorrência do erro são organizados para isolar causas em potencial Hipótese de causa é concebida Dados são usados para provar ou rejeitar a hipótese Lista de todas as causa possíveis é desenvolvida São conduzidos testes para eliminar cada um 85
Depuração automatizada Uso de rastreadores Visualização de software Geradores automáticos de casos de testes 86
Correção do erro Correção de um defeito pode inserir novos O ES deve fazer três perguntas antes de fazer a correção do software: A causa do defeito está reproduzida em outra parte do programa? Qual o próximo defeito que pode ser introduzido pelo conserto que estou prestes a fazer? O que poderíamos ter feito para prevenir a ocorrência desse erro? 87
Dúvidas? 88
O Mundo sem engenheiros aeronáutico... 89
...Sem Engenheiro Mecânico 90
Sem Engenheiro Eletrônico... 91
Sem Engenheiro Civil 92
Sem Engenheiro de Comunicação 93
...Sem Engenheiro de Software 94