Test Automation Guide

AUTOMAÇÃO
DE TESTES
QUEM SOU EU?
 Jefferson Cavalcante
 Doutorando em Ciência da Computação – UFC
 Analista de sistemas e pesquisador – Instituto Atlântico

APRESENTAÇÃO DO CURSO
 O valor da automação de testes
 De testes manuais para testes automatizados
 Pessoas e Ferramentas
 Arquitetura e automação de testes
 Testes de aceitação
 Unit Tests & TDD
 Outros tipos de testes automatizados
Complete Guide to Test Automation (Arnon Axelrod)

CONHECENDO A TURMA
 Com o que trabalham?
 Utilizam testes automatizados nos projetos pessoais ou profissionais?

O VALOR DA AUTOMAÇÃO DE TESTES
POR QUE PRECISAMOS DE TESTES AUTOMATIZADOS?
 Inputs da turma
 Simplificação do trabalho, ganho de tempo
 Introducao de melhoria impactava outras funcionalidades
 Lenvanta-se duvidas se o sistema continua funcionando
corretamente
 Testes de carga, de penetração, etc são custosos
 Garantir integração dos sitemas

POR QUE PRECISAMOS DE TESTES AUTOMATIZADOS?
 Vejamos duas motivações para a automatização de testes de software

DA CASCATA AO ÁGIL
 Quando o software era planejado “de uma vez”, sabia-se o que e como testar com bastante
antecedência
 Modelo em cascata se mostrava problemático... Aplicou-se a lei de Boyd

DA CASCATA AO ÁGIL
 Lei de Boyd: velocidade da iteração vence a qualidade da iteração
 Descobriu como caças F-86 americanos venciam caças MIG-15 russos muito
superiores
 Pequenos movimentos mas com menos esforço físico (manche hidráulico) garantiam mais
vitórias
 Base do desenvolvimento ágil

DA CASCATA AO ÁGIL
 Entregam-se muitas versões do sistema durante seu desenvolvimento
 Novas funcionalidades são projetadas durante o desenvolvimento
 Nesse cenário, testar cada entrega manualmente pode tomar MUITO tempo do time
DA CASCATA AO ÁGIL
 Entregam-se muitas versões do sistema durante seu desenvolvimento
 Novas funcionalidades são projetadas durante o desenvolvimento
 Nesse cenário, testar cada entrega manualmente pode tomar MUITO tempo do time
Primeiro grande motivo para se querer testes automatizados

COMPLEXIDADE DO SISTEMA
 Agora, imagine um sistema muito fácil de

manter
 Adicionar funcionalidades aumentaria a

complexidade do sistema de forma constante
 O custo de gerar uma nova entrega seria

sempre o mesmo
 Custo em termos de tempo de trabalho gasto

pelo time
 Enquanto isso, na vida real...
 Quanto mais funcionalidades, mais rápido

aumenta a complexidade do sistema
 Quanto mais complexo o sistema, mais difícil

não quebrar funcionalidades existentes
 O custo de entregar uma nova feature

aumenta cada vez mais
 Dois tipos de complexidade podem ser

adicionadas ao sistema
 Complexidade inerente
 Complexidade acidental
https://medium.com/background-thread/accidental-and-essential-complexity-programming-word-of-the-day-b4db4d2600d4
 No desenvolvimento de sistemas, é inevitável adicionar complexidade ao se implementar uma nova

feature
 Mesmo que ela tenha sido muito bem projetada e com antecedência
Complexidade inerente
 No desenvolvimento de sistemas, é inevitável adicionar complexidade ao se implementar uma nova
feature
 Mesmo que ela tenha sido muito bem projetada e com antecedência
 No entanto, muita complexidade pode ser adicionada por:

 Design ruim
 Falta de comunicação entre membros do time
 Falta de conhecimento sobre alguma tecnologia ou sobre o negócio
 Essa complexidade que poderia ser reduzida é parte natural de todo desenvolvimento de software
 No entanto, muita complexidade pode ser adicionada por:

 Design ruim
 Falta de comunicação entre membros do time
 Falta de conhecimento sobre alguma tecnologia ou sobre o negócio
 Essa complexidade que poderia ser reduzida é parte natural de todo desenvolvimento de software
Complexidade acidental
 O aumento da complexidade aumenta o custo de entregar uma feature
 Leva-se mais tempo para adicionar features, testar tudo, corrigir bugs
 O software se torna cada vez mais frágil e difícil de manter
 Queremos manter o custo de entregar uma feature sempre constante...

