O documento apresenta conceitos básicos de teste de software, incluindo suas fases, técnicas e critérios. Discute a importância do teste para encontrar erros, apresenta exemplos de bugs caros, e aborda desafios como novos paradigmas de programação. Explica as fases de teste de unidade, integração e regressão, e as técnicas funcionais como particionamento em classes de equivalência e análise de valor limite para gerar casos de teste.

1. Prof. Msc. André Abe Vicente
Teste
de
Software
Uma abordagem Ágil

2. André Abe Vicente
▶ Bach. em Informática (UNIOESTE – PR)
 LabES - Engenharia de Requisitos
▶ Msc. ICMC-USP (São Carlos – SP)
 LabES - Teste de Software e Agile
▶ Techne Eng. e Sistemas
 Lyceum Gestão Acadêmica
▶ UOL e PagSeguro (2012 – Atual)
 Solução de Pagamentos Online

3. ▶ Minhas Atividades no PagSeguro
 Prover ferramentas para facilitar o trabalho
e melhorar a produtividade dos times
 Canais e Parcerias, bandeiras de Voucher e
Análise de Risco.

4. Conteúdo
1. Conceitos Básicos de Teste de Software
 Conceitos, Importância, Técnicas e Critérios
2. Testes Ágeis
 Métodos Ágeis, Quadrantes do Teste (TDD, ATDD...),
Papéis do Time, Práticas e Ferramentas
3. Automação de Testes
 Conceitos e pirâmide de testes
 Testes Unitários: JUnit, Code Coverage Tools
 Testes Funcionais: Selenium Webdriver (Locators e
Page Objects)
 Testes de API: Postman + RestAssured
4. Continuous Integration e Delivery
 Introdução e Prática

5. Alunos ?
▶ Dado alunos do curso de especialização da Univem
▶ Quando os alunos descrevem
 Nome
 Empresa, Cargo, Ramo de Atuação
 Experiência com Teste de Software
 O que espera do curso?
▶ Então o professor conhece o perfil dos alunos da
disciplina de Teste de Software

6. 1. Conceitos Básicos de Teste de Software
Conceitos, Importância, Técnicas e Critérios

7. Teste de Software
▶ Software complexo e variável
 Requisitos de qualidade (diferentes e incompatíveis e
domínios distintos)
▶ Objetivo: revelar a presença de erros ou defeitos no
produto e aumentar a confiança de que o produto esteja
correto (Myers et al., 2004).
▶ Aplicado em vários estágios, com diferentes objetivos.
▶ Sistemas Flexíveis: novos desafios
• Paradigmas de programação
• Tecnologias
• Microservices, Agile

8. Bugs
▶ AT&T suspendeu seu serviço de longa distância (1990)
▶ Self-test em um dos 114 switchs em NYC detectou que estava no
seus limites de capacidade foi resetado automaticamente e
acabou ocasionando um erro em cascata nos outros switchs.
60 milhões de dólares e 500 vôos atrasados
▶ Mais detalhes:
http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse.html

9. Bugs
▶ Erro Matemático no Chip Intel Pentium (1993)
▶ Falha na divisão de ponto flutuante.
Exemplo: 4195835,0 por 3145727,0 o resultado apresentado
pelo microprocesador era 1,33374 ao invés de 1,33382, um
erro de 0.006%
475 milhões de dólares
▶ Orbitador Climático de Marte (1998)
▶ Medida de força Libra/sec (Lockhead) >> Newton/sec
▶ 1 pound = 4,5 newtons
125 milhões de dólares

10. Bugs
▶ Windows bloqueando SOs que não eram piratas (2007)
▶ Por 19 horas todo usuários que tentavam instalar o
Windows tomavam um erro falando que a cópia era
ilegal (Windows Genuine Advantage)
▶ Apple Maps fornecendo trajetos errados (2012)
▶ Direções e lugares errados, Mapas 3D com problemas...
▶ Richard Williamson demitido e parceria com TomTom

11. Bugs
▶ Apple Maps fornecendo trajetos errados (2012)

12. Bugs
▶ Apple Maps fornecendo trajetos errados (2012)

13. Bugs
▶ Apple Maps fornecendo trajetos errados (2012)

14. Bugs no Brasil
▶ Companhia Aérea G
 Bug: Cotação do dólar R$ 2,20 >> R$ 0,22
 Data: 15 de Maio de 2015
 Duração do bug: madrugada do dia 15/05 até 09 da manhã

15. Bugs no Brasil
▶ eSocial
 Problemas cadastro (lentidão e erros internos) – Out/2015
 Cadastrar férias, desligamentos, pagamentos pendentes
 Licença Maternidade, Aux. Doença – continua pagamento INSS
 http://g1.globo.com/globo-news/jornal-globo-news/videos/v/especialista-

16. Bugs no Brasil
▶ Empresa de Telefonia
 Celulares por R$ 9 (2012)

