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

Apresentação em tema: "Automação de Testes: Ferramentas e Aplicação com Integração Contínua"— Transcrição da apresentação:

1 Automação de Testes: Ferramentas e Aplicação com Integração Contínua
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 1

2 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?

3 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

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

6 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.

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

8 Tipos de Teste Fumaça Integração
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.

9 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.

10 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.

11 Ferramentas: Selenium

12 Ferramentas: Outras Nome Site Tecnologia Finalidade Watir
web Automação de testes para páginas Web via programação (Ruby) Marathon Java Testes de regressão Selenium Testes Funcionais e regressão JMeter Testes de desempenho Tabela disponível em:

13 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 Possibilidade de build noturna Métricas de Código: gerar relatórios de métricas de qualidade Geração automática de documentação

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

17 Hudson : Configuração Painel Principal

18 Informações do Projeto
Hudson: Configuração Informações do Projeto

19 Hudson : Configuração Configuração do Projeto

20 Hudson: Configuração Configuração do Projeto

21 Hudson: Configuração Configuração do Projeto

22 Hudson: Histórico Revisões e Mudanças

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

24 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.

25 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”.

26 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.

27 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.

28 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.

29 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”.

30 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”

31 Passo 8 Faça a última verificação do software e dos testes;
Sua integração finalmente terminou! Parabéns!

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 avisando - Crie um alias para receber estes alerts e insira o código junto com o da build

33 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

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: 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: Leão. D.S. (2008). Práticas de Integração. Acessado em 30 de maio de 2010, no website ImproveIT. Disponível em: Tabela de ferramentas de automação. Acessado em 12 de abril de 2010, no website da Open Source Testing. Disponível em:

35 Obrigada! Dúvidas?

36

37 Ci&T Software S.A. – Todos os direitos reservados.
Copyright (C) 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. 37