SISTEMAS DE

INFORMAÇÕES
GERENCIAIS
Sumário

1. Apresentação I.......................................................................08
2. Introdução – Organização do Conteúdo – Conceitos de Teste I
– Testes Estáticos x Testes Dinâmicos – Testes Funcionais
(Caixa-preta) x Estruturais (Caixa-branca) – Conceitos de
Testes Níveis de Testes - As integrações podem ser do tipo
Big-Bang ou incremental - II..................................................09
3. Técnicas de Testes - Custos de Testar; da Correção e o Retorno
de Investimento em Testes - Custo da Correção - Retorno de
Investimento - Custos das Falhas.........................................20
4. Erros em Escalas da GOL - Autodestruição do Foguete Ariane
501 - Destruição da Sonda da NASA Mars Climate Orbiter - O
Processo de Teste – O Modelo V – Planejamento dos Testes ..
...............................................................................................30
5. Análise dos Riscos – Término dos Testes – Ambiente de Testes
– Massa de Dados – Ferramentas.............................................42
6. A Equipe e os Papéis nos Testes – Abordagens para Montar a
Equipe - Papéis no Processo de Teste - Certificações para
Profissionais de Testes - Técnicas Estáticas - Revisão e
Inspeção................................................................................53
7. Resumo I................................................................................62
8. Apresentação II......................................................................63
9. Casos de Teste – Conteúdo do Caso de Teste – Características
e Potenciais Problemas – Execução dos Testes – Testes
Orientados a Dados (DDT – Data Driven Test) – Automatização
dos Testes..............................................................................64
10. Gestão de Testes – Ferramenta TestLink – Gestão de Defeitos
(Conceito de Erro, Defeito e Falha) – Gestão de Defeitos
(Resolução do Defeito)...........................................................73

www.esab.edu.br 3
11. Gestão de Defeitos – Ferramenta Mantis – Gestão de Defeitos
– Ferramenta Mantis (Continuação).......................................81
12. Cobertura de Código – Ferramenta EclEMMA – Testes de
Unidade e Integração – Ferramenta Junit – Localização das
Classes de Teste ................................................................89
13. Testes com Objetos Substitutos ou Falsificados (Mock Objects)
– Ferramenta Mockito – Ferramenta Mockito – Ferramenta
Mockito (Continuação) .............................. .........................101
14. Resumo II.............................................................................109
15. Apresentação III...................................................................110
16. Desenvolvimento Orientado a Testes (TDD - Test Driven
Devlopment) - Exemplo de TDD na Prática........................111
17. SELENIUN - Ferramenta para Gravar/Executar Testes em
Browsers I - Ferramenta para Gravar/Executar Testes em
Browsers II - Ferramenta para Gravar/Executar Testes em
Browsers III..........................................................................122
18. SELENIUN - Teste de Performance e Estresse - Ferramenta
JMeter...................................................................................135
19. Integração Contínua - Controle de Versão de Código - Integração
Contínua - Ferramenta Jenkins I..........................................145
20. Integração Contínua - Ferramenta Jenkins II .......................
.............................................................................................153
21. Resumo III............................................................................159
22. Glossário..............................................................................163
23. Bibliografia..........................................................................165

www.esab.edu.br 4
Palavras do Tutor

Sobre o autor

• Professor e Consultor de Tecnologia de Informação.

• Doutorando (ITA) e Mestre (IPT) em Engenharia de

Computação, Pós-Graduado em Análise de Sistemas
(Mackenzie), Administração (Luzwell-SP), e Reengenharia
(FGVSP). Graduado/Licenciado em Matemática.

• Professor e Pesquisador da Universidade Anhembi Morumbi,

UNIBAN, e ESAB (Ensino a Distância). Autor de livros em
Conectividade Empresarial. Prêmio em ELearning no Ensino
Superior (ABED/Blackboard).

• Consultor de T.I. em grandes empresas como Sebrae,

Senac, Granero, Transvalor, etc. Viagens internacionais:
EUA, França, Inglaterra, Itália, Portugal, Espanha, etc.

Apresentação

O software passou a ser peça chave na competitividade de muitas

empresas, fazendo com que suas falhas provocassem diversos
tipos de prejuízos. Nesse cenário, para garantir a qualidade dos
softwares, a área de teste vem ganhando cada vez mais importância
e notoriedade. Para obter a atenção necessária, os testes devem
ser tratados com uma abordagem mais sistemática, deixando de
ser uma atividade dentro do processo de desenvolvimento, e
passando a ter um processo próprio, com etapas, atividades,
artefatos, técnicas, equipe, ambiente e ferramentas.

www.esab.edu.br 5
Objetivo

Apresentar de forma dinâmica os conceitos relacionados aos

testes de software e a sua importância, em conjunto com
demonstrações práticas. Proporcionar ao aluno o aprendizado
necessário para colocar em prática os principais aspectos dos
testes de software.

Para atingir esse objetivo, foram intercaladas unidades de

conceituação e recomendações, com outras de demonstração de
ferramentas gratuitas e ricas em funcionalidades, para apoiar
diferentes atividades e etapas do processo de Teste do Software.

Ementa

Apresentação dos seguintes temas: Introdução, Organização do

Conteúdo, Conceitos de Teste I, Testes Estáticos x Testes
Dinâmicos, Testes Funcionais (Caixa-preta) x Estruturais (Caixa-
branca), Conceitos de Testes Níveis de Testes, As integrações
podem ser do tipo Big-Bang ou incremental - II, Técnicas de Testes.
Custos de Testar; da Correção e o Retorno de Investimento em
Testes, Custo da Correção, Retorno de Investimento, Custos das
Falhas - Erros em Escalas da GOL, Autodestruição do Foguete
Ariane 501, Destruição da Sonda da NASA Mars Climate Orbiter,
O Processo de Teste, O Modelo V, Planejamento dos Testes -
Análise dos Riscos, Término dos Testes, Ambiente de Testes,
Massa de Dados, Ferramentas - A Equipe e os Papéis nos Testes,
Abordagens para Montar a Equipe, Papéis no Processo de Teste,
Certificações para Profissionais de Testes, Técnicas Estáticas,
Revisão e Inspeção, Casos de Teste, Conteúdo do Caso de Teste,

www.esab.edu.br 6
Características e Potenciais Problemas, Execução dos Testes,
Testes Orientados a Dados (DDT – Data Driven Test), Automatização
dos Testes - Gestão de Testes, Ferramenta TestLink, Gestão de
Defeitos (Conceito de Erro, Defeito e Falha), Gestão de Defeitos
(Resolução do Defeito) - Gestão de Defeitos – Ferramenta Mantis,
Gestão de Defeitos – Ferramenta Mantis (Continuação) - Cobertura
de Código – Ferramenta EclEMMA, Testes de Unidade e Integração
- Ferramenta Junit, Localização das Classes de Teste, Testes com
Objetos Substitutos ou Falsificados (Mock Objects), Ferramenta
Mockito, Ferramenta Mockito (Continuação) – Desenvolvimento
Orientado a Testes (TDD - Test Driven Devlopment), Exemplo de
TDD na Prática - Desenvolvimento Orientado a Testes (TDD - Test
Driven Devlopment), Exemplo de TDD na Prática - SELENIUN -
Ferramenta para Gravar/Executar Testes em Browsers I,
Ferramenta para Gravar/Executar Testes em Browsers II,
Ferramenta para Gravar/Executar Testes em Browsers III - Teste
de Performance e Estresse - Ferramenta JMeter - Integração
Contínua, Controle de Versão de Código, Integração Contínua,
Ferramenta Jenkins I - Integração Contínua - Ferramenta Jenkins
II - Integração Contínua, Ferramenta Jenkins I.

www.esab.edu.br 7
1: FUNDAMENTOS DE TESTE DE SOFTWARE

O teste de software é um processo usado para facilitar a

identificação da exatidão, integridade, segurança e qualidade do
software. Em outras palavras, um teste de software é um processo
de auditoria ou comparação entre a saída real e a saída esperada.
Com o desenvolvimento contínuo da tecnologia de teste de
software, os métodos de teste são cada vez mais diversificados e
mais direcionados. Este eixo temático fará uma descrição
introdutória sobre teste de software, buscando sistematicamente
introduzir o conceito de teste de software. Ainda, este eixo
temático fará uma organização dos conteúdos de forma simples
para uma melhor compreensão das características da disciplina
de teste de software.

Objetivo

Fornecer conhecimentos básicos sobre o conceito de teste de

software, através de uma introdução e organização dos conteúdos,
a fim de permitir que os alunos adquiram habilidades básicas, para
que mais tarde, à medida que o estudo se desenvolva, possam
obter habilidades mais complexas. Desta forma, serão
apresentados os seguintes tópicos:

www.esab.edu.br 8
Introdução

Bem-vindo ao Módulo Teste de Software!

O avanço da tecnologia nas últimas décadas em áreas que vão

dos hardwares até as linguagens de programação, proporcionou
o surgimento de milhares de software. A utilização da Internet
potencializou ainda mais esse fato, fazendo com que diversas
aplicações computacionais fizessem parte do nosso dia a dia.
Assim, o software passou a ser peça chave na competitividade de
muitas empresas, fazendo com que suas falhas provocassem
diversos tipos de prejuízos. Nesse cenário, para garantir a
qualidade dos softwares, a área de teste foi ganhando cada vez
mais importância.

Até a década de 1990, os testes eram realizados na maioria das

vezes pelos próprios desenvolvedores, e eram tratados como
uma atividade que tinha pouco tempo disponível, no cronograma
do projeto de software, para ser realizada (BERNARDO, 2008).
Desde então, diversos artigos, ferramentas e livros sobre testes
foram lançados, mas, assim mesmo, é comum ver empresas que
não dedicam a atenção necessária a essa área para garantia da
qualidade.

Portanto, o objetivo deste Módulo 1 é apresentar os principais

pontos envolvidos com o teste de software, com uma abordagem
mais sistemática; deixando de ser uma atividade dentro do

www.esab.edu.br 9
processo de desenvolvimento, e passando a ter um processo
próprio, com etapas, atividades, artefatos, ambiente, técnicas,
equipe e ferramentas.

Mesmo com todo avanço em relação aos testes, nos últimos anos;
o teste de software não é uma ciência exata. No entanto, teste
exaustivo é impossível, e para realizar os testes adequadamente
é importante realizar uma avaliação de risco.

A análise de risco é uma parte importante dos testes de software,

visto que vai determinar as áreas que precisam ser mais
cuidadosamente testadas, e em qual momento pode-se considerar
que os testes realizados foram suficientes para garantir uma
confiança adequada para liberar o software para produção.

Para atingir o objetivo, este Módulo foi baseado em livros, artigos

de especialistas, revistas especializadas e manuais de ferramentas.
Para fornecer uma abordagem conceitual aliada à prática, 8
ferramentas gratuitas, relacionadas com diferentes partes do
teste de software, serão apresentadas.

O objetivo da apresentação dessas 8 ferramentas é propiciar ao

aluno o conhecimento dos principais benefícios, facilidade de uso
e o momento adequado para usar cada tipo de ferramenta. Assim,
o Módulo não tem a pretensão de abranger todos os aspectos
dessas ferramentas, até porque o manual delas é extenso,
impossibilitando abordar em um módulo.

A Figura 1 apresenta algumas das bibliografias utilizadas como

base para à elaboração deste Módulo 1.

www.esab.edu.br 10
Figura 1: Algumas referências que serviram como base para
este Módulo
Fonte: Próprio autor

Um dos indicadores da importância e aumento de notoriedade dos

testes de software é o surgimento de várias certificações. Dentre
elas, é importante citar a Certificação Brasileira em Teste de
Software (CBTS) e a Qualificação Internacional de Teste de
Software (ISTQB - Internacional Software Testing Qualification),
cujas referências também foram consultadas para a elaboração
deste Módulo.

Os modelos de processo de melhoria de software, como CMMI

(Capability Maturity Model Integration) e o MPS.BR (Melhoria de
Processos do Software Brasileiro), exigem a implantação de
testes de software. Por exemplo, para conquistar o nível 3 do
CMMI é preciso adotar uma abordagem sistemática em relação
aos testes, que se encontra nas áreas de Verificação e Validação
deste modelo.

É importante notar que as metodologias ágeis como o XP (eXtreme

Programming) contribuíram com os conceitos de Integração
Contínua, Desenvolvimento Orientado a Testes (TDD) e
ferramentas de testes unitários no modelo xUnit, que serão

www.esab.edu.br 11
estudadas neste Módulo. Apesar de a origem ter sido em
metodologias ágeis, qualquer metodologia de desenvolvimento
pode se beneficiar dessas práticas (REIS, 2008).

Organização do Conteúdo

Nas próximas duas unidades deste Módulo, serão abordados

conceitos utilizados nas demais unidades. Portanto, as Unidades
1 e 2 apresentam conceitos como testes estáticos, dinâmicos,
funcionais (caixa-preta), estruturais (caixa-branca), tipos e níveis
de testes. As unidades seguintes apresentam conceitos
relacionados com o custo do teste, custo da falha e da correção;
o processo de teste; planejamento; ambiente; equipe; casos de
teste; execução; gestão dos defeitos; revisão e inspeção;
desenvolvimento orientado a testes (TDD) e integração contínua.

Serão apresentadas também 8 ferramentas gratuitas para:

cobertura de código, teste unitário, objetos substitutos (mock
objects), gestão de defeitos, gestão do processo de teste, teste de
estresse e de performance, testes de aplicações web e integração
contínua.

Conceitos de Testes I

Se os testes são tão importantes, por que normalmente não se

testa adequadamente? Um dos principais fatores para responder
essa pergunta é entender que a pressão por menores prazos e
valores negociados para desenvolver um software, dificilmente
contempla a realização de testes de forma adequada. Os testes
precisam de um investimento inicial maior, mas como será visto,
ao longo deste módulo, os prejuízos provocados pelas falhas
costumam justificar o investimento em um processo de testes.

www.esab.edu.br 12
Os softwares são desenvolvidos por seres humanos, que por mais
dotados de competências, não são perfeitos, sendo passíveis de
cometer erros. A verdade é que infelizmente os erros estarão
presentes no software, e se a equipe de desenvolvimento não os
encontrar, o cliente vai encontrar, já que cada vez que ele interage
com o software, ele está exercitando uma funcionalidade.

Delamaro, Maldonado e Jino (2007) citam no livro “Introdução ao

Teste de Software” que o desenvolvimento de software está sujeito
a diversos tipos de influências e problemas que acabam por gerar
um software diferente do que o cliente esperava. Dentre os
diversos fatores que podem causar esses problemas, eles
identificam que a maioria é ocasionado por uma mesma origem, o
erro humano.

Portanto, os testes devem ser realizados de uma maneira

sistemática, para evitar o acontecimento de uma das Leis de
Murphy: “Se alguma coisa pode dar errado, dará. E mais, dará
errado da pior maneira, no pior momento e de modo que cause o
maior dano possível.” (WIKIPÉDIA, 2018).

Exceto em casos triviais, a execução de testes exaustivos que

testam todas as possibilidades de combinações, entradas, etc.,
não são viáveis. Pode-se citar como exemplo, uma demonstração
simples apresentada por Falbo (2008, 71):

Suponha um programa que calcule o

exponencial de números inteiros x e y (xy).
Para testar todas as entradas possíveis todos
os números inteiros de x e y combinados
devem ser testados, gerando uma cardinalidade
de 2n * 2n, sendo n o número de bits usados
para representar um inteiro. Em uma arquitetura
de 32 bits, a cardinalidade seria 264 (232*232).

www.esab.edu.br 13
 Se cada teste puder ser realizado em 1
milissegundo, seria necessário
aproximadamente 5,85 milhões de séculos
para executar todos os testes. Adicionalmente
mesmo que o teste exaustivo fosse executado,
ele não garantiria que o software corresponde
à sua especificação. Suponha que ao invés do
xy o cliente tenha especificado a raiz de x por y
(y√ x), e o desenvolvedor por equívoco
implementou a função apresentada no
exemplo; esse erro não seria identificado pelo
teste exaustivo, e sim pela revisão dos
requisitos ou teste de aceitação.

Portanto, como afirmou Djkistra (1930-2202) “O teste não pode

nunca demonstrar a ausência de defeitos, apenas sua presença”.
(Wikiquote, 2018, n.p.).

Mesmo não sendo possível realizar testes exaustivos para provar

que o software está livre de defeitos, a condução sistemática de
testes em conjunto com as definições de critérios, riscos e
prioridades contribuem para aumentar a qualidade e confiança no
sistema.

Testes Estáticos x Testes Dinâmicos

As atividades relacionadas ao teste do software em si não envolvem

somente a execução do programa, que é o teste dinâmico.
Existem também os testes estáticos, que não precisam da
execução de um software (ou nem mesmo a sua existência) para
serem realizados. Os testes estáticos podem ser aplicados a
diferentes artefatos como a revisão de documentos de requisitos,
análise, do próprio código fonte etc.

www.esab.edu.br 14
Testes Funcionais (Caixa-preta) x Estruturais (Caixa-branca)

Os testes funcionais também são conhecidos como teste caixa-

preta, pelo fato de o testador não precisar conhecer os detalhes
da codificação. Nesse tipo de teste o testador informa os dados de
entrada e verifica se a saída/resultado está de acordo com o que
era esperado. Portanto, esse tipo de teste não tem como objetivo
saber como a funcionalidade foi implementada, mas, sim, quais
são os resultados apresentados. Avaliando somente a entrada e a
saída, o teste de caixa-preta visa identificar defeitos do tipo:

• Se o sistema aceita entradas incorretas;

• Se a saída produzida está correta;
• Se existem erros na interface;
• Se alguma funcionalidade está faltando;
• Dentre outros.

Já os testes estruturais, ou testes caixa-branca, levam em

consideração a estrutura do código fonte para identificar a
implementação e se os diferentes caminhos estão sendo cobertos
por algum tipo de teste. Assim, os testes serão elaborados para:
testar as decisões lógicas (verdadeiro/falso), testar os loops até o
limite, as variáveis estáticas e dinâmicas, dentre outros.

O teste de caixa-branca não substitui o teste de caixa-preta, e

vice-versa. Eles são utilizados em conjunto; cada um com um
objetivo distinto.

www.esab.edu.br 15
Figura 2: Teste Caixa-preta e Teste Caixa-branca
Fonte: Costa (2013)

Conceitos de Testes II

Níveis de Testes

Os níveis de testes normalmente são classificados como: teste

unitário, teste de integração, teste de sistema e teste de aceitação.

Os testes unitários são realizados nas menores unidades do

software, que normalmente são os métodos ou funções.
Usualmente são os próprios desenvolvedores que realizam os
testes unitários do próprio código. O seu objetivo é buscar por
erros de lógica e programação, nas unidades em separado, de
forma a garantir que essas unidades funcionem corretamente e
isoladamente. A justificativa clara para realizar os testes de unidade
é se uma unidade não funcionar isoladamente, ao ser integrada
com outras unidades, o erro será propagado e mais tempo será
gasto para identificá-lo. Os testes unitários podem ser realizados
após a implementação da unidade, ou até mesmo antes de seu
código ser implementado, sendo essa última uma abordagem de
metodologias ágeis (Mais detalhes, a respeito de desenvolvimento
orientado a testes, serão abordados adiante).

www.esab.edu.br 16
Os testes de integração verificam se as partes que funcionavam
isoladamente continuam a funcionar após serem combinadas.
Portanto, são verificadas as integrações entre unidades,
componentes, sistemas, camadas, etc.

As integrações podem ser do tipo Big-Bang ou incremental.

A integração Big-Bang consiste na realização do teste após

todas as unidades, componentes, etc.; serem integrados, testando
tudo de uma só vez. A integração incremental consiste em integrar
e testar o programa gradativamente, começando com uma
integração pequena e testando; constituindo uma nova integração
somente quando os testes da integração menor forem bem-
sucedidos. A integração Big-Bang é mais arriscada, porque
quanto maior for a abrangência da integração mais difícil será para
identificar a parte que originou a falha. Sem contar que testar a
integração, após tudo ter sido desenvolvido, faz com que os erros
sejam encontrados tardiamente. Portanto, para evitar esses tipos
de problemas, recomenda-se o uso da Abordagem Incremental.

Testes de sistema avaliam o comportamento do sistema como

um todo. Além das funcionalidades, as características não
funcionais como: performance, segurança, usabilidade, dentre
outros, são avaliados. Esses quesitos podem ser avaliados
também nos outros níveis de teste, e devem ser feitos por completo
nos testes de sistema. Nesse nível, é importante que o ambiente
de teste se pareça, ao máximo, com o ambiente de produção, de
forma que os testes reproduzam o máximo possível o uso real.

Testes de aceitação são realizados pelos clientes e/ou usuários

do sistema com o objetivo de verificar se o sistema está atendendo

www.esab.edu.br 17
ao que era pretendido e foi especificado. Esse nível não tem como
objetivo caçar defeitos e sim verificar se o sistema está «conforme».
Engana-se quem pensa que esses testes devem ser realizados
somente ao final do desenvolvimento. Eles devem ser realizados
o quanto antes, para que os desvios possam ser corrigidos
enquanto há tempo e não tenham sido propagados. Deixar os
testes de aceitação somente para o final representa um risco
altíssimo de reprovação do cliente, gerando diversos tipos de
prejuízos que englobam o custo do retrabalho, perda do tempo
certo para lançar o produto, dentre outros.

Saiba Mais

É válido lembrar que:

Cada projeto apresenta características distintas, que

dependem do tamanho do software, da tecnologia utilizada
para o seu desenvolvimento e de muitos outros fatores.
Assim, a escolha adequada dos tipos de testes que serão
adotados torna-se primordial.

Fonte: DEVMEDA, 2013.

www.esab.edu.br 18
 Reflexão

Em relação à performance de um site, a revista Exame PME, de junho

de 2011, traz uma informação interessante. Na reportagem “Quem é
mais rápido vende mais” são apresentados dados de uma pesquisa
informando que:

• Cada 1 segundo que um site demora a mais para carregar;

significa perda de 7% das vendas

• 57% dos consumidores abandonam um site depois de esperar 3

segundos para visualizar os dados

• 80 % desses consumidores não voltam ao site por pelo menos 6

meses

• Desde 2008, a Amazon estima ter aumentado suas receitas em

1%, cada vez que suas páginas ficaram um décimo de segundo
mais rápidas.

www.esab.edu.br 19
Técnicas de Testes

A seguir, serão apresentadas algumas técnicas de teste.

• Teste de regressão: consiste em testar novamente o

software (ou partes dele), após o desenvolvimento de uma
mudança. Assim, o objetivo é verificar se a introdução de
uma mudança, como por exemplo, novo código ou até
mesmo a correção de um defeito, não provocou um novo
defeito em uma parte do software que funcionava
corretamente, ou seja, verificar que não ocorreu nenhum
efeito colateral. A reexecução dos testes muitas vezes
não é realizada da forma adequada por ser encarada como
uma tarefa cansativa e repetitiva, mas é preciso avaliar o
risco de uma parte que funcionava apresentar defeitos.
Como os testes de regressão são realizados muitas vezes,
se tornam bons candidatos a serem automatizados.

• Teste de estresse: o objetivo do teste de estresse é avaliar

como o sistema se comporta em condições extremas.
Dessa forma, ele deve ser realizado para consumir os
recursos disponíveis de forma anormal, testando: restrições
de memória, espaço em disco, CPU, dentre outros. Para
isso, testa-se com quantidade elevada de acessos
simultâneos, volume de dados acima da média esperada,
etc. Nessas condições o comportamento do sistema será
avaliado. É importante que o ambiente de testes seja o
mais parecido possível com o ambiente de produção.

www.esab.edu.br 20
 • Teste de recuperação: verifica se o sistema será
restabelecido à sua operação normal e de forma íntegra
após ocorrer alguma falha, como por exemplo: queda da
rede, falha de hardware, perda de acesso ao banco de
dados, dentre outros. Para tanto, esses e outros tipos de
falhas são provocadas pelo testador. O teste de recuperação
avalia não só a recuperação automática do sistema, mas
também os procedimentos manuais necessários. Dessa
forma, os testes avaliam procedimentos com respectivos
checklilsts e podem envolver inclusive a restauração de
backup. Portanto, verifica-se, também, se o backup está
sendo realizado e armazenado adequadamente. Outro
ponto avaliado é a quantidade de tempo necessário para o
software se restabelecer, depois da realização dos
procedimentos.

• Teste de performance: o objetivo do teste de performance

