Estratégias de Teste de Software. Fabrício de Sousa

Transcrição

1 Estratégias de Teste de Software Fabrício de Sousa

2 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

3 Testes 3

4 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

5 Processo de Teste 5

6 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

7 Processo de Teste 7

8 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 9

10 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

11 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

12 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

13 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

14 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 15

16 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

17 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

18 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

19 Relação entre o processo de desenvolvimento e uma estratégia de software 19

20 Processo de Teste 20

21 Quando saberemos que é hora de parar de testar? 21

22 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

23 Métricas Uso de métricas Teoria da confiabilidade do software Modelos de falhas do software em função do tempo de execução

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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 33

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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 42

43 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

44 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

45 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

46 Estratégias de integração incrementais Integração descendente Integração Ascendente Teste de regressão Teste fumaça 46

47 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 48

49 Integração Ascendente Bottom-up Inicia a construção e teste de módulos atômicos Necessidade de pseudocontroladores são eliminados 49

50 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

51 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

52 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

53 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

54 Teste Sandwiche Testes descendentes Níveis mais alto Testes ascendentes Níveis subordinados 54

55 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

56 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

57 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

58 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

59 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

60 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 61

62 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

63 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

64 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

65 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

66 Teste Grande problema: Dedo-duro Erro descoberto e cada desenvolvedor culpa o outro 66

67 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

68 Teste de Sistema Teste de Recuperação Teste de Segurança Teste de Estresse Teste de Desempenho 68

69 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

70 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

71 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

72 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

73 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

74 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

75 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

76 Teste de Desempenho Freqüentemente acoplado ao teste de estresse Mede a utilização de recursos Processador Registra eventos (intervenções) 76

77 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 78

79 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

80 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

81 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

82 Abordagens de depuração Táticas de depuração Força bruta Rastreamento Eliminação da causa 82

83 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

84 Rastreamento O código é rastreado manualmente até que o lugar da causa seja encontrado Muitas linhas de código Tarefa mais complexa 84

85 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

86 Depuração automatizada Uso de rastreadores Visualização de software Geradores automáticos de casos de testes 86

87 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

88 Dúvidas? 88

89 O Mundo sem engenheiros aeronáutico... 89

90 ...Sem Engenheiro Mecânico 90

91 Sem Engenheiro Eletrônico... 91

92 Sem Engenheiro Civil 92

93 Sem Engenheiro de Comunicação 93

94 ...Sem Engenheiro de Software 94