Agile Brazil 2010 – 22 a 25 de Junho
Automação de Testes:
Ferramentas e Aplicação com
Integração Contínua
Gabriela de Oliveira Patuci
[email protected]
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
NÃO
-Requisito alterado
com menor
frequência (layout)
-Requisito alterado a
todo momento
(regravação)
-Projetos com mais de
5 sprints
(desenvolvimento
incremental)
-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ário
Foco em testar caminhos específicos do produto (caixa branca).
• Integração
Foco em combinar as partes do produto e testar as partes em conjunto.
Tipos de Teste
• Sistema
Visa garantir que o software funciona corretamente com os demais
elementos do sistema.
• Regressão
Visa evitar que defeitos já corrigidos retornem ao produto.
• Aceitação
Foco 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 IDE
Plugin para o Firefox , que ajuda a gravar, ver e editar as ações de teste.
• Selenium RC
Sistema cliente/servidor que permite que você controle o browser local
ou remotamente. É com ele que são executados os testes.
• Selenium GRID
Ferramenta 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/
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
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-001090001-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
Obrigada!
Dúvidas?
www.cit.com.br
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.