17. Bugs
▶ Como lidar com Bugs?
 Monitoração
 Delivery Minor, Rollback?
 Documentar ou não?
 Criticidade, Negócio/Produto
220 55

18. Problemas comuns de teste*
▶ Não há tempo para o teste exaustivo.
▶ Muitas combinações de entrada para serem exercitadas.
▶ Dificuldade em determinar os resultados esperados para cada caso de teste.
▶ Requisitos do software inexistentes ou que mudam rapidamente.
▶ Não há tempo suficiente para o teste
▶ Não há treinamento no processo de teste.
▶ Não há ferramenta de apoio.
▶ Massa de dados para teste.
▶ Gerentes que desconhecem teste ou que não se preocupam com qualidade.
* Notas de Aula Prof. Auri Vincenzi
▶ Qual técnica de teste aplicar em diferentes tipos de projetos
de software
▶ Sistemas Legados / Testabilidade, Manutenção e Cultura de
Qualidade
Dificuldades para Sistemas com QualidadeDificuldades para Sistemas com Qualidade

19. TEORIA DETECTED
▶ Fases de Teste
▶ Técnicas e Critérios de Teste
▶ JUnit e Code Coverage

20. Fases de Teste
▶ Teste de Unidade
 Tem como foco as menores unidades de um programa,
que podem ser funções, procedimentos, métodos ou
classes.
 Objetivo: revelar defeitos de lógica e implementação
em cada unidade, fornecendo evidências de que a
unidade testada funciona adequadamente de forma
isolada.
▶ Teste de Integração: as diversas partes do software
são integradas e executadas.
 Verificando se a interação entre elas funciona de
maneira adequada e não leva a erros.

21. Fases de Teste
▶ Teste de Sistema: iniciado após se ter o sistema completo,
com todas as suas partes integradas e funcionando.
 Objetivo: detectar possíveis erros na integração do
software com recursos (banco, serviços) e plataforma
(hardware).
 Cada funcionalidade ou comportamento especificado do
sistema deve ser verificado.
 Também são observados requisitos não-funcionais.

22. Fases de Teste
▶ Teste de Aceitação: deve orientar a decisão de
quando o produto em seu estado atual deve ser
liberado.
 Verifica a adequação às necessidades do usuário.
 Bom o suficiente para ser implantado e usado em seu
ambiente operacional.
▶ Teste de Regressão: é realizado durante a
manutenção do software.
 Cada modificação efetuada no sistema, após a sua
liberação, corre-se o risco de que novos defeitos sejam
introduzidos.
 Novos requisitos e requisitos anteriormente testados.
 Integração Contínua

23. Técnicas e Critérios de Teste
▶ Abordagem sistemática e teoricamente fundamentada
para se conduzir e avaliar a qualidade do teste de
software.
▶ A escolha do deve levar em conta
 Restrições de qualidade, custo, prazo e recursos.
 Técnica: definida pelo tipo de informação utilizada para realizar
o teste (especificação, código, histórico de defeitos...).
 Cada técnica de teste possui um conjunto de critérios de teste.
 Sistematizar a forma de como os requisitos devem ser
produzidos.
Técnicas e Critérios de Teste

24. Técnicas de Teste
▶ Funcional: especificação do programa ou
componente.
▶ Estrutural: estrutura do programa, cobertura do
código-fonte, fluxo de controle e dados.
▶ Baseado em Defeitos: utiliza informações sobre
tipos de erros frequentes.
▶ Baseado em Estados: modela comportamento do
sistema ou unidade testada.

25. Técnicas Funcionais
Objetivo: Reduzir significativamente o número de casos de teste
em relação ao teste exaustivo.
▶ Divide o domínio de entrada em classes de equivalência
(válidas e inválidas).
▶ Valor dentro do intervalo tem a mesma importância, ou seja,
qualquer valor escolhido é adequado.
Particionamento em Classes de Equivalência
▶ Testa os limites das classes de equivalência nos quais
diferentes tipos de erros estão escondidos.
▶ Mais adequado para o teste de produtos com domínios de
entrada divididos em intervalos ou conjuntos.
Análise de Valor Limite

26. Técnicas Funcionais
Particionamento em Classes de Equivalência
▶ Dividir a entrada e saída de domínios em classes de dados,
válidos e inválidos, de acordo com a especificação da
funcionalidade.
▶ Um conjunto mínimo de casos de teste é projetado contendo
pelo menos um elemento representante de cada classe de
equivalência.

27. Técnicas Funcionais
Particionamento em Classes de Equivalência
▶ Diferentes tipos de dados exigem diferentes tipos de classe de
equivalência.
▶ Duas classes inválidas e uma válida.
R$ 1000,00/mês R$ 83000,00/mês
0 1 2 3 4 5 6
Válido
Inválido
Renda para Hipoteca (Contínuos)
# de Pessoas (Discretos)

28. Técnicas Funcionais
Particionamento em Classes de Equivalência
▶ Diferentes tipos de dados exigem diferentes tipos de classe
de equivalência.
Classes Válidas Classes Inválidas
Pessoas Corporações
Associações
Condomínio
Sobrado
Casa Térrea
Duplex
Trailer
Simples
Múltipla
Escolha

