Validação e Testes de software

1.027 visualizações

Publicada em

Disciplina de Validação e Testes de Software, ministrada na Pós Graduação de Engenharia de Software da Faculdade Vale do Salgado - Icó - Ceará

Publicada em: Software
2 comentários
7 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
1.027
No SlideShare
0
A partir de incorporações
0
Número de incorporações
43
Ações
Compartilhamentos
0
Downloads
59
Comentários
2
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Validação e Testes de software

  1. 1. Validação e Testes de Software Rondinelli Mesquita
  2. 2. About me Rondinelli  Mesquita Developer | Tester | Coffee | Rock •  Sistemas de Informação •  Esp. Desenv. Aplicativos Móveis •  Instituto Atlântico - Fortaleza @rondymesquita rondinellimesquitas@gmail.com rondymesquita.com.br Skills •  Java •  Android •  Javascript •  Automated Tests
  3. 3. Introdução Processo de Teste Nível e Abordagem de Teste Papeis, Ambiente 1 2 3 4
  4. 4. Planejamento Casos de Teste Técnicas Ferramentas 5 6 7 8
  5. 5. Bibliografia Livro Base
  6. 6. https://stocksnap.io/photo/IA7B7S9TSW
  7. 7. O que NÃO é testar “Testar é o processo de demonstrar que os erros não estão presentes”
  8. 8. O que é realmente testar “Testar é o processo de executar o programa com a intenção de encontrar erros” (MYERS, BADGET e SANDLER, 2012)
  9. 9. Perfil de um Tester Demonstrar que existem erros no software e auxiliar equipe na resolução desse erro.
  10. 10. POR QUE TESTAR ?
  11. 11. Regra 10 de Myers Custo da correção de defeitos: Extraído de Bastos; Rios; Cristalli; Moreira (2007)
  12. 12. Redução de defeitos •  Testes unitários podem remover entre 30% e 50% •  Testes sistêmicos podem remover 30% e 50% •  Revisões de códigos podem reduzir entre 20% e 30% •  Mesmo assim, os sistemas podem ir para a produção ainda com aprox. 49% de defeitos Extraído de Bastos; Rios; Cristalli; Moreira (2007)
  13. 13. Ciclo de Vida do Software Um software pode ainda estar rodando mesmo depois de ter sido construído (10 anos…) Riscos? •  Falta de profissional especialista na tecnologia •  Custo de parar o sistema que está rodando para corrigir um erro
  14. 14. Dev Test
  15. 15. Dev Test
  16. 16. “Quanto menos defeitos deixarmos no software, mais barata será sua manutenção” $  
  17. 17. Custo com Qualidade Estimativas de custos de teste. Fonte: Extraído de Bastos; et al(2007)
  18. 18. O teste é iniciado junto com o desenvolvimento!
  19. 19. Scrum Processo Scrum. Fonte: Adaptado de Keith (2010) !
  20. 20. Integração entre processos Integração entre processos. Fonte: Extraído de Bastos; et al (2007)
  21. 21. Mitos “O Tester é inimigo do Desenvolvedor"
  22. 22. Mitos “A equipe de testes pode ser montada com os desenvolvedores menos qualificados, pois qualquer um pode testar sistemas”
  23. 23. Mitos “Quando estiver tudo pronto, o software seguirá para o pessoal fazer o teste.”
  24. 24. Como priorizar? Quais testes são importantes? •  Analisar os riscos e impactos – Requisito: tempo de resposta -> Teste de performance “É necessário ter uma metodologia estruturada de teste”
  25. 25. Verificação x Validação •  Verificação: realizar inspeções sobre os artefatos gerados nas etapas do processo •  Validação: Avaliar se o sistema atende aos requisitos Definições de verificação e validação. Fonte: Extraído de Bastos, et al (2007)
  26. 26. Inspeção de código (verificação) O time inspeciona os artefatos produzidos à procura de possíveis erros. Importante existir um checklist. Conduzindo por um desenvolvedor que não seja o autor do código Ferramentas: PMD e FindBugs (MYERS, BADGET e SANDLER, 2012)
  27. 27. Passo a passo (walkthrough) Geralmente informal, o autor do código apresenta o código para o time e o time faz sugestões. (MYERS, BADGET e SANDLER, 2012)
  28. 28. Processo de Teste https://stocksnap.io/photo/PBTF1NEBCG
  29. 29. Conceito “V” de teste Conceito “V” de teste de software. Fonte: Extraído de Bastos, et al (2007)
  30. 30. Passos do Processo de Teste 1.  Acesso ao Plano de Desenvolvimento 2.  Plano de Testes 3.  Avaliação dos Requisitos do Software 4.  Avaliação do Desenho 5.  Inspeção da Construção do Software 6.  Execução dos Testes 1.  Abordagem 2.  Ferramentas 3.  Tipos de Teste
  31. 31. Passos do Processo de Teste 7.  Teste de Aceitação 8.  Informação dos Resultados 1.  Bugs 2.  Melhorias 9.  Teste de Instalação 10. Teste das Mudanças 11. Avaliação da Eficácia
  32. 32. Ciclo de vida de testes 1.  Planejamento 2.  Preparação 3.  Procedimentos Iniciais 4.  Especificação 5.  Execução 6.  Entrega Ciclo de vida de testes: Adaptado de Bastos, et al (2007)
  33. 33. Modelo 3P x 3E do Ciclo de Vida Modelo 3P x 3E. Fonte: Extraído de Bastos, et al (2007)
  34. 34. https://stocksnap.io/photo/QNFDIZPFN6 Nível de Teste
  35. 35. Nível de Teste de Software •  Representa a que fase do desenvolvimento se aplica um determinado teste. – Teste de Unidade – Teste de Integração – Teste de Sistema (ou sistêmico) – Teste de Aceitação
  36. 36. Teste de Unidade Estágio mais baixo da escala de teste Feito pelos desenvolvedores Testa as classes, métodos, funções, componentes isolando/simulando suas dependências
  37. 37. Teste de Unidade //JUnit Example
 Discipline discipline = new Discipline(); discipline.setName("Prog 1"); discipline.setWorkload(120); Assert.assertEquals("Prog 1", discipline.getName());
  38. 38. Teste de Unidade //JUnit Example
 Calculator  calculator  =  new  Calculator(); calculator.add(1,  2);   Assert.assertEquals(3,  calculator.getResult());
  39. 39. Teste de Integração Teste do sistema ao término de cada iteração. Teste da integração entre os componentes.
  40. 40. Teste de Integração //JUnit Example Discipline discipline = new Discipline(); discipline.setName("Prog 1"); discipline.setWorkload(120); Assert.assertTrue(disciplineApplication.save(discipline));
  41. 41. Teste de Sistema Teste do sistema como um todo depois da integração dos componentes. Utiliza um ambiente parecido ou igual ao ambiente real
  42. 42. Teste de Aceitação Verificar se o software está pronto para ser usado. Verificar o comportamento do software Feito no ambiente de homologação
  43. 43. Abordagem de Teste https://stocksnap.io/photo/16VYGB9PG5
  44. 44. White box Se concentra do comportamento do software sem se deter a sua estrutura interna. Verifica se o programa se comporta de acordo com suas especificações. •  Teste Sistêmico •  Teste de Aceitação (MYERS, BADGET e SANDLER, 2012)
  45. 45. Black Box Testa a estrutura interna, a lógica do software. O critério de busca é o Teste do Caminho, testando os possiveis caminhos que o software pode tomar. •  Teste unitário •  Teste de Integração (MYERS, BADGET e SANDLER, 2012)
  46. 46. https://stocksnap.io/photo/VQXYE2ZEHC Papeis
  47. 47. Papeis do Processo de Teste Papel Responsabilidade Gerente de Teste Responsável pela área de teste na empresa Líder do Projeto de Teste Líder do time de testes Arquiteto de Teste Montagem de Infra- estrutura e ambiente, ferramentas, preparação do time Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)
  48. 48. Papeis do Processo de Teste Papel Responsabilidade Analista de Teste Elaboração dos casos e scripts de teste Testador Execução dos casos de teste e scripts de teste Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)
  49. 49. https://stocksnap.io/photo/DUGHLO7780 Ambiente
  50. 50. Ambiente •  Toda a estrutura onde os testes serão executados – Ambiente físico – Pessoal – Hardware – Software – Suprimentos – Rede – Documentação
  51. 51. Ambiente Ao definirmos o ambiente de teste devemos considerar: •  OS •  Arquitetura do sistema •  Identificação dos componentes •  Meio de acesso ao sistema •  Linguagem de programação •  Conectividade entre ambientes (RIOS e MOREIRA, 2003, apud BASTOS el al., 2007)
  52. 52. https://stocksnap.io/photo/QKNVDENHQP Planejamento e Documentação
  53. 53. Documentação •  Plano de Testes – Planejamento para a execução dos testes, abrangência, abordagem, níveis, ambientes, recursos e técnicas. •  Especificação de Caso de Teste – Define os cenários com entradas, saídas, resultados esperados e condições para a execução.
  54. 54. Plano de Testes •  Descreve quais testes serão executados e como será feita a execução – Escopo – Ambiente – Abordagem – Nível – Técnicas
  55. 55. Plano de Testes – Artefatos liberados – Responsabilidade – Cronograma – Critérios de completude Requisitos do Projeto à Plano de Testes
  56. 56. Brainstorm https://stocksnap.io/photo/84GOP2OAKR
  57. 57. Procedimentos de Teste https://stocksnap.io/photo/84GOP2OAKR
  58. 58. Procedimentos de Teste “…os testes devem ser executados em todas as etapas do ciclo de vida do processo de desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o software para a produção.” (BASTOS el al., 2007)
  59. 59. Procedimentos de Teste •  Plano de teste sempre atualizado. •  Responsabilidades Teste Unitários Feito pelos desenvolvedores Teste de Integração Feito quando os componentes a ser integrados já tiverem seus testes unitários feitos.
  60. 60. Procedimentos de Teste Teste de Sistema –  Ambiente deve se aproximar do ambiente de produção –  Definir quais casos de teste serão empregados nessa fase –  Avaliar os resultados dos testes e identificar problemas encontrados –  Registro de defeitos –  Garantir que usuários finais não encontrem erros grosseiros
  61. 61. Procedimentos de Teste Teste de Aceitação –  Realizado pelos usuários do software para garantir que tudo que foi definido tenha sido de fato implementado.
  62. 62. Procedimentos de Teste Quando parar de testar? •  Métricas – Tempo médio entre defeitos encontrados – Porcentagem de cobertura alcançada – Número de defeitos encontrados que não foram corrigidos dependendo do seu grau de severidade
  63. 63. Procedimentos de Teste Construir casos de teste Executar os testes Registrar os resultados dos testes Identificar a natureza dos problemas e retrabalhar o teste Foram encontra dos defeitos Os testes foram executados corretame nte? Construir casos de teste Ambiente Plano de Teste Softwares de Teste Documen tação Relatórios Fluxo de execução dos testes. Fonte: Adaptado de Bastos, et al (2007)
  64. 64. Casos de Teste User Stories e BDD https://stocksnap.io/photo/84GOP2OAKR
  65. 65. Casos de Teste Detalhamento das interações com a aplicação. Estabelece quais as informações empregadas e os resultados. – Cenários – Pré-condição – Pós-condição – Critério de aceitação
  66. 66. Casos de Teste – Configuração de ambiente – Manual/Automatizada – Dependências Características – Efetivo – Econômico – Reutilizável – Rastreável – Auto-explicativo
  67. 67. Casos de Teste Fluxo de caso de uso. Fonte: Extraído de Bastos, et al (2007)
  68. 68. User Story •  Representa uma funcionalidade/ caracteristica do produto narrada pelo cliente. •  São as necessidades do cliente, mostrando qual problema ele deseja resolver. (COHN, 2004)
  69. 69. User Story Eu, como… (Papel) Eu quero… (Necessidade) Para… (Valor de negócio)
  70. 70. User Story - Exemplo [US_03] Realizar reserva Como um usuário do sistema Eu quero poder realizar a reserva de salas da minha instituição Para facilitar o controle de reservas e evitar atrasos !
  71. 71. BDD Behavior-driven development ou Desenvolvimento Orientado ao Comportamento. Combina ideias do TDD e DDD e Projeto Orientado a Objeto que fornece ao time um processo compartilhado para o desenvolvimento do software (YE, 2013)
  72. 72. BDD •  Linguagem ubiqua – Linguagem natural – Linguagem compartilhada •  Foco no Minimum Markatable Feature •  Valor verificável para o negócio •  Requisitos aliado aos testes •  Baseado naquilo que se espera da aplicação •  Documentação viva
  73. 73. BDD Dado que… (pré-condição) Quando… (ação) Então… (pós-condição)
  74. 74. BDD Dado que… (pré-condição) E… (mais uma pré-condição) Quando… (ação) E… (mais uma ação) Então… (pós-condição) E… (mais uma pós-condição)
  75. 75. Cenário BDD - Exemplo [US_3] Realizar reserva Como um usuário do sistema Eu quero poder realizar a reserva de salas da minha instituição Para facilitar o controle de reservas e evitar atrasos !
  76. 76. Cenário BDD - Exemplo [TC_3.1] Realizar uma reserva com sucesso Dado que eu estou na tela principal E seleciono a opção “Resevas” E preencho o campo “Responsável” E preencho o campo “Sala” E seleciono a data E seleciono a hora Quando eu clico em “Finalizar” Então devo ver a mensagem “Reserva realizada com sucesso”
  77. 77. Brainstorm A saga continua https://stocksnap.io/photo/84GOP2OAKR
  78. 78. Técnicas de Teste https://stocksnap.io/photo/OXTQKWK4EJ
  79. 79. Técnicas de Teste •  Estrutural – Garantir que o software é sólido. Relacionados as características do software. •  Funcional – Garantir que o software atende aos requisitos.
  80. 80. https://unsplash.com/levisaunders Estrutural
  81. 81. https://stocksnap.io/photo/08770132A3 Estresse
  82. 82. Estrutural – Teste de Estresse Avalia o software sob condições críticas. •  Restrição de Memória •  Processamento •  Armazenamento •  Volume de Dados •  Tempo de Transação
  83. 83. Estrutural – Teste de Estresse Objetivos •  Determinar que a aplicacao suporta volume de transação normal ou acima do normal num periodo de tempo esperado •  Determinar que a aplicação suporta volume normal e continua a funcionar corretamente Comuns em aplicações web
  84. 84. https://stocksnap.io/photo/LNYEQYRA6G Execução
  85. 85. Estrutural – Teste de Execução Avalia o tempo de resposta, de processamento e desempenho. •  Tempo de resposta das transações
  86. 86. Estrutural – Teste de Execução Objetivos •  Determinar o tempo de resposta das transações •  Determinar se hardware e software fornecem capacidade adequada •  Código é executado com eficácia
  87. 87. https://stocksnap.io/photo/A129A7D04F Recuperação
  88. 88. Estrutural – Teste de Recuperação •  Capacidade de reiniciar operacoes após a perda de integridade. •  Garantir a continuidade das operações após um erro. – Fatores •  Volume de dados processados no momento do erro
  89. 89. Estrutural – Teste de Recuperação Objetivos – Verifica a eficácia e eficiência o processo de recuperação – Backup – Documentar procedimentos de recuperação
  90. 90. https://stocksnap.io/photo/4B29F3D6ED Operação
  91. 91. Estrutural – Teste de Operação Objetivos – Estabelecer se o sistema é executável durante a operação normal – Se os utilizadores do sistema conseguem utilizar-lo, utilizando a documentação preparada. – Os utilizadores devem testar sem ajuda nenhuma
  92. 92. https://stocksnap.io/photo/D5E363D0E7 Conformidade
  93. 93. Estrutural – Teste de Conformidade •  Verifica se a aplicação foi desenvolvida de acordo com os padrões de TI – Aumentar as chances de sucesso – Transferência de conhecimento e curva de aprendizado – Manutenibilidade
  94. 94. Estrutural – Teste de Conformidade Objetivos – Padrões de TI estão sendo seguidos e de forma adequada – Avalidar documentação – Falta de conformidade foi falta de comunicação? Problema no processo? Padrões mal entendidos?
  95. 95. https://stocksnap.io/photo/AD76394B17 Segurança
  96. 96. Estrutural – Teste de Segurança •  Verificar a confidencialidade das informações e proteção dos dados contra acesso indevido. – Segurança da Informação – Defeitos difíceis de indentificar
  97. 97. Estrutural – Teste de Segurança Objetivos – Riscos? •  Determinar as regras de acesso e se foram implementadas de acordo com as definições •  Verificar se as medidas de segurança foram corretamente implementadas – Riscos baixos, tecnicas de invasão usual: •  Pode-se realizar os testes – Riscos altos, técnicas de invasão sofisticadas: •  Testes conduzidos por pessoal especializado
  98. 98. https://stocksnap.io/photo/E2C541A7DC Funcional
  99. 99. https://stocksnap.io/photo/AD76394B17 Requisitos
  100. 100. Funcional – Teste de Requisitos Objetivos – Verificar se o sistema faz o que está especificado nos requisitos. – Verificação do comportamento do sistema – Checklist de funcionalidades – Normalmente os testes são preparados na fase de requisitos
  101. 101. http://pixabay.com/en/road-sign-roadsign-traffic-turning-145153/ Regressão
  102. 102. Funcional – Teste de Regressão •  Voltar a testar componentes já testados após implementação de uma mudança em outra parte do software Objetivos – Determinar se a funções previamente testadas continuam funcionando após a introdução de mudanças no sistema
  103. 103. Funcional – Teste de Regressão Riscos –  Tempo e custo •  Automação de Testes Quando usar? Quando os riscos de mudança do software são altos
  104. 104. http://pixabay.com/en/stop-shield-traffic-sign-road-sign-634941/ Tratamento de Erros
  105. 105. Funcional – Teste de Tratamento de Erros •  Verificar a capadicade do sistema de tratar transações incorretas Objetivos – Determinar as condições de erro e tratá-los – Testar o erro e o acerto
  106. 106. https://stocksnap.io/photo/56A1C1BE07 Interconexão
  107. 107. Funcional – Teste de Interconexão •  Verificar a conectividade do software com outros softwares – Sejam dados recebidos ou fornecidos Objetivos – Verificar se os dados são recebidos e/ou enviados corretamente – Executar quando as entradas e saídas dos softwares relacionados mudarem
  108. 108. https://stocksnap.io/photo/WBDINSMDFO Paralelos
  109. 109. Funcional – Teste Paralelo •  Teste de compatibilidade. Demonstrar consistência e cincosistências entre versões do mesmo software •  Mesmos dados de entrada funcionem em software de diferentes versões
  110. 110. Gestão de Defeitos https://stocksnap.io/photo/AC169E486A
  111. 111. Gestão de defeitos •  Prevenção de defeitos •  Baselines •  Identificação •  Registro •  Solução do defeitos •  Melhoria do processo •  Relatório de gestão (BASTOS et al., 2007)
  112. 112. Gestão de defeitos Jira
  113. 113. Gestão de defeitos
  114. 114. Ferramentas https://stocksnap.io/photo/5304C4F098
  115. 115. Teste de Unidade @Test public void sumTwoNumbers() { Calculator calculator = new Calculator(); calculator.add(1, 2); Assert.assertEquals(calculator.getResult(), 3); } http://junit.org
  116. 116. Teste de Unidade •  Ruby – Rspec: http://rspec.info •  .Net – Nunit: http://www.nunit.org
  117. 117. Teste Funcional Selenium Testes Automatizados de aplicações web.
  118. 118. Teste Funcional •  Selenium: http://www.seleniumhq.org – Java – C# – Ruby – Python – JS(Node) •  Ruby – Capybara: http://jnicklas.github.io/capybara/
  119. 119. Teste Funcional @Test public void doBingSearch() { WebDriver driver = new FirefoxDriver(); driver.get("http://www.bing.com"); WebElement searchField = driver.findElement(By.id("sb_form_q")); searchField.sendKeys("Transformers"); driver.findElement(By.id("sb_form_go")).click(); driver.getPageSource().contains("Imagens de transformers"); }
  120. 120. Teste Funcional •  Calabash: http://calaba.sh – Android – IOS •  Selendroid: http://selendroid.io – Android
  121. 121. Teste de Desempenho •  Realiza testes de desempenho em aplicações web, webservices e páginas dinâmicas
  122. 122. 122   Meu software está rodando… Mas o meu tem testes!
  123. 123. Certificação de Testes https://stocksnap.io/photo/DB7F22291B
  124. 124. CBTS Certificação Brasileira de Teste de Software Criada pela ALATS (Associação Latino Americana de Teste de Software), procura estabelecer um padrão de conformidade para avaliação da qualificação dos profissionais da área da qualidade do software.
  125. 125. CBTS Certificação Brasileira de Teste de Software Criada pela ALATS (Associação Latino Americana de Teste de Software), procura estabelecer um padrão de conformidade para avaliação da qualificação dos profissionais da área da qualidade do software.
  126. 126. E... https://stocksnap.io/photo/2E7892A6E4
  127. 127. Livros recomendados sd
  128. 128. Livros recomendados sd
  129. 129. Livros recomendados sd
  130. 130. Livros recomendados sd
  131. 131. Links •  http://behaviourdriven.org •  http://dannorth.net/introducing-bdd/ •  http://tableless.com.br/introducao-ao-behavior- driven-development/ •  http://junit.org •  http://www.seleniumhq.org •  https://www.atlassian.com/software/jira •  http://www.alats.org.br/portal/home.html
  132. 132. Links •  http://aprendendotestar.webs.com •  http://qualidade-de-software.blogspot.com.br •  http://www.bstqb.org.br •  http://guts-rs.blogspot.com.br •  http://www.qualister.com.br •  https://www.youtube.com/user/guru99com •  https://github.com/rondymesquita •  http://rondymesquita.com.br
  133. 133. About me Rondinelli  Mesquita @rondymesquita rondinellimesquitas@gmail.com rondymesquita.com.br
  134. 134. Bibliografia •  BASTOS, Aderson, at al. Base de conhecimento em teste de software. 2. ed. rev. São Paulo: Martins, 2007. •  MYERS, Glenford J.; BADGET, Tom; SANDLER, Corey. The art of software testing. 3. ed. Wiley, 2012. •  WATKINS, John. Agile testing: how to succeed an extreme testing environment. Cambridge, 2009. •  YE, Wayne. Cucumber BDD how-to: A short guide to mastering behavior-driven software development with cucumber. Packt Publishing, 2013.
  135. 135. Bibliografia •  KEITH, Clinton. Agile game development with scrum. Addison-Wesley, 2010. •  COHN, Mike. User stories applied: for agile software development. Addison-Wesley, 2004.
  136. 136. Imagens Imagens extraídas de stocksnap.io. Capa: https://stocksnap.io/photo/F164KBFZ95
  137. 137. Obrigado! :D

×