Upload
gabriela-patuci
View
6.528
Download
4
Embed Size (px)
DESCRIPTION
Apresentação utilizada no Agile Brazil 2010 em Porto Alegre.
Citation preview
Automação de Testes: Ferramentas e Aplicação com
Integração Contínua
Gabriela de Oliveira [email protected]
Agile Brazil 2010 – 22 a 25 de Junho
Agenda
Introdução
Por que automatizar?
Quando a automação começa a valer a pena
Tipos de Teste
Ferramentas : Selenium
Ferramentas: Outras opções no mercado
Por que usar a Integração Contínua neste caso?
Agenda
CI: Conceito
Ferramentas : Hudson, Cruise Control
Hudson: Como configurar um projeto?
Dia a dia com CI
Hudson exibindo resultados de testes
Conclusão
Dúvidas
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
Por que automatizar?
• Porque existe muito a ser testado;
• Porque nem todo tipo de teste tem que ser manual;
• Porque se testarmos algo mais simples automaticamente, temos tempo para testes mais complexos (maior cobertura);
Por que automatizar?
• Porque temos que executar testes de regressão;
• Porque testes de fumaça devem ser executados antes da bateria de testes funcionais.
• Porque precisamos executar testes de estresse.
Quando a automação começa valer a pena...
SIM
-Requisito alterado com menor frequência (layout)
-Projetos com mais de 5 sprints (desenvolvimento incremental)
SIM
-Requisito alterado com menor frequência (layout)
-Projetos com mais de 5 sprints (desenvolvimento incremental)
NÃO
-Requisito alterado a todo momento (regravação)
-Projetos de menos de 3-5 sprints (pouco reteste)
NÃO
-Requisito alterado a todo momento (regravação)
-Projetos de menos de 3-5 sprints (pouco reteste)
Tipos de Teste
• Fumaça Consiste em fazer um teste superficial que indica a viabilidade de rodar os demais testes.
• UnitárioFoco em testar caminhos específicos do produto (caixa branca).
• IntegraçãoFoco em combinar as partes do produto e testar as partes em conjunto.
Tipos de Teste
• SistemaVisa garantir que o software funciona corretamente com os demais elementos do sistema.
• RegressãoVisa evitar que defeitos já corrigidos retornem ao produto.
• AceitaçãoFoco em apresentar o produto ao cliente para que o produto seja homologado.
Ferramentas: Selenium
Fumaça, Regressão, Estresse...Selenium – tipo “gravação e reprodução”
• Selenium IDEPlugin para o Firefox , que ajuda a gravar, ver e editar as ações de teste.
• Selenium RCSistema cliente/servidor que permite que você controle o browser local ou remotamente. É com ele que são executados os testes.
• Selenium GRIDFerramenta para executar o Selenium RC em vários servidores ao mesmo tempo. Gerando assim produtividade e diversidade.
Ferramentas: Selenium
Ferramentas: Outras
Nome Site Tecnologia Finalidade
Watir http://watir.com/ webAutomaçã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 eregressão
JMeter http://jakarta.apache.org/ web Testes de desempenho
Tabela disponível em: http://www.opensourcetesting.org/
Por que usar CI nestes casos?
- Execução dos primeiros testes da bateria : Smoke (validação da bateria para início dos testes funcionais)
- Execução de todos os testes automatizados
- Possibilidade de receber resultados por e-mail
- Possibilidade de build noturna
- Métricas de Código: gerar relatórios de métricas de qualidade
- Geração automática de documentação
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.
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.
CI : Ferramentas de Apoio
Servidores de buid automatizadas mais utilizados no mercado: Hudson e Cruise Control.
Hudson (principais características):
• Facilidade de instalação.• Possibilidade de distribuir as builds para múltiplas máquinas.• Publicação de resultados, de testes e acompanhamento do log.• Notificação por email.
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
Passos que podem ser executados no dia a dia de um projeto com CI
• Sempre tenha certeza que o projeto está sendo compilado corretamente e que todos os testes (automatizados) estão sendo executados;
• Converse com o time para saber quando é sua vez de integrar o código;• Sempre mantenha um backup na sua máquina (de um dos dois);• Faça o update do projeto;• Faça novamente a verificação do software e dos testes;• Faça o commit do projeto;• Apague o diretório do projeto da máquina de integração e faça o
checkout;• Faça a última verificação do software e dos testes;
Passo 1
Sempre tenha certeza que o projeto está sendo compilado corretamente e que todos os testes (automatizados) estão sendo executados;
-Por que? A idéia é que o repositório esteja sempre consistente e o mais atualizado o possível.
-Quando? A todo momento, quando alguém faz checkout, o código deve ser executado em perfeito estado.
-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.
Passo 2
Converse com o time para saber quando é sua vez de integrar o código;
-Por que? Imagine se todos pudessem fazer commit a todo tempo?
-Quando? Sempre e a todo o momento... a ordem é: antes de fazer o commit, verificar!
-Como? Que tal um sinalizador? Nós temos a “arara amarela”.
Passo 3
Sempre mantenha um backup na sua máquina (de um dos dois);
- 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)
- Quando? Sempre e a todo código novo. Nunca se sabe quando você vai precisar.
- Como? Simplesmente mantendo o backup.
Passo 4
Faça o update do projeto;
- Por que? Para podermos integrar as alterações feitas pelos pares na máquina que executa as integrações.
- Quando? Toda vez que estiver prestes de fazer um commit de suas alterações.
- Como? Através de comandos CVS que selecionam apenas o que foi alterado desde o último checkout.
Passo 5
Faça novamente a verificação do software e dos testes;
- 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.
- Quando? Toda vez que estiver prestes de fazer um commit de suas alterações.
- Como? Executando a build novamente, seguida dos testes.
Passo 6
Faça o commit.
- Por que? Porque é assim que você une efetivamente suas alteracões ao pacote.
- Quando? Toda vez que estiver prestes a fazer um commit de suas alterações.
- Como? Normalmente, clicando com o botão direito sobre os arquivos e depois na opção “Commit”.
Passo 7
Apague o diretório do projeto que está na máquina de integração e faça o checkout.
- Por que? Porque essa é a única maneira de se assegurar que os próximos possam fazer todo o processo de maneira segura.
- Quando? Depois que o processo de integração terminar.
- Como? Normalmente, clicando no botão direito e na opção “Delete”
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, 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
Conclusão
E então, o que mudou?
- Diminuição dos casos de builds não testáveis.
- Aumento da cobertura de testes.
- Aumento da qualidade (medido pelos bugs em produção).
- Agilidade na integração de códigos
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
Dúvidas?
Obrigada!
Copyright (C) 1995-2009Ci&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