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

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

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

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);

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)
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á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 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

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: 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-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

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

by Gabriela Patuci on Jun 27, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

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