A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Automação de Testes: Ferramentas e Aplicação com Integração Contínua Gabriela de Oliveira Patuci Agile Brazil 2010 – 22 a 25 de Junho.

Apresentações semelhantes


Apresentação em tema: "Automação de Testes: Ferramentas e Aplicação com Integração Contínua Gabriela de Oliveira Patuci Agile Brazil 2010 – 22 a 25 de Junho."— Transcrição da apresentação:

1 Automação de Testes: Ferramentas e Aplicação com Integração Contínua Gabriela de Oliveira Patuci Agile Brazil 2010 – 22 a 25 de Junho

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

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

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 NomeSiteTecnologiaFinalidade Watir web Automação de testes para páginas Web via programação (Ruby) Marathon JavaTestes de regressão Selenium web Testes Funcionais e regressão JMeter webTestes 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 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: 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: Tabela de ferramentas de automação. Acessado em 12 de abril de 2010, no website da Open Source Testing. Disponível em:

35 Dúvidas? Obrigada!

36

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


Carregar ppt "Automação de Testes: Ferramentas e Aplicação com Integração Contínua Gabriela de Oliveira Patuci Agile Brazil 2010 – 22 a 25 de Junho."

Apresentações semelhantes


Anúncios Google