REFATORAÇÃO
 Uma forma de manter a complexidade

acidental sempre sob controle é através da
refatoração
REFATORAÇÃO
 Refatoração do código deve ser feita de forma regular, sempre seguida de testes de regressão
 Assim, a quantidade de vezes que executam testes no sistema torna-se incontável

REFATORAÇÃO
 Refatoração do código deve ser feita de forma regular, sempre seguida de testes de regressão
 Assim, a quantidade de vezes que executam testes no sistema torna-se incontável
Segundo grande motivo para se ter testes automatizados

ATIVIDADE 1
 Implementar uma calculadora em Java ou Python
 Requisitos:
 Classe claculadora que opera double: soma, subtração, multiplicação e divisão
 Classe CLI que permite usar a calculadora pela linha de comando (exemplo: soma 10.0 20.0)
 Tempo: 30 min
DE TESTES MANUAIS PARA TESTES AUTOMATIZADOS
PRÓXIMO PASSO
 Já vimos a importância dos testes automatizados
 Agora queremos sair dos testes manuais e torná-los automatizados
 Como fazer?
 Nessa seção, veremos:

 Os desafios da automação
 Os prós e contras dos testes manuais e automatizados
AUTOMATIZAÇÃO DE TESTES MANUAIS
 Agora, imagine que já tenhamos alguns testes manuais e queremos automatizá-los
 Uma possibilidade seria gravar os passos e reproduzi-los posteriormente

GRAVAR E REPRODUZIR PASSOS
 Sugestões...
 Gravar sequências de cliques na tela e inputs de teclado
 Gravar pacotes de requisição e resposta para uma aplicação

 Hmm... O que poderia dar errado, não é?

 Detectar o que houve de errado em um teste é essencial no processo de testar
 Nesse cenário, como detectar bugs de uma forma também automatizada?
 Sugestões:
 Vejamos algumas possibilidades

 Uma abordagem seria printar a tela e comparar com o que havia sido gravado
 Sensível a mudanças na resolução da tela, data/hora, outros dados que aparecem na tela
 Pode-se usar ferramentas que isolam regiões de interesse na tela

 Outra abordagem seria capturar pacotes de requisição e resposta, reenviar as requisições e comparar
com os pacotes de resposta gravados
 Sensível a mudanças nos campos de protocolos de rede (ip, porta, etc)
 Pode-se usar ferramentas que leem somente os dados de interesse

 Mesmo com ferramentas que isolem as informações úteis
 Mudenças legítimas na aplicação podem quebrar os testes
 Como distinguir, de forma automática, o que é bug e o que é resultado de evoluções na aplicação?
 Seria preciso regravar o teste manualmente de novo, e isso teria que ser feito com muita frequência
 Perde-se parte do apelo da automação de testes
PENSANDO ERRADO...
 Executamos testes de regressão para que tudo funcione como antes, certo?
 Essa história de ter ficar regravando os testes pode parece estranha...

PENSEMOS BEM...
 Se ninguém mexer no código, os testes devem sempre continuar passando
 Não há sequer motivo para rodar os testes automatizados novamente
 Por outro lado, raramente um desenvedor vai querer mudar o código se não for para introduzir
mudanças na aplicação
 Queremos re-executar testes somente quando algo mudar
 E sempre que executamos testes é porque esperamos que algo tenha mudado
A QUESTÃO É...
 Essas mudanças podem ser pequenas o suficiente para serem ignoradas em testes manuais
 Com nosso discernimento, julgamos se diferenças vem de evoluções na aplicação ou de bugs
 A máquina não tem essa habilidade

 Para ela, ao comparar resultados de testes automátizados mudanças e bugs são a mesma coisa
A QUESTÃO É...
 Na automação de testes, resultados esperados devem sempre ser claros e concisos

SEM RESULTADOS ESPERADOS CLAROS E CONCISOS...
 Para cada mudança na aplicação, testes continuarão falhando até que sejam regravados novamente
(1/4)
 Regravar os mesmos testes repetidas vezes pode introduzir problemas nos próprios testes
 Causando perda de confiança no processo de automação de testes
(2/4)
 Pequenas mudanças na aplicação podem requerer mudanças em muitos cenários de testes
 Por exemplo: ao consertar o texto de um botão de uma tela, todos os testes que checam pelo botão