29. Técnicas Funcionais
Particionamento em Classes de Equivalência
▶ Renda: R$ 1000,00 à R$ 83000,00
▶ Moradores: 1 à 5
▶ Aplicante: Pessoas
▶ Tipo: Condomínio, Sobrado ou Casa Térrea
Renda # Moradores Aplicante Tipo Resultado
R$ 6000 3 Pessoas Condomínio Válido
R$ 100 2 Pessoas Casa Térrea Inválido
R$ 90000 2 Pessoas Casa Térrea Inválido
R$ 2153 0 Pessoas Condomínio Inválido
R$ 2153 6 Pessoas Condomínio Inválido
R$ 2153 1 Associação Sobrado Inválido
R$ 2153 1 Pessoas Duplex Inválido

30. Técnicas Funcionais
Análise de Valor Limite
1. Identificar as classes de equivalência (requisitos de teste do
critério).
2. Identificar os limites de cada classe.
3. Criar casos de teste para os limites escolhendo:
O ponto abaixo do limite | O limite | Um ponto acima do limite.
0 ≤ idade ≤ 15 Não empregar
16 ≤ idade ≤ 17 Pode ser empregado em tempo parcial
18 ≤ idade ≤ 54 Pode ser empregado em tempo integral
55 ≤ idade ≤ 99 Não empregar
(Copeland, 2004)

31. Técnicas Funcionais
Prática 1 – Técnicas Funcionais (JUnit IR)
https://github.com/andvicente/JUnit_ImpostoRenda

32. Teste Estrutural
▶ A técnica estrutural (caixa-branca) é vista como complementar à
técnica funcional
 baseia-se na estrutura de um programa para derivar os seus casos
de teste.
▶ Critérios
 Fluxo de controle: utilizam apenas características de
controle de execução do programa, como comandos ou
desvios, para derivar os requisitos de teste necessários.
 Fluxo de dados: definição e uso de variáveis.

33. Teste Estrutural
▶ Os critérios mais conhecidos baseados em fluxo de controle são:
 Cobertura de Comandos (Todos-nós): exige que cada comando
do programa seja executado ao menos uma vez.
 Cobertura de Decisões (Todos-arcos) : objetivo fazer cada
comando de decisão assumir os valores TRUE e FALSE.
 Cobertura de Condição: em geral, melhor que cobertura de
decisão. Cada condição individual assume os valores TRUE e
FALSE.
 Cobertura de decisões/condições: requer que todas as
combinações sejam testadas.
 ...

34. Teste Estrutural
 Cobertura de Comandos
(todas linhas): foo(1,1)
 Cobertura de Decisões
foo(1,1) – 2 condições IF true
foo(0,1) – 1 condição IF false
 Cobertura de Condições
foo(1,1) – x>0 (T) y>0 (T)
foo(1,0) – x>0 (T) y>0 (F)
foo(0,0) – x>0 (F) y>0 (F)
int foo (int x, int y){
int z = 0;
if ((x>0) && (y>0)) {
z = x;
}
return z;
}
Exemplo:Exemplo:

35. Teste Estrutural
int foo (int x, int y){
int z = 0;
if ((x>0) && (y>0)) {
z = x;
}
return z;
}
Exemplo:Exemplo:
 Cobertura de
Decisões / Condições
foo(1,1) – x>0 (T) y>0 (T)
foo(1,0) – x>0 (T) y>0 (F)
foo(0,1) – x<0 (F) y>0 (T)
foo(0,0) – x>0 (F) y>0 (F)
Outros tipos de cobertura
Cobertura de Loop (1, 2 vezes,
n vezes...)
Cobertura de Caminhos: exige
que todos os caminhos
possíveis do programa sejam
executados (geralmente
impraticável)

36. Resumo
▶ Teste de Software
 Revelar a presença de erros ou defeitos no produto e aumentar a
confiança de que o produto esteja correto (Myers et al., 2004).
 Desafios: novos paradigmas, micro-services, cultura de testes.
▶ Fases de Teste
 Teste de Unidade, Integração e Testes de Regressão (com
Integração Contínua)
▶ Técnicas e Critérios de Teste
 Técnica: informação utilizada para criar o teste (especificação,
codigo…)
 Critérios: sistematizar a forma de como os casos de teste serão
criados
 Funcional: Análise de Valor Limite e Classe de Equivalência
 Estrutural: Cobertura de Comandos, Decisões, Condições,
Caminhos

37. Referências
▶ Delamaro, M. E.; Maldonado, J. C.; Jino, M.
software Rio de Janeiro, RJ: Elsevier, 2007.
▶ Vincenzi, Auri. Notas de Aula (Teste de Software) – Instituto de
Informática (UFG), 2008.
▶ Bibliografia Sugerida: Auri Vincenzi, José Carlos Maldonado e
Márcio Delamaro - Automatização de Teste de Software - com
ênfase em Ferramentas Open Source -
http://napsol.icmc.usp.br/ats/

