TESTES DE SOFTWARE. Profa. Maria Auxiliadora

Transcrição

1 TESTES DE SOFTWARE 1

2 Teste de software É uma atividade crítica na garantia de qualidade de software; Quatro dimensões: Estado do teste ( o momento ); Técnica do teste ( como vou testar ); Metas do testes ( o que tenho que testar ); Onde será o teste ( ambiente do teste ). 2 2

3 Objetivos da Atividade de Teste Projetar testes que descubram sistematicamente diferentes classes de erros e façam-o com uma quantidade de tempo e esforço mínimos. Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software. 3

4 Objetivos da Atividade de Teste A atividade de teste não pode mostrar a ausência de bugs; ela só pode mostrar se defeitos de software estão presentes. Se erros graves forem encontrados com regularidade a qualidade e a confiabilidade de software são suspeitas. 4

5 Objetivos da Atividade de Teste Se erros facilmente corrigíveis forem encontrados a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves. Se não for encontrado erro a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software. 5

6 Organização para Realização de Teste de Software Quando o teste se inicia há um conflito de interesses: Desenvolvedores: interesse em demonstrar que o programa é isento de erros. Responsáveis pelos testes: interesse em mostrar que o programa tem erros. 6

7 Organização para Realização de Teste de Software Do ponto de vista psicológico: Análise, Projeto e Codificação de Software são tarefas construtivas Teste é tarefa destrutiva 7

8 Verificação e Validação Objetivo: assegurar que o software Cumpra as suas especificações e atenda às necessidades dos usuários e clientes. Ocorrem em todo o ciclo de vida do software Revisões de requisitos, revisões de design, inspeções de código e teste do produto. 8

9 Verificação e Validação Validação: Estamos construindo o produto certo? O software deve atender às necessidades dos usuários. Verificação: Estamos construindo o produto corretamente? O software deve estar de acordo com a sua especificação. 9

10 Metas do processo de Verificação e Validação Função de software O nível de confiança depende de quanto o software é para uma organização. Expectativas de usuário Usuários podem ter poucas expectativas em relação ao software. 10

11 Metas do processo de Verificação e Validação Ambiente de mercado verificar o momento exato de colocar o produto no mercado ( com ou sem depuração e teste do produto). 11

12 Planejamento de Verificação e Validação Um planejamento cuidadoso é necessário para obter o melhor das inspeções e dos testes e para controlar os custos do processo de verificação e validação. O planejando de V&V deve se iniciar no começo do processo de desenvolvimento. 12

13 Planejamento de Verificação e Validação Especificação de requisitos Especificação de sistema Projeto de sistema Projeto detalhado Plano de teste de aceitação Plano de teste de integração de sistema Plano de teste de integração de subsistema Teste de unicidade e de módulo Operação Teste de aceitação Teste de integração do sistema Teste de integração do subsistema 13

14 O que deve ser verificado e validado? Fatores de Qualidade de Revisão Relacionados com a manutenção, evolução e avaliação do software. Fatores de Qualidade de Transição Relacionados com a instalação, reutilização e interação com outros produtos. 14

15 Técnicas de V & V Inspeções de software (V & V estática) Testes de software (V & V dinâmica) 15

16 Inspeções de Software Interessadas na análise da representação estática do sistema para descobrir problemas Pode ser suplementado por ferramentas baseadas em documentos e análise de códigos. 16

17 Teste de Inspeção 17

18 Inspeções de Programas Revisões cujo objetivo é a detecção de defeitos no programa. Principal meta DESCOBERTA de defeito (não correção). Defeitos podem ser erros lógicos, anomalias no código que poderia indicar uma condição errônea. 18

19 Checagem de Inspeções Defeitos nos dados: Todas as variáveis de programa são iniciadas antes de seus valores serem utilizados? Todas as constantes foram denominadas? Existe alguma possibilidade de overflow de buffer (limite de vetores)? 19

20 Checagem de Inspeções Defeitos de controle: Para cada condição condicional a condição está correta? As declarações compostas estão corretamente entre parênteses? 20

21 Checagem de Inspeções Defeitos de entrada e saída Todas as variáveis de entrada são utilizadas? Todas as variáveis de saída têm um valor designado antes de saírem? 21

22 Checagem de Inspeções Defeitos de interface Todas as chamadas de funções e métodos têm o número correto de parâmetros? Os parâmetros estão em ordem corretas? 22

23 Checagem de Inspeções Defeito de gerenciamento de armazenamento Se o armazenamento dinâmico é utilizado, o espaço foi alocado corretamente? O espaço é explicitamente liberado, depois que não é mais necessário? 23

24 Teste de software (dinâmica) 24 24

25 Teste de Validação - escopo Objetivo: Avaliar a possibilidade de uso do sistema Quem faz: Cliente ou usuário final O que é testado: Funções principais, documentação e procedimentos Quando termina: Em geral, quando o usuário se sente a vontade, ou quando o teste proposto dá bom resultado. 25