irão falhar, mesmo se tratando de uma mudança, não de um bug
(3/4)
 Investigar a diferença nos resultados pode não ajudar muito na identificação da causa do problema
 O custo de investigar falhas nos testes pode se tornar maior que testar manualmente
(4/4)
EXTRAINDO O MELHOR DA AUTOMAÇÃO DE TESTES
 Até agora vínhamos pensando como sair de testes manuais introduzindo automação
 Vamos pensar de outra forma...
 Vamos analisar o caso ideal de automação de testes e o que podemos aprender dele
 Veremos um caso ideal, talvez tangível para alguns projetos, de onde há muito o que se aprender
 Durante essa disciplina, esse caso ideal é o que se buscará durante o projeto e implementação de
testes automatizados
 Imagine um sistema cujos testes de regressão cobrem todas as funcionalidades e rodam em poucos
minutos
 Imagine que seu time já corrigiu todos os bugs conhecidos e todos os testes estão passando
 Imagine também que qualquer dev do time pode rodar os testes em sua máquina de desenvolvimento
sempre que quiser
 Como esse cenário mudaria a forma como você usa testes automatizados enquanto desenvolve novas
features?
 Será que você colocaria para rodar apenas no fim do expediente para ver os resultados no outro dia?
 Será que se, ao detectar um bug, faria um report para que fosse corrigido somente numa futura
release?
 Comos os testes rodam rapidamente, você pode executá-los antes de cada commit
 Isso faria com que todos os commits no repositório sempre passem em todos os testes disponíveis
 Essa é a ideia por trás da Integração Contínua (CI), por exemplo

 Ou seja, se desde o início um sistema de CI previnea entrada de bugs por falha em testes de regressão
 Teria-se um sistema virtualmente livre de bugs conhecidos para sempre
 Se, ao introduzir novos testes de regressão, um desenvolvedor acha um bug, ele seria corrigido
imediatamente para manter o estado de zero bugs conhecidos no sistema
 Novas features seriam sempre entregues junto de seus testes automatizados

 Um cenário assim também encorajaria desenvolvedores a melhorar o código através de refatoração
 Já que um testes com tamanha cobertura garantiriam que nada foi quebrado com a refatoração
 Quanto melhor a qualidade do código, mais fácil de manter sem introduzir novos bugs
 Maior produtividade do time

 Essa é uma mentalidade que devemos sempre buscar ao iniciar um projeto
 Até mesmo para projetos já em andamento!

ATIVIDADE 2
 Adicionar testes automatizados para as funções da nossa calculadora
 Requisitos: Operação Resultado esperado

 Criar classe TesteCalculadora que teste os casos na tabela ao lado 0.3 + 0.2 0.5
 Um método para cada caso de teste, sugestão: testeSoma0ponto5() 3.5 + 2.5 6.0
 Preferencialmente usando Junit (Java) ou unittest (Python) 0.2 + 0.04 0.24

0.36 + 0.04 0.4
 Adicione pelo menos 1 caso de teste para cada outra operação
0.68 + 0.04 0.72
 Tempo: 30 min
TESTES MANUAIS VS AUTOMATIZADOS
 Até agora já vimos que imitar cegamente o comportamento de um testador manual não é suficiente
 Vimos também que uma implementação bem sucedida de automação de testes traz benefícios que
testes manuais não podem trazer
 A diferença ente testes manuais e automatizados não é uma mera questão de conveniência
 Vejamos as principais diferenças entre eles em 8 importantes tópicos

TESTES MANUAIS
 Testes manuais podem ser exploratórios ou planejados
 Alguns times realizam apenas testes exploratórios com alguns testes de sanidade
 Testes dependentes da cabeça do tester
 Mais comum em empreas pequenas, times pequenos
 Por outro lado, alguns times focam em testes altamente documentados

 Mais engessados, mas mais documentados e precisos
TESTES MANUAIS EXPLORATÓRIOS
 O tester explora o sistema buscando novos bugs

 Mesmo tendo um planejamento, ele(a) pode fazer alguns testes exploratórios no meio do caminho
 Algumas pessoas acham que seria possivel aleatorizar testes automatizados

 O objetivo principal de testes automatizados
 Não é encontrar o máximo de bugs possível
 É dar um retorno rápido sobre se o sistema está funcionando como se espera ou não
 Existe também a vertente dos testes exploratórios semi-automatizados

 Vimos que testes exploratórios se encaixam melhor no contexto de testes manuais
 Daqui por diante vamos sempre nos referir a testes planejados

 Onde há uma sequência de testes a serem realizados com resultados esperados