38. Code Coverage
▶ JUnit e Ferramentas de Cobertura

39. 2. Testes Ágeis
Métodos Ágeis, Quadrantes do Teste (TDD, ATDD...), Papéis do
Time, Práticas e Ferramentas
Agilidade: adotar e reagir rapidamente a mudanças no
ambiente e clientes.

40. Métodos Ágeis
 Mudanças: necessidades do cliente (satisfação). Não podem
afetar: cronograma e orçamento.
 Métodos ágeis: valores, princípios e boas práticas de
desenvolvimento e condução de projeto.
Mudanças e Métodos Ágeis

41. Métodos Ágeis
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a fazerem o
mesmo. Através deste trabalho, passamos a valorizar:
http://www.manifestoagil.com.br

42. Métodos Ágeis

43. Métodos Ágeis
 Satisfazer o cliente com entregas rápidas e frequentes.
 Entrega incremental de software deste as etapas iniciais.
 Soluções simples, pequenos ciclos de desenvolvimento.
 Processos eficientes para gerar produtos de qualidade
(cronograma, menos defeitos, usuários satisfeitos).
 Colaboração com o cliente.
 Aprendizagem e melhoria contínua.
Métodos de Desenvolvimento Ágil
 Projetos grandes e complexos,
 Cultura Agile, garantir a qualidade com menos processos.
Dificuldades Agile

44. Testes Ágeis
 Executado com frequência para detectar defeitos o
mais cedo possível (ciclos iterativos e curtos).
 Constante feedback do cliente.
 Testando sob o ponto de vista do cliente (aceitação).
 Execução de testes manuais por meio de teste
exploratórios
Características Testes Ágeis
Todo mundo no time de desenvolvimento é
igualmente responsável pela qualidade e sucesso do
projeto.
The Whole Team-Aproach

45. Testes Ágeis
“O foco no desenvolvimento agil é produzir software de
qualidade em um prazo que maximize o valor para o
negócio. Esse é o trabalho de todo o time, não somente
os testes ou profissionais designados para garantia de
qualidade.”
“Todos em um time ágil ficam “infectados pelo teste”.
Testes, do nível de unidade para cima, devem guiar o
código, ajudar o time a aprender como a aplicação
deve funcionar e deixam nos saber quando uma task ou
história está terminada.”
by Lisa Crispin and Janet Gregory
Todo Time responsável pela Qualidade

46. Quadrantes de Testes Ágeis

47. Quadrantes de Testes Ágeis
▶ Brian Marick’s (2003) fez duas distinções
 Testes voltados para tecnologia vs negócios
 Testes que dão apoio ao time vs que criticam/avaliam o
produto.
▶ Quadrantes
 Q1 – Testes tecnológicos que guiam time.
 Q2 – Testes de negócio que guiam o time.
 Q3 – Testes de negócio que avaliam o produto.
 Q4 – Testes tecnológicos que avaliam o produto.

48. Pirâmides de Teste
 http://martinfowler.com/bliki/TestPyramid.html
 https://www.thoughtworks.com/insights/blog/introducing-software-testing-cupcake-anti-
 https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

49. Quadrantes de Testes Ágeis
▶ Brian Marick’s (2003) fez duas distinções
 Testes voltados para tecnologia vs negócios
 Testes que dão apoio ao time vs que criticam/avaliam o
produto.
▶ Quadrantes
 Q1 – Testes tecnológicos que guiam time.
 Q2 – Testes de negócio que guiam o time.
Prevenir defeitos antes e durante o desenvolvimento

50. Quadrantes de Testes Ágeis
▶ Brian Marick’s (2003) fez duas distinções
 Testes voltados para tecnologia vs negócios
 Testes que dão apoio ao time vs que criticam/avaliam o
produto.
▶ Quadrantes
 Q3 – Testes de negócio que avaliam o produto.
 Q4 – Testes tecnológicos que avaliam o produto.
Encontrar defeitos e descobrir funcionalidades, mas com
o entendimento de que queremos encontrar esses
defeitos o mais rápido possível.

51. Quadrantes de Testes Ágeis
▶ Brian Marick’s (2003) fez duas distinções
 Testes voltados para tecnologia vs negócios
 Testes que dão apoio ao time vs que criticam/avaliam o
produto.
▶ Não tem relação com quando os testes são feitos.
 Depende de riscos de cada projeto
 Objetivos do cliente para o produto
 Projeto com código legado ou novo
 Quando os recursos estão disponíveis para o teste

52. Quadrantes de Testes Ágeis
http://www.slideshare.net/dwhelan/agile-testing-and-the-role-of-the-agile-tester

53. Q1 - Testes de Unidade e Componentes
▶ Testes de Unidade e Componentes
 Ajuda os desenvolvedores a entender exatamente que
