Automação de Testes: Ferramentas e Aplicação com Integração Contínua
Integração Contínua
-
Upload
scrumhalf-gpe -
Category
Technology
-
view
301 -
download
4
description
Transcript of Integração Contínua
![Page 1: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/1.jpg)
Integração ContínuaEster Lima de Campos
Projeto Capacitar – GPESetembro 2011
![Page 2: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/2.jpg)
Realidade
• Estranho, mas comum… – Que por um longo tempo, durante o processo de
desenvolvimento, a aplicação não está funcional.
• A Razão? É fácil de entender…– Ninguém tenta usar a aplicação como se esta
estivesse no ambiente de produção.
![Page 3: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/3.jpg)
Realidade, ainda…
• A maioria dos projetos agenda fases para integração ao final do desenvolvimento
– Tempo para Integração pode ser extremamente longo.
– Não há como prever o tempo.
![Page 4: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/4.jpg)
Integração Contínua
• Toda vez que alguém “commita” alguma mudança, toda a aplicação é construída (build) e um conjunto expressivo de testes automatizados são executados a fim de testá-la.
• Se o build ou os testes falham toda a equipe para o que quer que estejam fazendo e acertam os problemas imediatamente.
• Software em estado funcional a todo o tempo.
![Page 5: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/5.jpg)
Origem
• Primeiramente escrito sobre, no livro Extreme Programming Explained (Kent Beck 1999).
![Page 6: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/6.jpg)
Conceitos que justificam
• Se a integração do código está funcionando, por que não fazê-la a todo instante?
• Mudança de paradigma:– Sem a integração contínua seu software está
quebrado até que alguém prove o contrário.
![Page 7: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/7.jpg)
Vantagens
• Equipes que adotam a IC são capazes de efetivamente entregar software mais rápido e com menos bugs.
• Bugs são detectados previamente, quando são baratos de serem solucionados, provendo menos gastos de custo e tempo.
![Page 8: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/8.jpg)
O que é preciso antes de iniciar?
1. Controle de Versão– Repositório de tudo do projeto: código, testes,
scripts de BD, build, scripts de deployments e o que mais for preciso para: criar, instalar, rodar e testar a aplicação.
![Page 9: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/9.jpg)
O que é preciso antes de iniciar?
2. Build Automático– Deve ser possível iniciar o build pela linha de
comando. Razão?• Deve ser possível compilar a aplicação de forma
automática do ambiente de IC, para quando algo der errado que seja possível de ser auditado.
• Seu script de build tem que ser como o código do projeto. Deve ser testado e constantemente refatorado, para estar sempre arrumado e compreensível. Importante à medida que o projeto vai se tornando mais complexo.
![Page 10: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/10.jpg)
O que é preciso antes de iniciar?
3. Combinado entre todos os membros da equipe• Integração contínua é uma prática e não uma
ferramenta.• Requer um grau de comprometimento e disciplina dos
membros da equipe.• É preciso que todos “comitem” frequentemente
pequenos incrementos/mudanças.• A tarefa de maior prioridade é consertar qualquer
mudança que tenha quebrado a aplicação.
![Page 11: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/11.jpg)
Sistema Básico para IC
• Hudson e CruiseControl (open source)• Pré-condições para iniciar o uso.– Informar onde encontrar o código no repositório.– Que script executar para compilar o projeto.– Que script executar para rodar os testes.– Como informar a equipe que a última mudança
quebrou o software.
![Page 12: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/12.jpg)
Processo IC
1. Verifique se o build ainda está rodando. Em caso positivo aguarde o término. Se falhar, trabalhe com a equipe para fazê-lo passar antes de dar o check-in.
2. Quando tiver terminado e os testes tiverem passados, atualize o código no seu ambiente de trabalho
3. Rode o script de build e testes na sua máquina para ter certeza que tudo está funcional no seu ambiente de trabalho, ou alterantivamente use sua ferramente de
IC pessoal.
![Page 13: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/13.jpg)
Processo IC4. Se o seu build local passar, check seu código para o controle de versão.
5. Espere a ferramente de IC executar o build com suas mudanças
6. Se falhar, conserte o problema imediatamente no seu ambiente de trabalho e volte ao passo 3.
7. Se o build passar, alegre-se e mova para a próxima tarefa.
![Page 14: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/14.jpg)
Pré-requisitos para IC
• Check-in no trunk regularmente. – As alterações serão menores, menos provável de
quebrar o build.– Significa que há uma versão do SW funcional
recente a ser revertida se você fizer algum erro.– Ajuda a equipe a ser mais disciplinada com seus
refactorings. – Garantir que mudanças que alteram muitos
arquivos são menos prováveis de dar conflito com o trabalho de outros da equipe.
![Page 15: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/15.jpg)
Pré-requisitos para IC
1. Check-in no trunk regularmente. – Permite o desenvolvedor explorar mais
alternativas, experimentando ideias e as descartando, revertendo a versão para a anterior.
– Força a pausas regulares para esticar os músculos ajudando a evitar a síndrome do carpo.
– E se algo de catastrófico acontecer, ninguém perde um grande trabalho.
![Page 16: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/16.jpg)
Pré-requisitos para IC
• O check-in deve ser feito no trunk, pois não é aconselhável trabalhar com branches.
• É impossível fazer IC usando branches, porque por definição, se estiver trabalhando em branches seu código não está sendo integrado com o de outros desenvolvedores.
![Page 17: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/17.jpg)
Pré-requisitos para IC
2. Criar uma suite de testes automatizados– É essencial ter um nível de testes automatizados
para fornecer confiança de que seu software está funcionando.• Testes unitários• Testes de componente• Testes de aceitação
![Page 18: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/18.jpg)
Pré-requisitos para IC
• Testes Unitários – Testa partes pequenas e isoladas da aplicação
(método, função, ou interação entre alguns deles). – Não se conecta o banco de dados, arquivos de
sistema ou a sua rede.– Podem ser executados sem que a aplicação esteja
num ambiente semelhante ao de produção.– Devem rodar rapidamente, toda a suíte em mais
ou menos 10 minutos.
![Page 19: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/19.jpg)
Pré-requisitos para IC
• Testes de Componente– Testa o comportamento de vários componentes da
aplicação.– Podem ser executados sem que a aplicação esteja
num ambiente semelhante ao de produção.– Conceta-se ao banco de dados, arquivos de
sistema ou a sua rede.– Tipicamente demoram a ser executado.
![Page 20: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/20.jpg)
Pré-requisitos para IC
• Testes de Aceitação– Testa se a aplicação atende aos critérios definidos
pelo negócio para aceitação, incluindo funcionalidade e também características como: capacidade, disponibilidade, segurança, etc.
– Preferencialmente executados num ambiente que simule o de produção.
![Page 21: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/21.jpg)
Pré-requisitos para IC
3. Mantenha o build e o processo de teste unitário curto. 10 minutos é o tempo limite
– Equipe deixará de fazer esse processo na sua área de trabalho e teremos mais builds quebrados.
– IC vai levar também tanto tempo que multiplos commits irão ocorrer e não será possível detectar qual check-in quebrou.
– Equipe fará check-in com menos frequência.
![Page 22: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/22.jpg)
Pré-requisitos para IC
4. Administre sua área de trabalho– Cada membro da equipe deve ser capaz de rodar
o build, executar os testes automatizados e fazer o deploy da aplicação em um ambiente sobre o seu controle.
![Page 23: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/23.jpg)
Usando Software de IC
• Operações Básicas– Executar um simples worflow em intervalos
regulares– Prover uma forma visual de analisar os resultados
• Chamando a atenção– Enviar o status do build mais recente para outro
dispositivo.• Indicadores com lâmpadas, som, falando nome do
desenvolvedor que quebrou o build…
![Page 24: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/24.jpg)
Boas Práticas
1. Não dar check-in em um build quebrado.2. Sempre executar localmente os testes antes
de commitar.3. Esperar os testes serem executados antes de
mover adiante.4. Nunca ir para casa se um build quebrar.
![Page 25: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/25.jpg)
Práticas Essenciais
5. Sempre estar preparado para reverter a uma versão anterior.
6. Estabelecer um timebox antes de reverter.7. Não “comentem” os testes que falharam.8. Assuma a responsabilidade de todos os
testes que quebrarem pelo resultado de uma mudança sua.
9. TDD.
![Page 26: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/26.jpg)
Estratégia de Testes
• Testar é uma atividade que deve – Envolver toda a equipe– Ser feita continuamente desde o início do projeto.
• Construir qualidade significa escrever testes automatizados em diversos níveis e executá-los como parte do pipeline de deployment.
• Testes manuais também são essenciais para construir a qualidade do software.
![Page 27: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/27.jpg)
Estratégia de Testes
• Testers colaboram com desenvolvedores e usuários para escrever os testes automatizados.
• Os testes devem ser escritos antes de ser iniciado o desenvolvimento de uma história
![Page 28: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/28.jpg)
Tipos de Testes
Brian Marick
Functional acceptance test
ShowcasesUsability testing
Exploratory testing
Nonfunctional acceptance tests
(capacity, security,…)
Unit testsIntegration tests
System tests
Manual/Automated
Manual
Automated
Automated
Supp
ort P
rogr
amm
ing
Critique Project
Technology Facing
Business facing
![Page 29: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/29.jpg)
Suporte a Tecnologia e Desenvolvimento
• Responsabilidade exclusiva dos desenvolvedores– Unitários– Integração / Componente– Deployment / Sistema
Unit testsIntegration tests
System tests
Automated
Supp
ort P
rogr
amm
ing
Technology Facing
![Page 30: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/30.jpg)
Teste de Integração
• Se refere a testes que garantem que cada parte independente da aplicação funciona corretamente com serviços dos quais dependam.
• Podem ser escritos como são os testes de aceitação
![Page 31: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/31.jpg)
Teste de Integração
• Devem ser executados em dois contextos:1. Interfaceando com os sistemas externos dos quais
dependem ou com replicas controladas pelo provedor
2. Interfaceando com equipamentos de testes desenvolvidos como parte do código base.
![Page 32: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/32.jpg)
Suporte ao Negócio e Desenvolvimento
• Responde as perguntas:– Como eu sei que está done?
(para desenvolvedor)
– O done é o que eu realmente queria?
(para usuário)
• Preparando o teste– Dado [] quando[], então[]
Functional acceptance test
Automated
Supp
ort P
rogr
amm
ing
Business facing
![Page 33: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/33.jpg)
Negócio e Desenvolvimento
• Preparando o teste– Dado [1] quando[2], então[3]1. Importantes características
do estado do sistema.2. O usuário executa algumas
ações específicas.3. Importantes características
do novo estado do sistema.
Functional acceptance test
Automated
Supp
ort P
rogr
amm
ing
Business facing
![Page 34: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/34.jpg)
Processo – Teste Aceitação
• No início de cada iteração reunir cliente, analistas e testers para levantar o cenário de maior prioridade a ser testado.
• Usar ferramentas para escrever em linguagem natural os testes e que permitam depois criar o código para fazer os testes serem executados. Exemplos:– Cucumber / Jbehave / Concordion / Twist
![Page 35: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/35.jpg)
Processo – Teste Aceitação
• Refatoração no código de teste implica em atualização da especificação do teste.
• Usar uma linguagem específica do domínio (DSL) para testar, isso permite que os critérios de aceitação entrem em DSL também.
![Page 36: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/36.jpg)
Processo – Teste Aceitação
• Testers e desenvolvedores se reunem antes do início do desenvolvimento da história para discutir os testes de aceitação. – Isso permite aos desenvolvedores terem uma boa visão
da história e entenderem qual o cenário mais importante.
– Reduz o ciclo de feedback entre desenvolvedores e testers que pode acabar acontecendo ao final do desenvolvimento.
– Ajuda a reduzir tanto funcionalidades não implementadas, quanto o número de bugs.
![Page 37: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/37.jpg)
Suporte ao Negócio e Projeto
• Não apenas valida se a aplicação atende a especificação, mas se a especificação está correta.
• Desenvolvimento de software é um processo iterativo.
ShowcasesUsability testing
Exploratory testing
Manual
Critique Project
Business facing
![Page 38: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/38.jpg)
Suporte ao Negócio e Projeto
• Showcases– Equipe ágeis com produto após
iteração.• Exploratory
– Controla a criação dos testes enquanto sendo executados e usa os resultados são usados para criar novos testes automatizados
• Usability– Descobre quão fácil é para o usuário
alcançar seus objetivos com o SW.
ShowcasesUsability testing
Exploratory testing
Manual
Critique Project
Business facing
![Page 39: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/39.jpg)
O que testar? Novo Projeto
• Iniciar escrevendo testes de aceitação automatizados. Para isso:– Escolher uma plataforma e uma ferramenta de
teste– Set up o build automático– Trabalhar em histórias que sigam os princípios
INVEST (Independent, Negotiable, Valuable, Estimable, Small, and Testable)
![Page 40: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/40.jpg)
O que testar? Novo Projeto
• Processo– Cliente, analistas e testers definem os critérios de
aceitação– Testers trabalham com os desenvolvedores para
automatizar os testes de aceitação baseado nos critérios definidos
– Desenvolvedores codificam o comportamento para atender os critérios de aceitação
– Se os testes falharem, prioridade em acertar o código.
![Page 41: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/41.jpg)
O que testar? Projeto em Andamento
• Começar pelo caso de uso mais comum, importante e de maior valor da aplicação.– Conversa com o cliente para identificar onde o
valor do negócio está centrado.– Automatizar o fluxo básico que cobre esse cenário
de alto-valor.– Em adição, maximizar o número de ações que
esses testes cobrem.
![Page 42: Integração Contínua](https://reader037.fdocumentos.tips/reader037/viewer/2022102814/54913834b47959ac088b48e5/html5/thumbnails/42.jpg)
Referência:
• Dave Farley
• Jez Humble
Sobre os autores…