26 Teste de Programa Um teste próspero é um teste que descobre um ou mais erros. Elaboração de casos de testes baseados na especificação funcional Dados de entradas. Comportamento esperado. 26

27 Teste de Programa Podem ser classificados Quanto ao método: defeitos e estatísticos. Quanto ao escopo: unicidade, integração, sistema e aceitação. 27

28 Tipos de Testes (Método) Testes de defeitos Tem por objetivo encontrar defeitos inconsistências entre o programa e a sua especificação. Verifica a correção conhecido também por testes de correção. Normalmente realizados com protótipos funcionais. 28

29 Tipos de Testes (Método) Testes estatísticos Utilizados para avaliar o desempenho e a confiabilidade checar como ele trabalha nas condições operacionais Exemplos de medições: Número de falhas observadas Tempos de resposta Tempos de execução 29

30 Teste de Programa Fase de Validação Categorias de Testes Aplicadas Características da Fase de Validação Teste de Baixo Nível Teste de Unidade Teste de Integração Estrutura Interna Funcionalidade Usabilidade Segurança Interfaces Dependência entre Componentes Estratégia caixa branca e caixa preta. Testar partes do software. Requer conhecimento da estrutura interna. Executada pelo desenvolvedor ou profissional de teste. Estratégia de caixa branca e caixa preta. Testa integrações entre partes de software. Requer conhecimento da arquitetura interna do software. Executada pelo desenvolvedor ou profissional de teste. 30

31 Teste de Programa Fase de Validação Categorias de Testes Aplicadas Características da Fase de Validação Teste de Alto Nível Teste de sistema o o o o Funcionais Não Funcionais Performance Instalação Recuperação Carga Estratégia de caixa preta. Os testes são aplicados no software como todo. Não requer conhecimento da estrutura interna do software. Requer ambiente muito semelhante ao da produção. Deves ser executada por um grupo de teste independente. 31

32 Esquema Tipos de Unicidade 32

33 Tipos de Unicidade É o processo de teste de componentes individuais isoladamente. As unidades podem ser: Funções individuais ou métodos dentro de um objeto Classes de objetos com vários atributos e métodos Componentes compostos com interfaces definidas usados para acessar suas funções. 33

34 Tipos de Unicidade 34

35 Testes de Integração Concentra-se no projeto e na construção da arquitetura de software. Conhecidos como testes em ponto grande. Os componentes são integrados e o conjunto maior é testado módulo e subsistemas. 35

36 Testes de Integração Tipos de interfaces Interfaces de parâmetro - Dados passados de um método ou procedimento para o outro. Interfaces de memória compartilhada - Blocos de memória são compartilhados entre os procedimentos ou funções. Interfaces de procedimento - Subsistemas sintetizam um conjunto de procedimentos para serem chamados por outros subsistemas. Interfaces de passagem de mensagem - Subsistemas solicitam serviços de outros subsistemas. 36

37 Testes de Integração Quem faz: Geralmente o programador. O que é testado: A integração entre os módulos. Quando termina: Quando o programador verifica que a interligação entre os módulos se encontra bem definida. 37

38 Testes de Integração Não-Incremental: As unidades são combinadas e o programa completo é testado como um todo. Incremental: Combina o módulo seguinte a ser testado com o conjunto de módulos já testados, existem alguns tipos: Integração Top-down. Integração Bottom-up. 38

39 Integração Top-down Módulos são integrados de cima para baixo, partindo-se do módulo principal. Pode ser realizada, de duas maneiras: por profundidade (depth first) por largura (breadth first) 39

40 Integração Top-down 40

41 Integração Bottom-up Início da construção e dos testes com módulos atômicos (localizados no nível mais baixo da estrutura do sistema). Quando os módulos de níveis superiores vão ser testados, os módulos subordinados já estão prontos e portanto, não se torna necessária a criação de stubs. 41

42 Integração Bottom-up M c M a M b D 1 D 2 D 3 Cluster 1 Cluster 3 Cluster 2 42

43 Testes de Integração Vantagens e desvantagens Integração Top-down: Vantagem: Testar logo no início as funções principais do software. Desvantagem: necessidade de simuladores. Integração Bottom-up: Vantagem: permite que as unidades mais básicas sejam testadas mais cedo. Desvantagem: O módulo principal não existe até que todos os módulos estiverem testados. 43

44 Teste de Sistema Verificar se as funções estão de acordo com a especificação e se todos os elementos do sistema combinam-se adequadamente. Quem faz: Líder do projeto ou grupo de teste; O que é testado: Necessidades técnicas e funcionais do sistema. Interfaces do sistema; 44

45 Teste de Sistema Quando termina: Em geral, quando a maioria das necessidades é atendida, permanecendo poucos erros importantes; Recursos extras: Biblioteca de casos de testes. Geradores, comparadores e simuladores de teste em massa. 45