código é necessário para implementar uma
funcionalidade.
 Qual o melhor design para ele (TDD + Clean Code).
 Rapidez no feedback, detectar os erros antes.
 Infra-estrutura: versionamento de código, gerência de
configuração e integração contínua.

54. Q1 - Testes de Unidade e Componentes
Mocks
▶Teste de unidade: testar a classede maneira isolada, sem
▶ bug em uma unidade não afeta testes da outra
▶Acelera preparação ou execução dos testes
▶Permite testar mesmo que algum componente não esteja
pronto ou disponível.
▶Mockar classes que lidam com infra-estrutura

55. Test Driven Development (TDD)
▶ Explorar, projetar, desenvolver e testar o software
 menos defeitos, desenvolvedores mais confiantes
(mudanças), melhoria qualidade do código
 verificar se o projeto e decisões arquiteturais foram
apropriadas, menos tempo de depuração (produtividade)
Benefícios: código de melhor qualidade

56. Test Driven Development (TDD)
ANICHE, M. Test-Driven Development: Teste e Design no
Mundo Real, 2012.
Prática 3 – Test Driven Development
Números Romanos
https://github.com/andvicente/TDD_EXEMPLO

57. Test Driven Development (TDD)
▶ Código de Melhor Qualidade diminuição de defeitos.⇒
▶ Design: LOC, Complexidade, Coesão e Acoplamento (David
Janzen)
▶ Facilita comunicação, mudanças ocorrem mais
naturalmente.
▶ Usuários mais satisfeitos.
 TDD é difícil de ser aplicado: nova forma de
desenvolvimento.
 Maior tempo para desenvolvimento de código-fonte.
Dificuldades

58. Q2 – Testes de Negócio (BDD)

59. Q2 – Testes de Negócio (BDD)
▶ Customer-facing tests (qualidade externa e funcionalidades
que os clientes desejam).
▶ Baixa qualidade na comunicação entre os especialistas de
domínio e o time.
▶ Tradicional: stakeholders passam os requisitos ao time sem
muita oportunidade para feedback
▶ Agile: os desenvolvedores e stakeholders colaboram para
escrever testes automatizados que expressam o que os
stakeholders querem

60. Q2 – Testes de Negócio (BDD)
▶ Testes de aceitação expressam o que o software precisa
para que os stakehoders achem esse aceitável.
▶ Testes como exemplos que qualquer um pode ler.
 Obter feedback dos stakeholders se estamos definindo da
forma correta o que será construido antes do
desenvolvimento começar.
▶ Behavior Driven Development (BDD)
Dado um contexto inicial
Quando um evento ocorre
Então assegure alguns resultados

61. Q2 – Testes de Negócio (BDD)
▶ BDD (Given-When-Then)
 Feature: Registrar-se no PagSeguro
Registrar-se deve ser rápido e amigável

62. ▶ Cenário: Registrar-se no PagSeguro com sucesso
 Novos usuários devem receber um e-mail
de confirmação e
 Receber uma mensagem personalizada do site quando
estiver logado.
Given Eu escolhi me registrar
When Eu me registro com dados válidos
Then Eu recebo uma email de confirmação
And Eu vejo uma mensagem de boas vindas personalizada
Q2 – Testes de Negócio (BDD)

63. ▶ Cucumber
 Feature e Steps (Java)
 https://cucumber.io

64. https://github.com/taisedias/selenium-cucumber

65. Cultura Ágil
Spotify (and Agile Companies)
▶ Organização dos Times
▶ Backend Devs, QAs, Frontend Devs
ADs / DBAs, Implantação / Operações
Times de Infra
▶ Grupos de Interesse (Continuous Delivery, Coaching,
Qualidade/Testes…)
Fonte: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

66. Cultura Ágil
Spotify (and Agile Companies)
▶ Entregas + Feature Toggles
▶ Releases separados, Fatiar Monolítico (DESAFIO!)
▶ Entregas (Trens de Entrega, Caronas)
▶ Chaveamentos (Usuário, Porcentagem, Testes A/B)
Fonte: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-2/

67. ▶ Monitoramento em Produção
▶ Acompanhamento Delivery e Pós
▶ Monitoramento Operações, Relatórios de Erros 500, Banco
▶ Acompanhamento Funcionalidades (Erros, Negócio…)
Cultura Ágil
Spotify (and Agile Companies)
Payment Gateway Real - Time Monitoring with Splunk!
Marcio Ghiraldelli @ SplunkConf 2013

68. Prática 4 – Monitoramento em Produção
▶ O que é Monitorado ou poderia ser na sua empresa?
▶ Monitoramento de Atributos Técnicos
▶ Monitoramento de Negócio
20 - 30 min
Exercício Monitoração

69. Agile Tester
▶ Dimensão de Negócio
 Entender contexto do negócio
 Pair com desenvolvedores para alinhar o que deve ser
feito
 Lado racional do PO (priorizar, simplificar, alternativas)
 BDD, Testes de Aceitação, Specification by Example