Precisão
Manuais Automatizados
 Passos dos casos de teste podem ser meio vagos  Passos dos casos de teste precisam ser exatos
1/8
Mantenabilidade
 Durante os testes, testadores podem facilmente  Casos de teste devem ser atualizados com
entender se adaptar a mudanças recém absoluitamente cada mudança que os afete
introduzidas
 Testes automatizados requerem manutenção
 Espera-se que eles atualizem o plano de testes constante
com as mudanças que alterem seu procedimento
 É importante escrever testes automatizados que
de execução
possam ser facilmente atualizáveis
2/8
Sensibilidade a mudanças
 Não há a necessidade de por cada detalhe dos

passos de um caso de teste dentro do próprio caso
de teste
 Normalmente, alguns scripts de teste separados
podem ser usados para esse fim, enquqanto os
casos de teste focam no essencial
3/8
Tratamento de falhas
 Primeiras execuções podem sofrer com casos não previstos na documentação inicial
 Execuções futuras podem falhar por algum desses motivos:

 Há um novo bug no sistema
 Houve uma mudança no sistema que não foi refletida nos testes
 Houve um problema no ambiente (problema de memória, disco, rede...)
 Há um problema/bug no teste
 Falta de isolamento - algum fator externo afetou o ambiente de testes durante sua execução
4/8
Tratamento de falhas
 Ambos podem sofrer com aqueles casos, mas como lidam é diferente
 Seres humanos lidam mais facilmente com falhas provocadas por fatores externos
 Mesmo em caso de novo bug detectado, o testador pode avaliar continuar os testes ou explorar mais
 Para a máquina, qualquer problema é uma falha no teste e será reportado como tal
4/8
Tamanho de um caso de teste
 Costumam ser grandes e tendem a cobrir uma  Menores, verificando apenas uma coisa
funcionalidade por inteiro
 Quase cada verificação deve ter seu caso de teste
5/8
Dependência entre testes
 É comum: execute o teste X após o teste Y  Em testes automatizados, dependências entre

testes são desencorajadas
6/8
Coleta de evidências em caso de falha
 Tester coleta informações relevantes durante a  Testes automatizados trata qualquer problema
execução do teste que gerou a falha como falha e reporta
 O tester pode explorar um pouco para encontrar  Investigação da falha só pode ser realizada a
mais detalhes acerca da falha posteriori, possivelmente com perda de algumas
evidências (logs, por exemplo)
7/8
Confiança
 Às vezes há falta de confiança entre o dev e o  Todos precisam confiar na máquina

tester, mas há consenço sobre a importância dos
 Testes confiáveis precisam garantir que
dois papéis
 Quase toda falha é na presença de bugs reais
 Não deixam passar bugs que eles foram feitos para pegar
8/8
CONCLUSÕES
 Para maximizar os sucessos da automação de testes em um projeto, é importante que

 Cada falha seja resolvida ASAP
 Cada falha seja investigada até que se encontra sua causa raíz
 Testes devem garantir resultados consistentes
 Assim, tem-se uma suíte de testes confiáveis e que garantem a qualidade do produto
PAUSA PARA O ALMOÇO
 Voltamos às 13h
PESSOAS E FERRAMENTAS
PARTE 1 - PESSOAS
COMO ESCOLHER BOAS FERRAMENTAS
 Existem MUITAS ferramentas para automação de testes, como escolher a melhor para seu projeto?
 Ferramentas estão dispostas em categorias, talvez você precise não de uma, mas de algumas...
 Vamos discutir alguns tipos de ferramentas de automação de testes
 Antes de perguntar “qual” ou “por que”, deve-se perguntar “quem”

QUEM DEVE ESCREVER OS TESTES?
 Existem várias abordagens sobre quem do time ou na empresa estará responsável pelos testes
automatizados
 É importante conhecer os pros e contras de cada abordagem, pois sua escolha depende da situação
do time ou da empresa
 Vejamos agora 5 abordagens

PROMOVER TESTERS MANUAIS OU PROGRAMADORES INEXPERIENTES
 Às vezes se interessam em aplicar alguma ferramenta de teste que tenham visto
 Parece uma boa ideia, podem ser profissionais que conhecem o sistema e o negócio
 É importante introduzir de testes automatizados através de um bom projeto e planejamento
 Já vimos que simplesmente automatizar passos manuais não é uma tarefa trivial
 No início os desafios técnicos são menores, mas aumentam de complexidade com o tempo
 O aumento da complexidade dos testes automatizados requer boas skills de debug