é avaliar se o sistema consegue obter um desempenho
determinado em quesitos como, tempo de resposta,
utilização do hardware, dentre outros. Não deve ser
confundido com o teste de estresse, visto que, nesse caso,
o objetivo é verificar se a performance está como esperada
em condições normais, e não em condições extremas.

• Teste de segurança: os testes de segurança são executados

para garantir que os mecanismos de segurança do software
vão protegê-lo em relação à integridade, confidencialidade das
informações e proteção do software. Esse tipo de teste pode
necessitar de contratação de terceiros, visto que especialistas
poderão utilizar técnicas e conhecimentos específicos para
invadir o software, sendo que esses conhecimentos não
costumam ser de conhecimento de analistas, desenvolveres
e testadores em geral.

www.esab.edu.br 21
 • Teste paralelo: a referência do CBTS chama de teste
paralelo a execução da nova versão do software em conjunto
com uma versão antiga, para comparar se os resultados
apresentados são iguais.

Custos de Testar; da Correção e o Retorno de Investimento

em Testes

O autor do livro The Art of Software Testing (A Arte de Testar

Software), Glenford Myers (2011) estima que 50% do custo total
do projeto são gastos com as atividades relacionadas ao teste de
software. Embora outros autores apresentem estimativas
diferentes é importante identificar onde esses custos estão
alocados.

O teste de software consome recursos principalmente em:

• Profissionais: horas gastas pelos profissionais da equipe

(desenvolvedores, analistas de teste, testadores, etc.) com
atividades de testes, custos com treinamento da equipe,
dentre outros.
• Equipamentos: máquinas necessárias para permitir a
criação de um ambiente de teste adequado, que permita
simular o ambiente de produção.
• Ferramentas: softwares necessários para gerenciar o
processo de teste e os defeitos, preparar as bases de dados,
realizar testes unitários, de integração, aceitação, regressão,
e demais testes.

Portanto, para implantar um processo de teste de software será

necessário investir um valor maior no início. Entretanto, o retorno

www.esab.edu.br 22
desse investimento tende a ser muito maior do que se os testes
não fossem realizados de forma planejada e organizada.

A Figura 3 demonstra, de forma simples, o aumento do investimento

inicial com a implantação de um processo de testes bem como
retorno de investimento proporcionado.

Figura 3: Economia proporcionada ao investir em testes de

software
Fonte: Próprio autor

Como se pode perceber na Figura 3, a parte da esquerda representa

um projeto que não possui um processo de teste formalizado.
Mesmo não sendo formalizado, esse projeto consome recursos
com testes; visto que alguns testes aleatórios são realizados pelos
desenvolvedores e eventualmente por algum outro membro da
equipe. Já no projeto da direita, que possui um processo de teste
estabelecido, o custo com a realização dos testes aumenta em
relação ao anterior (custo com pessoas, ferramentas, etc.) e o
custo das falhas diminui, proporcionando uma economia ao longo
do tempo. O Custo da Falha, representado de forma resumida na
figura, engloba o custo do retrabalho, correção e prejuízos

www.esab.edu.br 23
ocasionados pela falha; desde prejuízo de imagem da equipe
desenvolvedora até prejuízos financeiros, como por exemplo,
processos judiciais.

Custo da Correção

No processo de desenvolvimento de software com as etapas de:

Especificação de Requisitos, Análise, Projeto, Implementação e
Implantação; quanto mais tarde um defeito for encontrado, maior
será o custo para corrigi-lo. E não é difícil visualizar o motivo desse
aumento, visto que uma simples declaração errada, nos requisitos,
pode gerar de duas a três decisões equivocadas na etapa de
análise/projeto, podendo ocasionar uns vinte erros introduzidos
no desenvolvimento (BLACK, 2005). É como se fosse uma bola
de neve que aumenta na medida em que ela desce morro abaixo.

Essa percepção de que: quanto mais cedo o defeito for encontrado

mais barato será a sua correção é antiga. Barry Boehm já abordava
esse tópico em seu artigo de 1976 e Glenford Myers em seu livro
The art of sotware testing (A arte de testar software) de 1979. A
declaração de Myers ficou famosa, sendo conhecida como a
Regra 10 de Myers, em que ele alega que o custo de corrigir um
defeito aumenta 10x por cada etapa em que o projeto de software
avança.

O custo de correção aumenta ainda mais se o erro for detectado

externamente (pelo cliente), após a entrega do software, do que
internamente pela equipe desenvolvedora/testadora. O especialista
Rex Black (2010) estima que um defeito encontrado por um
desenvolvedor, custa, em média, $10 para ser corrigido, enquanto
que, se for identificado por um testador custará $100 e pelo cliente
$1000. Para visualizar melhor esses custos, é importante pensar

www.esab.edu.br 24
no processo. Quando o desenvolvedor identifica o defeito, ele vai
e corrige. Caso esse mesmo defeito seja identificado por um
testador, ele terá que reportar para que o desenvolvedor o
identifique e conserte. Em seguida, uma nova versão deverá ser
disponibilizada para o testador verificar se o erro foi, de fato,
corrigido e se nenhum outro foi introduzido com a correção
(realização do teste de regressão). Portanto, pode-se perceber
como é mais caro quando o defeito é identificado pelo testador.

Quando o defeito é identificado pelo cliente, além dos passos

descritos anteriormente, existe o aumento do custo com o suporte
técnico que atenderá o cliente e de implantar a nova versão do
software, sem contar os possíveis custos intangíveis com
processos judiciais e impactos, na reputação da empresa
desenvolvedora (BLACK, 2010).

Adicionalmente, com o passar dos anos, os custos podem

aumentar de maneira exorbitante, visto que pode ser difícil
encontrar algum desenvolvedor que trabalhou no software
(problema agravado se o software não tiver uma documentação
adequada) e/ou então encontrar um profissional com experiência
adequada em uma linguagem de programação/plataforma que se
tornou obsoleta.

Então, se é fácil perceber pelos motivos citados que quanto mais

cedo o defeito for identificado e corrigido, menor será o seu custo,
por que muitos gestores ignoram a realização adequada de testes?
A resposta é: eles não visualizam o teste como um investimento.
Normalmente enxergam o teste como uma atividade custosa, que
requer muito tempo e investimento e que não ajudará o software
ficar pronto mais cedo, em um cenário que, na maioria das vezes,
a pressão por prazo e as margens de lucro são bem pequenas.

www.esab.edu.br 25
Portanto, para visualizar que o teste deve ser visto como um
investimento; é importante observar a situação descrita a seguir.

Retorno de Investimento

Para entender melhor o retorno de investimento proporcionado

pelos testes, deve-se tomar como base o seguinte estudo de caso
hipotético, apresentado por Rex Black (2010).

Um software implantando em um cliente possui uma nova versão

liberada a cada 3 meses. Em média, cada nova versão possui
1000 novos defeitos. A equipe desenvolvedora desse software
encontra em média 250 erros antes de liberar a versão, sendo que
o restante (750) é encontrado pelo cliente. Tendo como base a
estimativa anterior do próprio Rex Black (2010), que um erro
encontrado por um desenvolvedor custa em média $10 e pelo
cliente custa $ 1000, esse cenário, que não possui um processo
formal de teste, gera um custo de $750.000 por versão, e uma
insatisfação imensa no cliente. Para tentar melhorar essa situação,
o gerente do projeto consegue investir $70.000 por versão em
testes manuais para minimizar os impactos. Sendo assim, a equipe
dedicada para testes identifica mais 350 defeitos que são corrigidos
antes de lançar a versão. Partindo da estimativa que cada defeito
encontrado por um testador custa em média $100, o retorno do
investimento é 350%, conforme apresentado na Tabela 1 a seguir.

www.esab.edu.br 26
Tabela 1: Retorno de Investimento em Testes

Fonte: Black (2010), adaptado.

Percebendo o retorno do investimento, o gerente do projeto

consegue pleitear um investimento de mais $12.500, por versão,
para investir em automatização dos testes, encontrando 150
defeitos a mais. Dessa forma, o retorno de investimento obtido
seria de 445%.

Apesar desse estudo de caso ser hipotético, o renomado

especialista Rex Black (2010) afirma ter presenciado retorno de
investimento, em testes, variando de 50% a 3200%. Entretanto,
assim como qualquer outro investimento, somente disponibilizar a
verba não é garantia de sucesso, visto que existem formas corretas
e erradas de se investir. Se o dinheiro não for investido com a
equipe, ferramentas e técnicas adequadas, o resultado pode ser
negativo e frustrante.

www.esab.edu.br 27
Custos das Falhas

O National Institute of Standards and Technology (NIST), ou em

português Instituto Nacional de Tecnologia e Padrões, é uma
agência do Departamento de Comércio dos Estados Unidos. Em
2002 o NIST elaborou um estudo para estimar o custo anual
provocado por falhas de software. O estudo foi intitulado The
Economic Impacts of Inadequate Infrastructure for Software
Testing, ou em português, O Impacto Econômico da Infraestrutura
Inadequada para Testes de Software. (TASSEY, 2002).

O impacto das falhas de software é alto devido ao fato de muitos

empreendimentos, desde indústrias à medicina, dependerem de
software. Segundo estimativas desse estudo, as falhas de
software são predominantes e prejudiciais ao ponto de custar à
economia americana $59,5 bilhões de dólares anualmente. Os
autores estimaram também que pouco mais de um terço desse
valor ($22,2 bilhões) poderiam ser eliminados com a implantação
de processos de testes que permitissem identificar (e
consequentemente corrigir) mais cedo e de maneira mais efetiva
os defeitos de software.

Algumas falhas de software podem causar prejuízos imensos.

Vamos ver agora alguns exemplos de falhas de software que
viraram notícias.

www.esab.edu.br 28
 Estudo Complementar

Conheça
Rex Black:
Rex Black é um dos especialistas mais
reconhecidos em teste de software. Autor
de livros relacionados aos testes, dentre
eles o popular “Managing the Test Process”
com mais de 25.000 cópias vendidas ao
redor do mundo. Também é palestrante e
autor de vários artigos (muitos deles podem
ser encontrados em http://www.rbcs-us.
com/).

Durante 4 anos foi presidente do ISTQB e

um dos autores do Syllabus da certificação
desse instituto.

www.esab.edu.br 29
Erros em escalas da GOL

Veja a seguir parte da notícia publicada no portal Terra (CAMPOS,

2010, n.p.) sobre o transtorno provocado por uma falha de software:
“Gol diz à Anac que falha em software causou erro em escalas.”

Figura 3: Passageiros aguardam para fazer check-in no aeroporto

de Guarulhos
Fonte: CAMPOS, 2010.

A Agência Nacional de Aviação Civil (Anac)

informou nesta terça-feira que a companhia
aérea Gol disse que um problema no software
para planejamento de escala da tripulação
gerou dados incorretos que resultaram no
“planejamento inadequado da malha aérea e
da jornada de trabalho dos tripulantes”. Hoje, a

www.esab.edu.br 30
 Gol foi convocada pela agência a apresentar
um plano de ação para atender os passageiros
de voos cancelados ou atrasados. A companhia
operava cerca de 70% dos voos atrasados
ontem em todo o País. De acordo com a Anac,
a Gol afirmou que o problema no sistema
aconteceu em julho, durante um upgrade no
programa. “Por essa razão, foi adotada
novamente a configuração de escala do mês
anterior”, disse a agência, em nota: “O sistema
era utilizado há três meses, segundo a
companhia, e com o conhecimento da Anac.
(CAMPOS, 2010, n.p.)

Autodestruição do Foguete Ariane 501

Em junho de 1996, aproximadamente 37 segundos após o seu

lançamento o foguete Ariane 501 explodiu em voo.

O foguete possuía um sistema referencial inercial (SRI) para medir

a trajetória. O SRI 2 era o principal, sendo que o SRI 1 funcionava
como sistema redundante para assumir em caso de falhas no
primeiro. Ao invés de enviar os dados corretos da altitude, o SRI 2
enviou um código de erro decorrente de uma falha no software. Só
que o SRI 1 não pode entrar em operação, visto que 72
milissegundos antes apresentou o mesmo problema que o SRI 2.

A falha foi provocada pela conversão de um float de 64 bits para

um número inteiro com sinal de 16 bits, referente à velocidade
horizontal para a plataforma. Na tentativa da conversão, foi gerado
um número maior do que o comportado nos 16 bits. O motivo

www.esab.edu.br 31
dessa conversão estar vulnerável não foi identificada, uma vez
que nenhum comentário no código fonte justificava esse fato,
sendo que existiam outras conversões com a proteção adequada.
O foguete e a carga destruída estavam avaliados em $ 500 milhões
de dólares.

Destruição da sonda da NASA Mars Climate Orbiter

A NASA enviou uma sonda para Marte para poder estudar o clima
deste planeta. A sonda Mars Climate Orbiter deveria entrar na
órbita do planeta ao atingir uma altitude aproximada de 150 km.
Porém, devido a um erro de conversão de medidas, a sonda
entrou em uma altitude inferior, provocando a sua destruição. A
conversão que não foi realizada era de medidas inglesas para o
sistema métrico. O veículo espacial foi lançado no dia 11 de
dezembro de 1998 e seu último sinal foi recebido em 23 de
setembro de 1999.

Os exemplos de incidentes apresentados nesta unidade

apresentam alguns prejuízos financeiros, e de tempo, ocasionados
por falhas de software. Existem outras falhas conhecidas que,
infelizmente, além das perdas financeiras, provocaram a perda
de vidas, como por exemplo, o caso do Therac-25; um acelerador
médico utilizado para tratar tumores.

O Processo de Teste

É comum em projetos de software encontrar os testes sendo

tratados como uma atividade dentro do processo de

www.esab.edu.br 32
desenvolvimento. Nessa abordagem, muitas vezes os testes são
iniciados após a etapa de desenvolvimento. A Figura 4, ilustra
esse caso.

Figura 4: Abordagem de Testes como uma Atividade no Processo

de Desenvolvimento
Fonte: Próprio autor.

Entretanto, para aumentar a qualidade do projeto, os testes

precisam ter um processo próprio não sendo mais tratado apenas
como uma atividade dentro do processo de desenvolvimento,
conforme apresenta a Figura 5:

www.esab.edu.br 33
Figura 5: Abordagem de Testes com um Próprio
Fonte: Próprio autor.

Essa abordagem é importante para dar uma ênfase maior aos

testes. Assim, o teste passa a ter as etapas estruturadas possuindo
atividades, artefatos, métodos, papéis e responsabilidades. Esse
processo deve ser iniciado em paralelo com o início do projeto de
software e, normalmente, deve ser realizado dentro do prazo do
processo de desenvolvimento, ou seja, de forma geral o cronograma
do projeto não será aumentado para realização dos testes.

Mesmo sendo um processo e não mais uma atividade, o processo

de teste e o de desenvolvimento estão interligados (conforme
demonstrado a seguir no Modelo em V), mas possuem alguns
indicadores distintos. Tome como exemplo o indicador Defeitos
Encontrados: quanto maior o número de defeitos encontrados,

www.esab.edu.br 34
mais bem-sucedidos consideram-se os testes, e menos o processo
de desenvolvimento.

Um processo é constituído por um conjunto de tarefas e atividades,

sendo que algumas podem ser sequenciais enquanto outras são
realizadas em paralelo. De forma geral, as principais atividades do
processo de teste são: planejamento, preparação, especificação,
execução e entrega/avaliação (RIOS; MOREIRA, 2007).

O Modelo V

A representação gráfica que é mais utilizada para demonstrar a

integração entre o desenvolvimento e os testes é o Modelo V.
Existem algumas variações do Modelo V, mas, de forma geral,
ele é representado conforme Figura 6:

Figura 6: Forma usual de representar o Modelo V (1)

Fonte: Próprio autor.

www.esab.edu.br 35
Outras formas de representação do modelo V, diferentes da figura
anterior, existem. O próprio Syllabus (documentação) da
certificação de testes ISTQB, cita o modelo V sem apresentar
nenhuma figura e nem mesmo informar os nomes das quatro
etapas de desenvolvimento.

Alguns autores criticam esse modelo, como por exemplo, James

Christie. Christie alega que existem tantas variações do modelo
em V que na prática podem significar qualquer coisa. As
representações normalmente compartilham o formato de V com
uma seta ligando os estágios equivalentes em cada lado. Mas
qual é o significado dessas setas?

1. O teste das entregas de cada etapa do desenvolvimento?

2. O planejamento dos testes em paralelo a cada etapa do
desenvolvimento?

Figura 7: Forma usual de representar o Modelo V (2)

Fonte: Próprio autor.

Seguem abaixo algumas críticas dos equívocos que podem ser

ocasionados por conta da interpretação do modelo V baseados
em Christie (2008), e aproveitando o gancho das críticas, algumas

www.esab.edu.br 36
recomendações de boas práticas de testes (que na verdade
independem do modelo adotado).

1. Desencoraja a participação do usuário avaliando as

funcionalidades e interface antes da etapa de Teste de
Aceitação, que de acordo com a representação ocorre
mais tardiamente no projeto.

a. Recomendação: Idealmente, a prototipação e testes

cedo devem ser incluídos para identificar problemas
quando são mais baratos de resolver. Não é raro
encontrar projetos que são submetidos para o cliente
aprovar somente ao final e o cliente não aprova o que
foi entregue, gerando um imenso prejuízo (para ambas
as partes) e insatisfação. Portanto o planejamento do
projeto deve contemplar os testes de aceitação em
todas as etapas, submetendo, sempre que possível,
às telas (mesmo que protótipos) e funcionalidades
para aprovação do cliente.

2. Caso ocorra o atraso no tempo do desenvolvimento, sobrará

pouco tempo para realização dos testes, visto que a
interpretação pode deixar a entender que os testes são
realizados após o desenvolvimento.

a. Recomendação: É importante que os testes ocorram

em paralelo durante todo o processo

3. Começar as respectivas revisões e testes, em paralelo com

as etapas de desenvolvimento, não deve significar revisão
e aceite ao final de cada etapa.

www.esab.edu.br 37
 a. Recomendação: Revisões e testes devem ser
realizados enquanto os documentos/diagramas são
elaborados. Testadores devem se envolver na revisão
de documentos o mais cedo possível ao longo do ciclo
de desenvolvimento.

Independente da representação gráfica utilizada é importante

visualizar que o processo de desenvolvimento e o de testes andam
juntos para proporcionar um aumento na qualidade do projeto do
software.

Planejamento dos Testes

Para elaborar um planejamento de testes, é importante identificar

as seguintes questões, conforme aponta McGregor e Sykes
(2001):

• Quem deve realizar os testes?

• Quais partes deverão ser testadas e receber mais
atenção?
• Em qual momento os testes serão realizados?
• Como os testes serão realizados?
• Quanto de teste é adequado?

O planejamento dos testes visa minimizar os riscos e evitar

desperdícios de tempo e dinheiro. Se os testes forem realizados
ao acaso, o esforço gasto tende a ser um prejuízo e não proporcionar
um retorno do investimento, visto que muitos defeitos não serão
identificados antes do software ir para produção.

www.esab.edu.br 38
E como em qualquer planejamento. O planejamento de testes
após ter sido realizado no início deve ser revisado e atualizado até
o término do projeto, para não ficar engessado e desatualizado,
permitindo corrigir o rumo na ocorrência de imprevistos. Se o
planejamento do desenvolvimento mudar, o planejamento de
testes tem que ser reavaliado.

Esse planejamento é feito em um documento de Plano de Testes

que essencialmente deve conter: o escopo, o processo de teste
definido, os profissionais, ferramentas, ambiente/hardware,
estimativas financeiras, cronograma e riscos. Esses são itens
importantes, mas a composição do documento varia de empresa
para empresa, sendo um fator limitante os recursos disponíveis
principalmente de tempo e dinheiro. Um exemplo de modelo de
plano de testes é o padrão IEE 829.

Os autores do livro, em referência para a certificação brasileira

CBTS, citam que o Plano de Testes deveria seguir o modelo de
Plano de Projeto do PMBOK, que é o conjunto de práticas para
gestão de projetos, publicado pelo PMI (a principal associação
mundial de gerenciamento de projetos). Eles identificaram que é
possível fazer uma relação entre os dois modelos.

De forma geral, um bom Plano de Testes abordará questões como:

o que será testado, as funcionalidades que serão testadas e as
que não serão testadas em conjunto com o motivo, o processo
com as principais técnicas e ferramentas que serão utilizadas, os
critérios para considerar os testes concluídos, os artefatos que
serão produzidos pelo processo de testes (casos de testes,
relatórios, etc.), indicadores de qualidade (elaborados em conjunto
com o cliente), a necessidade de aquisição de suprimentos como
hardware e software, necessidade de treinamento da equipe, as

www.esab.edu.br 39
responsabilidades, riscos do projeto de teste (ex: risco de
determinado profissional ficar ausente, ou de ter que utilizar uma
ferramenta nova que ninguém tem experiência), risco do negócio
e das funcionalidades do software, custo e cronograma previstos.
Abordando esses itens, o planejamento visa proporcionar ações
preventivas ao invés de reativas, de forma que os riscos sejam
minimizados e as medidas (como por exemplo, compra de
hardware/software) sejam realizadas no momento certo para
evitar atrasos.

Estudo Complementar

Como os testes são realizados na empresa que

você trabalha? Existe algum tipo de abordagem
sistemática (casos de teste, apoio por ferramentas,
automatização de testes, definição de papéis e
processos, etc.)? Quais?

www.esab.edu.br 40
 Reflexão
Com uma breve pesquisa na Internet é possível
achar várias outras falhas de software que
ficaram famosas.
É possível inclusive assistir o vídeo de destruição do
foguete Ariane 5. Um dos endereços disponíveis é: http://
www.youtube. com/watch?v =gp_D8r-2hwk

www.esab.edu.br 41
Análise dos Riscos

O planejamento está fortemente relacionado com a avaliação

dos riscos que é fundamental para definir o que será testado e
em qual momento os testes podem ser considerados
terminados. Esse ponto é bem importante porque não tem como
realizar testes exaustivos para garantir que o sistema está livre de
defeitos então é preciso garantir que as partes mais críticas do
sistema foram testadas.

São avaliados os riscos, ou seja, potenciais situações que, se

acontecerem, podem gerar diversos tipos de prejuízos e perdas
para a organização. Dessa forma, as ameaças e vulnerabilidades
são analisadas para identificar potenciais formas de controle que
podem prevenir, ou minimizar os prejuízos.

A análise do risco avalia a probabilidade de ocorrência com

gravidade do impacto do dano causado. Essa análise deve ser
feita ao longo de todo o projeto, uma vez que a gravidade e o
impacto podem mudar com o decorrer do tempo. Por exemplo, no
início do projeto a probabilidade de invasão ao software quando
estiver pronto pode ser alto, mas no decorrer do desenvolvimento
o surgimento de um componente de segurança que pode ser
acoplado ao software diminui os riscos. A avaliação deve contemplar
tanto os riscos referentes ao projeto e processo de teste em si,
quanto os riscos inerentes ao negócio, como por exemplo, as
funcionalidades que contemplam áreas mais críticas.

www.esab.edu.br 42
Quanto ao projeto de teste os riscos já começam no orçamento e
no cronograma. Se a verba e/ou o tempo disponível para os testes
forem poucos, os testes serão realizados inadequadamente,
aumentando muito a probabilidade dos defeitos serem encontrados
no software já implantado, potencializando, assim, os prejuízos.
Muitas vezes, a empresa que está orçando o desenvolvimento do
software não contempla na proposta comercial o custo e tempo
para os testes, percebendo que tomou prejuízo somente no
momento dos testes de aceitação quando o cliente não aprova o
que lhe foi apresentado. Portanto, no fechamento do contrato é
fundamental negociar prazos e custos adequados que contemplem
a realização dos testes. Outros riscos envolvem a qualificação da
equipe, utilização de uma ferramenta nova para realização dos
testes, ambiente de teste pouco parecido com o ambiente de
produção, inadequação de metodologias, processo e controle dos
artefatos de teste.

A realização dos testes custa dinheiro e o investimento necessário

aumenta na medida em que a cobertura dos testes aumenta. A
análise de riscos bem realizada proporciona uma destinação
coerente dos esforços, priorizando as partes que apresentam
maior probabilidade de ocorrência x impacto de perda (risco) de
forma que o teste tenha o maior nível possível de confiabilidade
no tempo disponível (RIOS;MOREIRA, 2007).

Portanto, é necessário realizar uma análise de custo x benefício

para avaliar até que ponto vale a pena investir em testes,
respondendo perguntas como: O custo da ocorrência do defeito
é muito maior do que o custo da sua prevenção?

Uma forma de se estabelecer a prioridade é definir quantitativamente

