Teste de Software
Teste de Software
Teste de Software
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
Apresentação
www.esab.edu.br 5
Objetivo
Ementa
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
Objetivo
www.esab.edu.br 8
Introdução
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.
www.esab.edu.br 10
Figura 1: Algumas referências que serviram como base para
este Módulo
Fonte: Próprio autor
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
Conceitos de Testes I
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.
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.
www.esab.edu.br 14
Testes Funcionais (Caixa-preta) x Estruturais (Caixa-branca)
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
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.
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
www.esab.edu.br 18
Reflexão
www.esab.edu.br 19
Técnicas de Testes
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.
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.
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.
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
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.
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
www.esab.edu.br 26
Tabela 1: Retorno de Investimento em Testes
www.esab.edu.br 27
Custos das Falhas
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/).
www.esab.edu.br 29
Erros em escalas da GOL
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.)
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.
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.
O Processo de Teste
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.
www.esab.edu.br 33
Figura 5: Abordagem de Testes com um Próprio
Fonte: Próprio autor.
www.esab.edu.br 34
mais bem-sucedidos consideram-se os testes, e menos o processo
de desenvolvimento.
O Modelo V
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.
www.esab.edu.br 36
recomendações de boas práticas de testes (que na verdade
independem do modelo adotado).
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.
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.
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
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
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.
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.
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.
www.esab.edu.br 45
testes, visto que, o prejuízo ocasionado por uma possível falha
pode ser muito alto.
Ambiente de Testes
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.
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
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.
www.esab.edu.br 49
novamente, bastando para isso restaurar a base previamente
criada com essas condições.
Ferramentas
www.esab.edu.br 50
teste, como número de defeitos graves que faltam ser
corrigidos).
www.esab.edu.br 51
Saiba Mais
www.esab.edu.br 52
A Equipe e os Papéis nos Testes
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.
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.
www.esab.edu.br 55
Papéis no Processo de Teste
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.
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
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.):
www.esab.edu.br 59
acompanhamento consiste em verificar se os defeitos foram
devidamente corrigidos e a necessidade de uma nova revisão.
www.esab.edu.br 60
Estudo Complementar
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
Objetivo
www.esab.edu.br 63
Casos de Teste
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.
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.
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).
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.
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).
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.
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.
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.
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.
www.esab.edu.br 72
Gestão de Testes - Ferramenta TestLink
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.
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).
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.
www.esab.edu.br 76
• Falha: Se um defeito no código for executado, causará uma
falha.
Gestão de Defeitos
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).
www.esab.edu.br 78
deverá avaliar para ver se é legítimo. A demora em reconhecer o
defeito pode ser muito prejudicial.
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.
Resolução do Defeito
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.
Estudo Complementar
www.esab.edu.br 80
Gestão de Defeitos - Ferramenta Mantis
Figura 14 – MANTIS
Fonte: MANTIS- Bug Tracker (2018)
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.
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.
www.esab.edu.br 84
Figura 17 – Tela de Registrar Defeito no Mantis - parte 2
Fonte: Print screen do http://www.mantisbt.org (2018)
www.esab.edu.br 85
Figura 18 – Roadmap 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.
Figura 20 – 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
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.
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.
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.
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).
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.
www.esab.edu.br 94
Figura 26 – Código Fonte (2)
Fonte: Print screen do http://emma.sourceforge.net
www.esab.edu.br 95
Figura 28 – Teste Depósito Conta Bancária
Fonte: Print screen do http://emma.sourceforge.net
www.esab.edu.br 96
Figura 28 – 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
www.esab.edu.br 98
integrado, pronto para uso, bastando adicionar a biblioteca ao seu
projeto.
www.esab.edu.br 99
Estudo Complementar
www.esab.edu.br 100
Testes com Objetos Substitutos ou Falsificados (Mock
Objects) - Ferramenta Mockito
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:
www.esab.edu.br 102
Ferramenta Mockito (Continuação)
www.esab.edu.br 103
Figura 36 – Objeto mockado
Fonte: Próprio autor
www.esab.edu.br 104
Ferramenta Mockito
www.esab.edu.br 105
realizarDepositoEmConta utilizará o objeto falsificado na hora
de verificar se a conta está ativa.
www.esab.edu.br 106
Figura 41 – Teste de uma conta inativa
Fonte: Próprio autor
www.esab.edu.br 107
Atividade
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
Objetivo
www.esab.edu.br 110
Desenvolvimento Orientado a Testes (TDD - Test Driven
Devlopment)
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.
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.
www.esab.edu.br 113
Para atingir rapidamente o verde, duas estratégias são utilizadas.
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
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.
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.
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).
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.
www.esab.edu.br 119
Como se sabe que o primeiro 1 = F(n-1), se faz essa alteração.
www.esab.edu.br 120
Tamanho dos passos
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
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
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).
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.
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.
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!
www.esab.edu.br 126
Figura 60 – comando click
Fonte: Print screen do http://seleniumhq.org/download
www.esab.edu.br 127
Figura 61 – Exibição dos comandos disponíveis para determinado
elemento
Fonte: Print screen do http://seleniumhq.org/download
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.
www.esab.edu.br 129
• waitForElementPresent: aguarda até o elemento HTML
estar presente na página.
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.
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.
clickAndWait css=input.button
verifyText css=font *disabled*blocked*incorrect*
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.
www.esab.edu.br 133
Uma vez exportado para a linguagem de programação desejada,
é possível continuar programando normalmente.
Estudo Complementar
https://www.seleniumhq.org/projects/
webdriver/
www.esab.edu.br 134
Teste de Performance e Estresse - Ferramenta JMeter
www.esab.edu.br 135
pelo site para, posteriormente, durante a execução do teste,
reproduzir os mesmos passos.
www.esab.edu.br 136
Figura 68 – Thread Group
Fonte: Print screen do http://jakarta.apache.org/jmeter/
www.esab.edu.br 137
Figura 70 – URL Patterns to exclude
Fonte: Print screen do http://jakarta.apache.org/jmeter/
www.esab.edu.br 138
Figura 72 – Configurar conexão
Fonte: Print screen do http://jakarta.apache.org/jmeter/
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:
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/
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
www.esab.edu.br 154
Figura 84 – Gráfico com a Tendência dos Builds
Fonte: Print screen do http://jenkins-ci.org/
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.
www.esab.edu.br 156
A Figura 88 apresenta a quantidade e informações dos testes
executados por módulo.
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.
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.
Ferramentas
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.
• Selenium+Mantis+Testlink: <http://sembugs.blogspot.
com/2010/10/projeto-integracao-selenium-mantis.html>
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
www.esab.edu.br 163
Kick-off: (v.) / kickoff (n.). Dar o pontapé inicial – começar. R
www.esab.edu.br 164
APACHE. J Meter – TM. Disponível em: <http://jmeter.apache.
org/> Acesso em: 10 nov. 2018.
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.
www.esab.edu.br 166
GREGOR, J.D., SYKES, D.A., A Practical Guide to Testing
Object-Oriented Software, Wesley: Addison, 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.
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.
www.esab.edu.br 169
index.php?title=TestLink&oldid=50572642>. Acesso em: 24 nov.
2018.
www.esab.edu.br 170