(1/5)
PROMOVER TESTERS MANUAIS OU PROGRAMADORES INEXPERIENTES
 A longo prazo, essa é uma abordagem arriscada, principalmente quando há alocação parcial
 Nada sai direito, nem os testes manuais nem os automatizados
 Não é um trabalho que possa ser feito nas horas vagas, por assim dizer, requer dedicação
 Mais adequado para quando testes automatizados estão estabelecidos, com testadores experientes,
talvez não no início
(1/5)
TESTERS MANUAIS E PROGRAMADORES DE TESTES AUTOMATIZADOS
 Desenvolvedores experientes construindo a solução de testes automatizados (as fundações)
 Desenvolvedores juniores ou testadores manuais automatizando testes sobre essas fundações
 Existem ferramentas que requerem pouco código para a escrita de casos de teste
 Costumam ser menos flexíveis do que as baseadas em orientação a objetos, por exemplo
 Ferramentas de testes orientados a palavras-chave ou a comportamento

 Keywork driven testing (KDD) ou Behavior driven testing (BDD)
(2/5)
 KDD: testes são construídos a partir de frases com argumentos
 Cada “frase” é implementada por um método no código do sistema
 Foco em reuso das palavras-chave torna mais legível e fácil para testadores iniciantes
Carregar site ‘www.google.com’

Clicar em ‘search-box’
Digitar ‘minha busca’
Clicar em ‘search-button’
(2/5)
Vantagens Desvantagens
 Reuso de palavras-chave em vários testes  Necessidade de criar ou alterar palavras-chave

costuma ser frequente
 Os próprios testes podem ser usados como
documentação  Dependência entre palavras-chave podem dificultar
a manutenabilidade
 Costuma haver separação do código de teste e da
implementação das palavras-chave  Palavras-chave muito genéricas e cheias de
parâmetro podem se tornar uma dor de cabeça
É importante buscar o equilíbrio entre reusabilidade e legibilidade das palavras-chave
(2/5)
UM TIME DEDICADO À AUTOMAÇÃO DE TESTES
 Um time de pessoas dedicadas somente à automação de testes como um todo
 Implementa a infraestrutura de testes, os testes, investigam resultados e melhoram o sistema de automação
 Existem vantagens
 Membros tem pleno domínio de tudo relacionado aos testes
 Alto compartilhamento de conhecimento entre os membros
 E desvantagens
 A feature pode não ter sido escrita de um jeito facilmente testável pelo sistema de automação
 Testes que passaram no manuial e falharam no automatizado podem bloquear até que o dev investigue
(3/5)
TESTER(S) ALOCADOS NO TIME DE DESENVOLVIMENTO
 Times organizados por features e cuja empresa quer cobrir cada User Story com testes automatizados
 Recomenda-se a troca constante de conhecimento (boas práticas, ideias) entre os testadores e os

desenvolvedores
 Pode ser interessante haver um profissional senior em automação de testes que supervisiona os
testadores alocados nos times
 Não é um bom modelo para a cobertura de features antigas, já entregues
 É um modelo que garante entregas sempre testadas e torna difícil quebras por regressão
(4/5)
PROGRAMADORES RESPONSÁVEIS PELOS TESTES AUTOMATIZADOS
 Normalmente os desenvolvedores já fazem testes unitários de seu código
 Alguns times levam isso a um outro patamar e os devs implementam todos os testes automatizados de
suas features
 Pode ser uma exceletente abordagem quandos os devs tem skills de testes
 Pode não ser uma boa estratégia adotar essa abordagem de forma inadvertida
 Um time por vez para ver se funciona
 Ter devs com experiência em automação de testes que ajudam a manter sua qualidade
(5/5)
RESUMO SOBRE QUEM ESCREVE OS TESTES AUTOMATIZADOS
 É uma escolha que depende do time, do projeto, tamanho da empresa...
 Mas é importante ter em mente essas estratégias para tomar boas decisões e realizar experimentos
sem perder muito tempo e dinheiro
 Sabendo quem estará envolvido na automação de testes, é importante escolher as ferramentas

adequadas
 A seguir veremos alguns tipos de ferramentas de automação de testes e alguns exemplos
 Mas antes...