https://www.thoughtworks.com/pt/insights/blog/agile-tester

70. Agile Tester
▶ Dimensão Técnica
 Técnicos com boa habilidade de programação
 Pair programming com devs
 boas práticas como clean code e patterns
 escrever testes, revisar código e até ajudar a depurar problemas
 Conhecimento em automação, ajudam a escolher os
frameworks de teste.
 Importante: conhecer arquitetura do sistema
 Mais do que interface: monitoração, logs, mensageria,
protocolos de comunicação.

71. Agile Tester
▶ Dimensão DevOps
 Pipeline de integração contínua
 Configuração de scripts
 Prática de Entrega Contínua

72. 3. Automação de Testes
JUnit + Coverage, Selenium Webdriver, Postman + Rest-assured

73. Ferramentas
https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016

74. Stack Ferramentas
▶ Ferramentas Qualidade e Testes
▶ Delivery Contínuo
+

75. Ferramentas
1.Testes Unitários
JUnit, Code Coverage Tools
2.Bug Tracking Tools
3.Testes Funcionais
Selenium Webdriver (Locators e Page Objects)
4.Testes de API
Postman + RestAssured

76. JUnit
▶ Desenvolvido em 1997 por Erich Gamma e Kent Beck.
▶ Framework livre para apoiar teste de unidade de programas
Java, facilitando a escrita de testes automatizados.
▶ Importante para teste de regressão: testes podem ser
reexecutados automaticamente.
▶ Integração com as principais IDEs e grande comunidade de
usuários.
 Assertivas para testar resultados esperados
 Fixtures para reutilização de dados para teste
 Test Suites para organizar e executar conjuntos de testes
 Interface gráfica e textual para execução de testes
Funcionalidades inclusas

77. JUnit
▶ Teste unitário com JUnit
 Dado uma classe CartaoCredito, criar outra classe
CartaoCreditoTest para testar ela, contendo vários métodos
de casos de teste para executar.
 Cada caso de teste procura resultados específicos e passa ou
falha.
▶ JUnit fornece comandos "assert" para nos ajudar a escrever
testes.
 Colocar chamadas a asserções em seu método de teste para
checar coisas que você espera ser verdade. Se elas não
forem, o teste irá falhar.
A ideia

78. JUnit
▶ Classe de Testes: estender a classe TestCase (extends
TestCase).
▶ A classe pode conter mais de um método de teste (caso de
teste)
▶ Assertivas: verificar se o teste passou ou falhou.
Método Descrição Teste passa se
assertEquals(a,b) Compara dois valores a.equals(b)
assertFalse(a) Avalia uma expressão
boleana
a == false
assertTrue(a) a == true
assertNotNull(a) Compara uma variável
com nulo
a != null
assertNull(a) a == null
assertNotSame Compara dois objetos a == b
assertSame a !=b
fail() Causa uma falha no
teste atual

79. JUnit
▶ JUnit 5 (Lambda, Assumptions ...)
https://www.infoq.com/articles/JUnit-5-Early-Test-Drive

80. JUnit
▶ JUnit 5 (Lambda, Assumptions ...)

81. JUnit
▶ Importar os seguintes pacotes
 import org.junit.Test e
 import static org.junit.Assert.*
Annotation Descrição
@BeforeClass Roda somente uma vez antes de todos os
testes da classe
@Before Antes de cada caso de teste
@Test Identifica o caso de teste
@After Depois de cada caso de teste
@AfterClass Roda somente uma vez após todos os testes
da classe

82. JUnit – Hamcrest
http://www.vogella.com/tutorials/Hamcrest/article.html
Gerais Lista Maps e Arrays
 allOf e anyOf
 Igualdade entre objetos usando equals:
equalTo
 Compara tipos:
instanceOf, isCompatibleType
 Null:
notNullValue, nullValue
 assertThat(list, hasSize(3));
 assertThat(list, contains(5, 2, 4));
 assertThat(list,
containsInAnyOrder(2, 4, 5));
 assertThat(list,
everyItem(greaterThan(1)));
 MAP: hasEntry, hasKey, hasValue
 Coleção: hasItem, hasItems
 Array: hasItemInArray

83. JUnit – Hamcrest
http://www.vogella.com/tutorials/Hamcrest/article.html
Números Strings
 Float: closeTo
 Comparar Números
greaterThan, greaterThan
OrEqualTo, lessThan,less
ThanOrEqualTo
 equalToIgnoringCase
 equalToIgnoringWhiteSpace
 containsString, endsWith, starts
With

84. JUnit
▶ Importar os seguintes pacotes
 import org.junit.Test e
 import static org.junit.Assert.*
ALT + ENTER
⌥⏎

85. Code Coverage Tools
 Cobertura (open source)
 JaCoCo / Emma / EclEmma (open source)
 JaBUTi (Java Bytecode Understanding and Testing)
 CodeCover (open source)
 Atlassian Clover (commercial)
Ferramentas

