Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Estratégias e Técnicas de Testes - Parte 2

883 vues

Publié le

Slides da da palestra sobre Estratégias e Técnicas de Testes, apresentada por mim, na data de 19/11/2013 aos formandos do curso de Análise de Sistemas da instiutição IBES

Publié dans : Logiciels
  • Soyez le premier à commenter

Estratégias e Técnicas de Testes - Parte 2

  1. 1. Estratégias e Técnicas de Teste de Software Lorena Caldas – 19/11/2013
  2. 2. Resumo da Apresentação •Parte 1 – Introdução ao Teste de Software ▫Principais Conceitos ▫Estratégias de Teste •Parte 2 – Técnicas de Teste de Software ▫Técnicas, Situações e Ferramentas
  3. 3. Técnicas, Situações e Ferramentas
  4. 4. Execução dos Testes •A atividade de execução dos testes é realizada após a construção de um produto de trabalho, quando na etapa de Verificação, ou após o desenvolvimento de um escopo do sistema, quando na etapa de Validação. ▫Verificação: Revisões de requisitos, modelos, gráficos, inspeções na base de dados ▫Validação Execução do software e sua infraestrutura para analisá-lo sob ponto de vista dos procedimentos usuais
  5. 5. Técnicas •Devem considerar: ▫Estratégia e Método escolhidos Características do Software ▫Ferramentas disponíveis
  6. 6. Estratégias X Técnicas •As Técnicas de Teste devem ser escolhidas conforme Estratégia definida. Elas podem participar de várias Estratégias ou ser combinadas entre si •Por Tipo de Sistema ▫Desktop, Web, Mobile e Híbrido •Por Arquitetura ▫Top-down e Bottom-up •Por Abrangência ▫Unidade, Integração e Sistema •Por Fase ▫Confirmação, Aceite e Manutenção
  7. 7. Técnicas •Podem ser: ▫Estruturais (Caixa Branca) São testados os caminhos lógicos do sistema em suas diversas camadas ▫Funcionais (Caixa Preta) Considera as entradas e saídas do sistema, de acordo com as especificações de interface ▫Não Funcionais Observa os aspectos além daqueles funcionais ▫Baseados em Erros São inseridos defeitos propositais no sistema para que se já existia falhas no software (código legado)
  8. 8. Testes Estruturais (Caixa Branca)
  9. 9. Testes Estruturais – Caixa Branca •Observa os procedimentos de construção do software: ▫Análise dos produtos do projeto: modelos, tabelas, gráficos, classes ▫Revisões de código-fonte ▫Estruturas das tabelas e integridade dos dados ▫Forma da comunicação em rede •Ator: Projetista, programador, analista de sistemas e tester
  10. 10. Testes Estruturais – Caixa Branca •Objetivo: ▫Garantir que todos os caminhos de uma funcionalidade, suas decisões lógicas, laços, fronteiras e estruturas de dados foram exercitados ao menos 1 vez •Métodos ▫Caminho Básico ▫Caminho Independente ▫Complexidade Ciclomática
  11. 11. Testes Estruturais – Caminho Básico •O ator define um limite aceitável para os caminhos lógicos básicos do sistema sejam identificados (fluxo de controle) •Condição de Aceite: ▫Quantidade de itens sem ramificação não ultrapassa limite aceitável •Notação Utilizada: ▫Grafo de fluxo
  12. 12. Testes Estruturais – Caminho Independente •Extensão do Ciclo Básico – São caminhos do sistema que levam a uma novo conjunto de instruções de processamento de uma nova condição •Condição de Aceite: ▫Fluxos de controle possuem ramificações •Notação Utilizada: ▫Grafo de fluxo Caminhos Independentes: Caminho 1: 1 – 11 Caminho 2: 1 – 2,3 – 4,5 – 10 – 1 – 11 Caminho 3: 1 – 2,3 – 6 – 8 – 9 – 10 – 1 – 11 Caminho 4: 1 – 2,3 – 6 – 7 – 9 – 10 – 1 – 11
  13. 13. Testes Estruturais – Complexidade Ciclomática •Extensão do Ciclo Básico e Independente – Mede a quantidade de caminhos independentes do conjunto de caminhos básicos •Condição de Aceite: ▫Limite máximo de teste necessários para exercitar todos os caminhos é respeitado •Formas de Fazer: ▫Número de regiões do grafo de fluxo ▫V(G) = E – N + 2 V (G) = número de teste necessários para cobrir instruções E = número de ramos do grafo N = número de nós do grafos do fluxo G ▫V(G) = P + 1 P = conjunto de nós que contém condicionais, contidos no fluxo G A Complexidade Ciclomática do grafo de fluxo é 4 O grafo de fluxo contém 4 regiões; V(G) = 11 ramos - 9 nós + 2 = 4; V(G) = 3 nós predicativos + 1 = 4.
  14. 14. Testes Estruturais – Como Fazer • Passo 1: Traçar o gráfico de fluxo para o trecho este trecho de código procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variaveis I,M:inteiro Inicio M A[1]; I 2; enquanto I T faça se A[I] > M então M A[I] I I+1 senão I I+1 fim se fim enquanto MAX M; fim do procedimento 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - Resposta
  15. 15. Testes Estruturais – Como Fazer • Passo 2: Definir conjunto de Caminhos Básicos procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variaveis I,M:inteiro Inicio M A[1]; I 2; enquanto I T faça se A[I] > M então M A[I] I I+1 senão I I+1 fim se fim enquanto MAX M; fim do procedimento 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - Resposta Nós sem ramificações: 1, 2, 3, 8, 9 e 10.
  16. 16. Testes Estruturais – Como Fazer • Passo 3: Definir Caminhos Independentes procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variaveis I,M:inteiro Inicio M A[1]; I 2; enquanto I T faça se A[I] > M então M A[I] I I+1 senão I I+1 fim se fim enquanto MAX M; fim do procedimento 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - Resposta Caminho 1: 1, 2, 3, 9, 10; Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9, 10; Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 10.
  17. 17. Testes Estruturais – Como Fazer • Passo 4: Encontrar Complexidade Ciclomática procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variaveis I,M:inteiro Inicio M A[1]; I 2; enquanto I T faça se A[I] > M então M A[I] I I+1 senão I I+1 fim se fim enquanto MAX M; fim do procedimento 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - Resposta N. Regiões: 3; V(G) = 9 ramos - 8 nós + 2 = 3; V(G) = 2 nós predicativos + 1 = 3.
  18. 18. Testes Estruturais – Como Fazer • Passo 5: Preparar casos de teste que exercitem todos os caminhos do conjunto básico procedimento MAIOR(A:VETOR; T:inteiro; var MAX:inteiro); variaveis I,M:inteiro Inicio M A[1]; I 2; enquanto I T faça se A[I] > M então M A[I] I I+1 senão I I+1 fim se fim enquanto MAX M; fim do procedimento 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - Resposta Caminho 1: 1, 2, 3, 9, 10 A=(1,3) T = 0 Resultado Esperado – Max = 1; Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9, 10 A=(1,3) T = 2 Resultado Esperado – Max = 3; Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 10 A=(3,1) T = 2 Resultado Esperado – Max = 3.
  19. 19. Ferramentas •Análise Estática ▫Não precisa executar o código-fonte •Análise Dinâmica ▫Precisa executar o código-fonte
  20. 20. Ferramentas de Análise Estática •IDEs ▫Eclipse, NetBeans, DevC++, VisualStudio, etc. •Plugins ou ferramentas integradas às IDEs ▫Code Explorer, Dodgy Code, FXCop, etc. •Browsers e plugins ▫Firebug, etc. •Outras ferramentas de visualização de software ▫Code Analisys, CodeScan, etc.
  21. 21. Ferramentas de Análise Dinâmica •Compiladores: ▫Prompt - Windows, Console – Linux •IDEs •Outras ferramentas de visualização de software
  22. 22. CodeExplorer
  23. 23. Quintics
  24. 24. FXCop
  25. 25. Code Analysis
  26. 26. Integradas às IDES ou browsers •Dodgy Code, JFokus, Firebug
  27. 27. Outras ferramentas de visualização de software •Universal Code Lines Counter •Thinking Craftsman’s Tool Kit
  28. 28. Testes Caixa Branca - Unitários •Criação de pequenos métodos de teste para cada função da classe •Ferramentas ▫JUnit ▫NUnit ▫Cucumber
  29. 29. JUnit
  30. 30. NUnit
  31. 31. Cucumber •Linguagem Gherkin
  32. 32. Testes Funcionais (Caixa Preta)
  33. 33. Testes Funcionais – Caixa Preta •Analisa a interface e suporte funcional do software: ▫Forma de apresentação do software: tela, terminal, componentes COTs, e-mail, etc. ▫Forma de armazenamento dos dados: base de dados, planilhas, arquivos, etc. ▫Operação sobre ambiente do cliente; ▫Interface de comunicação com outros sistemas ou módulos híbridos. •Ator: Tester
  34. 34. Testes Funcionais – Caixa Preta •Objetivo: ▫Exercitar todos os requisitos funcionais do sistema •Métodos ▫Partições de Equivalência ▫Análise do Valor Limite ▫Tabela de Decisão ▫Transição de Estados ▫Teste de Caso de Uso
  35. 35. Testes Funcionais – Caixa Preta •Testes Baseados em Especificações ▫Teste de Roteiro Quando existe um script pré-definido a ser seguido (caso de teste) •Testes Baseados na Experiência ▫Teste Exploratório Quando não existe documentação a ser seguida. Depende do conhecimento técnico do ator
  36. 36. Testes Funcionais – Partições de Equivalência •Os casos de teste são preparados conforme classificação dos dados de entrada
  37. 37. Testes Funcionais – Partições de Equivalência •Um bolo possui 6 camadas e 1 sabor por camada: limão, baunilha, maracujá, morango, nozes e chocolates. Quantas classes podem ser extraídas? ▫6 classes, 1 por sabor •Sabendo que cada camada possui 20 cm de altura, quais valores válidos e inválidos são necessários para testar todas as condições de teste do bolo? ▫Limão: 0 a 20 cm ▫Baunilha: 20 a 40 cm ▫Maracujá: 40 a 60 cm ▫Morango: 60 a 80 cm ▫Nozes: 80 a 100 cm ▫Chocolate: 100 a 120 cm Válidos Inválidos 10 -10, 30 30 15, 50 50 35, 70 70 50, 90 90 70, 110 110 90, 130
  38. 38. Testes Funcionais – Análise do Valor Limite •Os casos de teste são preparados conforme fronteiras das classes de equivalência, para os dados de entrada e saída do sistema ▫Classe Válida Extremidades mínima e máxima de um intervalo ▫Classe Inválida Valores fora do intervalo
  39. 39. Testes Funcionais – Análise do Valor Limite •Sabendo que cada camada possui 20 cm de altura, quais valores medem os limites das classes? ▫Limão: 0 a 20 cm ▫Baunilha: 20 a 40 cm ▫Maracujá: 40 a 60 cm ▫Morango: 60 a 80 cm ▫Nozes: 80 a 100 cm ▫Chocolate: 100 a 120 cm Válidos Inválidos 0, 20 -1, 21 20, 40 19, 41 40, 60 39, 61 60, 80 59, 81 80, 100 79, 101 100, 120 99, 119
  40. 40. Testes Funcionais – Tabela de Decisão •Avalia causa e efeito. As condições são consideradas falsa e verdadeira •Traça as combinações entre as regras de negócio do sistema e suas possibilidades de operação
  41. 41. Testes Funcionais – Transição de Estado •Avalia a situação do sistema após a troca de estado de uma variável do sistema. •Traça a combinação entre as regras de negócio do sistema e suas possibilidades de estado
  42. 42. Testes Funcionais – Teste de Caso de uso •A preparação dos casos de teste é baseada nas regras de negócio do sistema. •São criados casos positivos e negativos para cobrir cada situação prevista.
  43. 43. Ferramentas – Caixa Preta •Gerência de teste ▫TestLink, HP Quality, etc. •Cadastro de ocorrências ▫RedMine, Mantis, Bugzilla, etc. •Geração de Evidências ▫Texto, Imagem e Vídeo. •Testes Automatizados ▫Selenium IDE, Selenium WebDriver, TestComplete, etc.
  44. 44. Ferramentas – Gerência de Teste •TestLink
  45. 45. Ferramentas – Gerência de Teste •HP Quality Center
  46. 46. Ferramentas – Cadastro de Ocorrências •RedMine
  47. 47. Ferramentas – Cadastro de Ocorrências •Mantis
  48. 48. Ferramentas – Geração de Evidência •Texto ▫Notepad, Gedit, Ferramentas COTS: Pacotes Office ou BrOffice •Imagem ▫PrintScreen, Captura automática, Ferramentas de edição de imagem: Paint, Gimp, Plugins dos browsers, etc. •Vídeo ▫Captura automática do Windows, Plugins dos browsers e outras ferramentas de captura.
  49. 49. •Vídeo •Plugins dos browsers
  50. 50. Ferramentas - Testes Automatizados •Os testes manuais devem ser automatizados quando for executado diversas vezes em diferentes versões do software •Os principais casos de teste a ser automatizados são aqueles que passam por regressão
  51. 51. Ferramentas - Testes Automatizados •Selenium IDE
  52. 52. Selenium WebDriver
  53. 53. TestComplete
  54. 54. Testes Não Funcionais
  55. 55. Testes Não Funcionais •Analisa os aspectos que não estão diretamente baseados nas regras de negócio do software (funcionalidades); •Avalia as medidas quantitativas do software: ▫Verifica: Operacionalidade do sistema (consumo recursos do computador, cliente, servidor, serviço embarcado, etc.) Acessibilidade Performance Usabilidade Confiabilidade, Recuperação, Portabilidade, etc. •Ator: Tester e técnico em infraestrutura
  56. 56. Testes Não Funcionais •Objetivo: ▫Garantir operação do sistema sob condições não ligadas às funcionalidades da aplicação •Métodos ▫Baseado no tipo do teste a ser realizado. ▫Teste de Carga Conforme base de dados ▫Teste de Stress Conforme arquitetura e tipo do sistema: desktop, etc. ▫Teste de Acessibilidade Conforme interface do sistema
  57. 57. Ferramentas – Testes não Funcionais •Consumo dos recursos ▫Gerenciador de tarefas do Windows e do Linux, QuickPerformance, etc. •Performance, Stress e Carga ▫Jmeter, HP Load Runner, etc. •Usabilidade ▫Ethnio Status, UseMonitor, etc. •Acessibilidade ▫ASES, etc.
  58. 58. Ferramentas – Consumo de recursos •QuickPerformance
  59. 59. Ferramentas - Performance •JMeter
  60. 60. Ferramentas - Performance •HP Load Runner
  61. 61. Ferramentas - Usabilidade •Ethnio Status
  62. 62. Ferramentas - Usabilidade •UseMonitor
  63. 63. Ferramentas - Acessibilidade •ASES
  64. 64. Testes Baseados em Erros
  65. 65. Testes Baseados em Erros •Inclui defeitos propositalmente no software para testar seu comportamento; •Necessita das versões: Original (sem defeitos) e Alterada (com defeitos) • Ator: Tester e analista de sistemas
  66. 66. Testes Baseados em Erros •Objetivo: ▫Fornecem indicadores para gerenciar o processo de teste (porcentagem de erros remanescentes, qualidade dos casos de testes) •Métodos ▫Semeadura de Erros ▫Análise de Mutantes
  67. 67. Semeadura de Erros – Como Fazer •Passo 1: ▫Erros artificiais são introduzidos no programa; •Passo 2: ▫Cria-se um caso de uso para identificar falhas naturais e artificiais •Passo 3: ▫Baseados na proporção erros naturais/artificiais pode-se estimar a quantidade de erros remanescentes para o conjunto de casos de teste definidos para o programa. Desta forma pode-se comparar a estimativa de erros remanescentes com a confiabilidade esperada (especificada) para o software.
  68. 68. Semeadura de Erros – Análise de Mutantes •Visa avaliar quão adequado um conjunto de testes é para testar uma funcionalidade. •Passos ▫1 - Gera-se casos de teste (T) para um programa (P); ▫2 - Verifica-se se ele funciona corretamente; ▫3 - Verifica-se o funcionamento do mutante (M) para os casos de teste (T): Caso a verificação de M apresentar resultados diferentes da verificação de P o mutante é “morto” Caso contrário, M continua “vivo” e deve ser analisado; ▫4 - Análise dos mutantes vivos: O mutante M é equivalente ao programa original P O caso de teste é insuficiente para diferenciar M de P e novos casos de teste devem ser definidos
  69. 69. Testes Baseados em Erros – SQL Injection
  70. 70. Referências •Livro - Engenharia de Software, Roger Pressman •Livro – Base de Conhecimento em Teste de Software - Certificação CBTS / ALATS – Anderson Bastos, Emerson Rios, et. al. •Artigos – Rex Black •Syllabus – CTFL / ISTQB •Comunidade de Testes – Site Elias Nogueira •Slides da Qualidade BR – Fabrício de Campos
  71. 71. Dúvidas???
  72. 72. Obrigada!

×