a probabilidade e severidade (impacto) da ocorrência. A Tabela 2

www.esab.edu.br 43
apresenta um exemplo simples de análise quantitativa de risco
utilizando escalas como 1, 5, 10, 15; sendo que quanto maior o
número maior a prioridade.

Tabela 2: – Exemplo simples de cálculo de prioridade de

funcionalidade a ser testada

Algumas das formas de determinar o risco são: intuição baseada

na experiência de profissionais, consenso da equipe e estimativas.
Essa última se baseia em dados para o cálculo, como por exemplo:
Quanto custa cada hora que essa máquina fica parada sem
produzir? Quanto se perderá, por minuto, se o site ficar fora
do ar?.

Adicionalmente, pode-se utilizar também o Princípio de Pareto

adaptado, em que 20% do software são responsáveis por 80%
das funcionalidades mais utilizadas. Para determinar quais são
essas funcionalidades mais utilizadas, se o software já estiver em
produção (vale lembrar que as manutenções também devem ser
testadas), pode-se monitorar as estatísticas de uso, e caso o
software não esteja implantado, perguntar aos usuários. Porém, é
importante perceber que o Princípio de Pareto, por si só, pode não
ser suficiente, visto que uma funcionalidade pode ser muito

www.esab.edu.br 44
importante e raramente utilizada, mas se falhar pode causar um
grande prejuízo. Portanto, deve-se avaliar quando essa informação
será útil, atrelada a outras estimativas.

Término dos Testes

Um ponto muito importante relacionado ao projeto de testes é o

momento de identificar o seu fim, para não acontecem: testes de
menos, com uma interrupção, muito antes de atingir a cobertura
adequada (essa situação é mais comum, principalmente por causa
das pressões por prazos, ou inadequação em definir a cobertura
apropriada); ou testes de mais, implicando em custos, acima do
necessário, com o excesso de testes, pois o custo adicional, com
os testes, não compensa o custo que seria provocado pela falha.

Figura 7 – Custo do teste comparado com número de defeitos que

faltam ser corrigidos
Fonte: Rios e Moreira, 2007

Portanto, é importante identificar o ponto de equilíbrio. Esse ponto

de equilíbrio está relacionando com aspectos de criticidade: quanto
mais crítico o negócio, mais testes devem ser realizados. Por
exemplo, os testes de um software para controle de rota de
espaçonaves, é muito mais crítico do que um software para gestão
financeira pessoal, de forma que o primeiro requer muito mais

www.esab.edu.br 45
testes, visto que, o prejuízo ocasionado por uma possível falha
pode ser muito alto.

Mas, como se pode identificar esse ponto de interrupção? Rios e

Moreira, (2007) apontam algumas sugestões que podem ser
utilizadas em conjunto para definir o momento de término:

• Quando intervalo de ocorrência e identificação de defeitos

aumenta muito – de horas para dias;
• Quando a nova realização de um ciclo de teste acha
menos do que um número determinado de bugs;
• Quando atinge determinado valor de cobertura sem
descobrir novos defeitos;
• De acordo com o número de defeitos encontrados e
ainda não corrigidos, considerando a respectiva
severidade (ex: existem defeitos, de alto ou médio
risco, que ainda não foram corrigidos?).

Ambiente de Testes

É preciso planejar também o ambiente em que os testes devem

ser realizados. Engana-se quem pensa que o ambiente se refere
apenas ao hardware necessário; ele engloba toda a estrutura
envolvida com a execução dos testes, como por exemplo: sistemas
operacionais, browsers compatíveis, a massa de dados a ser
utilizada, e assim por diante.

As características do ambiente vão depender de alguns fatores.

Quanto mais crítico o software, mais o ambiente de teste deve
ser parecido com o ambiente de produção. E em alguns casos, o
ambiente de produção pode ser o mais variado possível. Por
exemplo, um grande site de vendas precisa rodar perfeitamente

www.esab.edu.br 46
em diferentes browsers (e em diferentes versões do mesmo)
combinados com diferentes sistemas operacionais. Se uma
atualização do site não rodar em um determinado browser padrão,
o prejuízo pode ser grande; visto que seus clientes em um segundo
podem acessar o site do concorrente. Assim, a preparação do
ambiente deve levar em consideração as características de cada
projeto. Um software com arquitetura cliente-servidor deve permitir
a realização adequada de testes em ambientes que simulem bem
a parte do cliente e, também, em ambientes que simulem a parte
do servidor.

Um software que precise ser testado com diferentes sistemas

operacionais e configurações; pode utilizar as máquinas virtuais
(ou Virtual Machines). Um mesmo computador pode ser utilizado
com diferentes máquinas virtuais. Cada máquina virtual pode
receber um sistema operacional diferente, reduzindo os custos.
Assim, um único computador com um Windows 7 (ou qualquer
outro sistema operacional) instalado, pode ter uma máquina virtual
com o Linux Ubuntu 10.10, outra com o Windows XP, outra com
Mac O.S, etc. A referência do CBTS lembra um ponto importante;
normalmente esses ambientes não são recomendados para teste
de performance, uma vez que a máquina virtual pode não ter a
quantidade suficiente de recursos alocados (ex: memória e
processamento) por estar sendo compartilhada com o sistema
operacional do computador.

Existem casos em que determinadas condições são proibitivas

para a reprodução do ambiente no local do desenvolvimento.
Pode-se citar como exemplo fictício, mas provável, uma indústria
que contrata uma empresa para desenvolver um software. Essa
indústria pode ter uma estrutura de hardware muito cara que pode
custar muito mais do que o software que está sendo desenvolvido.
Nesse caso, a empresa desenvolvedora tem que realizar alguns

www.esab.edu.br 47
tipos de testes no ambiente de testes da indústria, enviando alguns
participantes de sua equipe para lá. É importante perceber, que
essa situação deve ser prevista no planejamento dos testes.

Massa de Dados

A necessidade dos dados que serão utilizados nos testes varia de

acordo com a necessidade de cada tipo de teste. Os testes de
unidades e integração normalmente não precisam de muitos
dados, enquanto os testes de performance precisam, e para os
testes de homologação e aceitação é interessante que tenha uma
quantidade representativa.

Em alguns casos, ter dados reais de uma base já em produção é

relevante. Mas nem sempre é possível obtê-los seja porque não
existe uma base de dados de produção (sistema novo) ou porque
a política de privacidade da empresa contratante não permite que
esses dados sejam acessados por terceiros. Caso seja possível
obter os dados reais é importante ter cuidado para camuflar dados
confidenciais, substituindo-os ou convertendo-os no momento da
importação. Também é preciso, avaliar se é necessário utilizar
todos os dados, ou se apenas uma parte deles seria mais
adequada, filtrando o que for relevante para reduzir a base. Em
alguns casos, como nos testes de performance e estresse, os
dados geralmente não precisam ser reais, ou seja, em muitos
casos podem ser gerados aleatoriamente.

Outro ponto importante a se observar, na realização de testes com

dados reais, é em relação ao disparo de e-mails. Se a aplicação
possui funcionalidades que disparam e-mails, na base de teste é
fundamental adotar uma política que trate os mesmos, adotando
medidas como substituir os e-mails originais por e-mails de teste,

www.esab.edu.br 48
por exemplo. Essa política visa evitar problemas maiores com as
pessoas cadastradas no sistema. Além de ser incômodo para
pessoa receber e-mails desse tipo, uma informação falsa pode ser
enviada causando confusão e problema. Por exemplo, se estiver
sendo realizado um teste em um sistema bancário e um cliente
que possua uma fortuna recebe um e-mail disparado pelo ambiente
de testes informando que sua conta foi zerada, certamente seria
gerado um transtorno. Outro ponto que deve ser observado, é que
a aplicação no ambiente de testes deve estar apontando para um
banco de dados de testes, pois em alguns casos, por descuido,
eles podem estar apontando para o banco de produção,
ocasionando a perda de dados importantes.

Quando não for possível, ou não for necessário obter dados reais,
de acordo com o objetivo e necessidade de volume dos testes, os
mesmos podem ser gerados manualmente ou então
automaticamente; sendo gerado de forma aleatória por alguma
ferramenta.

Como diferentes tipos de testes demandam de diferentes tipos de

dados, várias bases com propósitos distintos são criadas. Após
essa criação, é interessante fazer o backup dessas bases,
armazenando-os de forma adequada e categorizada, para futura
reutilização em testes de regressão ou outros. Por exemplo,
suponha um sistema que gerencia planos de saúde que de acordo
com a idade do cliente cadastrado o valor e os benefícios mudam.
Os casos de testes vão ser elaborados para exercitar essa situação
de forma que um determinado cliente seja envelhecido nos testes,
passando por diferentes idades. Assim, um teste pode começar
com João da Silva com 5 anos de idade e no final dos testes, ele
estar com 75 anos. Após a realização de alterações no sistema os
testes de regressão vão precisar que João da Silva tenha 5 anos

www.esab.edu.br 49
novamente, bastando para isso restaurar a base previamente
criada com essas condições.

Ferramentas

Faz parte de preparação, e utilização do ambiente, o uso de

ferramentas. As ferramentas visam apoiar diversos aspectos
relacionados aos testes, desde a gestão do processo de teste em
si até a sua execução dos mesmos. Portanto, existem ferramentas
para gerenciar os testes, controle de defeitos, cobertura de código
e ainda, realizar testes de estresse, facilitar os testes unitários,
comparar os resultados dos testes, dentre outros. Existem
ferramentas que atuam sobre uma atividade específica enquanto
outras contemplam mais do que uma.

Apenas a aquisição da ferramenta não é condição suficiente para

obter o sucesso na atividade que ela suporta. Portanto, existem os
benefícios que podem ser conquistados e, também, existem os
riscos que são apresentados abaixo, baseados na referência da
certificação do ISTQB:

Alguns possíveis benefícios:

• Redução de trabalhos repetitivos (ex: execução de testes

de regressão);
• Avaliação dos objetivos (ex: número de defeitos, cobertura
de código);
• Maior consistência e possibilidade de repetições (ex:
testes realizados por uma ferramenta);
• Facilidade de acessar as informações sobre os testes
(ex: estatísticas e gráficos referentes ao progresso do

www.esab.edu.br 50
 teste, como número de defeitos graves que faltam ser
corrigidos).

Alguns riscos potenciais:

• Criar expectativas falsas sobre a ferramenta, como por

exemplo, funcionalidades oferecidas e facilidade de uso;
• Subestimar o tempo necessário para iniciar o uso da
ferramenta, assim como, custo e esforço necessário
para conseguir utilizar a mesma;
• Subestimar o esforço necessário para manter atualizados
os artefatos gerados pelas ferramentas;
• Tentar utilizar a ferramenta para tudo, mesmo quando a
realização manual seria mais adequada.

Ao longo deste Módulo, serão apresentadas algumas ferramentas

gratuitas que, se forem bem empregadas, podem auxiliar bastante
nos testes. Essas ferramentas servem para demonstrar conceitos
para você saber escolher qual tipo de ferramenta será adequada
ao seu projeto. Entretanto, o Módulo não tem a pretensão de
abranger todos os aspectos dessas ferramentas, até mesmo
porque o manual delas é extenso. Assim, problemas com instalação
e utilização das ferramentas não devem ser retiradas na sala
de aula, e sim nos manuais encontrados em fóruns de discussão
da internet, dentre outros meios adequadamente disponíveis na
web para essa finalidade. Algumas ferramentas demonstradas
são específicas para linguagem de programação Java. Uma vez
entendido os benefícios oferecidos por determinado tipo de
ferramenta, independente da linguagem de programação, basta
pesquisar na internet por uma ferramenta similar para a sua
linguagem de programação preferida.

www.esab.edu.br 51
 Saiba Mais

Existem ferramentas que facilitam a geração,

extração e manipulação de dados, como por exemplo
a ferramenta gratuita Kettle da suite Pentaho,
disponível em http://kettle.pentaho.com/.
Para crirar as Virtuais Machines, uma opção gratuita
é o Virtual Box - http://www.virtualbox.org/.

www.esab.edu.br 52
A Equipe e os Papéis nos Testes

Conforme visto anteriormente, as atividades relacionadas com os

testes devem ser iniciadas junto com projeto de software. Dessa
forma, a equipe de testes inicia sua participação no início do
projeto para detectar defeitos o mais cedo possível, visando evitar
a propagação dos mesmos e tentar corrigi-los enquanto os custos
são menores. A equipe de testes utilizará os artefatos gerados
pela equipe de desenvolvimento para testá-los ou planejar testes
de outros artefatos.

Para montar a equipe de testes, existem algumas abordagens

que vão desde utilizar os próprios desenvolvedores até terceirizar
os testes para equipe externa. A estratégia utilizada depende
muito das condições do projeto, como custo, prazo, dentre outros.
O ideal é uma equipe de testes dedicada (seja ela interna ou
terceirizada), mas muitas vezes esse objetivo é difícil de alcançar
por restrições financeiras. Mas é importante ter em mente que:
dificilmente se obtém resultados satisfatórios quando o
desenvolvedor testa o próprio código. Alguns motivos são:

• O testador precisa trabalhar de maneira isenta e

independente e os seres humanos tendem (mesmo que
de forma inconsciente) a encobrir os seus próprios
enganos.
• É difícil ter motivação psicológica para elaborar casos de
testes que mostram que seu código possui defeitos.
• Ao desenvolver, utilizou-se uma lógica de raciocínio que

www.esab.edu.br 53
 precisa ser modificada, para tentar identificar os possíveis
defeitos.
• O desenvolvedor possui uma lista de atividades para
desenvolver e normalmente fica ansioso. Quando termina
uma atividade, tem a intenção de logo começar outra e
não parar e ficar testando o que já fez.

Essas dificuldades não são exclusivas de desenvolvedores de

software, por isso, estão presentes em qualquer tipo de construção
intelectual. Você já tentou revisar um texto depois que escreveu?
E revisar novamente após outra pessoa ter feito uma revisão
seguida de correções? Muitas pessoas consideram essa atividade
torturante.

Abordagens Para Montar a Equipe

A seguir, algumas vantagens e desvantagens de montar a equipe

de testes com os desenvolvedores e outra com profissionais
designados somente para essa função, com base na referência
da certificação CBTS (RIOS; MOREIRA, 2007).

1 Alocar equipe de desenvolvimento para realizar os testes

- Nesse caso, um desenvolvedor (ou analista) deve testar a
funcionalidade do outro, de forma que o responsável nunca
deve testar o que ele mesmo produziu (com exceção dos
testes unitários e alguns tipos de integração). Para isso, é
importante que os desenvolvedores passem por treinamentos
que permitam desempenhar melhor a função de testador,
adquirindo conhecimentos com técnicas, documentos e
ferramentas de testes. Apesar dessa abordagem envolver
menores investimentos iniciais e permitir alcançar resultados
positivos, o gerenciamento passa ser mais trabalhoso, uma

www.esab.edu.br 54
 vez que é necessário organizar o tempo e sincronizar
cronogramas de forma a não atrapalhar o trabalho do outro
desenvolvedor (seja por interrupção ou espera da realização
dos testes para poder prosseguir). Além da dificuldade de
sincronizar cronogramas, outros riscos envolvidos são: os
desenvolvedores terão uma tendência a realizar os testes de
maneira mais informal. Assim, dificilmente manterão os
documentos de testes atualizados, portanto, não terão
conhecimento a respeito do negócio.

2 Alocar equipe independente para realizar os testes - A

equipe independente pode ser da própria empresa
desenvolvedora ou então uma equipe externa, terceirizada.
Essa abordagem tem um custo inicial maior, visto que mais
pessoas estarão envolvidas e alocadas no projeto. Porém,
tende a proporcionar um retorno financeiro maior ao longo do
tempo, principalmente se for contabilizado o custo de corrigir
os defeitos encontrados no software em produção. A qualidade
final é maior devido à: dedicação de tempo maior, conhecimento
mais especializado nas técnicas, ferramentas e metodologias
de teste. Para funcionar bem, é preciso gerenciar alguns
pontos, como por exemplo: a equipe de desenvolvimento
pode achar que a responsabilidade sobre a qualidade é
somente da equipe de testes, diminuindo o seu padrão de
qualidade e existe uma tendência de desentendimento entre
as duas equipes, que pode ser ocasionado principalmente se
os testadores reportarem os erros com linguagem inapropriada
(ex: deboche, agressividade, etc.).

Beizer já dizia, em 1990: responsabilidade, e teste com (tradução

livre).

“Testadores, quebrem o software como é de sua força, mas não

sinta prazer com a dor do programador” (BEIZER, 1990, n.p.)

www.esab.edu.br 55
Papéis no Processo de Teste

A equipe de desenvolvimento é responsável por realizar os testes

unitários e de integração. Em relação à equipe de testes,
normalmente os papéis existentes são:

• Gerente de Teste: esse papel é semelhante ao gerente

de projetos, e normalmente encontrado apenas em
equipes maiores.
• Líder do Projeto de Teste: lidera um projeto de teste
específico.
• Arquiteto de Teste: tem como responsabilidade
preparar o ambiente de testes e escolher as
ferramentas que serão utilizadas.
• Analista de Teste: elabora os casos de teste.
• Testador: executa os casos de teste.

Pode ser que profissionais acumulem alguns papéis (tanto de

teste como de desenvolvimento), de acordo com a necessidade e
porte da equipe e projeto. Em relação à automatização dos testes
e aos testes de performance, essa atribuição, dependendo da
equipe, fica sob responsabilidade do testador ou do analista de
teste.

Certificações para Profissionais de Testes

Existem no mercado várias certificações para os profissionais

de testes. Abaixo são relacionadas três delas (2 delas já citadas
neste módulo) que são bem aceitas no Brasil, juntamente com
algumas informações adicionais. Vale ressaltar que essas

www.esab.edu.br 56
informações servem apenas para dar uma pequena noção, visto
que os valores, tempo, número de questões podem mudar.

• CBTS - Certificação Brasileira de Teste de Software.

• ALATS (Associação Latino-Americana de Teste de
Software).
Material de apoio para a certificação: Livro Base de
Conhecimento em Teste de Software, 2ª edição.
Valor: R$ 300 reais.
Número de Questões: 100 questões.
Percentual de Acerto para aprovação: 75%
Duração: 3 horas.
Formato: Múltipla escolha.
Site: http://www.alats.org.br.

• CTFL Foundation - Certified Tester, Foundation Level.

• ISTQB (International Software Testing Qualifications
Board).
Material de apoio para a certificação: “Foundation Level
Syllabus” e “Glossary of Terms” (ambos possuem
tradução para português).
Valor: R$ 350 reais.
Número de Questões: 40 questões.
Percentual de Acerto para aprovação: 60%
Duração: 1 hora.
Formato: Múltipla escolha.
Site: http://www.bstqb.org.br/

• CSTE - Certified Software Tester.

• QAI - Quality Assurance Institute.
Material de apoio para a certificação: Common Body of
Knowledge(CBOK).
Valor: U$ 350 dólares.

www.esab.edu.br 57
 Número de Questões: 100 múltipla-escolha e 20
dissertativas curtas
Percentual de Acerto para aprovação: 75%
Duração: 4 horas e meia.
Formato: Múltipla escolha e dissertativa.
Site: http://www.softwarecertifications.org/qai_cste.htm

Técnicas Estáticas - Revisão e Inspeção

As técnicas de Teste Dinâmico necessitam da execução do

código fonte para serem realizadas. Portanto pode-se citar
como exemplo, a execução dos testes unitários e dos testes
de performance como técnicas de Teste Dinâmico.

Já as técnicas de Teste Estático não estão relacionadas à

execução do código fonte, que pode muitas vezes nem existir
ainda. São exemplos de testes estáticos, as revisões de
artefatos como especificação de requisitos, diagrama de
classes, inspeção do código fonte, dentre outros. Portanto,
muitas das técnicas de Teste Estático são realizadas
manualmente, como a leitura de documentos para identificar
inconsistências.

Como estudado anteriormente, quanto mais cedo um defeito

for identificado, menor é o custo da sua correção. Para evitar
que defeitos introduzidos nos artefatos, como especificação
de requisitos, diagramas de classe, etc., se propaguem para
os demais artefatos, é importante realizar a revisão desses
documentos.

Para facilitar a leitura, os defeitos dos artefatos citados nesta

Unidade, são mais abrangentes do que o conceito de defeito

www.esab.edu.br 58
que será estudado, abstraindo o conceito para qualquer tipo
de problema. Ao revisar os requisitos e diagramas os tipos de
problema procurados são (KALINOWSKI, 2008, n.p.):

Omissão: falta de informações relevantes a

respeito do sistema, como por exemplo, parte
importante não definida, ausência de classes,
diagramas, etc. - Ambiguidade: a descrição do
texto ou diagramas permite que a mesma
informação seja interpretada de diferentes
formas - Inconsistência: informações no mesmo
artefato ou em artefatos distintos são conflitantes
entre si - Fato Incorreto: a informação textual ou
diagramática não condiz com a verdade-
Informação Estranha: informações que não são
necessárias ou não são utilizadas - Outros: os
demais tipos de defeito, como posicionamento
errado de informações em determinada seção.

A realização da revisão deve iniciar o quanto antes e não somente

ao término de uma fase. As revisões podem seguir processos
informais ou formais. Segundo o Syllabus do ISTQB (2011), a
revisão formal normalmente contempla as etapas de planejamento,
kick-off, preparação individual, reunião de revisão, correção e
acompanhamento. No planejamento são definidas as técnicas a
serem empregadas e os revisores, dentre outros. A fase de kick-
off contempla a distribuição dos documentos, e explicação para
os participantes sobre os objetivos, documentos e processos. A
preparação individual consiste na revisão individual antes da
reunião, de forma que cada revisor identifique os problemas,
comentários e sugestões. Na reunião de revisão, os participantes
discutem as anotações realizadas previamente e decidem com a
ajuda do moderador os defeitos (e os pontos que não são defeitos)
e possíveis encaminhamentos. O retrabalho (correção) é a etapa
de correção dos defeitos, normalmente pelo autor do artefato. O

www.esab.edu.br 59
acompanhamento consiste em verificar se os defeitos foram
devidamente corrigidos e a necessidade de uma nova revisão.

As abordagens para leitura normalmente são: ad hoc, baseadas

em checklists e técnicas de leitura de software. A leitura ad hoc
não possui um método definido, sendo sua eficácia dependente
da habilidade do revisor. A leitura baseada em checklist (ou lista
de verificação) não apresenta uma metodologia sistemática, mas
sim um conjunto de características de defeitos conhecidos
previamente, que devem ser verificados (FALBO, 2017). Já a
técnica de leitura de software visa adotar uma postura mais
sistemática na realização da revisão. Pode-se citar como exemplo,
a Técnica de Leitura Orientada a Objetos (OORT - Object-Oriented
Reading Techniques). A OORT estabelece procedimentos para
revisão de documentos e diagramas do projeto orientados a objeto
(MAFRA; TRAVASSOS; 2005). Duas dimensões são analisadas,
a leitura horizontal (verificação de consistência de artefatos de
uma mesma fase) e leitura vertical (verificação de artefatos
produzidos em fases diferentes) (FALBO, 2017). Assim, são
apresentadas técnicas que verificam, por exemplo, a consistência
dos casos de uso com o diagrama de classes.

Na inspeção do código fonte, algumas atividades podem ser