ATIVIDADE 3
 Adicionar testes do tipo BDD à nossa calculadora (muito similar ao KDD)
 Vamos melhorar os testes unitários das nossa calculadora através da criação de comportamentos
 Isso deve aumentar a legibilidade dos testes para viabilizar a escrita por quem não é desenvolvedor
 Servirá como documentação apresentável do comportamento do nosso sistema
 Usaremos a biblioteca JBehave
 Vejamos como funciona o Behavior Driven Development

BEHAVIOR DRIVEN DEVELOPMENT
 É uma metodologia que dá ênfase na legibilidade dos testes (linguagem quase natural)
 Especificação dos testes funcionam como uma documentação por si só
 Escrevem-se dois tipos de arquivo

 Especificação dos testes em linguagem próxima à natural
 Código que implementa as palavras-chave (similar ao KDD)
Exemlo escrito em Gherkin

 Vejamos como reescrever nossos testes da calculadora usando BDD com a biblioteca Behave
INSTALAR BIBLIOTECA BEHAVE
 pip3 install –user behave

CRIAR TESTES BDD
Crie a seguinte estrutura de pastas:

features/
features/calculadora.feature  testes na linguagem gherkin
features/steps/
features/steps/calculadora_steps.py  Implementação dos comportamentos
TESTES DA CALCULADORA COM BEHAVIOR DRIVEN DEVELOPMENT
features/
features/calculadora.feature  testes na linguagem gherkin
features/steps/
features/steps/calculadora_steps.py  Implementação dos comportamentos
APPLICATION PROGRAMMING INTERFACE (API)
 Vimos um tipo de teste automatizado que busca ser de fácil adoção e manutenção
 Orientado a comportamentos (BDD), parecido com o orientado a palavras-chave (KDD)
 Na próxima aula veremos os tipos de ferramentas de teste e alguns exemplos
 Até agora introduzimos testes automatizados de funções de um programa, o que é muito comum
 Hoje, um tipo comum de sistema é o orientado a serviços ou microserviços
 São sistemas que expõem uma API com funções que podem ser chamadas remotamente
 APIs definem um conjunto de operações que clientes podem invocar

 Contém parâmetros, estruturas de dados, resultados, etc
 Devem ser bem documentadas
 Há 3 tipos de tecnologias que expõem APIs

 Chamadas diretas
 Protocolo de comunicação
 Chamada de procedimento remoto (RPC)
CHAMADAS DIRETAS
 APIs que são chamadas por um mesmo processo, algo que a gente já viu com nossa calculadura
 A Classe calculadora expõe uma API para operações com números de ponto flutuante
 Float Calculadora.soma(Float a, Float b)
 Float Calculadora.mult(Float a, Float b)
PROTOCOLO DE COMUNICAÇÃO
 A aplicação define mensagens que serão trocadas entre os pares
 Normalmente a implementação aceita multiplas requisições em paralelo
 HTTP é um exemplo de protocolo, e suporta dados em HTML, JSON, XML, etc
 SOAP é um outro exemplo, cujo foco é o transporte de dados em XML

REMOTE PROCEDURE CALL (RPC)
 A aplicação define chamadas e expõem da mesma forma que as chamadas diretas
 Stubs são gerados (esqueletos) e são usados pelas aplicações para realizar as chamadas similar às
chamadas de métodos
 A implementação das chamadas conecta-se a o serviço que as implementa, envia os parâmetros e

recebe os resultados, retornando para o método que realizou a chamada
 Duas implementações famosas são o gRPC do Google e o RMI (mais comum no Java, orientado a
objetos)
 APIs são normalmente usadas para que sistemas implementem

 Acesso a recursos como hardware, rede, etc (sistemas operacionais tem APIs para as aplicações)
 Componentes reutilizáveis de aplicações
 Web services para serem consumidos por diversas aplicações de terceiros
 Plugins – sistemas componentizáveis que aceitam plugins expondo uma interface para tal
ATIVIDADE 4
 Objetivo 1: Implementar a calculadora como um serviço REST 30 minutos

 Objetivo 2: Automatizar testes das chamadas à API da calculadora
 Usar biblioteca para levantar serviço REST (python: Flask)

 Serviço chama o método Calculadora.Soma() e retorna o resultado
 Usar biblioteca que realize as chamadas HTTP e recebam o resultado
 Plus: Substituir as chamadas no teste unitário pelas chamadas HTTP