86. Exercícios JUnit + Cobertura
Prática 2 – JUnit + Cobertura
Testes Cartão (Validação - Luhn e BIN)
https://github.com/andvicente/Cartoes-CodeCoverage
Exemplo: 4556727112881899
Voltar Cobertura de Código
Cartão 9 9 8 1 8 8 2 1 1 7 2 7 6 5 5 4
2x Digitos
Pares
9 18 8 2 8 16 2 2 1 14 2 14 6 10 5 8
Somar
Digitos
9 9 8 2 8 7 2 2 1 5 2 5 6 1 5 8

87. 100% de Cobertura de Código?
▶ Não mostra a qualidade do código de testes.
 Apenas mostra que um pedaço de código foi executado.
 Entenda sua aplicação e encontre áreas com risco e
estabeleça uma meta.
▶ Fizemos testes suficientes?
 Você raramente pega bugs em produção.
 Você raramente exita em mudar um pedaço de código com
medo de causar bugs em produção.
http://martinfowler.com/bliki/TestCoverage.html

88. 100% de Cobertura de Código?
getters e setters, e todas as
Brian Marick
http://www.exampler.com/testing-com/
 Testes estão te atrasando. Mudanças simples no código
geram muita refatoração nos testes.
 Trechos que não valem a pena serem testados de forma
isolada ou são simples demais.
Testando Muito?

89. Bug Tracking Tools
▶ Mantis: http://www.mantisbt.org
▶ RedMine: http://www.redmine.org
▶ Bugzilla: http://www.bugzilla.org
▶ JIRA: http://www.atlassian.com/software/jira
▶ Trello, You Track (Jet Brains) …
▶ Testlink - Especificação
http://www.teamst.org
▶ Integração entre ferramentas!

90. Selenium
▶ http://seleniumhq.org
▶ 2004
 Jason Huggins
 Simon Stewart 2006 (Google)
▶ Testes Funcionais (Integração)
▶ Escrever testes em várias linguagens
▶ Suporte a Múltiplos Navegadores
▶ Frameworks de Teste: JUnit,
TestNG, NUnit, rspec
▶ http://seleniumhq.org/about/platforms.html

91. Selenium
▶ Selenium IDE: record/play no Firefox
▶ Selenium RC e Selenium Webdriver
 Selenium RC injeta funções javascript no navegador quando a
página é carregada.
 Selenium WebDriver controla o navegador utilizando o suporte
suporte interno do navegador.
▶ Selenium Grid: executar testes em paralelo (múltiplas
máquinas ou VMs). Integração Contínua

92. Selenium Webdriver
▶ Selenium vs Selenium 2 (WebDriver)
 Extensões ou recursos nativos oferecidos pelo
próprio navegador para controlá-lo diretamente
 Mais rápido e API mais legível
 Caixas de diálogo (por exemplo download e upload)
 Suporte para Drivers Mobile: Android e iOS
 Linguagens: Java, Ruby, Python, C#
 Suporte de Fabricantes de Navegadores: Opera, Mozilla e
Google
 Não precisa do Selenium Server

93. Selenium Webdriver
▶ XPath e CSS Locator
 Firefinder (Firefox)
 Developer Tools (Chrome) – ctrl/ + alt / + i
▶ CSS Locators
 Mais rápido
 Mais fácil de ser lido