apoiadas por ferramentas. Por exemplo, a ferramenta Checkstyle
(http://checkstyle.sourceforge.net/) verifica se o código fonte dos
desenvolvedores segue um padrão como nomenclatura de
métodos, código duplicado, etc. Já a ferramenta gratuita FindBugs
(2018), para Java, analisa estaticamente o código fonte e aponta
possíveis defeitos, baseados em padrões conhecidos. Dentre as
inúmeras análises realizadas, aponta variáveis que não são
inicializadas, possíveis ocorrências de exceções de null pointer,
indicação de problemas de performance com código desnecessário,
tratamento incorreto de exceções, etc.

www.esab.edu.br 60
 Estudo Complementar

Uma alternativa de terceirização da equipe

de testes que vem ganhando popularidade,
principalmente no exterior é o CrowdTest
(algo como: teste da multidão).

Atividade
Após o estudo referente ao Eixo Temático 1,
você será capaz de entrar na sua sala de aula
virtual e acessar a Lista 1 de atividades
objetivas. Boas atividades!

www.esab.edu.br 61
O objetivo do estudo sobre Fundamentos de Teste de Software foi
o de expor os Fundamentos de Teste de Software para o aluno,
além de conceituar os níveis de testes, as técnicas utilizadas, bem
como se dá o processo de teste e suas falhas. Portanto, ao
discorrer sobre as cinco primeiras unidades desse eixo temático
1, buscou-se de forma sucinta alcançar os seguintes entendimentos
sobre cada unidade e sua importância para a Engenharia de
Software: Unidade 1 - Introdução, Organização do Conteúdo,
Conceitos de Teste I, Testes Estáticos x Testes Dinâmicos, Testes
Funcionais (Caixa-preta) x Estruturais (Caixa-branca), Conceitos
de Testes Níveis de Testes, As integrações podem ser do tipo Big-
Bang ou incremental – II. Unidade 2 - Técnicas de Testes. Custos
de Testar; da Correção e o Retorno de Investimento em Testes,
Custo da Correção, Retorno de Investimento, Custos das Falhas.
Unidade 3 - Erros em Escalas da GOL, Autodestruição do Foguete
Ariane 501, Destruição da Sonda da NASA Mars Climate Orbiter,
O Processo de Teste, O Modelo V, Planejamento dos Testes.
Unidade 4 - Análise dos Riscos, Término dos Testes, Ambiente de
Testes, Massa de Dados, Ferramentas. Unidade 5 - A Equipe e os
Papéis nos Testes, Abordagens para Montar a Equipe, Papéis no
Processo de Teste, Certificações para Profissionais de Testes,
Técnicas Estáticas, Revisão e Inspeção.

www.esab.edu.br 62
2: TESTES AUTOMÁTICOS

Os Testes automáticos de software é de suma importância quan-

to a garantia, agilidade e qualidade durante o projeto de desenvol-
vimento. Além disso, o testes automáticos apresentam longo ciclo
de vida no mercado, por isso, cada vez mais vêm se desenvolven-
do nas indústrias e no mercado.

Para que a sustentabilidade de sua operação tenha êxito, não

deve existir o risco de mau funcionamento ou falhas durante a
análise e integração do software. Os testes automatizados
surgiram no intuito de aperfeiçoar o processo de execução, ou
seja, permitem a repetição de uma grande quantidade de testes
em um tempo menor e com número reduzido de testadores.

Objetivo

Fornecer orientações sobre Testes Automáticos, através dos

seguintes tópicos: Casos de Teste – Conteúdo do Caso de Teste
– Características e Potenciais Problemas – Execução dos Testes
– Testes Orientados a Dados (DDT – Data Driven Test) –
Automatização dos Testes – Gestão de Testes – Ferramenta
TestLink – Gestão de Defeitos (Conceito de Erro, Defeito e Falha)
– Gestão de Defeitos (Resolução do Defeito) – Gestão de Defeitos
– Ferramenta Mantis – Cobertura de Código – Ferramenta
EclEMMA – Testes de Unidade e Integração – Ferramenta Junit
– Localização das Classes de Teste – Testes com Objetos
Substitutos ou “Falsificados” (Mock Objects) – Ferramenta Mockito.

www.esab.edu.br 63
Casos de Teste

O Caso de Teste é um dos artefatos do processo de teste. Seu

objetivo é documentar os cenários de teste de forma a verificar se
os resultados esperados estão sendo atingidos. Normalmente,
utilizam-se os casos de uso (do processo de desenvolvimento)
para elaborar os casos de teste, sendo que cada cenário do caso
de uso pode ser coberto por um ou mais casos de testes. Entretanto,
existem alguns casos de testes que são baseados em requisitos
não funcionais, como por exemplo, desempenho, e dessa forma
não utilizam os casos de uso como base.

Como os casos de uso são utilizados como base, caso eles sejam
alterados os casos de teste precisam ser revisados. Por isso, é
importante manter a rastreabilidade entre a especificação de
requisitos e casos de teste (SAYÃO, 2005). Uma boa ferramenta
de gestão de teste deve oferecer a funcionalidade para realizar
essa rastreabilidade.

Conteúdo do Caso de Teste

O conteúdo do caso de teste, normalmente, é composto por

valores de entrada, pré-condições de execução, os passos/
procedimentos e resultados esperados. Essas informações
normalmente são utilizadas, mas o conteúdo do documento pode
ser adaptado pela equipe. Segue abaixo uma possibilidade de
campos para compor um caso de teste:

www.esab.edu.br 64
 • Autor: autor do caso de teste.
• Id: número que identifica o caso de teste.
• Título: deve descrever brevemente o caso de teste.
• Pré-condições: condição que deve ser atendida antes do
teste ser executado. Por exemplo, pode ser necessário
ter um cliente cadastrado com um filho de 17 anos.
• Dados de entrada: indica os dados que serão informados
durante o teste.
• Procedimentos: descreve os passos que devem ser
realizados para executar o teste, indicando qual passo é
realizado pelo testador e qual é realizado pelo sistema.
• Dados de saída: dados que foram modificados ou
produzidos durante a execução do teste.
• Pós-condições: situações que devem ser verificadas ao
término do teste, como mudanças de status e outras
alterações ocasionadas pelo teste.
• Ambiente: utilizado para informar características do
ambiente, como por exemplo, uma versão do sistema
operacional e do browser.
• Tipo de execução: se o teste deve ser executado
manualmente ou automaticamente.
• Rastreabilidade: indica os artefatos do desenvolvimento
(ex: o caso de uso, requisito) que serviram como base
para criação do caso de teste.
• Observações: informações adicionais que o analista de
teste queira passar para o testador.

Esses campos podem ser modificados de acordo com a

necessidade da equipe, que pode querer, por exemplo, unificar os
dados de saída e pós-condições que compõem os resultados
esperados. É importante ressaltar que os resultados esperados

www.esab.edu.br 65
devem estar presentes, caso contrário o testador pode julgar um
resultado errado, mas aparentemente correto como válido
(SOUZA, 2009).

A seguir é apresentado um caso de teste elaborado a partir de um

cenário de caso de uso imaginário, de número RN025, que
especifica um depósito em conta bancária, determinando que os
depósitos acima de R$ 14.999,99 devem enviar um e-mail para o
dono da conta.

Figura 8 – Exemplo de um caso de teste

Fonte: Próprio autor.

O exemplo da Figura 8 apresenta um caso de teste para o requisito

RN025. Outros casos de testes deveriam ser elaborados para o
mesmo requisito, como depósito para conta inativa, depósito de
valor negativo, dentre outros. Supondo-se que o mesmo requisito
especificasse que depósitos acima de R$ 30.000,00 gerassem

www.esab.edu.br 66
pontuação extra no programa de fidelidade. Para realizar um teste
com depósito de R$ 29.999,99 um novo caso de teste teria que
ser elaborado.

O caso de teste apresentado (Figura 8) foi demonstrado dessa

forma, propositalmente, para mostrar que para generalizar e
reaproveitar o caso de teste; é importante que os valores possam
ser variáveis. Para generalizar, o nome do caso de teste deveria
ser mudado, passando para algo do tipo Realizar depósito de
valores que enviam e-mail, mas não geram pontuação extra e
nos procedimentos e dados de saída, ao invés de colocar o valor
fixo R$ 15.000,00, o texto descreveria que seria um valor informado
pelo usuário, de forma que ficasse genérico o suficiente para
permitir que os valores variassem nos dados de entrada. Esse
conceito chama-se DDT (Data Driven Test, ou em português,
Testes Orientados a Dados) que serão abordados mais adiante.

Características e Potenciais Problemas

A referência para certificação CBTS apresenta algumas

características, problemas e recomendações interessantes a
respeito dos casos de teste, que são apresentados a seguir.

As características de qualidade de um caso de teste são:

• Efetivo: deve testar o que foi planejado.

• Econômico: não deve possuir passos desnecessários.
• Reutilizável: deve ser possível reexecutar (muito
importante para os testes de regressão).
• Rastreável: identifique o requisito que está sendo testado.
• Autoexplicativo: qualquer testador deve ser capaz de
executar.

www.esab.edu.br 67
A referência do CBTS apresenta também problemas que precisam
ser controlados pelo gerenciamento de testes durante todo o
projeto (LOURENÇO, 2010).

• Mudança de Requisitos: É importante tentar identificar

quais os requisitos que apresentam os maiores riscos de
mudança, e escrever primeiro os requisitos que não
serão impactados pela mudança. A revisão dos casos de
testes produzidos implica em tempo e custo. O gerente
de projeto deve ter conhecimento desses itens e definir a
prioridade do que deve ser refeito, dando prioridade aos
requisitos de maior risco.
• Mudança de Cronograma: Se o prazo para elaboração
dos casos de teste for reduzido por alguma razão, o
gerente do projeto deve participar na escolha da
prioridade, de forma que os cenários de maior risco sejam
elaborados antes. Só se deve considerar aumentar a
equipe se houver tempo suficiente para treinamento e
adaptação dos integrantes novos.
• Rotatividade da equipe: Todo participante novo deve
entender os objetivos, cronograma e organização do
projeto. Eles devem ter acesso à documentação do
software para conhecer primeiro as regras de negócios e
só então elaborar os casos de teste. É importante que
um profissional mais experiente revise os artefatos
produzidos pelos novos integrantes.

Execução dos Testes

As informações a respeito da execução dos testes devem ser

armazenadas por serem preciosas para acompanhamento e
tomada de decisão. A partir desse registro é possível saber quantos

www.esab.edu.br 68
testes foram realizados, quantos foram bem-sucedidos, quantos
falharam e quantos não foram executados. Assim, consegue-se
cruzar informações sobre os testes, riscos e prioridades, obtendo
informações do tipo quantos testes de partes de alto risco falharam.
Uma boa ferramenta de gestão de testes deve permitir o cadastro
dessas informações, bem como emitir relatórios com esses
indicadores citados.

Na execução, outra informação valiosa que deve ser registrada é

a respeito dos defeitos encontrados. Essa informação deverá ser
salva em uma ferramenta de Gestão de Defeitos, que será tratada
adiante.

Durante a execução, de acordo com os tipos de defeitos

encontrados, é possível identificar se o desenvolvedor liberou o
código para teste antes do momento adequado. Se muitos defeitos
e/ou defeitos primários forem encontrados durante o teste (defeitos
do tipo que deveriam ser identificados nos testes unitários e de
integração do desenvolvedor) significa que o código foi liberado
para o teste antes do tempo. Esse fato representa um custo
adicional, já que o testador vai testar funcionalidades que não
estão adequadamente finalizadas. Vai gastar tempo registrando
esses defeitos que poderiam ser identificados pelo desenvolvedor,
e depois terá que realizar os mesmos testes, novamente, para
saber se foram corrigidos. Portanto, o cronograma para realização
dos testes poderá ser prejudicado, portanto o gerente de testes e
de projeto devem tomar as devidas providências.

Ainda durante a execução, o testador pode verificar que o resultado

esperado do caso de teste e o resultado obtido são diferentes. Se
ele perceber que o software aparenta estar correto, e achar que o
erro está na especificação do caso de teste, ele deve reportar
para o analista de teste avaliar. Se o analista confirmar que o caso

www.esab.edu.br 69
de teste está errado, ele o corrigirá. Caso contrário, o testador
deverá reportar ao defeito encontrado na ferramenta de gestão de
defeitos.

Testes Orientados a Dados (DDT - Data Driven Test)

O conceito de Testes Orientados a Dados (do inglês Data Driven

Test - DDT) se refere a executar (e também descrever) o mesmo
teste, apenas variando os dados, permitindo realizar vários testes
sem ter que alterar o código (ou caso de teste). Para atingir esse
resultado, muitas vezes arquivos externos em csv, xml, dentre
outros formatos, são utilizados. Algumas ferramentas já oferecem
suporte à utilização do DDT, mas em alguns casos é preciso
codificar. A Tabela 3 demonstra um exemplo que poderia ser
utilizado para testar se a mensagem de boas-vindas está sendo
exibida corretamente para os usuários cadastrados, de acordo
com seu cargo.

Tabela 3: Exemplo de utilização de dados para DDT

Login Senha Mensagem Esperada
João João Usuário não cadastrado

José José Bem-vindo desenvolvedor José

Carlos Carlos Bem-vindo administrador Carlos

... ... ...

... ... ...

... ... ...

Marta Marta Bem-vinda analista Marta

Fonte: Próprio autor.

www.esab.edu.br 70
Dessa forma, a ferramenta utilizaria os dados do login e senha
como dados de entrada e verificaria se a mensagem apresentada
corresponde ao que era esperado. Se for preciso testar para outros
usuários, basta adicionar/alterar linhas na tabela e executar o
teste novamente.

Automatização dos Testes

A automatização dos testes permite executá-los novamente de

forma muito mais fácil, contribuindo para a realização dos testes
de regressão, dando uma confiança muito maior para a qualidade
do software. Sendo assim, a automatização dos testes parece
uma ideia fantástica, mas será que sempre é a melhor opção? A
resposta é: Não, existem casos que os testes manuais serão mais
adequados. Existem casos também, que o prazo apertado não
fornece tempo para automatizar, sendo o teste manual a única
alternativa.

É preciso lembrar que os testes automatizados precisam ser

programados nas ferramentas, o que requer tempo e, também,
manutenção dos mesmos. Portanto, se a parte do software que
está sendo testada de forma automatizada for mudar muito, em
curto prazo, o custo para reprogramar o teste automatizado pode
ser alto. Dessa forma, a decisão de automatizar ou não a execução
de um teste, deve avaliar alguns fatores, como por exemplo: Qual
é o esforço necessário para automatizá-lo? Existe expectativa de
alterar muito o software testado? O teste deverá ser executado
muitas vezes? Qual o grau de risco da parte a ser testada?

Esses quesitos devem ser avaliados, visto que, além do tempo

para automatizar o teste é preciso dar manutenção nos scripts. E

www.esab.edu.br 71
a manutenção pode ser dificultada por alguns fatores. A primeira
já foi dita: Que mudança no software pode implicar na alteração
do teste automatizado. Outro fator se refere à própria ferramenta
de testes, que ao passar por uma atualização pode não ser
compatível com o script de teste criado. Nesse caso, para executar
o teste automatizado seria necessário baixar a versão anterior da
ferramenta, ou então adaptar o script.

A programação dos scripts de teste passa pelos mesmos desafios

do que o desenvolvimento de um software. As boas práticas de
programar, de forma que seja reutilizável e de fácil manutenção,
se aplicam a programação dos scripts de teste.

É possível perceber que possuir testes automatizados pode ser

muito útil para garantir a qualidade do software, mas é preciso
conhecer os desafios envolvidos para avaliar o custo x benefícios
de cada automatização.

www.esab.edu.br 72
Gestão de Testes - Ferramenta TestLink

O TestLink (WIKIPÉDIA , 2018) é uma aplicação web gratuita

para realizar a gestão dos testes de software. Pode ser implantado
em qualquer ambiente que ofereça suporte a PHP, MySQL e
Apache.

Permite gerenciar todo o ciclo de vida do processo de software.

Portanto, possui funcionalidades para cadastrar os requisitos e os
casos de testes; permite associá-los de forma a manter a
rastreabilidade; controla o plano de testes, os papéis da equipe
(testador, analista, etc.); possui estatísticas e métricas para
acompanhar o progresso dos testes; permite a priorização dos
testes; definição de marcos e agrupamento dos testes para testar
determinada versão; dentre outras facilidades.

Figura 9 – Principais Funcionalidades do TestLink

Fonte: TestLink (2018).

www.esab.edu.br 73
O TestLink trabalha com quatro principais conceitos: Projeto de
Teste, Plano de Teste, Suíte de Teste e Casos de Teste. O
Projeto de Teste é o projeto que está sendo gerenciado. O Plano
de Teste representa a base para execução do teste, contendo o
subconjunto de casos de teste selecionado, a prioridade, os
resultados, responsáveis e marcos. O Suíte de Teste representa
a organização dos casos de teste para permitir o agrupamento em
unidades lógicas. É como se fosse um diretório que contém casos
de testes para determinada funcionalidade. Por exemplo, é
possível criar uma Suíte para um determinado módulo e associar
todos os Casos de Testes desse módulo. O Caso de Teste é o
documento estudado anteriormente.

Para entender melhor os conceitos, a figura abaixo apresenta um

exemplo fictício criado no TestLink para demonstração. O Projeto
é a Loja Magnun. Tem o Plano de Teste 1 que possui seis casos
de testes atribuídos. Os casos de testes estão começando com a
sigla LM, uma configuração realizada pelo gerente de teste
cadastrado na ferramenta. Para organizar melhor os casos de
testes, tem 3 Suítes: a suíte Módulo Frente de Loja, a suíte
Pagamento e a Venda.

Figura 10 – Exemplo de Projeto de Teste no TestLink

Fonte: Print screen do https://www.testlink-gerenciando-atividades-
de-teste/ (2018)

www.esab.edu.br 74
A figura representa uma facilidade do TestLink de visualização
dos testes que passaram (verde), falharam(vermelho), não foram
executados (cinza) e estão bloqueados (roxo/azul).

O TestLink apresenta diferentes relatórios com estatísticas e

métricas para servir como base de informação para o gerente de
teste acompanhar o progresso e avaliar o risco de liberar o
software. O relatório abaixo exemplifica algumas dessas métricas,
como o resultado do teste por prioridade, indicando, por exemplo,
quantos testes de alta prioridade falharam ou ainda não foram
executados.

Figura 11 – Métricas do Plano de Teste

Fonte: Print screen do https://www.testlink-gerenciando-atividades-
de-teste/ (2018)

O TestLink permite exportar relatórios e documentos (requisitos,

casos de teste, planos de teste) para HTML, Word e Excel.

Em relação ao Caso de Teste, ele segue o modelo apresentado na

Unidade 11, com exceção dos campos pós-condições, dados de

www.esab.edu.br 75
entrada e dados de saída. Alguns usuários colocam a informação
dos dados de entrada em ações do passo, e as pós-condições e
dados de saída, em resultados esperados. Também é possível
colocar os dados de entrada e saída em um arquivo e anexá-los
ao caso de teste, tornando o teste orientado a dados (DDT).
Adicionalmente, caso prefira ter esses campos explícitos, o
TestLink permite criar campos personalizados.

A Figura 12 apresenta um exemplo de caso de teste no TestLink.

Figura 12 – Exemplo de Caso de Teste no TestLink

Fonte: Print screen do https://www.testlink-gerenciando-atividades-
de-teste/ (2018)

Gestão de Defeitos (Conceito de Erro, Defeito e Falha)

Antes de estudar Gestão de Defeitos, é importante analisar os

conceitos de erro, defeito e falha, segundo o ISTQB:

• Erro (ou engano): ação humana que produz um resultado

incorreto, como por exemplo, uma ação incorreta realizada
por um programador.
• Defeito (ou bug): o erro produz um defeito no código, em
um software ou em um documento.

www.esab.edu.br 76
 • Falha: Se um defeito no código for executado, causará uma
falha.

Portanto, de acordo com os conceitos do ISTQB (2011), o defeito

é o problema, e a falha é a manifestação do problema. A falha
também pode ser causada por condições externas: como por
exemplo, uma falha na memória RAM (radiação e magnetismo)
pode impactar no funcionamento do software por causa de
problemas no hardware. De acordo com esses conceitos, é
possível que um defeito não ocasione uma falha? A resposta é
sim. Se a parte do código que contém o defeito nunca for
executada, a falha não ocorrerá. O código representado na Figura
13, exemplifica esse fato.

Figura 13 – Código (defeito = converter Celsius para Fahrenheit

multiplicando por 2)
Fonte: Próprio autor.

No código da Figura 13, o defeito é converter Celsius para

Fahrenheit multiplicando por 2. Se o código nunca for executado
com medida = FAHRENHEIT, o defeito não ocasionará uma falha.

Gestão de Defeitos

Os defeitos (por uma questão de Didática, aqui, será tratado

defeito com o significado mais amplo, abrangendo também o
conceito de falha) devem ser registrados no momento de sua
descoberta. Esse registro pode ser manual ou automático. Os
desenvolvedores tomarão conhecimento sobre a existência do

www.esab.edu.br 77
defeito a partir do canal de comunicação estabelecido pela equipe.
É importante que a comunicação seja eficiente para tentar reduzir
o tempo de correção (RIOS; MOREIRA, 2007).

A referência do CBTS apresenta um conjunto de boas práticas

interessantes para relatar os defeitos:

• Resumo: O defeito deve ser relatado de maneira clara e

resumido.
• Precisão: Antes de reportar o defeito, certificar-se que o
que foi identificado é realmente um defeito, e não uma falha
no entendimento ou erro do usuário ou testador.
• Neutralidade: Ao reportar o defeito, apresente apenas o
problema sem ser sarcástico ou colocar qualquer tipo de
emoção ou humor no relato.
• Isolamento: Isolar o defeito, e reportá-lo.
• Generalização: Avaliar se o problema pode ocorrer em
outras situações, avaliando o defeito de uma forma genérica.
• Reprodução: Antes de relatar um defeito, tentar reproduzir
a falha, no mínimo duas vezes. Caso não seja possível, por
se tratar de uma falha intermitente, tentar colocar uma
prova ou evidência da ocorrência, como por exemplo, um
printscreen da tela.
• Impacto: Identificar o impacto e grau de severidade do
defeito para o cliente e/ou negócio.

As boas práticas apresentadas visam evitar a perda de tempo dos

desenvolvedores ao identificar a origem do defeito, bem como
evitar o desgaste entre a equipe de desenvolvimento e a equipe
de teste. Os defeitos podem ser encontrados e relatados pelos
testadores, usuários, clientes, help desk, equipe de desenvolvi-
mento, dentre outros. Porém, o desenvolvedor responsável

www.esab.edu.br 78
deverá avaliar para ver se é legítimo. A demora em reconhecer o
defeito pode ser muito prejudicial.

Após o desenvolvedor saber da existência de um possível defeito,

a demora em reconhecê-lo pode ser porque ele não conseguiu
reproduzir a falha. Em alguns casos, o desenvolvedor acaba
definindo que o defeito não existe, ou posterga a sua identificação.

Uma das abordagens que pode ser tomada, para tentar acelerar o
reconhecimento do defeito, é a geração de logs pelo código para
registrar o ponto em que ocorreu a falha e se possível outras
condições.

Caso haja discordância a respeito da existência do defeito, por

parte dos testadores/usuários e desenvolvedores, é preciso definir
uma forma para decidir. Se o sistema apresenta uma falha nítida
e reproduzível, ou então suas funcionalidades são diferentes do
que foi especificado na documentação, então o defeito existe.

Resolução do Defeito

Como podem existir vários defeitos a serem corrigidos, bem como

novos desenvolvimentos de código a serem realizados, é
necessário classificar a prioridade para definir a ordem de correção.
A priorização está relacionada com o impacto que o defeito pode
causar, avaliando se é crítico; grave ou menos relevante.

Enquanto o defeito não é corrigido, é importante avaliar as

medidas que podem ser tomadas para reduzir o risco e minimizar
o impacto que a falha pode provocar. Após a correção, a parte
corrigida deve ser testada novamente pela equipe de testes. Além
do teste da correção em si, testes de regressão na maioria das

www.esab.edu.br 79
vezes são necessários para garantir que nenhum efeito colateral
foi introduzido com a alteração do código.

É importante comunicar às partes interessadas a respeito da

resolução do problema, bem como sobre os aspectos da liberação
do código corrigido.

Estudo Complementar

Outra facilidade oferecida pelo TestLink é atribuição

de palavras-chave, facilitando a categorização e
busca dos casos de teste. É possível acessar um
demonstrativo on-line do TestLink em http://testli
nk.sourceforge.net/demo/login.php.

www.esab.edu.br 80
Gestão de Defeitos - Ferramenta Mantis

Os defeitos quando encontrados precisam ser reportados aos

desenvolvedores. Existem diversas formas de realizar a gestão
do defeito, desde processo manual, processadores de texto,
planilhas e até ferramentas específicas para esse fim. A utilização
de uma ferramenta apresenta benefícios como centralização dos
dados, facilidade de acompanhamento, atribuição de tarefas,
dentre outros.

Figura 14 – MANTIS
Fonte: MANTIS- Bug Tracker (2018)

O Mantis (2018) é uma ferramenta gratuita para realizar a gestão

dos defeitos, disponível no site: http://www.mantisbt.org/. Ela foi
desenvolvida em PHP e roda nos bancos de dados MySql, MS
SQL e PostgreSQL.

O Mantis é fácil de instalar e, também, fácil de usar. É possível

configurá-lo para ser apresentado em português. Além de permitir
fazer a gestão dos bugs, permite gerenciar o desenvolvimento de
novas funcionalidades também, contribuindo para a gestão do que
será desenvolvido. É possível designar o responsável pelo
desenvolvimento de cada item, bem como configurar as situações
www.esab.edu.br 81
que devem enviar e-mail. Assim, um e-mail pode ser enviado aos
responsáveis quando o defeito for corrigido.

O Mantis gerencia todo o ciclo de vida do defeito, desde a sua

criação até sua conclusão, passando por fases como confirmação,
correção e revisão. Cada defeito recebe um identificador numérico
sequencial para facilitar o acompanhamento. Ao logar no Mantis
(2018), o desenvolvedor visualiza uma tela com os defeitos
atribuídos a ele, os defeitos reportados por ele, bem como os
defeitos do projeto, que não possuem responsáveis, os que foram
alterados e os concluídos recentemente. A Figura 15 apresenta o
painel geral dos defeitos.

Figura 15: Visão Geral dos defeitos

Fonte: Print screen do http://www.mantisbt.org (2018)

Como é possível observar na imagem, ao final da página Minha

Visão existe a legenda com as respectivas cores dos status de
cada defeito. Os status indicam:

• Novo: um novo defeito ou funcionalidade registrada que

ainda não foi confirmado, admitido, atribuído, etc.
• Retorno - Feedback: indica que o defeito precisa de alguma
informação adicional ou algum feedback.

www.esab.edu.br 82
 • Admitido: geralmente é utilizado pela equipe de
desenvolvimento para informar que está ciente e concorda
com o defeito relatado, mas ainda não teve tempo ou
condições de reproduzir o defeito.
• Confirmado: ao contrário do defeito admitido, no confirmado
o desenvolvedor além de estar ciente e concordar, já
conseguiu reproduzir.
• Atribuído: o defeito já foi designado para um desenvolvedor,
que passa a ser responsável pela sua correção.
• Resolvido: defeito resolvido pelo desenvolvedor. Um defeito
passa a ter o status resolvido quando o responsável, ao
editá-lo, informa que a resolução foi: corrigido, não é o
caso (não se aplica), e não será corrigido. Quando ele é
corrigido, precisa ser testado novamente.
• Fechado: defeito já corrigido e (re) testado, não sendo
necessária nenhuma informação adicional.

As Figuras 16 e 17 apresentam a tela para registrar um defeito.

Devido ao seu tamanho, ela foi dividida em duas imagens, e será
explicada por partes.

Figura 16 – Tela de registrar defeito no Mantis - parte 1

Fonte: Print screen do http://www.mantisbt.org (2018)

A tela de registro de defeito apresenta todas as informações

relevantes, estudadas na Unidade anterior. O primeiro campo

www.esab.edu.br 83
categoria indica em qual categoria em relação ao projeto o defeito
se encontra. As opções são cadastradas pelo usuário administrador
e normalmente contemplam os módulos de um sistema, ou outra
categoria que o administrador julgue relevante.

Gestão de Defeitos - Ferramenta Mantis

As opções para frequência da ocorrência do defeito são: sempre,

às vezes, aleatório, não se tentou, incapaz de reproduzir. A
gravidade se refere à severidade do defeito encontrado. As
opções para esse campo são: trivial, mínimo, pequeno, grande,
travamento (crash), obstáculo (block), recurso (funcionalidade
nova - feature).

A prioridade tem as opções: nenhuma, baixa, normal, alta, urgente

e imediato. É possível informar dados a respeito da plataforma e
sistema operacional, caso essas informações sejam relevantes
para o defeito. A versão do produto indica em qual versão o
defeito foi encontrado. As possíveis versões são cadastras pelo
administrador. Atribuir a permite designar para o desenvolvedor
responsável. Já o previsto para a versão indica em qual versão
o defeito está previsto de ser corrigido.

A Figura 17 apresenta o restante da tela.

www.esab.edu.br 84
Figura 17 – Tela de Registrar Defeito no Mantis - parte 2
Fonte: Print screen do http://www.mantisbt.org (2018)

Os campos resumo, descrição, passos para reproduzir,

informações adicionais, horas estimadas e horas gastas são
autoexplicativos. O carregar arquivo permite que o responsável
anexe arquivos. Essa funcionalidade é útil para anexar, dentre
outras coisas, o print da tela de erro. A visibilidade indica se o
defeito vai ficar visível para todos que têm acesso ao projeto ou se
vai ser restrito. Continuar relatando serve para o responsável
relatar outro defeito na sequência.

Um recurso importante do Mantis é a organização das informações,

permitindo ter acesso, de forma facilitada, a resumos e relatórios
que auxiliam na gestão e tomada de decisão. O Roadmap (na
versão em português está traduzido como planejamento)
apresenta os defeitos por versão do projeto, indicando a
porcentagem que já foi resolvida por versão e o quanto ainda falta.

www.esab.edu.br 85
Figura 18 – Roadmap do Mantis
Fonte: Print screen do http://www.mantisbt.org (2018)

Já o Resumo, apresenta estatísticas importantes a respeito dos

defeitos, que são importantes para o gerenciamento do processo
de testes. Como apresenta a figura 19, é possível saber a
quantidade de defeitos em todos os status (aberto, resolvido, etc.),
gravidade, dia, categoria, os mais ativos, os abertos há mais
tempo, etc.

Figura 19 – Resumo com estatísticas do Mantis

Fonte: Print screen do http://www.mantisbt.org (2018)

www.esab.edu.br 86
Outras estatísticas apresentadas pelo MANTIS são: status x
prioridade, status x resolução, estatísticas de relatores, eficiência
dos relatores (quantos % não foram considerados bug), relator
por resolução e desenvolvedor por resolução.

Vale ressaltar que o MANTIS permite gerenciar um número

ilimitado de projetos, sendo que o usuário pode escolher se deseja
visualizar as informações de todos os projetos ou de um projeto
específico.

Figura 20 – MANTIS
Fonte: Print screen do http://www.mantisbt.org (2018)

Outra informação interessante apresentada pelo MANTIS é o

histórico de mudanças por versão. Dessa forma, se algum cliente
entrar em contato relatando um defeito que já foi corrigido, é
possível identificar se a versão que ele está usando já contempla
a correção.

Figura 22 – Histórico de Mudança no Mantis

Fonte: Print screen do http://www.mantisbt.org (2018)

www.esab.edu.br 87
Essas foram algumas das facilidades oferecidas pela ferramenta
de gestão de defeitos MANTIS. Acesse o demonstrativo da
ferramenta para conhecê-la melhor!

Saiba Mais
Uma forma facilitada para instalar o MANTIS é
utilizando o Xampp, uma distribuição do Apache
contendo MySQL e PHP: http://www.
apachefriends.org/en/xampp.html.
O Xampp também permite instalar facilmente o
TestLink

www.esab.edu.br 88
Cobertura de Código - Ferramenta EclEMMA

A Cobertura de Código se refere a um conceito de teste de caixa-

branca para avaliar a porcentagem de uma classe, método, linha,
etc., que foram exercitados ao se executar um conjunto de testes.
Conforme Rabelo (2017, n.p.): “Cobertura de código te ajuda a
entender quando algum código que você escreveu, está sendo
executado, descobrindo se você tem linhas supérfluas e não
cobertas por testes, podendo ser removidas ou requerendo mais
testes.”

Para facilitar essa identificação, existem ferramentas que

automaticamente apontam a porcentagem exercitada por
determinado, em todas as classes do projeto. Essas ferramentas
pintam as linhas de acordo com cores, que normalmente são:
vermelho para linha que não foi exercitada, amarelo para uma
linha parcialmente exercitada, e verde para linha que foi exercitada
por completo ao menos uma vez. Uma delas é a Emma (2018).

Emma é uma ferramenta gratuita para identificar a cobertura de

código para Java. Existem outras ferramentas para outras lingua-
gens de programação, como o NCover para.Net, por exemplo. O
interessante do Emma é que para utilizá-la não vai ser necessário
mudar uma linha sequer do seu código fonte. O Emma vai obter
as estatísticas através da Java Virtual Machine (JVM) adicionando
um pequeno overhead de performance (processamento adicional),

www.esab.edu.br 89
agindo de forma silenciosa durante a execução dos testes. Os
resultados obtidos são imediatamente sumarizados e destacados
(pintados) no editor do código fonte. O Emma produz os seus re-
latórios em HTML, XML ou texto e no formato HTML, é possível
relacionar os resultados ao código fonte.

Visando facilitar ainda mais essa atividade, existem adaptações

para as IDEs (Integrated Development Environment - Ambiente
Integrado de Desenvolvimento). O EclEMMA (2018) é integração
do EMMA ao ambiente de desenvolvimento Eclipse. Portanto,
representa a utilização da filosofia do EMMA no Eclipse,
apresentando os indicadores de forma interativa. Ao instalar o
EclEmma, o botão aparecerá. Ao executar um teste do JUnit,
por exemplo, com essa opção o código fonte testado será pintado
de acordo com as cores vermelho, amarelo e verde, conforme
apresenta a Figura 23.

Figura 23 – Código fonte pintado de acordo com a cobertura do

código no Eclipse
Fonte: Print screen do http://emma.sourceforge.net

Como pode ser observado na figura, a utilização do EclEMMA

torna fácil a identificação das partes do código que não foram

www.esab.edu.br 90
testadas. Essa informação é bem útil visto que, por mais experiente
que o programador seja, ela pode esquecer-se de criar um teste
que execute um comando importante, parcialmente ou
completamente, diminuindo a probabilidade de encontrar defeitos.

Para ter uma visão geral do projeto, existe um relatório que

apresenta a porcentagem de cobertura geral, por projeto, pacotes,
classes e métodos facilitando visualizar em um só lugar o
andamento dos testes nesse aspecto. Esse relatório é apresentado
na figura a seguir. Assim o gerente de projetos pode acompanhar
se determinada porcentagem, definida como mínima para
qualidade, foi alcançada. Portanto, o gerente pode determinar
como indicador adicional, que o software só pode ser liberado se
tiver atingido no mínimo 85% de cobertura, por exemplo.

Figura 24 – Estatísticas de Cobertura de Pacote, Classes, Métodos,

etc.
Fonte: Print screen do http://emma.sourceforge.net

Segundo as referências do EMMA, a prática diz que percentuais

abaixo de 60% - 70% representam software testado de maneira
pobre, aumentando muito a probabilidade dos defeitos serem
encontrados pelos usuários. A referência afirma também que
atingir 100% não é economicamente viável. Existem muitos
métodos simples que inclusive são gerados automaticamente pela
IDE (ex: os que apenas retornam o valor de um atributo) que não
justificam escrever testes apenas para exercitá-los, se eles não

www.esab.edu.br 91
tiverem sido exercitados em um teste, naturalmente. A referência
diz que cobertura entre 80%-90% é o suficiente para a maioria dos
casos.

É importante observar que mesmo que a classe tenha 100% do

código coberto não significa que ela esteja livre de erros e não dá
para garantir que o teste foi bem elaborado. Um software
normalmente tem várias combinações de caminhos possíveis, e
apenas testar todas as linhas de um caminho não garante que os
outros caminhos estão corretos. Portanto, a cobertura de código
torna-se uma ferramenta útil para indicar facilmente se partes
importantes do código não foram testadas, mas não para garantir
por si só a qualidade dos testes. Como essa ferramenta não requer
nenhuma alteração no código fonte; é gratuita e rápida. Ela é muito
útil para o programador verificar a cobertura dos seus testes desde
o início do desenvolvimento e, frequentemente, a cada execução
dos mesmos.

Testes de Unidade e Integração - Ferramenta JUnit

Os desenvolvedores devem testar o seu próprio código na medida

em que desenvolvem e para isso realizam testes unitários e alguns
tipos de testes de integração. Para facilitar essa atividade, existem
ferramentas disponíveis com esse objetivo. O nome genérico para
ferramentas de teste de unidade é xUnit.

Nesta Unidade será apresentada a ferramenta para Java chamada

JUnit. Uma grande quantidade de linguagens de programação
possui ferramentas de teste de unidade, como é o caso do nUnit
(.Net), CppUnit (C++), dUnit (Delphi), PHPUnit (PHP), etc.

www.esab.edu.br 92
O JUnit é uma ferramenta gratuita. Foi originalmente criada por
Kent Beck e Erich Gamma (WIKIPÉDIA, 2018), dois grandes
nomes da ciência da computação. Kent Beck é o criador do XP
(Extreme Programming) e Erich Gama ficou famoso com o GoF
(Gang of Four - Gangue dos Quatro) referenciando os quatro
autores do livro sobre padrões de projeto (Design Patterns).

O conceito do xUnit foi criado por Kent Beck, um grande entusiasta

de testes automatizados. Para facilitar a organização e execução
de testes de unidade, Kent Beck desenvolveu uma ferramenta
xUnit para a linguagem de programação Smalltlk. Segundo Martin
Fowler, Kent Beck e Erich Gama começaram o JUnit em um voo
entre a Suíça e os Estados Unidos em 1997, aproveitando o tempo
no ar para fazer programação em par e realizando os testes antes
de desenvolver (conceitos defendidos por Kent Beck no XP)
(SOARES, 2018).

Sem a utilização de uma ferramenta de apoio, a forma padrão de

testar código unitário e alguns casos de integração era através de
debbugers ou mandando imprimir na tela o resultado dos métodos.
Essas formas são dependentes da análise humana para averiguar
se o resultado corresponde ao esperado, impedindo a execução
automática e desestimulando a repetição dos testes.

Ferramentas para esse objetivo facilitam essa atividade através

de uma estrutura pronta. O JUnit utiliza o conceito de asserções
(asserts) para verificar se o resultado do teste equivale ao que era
esperado. Assim, o assertTrue(<condição>) verifica se a condição
é verdadeira, o assertFalse(<condição>) verifica se é falsa e o
assertEquals (Objeto1, Objeto2) verifica se dois objetos são iguais.
Para informar que um método é um teste, basta colocar a anotação
@Test (importando o pacote import org.junit.Test) antes de sua
declaração.

www.esab.edu.br 93
Caso seja preciso preparar algumas condições (ex: inicialização
de variáveis) antes de o teste ser executado é possível criar um
método com a anotação @Before. Essa anotação é útil visto que
normalmente será necessário configurar determinadas
características para serem utilizado por vários testes. Já anotação
@After indica que o método será chamado após a execução do
teste.

Um exemplo simples de funcionamento do JUnit: Supondo-se um

método para realizar o depósito bancário para valores maiores ou
iguais à R$ 10,00. Quando o valor é menor do que R$ 10,00 o
depósito não deve ser realizado e a respectiva mensagem é
exibida. O código fonte (Figura 25), exibe as mensagens de retorno
e o método de realizar o depósito em conta.

Figura 25 – Código Fonte

Fonte: Print screen do http://emma.sourceforge.net

Criando os testes referentes a esse método. Antes de começar os

testes, será criada uma conta de número 12345-0 com saldo inicial
= R$ 100,00. O código abaixo apresenta a declaração da conta e
do saldo inicial, bem como o método com a anotação @Before
que cria a conta com o saldo inicial. Esse método será chamado
antes da execução de cada teste.

www.esab.edu.br 94
Figura 26 – Código Fonte (2)
Fonte: Print screen do http://emma.sourceforge.net

Nessa mesma classe, adicionam-se os métodos dos testes. É

importante testar primeiro a tentativa de depósito com valor menor
do que R$ 10,00. Nesse caso, o resultado esperado é a mensagem
de aviso que o valor deve ser maior do que R$ 9,99 e o saldo da
conta permanece inalterado.

Figura 27 – Código Fonte (3)

Fonte: Print screen do http://emma.sourceforge.net

Portanto o método realizarDepositoContaValorMenor10 foi

criado com a anotação @Test indicando que é um teste. Primeiro
está sendo verificado se a mensagem correta está sendo
retornada ao chamar o método realizarDepositoEmConta com
valor de R$ 9,99. Utilizou-se o assertEquals para compara dois
objetos do tipo String (texto). Em seguida, está sendo verificado
se o saldo da conta permanece inalterado, ou seja, é igual ao seu
valor inicial. Para esse caso, utilizou-se o assertTrue visto que
está sendo verificada uma condição lógica (verdadeiro ou falso).

www.esab.edu.br 95
Figura 28 – Teste Depósito Conta Bancária
Fonte: Print screen do http://emma.sourceforge.net

Ao executar o teste, o resultado apresentado na Figura 28 é

exibido, indicando que 1 teste rodou com sucesso, sendo o seu
resultado a barra verde. A seguir, é necessário rodar esse mesmo
teste com a execução do EclEmma, para ver como foi a cobertura
de código obtida no método que está sendo testado. A figura a
seguir apresenta o resultado.

Figura 28 – Teste com a execução do EclEmma

Fonte: Print screen do http://emma.sourceforge.net

Como foi testado somente para valores menores do que R$ 10,00,

o EclEmma apresentou que a parte do else não foi testada. Agora,
um teste para completar a cobertura do código. O teste vai
depositar R$ 10.000,00 na conta, e o resultado esperado será a
mensagem de depósito realizado com sucesso e o saldo da conta
será R$ 10.100,00, ou seja, o saldo inicial + R$ 10.000,00. Apenas
para ver o comportamento do JUnit, propositalmente, declara-se
que o saldo da conta deveria ser igual ao saldo inicial.

www.esab.edu.br 96
Figura 28 – Teste realizarDepositoContaValorIgual10_MIL()
Fonte: Print screen do http://emma.sourceforge.net

O código da figura 28, apresenta o teste

realizarDepositoContaValorIgual10_MIL() comparando se a
mensagem de retorno é a de depósito bem sucedido, e verificando
se o saldo da conta é igual ao saldo inicial, ou seja, verificando
uma condição errada.

Figura 29 – Teste realizarDepositoContaValorIgual10_MIL()

Fonte: Print screen do http://emma.sourceforge.net

Como o teste (figura 29) possui um erro, o JUnit indica que dois
testes foram executados, e um falhou, apresentando a barra ver-
melha. Ele indica através de ícones que o teste que causou o erro
foi o realizarDepositoContaValorIgual10_MIL(),sendo que o
primeiro teste foi bem sucedido realizarDepositoContaValorMe-
nor10(). Para consertar o segundo teste, deve-se substituir a se-
gunda verificação para comparar se o saldo final é igual ao saldo
inicial + R$ 10.000,00.

www.esab.edu.br 97
Figura 30 – Teste realizarDepositoContaValorIgual10_MIL()
Fonte: Print screen do http://emma.sourceforge.net

Ao executar esse teste (Figura 30), o JUnit apresenta o resultado

que os dois testes executados foram bem-sucedidos.

Figura 31 – Teste realizarDepositoContaValorIgual10_MIL(), bem-

sucedidos
Fonte: Print screen do http://emma.sourceforge.net

Por sua vez, o EclEMMA apresenta que o método foi completamente

coberto pelos testes.

Figura 32 – Teste realizarDepositoContaValorIgual10_MIL()

(EclEMMA)
Fonte: Print screen do http://emma.sourceforge.net

Esse foi apenas um exemplo simples para demonstrar o JUnit e o

EclEmma. As IDEs mais utilizadas no mercado já trazem o JUnit

www.esab.edu.br 98
integrado, pronto para uso, bastando adicionar a biblioteca ao seu
projeto.

Localização das Classes de Teste

É uma boa prática separar o pacote, com os arquivos de testes,

do pacote com os arquivos de desenvolvimento. O isolamento
permite que apenas o código da aplicação seja preparado para ir
para produção, desconsiderando os testes.

Figura 33 – Teste realizarDepositoContaValorIgual10_MIL()

(EclEMMA)
Fonte: Print screen do http://emma.sourceforge.net

A figura ao lado exemplifica essa separação, em que o código

fonte está no src e o código de teste no pacote test.

como sobre os aspectos da liberação do código corrigido.

www.esab.edu.br 99
 Estudo Complementar

Conheça Martin Fowler:

Martin Fowler é um renomado palestrante e autor
de artigos e livros, relacionados ao desenvolvimento
e testes de software. Trabalhou com Kent Beck no
C3 (projeto que Kent gerenciava e onde utilizou os
métodos ágeis que culminaram na escrita do livro
do XP). Desde 2000 trabalha na ThoughWorks
empresa desenvolvedora de ferramentas open-
source como o Selenium e o CruiseControl (para
Integração Contínua).
Possui ampla experiência e bons artigos sobre
Integração Contínua, e por isso foi utilizado como
referência para esta unidade. Maiores informações
e artigos disponíveis em: <http://martinfowler.
com>. Foto de: Adewale Oshineye.

www.esab.edu.br 100
Testes com Objetos Substitutos ou Falsificados (Mock
Objects) - Ferramenta Mockito

Metodologias ágeis e as boas práticas incentivam que os

desenvolvedores testem a todo o momento o seu código. Na
Unidade anterior foi visto como ferramentas no padrão xUnit
ajudam a atingir esse objetivo.

Para isolar os métodos ou classes durante os testes é possível

utilizar os objetos mocks, ou seja, objetos falsificados ou substi-
tutos. Os objetos mocks simulam ou imitam o comportamento de
outro objeto, permitindo definir o que o método substituto vai retor-
nar, de acordo com os parâmetros de entrada.

Os mocks oferecem diversos benefícios aos testes. Primeiramente,

permitem isolar a classe que está sendo testada. Também permite
simular estados dos objetos que podem ser difíceis de reproduzir,
realizando os testes em um ambiente controlado. Permitem
substituir, inclusive, objetos que não foram implementados. Outro
benefício é substituir objetos que podem demorar mais a serem
executados, como aqueles que precisam acessar banco de dados,
agilizando, assim, a execução dos testes. Para entender o seu
funcionamento, segue um exemplo.

Antes que um depósito possa ser realizado, é preciso verificar se

a conta bancária está ativa. Assim, o método
realizarDepositoEmConta chama o método

www.esab.edu.br 101
verificarSeContaAtiva(numConta) da classe ContaDAO (padrão
DAO de Data Acess Object, ou Objeto de Acesso a Dados) que
realiza uma consulta ao banco de dados para verificar se a conta
está ativa. Utilizando o mock é possível isolar o método
realizarDepositoEmConta, fazendo com que não seja preciso
realizar a consulta ao banco. Ou seja, determinar durante o teste
com o mock:

• Quando verificarSeContaAtiva for chamado para a conta

de número 12345, é para retornar que está ativa.
• Quando verificarSeContaAtiva for chamado para a conta
de número 67891, retornando que está inativa.

Dessa forma, quando realizarDepositoEmConta chamar o

método verificar SeContaAtiva, o objeto falsificado entrará em
ação e retornará a resposta determinada, sem executar de fato
esse último método e, consequentemente, sem realizar a consulta
ao banco de dados.

Figura 34 – Utilização de Objeto Mock

Fonte: Próprio autor

www.esab.edu.br 102
Ferramenta Mockito (Continuação)

Conhecido o conceito de objetos mock, a seguir apresenta-se uma

ferramenta que facilita a sua criação. Sem a utilização de uma
ferramenta, seria preciso alterar (ou até mesmo criar) o código da
classe original a ser substituída para verificar o parâmetro de
entrada e retornar um resultado esperado, poluindo o código
original e adicionando trabalho extra para depois voltar o código
ao normal.

A vantagem da ferramenta é justamente essa, ela permite criar

o comportamento desejado sem ter que alterar uma linha
sequer do código original.

A ferramenta apresentada também é gratuita para JAVA,

chamada Mockito. O conceito se repete para outras linguagens
orientadas a objeto, que também possuem ferramentas para
esse objetivo.

Figura 35 – MOCKITO (2018)

Fonte: Próprio autor

Para utilizar o Mockito, basta acessar o site e realizar o download

e colocar o jar no classpath do projeto.

O Mockito é muito simples de usar. Primeiro, cria-se o objeto

mockado:

www.esab.edu.br 103
Figura 36 – Objeto mockado
Fonte: Próprio autor

Depois, determina-se que o método deve retornar quando for

chamado. Exemplos:

Figura 37 – Objeto mockado (retornar o método)

Fonte: Próprio autor

Para ver na prática, repetiu-se o exemplo da unidade anterior

adicionando a verificação se a conta está ativa antes de realizar o
depósito.

Figura 37 – Objeto mockado (retornar o método)

Fonte: Próprio autor

www.esab.edu.br 104
Ferramenta Mockito

Na Figura 38, percebe-se, no código abaixo, que poucas

modificações foram feitas para a utilização do Mockito. As
alterações estão sublinhadas.

Figura 38 – Utilização do Mockito

Fonte: Próprio autor

O método realizarDepositoContaValorMenor10() não foi

alterado porque quando o valor é menor do que R$ 10,00 o código
não chega a verificar se a conta está ativa.

Já no método realizarDepositoContaValorMenor10, foi adicio-

nada a linha when (mockDao.verificarSeContaAtiva(12345)).
thenReturn(true); indicando que quando o método verificarSe-
ContaAtiva for chamado para a conta de número 12345, a res-
posta deve ser que a conta está ativa e o método original não será
executado. Assim, na linha imediatamente abaixo, ao chamar
conta.realizarDepositoEmConta(10000.00, 12345) o

www.esab.edu.br 105
realizarDepositoEmConta utilizará o objeto falsificado na hora
de verificar se a conta está ativa.

Figura 39 – método realizarDepositoContaValorMenor10

Fonte: Próprio autor

Executando os testes (Figura 39) obtém-se a barra verde indicando

que os dois testes foram realizados com sucesso.

Visualizando a cobertura do código, verifica-se que não foi criado

um teste que passe pela situação de uma conta inativa, conforme
apresenta a Figura 40:

Figura 40 – Visualização da cobertura do Código

Fonte: Próprio autor

Criando um teste para resolver essa situação (Figura 41):

www.esab.edu.br 106
Figura 41 – Teste de uma conta inativa
Fonte: Próprio autor

O código da Figura 41 apresenta o teste de uma conta inativa

realizarDeposito ContaInativa(). Primeiro foi indicado que ao
verificar se a conta 67891 está ativa, deve ser retornado falso. Em
seguida, é verificado se ao chamar realizarDepositoEmConta
para uma conta inativa, a mensagem correta é retornada.

Figura 42 – Barra verde do JUnit

Fonte: Próprio autor

Executando o teste, a barra verde do JUnit indica que os três

testes foram realizados com sucesso. Não será exibido aqui, mas
o EclEMMA indica que a cobertura para esse método foi 100%.
Pronto!

O Mockito oferece ainda outros métodos para verificar a quantidade

de vezes que o método foi chamado, se os métodos foram
chamados em uma determinada ordem, dentre outras facilidades.

www.esab.edu.br 107
 Atividade

Após o estudo referente ao Eixo Temático 2,

você será capaz de entrar na sua sala de aula
virtual e acessar a Lista 2 de atividades
objetivas. Boas atividades!

www.esab.edu.br 108
O objetivo do eixo temático sobre testes automáticos é o de
apresentar uma visão geral no intuito de colaborar para que os
alunos possam executar muitos casos de testes. Para isso,
buscou-se discorrer sobre as cinco unidades (6-10) desse eixo
temático :6. Casos de Teste – Conteúdo do Caso de Teste –
Características e Potenciais Problemas – Execução dos Testes –
Testes Orientados a Dados (DDT – Data Driven Test) –
Automatização dos Testes. 7. Gestão de Testes – Ferramenta
TestLink – Gestão de Defeitos (Conceito de Erro, Defeito e Falha)
– Gestão de Defeitos (Resolução do Defeito). 8. Gestão de Defeitos
– Ferramenta Mantis – Gestão de Defeitos – Ferramenta Mantis
(Continuação) 9. Cobertura de Código – Ferramenta EclEMMA –
Testes de Unidade e Integração – Ferramenta Junit – Localização
das Classes de Teste. 10. Testes com Objetos Substitutos ou
Falsificados (Mock Objects) – Ferramenta Mockito – Ferramenta
Mockito – Ferramenta Mockito (Continuação).

www.esab.edu.br 109
3: MODELAGEM E IMPLEMENTAÇÃO DE TESTES

Dentre as técnicas utilizadas para a construção de modelos de

software, encontra-se a modelagem e implementação de testes,
cujas características estão na identificação de todos os elementos
necessários para a implementação de cada caso de testes
especificado.

A modelagem pode ser realizada junto com a implementação de

testes, como por exemplo: os testes exploratórios. O TDD é uma
técnica a ser utilizada com o design Evolucionário, em contraposição
ao design planejado. 

Objetivo

Esclarecer sobre a importância do desenvolvimento da ferramenta

de modelagem e implementação de testes e, para isso, serão
vistas as seguintes unidades: Desenvolvimento Orientado a Testes
(TDD - Test Driven Devlopment) – Exemplo de TDD na Prática –
SELENIUN - Ferramenta para Gravar/Executar Testes em
Browsers.I – SELENIUN - Ferramenta para Gravar/Executar
Testes em Browsers II – SELENIUN - Ferramenta para Gravar/
Executar Testes em Browsers III – Teste de Performance e Estresse
– Ferramenta JMeter – Teste de Performance e Estresse -
Ferramenta JMeter IV – Integração Contínua – Controle de Versão
de Código – Integração Contínua - Ferramenta Jenkins I –
Integração Contínua - Ferramenta Jenkins II – Considerações
Finais – Ferramentas.

www.esab.edu.br 110
Desenvolvimento Orientado a Testes (TDD - Test Driven
Devlopment)

O Desenvolvimento Orientado a Testes mundialmente conhecido

como TDD (Test Driven Devlopment) consiste em um paradigma
para criar o teste antes de implementar o código do programa. O
TDD foi popularizado por Kent Beck(2003) (o mesmo Kent Beck
(2003) que criou o JUnit) na metodologia ágil XP (eXtreme
Programming) em 1999. Mesmo tendo sido difundido junto com o
XP, o TDD pode ser aplicado em qualquer metodologia de
desenvolvimento. Segundo o próprio Kent Beck (2003, p. 18): “É
uma forma previsível de desenvolvimento. O usuário saberá
quando terminou, sem ter que se preocupar com um longo rastro
de bugs.”

O TDD prega que código novo só é escrito quando um teste

automatizado falhar e, na medida em que o código vai evoluindo,
as duplicações são eliminadas. Adiante, um exemplo prático.

Em seu livro Test Driven Devlopment by Example (no Brasil o

título foi: TDD - Desenvolvimento Guiado por Testes), Kent Beck
(2003, p. 27) afirma que o TDD não é uma ideia nova (esta Unidade
foi baseada nesse livro). Segundo ele:

Desde os primórdios da computação

programadores especificam os inputs e outputs
antes de precisamente programar. TDD pega

www.esab.edu.br 111
 essa ideia antiga e mistura com linguagens e
ambientes de programação modernos, e
cozinha um ensopado saboroso garantido para
satisfazer seu apetite para código limpo que
funcione agora.

No livro, ele agradece ao autor do livro que leu aos 12 anos, que
sugeria que se escrevesse o output esperado a partir de um input
real e, então, codificasse até que os resultados atuais batessem
com o resultado esperado.

O mantra do TDD é Vermelho -> Verde -> Refatoração.

1. Vermelho: Escreva um teste que falhe, e que talvez nem

compile na primeira vez.
2. Verde: Faça o teste funcionar rapidamente, fazendo o que
for necessário para atingir esse objetivo.
3. Refatorar – Elimine todas as duplicações criadas e que
foram inseridas ao fazer o teste funcionar.

Os passos recomendados por Kent Beck (2003) para o TDD são:

• Rapidamente, adicione um teste;

• Rode todos os testes e veja o novo teste falhar;
• Realize uma pequena mudança;
• Rode todos os testes e veja todos eles serem bem-
sucedidos;
• Refatore para remover duplicidades;
• Boas práticas no tempo certo. Primeiro faça rodar,
posteriormente faça certo.

Assim, a ideia é que primeiro escreva o teste. Em seguida, faça o

teste ser bem-sucedido. No conceito TDD, fazer com que a barra
(estilo JUnit) fique verde, prevalece sobre qualquer outro ponto.

www.esab.edu.br 112
Segundo Kent Beck (2003), essa mudança estética é difícil para
desenvolvedores e engenheiros de software experientes, que só
conseguem escrever o código correto para passar em um teste.
Ainda de acordo com ele, tornar verde rápido perdoa todos os
pecados, mas apenas por um momento. Após fazer o teste passar,
faça corretamente. Em relação ao faça corretamente Kent (2003)
afirma que quando o código está se comportando corretamente,
elimine os pecados do passado recente, voltando ao caminho
estreito e reto da integridade do software. Nesse momento, remova
a duplicação que introduziu e faça a barra ficar verde rapidamente.
Esse conceito prega que primeiro seja resolvido à parte do
problema que funcione. Então, resolva a parte código limpo.

Seguindo esses passos, normalmente será percebido:

• Como cada teste pode cobrir um pequeno incremento da

funcionalidade;
• Quão pequena e “feia” a mudança pode ser para fazer o
novo teste rodar;
• A frequência com que os testes são executados;
• Quantos passos pequenos compõem uma refatoração.

Ao realizar TDD, recomenda-se que se tenha uma lista de tarefas

para lembrar o que deve ser feito e, ao mesmo tempo, manter o
foco. Um item finalizado deve ser riscado da lista. Ao pensar em
um novo teste para escrever, adicione à lista.

Segundo o livro de Kent Beck (2003), se uma solução simples e

limpa for óbvia, então a escreva. Se a solução for simples e limpa,
mas for tomar mais do que um minuto para ser executada, deve-
se escrever na lista e voltar para o problema principal, que é fazer
a barra ficar verde em segundos.

www.esab.edu.br 113
Para atingir rapidamente o verde, duas estratégias são utilizadas.

1. Fingir/Falsificar: consiste em forçar o resultado, como por

exemplo, retornar uma constante e gradualmente
substituindo por variáveis até chegar ao código real (Será
mais exemplificado da próxima Unidade).
2. Utilizar a implementação óbvia, já digitando a solução real.

Kent Beck (2003) varia entre as duas estratégias quando está

utilizando o TDD na prática. Quando tudo está fluindo
tranquilamente e ele sabe o que digitar, ele vai pela implementação
óbvia, sempre rodando os testes. Assim que ele obtém um
vermelho inesperado, ele recua, volta para a implementação
falsa, e refatora o código correto.

Segundo Erich Gamma (2006), a maioria das pessoas que aprende

TDD identifica que suas práticas de programação mudaram para
melhor. Ele cunhou o termo Test Infected (Contagiado pelos
Testes) para esse tipo de situação. Por outro lado, alguns
engenheiros de software aprendem TDD e continuam com sua
forma padrão de desenvolvimento, deixando o TDD para ocasiões
especiais em que não sente que está tendo progresso.

“Você pode se encontrar escrevendo mais testes antecipadamente

e trabalhando em passos menores do que você poderia imaginar
que seria possível” (BECK, 2013, p. 18) .

Exemplo de TDD na Prática

Após ter estudado os principais conceitos do TDD, será apresentado

um exemplo prático do TDD, baseado no livro “Test Driven
Devlopment by Example” de Kent Beck (2013).

www.esab.edu.br 114
O exemplo apresentado refere-se à sequência de Fibonacci. A
série de Fibonacci (representado abaixo por F()=) tem a seguinte
formação:

• F(0) = 0
• F(1) = 1
• F(2) = 1
• F(n-1) + F(n-2), para qualquer outro número maior do que 2

Assim, tendo n = 3, F(3) = F (3 - 1) + F (3 - 2) = F (2) + (1) = 1 + 1

= 2. Já para n=4, F(4) = F(3) + F(2) = 2 + 1 = 3. Portanto a sequência
é: 0,1,1,2,3,5,8,13, ...

Agora que a série de Fibonacci foi apresentada, segue à resolução

com o TDD.

O primeiro teste apresenta que Fib(0) = 0. Seguindo os conceitos

do TDD, antes de desenvolver o código, é importante desenvolver
o teste para ele.

Figura 43 – Teste apresenta que Fib(0) = 0

Fonte: Próprio autor

O código da figura 43 representa esse teste escrito com o JUnit,

que já foi estudado neste Módulo. Portanto, verifica (assertEquals)
se o resultado de fibonacci.fib(0)é 0. Esse teste não vai nem
compilar, viso que a classe Fibonacci ainda nem foi criada. O
objetivo é esse mesmo, lembrando o mantra TDD: Passo 1:
Vermelho – deve-se fazer um teste que falhe, e que talvez nem

www.esab.edu.br 115
compile na primeira vez. Passo 2: Verde - Fazer o teste
funcionar rapidamente, fazendo o que for necessário para
atingir esse objetivo.

Portanto, deve-se criar a implementação de Fibonacci mais

simples possível para passar no teste criado.

Figura 44 – Teste com implementação de Fibonacci

Fonte: Próprio autor

Executando o teste, atinge-se o objetivo de conseguir a barra

verde o mais rápido possível. Para isso, cria-se um código que
independente do número de entrada, sempre retornará o número
zero.

Figura 45 – Teste com implementação de Fibonacci (Barra verde)

Fonte: Próprio autor

Executando o teste, atinge-se o objetivo de conseguir a barra

verde o mais rápido possível. Para isso, cria-se um código que
independente do número de entrada, sempre retornará o número
zero. Escrevendo o segundo teste, para Fib(1)= 1.

Figura 46 – Teste, para Fib(1)= 1

Fonte: Próprio autor

www.esab.edu.br 116
O teste vai falhar, visto que de acordo com o código implementado
Fib(1) =0 ao invés de 1. Esse comportamento está de acordo com
o que prega o TDD. Agora, acerta-se o código, desenvolvendo
uma implementação mais simples para obter a barra verde.

Figura 47 – Teste, com implementação mais simples

Fonte: Próprio autor

Figura 48 – Teste, com implementação mais simples (2)

Fonte: Próprio autor

Figura 49 – Teste, com implementação mais simples (2)

Fonte: Próprio autor

O código bem simples, que retorna 0 quando n = 0, e 1 para todos

os demais números de entrada foi criado, e o teste passou.

O próximo teste é Fib (2) =1.

www.esab.edu.br 117
Figura 50 – Teste Fib (2) =1
Fonte: Próprio autor

Esse teste vai passar, visto que o código está sempre retornando
1, para números diferentes de 0. Se reparar no teste, cada linha é
cópia da linha anterior alterando apenas dois números. Seguindo
a recomendação do TDD, refatore para eliminar a duplicidade
(aplica-se ao teste também).

Figura 51 – Teste Fib (2) =1

Fonte: Próprio autor

Portanto, o teste foi refatorado de forma que para inserir novos

testes, basta colocar na matriz “casos” o par “{n, resultado
esperado}”.

O próximo teste é Fib (3) = 2. Adicionando no teste {3,2} e rodando,

obtém-se o seguinte resultado:

Figura 52 – Teste Fib (3) =1

Fonte: Próprio autor

www.esab.edu.br 118
A barra vermelha é apresentada com a mensagem de erro do
JUnit: era esperado o resultado 2 mas foi obtido 1. A mensagem
de erro do JUnit acompanha todos os testes vermelhos, ela foi
omitida nos outros exemplos, mas foi inserida aqui para
conhecimento de mais esse recurso.

Alterando o código para o teste passar:

Figura 53 – Teste Fib (3) =1 (2)

Fonte: Próprio autor

Para fazer o teste Fib(3) passar, o número 2 está sendo retornado

para números de entrada > 2. Mas utilizando o conhecimento
sobre Fibonacci, sabe-se que F(3) = 2 porque F(3) = F(3 -1) +
F(3-2) = 1 + 1 = 2. Portanto, vamos aplicar essas substituições,
passo a passo no código, antes de ir para o próximo teste. Cada
alteração no código, o JUnit deve ser rodado novamente para ver
se os testes anteriores continuam funcionando. A primeira mudança
é substituir o 2 por 1 + 1.

Figura 54 – Teste Fib (3) =1 (3)

Fonte: Próprio autor

www.esab.edu.br 119
Como se sabe que o primeiro 1 = F(n-1), se faz essa alteração.

Figura 55 – Primeiro 1 = F(n-1)

Fonte: Próprio autor

A seguir, na Figura 56, substituir o segundo 1 = F(n -2).

Figura 56 – Substituir o segundo 1 = F(n -2 )

Fonte: Próprio autor

Pronto, agora todos os demais testes vão passar. Rodando cada

um deles por vez: Fib(4) = 3, Fib(5)=5, Fib(6)=8, etc., obtém-se a
barra verde em todos. Chega-se então à resolução do problema,
utilizando-se os conceitos do TDD:

1. Vermelho: Escreva um teste que falhe, e que talvez nem

compile na primeira vez
2. Verde: Faça o teste funcionar rapidamente, fazendo o que
for necessário para atingir esse objetivo.
3. Refatorar – Elimine todas as duplicações criadas, que
foram inseridas ao fazer o teste funcionar.

O próximo passo é realizar o teste para valores ilegais, adicionando

a proteção ao código para tratar os números negativos.

www.esab.edu.br 120
Tamanho dos passos

Algumas pessoas podem ter achado os 3 últimos passos muito

pequenos: substituir 2 por 1 + 1; substituir 1 + 1 por fib(n -1) + 1; e
por fim substituir fib(n-1) +1 por fib(n-1) + fib(n-2).

Se os passos parecerem muito pequenos, lembre-se que TDD

não prega que se realizem passos pequenos, mas que se tenha a
habilidade de realizar os passos pequenos. Segundo Kent Beck,
ele não codifica no dia a dia com passos tão pequenos. Mas
quando as coisas começam a complicar o mínimo possível, ele se
diz contente por poder realizar os passos pequenos. Ele recomenda
que se tentem passos pequenos com um exemplo. Se conseguir
fazer os passos muito pequenos, certamente conseguirá fazê-los
do tamanho correto. Se apenas fizer passos grandes, nunca
saberá quando passos menores são apropriados.

Após ter visto o exemplo prático, pode ser uma boa pedida estudar
novamente a Unidade anterior, visto que os conceitos estão mais
claros e o aprendizado de um paradigma novo será reforçado.

Estudo Complementar

Veja estas informações através dos links abaixo que lhe

ajudará no aprendizado:

http://redspark.io/tdd-na-pratica/
https://www.youtube.com/watch?v=2hcGxVYfec0
https://slideplayer.com.br/slide/344560/

www.esab.edu.br 121
SELENIUN - Ferramenta para Gravar/Executar Testes em
Browsers I

Figura 57 – Selenium, HQ, 2018

Fonte: Próprio autor

O Selenium é uma ferramenta gratuita muito boa para automatizar

os testes de aplicações WEB. Com o Selenium é possível gravar
todos os passos (cliques, inserção de dados, etc.) realizados pelo
usuário em um site, para depois reproduzir os mesmos.

Ela suporta diferentes linguagens de programação como Java,

Javascript, Ruby, PHP, Python, Perl e C#, e a quase todos os
browsers como Firefox, Google Chrome, Internet Explorer, etc.

O Selenium foi criado em 2004 por Jason Huggins da ThoughtWorks

(DEVMEDIA, 2018), quando ele estava realizando testes de uma
aplicação web. Ao perceber que existia uma forma melhor de
executar os testes, sem ter que executá-los manualmente a cada
mudança, ele desenvolveu uma biblioteca Javascript para realizar
interações com a página, sendo que era possível rodar os testes
em diferentes browsers. Essa biblioteca se tornou o núcleo do
Selenium, uma ferramenta inovadora visto que na época não

www.esab.edu.br 122
existia nenhum outro produto que permitia controlar o browser de
uma linguagem de programação escolhida pelo programador
(HUNT et al., 2011).

Em 2006, Simon Stewart engenheiro do Google iniciou um projeto

chamado de WebDriver para contornar algumas limitações do
Selenium, já que o Google era um usuário assíduo dessa
ferramenta. Em 2008 o WebDriver e Selenium foram unificados.
Assim surgiu o Selenium 2 (Selenium WebDriver), enquanto o
anterior era o Selenium 1 (Selenium Remote Control - RC). O
mais atual possui uma API mais coesa e orientada para objetos
com funcionalidades que derrubam algumas limitações da
implementação antiga. O Selenium 2 também roda a interface do
primeiro Selenium, para prover compatibilidade.

Mesmo com a existência da versão 2, o Selenium 1 ainda recebe

suporte porque, segundo o próprio manual, existem funcionalidades
que podem não ser inseridas no Selenium 2 por um bom tempo
(HUNT et al., 2011).

O Selenium IDE (Integrated Development Environment - Ambiente

Integrado de Desenvolvimento) é um plugin para Firefox que
facilita a criação dos scripts de teste, pois grava todas as ações
dos usuários, na medida em que ele navega pelo site ou aplicação
web. Após salvar, é possível exportar o código para as várias
linguagens de programação que são suportadas pelo Selenium,
de forma a permitir a execução futura. Mesmo o IDE sendo
somente para Firefox, os testes criados podem ser executados
em qualquer browser compatível através da linha de comando
do Selenium RC. Ou seja, para gravar os passos de forma
facilitada vai ser necessário utilizar o Firefox, mas para executá-
los é possível utilizar qualquer browser.

www.esab.edu.br 123
O Selenium IDE não fornece iterações (while, for, etc.), nem
condicionais (if, else,etc) para os scripts, e não existe planejamento
até o momento para adicionar essas funcionalidades. Isso porque
o IDE tem o objetivo de ser uma ferramenta para prototipar os
testes rapidamente e mesmo sem essas funcionalidades, é uma
das formas mais eficientes de se desenvolver os scripts de teste
para aplicações web. Caso deseje utilizar as iterações e
condicionais para realizar testes mais complexos, é possível
exportar o script criado no IDE para uma das linguagens de
programação e em seguida alterar o código, funcionando tanto
para o Selenium 1 quanto para o Selenium 2.

Outra alternativa para utilizar iterações e condicionais, mas do

próprio browser, é através da instalação de uma extensão,
chamada goto_sel_ide.js (MOZILLA, 2018).

Para instalar o Selenium, vá até a página: <http://seleniumhq.org/

download/>. Para instalar o Selenium IDE, utilize o FireFox, clique
no link e confirme. Assim, os dois já são integrados. Realize
também o download do Selenium RC. Para rodar o Selenium
IDE, utilize uma das duas formas apresentadas na Figura 58:

Figura 58 – Formas de rodar o Selenium IDE

Fonte: Print screen do http://seleniumhq.org/download

www.esab.edu.br 124
Ao executar, a tela do Selenium será exibida. Por padrão o botão
vermelho já vem marcado, indicando que o modo de gravação
está ativado.

Figura 59 – Selenium IDE

Fonte: Print screen do http://seleniumhq.org/download

Com o botão de gravação ativado, tudo que o usuário fizer na

página será gravado.

SELENIUN - Ferramenta para Gravar/Executar Testes em

Browsers II.

Repare na Figura 60 que o Selenium IDE gravou a navegação do

usuário, que consistiu em abrir a página do Mantis e em seguida
digitar o nome Pedro no campo username. A figura destaca em
vermelho o comando gerado pelo Selenium ao digitar o username.

Figura 60 – Gravação dos passos do usuário com o Selenium IDE

Fonte: Print screen do http://seleniumhq.org/download

www.esab.edu.br 125
A Figura 60 mostra apenas, até o momento, que foi digitado o
username, mas continuando o processo para fazer o login, ao
informar a senha e clicar no botão Login o Selenium salvará
todos esses passos. Interrompendo a gravação e clicando no
botão do Selenium play, todos os passos gravados serão
executados, fazendo o login automaticamente no exemplo,
casos os dados informados sejam válidos. Simples e genial!

Portanto, durante a gravação, o Selenium IDE automaticamente

adicionará os comandos no script de acordo com as ações do
usuário, como por exemplo: clicar em um botão, em um link,
checkbox, etc., preencher campos da página (ex: login, senha,
nome, idade, etc.); e selecionar uma opção de uma caixa de
seleção (drop down).

É importante perceber que normalmente ao preencher os campos

da página, é preciso sair do campo para que o comando type seja
gravado, ou seja, na figura anterior, após informar o username, foi
preciso ir para o próximo campo (ou clicar em outro ponto da
página) para o comando ser gravado.

Ao clicar em um botão, link, etc., o comando click ou clickAndWait

será gravado. O clickAndWait deve ser utilizado quando for
preciso aguardar alguma situação, como por exemplo, a próxima
página ser carregada. Caso contrário, o teste vai continuar
executando, antes da página ter carregado todos os elementos,
o que pode provocar falhas no teste. Isso acontece porque a
velocidade de execução do Selenium (rodando na máquina
local) é mais rápida do que o tempo de resposta do servidor.

www.esab.edu.br 126
Figura 60 – comando click
Fonte: Print screen do http://seleniumhq.org/download

A IDE oferece algumas opções para executar os casos de teste.

É possível rodar o script gerado por completo, interromper e
continuar, alterar a velocidade da execução, executar uma linha
por vez e rodar todos os scripts do Test Suite. É possível executar
também um único comando, sendo essa funcionalidade útil para
verificar se o comando que se está desenvolvendo está correto,
sem ter que executar o teste inteiro novamente. Ao clicar com o
botão direito nos comandos é possível incluir opções que
permitem debugar o script, como inserir um breakpoint para
forçar uma interrupção em um comando particular, e definir um
ponto de início no meio do teste.

Os comandos do Selenium, frequentemente, são chamados de

Selenese e, ao serem colocados em sequência, formam o script
de teste. O Selenium oferece uma boa quantidade de comandos
que permitem verificar: se determinado texto está presente na
página, o tamanho da janela, mensagens, a existência de um
elemento na página, dentre inúmeras outras funções. Ao clicar em
um elemento da página com o botão direito do mouse, a lista de
comandos e parâmetros do Selenium referentes ao mesmo são
exibidos, conforme apresenta a figura a seguir. Essa facilidade
economiza tempo e é uma excelente forma de aprender a sintaxe
do Selenium.

www.esab.edu.br 127
Figura 61 – Exibição dos comandos disponíveis para determinado
elemento
Fonte: Print screen do http://seleniumhq.org/download

A sintaxe dos comandos é simples, consistindo de 3 parâmetros:

o comando em si, o alvo da ação e o valor. Os parâmetros não são
sempre obrigatórios, variam de acordo com o comando selecionado.
O comando da figura 62, extraído da Figura 61 informa que será
digitado (type) o valor Pedro no campo username.

Figura 62 – Comando da figura 61

Fonte: Próprio autor

Existem três tipos de comandos: as ações - como digitar (type),

clicar (click), etc.; os acessors que salvam valores em variáveis,
como o comando store; e os assertions (verificadores) que

www.esab.edu.br 128
verificam se algo está conforme o esperado, como por exemplo,
garanta que a palavra Administrador está presente na página
após o login.

Os assertions, por sua vez, podem ser de três formas: comando

assert, que aborta o teste em caso de alguma falha; comando
verify que registra a falha no log, mas prossegue com o teste; e o
waitFor que espera até a condição ser verdadeira (espera durante
um timeout configurado). O waitFor é importante para testar
aplicações Ajax. Quanto à diferença do assert e verify, cada um
tem sua utilidade. Por exemplo, se o teste verificar que foi
direcionado para uma página diferente da esperada, geralmente
não vai fazer muito sentido continuar com o teste e, nesse caso,
usaria o assert para abortar em caso de falha. Por outro lado,
pode ser desejado testar vários elementos de uma mesma página
de uma vez, mesmo que um deles apresente erro, utilizando assim
o verify.

Seguem abaixo alguns dos comandos mais utilizados para testar

as páginas com o Selenium:

• open: utiliza a URL para abrir a página.

• click/clickAndWait: clica no elemento especificado no
parâmetro alvo.
• verifyTitle/assertTitle: verifica se o título da página contém
determinado texto.
• verifyTextPresent: verifica se o texto especificado está em
algum lugar na página.
• verifyText: verifica se o texto especificado está em um
determinado elemento HTML.
• verifyElementPresent: verifica se um elemento como link,
parágrafo, etc., está presente na página.

www.esab.edu.br 129
 • waitForElementPresent: aguarda até o elemento HTML
estar presente na página.

SELENIUN - Ferramenta para Gravar/Executar Testes em

Browsers III

Conforme foi possível observar, muitos comandos precisam

identificar um elemento HTML (alvo) para realizar determinada
ação. Mas como fazer essa identificação? A seguir, algumas
formas, tomando como exemplo a Figura 63:

Figura 63 – Exemplo de uma página HTML simples para Login

(HUNT et al., 2011)
Fonte: Próprio autor

Localizar por identificador: localizar o primeiro elemento HTML

correspondente ao id. Se o id não estiver presente, retornar o
primeiro elemento correspondente ao name. Portanto, se no alvo
estivesse identifier=loginForm, o comando seria realizado sobre o
elemento da linha 3. Se estivesse identifier=username, o comando
seria realizado sobre o elemento da linha 4.

Localizar por id: localizar o primeiro elemento correspondente ao

id, sendo que não se verifica no name. Portanto, se no alvo estiver
id=loginForm, o comando será realizado sobre o elemento da linha
3.

www.esab.edu.br 130
Localizar por nome: localizar o primeiro elemento correspondente
ao name. Voltando ao exemplo da Figura 61, percebe-se que essa
estratégia foi utilizada visto que o alvo está name=username.
Portanto, o comando especifica para digitar (type) o valor Pedro
no alvo que name=username. Se dois elementos tiverem o mesmo
nome, é possível utilizar outro atributo, em conjunto, para
identificação. Assim, um alvo que especifique name=continue
value=Clear indica para o comando ser realizado no elemento da
linha 7.

Localizar por Xpath: é uma maneira versátil de localizar um

elemento, facilitando identificações do tipo: localizar a quinta
linha de uma tabela. É possível localizar através do caminho
absoluto (que não é recomendado visto que o teste fica propenso
a falhar com uma mudança pequena da aplicação) ou caminho
relativo. Portanto, nesse exemplo, se o alvo for xpath=/html/body/
form[1], o comando será aplicado ao elemento da linha 3, visto
que é o primeiro form. Esse é um exemplo de caminho absoluto.
Se no alvo estiver //form[@id=’loginForm’]/input[4], o comando
será realizado sobre o elemento da linha 7, visto que esse caminho
relativo primeiro identificou o form de id=loginForm, para depois
localizar o quarto input desse form. Vale observar que começar
com xpath ou // produz o mesmo resultado. Para saber mais sobre
Xpath, acesse o tutorial disponível em: <http://www.w3schools.
com/Xpath/>.

Existem formas de localizar os elementos HTML também pelo

texto do link, por DOM (Document Object Model), utilizando
Javascript ou por CSS (Cascading Style Sheets).

Em relação à comparação de determinado texto da página, o

Selenium oferece a possibilidade de verificar por padrão de texto,
sendo essa uma forma flexível já que não vai ser necessário utilizar
o texto exato. Uma das formas de padrão de texto é através da

www.esab.edu.br 131
expressão regular. Assim, verifyTextPresent regexp.*
Administrador.*Bem.*Vindo, verifica se existe texto contendo as
palavras Administrador, Bem e Vindo, mesmo se estiver com
outras palavras ou caracteres entre elas.

Agora, que já se conhece um pouco mais sobre os comandos do

Selenium, o próximo passo é gravar um teste para depois executá-
lo automaticamente. O teste gravado será: ir à página de
demonstração do Mantis para ver se o texto de erro aparece na
página ao tentarmos efetuar login com usuário e senha inválidos.

O teste consiste em abrir a página de demonstração do Mantis,

digitar o nome Pedro no campo username, digitar Pedro no
campo password, clicar no botão, e verificar se aparece alguma
mensagem contendo as palavras disabled,blockedouincorrect,
indicando usuário e senha inválidos. A tabela abaixo apresenta os
comandos gerados ao gravar o teste com o Selenium.

Comando Alvo Valor

/demo/login_page.
open
php?return=%2Fdemo%2Fmy_view_p
type name=username pedro

type name=password pedro

clickAndWait css=input.button
verifyText css=font *disabled*blocked*incorrect*

Figura 64 – Teste de Login errado com Selenium

Fonte: Próprio autor

A Figura 65 apresenta a execução automática de todos os passos

gravados (Figura 64), com destaque para indicação da execução
com sucesso do teste no Selenium e a mensagem informando do
login sem sucesso. Portanto, automaticamente o Selenium

www.esab.edu.br 132
informou o usuário Pedro, senha Pedro, clicou no botão para login
e verificou se a mensagem de erro foi apresentada.

Figura 64 – Resultado da execução do Selenium

Fonte: Print screen do http://seleniumhq.org/download

É possível salvar o teste e executá-lo posteriormente. A ferramenta

permite carregar vários testes salvos, e executar todos. O conjunto
de testes é chamado de Test Suite. O painel em destaque, na
figura 63, mostrará quantos dos testes executados falharam.

Após criar o teste, é possível exportá-lo para uma das linguagens

de programação suportadas, conforme mostra a figura 65. No
exemplo, o arquivo está sendo exportado para a linguagem de
programação Java (opção JUnit).

Figura 65 – Exportando os comandos gravados para uma

linguagem de programação
Fonte: Print screen do http://seleniumhq.org/download

www.esab.edu.br 133
Uma vez exportado para a linguagem de programação desejada,
é possível continuar programando normalmente.

Para executar o teste a partir do Java, basta colocar o jar (ex:

selenium-java-2.0b2.jar) do Selenium no classpath do projeto
(para demais linguagens, consulte o manual de referência). O
servidor (Selenium 1 ou 2) deve estar rodando quando for
executar o arquivo java que foi salvo, bastando, para isso, digitar
na linha de comando java –jar selenium-server-standalone-
2.0b2.jar. Ou então colocar como atividade.

Estudo Complementar

Para uma um melhor aproveitamento desta

unidade 12, acesse o link abaixo:

https://www.seleniumhq.org/projects/
webdriver/

www.esab.edu.br 134
Teste de Performance e Estresse - Ferramenta JMeter

Para saber como o sistema se comporta com utilização dos

recursos padrão, no limite, e acima do limite, é importante realizar
os testes de performance e os de estresse.

Antes de iniciar os testes de performance e estresse, é importante

responder algumas perguntas: Qual é o número médio (conhecido
ou esperado) de usuários em uma carga normal? Qual é o pico de
usuários esperado? O servidor em que os testes serão realizados
pode ser interrompido? Qual momento adequado (ex: madrugada,
final de semana, etc.) para realizar os testes de performance e
estresse nesse servidor? Quais são os resultados esperados (ex:
tempo de resposta por quantidade de usuários)?

Figura 66 – JMeter (2018)

Fonte: Print screen do http://jakarta.apache.org/jmeter/

O JMeter (disponível em: <http://jakarta.apache.org/jmeter/>) é

uma ferramenta gratuita da Apache pare realizar testes de
performance e estresse em Aplicações Web, Banco de Dados,
Servidores FTP, dentre outros. Para realizar os testes em
aplicações Web, o JMeter permite que você salve a navegação

www.esab.edu.br 135
pelo site para, posteriormente, durante a execução do teste,
reproduzir os mesmos passos.

A seguir, os passos necessários para gravar os testes e em seguida

executá-los. Após efetuar o download do JMeter, basta acessar a
pasta bin e clicar 2 vezes em jmeter.bat (para usuários Windows).
O JMeter abrirá contendo Test Plan (plano de teste) e WorkBench
(área de trabalho). O WorkBench é a parte em que será realizada
a configuração para gravar o teste, e o Test Plan é o local onde o
teste será salvo para poder ser executado.

Clique com o botão direito em Test Plan, e em seguida selecione

Add>Threads (Users)>Thread Group. Dessa forma o Thread
Group será adicionado ao seu plano de teste. O Thread Group
representa o número de threads (processos, ou nesse caso
também pode ser usuários) que acessarão o site em paralelo.

Figura 67 – Test Plan

Fonte: Print screen do http://jakarta.apache.org/jmeter/

Clique com o botão direito em Thread Group, e em Add>Config

Element> HTTP Request Defaults (conforme imagem ao lado),
para adicionar as configurações da requisição Http.

www.esab.edu.br 136
Figura 68 – Thread Group
Fonte: Print screen do http://jakarta.apache.org/jmeter/

No elemento HTTP Request adicionado, informe a URL ou IP da

aplicação Web que deseja testar. Para não sobrecarregar nenhum
site, vou realizar a demonstração com um Mantis que instalei
localmente. Deixe os outros campos vazios.

Figura 69 – HTTP Request

Fonte: Print screen do http://jakarta.apache.org/jmeter/

Vamos agora para o WorkBench, configurar a parte responsável

pela gravação do teste. Clique com o botão direito no WorkBench,
Add>Non-Test Elements>HTTP Proxy Server. Esse elemento
serve para gravar as requisições que serão enviadas para o
servidor. Vale ressaltar que essa parte não será salva no plano de
teste, ou seja, ao fechar o teste no JMeter e abrir novamente, será
preciso configurar um novo HTTP Proxy Server, visto que esse
elemento é utilizado apenas no momento de gravar o teste, e não
durante a sua execução. Para aplicações que precisam de cookie,
adicione um HTTP Cookie Manager.

www.esab.edu.br 137
Figura 70 – URL Patterns to exclude
Fonte: Print screen do http://jakarta.apache.org/jmeter/

Quando o JMeter grava uma execução, ele grava todas as

requests das páginas, incluindo requests de imagem, stylesheets,
arquivos javascript, etc. Portanto, no HTTP Proxy Server é
importante filtrar os arquivos que não devem ser salvos no plano
de teste. A Figura 70 apresenta a configuração para excluir os
arquivos do tipo css, gif, png e ico (padrão: “.*\nome”).

Figura 71 – Configurar o proxy do navegador

Fonte: Print screen do http://jakarta.apache.org/jmeter/

Para poder gravar, será preciso configurar o proxy do navegador.

Vamos demonstrar como fazer no Firexox: clique em
Ferramentas>Opções> Avançado>Rede> Configurar conexão
(Figura 71).

www.esab.edu.br 138
Figura 72 – Configurar conexão
Fonte: Print screen do http://jakarta.apache.org/jmeter/

Na janela de Configurar conexão, selecione a opção

Configuração manual de proxy:, coloque HTTP: localhost e a
porta 8080. Marque a opção Usar este proxy para todos os
protocolos. Repare se Sem proxy para não contém localhost.
Se tiver, apague. É importante lembrar-se de voltar ao modo
padrão (Sem proxy) após salvar os testes, caso contrário não
conseguirá acessar páginas nesse navegador quando o JMeter
estiver desligado.

Figura 73 – HTTP Proxy Server do JMeter

Fonte: Print screen do http://jakarta.apache.org/jmeter/

Volte na tela HTTP Proxy Server do JMeter e clique em Start para

começar a gravar o teste (conforme Figura 73).

www.esab.edu.br 139
Em seguida vá ao navegador com o proxy configurado e digite o
endereço da aplicação web/site que deseja testar. No caso desta
demonstração:

<http://localhost/mantis/>. A partir de agora, toda a navegação

será salva no JMeter, incluindo os dados informados para login e
senha, as páginas clicadas, etc.

Teste as suas configurações e verifique se está gravando o que

interessa, e exclua o restante. Após realizar a navegação desejada,
volte no JMeter e clique no botão Stop para encerrar a gravação.

Teste de Performance e Estresse - Ferramenta JMeter IV

A Figura 74 apresenta o resultado da gravação do teste. É possível

perceber que todas as páginas navegadas foram salvas no Thread
Group, em conjunto com os dados pertinentes. Por exemplo, na
página de login, foram salvos os dados de username e senha para
o JMeter poder realizar o login automaticamente.

Figura 74 – Páginas salva e Dados da Página de Login

Fonte: Print screen do http://jakarta.apache.org/jmeter/

O JMeter oferece diferentes estatísticas para permitir acompanhar

o resultado dos testes. Antes de executar o teste, vamos adicionar
duas opções de visualização. Clique com o botão direito em
www.esab.edu.br 140
Thread Group, e em Add>Listener>View Results Tree, e em
Add>Listener>View Results in Table. Vamos agora configurar os
dados para executar o teste, como informações do número de
usuários simultâneos e de quanto em quanto tempo novos usuários
devem ser iniciados. Para isso, clique em Thread Group e configure
os dados a seguir.

Figura 75 – Thread Group

Fonte: Print screen do http://jakarta.apache.org/jmeter/

Informe o número de usuários (nesse caso os threads) que devem

acessar a aplicação durante o teste. O Ramp-Up Period serve
para informar ao JMeter em quanto tempo ele deve iniciar todos
os usuários. Assim, se forem configurados 10 usuários com um
Ramp-Up de 20 segundos, o JMeter começará um novo usuário a
cada 2 segundos (20/10) visto que tem 20 segundos para iniciar
os 10 usuários. No caso da figura, os 10 usuários vão ser iniciados
em 1 segundo. O Loop Count serve para informar quantas vezes
o teste deve ser repetido.

Uma vez definidos esses parâmetros, clique em Run>Start. O

quadro verde e os números no canto superior direito indicam que
o teste está rodando. Acesse o View Results Tree e o View Results
in Table (ou algum outro que tenha adicionado) para visualizar
informações e estatísticas a respeito da execução.

www.esab.edu.br 141
Figura 76 – Informações apresentadas em View Results in Table
do JMeter
Fonte: Print screen do http://jakarta.apache.org/jmeter/

No View Results in Tables é possível visualizar o tempo de início,

o nome do thread, a página acessada, o tempo de execução,
status e número de bytes. No View Results in Tree é possível ver
mais detalhes de cada item testado, como o resultado, a requisição
e resposta de uma tentativa de acesso. A figura abaixo apresenta
a visualização da resposta em HTML a uma requisição para a
página login.php.

Figura 77 – Informações apresentadas em View Results Tree do

JMeter
Fonte: Print screen do http://jakarta.apache.org/jmeter/

A quantidade de threads executando no JMeter vai ser limitada

pela capacidade do hardware. Outro ponto que influencia, é a

www.esab.edu.br 142
velocidade do servidor. Um servidor rápido responde às requisições
mais rapidamente e assim, o JMeter trabalhará mais, de forma
que cada thread tenha que esperar para acessar o CPU, por isso
a informação sobre o tempo pode ficar menos precisa. Portanto,
para realizar testes de performance/estresse em larga escala,
pode ser necessário executar paralelamente várias instâncias do
JMeter sem interface gráfica em diferentes máquinas.

Além dos testes da aplicação web, é possível monitorar a utilização

dos recursos e performance do servidor. Diferentemente do teste
da aplicação que pode ser realizado em sistemas desenvolvidos
em qualquer linguagem de programação, o monitoramento do
servidor só pode ser realizado em Servlets Container com suporte
para o JMX (Java Management Extension, ou em português,
Extensão de Gerenciamento Java).

A Figura 78 apresenta um gráfico de performance monitorado em

um servidor.

Figura 78 – Monitoramento do Servidor com JMeter

Fonte: Apache, 2011.

www.esab.edu.br 143
 Saiba Mais
Aperfeiçoe um pouco mais este estudo e acesse o link
abaixo:
https://medium.com/jmeter/jmeter-teste-de-carga-
2f1ed3932e4f

www.esab.edu.br 144
Integração Contínua

A Integração Contínua é um termo originado do processo de

desenvolvimento ágil do XP (eXtreme Programming). Entretanto,
qualquer metodologia pode se beneficiar da Integração Contínua.

A Integração Contínua consiste em uma prática dos

desenvolvedores integrarem o código alterado/desenvolvido ao
projeto principal em uma frequência alta, muitas vezes diariamente,
com intuito de descobrir o mais cedo possível se as alterações
não introduziram novos defeitos ao projeto. Essa prática pode ser
realizada manualmente, mas é preferível contar com ferramentas
que reduzem bastante o esforço.

Controle de Versão de Código

Um ponto chave para realização da integração contínua é contar

com uma boa ferramenta de controle de versão do código fonte.
Existem excelentes ferramentas gratuitas para esse fim, e uma
das mais populares é o Subversion (SUBVERSION, 2018) que é
considerado por muitos o substituto do CVS.

Os benefícios de utilizar um sistema para controle de versão são

inúmeros, como: permitir restaurar versões antigas, comparar um
código novo com um antigo que funcionava; gerenciar as alterações
do código em um único repositório, dentre outros. Independente

www.esab.edu.br 145
de utilizar integração contínua é muito importante que todo projeto
de software utilize um sistema de controle de versão.

De forma geral, é mantida no sistema de controle de versão uma

linha de desenvolvimento principal do projeto, contendo
documentação, código fonte, scripts de teste, arquivos de
propriedades, bibliotecas e todos os demais recursos necessários
para rodar o projeto. É possível criar linhas alternativas de
desenvolvimento (normalmente chamadas de branches) de forma
que essas não atrapalhem o desenvolvimento atual do projeto.
Um exemplo de utilidade é restaurar uma versão antiga para
corrigir um determinado bug, sem que essa alteração atrapalhe o
desenvolvimento da versão atual, sendo realizada pelos outros
desenvolvedores.

Antes de iniciar o desenvolvimento, o desenvolvedor baixa o

código do repositório central para sua máquina e começa a
trabalhar localmente. Ao concluir o desenvolvimento, ele deve
integrar o seu código com o da linha principal do repositório. Mas
antes, ele deve dar build (compilar, preparar um executável, rodar
testes automatizados, etc.) em sua máquina para ver se suas
alterações funcionam e passam nos testes. Caso esteja tudo
correto, o desenvolvedor deve se preparar para integrar ao
repositório central. Isso inclui integrar em sua máquina o código
atual que está no repositório para verificar se tem algum conflito
causando erro de compilação ou nos testes. Esse passo é
importante visto que, em paralelo, outros desenvolvedores podem
ter submetido suas alterações para o repositório central.

Após realizar os ajustes necessários para a integração funcionar,

o desenvolvedor sincroniza o seu código no repositório central. Na
Integração Contínua, esse processo deve ser feito frequentemente,
sendo sincronizado, sempre que possível, com o repositório

www.esab.edu.br 146
central. O desenvolvedor só deve considerar o seu trabalho
sincronizado quando realizar um build na máquina de integração
com a linha principal do código, e todos os testes sejam executados
com sucesso.

Assim, os problemas são encontrados mais rapidamente, visto

que a alteração é relativamente pequena, sendo mais fácil de
identificar a fonte do problema realizando debug ou comparação
das diferenças. Sem contar que as alterações estão mais recentes
na memória, facilitando também retomar a linha de raciocínio para
realizar as devidas correções. Um ambiente de Integração
Contínua não deve permanecer com uma versão falha por muito
tempo.

O processo de realizar o build em uma máquina de integração e

verificar o resultado dos testes automatizados pode ser realizado
manualmente, mas sem dúvida uma ferramenta é mais eficiente e
eficaz. Apenas compilar o código não é suficiente. É importante
que os testes automatizados sejam executados para identificar
um número maior de defeitos. Um build deve falhar caso algum
teste executado automaticamente falhe.

Muitas equipes agendam o build para ser executado em um

determinado horário, como por exemplo, de madrugada. Segundo
Martin Fowler (2007), essa abordagem não é suficiente para ser
considerada Integração Contínua, visto que o objetivo é encontrar
os problemas o quanto antes e, dessa forma, os problemas são
descobertos após 24 horas.

Para ser frequente, a realização de um build deve ser executada

rapidamente. Martin Fowler argumenta que 10 minutos é um
tempo suficiente, e apresenta uma estratégia para atingir esse
objetivo, já que alguns builds podem demorar mais por ter que

www.esab.edu.br 147
testar dados acessando o banco de dados, etc. Ele sugere a
utilização de builds em estágios. O primeiro estágio é o build
executado automaticamente quando o desenvolvedor submete o
seu código para a linha principal do projeto no repositório. Esse
build tem que prover feedback rapidamente, portanto ele possui
adaptações para atingir esse objetivo, como por exemplo, realizar
mais os testes unitários e deixar os testes mais demorados para o
outro build. Portanto, esse build vai detectar uma quantidade
menor de bugs, mas o ponto é equilibrar de forma que o build seja
rápido e confiável o suficiente. O segundo estágio pode ser
realizado em máquinas adicionais, e esse sim realizará todos os
testes, demorando mais tempo para executar, podendo levar
algumas horas. Martin Fowler (2007) argumenta que no segundo
estágio os problemas podem ser resolvidos nos dias seguintes.
Para realizar os dois estágios várias vezes ao dia, transferindo
executáveis entre máquinas (físicas ou virtuais) é importante que
essa tarefa seja feita automaticamente.

Sempre que possível, é importante que a máquina que executa os

builds se localize, o mais próximo possível do ambiente de
produção. Incluindo recursos de hardware, sistemas operacionais,
dentre outros. Para implantar a Integração Contínua, é importante
conhecer as recomendações de Martin Fowler (2007). O primeiro
passo é construir um build automático. Mesmo não considerando
um build por dia, Fowler indica que essa pode ser uma boa forma
de começar. Adicionar testes automatizados ao build, se o projeto
ainda não os tiver, começar construindo os testes para as áreas
que costumam ser problemáticas.

O ponto principal de realizar a Integração Contínua é reduzir os

riscos, sabendo a todo o momento o que está funcionando. Vale
lembrar que os testes não são perfeitos, e apontam a presença do
defeito, e não a sua ausência. Apenas executar a Integração

www.esab.edu.br 148
Contínua, com testes mal elaborados, não vai garantir a qualidade
adequada. Entretanto, a realização dos testes com uma frequência
alta tende a apontar os defeitos de forma que sejam mais fáceis
de descobrir. A maior qualidade está relacionada à qualidade dos
testes criados.

Integração Contínua - Ferramenta Jenkins I

Como explicado, a Integração Contínua pode ser realizada

manualmente ou através de ferramentas. A realização manual
consiste no desenvolvedor realizar o build em sua máquina e em
seguida, se tudo estiver certo, no repositório central, executar os
testes e acompanhar os resultados. A realização através de
ferramenta automatiza todos esses passos: quando o
desenvolvedor sincroniza o seu projeto com o repositório, a
ferramenta gera o build, realiza os devidos testes e checagens, e
informa através de e-mail ou outra forma de comunicação
configurada, se o resultado foi positivo ou negativo. Lembrando
que o trabalho do desenvolvedor só é considerado terminado
quando a integração apresenta resultado positivo.

O próprio build pode e deve ser automatizado através de scripts,

utilizando ferramentas como Ant (Java), Maven (Java), Nant (.Net),
MSBuild(.Net), etc. Diferentes builds podem ser necessários (ex:
builds em estágios), portanto os scripts devem contemplar cada
caso.

Figura 79 – Jenkins
Fonte: Print screen do http://jenkins-ci.org/

www.esab.edu.br 149
O Jekins (2018) é uma ferramenta gratuita para a realização
de Integração Contínua. É fácil de usar e de instalar. O arquivo
jenkins.war pode ser disponibiliizado de duas formas: em um
container Java EE (ex: Tomcat), ou através da execução
direta java -jar jenkins.war, não sendo necessário a instalação
de um servidor web visto que o Jenkins inicializa um servidor
web embutido (servidor bem pequeno, contém 320 kb),
bastando acessar <http://localhost:8080/>. A primeira forma é
recomendada para o uso real, sendo a segunda para
demonstração e testes da ferramenta. Caso prefira, ao invés
do jenkins.war, é possível baixar um instalador nativo para
diferentes sistemas operacionais. Para configurar o sistema,
clique em Gerenciar Jenkins, em seguida em Configurar
Sistema.

Figura 80 – Configurar Jenkins

Fonte: Print screen do http://jenkins-ci.org/

Ao clicar, é exibida uma tela com diversas configurações. Por

exemplo, é possível configurar em qual JDK(Java Development
Kit) o projeto deve rodar. Essa configuração é opcional, sendo
apenas necessária quando o projeto precisa de uma versão
específica do JDK para poder ser compilado e/ou realizar testes.
É possível configurar também o Ant ou Maven para realização dos

www.esab.edu.br 150
scripts automáticos, o Subversion ou CVS (ferramenta para
controle de versão), os dados do e-mail, caso deseje receber
notificações por e-mail, dentre outros.

A Figura 81 apresenta algumas dessas configurações.

Figura 80 – Tela de Configuração do Jenkins

Fonte: Print screen do http://jenkins-ci.org/

O interessante é que o Jenkins possui integração com diversas

ferramentas. Atualmente são mais de 400 plugins disponíveis para
integração, sendo bem fácil de instalar, bastando clicar no plugin
desejado e em instalar.

Figura 81 – Instalando Plugins

Fonte: Print screen do http://jenkins-ci.org/

www.esab.edu.br 151
Alguns dos plugins disponíveis são para as ferramentas: JUnit,
Emma, Selenium, Findbugs, Testlink, Checkstyle, etc., ou seja, é
possível integrar com algumas ferramentas gratuitas que foram
apresentadas neste módulo.

Assim, quando um desenvolvedor sincroniza o seu código através

do CVS ou Subversion, o Jenkins pode dar o build, gerar e instalar
os pacotes, rodar os testes do JUnit, Selenium,etc em diferentes
ambientes, verificar o padrão do código, verificar a cobertura dos
testes, enviar os resultados por e-mail ou RSS, dentre outras
atividades pertinentes. E o melhor, tudo isso de forma automática.

O build pode ser configurado para ser realizado sempre em um

horário específico, ou então a cada nova versão sincronizada com
o CVS/Subversion.

Reflexão
Os plugins do Jenkins utilizam o próprio
Jenkins na Web para Integração Contínua. É
possível navegar por esses projetos, e assim
conhecer melhor o Jenkins em: <http://
ci.jenkins-ci.org/view/All/>

www.esab.edu.br 152
Integração Contínua - Ferramenta Jenkins II

Utilizando os plugins, é possível utilizar o Jenkins para controlar

projetos em Phyton, PHP, Net, Android, dentre outros, sem
mencionar Java que é o padrão da ferramenta.

O Jenkins permite criar builds e testes para serem realizados em

diferentes computadores. Essa facilidade permite acelerar o tempo
para execução do build e testes, uma vez que permite realizar
atividades em paralelo. É possível monitorar, através do Jenkins,
informações a respeito dos computadores, como a diferença do
relógio, espaço livre em disco, o sistema operacional utilizado,
dentre outros.

Figura 82 – Acompanhando os Computadores

Fonte: Kawaguchi, 2009

www.esab.edu.br 153
O painel de controle apresenta o resumo com informações visuais
para facilitar a rápida interpretação, em conjunto com dados sobre
o período e tempo da última execução.

Figura 83 – Painel de Controle dos Projetos

Fonte: Print screen do http://jenkins-ci.org/

Na figura 83, o status azul indica que a última execução foi bem-
sucedida, enquanto o amarelo indica instabilidade e o vermelho
falha. O ícone com sol indica a estabilidade do projeto de acordo
com as últimas execuções. Quanto mais ensolarado, mas estável
o projeto. Assim, quando uma das últimas cinco tiver falhado, o
ícone parcialmente nublado é apresentado, quando três das
últimas cinco, o ícone totalmente nublado é apresentado, e assim
sucessivamente.

Outro exemplo de informação visual é o gráfico (Figura 84)

demonstrando o tempo necessário para realizar cada build, bem
como o respectivo status.

www.esab.edu.br 154
Figura 84 – Gráfico com a Tendência dos Builds
Fonte: Print screen do http://jenkins-ci.org/

Ao integrar com ferramentas de cobertura de código como o

Emma, é possível visualizar a porcentagem de cobertura de cada
build por blocos, classes, linhas e métodos.

Figura 85 – Gráfico com a Tendência da Cobertura de Código

Fonte: Austvi, 2009

www.esab.edu.br 155
Outra informação disponibilizada é a tendência de utilização de
espaço em disco. O gráfico da Figura 86 apresenta a quantidade
de megabytes utilizada por cada build e pelo código fonte do
projeto. No gráfico ao lado, no último build, o consumo foi de 13
MB pelo código e de 806 KB pelo build.

Figura 86 – Gráfico com a quantidade de megabytes

Fonte: Print screen do http://jenkins-ci.org/

É possível visualizar a saída no console contendo o log do erro.

Figura 87 – Log do Console

Fonte: Print screen do http://jenkins-ci.org/

www.esab.edu.br 156
A Figura 88 apresenta a quantidade e informações dos testes
executados por módulo.

Figura 88 – Resultado dos testes

Fonte: Print screen do http://jenkins-ci.org/

A apresentação do Jenkins será finalizada visualizando o gráfico

de tendência (Figura 89) com o resultado dos testes sucesso/falha
por build.

Figura 89 – Gráfico de Tendência do Resultado dos testes

Fonte: Print screen do http://jenkins-ci.org/
Considerações Finais

www.esab.edu.br 157
 Atividade
Após o estudo referente ao Eixo Temático 3, você
será capaz de entrar na sua sala de aula virtual e
acessar a Lista 3 de atividades objetivas. Boas
atividades!

www.esab.edu.br 158
Neste eixo temático buscou-se proporcionar conhecimentos nos
conceitos inerentes à modelagem e implementação de testes e
para isto buscou-se uma abordagem sobre as cinco unidades
apresentadas: 11. Desenvolvimento Orientado a Testes (TDD -
Test Driven Devlopment) - Exemplo de TDD na Prática. 12.
Ferramenta para Gravar/Executar Testes em Browsers I -
Ferramenta para Gravar/Executar Testes em Browsers II -
Ferramenta para Gravar/Executar Testes em Browsers III. 13.
SELENIUN - Teste de Performance e Estresse - Ferramenta
JMeter. 14. Integração Contínua - Controle de Versão de Código
- Integração Contínua - Ferramenta Jenkins I. 15. Integração
Contínua - Ferramenta Jenkins II.

Parabéns por completar o estudo do Módulo de Teste de

Software!

Vale relembrar alguns conceitos estudados neste Módulo. Foram

analisados os níveis de testes existentes. Apresentados, também,
os custos referentes ao teste de software, o custo de testar, da
falha e o da correção. O custo provocado por uma falha pode ser
intangível, podendo custar milhões de reais, processos judiciais, e
até mesmo vidas humanas. Estudou-se ainda, como a realização
dos testes pode proporcionar um retorno do investimento.

Para poder aumentar a qualidade do software é importante que o

teste seja abordado com um processo próprio, e não mais como
uma atividade dentro do processo de desenvolvimento. Mesmo
tendo um processo próprio, o de teste está fortemente relacionado
ao de desenvolvimento.
www.esab.edu.br 159
Ter um processo próprio implica em planejar corretamente o
projeto de testes. Um dos grandes desafios é definir o quanto de
teste é adequado e o momento correto de interromper os testes
para liberar o software para produção, de forma a não acontecer:
testes de menos (interrupção muito antes de atingir a cobertura
adequada) ou testes em excesso (custo adicional com os testes
não compensa o custo que seria provocado pela falha). Essa
decisão está relacionada à análise de risco do software e à
avaliação de métricas, como por exemplo, quantos testes de alto
e médio risco faltam ser executados, quantos falharam, quantos
faltam ser corrigidos, dentre outros.

O ambiente de teste engloba a utilização de ferramentas

adequadas, a obtenção/produção da massa de dados necessária
para cada tipo de teste e a utilização de configurações que
reproduzam o ambiente de produção.

Quando as condições (exemplo: financeiras) não permitirem

alocar uma equipe independente para realizar os testes, a solução
é utilizar a própria equipe de desenvolvimento para esse fim.
Lembrando que o desenvolvedor não deve ser o responsável por
testar o próprio código (com exceção dos testes unitários e alguns
testes de integração).

A fim de evitar desgastes e prejuízos, o planejamento do projeto

deve contemplar os testes de aceitação em todas as etapas e não
somente ao final do projeto, submetendo, sempre que possível, às
telas (mesmo que protótipos) e funcionalidades para aprovação
do cliente.

www.esab.edu.br 160
É importante realizar as revisões e inspeções em documentos e
diagramas da análise de sistemas. Essas revisões devem ser
feitas o mais cedo possível e não somente ao final de cada etapa.

No fechamento do contrato é fundamental negociar prazos e

custos adequados que contemplem a realização dos testes, visto
que com as pressões por prazos os testes tendem a ser a primeira
parte a ser reduzida.

Desenvolver testes automatizados pode ser muito útil para garantir

a qualidade do software e facilitar a realização dos testes de
regressão, mas é preciso conhecer os desafios envolvidos, para
desenvolvê-los e mantê-los atualizados, avaliando o custo x
benefício de cada automatização.

Ferramentas

Foram apresentadas 8 ferramentas gratuitas para: cobertura de

código, teste unitário, objetos “substitutos” (mock objects), gestão
de defeitos, gestão do processo de teste, teste de estresse e de
performance, testes de aplicações web e integração contínua.

Assim, foi possível perceber os benefícios oferecidos por cada

tipo de ferramenta, e como elas podem ajudar em diferentes
etapas e atividades dos testes, assim como, perceber, também, a
maturidade de ferramentas gratuitas, eliminando o custo de
aquisição, caso opte por utilizar uma delas.

Vale relembrar algumas considerações feitas pelo Syllabus da

certificação ISTQB em relação aos riscos de utilizar ferramentas:
criar expectativas falsas sobre a ferramenta, subestimar o tempo
necessário para iniciar o uso da ferramenta, subestimar o esforço

www.esab.edu.br 161
necessário para manter atualizados os artefatos gerados pelas
ferramentas, tentar utilizar a ferramenta para tudo, mesmo quando
a realização manual for mais adequada.

Algumas ferramentas demonstradas; são específicas para

linguagem da programação Java. Uma vez entendido os benefícios
oferecidos por determinado tipo de ferramenta (independente da
linguagem de programação) basta pesquisar na internet por uma
ferramenta similar para a sua linguagem de programação preferida.
O site <http://www.opensourcetesting.org> é um ponto de partida
(e não o único), visto que apresenta diversas ferramentas para
diferentes linguagens.

Muitas das ferramentas se integram com outras, para otimizar

ainda mais a gestão e execução do processo de teste. Abaixo,
seguem alguns links para demonstrar e servir como “pontapé
inicial” para quem desejar realizar integrações, mas outras
integrações podem ser pesquisadas na Internet:

• TestLink + Mantis: <http://sembugs.blogspot.com/2008/06/

integrao-do-testlink-com-o.html>

• TestLink + Selenium: <http://sembugs.blogspot.com/2010/10/

integracao-selenium-e-testlink.html>

• Selenium + Mantis: <http://sembugs.blogspot.com/2010/10/

integracao-selenium-mantis.html>

• Selenium+Mantis+Testlink: <http://sembugs.blogspot.
com/2010/10/projeto-integracao-selenium-mantis.html>

• TestLink + Eclipse: <http://www.jailtonalkiminlouzada.

com/2010/11/integracao-testlink-e-eclipse/>

www.esab.edu.br 162
C++: é uma linguagem de programação compilada multiparadigma
(seu suporte inclui linguagem imperativa, orientada a objetos e
genérica) e de uso geral. R

C#: é uma linguagem de programação interpretada, multi-

paradigma, fortemente ‘tipada’, e, possuindo paradigmas de
programação imperativa, funcional, declarativa, orientada a
objetos e genérica, R

CPU: Central Processing Unit, que, em português, significa

Unidade Central de Processamento. R

Delphi: anteriormente conhecido como CodeGear Delphi, Inprise

Delphi e Borland Delphi, também conhecido como Delphi, é um
compilador e uma IDE, produzido anteriormente pela Borland
Software Corporation e atualmente pela Embarcadero. R

FindBugs: Traduzido do inglês-O FindBugs é um analisador de

código estático de código aberto criado por Bill Pugh e David
Hovemeyer, que detecta possíveis bugs em programas Java. R

Hardware: é um termo da língua inglesa que se refere a

equipamentos como chaves, fechaduras, trincos e peças de
máquinas. No âmbito eletrônico utiliza-se na área de computação,
e se aplica à unidade central de processamento, à memória e aos
dispositivos de entrada e saída. R

Java: é uma linguagem de programação interpretada orientada a

objetos desenvolvida na década de 90 por uma equipe de
programadores chefiada por James Gosling, na empresa Sun
Microsystems. R

Javascript: é uma linguagem de programação interpretada. R  

www.esab.edu.br 163
Kick-off: (v.) / kickoff (n.). Dar o pontapé inicial – começar. R

Linux: é o núcleo do sistema operacional, programa responsável

pelo funcionamento do computador, que faz a comunicação entre
hardware (impressora, monitor, mouse, teclado) e software
(aplicativos em geral). R

MySQL: é um sistema de gerenciamento de banco de dados, que

utiliza a linguagem SQL como interface. R

Null Pointer: os programas rotineiramente usam ponteiros nulos

para representar condições como o final de uma  lista  de
comprimento desconhecido ou a falha em executar alguma ação.
R

Perl: é uma linguagem de programação multiplataforma usada

em aplicações de CGI para o web, para administração de sistemas
linux e por várias aplicações que necessitam de facilidade de
manipulação de strings. R

PHP: é uma linguagem interpretada livre, usada originalmente

apenas para o desenvolvimento de aplicações presentes e
atuantes no lado do servidor, capazes de gerar conteúdo dinâmico
na World Wide Web. R

PostgreSQL: é um sistema gerenciador de banco de dados objeto

relacional, desenvolvido como projeto de código aberto. R

Python: uma linguagem de programação de alto nível, interpretada,

de script, imperativa, orientada a objetos, funcional, de tipagem
dinâmica e forte. Foi lançada por Guido van Rossum em 1991. R

Ruby: é uma linguagem de programação interpretada

multiparadigma, de tipagem dinâmica e forte, com gerenciamento
de memória automático, originalmente planejada e desenvolvida
no Japão em 1995 R

www.esab.edu.br 164
APACHE. J Meter – TM. Disponível em: <http://jmeter.apache.
org/> Acesso em: 10 nov. 2018.

BERNARDO. Paulo Cheque. A Importância dos Testes

Automatizados Controle ágil, rápido e confiável de qualidade.
Disponível em: <http: //p rogrammingdumps. blogspot.com.
br/2011/11/software-engineering-software-crisis .h tm l>. Acesso
em: 1 out. 2017.

BECK, Kent. Test Driven Development: By Example. Addison-

Wesley Professional, 2003.

BLACK. R. The Cost of Software Quality. 2005. Disponível em:

<https://www. stickyminds.com/>. Acesso em: 20 Ag. 2018.

BOEHM. Barry W. Software Engineering: IEEE Transactions on

Computers. 1976.

CAMPOS, Vagner. Passageiros aguardam para fazer check-in

no aeroporto de Guarulhos. 2010. Disponível em: <http://noticias.
terra.com.br/brasil/gol-diz-a-anac-que-falha-em-software-causou-
erro-em-escalas,6dea4bc92690b310VgnCLD200000bbcceb
0aRCRD.html>. Acesso em: 7 nov. 2018.

CERTIFIED TESTER. Foundation Level Syllabus Versão 2011br,

Comissão Internacional para Qualificação de Teste de Software,
Tradução realizada pela TAG01, Documentação do BSTQB

www.esab.edu.br 165
baseada na versão 2011 do Certified Tester Foundation Level
Syllabus do ISTQB. Disponível em: <http://bstqb.org.br/uploads/
syllabus/syllabus_ctfl_2011br.pdf.> Acesso em: 3 nov. 2018.

CHECKSTYLE. Disponível em: http://checkstyle.sourceforge.net/.

Acesso em: 2 nov. 2018.

COSTA. Pedro. BASE2: Conceitos: testes de caixa branca e caixa

preta. 2013. Disponível em: < http://www.base2.com.br/2013/07/24/
teste-caixa-branca-caixa-preta/- >. Acesso em 23 set. 2018.

DELAMARO. J. C. Maldonado; Introdução ao teste de software.

p. 1 – 7. Elsevier, 2007.

DEVMEDIA. Introdução aos diferentes tipos de teste.

Disponível em: < https://www. devmedia.com.br/introducao-aos-
diferentes-tipos-de-teste/29799>. Acesso em 4 nov. 2018.

FALBO. R. A. Engenharia de Software. Notas de aula. UFES -

Universidade Federal do Espírito Santo. 2008.

______. Projeto de Sistemas de Software, 2017- UFES -

Universidade Federal do Espírito Santo. Disponível em: < https://
inf.ufes.br/~falbo/files/PSS/Notas_Aula_Projeto_Sistemas_ 2017.
pdf>. Acesso em: 28 out. 2018.

FERREIRA, Luiz Antonio. SQL, T-SQL, TRIGGER. Triggers –

SQL Server. 2016. Disponível em: <https://consultabd.wordpress.
com/2016/02/02/triggers-sql-server/>. Acesso em: 13 dez. 2018.

FINDBUGS. Disponível em:< http://findbugs.sourceforge.net>/.

Acesso em 3 out. 2018.

www.esab.edu.br 166
GREGOR, J.D., SYKES, D.A., A Practical Guide to Testing
Object-Oriented Software, Wesley: Addison, 2001.

HUNT, P., Konar, M., JUNQUEIRA, F. P., and Reed, B. ZooKeeper:

Waitfree Coordination for Internet-scale Systems. USENIX
Conference on USENIX Annual Technical Conference,
USENIXATC, 2010.

ISTQB - International Software Testing Qualifications Board. 2011.

Disponível em <http://bstqb.org.br/uploads/syllabus/syllabus_
ctfl_2011br.pdf>. Acesso em 16 nov. 2018.

JEKINS. Disponível em: <http://jenkins-ci.org>/. Acesso em: 13

out. 2018.

JUNIT. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia

Foundation, 2018. Disponível em: <https://pt.wikipedia.org/w/
index.php?title=JUnit&oldid=53552456>. Acesso em: 10 nov.
2018.

LEI DE MURPHY. WIKIPÉDIA. Flórida: Wikimedia Foundation,

2018. Disponível em: <https://pt.wikipedia.org/w/index.
php?title=Lei_de_Murphy&oldid=53736083>. Acesso em: 2 dez.
2018.

LOURENÇO, Marcelo. Dicas Exame CBTS 2010. Disponível em:

<http://qualidade-de-software.blogspot.com/2010/04/dicas-
exame-cbts-2010.html>. Acesso em: 3 nov. 2018.

MACGREGOR, J., SYKES, D. A Practical guide to testing

object-oriented software, Addison-Wesley. 2001.

www.esab.edu.br 167
MAFRA, Sômulo Nogueira Mafra; TRAVASSOS, Guilherme Horta.
Técnicas de Leitura de Software: uma revisão sistemática.
COPPE/UFRJ - Programa de Engenharia de Sistemas e
Computação, Cx. Postal 68.511, CEP 21945-970, Rio de Janeiro
- RJ – Brasil. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/
sbes/2005/005.pdf.> Acesso em: 17 set. 2018.

MANTIS- Bug Tracker . Disponível em: <https://www.mantisbt.

org/>. Acesso em: 2 nov. 2018.

MOCKITO, Disponível em: <https://i2.wp.com/www.codeatest.

com/wp-content/uploads /20 16/11/mockito-logo.
png?resize=800%2C400>. Acesso em 27 out. 2018.

MOZILLA. Disponível em: <https://addons.mozilla.org/pt-BR/

firefox/addon/flow-control/>. Acesso em 4 nov. 2018.

MYERS. Glenford J. The art of sotware testing. 3. ed., Wiley:

2011.

REIS, Daniel Fonsec. Metodologias Ágeis para Desenvolvi-

mento de Software, a Extreme Programming. Disponível em:
<https://www.devmedia.com.br/conceitos-basicos-so bre-metodo-
logias-ageis-para-desenvolvimento-de-software-metodologias-
-classicas-x-extreme-programming/10596>. Acesso em: 3 out.
2018.

RABELO , Eduardo. Cobertura de código explicada. 2017.

Disponível em: <https://medium. com/@oieduardorabelo/
cobertura-de-c%C3%B3digo-explicada-ba1516db7dbd>. Acesso
em: 6 nov. 2018.

www.esab.edu.br 168
RESEARCH. Automatização de teste de software com ênfase
em teste de unidade. Available . Disponível em: <from: https://
www.researchgate.net/publication/313360663 _Capitulo_6_
Automatizacao_de_teste_de_software_com_enfase_em_teste_
de_unidade> Acesso em: 11 dez. 2018.

RIOS, E.; MOREIRA, T. Teste de Software. 3.ª ed. ver. e amp. Rio
de Janeiro: Alta Books. 2007.

SAYÃO, Miriam. Rastreabilidade de Requisitos. Rio de Janeiro:

PUC, 2005.

SELENIUM HQ. Selenium is a suite of tools. Disponível em:

<https://www.seleni umhq.org>/. Acesso em: 28 out. 2018.

SOARES, Diogo Castro Veloso. Testes de unidade com JUnit.

Disponível em: <https://www.devmedia.com.br/testes-de-unidade-
com-junit/4637>, Acesso em 3 out. 2018.

SOUZA, Fernnda Monteiro de. Geração de casos de teste a

partir de especificações B. Natal: PPGSC, 2009.

SUBVERSION. Disponível em: <http://subversion.apache.org/>.

Acesso em: 18 out. 2018.

TASSEY. Gregory. Final report. National Institute of Standards

and Technology. Disponível em: <https://www.nist.gov/sites/
default/files/documents/director/planning/report02-3.pdf.> Acesso
em: 3 out. 2018.

TESTLINK. WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia

Foundation, 2017. Disponível em: <https://pt.wikipedia.org/w/

www.esab.edu.br 169
index.php?title=TestLink&oldid=50572642>. Acesso em: 24 nov.
2018.

UNIFIED MODELING LANGUAGE. Wikipedia, The Free

Encyclopedia. Retrieved 2017. 2017, September 20. Disponível
em: <https://en.wikipedia .org/w/index.php?title =Unified _Mo
deling_Language&oldid=801574126>. Acesso em: 20 set. 2018.

WIKIQUOTE. Desenvolvido pela Wikimedia Foundation.

Apresenta conteúdo enciclopédico. Disponível em: <//
pt.wikiquote.org/w/index.php?title=Edsger_ Dijkstra
&oldid=141866>. Acesso em: 11 dez. 2018

www.esab.edu.br 170