46 Teste de Sistema Envolve uma série de diferentes testes, cujo propósito primordial é pôr completamente à prova o sistema baseado em computador. Se divide em quatro testes: Teste de Recuperação; Teste de Estresse; Teste de Desempenho; Teste de Segurança. 46

47 Teste de Sistema Teste de Recuperação É um teste de sistema que força o software a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada. 47

48 Teste de Sistema Teste de Estresse Confronta os programas com situações anormais de frequência, volume ou recursos em quantidade. Pode ser utilizada uma lista com situações padrão de provocação de estresse do sistema. 48

49 Teste de Sistema Teste de Desempenho Testa o tempo de resposta do sistema e é aplicado geralmente para sistemas de tempo real. Preocupa-se com o rendimento, tempo de resposta e capacidade ( especialmente a capacidade do banco de dados.) 49

50 Teste de Segurança Teste de Sistema Tenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de fato, de acessos indevidos. A estratégia de teste deve ser feita por programadores que não desenvolveram o software. Os testadores devem tentar invadir o sistema de várias formas: obtenção ilegal de senhas, desarme do sistema e outros. 50

51 Teste de Aceitação Objetivo: Avaliar a possibilidade de uso do sistema; Quem faz: Cliente ou usuário final; O que é testado: Funções principais, documentação e procedimentos; Quando termina: Em geral, quando o usuário se sente a vontade, ou quando o teste proposto dá bom resultado. 51

52 Teste de Aceitação Revisão da configuração 52

53 Teste de Aceitação Tipos: Alfa: É feito por um cliente nas instalações do desenvolvedor. O software é usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros do usuário e registrando erros e problemas de uso. 53

54 Teste de Aceitação Tipos... Beta: É realizado nas instalações do cliente pelo usuário final do software. O desenvolvedor não está presente, e o cliente registra os problemas que são encontrados e relata-os ao desenvolvedor posteriormente. 54

55 Projeto de Casos de Teste Oferece uma abordagem sistemática ao teste; É um mecanismo que ajuda a garantir a mais alta probabilidade de revelar erros no software com uma quantidade mínima de tempo e esforço. 55

56 Projeto de Casos de Teste Teste de Caixa Preta (teste funcional) Teste de Caixa Branca (teste estrutural) Teste de Caminho Básico Caminho Independente Complexidade Ciclomática Teste de Estrutura de Controle Teste de Condição Teste de Fluxo de Dados Teste de Laços Teste no contexto de OO 56

57 Teste Funcional (caixa preta) O programa é uma caixa preta cujo comportamento é determinado estudando-se as suas entradas e saídas. Os casos de testes são derivados da especificação funcional. A escolha dos dados de entrada podem ser feitas com várias técnicas: Partição de domínio Análise de valor limite 57

58 Teste Funcional (caixa preta) Envolve dois passos principais: Identificar as funções que o software deve realizar (especificação dos requisitos) Criar casos de teste capazes de checar se essas funções estão sendo executadas corretamente. 58

59 Teste Funcional (caixa preta) Entrada de dados de teste I e Entradas que provocam comportamento anômalo Sistema Saída dos resultados de teste O e Saídas que revelam a presença de defeitos 59

60 Teste Funcional (caixa preta) Problemas: Dificuldade em quantificar a atividade de teste: não se pode garantir que partes essenciais ou críticas do software foram executadas. Dificuldade de automatização. 60

61 Teste estrutural (caixa branca) São testados os caminhos lógicos através do software, fornecendo casos de teste que põem à prova conjuntos específicos de condições e/ou laços. Exercita as estruturas de dados internas para garantir a sua validade; 61

62 Teste estrutural (caixa branca) Executa todos os laços em suas fronteiras; Exercita todas as decisões lógicas para valores falsos ou verdadeiros. 62

63 Teste estrutural (caixa branca) Dados de teste testa Deriva Código de componente Saídas do teste 63

64 Teste de Caminho Básico O teste de caminho básico possibilita que o projetista do caso de teste derive uma medida de complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução. 64

65 Teste de Caminho Básico 65

66 Fluxograma e Grafo de Fluxo , Fluxograma Grafo de fluxo 66

67 Teste de software Configuração de Software Esquema Atividades de Teste Resultados dos Testes Avaliação Erros Depuração Correções Configuração de Teste Resultados Esperados Dados da Taxa de Erros Modelo de Confiabilidade Confiabilidade Prevista 67

68 Ferramentas de Automatização Uma ferramenta de teste reduz a intervenção humana nos resultados obtidos, aumentando a qualidade e a produtividade da atividade de teste. Influencia diretamente a confiabilidade do software testado. 68

69 Tipos de Ferramentas Estáticas: verificam portabilidade, estilo e são independentes da qualidade dos casos de teste. Dinâmico Monitoram a execução do programa. Adiciona código a um programa para contar o número de vezes que cada declaração foi executada. Simulador simulam a máquina em que o programa deve ser executado. 69