CSS: span[name='cars’]
Xpath://body//div/spn/span/table/tr/tr/tr/td/td/t
d/td/span[@name='cars']
 Estratégia de localização do jQuery
 http://www.w3schools.com/cssref/css_selectors.asp
 http://goo.gl/41NXK (Sauce Labs)

94. Selenium Webdriver
▶ XPath e CSS Locator
 Developer Tools (Chrome) – ctrl/ + alt / + i

95. Page Objects
▶ Representa a tela de uma aplicação web como uma série de
objetos e encapsula funcionalidades de uma página.
▶ Separação de métodos de negócio por tela
TelaHome.abrir( )
TelaHome.logar(String login, String senha)
TelaHome.logoff( )
▶ Reduz a duplicação de código
▶ Faz com que os testes sejam mais legíveis e robustos
▶ Melhoram a manutenibilidade, particularmente quando há
mudanças frequentes na aplicação.
Vantagens

96. Selecionando Elementos
CSS-Locators (ID, Classe, Seleção de Elementos)
# <label id=“senha”>
label#senha ou #senha
Seleciona Elemento label com id
”senha”
. <table
class=“extratomensal”>
table.extratomensal
Seleciona tabela com classe
extratomensal
Element p Seleciona todos elementos p
Element,Element div,p Seleciona todos os elementos
<div> e <p>
Element element div p Seleciona todos os elementos <p>
dentro dos elementos <div>
Element > element div > p Seleciona todos os elementos p
onde o seu pai é o elemento div.

97. Selecionando Elementos
CSS-Locators (Tipos e Filhos)
nth-of-type ul#recordlist li:nth-of-
type(4)
4o
elemento do tipo <li>
nth-child ul#recordlist li:nth-child(4) 4o
elemento apenas se
ele for <li>
<ul id="recordlist”>
<p>Heading</p>
<li>Cat</li>
<li>Dog</li>
<li>Car</li>
<li>Goat</li>
</ul>

98. Selecionando Elementos
CSS-Locators (Atributos)
form input[name='username'] Selecionando username sem id ou
classe
input[name='continue']
[type='button']
Selecionando com mais filtros de
forma mais específica
div[id="pancakes”]
button[value="Blueberry"]
Seleciona o botão com o seu valor da
propriedade setado em Blueberry ,
sendo esse filho da div pancakes.
<form>
<input name="username"></input>
<input name="password"></input>
<input name="continue" type="button"></input>
<input name="cancel" type="button"></input>
<input type="hidden" name="vid" value="cbc-cd5-6c4f">
<input type="hidden" name="lf_cid" value="LF_0cf6d6”>
</form>

99. Selenium
Métodos Selenium (Abstração Webdriver)
selenium.click(locator)
selenium.type(locator)
selenium.selectByVisibleText
selenium.selectByValue
selenium.check(locator)
selenium.uncheck(locator)
selenium.click(locator)

100. Selenium
Métodos Selenium (Abstração Webdriver)
Texto selenium.assertText
selenium.assertTextPresent /
notPresent
Presença e Visiblidade de
Elementos
selenium.assertElementPresent /
notPresent
selenium.assertVisible
Outros selenium.getTitle()
selenium.takeScreenshot()

101. Exercícios Selenium Webdriver
Prática 5 – Selenium Webdriver
https://github.com/andvicente/SeleniumWebdriver-AulaUnivem
▶Busca Google
▶Câmbio de Moedas (UOL Economia)
▶ Limite Cota Viagens Exterior
▶TripAdvisor (Busca de Vôos)
▶ Buscar Vôo mais barato sem paradas
▶ Diferença de Preço com parada e sem parada
▶Campeonato Brasileiro
▶ Classificados Brasileiro e UEFA Champions League

102. Testes de API
▶ Postman - https://www.getpostman.com/docs/
▶ Aplicação para criar rapidamente requisições de API Rest
▶ Criar Collections
▶ Environments (Local, Produção)

103. Testes de API
▶ REST-assured é uma DSL Java para simplificar o teste de
sistemas baseados em serviços REST.
http://rest-assured.io
▶ Suporte para requisições: POST, GET, PUT, DELETE, OPTIONS,
PATCH e HEAD.
▶ Pode ser utilizado para verficar a resposta de requisições
(JSON ou XML)
▶ Validar cabeçalho e status de resposta

104. Exercícios Rest-assured
Prática 6 – Testes de API (Rest-assured)
https://github.com/andvicente/api-testing-rest-assured
▶Spotify Playlists
▶ https://developer.spotify.com/web-api
▶Checkout PagSeguro (Sandbox)
▶ https://dev.pagseguro.uol.com.br
▶ Criação Checkout – Sandbox (https://sandbox.pagseguro.uol.com.br )
▶ Pagamento com Cartão de Crédito (Selenium)

105. 4. Continuous Integration and Delivery
Introdução e Prática

106. +
▶ Continuous Integration and Delivery

107. +
▶ Continuous Integration and Delivery
https://www.thoughtworks.com/continuous-delivery

108. Continuous Integration and Delivery (PS)
Evolução Arquitetura do PagSeguro
Monolítico (Micro)serviços➡️
https://www.infoq.com/br/presentations/apache-mesos-para-operar-
grandes-sistemas-e-microservicos
Administrar o CAOS �
Delivery Contínuo
Cultura de Qualidade & Melhoria Contínua
Times Remotos
DesafiosDesafios

109. +
▶ Continuous Integration and Delivery
▶ CI: Código integrado a um repositório com a maior frequência
possível
▶ Processo de Build rápido, automatizado e incluindo testes
▶ Feedback Frequente 
▶ CD: Facilitar o processo de entrega em produção

110. +
▶ Continuous Integration and Delivery
“More Agile Testing: Learning Journeys for the Whole Team” (Janet
Gregory and Lisa Crispin)

111. +
Prática 7 – Continuous Integration
▶JUnit+ JaCoCo + Slack integration
▶Build Pipeline
https://github.com/andvicente/Cartoes-CodeCoverage

112. +
▶ Continuous Integration and Delivery (Referências)
▶ https://dzone.com/articles/get-started-with-jenkins-20-with-
docker
▶ https://www.docker.com/products/docker-toolbox

113. O que não cobrimos na disciplina
▶ Mocks
▶ Ex.: EasyMock, Mockito
▶ Teste BDD
▶ Ex.: Cucumber, Concordion
▶ Teste de Carga / Perfomance
▶ Ex.: JMeter, LOCUST, BlazeMetter, Flood.io
▶ Teste Mobile
▶ Ex.: Appium, Robotium, Selendroid

114. FIM