Automação de Testes: Ferramentas e Aplicação com Integração Contínua Gabriela de Oliveira Patuci [email_address] Agile Bra...
<ul><ul><li>Agenda  </li></ul></ul><ul><ul><li>Introdução </li></ul></ul><ul><ul><li>Por que automatizar? </li></ul></ul><...
<ul><ul><li>Agenda  </li></ul></ul><ul><ul><li>CI: Conceito </li></ul></ul><ul><ul><li>Ferramentas :  Hudson, Cruise Contr...
Introdução “ A clever person solves a problem. A wise person avoids it. ”  Albert Einstein  -- “ Bugs will appear in one p...
Por que automatizar? <ul><li>Porque existe muito a ser testado; </li></ul><ul><li>Porque nem todo tipo de teste tem que se...
Por que automatizar? <ul><li>Porque temos que executar testes de regressão; </li></ul><ul><li>Porque testes de fumaça deve...
Quando a automação começa  valer a pena... <ul><li>SIM </li></ul><ul><li>Requisito alterado com menor frequência ( layout ...
Tipos de Teste <ul><li>Fumaça  </li></ul><ul><li>Consiste em fazer um teste superficial que indica a viabilidade de rodar ...
Tipos de Teste <ul><li>Sistema </li></ul><ul><li>Visa garantir que o  software  funciona corretamente com os demais elemen...
Ferramentas:  Selenium <ul><li>Fumaça, Regressão, Estresse... </li></ul><ul><li>Selenium  – tipo “gravação e reprodução” <...
Ferramentas:  Selenium
Ferramentas: Outras Tabela disponível em: http://www.opensourcetesting.org/ Nome Site Tecnologia Finalidade Watir http://w...
Por que usar  CI  nestes casos? <ul><li>Execução dos primeiros testes da bateria :  Smoke   </li></ul><ul><li>(validação d...
CI  : Conceito Se uma nova funcionalidade é adicionada a um sistema que já funcionava bem (e já estava testado), sempre ex...
CI  : Conceito Sempre que um dos pares integra seu código, a ferramenta de integração contínua executa todos os testes aut...
CI  : Ferramentas de Apoio <ul><li>Servidores de  buid  automatizadas mais utilizados no mercado:  </li></ul><ul><li>Hudso...
Hudson : Configuração Painel Principal
Hudson: Configuração Informações do Projeto
Hudson : Configuração Configuração do Projeto
Hudson: Configuração Configuração do Projeto
Hudson: Configuração Configuração do Projeto
Hudson: Histórico Revisões e Mudanças
CI: Passo a passo <ul><li>Passos que podem ser executados no dia a dia de um projeto com  CI   </li></ul><ul><li>Sempre te...
Passo 1 <ul><li>Sempre tenha certeza que o projeto está sendo compilado corretamente e que todos os testes (automatizados)...
Passo 2 <ul><li>Converse com o time para saber quando é sua vez de integrar o código; </li></ul><ul><li>Por que? Imagine s...
Passo 3 <ul><li>Sempre mantenha um  backup  na sua máquina (de um dos dois);  </li></ul><ul><li>Por que? Sempre existem ri...
Passo 4 <ul><li>Faça o  update  do projeto; </li></ul><ul><li>Por que? Para podermos integrar as alterações feitas pelos p...
Passo 5 <ul><li>Faça novamente a verificação do  software  e dos testes;  </li></ul><ul><li>Por que? Porque neste momento ...
Passo 6 <ul><li>Faça o  commit .  </li></ul><ul><li>Por que? Porque é assim que você une efetivamente suas alteracões ao p...
Passo 7 <ul><li>Apague o diretório do projeto que está na máquina de integração e faça o  checkout .  </li></ul><ul><li>Po...
Passo 8 Faça a última verificação do  software  e dos testes; Sua integração finalmente terminou!  Parabéns!
Resultados de Testes (Hudson) Script  (feito dentro do código que gera a  build ) - Depois da execução dos unitários, envi...
Conclusão <ul><li>E então, o que mudou? </li></ul><ul><li>- Diminuição dos casos de  builds  não testáveis.  </li></ul><ul...
Referências Murta, L.G.P. (2009).  Verificação, Validação e Testes . Acessado em 12 de junho de 2010, no website do IC (In...
<ul><ul><li>Dúvidas? </li></ul></ul><ul><ul><li>Obrigada! </li></ul></ul>
 
Copyright (C) 1995-2009 Ci&T Software S.A. – Todos os direitos reservados. Todos os nomes e produtos são usados apenas com...
Próximos SlideShares
Carregando em…5
×

Automação de Testes: Ferramentas e Aplicação com Integração Contínua

8.319 visualizações

Publicada em

Apresentação utilizada no Agile Brazil 2010 em Porto Alegre.

Publicada em: Tecnologia, Negócios
  • Seja o primeiro a comentar

Automação de Testes: Ferramentas e Aplicação com Integração Contínua

  1. 1. Automação de Testes: Ferramentas e Aplicação com Integração Contínua Gabriela de Oliveira Patuci [email_address] Agile Brazil 2010 – 22 a 25 de Junho
  2. 2. <ul><ul><li>Agenda </li></ul></ul><ul><ul><li>Introdução </li></ul></ul><ul><ul><li>Por que automatizar? </li></ul></ul><ul><ul><li>Quando a automação começa a valer a pena </li></ul></ul><ul><ul><li>Tipos de Teste </li></ul></ul><ul><ul><li>Ferramentas : Selenium </li></ul></ul><ul><ul><li>Ferramentas: Outras opções no mercado </li></ul></ul><ul><ul><li>Por que usar a Integração Contínua neste caso? </li></ul></ul>
  3. 3. <ul><ul><li>Agenda </li></ul></ul><ul><ul><li>CI: Conceito </li></ul></ul><ul><ul><li>Ferramentas : Hudson, Cruise Control </li></ul></ul><ul><ul><li>Hudson: Como configurar um projeto? </li></ul></ul><ul><ul><li>Dia a dia com CI </li></ul></ul><ul><ul><li>Hudson exibindo resultados de testes </li></ul></ul><ul><ul><li>Conclusão </li></ul></ul><ul><ul><li>Dúvidas </li></ul></ul>
  4. 4. Introdução “ A clever person solves a problem. A wise person avoids it. ” Albert Einstein -- “ Bugs will appear in one part of a working program immediately after an 'unrelated' part of the program is modified.” Murphy -- “ Nothing is foolproof. Fools are just too darn clever.” anonymous
  5. 5. Por que automatizar? <ul><li>Porque existe muito a ser testado; </li></ul><ul><li>Porque nem todo tipo de teste tem que ser manual; </li></ul><ul><li>Porque se testarmos algo mais simples automaticamente, temos tempo para testes mais complexos (maior cobertura); </li></ul>
  6. 6. Por que automatizar? <ul><li>Porque temos que executar testes de regressão; </li></ul><ul><li>Porque testes de fumaça devem ser executados antes da bateria de testes funcionais. </li></ul><ul><li>Porque precisamos executar testes de estresse. </li></ul>
  7. 7. Quando a automação começa valer a pena... <ul><li>SIM </li></ul><ul><li>Requisito alterado com menor frequência ( layout ) </li></ul><ul><li>Projetos com mais de 5 sprints (desenvolvimento incremental) </li></ul><ul><li>NÃO </li></ul><ul><li>Requisito alterado a todo momento (regravação) </li></ul><ul><li>Projetos de menos de 3-5 sprints (pouco reteste) </li></ul>
  8. 8. Tipos de Teste <ul><li>Fumaça </li></ul><ul><li>Consiste em fazer um teste superficial que indica a viabilidade de rodar os demais testes. </li></ul><ul><li>Unitário </li></ul><ul><li>Foco em testar caminhos específicos do produto (caixa branca). </li></ul><ul><li>Integração </li></ul><ul><li>Foco em combinar as partes do produto e testar as partes em conjunto. </li></ul>
  9. 9. Tipos de Teste <ul><li>Sistema </li></ul><ul><li>Visa garantir que o software funciona corretamente com os demais elementos do sistema. </li></ul><ul><li>Regressão </li></ul><ul><li>Visa evitar que defeitos já corrigidos retornem ao produto. </li></ul><ul><li>Aceitação </li></ul><ul><li>Foco em apresentar o produto ao cliente para que o produto seja homologado. </li></ul>
  10. 10. Ferramentas: Selenium <ul><li>Fumaça, Regressão, Estresse... </li></ul><ul><li>Selenium – tipo “gravação e reprodução” </li></ul><ul><li>Selenium IDE </li></ul><ul><li>Plugin para o Firefox , que ajuda a gravar, ver e editar as ações de teste. </li></ul><ul><li>Selenium RC </li></ul><ul><li>Sistema cliente/servidor que permite que você controle o browser local ou remotamente. É com ele que são executados os testes. </li></ul><ul><li>Selenium GRID </li></ul><ul><li>Ferramenta para executar o Selenium RC em vários servidores ao mesmo tempo. Gerando assim produtividade e diversidade. </li></ul>
  11. 11. Ferramentas: Selenium
  12. 12. Ferramentas: Outras Tabela disponível em: http://www.opensourcetesting.org/ Nome Site Tecnologia Finalidade Watir http://watir.com/ web Automação de testes para páginas Web via programação (Ruby) Marathon http://www.marathontesting.com/ Java Testes de regressão Selenium http://seleniumhq.org/ web Testes Funcionais e regressão JMeter http://jakarta.apache.org/ web Testes de desempenho
  13. 13. Por que usar CI nestes casos? <ul><li>Execução dos primeiros testes da bateria : Smoke </li></ul><ul><li>(validação da bateria para início dos testes funcionais) </li></ul><ul><li>Execução de todos os testes automatizados </li></ul><ul><li>Possibilidade de receber resultados por e-mail </li></ul><ul><li>Possibilidade de build noturna </li></ul><ul><li>Métricas de Código: gerar relatórios de métricas de qualidade </li></ul><ul><li>Geração automática de documentação </li></ul>
  14. 14. CI : Conceito Se uma nova funcionalidade é adicionada a um sistema que já funcionava bem (e já estava testado), sempre existe a possibilidade desta afetar as outras. Uma boa maneira de assegurar que tanto esta funcionalidade, como todo o resto do sistema esteja funcionando de forma harmoniosa, é que as equipes utilizem uma prática cada vez mais comum no mercado de TI: a integração contínua. Ela consiste em pares integrando seus códigos com o restante do sistema diversas vezes ao dia.
  15. 15. CI : Conceito Sempre que um dos pares integra seu código, a ferramenta de integração contínua executa todos os testes automatizados programados para aquela build e assim, assegura que a integração ocorreu como programado e satisfatoriamente. Toda nova integração pode gerar erros no código/sistema. Exatamente por isso, as equipes utilizam esta prática de testes para localizar eventuais bugs, para que a correção seja o mais precoce possível.
  16. 16. CI : Ferramentas de Apoio <ul><li>Servidores de buid automatizadas mais utilizados no mercado: </li></ul><ul><li>Hudson e Cruise Control . </li></ul><ul><li>Hudson (principais características): </li></ul><ul><li>Facilidade de instalação. </li></ul><ul><li>Possibilidade de distribuir as builds para múltiplas máquinas. </li></ul><ul><li>Publicação de resultados, de testes e acompanhamento do log. </li></ul><ul><li>Notificação por email. </li></ul>
  17. 17. Hudson : Configuração Painel Principal
  18. 18. Hudson: Configuração Informações do Projeto
  19. 19. Hudson : Configuração Configuração do Projeto
  20. 20. Hudson: Configuração Configuração do Projeto
  21. 21. Hudson: Configuração Configuração do Projeto
  22. 22. Hudson: Histórico Revisões e Mudanças
  23. 23. CI: Passo a passo <ul><li>Passos que podem ser executados no dia a dia de um projeto com CI </li></ul><ul><li>Sempre tenha certeza que o projeto está sendo compilado corretamente e que todos os testes (automatizados) estão sendo executados; </li></ul><ul><li>Converse com o time para saber quando é sua vez de integrar o código; </li></ul><ul><li>Sempre mantenha um backup na sua máquina (de um dos dois); </li></ul><ul><li>Faça o update do projeto; </li></ul><ul><li>Faça novamente a verificação do software e dos testes; </li></ul><ul><li>Faça o commit do projeto; </li></ul><ul><li>Apague o diretório do projeto da máquina de integração e faça o checkout ; </li></ul><ul><li>Faça a última verificação do software e dos testes; </li></ul>
  24. 24. Passo 1 <ul><li>Sempre tenha certeza que o projeto está sendo compilado corretamente e que todos os testes (automatizados) estão sendo executados; </li></ul><ul><li>Por que? A idéia é que o repositório esteja sempre consistente e o mais atualizado o possível. </li></ul><ul><li>Quando? A todo momento, quando alguém faz checkout , o código deve ser executado em perfeito estado. </li></ul><ul><li>Como? Sempre que alguém integrar seu código a build , deve se assegurar de rodar todos os testes e saber que tudo correu bem. </li></ul>
  25. 25. Passo 2 <ul><li>Converse com o time para saber quando é sua vez de integrar o código; </li></ul><ul><li>Por que? Imagine se todos pudessem fazer commit a todo tempo? </li></ul><ul><li>Quando? Sempre e a todo o momento... a ordem é: antes de fazer o commit , verificar! </li></ul><ul><li>Como? Que tal um sinalizador? </li></ul><ul><li>Nós temos a “arara amarela”. </li></ul>
  26. 26. Passo 3 <ul><li>Sempre mantenha um backup na sua máquina (de um dos dois); </li></ul><ul><li>Por que? Sempre existem riscos. Um usuário pode tentar rodar a build e ela apresentar problemas (nem sempre a solução será rápida) </li></ul><ul><li>Quando? Sempre e a todo código novo. Nunca se sabe quando você vai precisar. </li></ul><ul><li>Como? Simplesmente mantendo o backup . </li></ul>
  27. 27. Passo 4 <ul><li>Faça o update do projeto; </li></ul><ul><li>Por que? Para podermos integrar as alterações feitas pelos pares na máquina que executa as integrações. </li></ul><ul><li>Quando? Toda vez que estiver prestes de fazer um commit de suas alterações. </li></ul><ul><li>Como? Através de comandos CVS que selecionam apenas o que foi alterado desde o último checkout . </li></ul>
  28. 28. Passo 5 <ul><li>Faça novamente a verificação do software e dos testes; </li></ul><ul><li>Por que? Porque neste momento você já poderá perceber que o código novo “quebrou” (ou não) aquilo que o time já tinha compilado. </li></ul><ul><li>Quando? Toda vez que estiver prestes de fazer um commit de suas alterações. </li></ul><ul><li>Como? Executando a build novamente, seguida dos testes. </li></ul>
  29. 29. Passo 6 <ul><li>Faça o commit . </li></ul><ul><li>Por que? Porque é assim que você une efetivamente suas alteracões ao pacote. </li></ul><ul><li>Quando? Toda vez que estiver prestes a fazer um commit de suas alterações. </li></ul><ul><li>Como? Normalmente, clicando com o botão direito sobre os arquivos e depois na opção “ Commit ”. </li></ul>
  30. 30. Passo 7 <ul><li>Apague o diretório do projeto que está na máquina de integração e faça o checkout . </li></ul><ul><li>Por que? Porque essa é a única maneira de se assegurar que os próximos possam fazer todo o processo de maneira segura. </li></ul><ul><li>Quando? Depois que o processo de integração terminar. </li></ul><ul><li>Como? Normalmente, clicando no botão direito e na opção “Delete” </li></ul>
  31. 31. Passo 8 Faça a última verificação do software e dos testes; Sua integração finalmente terminou! Parabéns!
  32. 32. Resultados de Testes (Hudson) Script (feito dentro do código que gera a build ) - Depois da execução dos unitários, envia resultados - Se um dos testes unitários falha, envia um e-mail avisando - Crie um alias para receber estes alerts e insira o código junto com o da build
  33. 33. Conclusão <ul><li>E então, o que mudou? </li></ul><ul><li>- Diminuição dos casos de builds não testáveis. </li></ul><ul><li>- Aumento da cobertura de testes. </li></ul><ul><li>- Aumento da qualidade (medido pelos bugs em produção). </li></ul><ul><li>- Agilidade na integração de códigos </li></ul>
  34. 34. Referências Murta, L.G.P. (2009). Verificação, Validação e Testes . Acessado em 12 de junho de 2010, no website do IC (Instituto de Computação da Unicamp). Disponível em: http://www.ic.uff.br/~leomurta/courses/2009.2/es2/aula5.pdf Godoy, G.L. (2009). Integração Contínua com Hudson . Acessado em 09 de junho de 2010, no website do evento SPIN Campinas. Disponível em: http://www.cpqd.com.br/spin-cps/images/Apresentacoes/reuni%E3o39_apst-hst-001-090001-eventospin.pdf Leão. D.S. (2008). Práticas de Integração . Acessado em 30 de maio de 2010, no website ImproveIT. Disponível em: http://improveit.com.br/xp/praticas/integracao Tabela de ferramentas de automação. Acessado em 12 de abril de 2010, no website da Open Source Testing. Disponível em: http://opensourcetesting.org
  35. 35. <ul><ul><li>Dúvidas? </li></ul></ul><ul><ul><li>Obrigada! </li></ul></ul>
  36. 37. Copyright (C) 1995-2009 Ci&T Software S.A. – Todos os direitos reservados. Todos os nomes e produtos são usados apenas com o propósito de identificação e são marcas registradas de seus respectivos proprietários. www.cit.com.br

×