Validação e Testes de software
•
11 likes•2,808 views
O documento discute validação e testes de software, abordando tópicos como: 1) Os diferentes níveis de teste (unidade, integração, sistema e aceitação); 2) As abordagens de teste (caixa preta e caixa branca); 3) Os principais papéis no processo de teste (gerente de teste, líder de projeto de teste, etc); 4) A importância da documentação no planejamento e execução dos testes.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Validação e Testes de software
Similar to Validação e Testes de software (20)
Validação e Testes de software
- 1. Validação e Testes de Software Rondinelli Mesquita
- 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. Introdução Processo de Teste Nível e Abordagem de Teste Papeis, Ambiente 1 2 3 4
- 7. O que NÃO é testar “Testar é o processo de demonstrar que os erros não estão presentes”
- 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. Perfil de um Tester Demonstrar que existem erros no software e auxiliar equipe na resolução desse erro.
- 10. POR QUE TESTAR ?
- 11. Regra 10 de Myers Custo da correção de defeitos: Extraído de Bastos; Rios; Cristalli; Moreira (2007)
- 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. 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. Dev Test
- 15. Dev Test
- 16. “Quanto menos defeitos deixarmos no software, mais barata será sua manutenção” $
- 17. Custo com Qualidade Estimativas de custos de teste. Fonte: Extraído de Bastos; et al(2007)
- 18. O teste é iniciado junto com o desenvolvimento!
- 19. Scrum Processo Scrum. Fonte: Adaptado de Keith (2010) !
- 20. Integração entre processos Integração entre processos. Fonte: Extraído de Bastos; et al (2007)
- 21. Mitos “O Tester é inimigo do Desenvolvedor"
- 22. Mitos “A equipe de testes pode ser montada com os desenvolvedores menos qualificados, pois qualquer um pode testar sistemas”
- 23. Mitos “Quando estiver tudo pronto, o software seguirá para o pessoal fazer o teste.”
- 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. 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. 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. 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)
- 29. Conceito “V” de teste Conceito “V” de teste de software. Fonte: Extraído de Bastos, et al (2007)
- 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. 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. 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. Modelo 3P x 3E do Ciclo de Vida Modelo 3P x 3E. Fonte: Extraído de Bastos, et al (2007)
- 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. 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. Teste de Unidade //JUnit Example Discipline discipline = new Discipline(); discipline.setName("Prog 1"); discipline.setWorkload(120); Assert.assertEquals("Prog 1", discipline.getName());
- 38. Teste de Unidade //JUnit Example Calculator calculator = new Calculator(); calculator.add(1, 2); Assert.assertEquals(3, calculator.getResult());
- 39. Teste de Integração Teste do sistema ao término de cada iteração. Teste da integração entre os componentes.
- 40. Teste de Integração //JUnit Example Discipline discipline = new Discipline(); discipline.setName("Prog 1"); discipline.setWorkload(120); Assert.assertTrue(disciplineApplication.save(discipline));
- 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. Teste de Aceitação Verificar se o software está pronto para ser usado. Verificar o comportamento do software Feito no ambiente de homologação
- 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. 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)
- 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. 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)
- 50. Ambiente • Toda a estrutura onde os testes serão executados – Ambiente físico – Pessoal – Hardware – Software – Suprimentos – Rede – Documentação
- 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)
- 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. Plano de Testes • Descreve quais testes serão executados e como será feita a execução – Escopo – Ambiente – Abordagem – Nível – Técnicas
- 55. Plano de Testes – Artefatos liberados – Responsabilidade – Cronograma – Critérios de completude Requisitos do Projeto à Plano de Testes
- 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. 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. 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. 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. 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. 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. Casos de Teste User Stories e BDD https://stocksnap.io/photo/84GOP2OAKR
- 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. Casos de Teste – Configuração de ambiente – Manual/Automatizada – Dependências Características – Efetivo – Econômico – Reutilizável – Rastreável – Auto-explicativo
- 67. Casos de Teste Fluxo de caso de uso. Fonte: Extraído de Bastos, et al (2007)
- 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. User Story Eu, como… (Papel) Eu quero… (Necessidade) Para… (Valor de negócio)
- 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. 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. 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. BDD Dado que… (pré-condição) Quando… (ação) Então… (pós-condição)
- 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. 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. 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”
- 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.
- 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. 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
- 85. Estrutural – Teste de Execução Avalia o tempo de resposta, de processamento e desempenho. • Tempo de resposta das transações
- 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
- 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. Estrutural – Teste de Recuperação Objetivos – Verifica a eficácia e eficiência o processo de recuperação – Backup – Documentar procedimentos de recuperação
- 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
- 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. 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?
- 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. 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
- 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
- 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. 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
- 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
- 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
- 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
- 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)
- 113. Gestão de defeitos
- 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. Teste de Unidade • Ruby – Rspec: http://rspec.info • .Net – Nunit: http://www.nunit.org
- 117. Teste Funcional Selenium Testes Automatizados de aplicações web.
- 118. Teste Funcional • Selenium: http://www.seleniumhq.org – Java – C# – Ruby – Python – JS(Node) • Ruby – Capybara: http://jnicklas.github.io/capybara/
- 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. Teste Funcional • Calabash: http://calaba.sh – Android – IOS • Selendroid: http://selendroid.io – Android
- 121. Teste de Desempenho • Realiza testes de desempenho em aplicações web, webservices e páginas dinâmicas
- 122. 122 Meu software está rodando… Mas o meu tem testes!
- 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. 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.
- 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. 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
- 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. Bibliografia • KEITH, Clinton. Agile game development with scrum. Addison-Wesley, 2010. • COHN, Mike. User stories applied: for agile software development. Addison-Wesley, 2004.
- 136. Imagens Imagens extraídas de stocksnap.io. Capa: https://stocksnap.io/photo/F164KBFZ95
- 137. Obrigado! :D