EXEMPLO: CALCULADORA API EM PYTHON
 Instalar biblioteca Flask

 Pip3 install –user flask
Criando serviço REST para somas
http://localhost:5050/calc?val=10.0
Inicializando o serviço de calculadora REST

Executando um teste
ATIVIDADE 4
 Objetivo 1: Implementar a calculadora como um serviço REST 30 minutos

 Objetivo 2: Automatizar testes das chamadas à API da calculadora
 Usar biblioteca para levantar serviço REST (python: Flask)

 Serviço chama o método Calculadora.Soma() e retorna o resultado
 Usar biblioteca que realize as chamadas HTTP e recebam o resultado
 Plus: Substituir as chamadas no teste unitário pelas chamadas HTTP

OBRIGADO.

Test Automation Guide

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Test Automation Guide

Enviado por

Direitos autorais:

Formatos disponíveis

AUTOMAÇÃO

 Doutorando em Ciência da Computação – UFC

 Analista de sistemas e pesquisador – Instituto Atlântico

 O valor da automação de testes

 De testes manuais para testes automatizados

 Arquitetura e automação de testes

 Unit Tests & TDD

 Outros tipos de testes automatizados

Complete Guide to Test Automation (Arnon Axelrod)

 Com o que trabalham?

 Utilizam testes automatizados nos projetos pessoais ou profissionais?

 Testes de carga, de penetração, etc são custosos

 Garantir integração dos sitemas

 Vejamos duas motivações para a automatização de testes de software

 Modelo em cascata se mostrava problemático... Aplicou-se a lei de Boyd

 Lei de Boyd: velocidade da iteração vence a qualidade da iteração

 Base do desenvolvimento ágil

 Entregam-se muitas versões do sistema durante seu desenvolvimento

 Novas funcionalidades são projetadas durante o desenvolvimento

 Entregam-se muitas versões do sistema durante seu desenvolvimento

 Novas funcionalidades são projetadas durante o desenvolvimento

Primeiro grande motivo para se querer testes automatizados

 Agora, imagine um sistema muito fácil de

 Adicionar funcionalidades aumentaria a

 O custo de gerar uma nova entrega seria

 Custo em termos de tempo de trabalho gasto

 Enquanto isso, na vida real...

 Quanto mais funcionalidades, mais rápido

 Quanto mais complexo o sistema, mais difícil

 O custo de entregar uma nova feature

 Dois tipos de complexidade podem ser

 No desenvolvimento de sistemas, é inevitável adicionar complexidade ao se implementar uma nova

 No entanto, muita complexidade pode ser adicionada por:

 No entanto, muita complexidade pode ser adicionada por:

 O aumento da complexidade aumenta o custo de entregar uma feature

 O software se torna cada vez mais frágil e difícil de manter

 Queremos manter o custo de entregar uma feature sempre constante...

 Uma forma de manter a complexidade

 Assim, a quantidade de vezes que executam testes no sistema torna-se incontável

 Assim, a quantidade de vezes que executam testes no sistema torna-se incontável

Segundo grande motivo para se ter testes automatizados

 Implementar uma calculadora em Java ou Python

 Já vimos a importância dos testes automatizados

 Agora queremos sair dos testes manuais e torná-los automatizados

 Nessa seção, veremos:

 Agora, imagine que já tenhamos alguns testes manuais e queremos automatizá-los

 Uma possibilidade seria gravar os passos e reproduzi-los posteriormente

 Gravar sequências de cliques na tela e inputs de teclado

 Gravar pacotes de requisição e resposta para uma aplicação

 Hmm... O que poderia dar errado, não é?

 Detectar o que houve de errado em um teste é essencial no processo de testar

 Nesse cenário, como detectar bugs de uma forma também automatizada?

 Vejamos algumas possibilidades

 Pode-se usar ferramentas que isolam regiões de interesse na tela

 Pode-se usar ferramentas que leem somente os dados de interesse

 Mesmo com ferramentas que isolem as informações úteis

 Mudenças legítimas na aplicação podem quebrar os testes

 Essa história de ter ficar regravando os testes pode parece estranha...

 Se ninguém mexer no código, os testes devem sempre continuar passando

 Não há sequer motivo para rodar os testes automatizados novamente

 Com nosso discernimento, julgamos se diferenças vem de evoluções na aplicação ou de bugs

 A máquina não tem essa habilidade