TESTES DE

SOFTWARE

autor
MARCOS DANILO CHIODI MARTINS

1ª edição
SESES
rio de janeiro  2016
Conselho editorial  regiane burger, roberto paes e paola gil de almeida

Autor do original  marcos danilo chiodi martins

Projeto editorial  roberto paes

Coordenação de produção  paola gil de almeida, paula r. de a. machado e aline

karina rabello

Projeto gráfico  paulo vitor bastos

Diagramação  bfs media

Revisão linguística  bfs media

Revisão de conteúdo  claudia abreu paes

Imagem de capa  alphaspirit | shutterstock.com

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogação na Publicação (cip)

M386t Martins, Marcos Danilo Chiodi

Testes de software / Marcos Danilo Chiodi Martins.
Rio de Janeiro: SESES, 2016.
144 p: il.

isbn: 978-85-5548-401-8

1. Software - testes. 2. Software - desenvolvimento. I. SESES. II. Estácio.

cdd 005.1

Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063
Sumário

Prefácio 5

1. Importância do teste de software 7

1.1  Introdução a teste de software 8
1.2  Termos & conceitos sobre teste 14
1.3  O teste nas fases de vida e de desenvolvimento de um software 22

2. Teste no programa 31

2.1  Revisões técnicas formais, no que isso pode ser útil? 32

2.2  Observando cenários da vida real 37
2.3  Técnica de testes, o que é isso? 40
2.4  Teste caixa preta, o teste funcional 41
2.5  Teste caixa branca, o teste estrutural 46
2.6 Depuração 54
2.7  Teste de ambiente web 57

3. Teste na implantação do sistema 65

3.1  Estratégia de teste 66

3.2  Teste de Unidade 69
3.3  Teste de Integração 71
3.4  Teste de validação 76
3.5  Teste de sistema 78
3.6  Teste de migração 81
4. Teste de software em sistemas em produção 89

4.1  Teste de software nos diversos tipos de manutenção 90

4.2  Requisitos de qualidade de software 96
4.3  Confiabilidade e disponibilidade 102

5. Ferramentas de teste de software 113

5.1  Introdução às ferramentas de teste de software 114

5.2  Ferramentas de teste no desenvolvimento de sistema 115
5.3  Ferramentas de teste para o programa 121
5.4  Ferramentas de teste para o ambiente web 131
5.5  Ferramentas de teste para o sistema em produção 135
Prefácio
Prezados(as) alunos(as),

Esperamos que as páginas desse livro se tornem uma leitura agradável e extre-
mamente útil para o seu cotidiano.
Seja bem-vindo à nossa disciplina de “Testes de software”, de muita relevância
no Processo de Desenvolvimento de Software. Nesta disciplina trataremos os vários
aspectos sobre teste de software, que é uma atividade planejada e executada com
o objetivo de melhorar a qualidade do software durante o processo de desenvolvi-
mento e manutenção.
Para isso, veremos a importância dos testes, o contexto dos testes nas atividades
de garantia de qualidade de software (Software Quality Assurance – SQA) e vamos
relembrar modelos de processo de desenvolvimento que você possivelmente já co-
nhece, salientando que todos eles requerem atividades de teste. Logo no começo
vai aprender alguns conceitos importantes, que facilitarão leitura e entendimento
de todo conteúdo aplicado à prática dos testes.
Vamos aprender sobre revisões formais, que fazem parte das atividades de ve-
rificação e validação, e veremos que elas podem ajudar muito a atividade de teste.
Sobre testes propriamente, veremos o que são e quais são as técnicas, critérios
e seus requisitos. Com todo esse conhecimento, estaremos aptos a conhecer algu-
mas das principais estratégias de teste, a importância de planejar e contextualizar
adequadamente as atividades de teste quando o software já está em produção – a
fase que chamamos de manutenção e, adicionalmente vamos estudar alguns crité-
rios básicos de qualidade de software que devem ser o objetivo de todos os envol-
vidos no projeto de software, verificando como a atividade de teste pode ajudar a
atingir esses critérios.
Como um conhecimento abrangente de teste, apresentamos algumas ferra-
mentas que podem auxiliar na automação de casos de teste, mesmo porque, ao es-
tudar estratégias de teste, veremos que testes como de stress e de performance são
extremamente difíceis de serem aplicados manualmente.
O objetivo deste livro não é torná-lo um especialista em teste de software, mas
sim, apresentar conceitos importantes para a sua carreira profissional e acadêmica,
dando a você conhecimento para se aprofundar em testes, caso necessário, ou ape-
nas ter argumentos e conhecimento para entender como planejar e aplicar ativida-
des de teste no desenvolvimento de software. Esse conhecimento também é muito

5
útil na aquisição de produtos de software quando você estiver no papel de cliente.
Afinal, você quer qualidade.
Desde já é importante ressaltar que o conhecimento sobre testes não será es-
gotado nesse livro, afinal, é um tópico que assim como muitos, está em constante
evolução. No entanto, tenha certeza de que o conteúdo que está por vir agregará
valor ao seu currículo acadêmico, bem como terá bastante aderência ao seu con-
texto prático profissional de forma que o aprendizado aqui, conquistado por você,
servirá como alicerce para a sua formação não só em teste, mas em engenharia de
software e TI como um todo, podendo aplicar no seu local de trabalho e em projetos
de software como um todo.
Sendo assim, dedique-se à leitura e aos exercícios desse livro.

Estrutura do Livro
No capítulo 1 apresentamos a importância do TESTE DE SOFTWARE e sendo
um capítulo introdutório trataremos da base teórica da disciplina, assim como os
termos relacionados ao assunto. Queremos que você entenda a importância de se
testar o software durante todo desenvolvimento.
No capítulo 2 iremos ver sobre teste no programa – vamos mergulhar em téc-
nicas de teste, critérios de teste e depuração. Veremos também, de forma sucinta,
outra atividade de V&V mencionada no Capítulo 1 – as revisões técnicas formais.
No capítulo 3 vamos estudar sobre as diversas estratégias de teste – teste de uni-
dade, teste de integração, teste de validação, teste de sistema e suas variações e teste
de migração.
Logo em seguida, no capítulo 4, vamos aprender sobre teste em sistemas que
já estão em produção, e nesse momento vamos relembrar um tópico importante
de engenharia de software – manutenção – além de nos atentarmos mais sobre cri-
térios de qualidade de software que devem ser perseguidos, como confiabilidade
e disponibilidade. Estudados esses tópicos, aprender sobre as estratégias de teste
torna o aprendizado e os relacionamentos mais fáceis e naturais.
Por fim, o capítulo 5 apresenta ferramentas de automação de teste, que permi-
tirão você ver diversas possibilidades para agilizar a atividade de teste e criar testes
automatizados.

Bons estudos!
 1
Importância do
teste de software
1.  Importância do teste de software
Neste capítulo teremos a introdução da nossa disciplina “Testes de Software” e
sendo um capítulo introdutório trataremos da base teórica da disciplina, assim
como os termos relacionados ao assunto. Queremos que você entenda a im-
portância de se testar o software durante todo desenvolvimento e saiba o que
é um teste.
Dessa forma, você terá “alicerce” para continuar na disciplina e terá mais
facilidade para entender, planejar e executar testes de software tanto em proje-
tos de softwares pessoais, como aqueles desenvolvidos durante disciplinas de
programação, quanto em projetos desenvolvidos no âmbito profissional, por
que é lógico, não queremos que esta disciplina seja somente um livro a mais na
sua prateleira. Queremos que esta disciplina lhe ajude a desenvolver melhores
projetos de software, com melhor qualidade e que com isso você se torne um
profissional completo, de qualidade e sempre galgando mais e, mais sucesso
na sua carreira profissional.

OBJETIVOS
•  Estudar sobre qualidade de software;
•  Entender a importância das atividades de garantia de qualidade e os envolvidos nes-
sas atividades;
•  Conhecer as atividades de verificação e validação (V&V) e entender a diferença ente elas;
•  Definir teste de software e termos relacionados, como caso de teste, cenário de teste,
defeito, erro, falha e engano;
•  Entender a importância dos testes nos diferentes modelos de processo de desenvolvimen-
to de software.

1.1  Introdução a teste de software

Olá, seja bem-vindo ao primeiro capítulo da nossa disciplina de “testes de

software”. Temos certeza que você irá aprender bastante e encontrará conhe-
cimentos importantes para o seu futuro acadêmico e profissional na área de
desenvolvimento de sistemas.

8• capítulo 1
 Contudo, agora no começo, sabemos que às vezes é difícil para o aluno en-
tender a importância desta disciplina e das tecnologias que estudaremos nela
e sabemos que você pode estar se perguntando: “Por que eu tenho que estudar
esta disciplina neste curso?”.
Então, iremos aqui estabelecer uma interessante discussão para que pos-
samos lhe explicar a importância desta disciplina no seu curso e na sua vida
profissional.
Para iniciar a discussão gostaríamos que você pensasse na seguinte
pergunta:

PERGUNTA
“Você conhece um software de qualidade?”

Independente da sua resposta ser SIM ou NÃO, gostaria que você pensasse
no que levou você a dar esta resposta. “No que você se baseou para julgar a qua-
lidade do software? O que é qualidade de software? Como será que se faz para
atingir qualidade de um software?”.
Perguntas complexas, concorda? Vamos continuar nossa leitura e estudo de
alguns conceitos importantes que pode te ajudar a responder essas questões de
forma mais concisa e técnica, como um profissional de TI.
Sempre que falamos de Qualidade de Software devemos lembrar nas ativi-
dades de garantia de software – SQA (Software Quality Assurance). Essas ativi-
dades foram pensadas para fazer parte de todo processo de desenvolvimento de
software e têm como objetivo garantir que requisitos de qualidade de software
sejam satisfeitos pelo software.
Sendo assim, podemos entender, seguindo Pressman (PRESSMAN, 2006),
que:

“Qualidade de software é a conformidade com requisitos funcionais e de desempe-

nho explicitamente declarados, normas de desenvolvimento explicitamente documen-
tadas e características implícitas que são esperadas em todo software desenvolvido
profissionalmente”.

capítulo 1 •9
 ©© PIXABAY.COM
Na Seção 5.3 (capítulo 5) veremos
em mais detalhes os requisitos de qua-
lidade de software, envolvendo com
todo o conhecimento sobre teste que
iremos construir até lá.
Pensando de maneira mais ampla,
a garantia de qualidade é uma ativida-
de imprescindível para qualquer negó-
cio que produza um produto, seja ele
software ou não.
Uma fábrica de carro, uma fábrica
de alimentos e um marceneiro tem
suas atividades de garantia de quali-
dade. Sem isso, esses produtores não
Figura 1.1  – 
sobreviveriam no mercado.

Pressman (PRESSMAN, 2006) relembra que no Século XX, a responsabilidade

da qualidade do produto era exclusiva de quem o fabricava, num processo quase
que artesanal. Durante os anos 40 houve disseminação de abordagens mais for-
mais para controle de qualidade, concentradas na medição e aperfeiçoamento
contínuo do processo como sendo elementos-chave da gerência de qualidade.
No contexto das atividades de garantia de qualidade de software, vários pa-
péis diferentes do time de desenvolvimento possuem grande importância: enge-
nheiros de software, gerentes de projeto, clientes (quando possível), pessoal de
vendas e outros envolvidos fazem parte de um time de SQA (PRESSMAN, 2006).
Pressman (PRESSMAN, 2006) reforça que o time de SQA deve olhar para o
software procurando ter o ponto de vista do cliente, procurando sempre res-
ponder perguntas como:
•  O software satisfaz critérios de qualidade? A saber, confiabilidade, cor-
reção, disponibilidade, eficiência, escalabilidade, flexibilidade, funcionalida-
de, integridade, interoperabilidade, manutenabilidade, prazo de colocação no
mercado, portabilidade, reutilização, segurança, testabilidade e usabilidade (
(MCCALL, RICHARDS e WALTERS, 1977), (ISO, 2003), (OLSINA, GODOY, et al.,
1999));
•  O desenvolvimento do software foi conduzido de acordo com pa-
drões preestabelecidos?

10 • capítulo 1
 •  As disciplinas técnicas desempenharam seu papel de forma adequada
como parte das atividades de SQA?

De acordo com Pressman (PRESSMAN, 2006), SQA é composta por diversas

tarefas associadas a duas frentes distintas – engenheiros de software, que fa-
zem o trabalho técnico, e o time de SQA (que também pode ser composto por
engenheiros de software), que se responsabiliza pelo planejamento, supervi-
são, registro, análise e relato da garantia da qualidade, tendo como missão, aju-
dar o time de desenvolvimento a entregar um produto final de qualidade para
o cliente.
Podemos resumir, então, baseando no mesmo autor que:
•  Engenheiros de software aplicam métodos e medidas técnicas sólidas,
conduzindo revisões técnicas formais e testes de software;
•  O time de SQA deve planejar as atividades que farão parte do plano de SQA,
supervisionar para garantir que as atividades estão sendo executadas de acordo
com o plano (por exemplo, garantir que os eventos previstos no Scrum (meto-
dologia ágil para gestão e planejamento de projetos de software) estão tendo o
resultado esperado), supervisionar a execução das atividades do plano de SQA,
registrar como elas são conduzidas e caso necessário, relatar inconformidades.

Essa distinção de tarefas ajuda a reforçar na empresa que todos, sem exce-
ção, são responsáveis pela qualidade do produto de software.
Pensa que SQA é um time muito difícil de se manter? Não é não.
Dependendo da fábrica de software, ele pode ser maior ou menor. Pense em
quais desses papéis você observa frequentemente numa empresa de desenvolvimen-
to: Product Owner (que é um papel previsto no Scrum e representa a pessoa indicada
a dar prioridade a execução das atividades pendentes), gerentes de teste, gerente de
desenvolvimento, líderes de equipes de programadores, gerentes de projeto, direto-
res (técnicos ou não), vendedores, analistas de suporte/atendimento ao cliente e as-
sim por diante. Todos eles querem um software de qualidade, pois isso tem impacto
no cotidiano deles. Sendo assim, eles são pessoas ideais para participar do time de
SQA de uma empresa, independentemente do tamanho que esse time irá ter.
Do ponto de vista técnico, temos duas atividades de extrema importância
para garantir a qualidade de um software: verificação e validação – conhecidas
como atividades de V&V.

capítulo 1 • 11
 Seguindo Pressman (PRESSMAN, 2006):

Atividades para responder à pergunta: “Estamos construindo

VERIFICAÇÃO o produto corretamente?”;

Atividades para responder à pergunta: “Estamos construindo

VALIDAÇÃO o produto certo?”.

Além de classificadas como verificação e/ou validação, as atividades V&V

são classificadas como estáticas e dinâmicas.
Atividades estáticas são aquelas que não dependem de um artefato execu-
tável para serem realizadas. Em outras palavras, não é necessário ter um códi-
go fonte para realizar atividades de V&V estáticas. Exemplo dessas atividades
são as revisões técnicas formais e Técnicas de Inspeção, que estudaremos no
Capítulo 2 (FABBRI, 2009) (VERACODE, 2016) (ISTQB, 2016).
Atividades dinâmica são aquelas que dependem de um artefato executável
para serem realizadas. Em outras palavras, é necessário ter um código fonte
executável para realizar atividades de V&V dinâmicas. O exemplo dessa ativi-
dade é o teste de software, que embora deva começar a ser planejado e defini-
do antes mesmo de se ter uma linha de código, é uma atividade que só pode
ser executada com um artefato executável (FABBRI, 2009) (VERACODE, 2016)
(ISTQB, 2016).
No artigo publicado por Firesmith no blog do SEI (Software Engineering
Institute) da Carnegie Mellon University (FIRESMITH, 2013), o autor apresenta
que as atividades de V&V são tipicamente executadas usando uma ou mais das
quatro técnicas listadas a seguir:

Que é o uso de técnicas ou modelos matemáticos, si-

mulações algoritmos ou procedimentos científicos para
ANÁLISE determinar se o produto ou artefato está em conformi-
dade com seus requisitos.

12 • capítulo 1
 É um exame visual do produto de software sendo exe-
cutado em um cenário específico a fim de identificar se
DEMONSTRAÇÃO ele está em conformidade com os requisitos. As famo-
sas “demos” são um exemplo dessas demonstrações.

É uma examinação visual (comumente envolvendo a mani-

pulação manual dos artefatos) de um artefato não executá-
vel, novamente para identificar a conformidade do artefato
com seus requisitos. Por sua característica comumente
INSPEÇÃO estática, Sommerville (SOMMERVILLE, 2011) salienta que
técnicas de análise, como as revisões formais e inspeção,
oferece garantia somente entre a correspondência de um
artefato com a sua especificação, não sendo adequada
para identificar a utilidade do software para o cliente.

É a simulação de um artefato executável com entradas

e pré-condições conhecidas e a comparação entre a
TESTE saída atual e a saída esperada para determinar se o
artefato está em conformidade com os requisitos.

Se recuperarmos as perguntas que foram feitas a você no início desse capí-

tulo, podemos concordar que atividades de V&V, e consequentemente teste de
software, são conhecimentos importantes quando se quer produzir software de
qualidade.
Então, você, caro aluno, pode se perguntar: “Por quê vamos estudar especi-
ficamente Teste de software e não as outras atividades de V&V?”.
Considerando as definições apresentadas por (FIRESMITH, 2013), qual a
atividade você pensa ser a mais plausível de ser aplicada? Fazendo uma busca
rápida no Google, qual a atividade você identifica como sendo a mais aplicada
na indústria?
Tenho quase certeza que sua resposta foi Teste para as duas perguntas.
Alguns motivos são a facilidade de executar a atividade e a certeza de que
mesmo em ambientes com processo de desenvolvimento inadequado, no
qual não há documentação alguma, há um executável e, mesmo que de forma
não adequada, a atividade de teste pode ser aplicada. Além disso, Pressman
(PRESSMAN, 2006) reforça que a atividade de teste é o último reduto no qual

capítulo 1 • 13
a qualidade do software pode ser avaliada e defeitos podem ser identificados
antes de serem entregues ao usuário final.
O mesmo autor salienta algo importante de você ter em mente desde já, no
início do livro: “Você não pode testar a qualidade. Se ela não estiver lá quando
começar a testar, certamente não estará lá quando terminar de testar.”.
Na literatura há divergências sobre o fato de teste ser uma atividade de ve-
rificação e validação, ser apenas atividade de validação e ainda, se teste é uma
atividade que está em paralelo às atividades de V&V, e então a sigla correta seria
V, V & T. No nosso contexto, essa definição não tem grande relevância – vamos
considerar apenas que teste é uma atividade dinâmica para verificar a confor-
midade do software com seus requisitos e validar se o software atende as neces-
sidades do cliente.
Com essa contextualização, você está pronto para aprender mais sobre
testes e seus conceitos. Vamos continuar que temos muitas páginas sobre
esse tema.

1.2  Termos & conceitos sobre teste

Na seção anterior vimos que teste é a simulação de um artefato executável com

entradas e pré-condições conhecidas e a comparação entre a saída atual e a saí-
da esperada para determinar se o artefato está em conformidade com os requi-
sitos (FIRESMITH, 2013).
Na norma ISO/IEC/IEEE 24765:2010 (ISO/IEC/IEEE 24765, 2010), temos
que “Teste é o processo de executar um sistema ou componente sob condições
específicas, observando e registrando os resultados, avaliando alguns aspectos
do sistema ou componente”. Roper (ROPER, 1994) define de forma sucinta que
“Teste é apenas uma amostragem”. Myers (MYERS, 2004) define que “Teste
é o processo de executar um programa ou sistema com a intenção de encon-
trar erros”.
Na literatura científica sobre engenharia de software ou especificamente
sobre testes, podemos encontrar diversas outras definições. No entanto, é im-
portante termos em mente exatamente o que Myers propaga – o objetivo dos
testes é encontrar defeitos, e nunca afirmar que um sistema não tem defeitos.
Complexo? Pense comigo: Quando você desenvolve um programa como
parte de uma disciplina, pode até mesmo ser um algoritmo, você, de certa for-
ma, testa esse programa, correto? Você informa algumas entradas e verifica se
a saída é a esperada ou não.

14 • capítulo 1
 ©© PIXABAY.COM
Se eu, sendo seu professor, per-
guntar “Está funcionando? Tem al-
gum erro?”.
Algumas respostas para essas per-
guntas comumente são “Não profes-
sor, eu testei!”, “Espero que não pro-
fessor!”... e outras similares a essa.

Figura 1.2  – 

No entanto, você concorda que uma resposta como “Professor, eu testei

com entrada A e B e pelo menos com essas entradas o programa está funcio-
nando!”. Razoável, não é mesmo? Afinal, você, aluno, pode garantir que com
os dados que você usou para testar, se havia algum defeito, ele foi encontrado e
corrigido por você – afinal, ninguém quer entregar programas com defeito para
o professor. No entanto, se o professor usar outros dados, realizar outros testes,
você não pode afirmar que não haverá problemas...
Isso também vale para o contexto de teste de software – a mentalidade é:
se existia algum defeito nas funcionalidades que eu executei durante os testes
(ou no código-fonte executado), defeitos esses alcançados pela forma como eu
usei o sistema (dados, sequência de execução etc.), esse defeito foi encontrado,
reportado e corrigido.
Talvez você pense imediatamente: ”Uma solução para não ter problema no
software é testar todas as possibilidades.” Afinal, dessa forma, nós podemos ga-
rantir que todas as funcionalidades foram executadas de todas as formas possí-
veis e como consequência, todos os defeitos foram encontrados.
Isso é o que chamamos de teste exaustivo. Pezzè e Young (PREZZÈ e YOUNG,
2007) ressaltam que o teste exaustivo pode ser considerado uma autêntica “pro-
va por casos”. No entanto, os mesmos autores levantam um ponto importante:
Quanto tempo levaria para ser executado um teste exaustivo?
Observe a seguir um exemplo de código adaptado de (BINDER, 1999).
O método exige apenas uma entrada inteira, decrementa essa entrada
em 1, divide esse resultado por 3000 e retorna o resultado dessas operações.
Simples assim!

capítulo 1 • 15
 1 int exemplo_simples(int j) {
2 j = j - 1;
3 j = j / 30000;
4 return j;
5 }

Exemplo de um código fonte. Adaptado de (BINDER, 1999).

No entanto, se estivermos considerando testes exaustivos, devemos lem-

brar que um número inteiro de 16 bits (2 bytes), tem como menor valor possível
-32,768 e como maior valor possível, 32,767, resultando em 65.536 valores dife-
rentes. Seria possível testar todos os possíveis valores?
Não! Quer dizer... não em um tempo plausível para testar um único méto-
do. Além da impossibilidade de testar por exaustão, ainda temos o impacto da
escolha dos dados corretos, pois um conjunto de dados pode fazer com que o
defeito seja identificado, e outro conjunto de dados pode fazer com que o defei-
to nunca seja identificado.
Vamos supor que o requisito do exemplo da tabela 1.1 é “O sistema deve
receber um valor inteiro, subtrair um desse valor e após essa operação, dividir
o resultado por 30000.”.
Se o método receber o valor 30000, o resultado seria 0,99, que não é um valor
inteiro e sendo assim, o programa iria falhar, pois como podemos observar na
linha 1 do exemplo dado na tabela 1.1, o retorno do método é de números intei-
ros, assim como a variável j que recebe o valor e armazena os processamentos
internos. O mesmo acontece com -30000, 29999 e – 29999.
Sendo assim, para identificar que há um defeito no programa, o testador de-
veria obrigatoriamente escolher um desses quatro valores para o teste, dentre
as 65.536 opções que ele tem. Tarefa difícil, não é?
Considerando a impossibilidade de testar por exaustão, nós devemos apli-
car os critérios de teste, que nos ajudam, entre outras coisas, a definir me-
lhor nossos casos de testes e os dados de entrada a fim de identificar defeito.
Veremos isso com calma no capítulo 2.

PERGUNTA
Mas, afinal, o que é caso de teste?

16 • capítulo 1
 De acordo com a norma IEEE 829-2008 (IEEE 829-2008, 2008), caso de tes-
te é um conjunto de dados de entradas, condições de execução do sistema e
o resultado desenvolvido/projetado para atingir um objetivo especifico, como
exercitar um caminho específico em um programa ou verificar a concordância
do programa com o requisito.
Em outras palavras, casos de teste é uma sequência de passos que devem ser
executados no sistema, sendo que os dados de entrada e saída esperada para
cada passo são especificados. A prática nos diz que os casos de teste devem
“direcionar” as ações do testador em uma determinada funcionalidade e fazer
com que ele observe se o resultado que ele obtém em cada passo é o resultado
esperado, de acordo com os requisitos.
A mesma norma (IEEE 829-2008, 2008) menciona que um caso de teste
deve conter:

1. IDENTIFICADOR Número único de identificação do caso de teste em

DO CASO DE questão.
TESTE

2. OBJETIVO DO Mostra de forma breve qual é a intenção de teste do caso

CASO DE TESTE de teste.

Todas as entradas que serão consideradas no caso de

3. ENTRADAS teste.

As saídas esperadas de acordo com as entradas indicadas

4. SAÍDAS na execução dos testes.

5. AMBIENTES Quais ambientes de hardware e software, inclusive com

NECESSÁRIOS OU versionamentos, que devem ser montados para o caso de
CONDIÇÕES DE teste em questão.
AMBIENTE

capítulo 1 • 17
 6.
PROCEDIMENTOS Como o analista de teste deve proceder para a execução
ESPECIAIS do caso de teste em questão. Deve especificar com deta-
REQUISITADOS lhes o que deve ser testado e a forma que o teste deve ser
PARA EXECUÇÃO executado.
DO CASO DE
TESTE

7 DEPENDÊNCIA No caso deste caso de teste estar relacionado com outro

COM OUTROS caso de teste, então, especificar este relacionamento aqui.
CASOS DE TESTE

Pensando no exemplo, um caso de teste possível seria:

1. Caso de teste 1: entrada negativa
2. Verificar se entradas negativas são possíveis
3. (E) Digite “- 30000”
4. (S) 0,99
5. Nenhum
6. Nenhum
7. Não

Com esse caso de teste, o testador iria verificar que há um defeito, pois cer-
tamente o programa iria falhar em não retornar o resultado esperado. O que
fazer nesse momento?
Ao identificar um defeito, o testador deve reportar o defeito de forma a per-
mitir que o time de desenvolvimento identifique facilmente como eliminar o
defeito do sistema.
A forma de reportar defeitos depende muito de padrões definidos em cada
empresa, ou time de desenvolvimento, e das ferramentas utilizadas para geren-
ciar o projeto e a atividade de teste, como por exemplo, Jira e Zephyr da Atlassian
(ATLASSIAN, 2016), Bugzilla (BUGZILLA, 2016) ou testLink (TESTLINK, 2016).
Uma sugestão de como reportar um defeito é (ISTQB, 2016):
•  Identificador do defeito: todo defeito deve ter um identificar único para
facilitar a comunicação e localização;

18 • capítulo 1
 •  Descrição do defeito: uma descrição sucinta do defeito encontrado
•  Versão do produto: para saber em qual versão do sistema o defeito
foi encontrado;
•  Passos detalhados: descrição de passos realizados no sistema, incluindo
os dados utilizados para encontrar o defeito. Screenshots e vídeos podem ser
muito úteis também. A ideia é permitir que os desenvolvedores consigam re-
produzir o defeito em ambiente de depuração;
•  Data de reporte do defeito: para facilitar o gerenciamento;
•  Reportado por: para saber qual o testador identificou o defeito;
•  Status: aqui, diferentes nomes podem ser aplicados, mas o objetivo é per-
mitir que todos os envolvidos saibam se o defeito já foi endereçado, analisado,
corrigido, se tem algum desenvolvedor encarregado de arrumar o programa, se
o testador já viu a resolução e assim por diante. Um exemplo de lista de possí-
veis status é: novo/aberto, designado, em verificação, resolvido, fechado, falha-
do, não será corrigido etc.
•  Corrigido por: Nome do desenvolvedor que corrigiu o defeito;
•  Data de encerramento: a data que o defeito foi dado como inexistente;
•  Severidade: para informar quão grave é o defeito no sistema, como por
exemplo, bloqueia a versão, crítico, pequeno;
•  Prioridade: para definir a prioridade em corrigir o defeito: alta, média
ou baixa
©© PIXABAY.COM

Figura 1.3  – 

capítulo 1 • 19
 Para exemplificar com um exemplo mais próximo do seu cotidiano, vamos
pensar em um cenário comum a muitos sistemas – autenticação (ou login). Se
você precisar criar um caso de teste para verificar defeitos na funcionalidade de
login, um possível caso de teste seria:
1. Caso de teste 1 -Login
2. Verificar login inválido
3. Entradas (E)
4. Saídas (S)
a) (E) No celular, clique no ícone do aplicativo.
b) (S) O aplicativo deve abrir e exibir a tela de login.
c) (E) Insira um e-mail inválido, sem o sinal de @ (professor.gmail.
com) e clique em “next”.
d) (S) O aplicativo deve deixar a borda do campo login vermelho e a
mensagem “Por favor, digite um login válido” deve ser exibida.
e) (E) Clicar em OK na mensagem.
f) (S) O cursor de digitação deve estar no campo de login e o usuário
deve poder corrigir o login anterior.
5. Smartphone com o aplicativo instalado
6. Nenhum
7. Não (afinal, não preciso ter feito nenhuma ação antes para testar
o login)

Outro conceito importante no contexto de teste é o conceito de cenário de

teste. De acordo com a norma IEEE 829-2008 (IEEE 829-2008, 2008), cenário de
teste é um conjunto de casos de teste relacionados, que comumente testam o
mesmo componente ou a mesma funcionalidade do sistema.
Ao definir esse agrupamento de casos de teste, temos que pensar que eles
serão extremamente úteis para testes de regressão (que são testes feitos na fase
de manutenção do sistema para garantir que as novas funcionalidades não
inseriram defeitos nas antigas), para revalidar mudanças nos casos de teste e
também para treinar novos testadores e pessoas que darão suporte ao sistema.
Cenários de caso de teste também chamados de suítes ou ciclos de teste.
Aqui, fica evidente outra utilização da atividade de teste – disseminar co-
nhecimento sobre o sistema, afinal, os casos de testes acabam sendo um guia
de como certas funcionalidades funcionam e a prática nos diz que eles ajudam
muito um leigo a aprender sobre o sistema.

20 • capítulo 1
 Antes de encerrarmos os termos e conceitos, é muito importante chamar a
atenção para alguns termos que você leu até agora nesse capítulo – afinal, é de-
feito, erro ou bug? Tenho usado a palavra defeito até agora e já que nessa seção
um dos objetivos é abordar conceitos sobre teste, é importantíssimo você saber
sobre a diferença desses termos.
Diversas definições sobre defeito, erros e falhas podem ser encontradas na
literatura e nos materiais sobre teste de software. Neste livro, vamos considerar
a definição da norma ISO/IEC/IEEE 24765:2010 (ISO/IEC/IEEE 24765, 2010),
que estabelece:

ENGANO Uma ação humana que produz um resultado incorreto,

(MISTAKE) como uma codificação ou modelagem errada;

Uma imperfeição ou deficiência em um artefato que faz

com que este não esteja em conformidade com os requisi-
DEFEITO tos ou especificações, sendo necessária sua correção ou
(FAULT) substituição. Termos como “erro” e “bug” comumente são
usados para expressar defeitos;

Resultado incoerente produzido por meio de uma ação no

ERRO (ERROR) sistema;

Incapacidade do software exercer a função para a qual foi

FALHA (FAILURE) desenvolvido.

Sendo assim, engano introduz um defeito que quando é exercitado, ideal-

mente por meio da execução de um caso de teste, produz um erro no sistema e
esse erro, consequentemente, faz com que o sistema falhe.
Caro aluno, até esse momento você já aprendeu o que é teste, caso de teste,
cenário de teste e acabou de ver o que é engano, defeito, erro e falha. Claro que
esse é apenas o começo e muitos outros conceitos serão vistos no decorrer des-
se livro. Por outro lado, esses conceitos são a base de todos eles e entendendo

capítulo 1 • 21
bem, você está pronto para continuar – o que falta é você entender como teste
está inserido no ciclo de vida de um software.

1.3  O teste nas fases de vida e de desenvolvimento de um software

Sempre que falamos de alguma atividade relacionada ao desenvolvimento de

software, nos lembramos dos modelos de processo de desenvolvimento, afinal,
é assim que geralmente começa nosso entendimento técnico sobre como de-
senvolver um software.
Se relembrarmos os principais modelos de processo, veremos que todos
incluem a atividade de teste. Vamos relembrar alguns deles para encerrarmos
esse capítulo não apenas sabendo sobre a importância do teste para a qualida-
de do software, o que é teste, caso de teste, cenário de teste e defeito, mas nos
convencendo que a atividade de teste é importante, deve ser estudada e pratica-
da por todos os estudantes e profissionais de TI.
O modelo mais famoso é o Cascata, também conhecido como modelo
de Ciclo de Vida Clássico. Ele é dividido em 5 fases: Definição de Requisitos,
Projeto do Software, Implementação e Teste de Unidade, Integração e Teste do
Sistema e Operação e manutenção. Na atualidade a atividade de teste é prevista
em todas as fases, pois é fundamental que as definições e construções estejam
correspondentes às necessidades apresentadas pelo cliente.

Definição de
Requisitos

Projeto de
Software

Implementação
e Teste de Unidades

Integração e
Teste do Sistema

Operação e
Manuteção

Figura 1.4  –  Modelo Cascata de desenvolvimento de software. (Sommerville, 2011)

22 • capítulo 1
 O Modelo Incremental é aquele no qual o Modelo Cascata é aplicado de for-
ma iterativa. O núcleo do produto é desenvolvido primeiro, como se fosse um
produto único (e seguindo o modelo cascata) e após isso, novos incrementos
são planejados e desenvolvidos. Sendo assim, podemos constatar que a cada
incremento a atividade de teste também é prevista, pois deve acontecer no con-
texto da fase de Transição.

Fases
Disciplinas Iniciação Elaboração Construção Transição
Modelagem de Negócios
Requisitos

Análise de Design

Implementação
Teste
Implantação
Geren. de
Configuração e Mudança
Gerenciamento de Projeto
Ambiente

Iniciação Elab. Elab. Const. Const. Const. Trans. Trans.

n° 1 n° 2 n° 1 n° 2 n° N n° 1 n° 2
Iterações

Figura 1.5  –  Modelo incremental de desenvolvimento de software. Disponível em: <http://

www.infoescola.com/engenharia-de-software/rup/>.

O Modelo RAD (Rapid Application Developement), de acordo com

(PRESSMAN, 2006), é uma adaptação de alta velocidade do modelo Cascata, por
meio de uma abordagem baseada em componentes. A fase de Comunicação e
Planejamento são executadas, assim como no Cascata, e então os componen-
tes são planejados e seguem para desenvolvimento paralelo, que é a fase de
Modelagem e Construção. Após todos os componentes estarem prontos, ini-
cia-se a fase de Implantação. Assim como no Modelo Cascata e Incremental,
a fase de testes é prevista na atividade de Construção, que no caso do modelo
RAD, ainda prevê a atividade de reuso de componentes e geração automática de
código. (PRESSMAN, 2006)

capítulo 1 • 23
 Equipo 1 Equipo 2 Equipo 3 ...
Modelado de
Modelado de Gestiôn
Modelado de
Gestiôn

Gestiôn Modelado de
Dados
Modelado de
Dados
Modelado de Modelado de
Processo
Dados Modelado de Generacion de
Processo Amplicaciones

Piruletas y
Generacion de
Modelado de Amplicaciones
Entrega

Processo
Piruletas y
Entrega
Generacion de
Amplicaciones

Piruletas y
Entrega

60-90 dias

Figura 1.6  –  Modelo RAD de desenvolvimento de software. Disponível em: <https://www.

google.com.br/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&-
ved=0ahUKEwjUt52L95_MAhVChJAKHds6D20QjRwIBw&url=http%3A%2F%2Fspa-
nishpmo.com%2Findex.php%2Fciclos-de-vida-desarrollo-rapido-de-aplicaciones%2F&psi-
g=AFQjCNFXDSk3EFgwTWjrXAYy9yUGmm0WAQ&ust=1461334953079376>.

Quando falamos nos modelos evolucionários – prototipagem e espiral –

também temos a atividade de teste prevista na fase de Construção.
No Modelo de Prototipagem, as fases são Comunicação, Plano rápido,
Modelagem de projeto rápido, Construção do Protótipo e por fim, Implantação,
Entrega e Feedback. Nesse caso, temos a fase de teste tanto do lado do time de
desenvolvimento, que testa o protótipo construído, como também há um teste
(não formal, obviamente) por parte do cliente, sendo que os resultados desses
testes são coletados por meio do feedback do cliente. (PRESSMAN, 2006)
No Modelo Espiral, que é uma junção da iteratividade da prototipagem
com o controle do modelo Cascata, as fases são Comunicação, Planejamento,
incluindo agora a análise risco, Modelagem, Construção – incluindo a ativi-
dade de teste e Implantação, que inclui entrega e feedback da prototipação.
(PRESSMAN, 2006)

24 • capítulo 1
 Planejamento
estimativa de custos
cronograma
análise de riscos

Comunicação

Modelagem
análise
projeto
Início

Emprego
entrega Contrução
feedback codificação
testes

Figura 1.7  –  < h t t p : / / a r q u i v o . d e v m e d i a . c o m . b r / a r t i g o s / H i g o r _ M e d e i r o s /

processos_es/image003.gif>.

Pensando em guias e frameworks modernos e amplamente utilizados na

indústria de software nos dias de hoje, o Scrum (SCHWABER e SUTHERLAND,
2013) merece um grande destaque.
Por definição, o Scrum é um framework desenvolvido para que as pessoas
possam tratar e resolver problemas complexos e adaptativos, mas ainda assim
de maneira produtiva e criativa, entregando produtos que agregam valor ao
cliente. Sendo assim, ele não define um processo de desenvolvimento, mas sim
boas práticas e atividades a serem seguidas.
Três pontos importantes em relação a teste no Scrum que merecem desta-
que é:
1. Ao fim de cada Sprint (iterações, comumente, 2 ou 4 semanas de desen-
volvimento), é esperado que se tenha um “entregável” do produto, ou seja, uma
versão pronta para ser usada (o que não significa, necessariamente, que será
entregue ao cliente);
2. O time Scrum deve ser multidisciplinar e todos devem seguir o conceito
de pronto, que é um conceito definido pelo próprio time a fim de garantir que o
trabalho está completo no incremento da Sprint;
3. Considerando que todos estão envolvidos com o teste, o empenho
em garantir que apenas requisitos testáveis e bem especificados façam parte
do Sprint backlog, que é compartilhada por todos, afinal, eles terão que testar
aquele requisito assim que ele estiver pronto, antes de terminar a Sprint.

capítulo 1 • 25
 Sendo assim aproveitando todo o conhecimento sobre testes que estamos
construindo nesse capítulo, pergunto a você:

PERGUNTA
“Como garantir que o entregável realmente é uma versão que pode ser usada pelo cliente e
que, por definição, agrega valor ao negócio?”
“Como cada pessoa do time Scrum pode ir ao encontro de qualquer conceito de pronto
e ter certezas sobre o seu trabalho estar completo ao final da Sprint?”

Sim, todos devem realizar atividades de teste. Em times Scrum, testes uni-
tários (que veremos no capítulo 3) são altamente recomendados e ao fim da
Sprint, todos devem estar comprometidos com a qualidade do incremento,
garantindo que testes tenham sido realizados para evitar que defeitos sejam
encontrados pelo cliente.
A figura 1.8 apresenta uma ilustração do framework Scrum, seus eventos e
papéis – o objetivo da figura é que você entenda um pouco melhor, após essas
colocações, quando a atividade de teste pode ser executada nesse contexto. É
importante ressaltar que os pontos levantados aqui não eliminam a necessi-
dade de um time de testadores e um time de SQA (Software Quality Assurance)
como consultores externos ao time Scrum.

Figura 1.8  –  O framework Scrum e seus eventos. (AGILE ATLAS, 2016)

26 • capítulo 1
 Sendo assim, é importante que você esteja convencido da importância de
estudar teste de software quando você é um profissional de TI, independente-
mente da área que pretende atuar, pois qualidade é algo esperado por qualquer
usuário, de qualquer produto. Como acabamos de ver, os modelos de proces-
so de desenvolvimento de software preveem essa atividade, o que indica forte-
mente sua relevância para os aprendizes e profissionais em desenvolvimento
de software.

CURIOSIDADE
Embora não seja uma data amplamente divulgada e comemorada, dia 20 de Fevereiro é
considerado o dia do Teste de Software. Isso porque em 20 de fevereiro de 1979, o famoso
pesquisador e autor Glenford Myers publicou o livro "The Art of Software Testing", introduzin-
do pela primeira vez o termo “Teste de software” e consequentemente, se tornando referência
obrigatória em todas as publicações a partir de tal data até os dias atuais.

ATIVIDADES
01. Lembrando sobre o time de SQA comentado no início do capítulo, pense no contexto de
alguma empresa de desenvolvimento de software que você conheça que não tenha um time
de SQA e escreva quais papéis você acredita que poderia compor esse time;

02. Faça uma pesquisa em fábricas de software ou com amigos que desenvolvem software
em alguma empresa e responda:
a) Quantas delas possuem um time de SQA?
b) Quantas delas se preocupam com atividades de garantia de qualidade?
c) Se identificar alguma empresa no item b, quais atividades a empresa aplica?

03. Defina, com suas palavras, o que é Verificação e o que é Validação de software.

04. No contexto de teste de software, o que é engano? Dê um exemplo.

05. No contexto de teste de software, o que é defeito? Dê um exemplo.

06. No contexto de teste de software, o que é erro? Dê um exemplo.

capítulo 1 • 27
07. No contexto de teste de software, o que é falha? Dê um exemplo.

08. No contexto de teste de software, o que é caso de teste?

09. No contexto de teste de software, o que é um cenário de teste e para quais fins ele pode
ser utilizado?

10. Você já havia estudado sobre o Scrum? Qual a sua opinião sobre as atividades de teste
nesse contexto?

REFLEXÃO
Parabéns! Você conseguiu chegar até o final do nosso primeiro capítulo.
Nesse capítulo você recebeu um turbilhão de novas informações, definições, perguntas,
respostas e reflexões que são cruciais para a jornada que estamos começando.
A partir dos próximos capítulos vamos detalhar mais tópicos já mencionados aqui, como
critérios de teste, teste de unidade, defeitos e outros termos.
Por hora, você já deve estar sabendo conceitos básicos sobre qualidade de software, o
papel do time de SQA e um pouco sobre as atividades de validação e verificação. É impor-
tante ressaltar que cada atividade de V&V tem sua importância, mas que neste livro, vamos
estudar sobre teste de software por se tratar da atividade de V&V mais aplicada na indústria
e ainda hoje, amplamente estudada no ambiente acadêmico e científico.
Nós também aprendemos o que é o teste com mais detalhes, o que é um caso de tes-
te e vimos dois exemplos em contextos diferentes, que nos permitiram entender o que é
importante em um caso de teste. Vimos também um exemplo de como reportar defeitos
encontrados durante o teste.
Aliás, tocando nesse assunto novamente aqui na nossa reflexão, vale a pena reforçar
que o objetivo da atividade de teste é encontrar defeitos e provar que eles existem, e nunca
afirmar que um software está livre de defeitos.
Reforçando um pouco mais conteúdo, a única maneira de afirmar que não há defeitos
num software é testando-o exaustivamente, com todas as entradas possíveis – como vimos,
isso é difícil se considerarmos apenas um método, com um parâmetro - imagine considerar
um sistema por completo.
Embora não seja o tópico desse capítulo, vimos que esse nosso impasse será resolvido
por meio dos critérios de teste, que vamos estudar adiante.

28 • capítulo 1
 Após ver todos esses conceitos, caminhamos um pouco mais e aprendemos sobre casos
de teste, cenários de teste e finalmente, fizemos a distinção de conceitos que permeiam to-
das as atividades de V&V e que causam muita confusão: engano, defeito, erro e falha.
A fim de olhar para a atividade de teste de um outro ponto de vista e reforçar a importân-
cia desse conhecimento para a sua formação, revisitamos brevemente alguns dos principais
modelos de ciclo de vida de software para relembrar que todos eles preveem a atividade de
teste como parte de suas atividades – ou seja, desde que a indústria de software começou
a se organizar, a necessidade de testar ficou evidente e acompanha a evolução da forma de
se desenvolver software. Outra evidência disso foram os pontos que ressaltamos sobre teste
no contexto do Scrum, que é uma abordagem moderna de desenvolvimento de produtos.
Querido aluno, esse foi apenas o começo...
Vamos em frente que temos muito conhecimento para construir.

LEITURA
Uma leitura bastante interessante que aborda o teste de software são livros do autor Leo-
nardo Molinari “Testes de software: produzindo sistemas melhores e mais confiáveis”,
publicado em 2003 pela Editora Érica. Além disso, muitos e-books e material on-line está
disponível para aprimorar seus conhecimentos sobre o tema, como o site <https://strongqa.
com>, que disponibiliza diversos exemplos e templates que podem ser úteis. Boa leitura!

REFERÊNCIAS BIBLIOGRÁFICAS
AGILE ATLAS. Scrum Framework. Agile Atlas, 27 abr. 2016. Disponível em: <http://agileatlas.org/
articles/item/scrum-framework>. Acesso em: 19 abr. 2016.
ATLASSIAN. Jira. Atlassian, 27 mar. 2016. Disponível em: <https://www.atlassian.com/software/jira>.
BINDER, R. V. Testing object-oriented systems: Models, patterns, and tools. London: Addison
Wesley Longman, 1999.
BUGZILLA. Bugzilla. Bugzilla, 27 mar. 2016. Disponível em: <https://www.bugzilla.org/>.
DA SILVA, L. et al. Marketing Estratégico - Módulo 4.2. Ribeirão Preto: Uniseb Interativo, 2013.
FABBRI, S. Atividades de V&V. São Carlos. 2009.
FIRESMITH, D. Using V Models for Testing. SEI Blog, 11 nov. 2013. Disponível em: <https://
insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html>.

capítulo 1 • 29
IEEE 829-2008. IEEE 829-2008 Standard for Software and System Test Documentation. New
York. 2008.
ISO. ISO/IEC TR 9126-2:2003. Software engineering -- Product quality, p. 86, 2003.
ISO/IEC/IEEE 24765. ISO/IEC/IEEE 24765:2010 (E) Systems and Software Engineering -
Vocabulary. New York. 2010.
ISTQB. What is Defect or bugs or faults in software testing? ISTQB Exam Certification, 27 mar.
2016. Disponível em: <http://istqbexamcertification.com/?s=bug+report>.
ISTQB. What is Maintenance Testing? ISTQB, 27 mar. 2016. Disponível em: <http://
istqbexamcertification.com/what-is-maintenance-testing/>.
MCCALL, J.; RICHARDS, P.; WALTERS, G. Factors in Software quality. [S.l.]. 1977.
MYERS, G. The Art of Software Testing. New Jersey: John Wiley & Sons, 2004.
OLSINA, L. et al. Specifying Quality Characteristics and Attributes for Websites. 1st ICSE
Workshop on Web Engineering. Los Angeles: ACM. 1999.
PRESSMAN, R. Engenharia de Software. São Paulo: McGraw-Hill, 2006.
PREZZÈ, M.; YOUNG, M. Software testing and analysis: Process, principles and techniques. New
Jersey: John Wiley & Sons, 2007.
ROPER, M. Software testing. London: McGrall Hill, 1994.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum. Scrum Guide, ago. 2013. Disponível em: <http://
www.scrumguides.org/>.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson, 2011.
TESTLINK. Testlink. Testlink, 27 mar. 2016. Disponível em: <http://testlink.org/>.
VERACODE. Static testing vs dynamic testing. Veracode, 27 mar. 2016. Disponivel em: <https://
www.veracode.com/blog/2013/12/static-testing-vs-dynamic-testing>.

30 • capítulo 1
 2
Teste no programa
2.  Teste no programa
Olá, caro aluno! Que bom que seus estudos sobre teste de software estão pro-
gredindo bem. É muito bom tê-lo no segundo capítulo!
No capítulo anterior discutimos sobre a importância da atividade de teste,
contextualizamos as atividades de garantia de qualidade (SQA), vimos o que
são as atividades de verificação e validação e começamos a aprofundar nos con-
ceitos da área de teste – caso de teste, cenário de teste, engano, defeito, erro e
falha. Para finalizar não só relembramos alguns modelos de ciclos de vida de
software e reforçamos que a atividade de teste está prevista em todos eles.
Com esse conteúdo em mente, estamos prontos para dar um passo adian-
te e falar sobre técnicas de teste, os famosos testes caixa branca e testes caixa
preta, depuração, assim como testes em ambiente web. A fim de fazermos uma
comparação, veremos também o que são as revisões técnicas formais mencio-
nadas no capítulo anterior. Temos certeza que esse conteúdo será de extrema
importância para sua vida acadêmica e principalmente para sua carreira profis-
sional, sendo ela trilhada na área de teste ou não!

OBJETIVOS
•  Aprender sobre revisões técnicas formais;
•  Aprender sobre técnicas de teste;
•  Aprender o que é teste caixa branca e quais seus critérios de teste;
•  Aprender o que é teste caixa preta e quais seus critérios de teste;
•  Entender a diferença entre teste caixa branca e caixa preta;
•  Aprender sobre a atividade de depuração;
•  Aprender sobre testes de ambiente web.

2.1  Revisões técnicas formais, no que isso pode ser útil?

No capítulo anterior vimos que Firesmith (Firesmith, 2013) comenta que as

atividades de V&V são tipicamente executadas usando técnicas de análise, de-
monstração, inspeção e teste.

32 • capítulo 2
 Podemos dizer que a análise e inspeção são técnicas essencialmente estáti-
cas e que demonstração e teste são técnicas dinâmicas – as duas primeiras não
exigem que se tenha um artefato executável para serem aplicadas, enquanto
que as duas últimas dependem de um artefato.
Recapitulando o que vimos no capítulo anterior, a análise no contexto de
V&V aplica técnicas ou modelos matemáticos, algoritmos de simulações ou
procedimentos científicos para determinar se algum produto ou artefato está
em conformidade com seus requisitos (Firesmith, 2013). Sendo assim, pode-
mos abstrair que esse tipo de atividade é aplicado em sistemas críticos, nos
quais há um alto risco em testar o que foi desenvolvido, por exemplo, sistemas
no ramo espacial, aéreo, químico etc.
As demonstrações (comumente chamadas de demos) são execuções do
produto para que o cliente, ou alguém nesse papel faça a aprovação e dê um
feedback sobre o que foi construído. Nesse ponto, para otimizar recursos, o ideal
é que o produto desenvolvido esteja o mais próximo possível dos requisitos.
Com base nisso, podemos constatar que para que o produto em desenvolvi-
mento esteja em conformidade com os requisitos, é importante que esses requi-
sitos estejam adequados. Mesmo porquê, se pensarmos na atividade de teste,
vimos no capítulo anterior que essa atividade também depende dos requisitos.
Por requisitos de software, no nosso contexto, podemos entender que é
qualquer documento que especifica as funcionalidades do software – pode ser
o documento textual, pode ser um diagrama de caso de uso, diagrama de ativi-
dades, fluxogramas... enfim, qualquer artefato que registre e especifique com
qualidade o que deve ser desenvolvido.
©© PIXABAY.COM

Figura 2.1  – 

capítulo 2 • 33
 Tendo isso em mente, você pode se perguntar:

PERGUNTA
“Professor, se vimos que o teste é uma forma de encontrar defeitos... e se pensarmos que al-
gum problema nos requisitos vai impactar nos testes que serão criados desde o começo, mas
executados apenas no final de um ciclo, o ideal seria testar os requisitos para que possamos
identificar os problemas existentes. Tem como fazer isso, mesmo sabendo que os requisitos
não são executáveis? ”

Primeiro, é bom lembrarmos que alguns requisitos são executáveis, como

por exemplo, aqueles especificados por meio de máquina de estado. No entan-
to, isso se aplica a sistemas muito específicos. Na grande maioria dos sistemas
os requisitos não são executáveis e uma forma de garantir a qualidade deles é
por meio de atividades V&V de inspeção, como revisões técnicas formais.
Desde já é importante destacar que revisões técnicas não são exclusividade
de requisitos – essas atividades podem ser aplicadas em todos os artefatos pro-
duzidos durante o ciclo de vida de um sistema, incluindo código-fonte.
As revisões técnicas formais, de acordo com (Pressman, Engenharia de
Software - Uma abordagem profissional, 2011) podem ser vistas como um filtro
para o processo de engenharia de software, afinal, ao revisar um artefato, ou
seja, uma representação do software, seja ela visual ou textual, e corrigir pos-
síveis defeitos, o próximo artefato e ser construído tendo o artefato revisado
como base não irá propagar esse defeito. Exemplo: ao inspecionar um docu-
mento de requisito, identificar e corrigir os defeitos, ao definir o diagrama de
casos de uso, esses defeitos não serão mais propagados, tornando o custo de
correção menor, pois isso é feito apenas em um artefato.
Os objetivos de uma revisão técnica formal, conhecida pelo acrônimo RTF,
são: (Pressman, Engenharia de Software - Uma abordagem profissional, 2011)
•  Identificar defeitos na implementação, na lógica ou em qualquer outra
forma de representação do sistema;
•  Verificar se o software satisfaz seus requisitos;
•  Garantir se padrões definidos para o time ou convenções da comunidade
estão sendo seguidos nas diversas formas de representação do software;
•  Permitir que o software seja desenvolvido de forma uniforme, sem mu-
danças drásticas no meio do caminho;

34 • capítulo 2
 •  Facilitar a administração/gerenciamento dos projetos;
•  Disseminar conhecimento para novos engenheiros de software.

Uma RTF pode ser considerada com uma classe (um conjunto) de diferen-
tes formas de revisão, como por exemplo, walkthroughs, inspeções, inspeções
circulares entre outras. Uma das atividades mais genéricas e que pode ser adap-
tada em vários contextos por meio de checklists e técnicas de leitura é a inspe-
ção de software.
A figura 2.2 apresenta uma representação visual das atividades e dos papéis
que os envolvidos empenham durante a inspeção. De maneira sucinta, os pa-
péis e as atividades são (Sauer, JEFFERY, , Land., & YETTON, 2000):

É o principal ator do processo de inspeção - lidera a

MODERADOR equipe e deve garantir o sucesso da atividade;

São os responsáveis por identificar os defeitos no

INSPETOR artefato;

É quem (ou o time) criou o artefato que será

AUTOR inspecionado;

Todos os envolvidos ficam a par do contexto do projeto

APRESENTAÇÃO e devem saber mais detalhes do que será inspecionado;

Os inspetores, com base em um checklist ou em uma

técnica de leitura (que dá as diretrizes de como o artefa-
DETECÇÃO to deve ser analisado), inspecionam o artefato a procura
de enganos e defeitos;

É feita a consolidação de todos os defeitos, de todos os

COLEÇÃO revisores;

Como uma reunião, todos os envolvidos discutem os

defeitos encontrados para identificar quais devem ou
DISCRIMINAÇÃO não ser corrigidos, encaminhando os que devem ser
corrigidos para a etapa de retrabalho;

capítulo 2 • 35
 Os defeitos encontrados são corrigidos pelo autor do
RETRABALHO artefato;

O moderador verifica cada correção feita pelo autor e

ACOMPANHAMENTO identifica se é necessária uma nova inspeção.

1
moderador Apresentação

inspetor 2
Detecção

3
moderador
Coleção

moderador, 4
inspetores e Discriminação
autor
5
Papel autor
Retrabalho
Atividade
6
moderador
Acompanhamento

Figura 2.2  –  Processo de inspeção proposto por Sauer e outros (Sauer, JEFFERY, , Land.,
& YETTON, 2000). Adaptado de (Travassos & Kalinowski , 2004)

Observando as atividades que são executadas, podemos ver que elas podem
ser feitas em qualquer artefato – afinal, de maneira abrangente, é feita a leitu-
ra, com base em direcionamentos prévios, a fim de encontrar defeitos. Sendo
assim, embora seja possível realizar inspeções no código, na literatura encon-
tramos mais exemplos relacionados a inspeção de artefatos não executáveis.
Como vimos no início dessa seção, a revisão formal pode ser vista como uma
aliada à atividade de teste, para garantir que o documento no qual os casos de
teste serão baseados (requisitos, casos de isso, estórias de usuário etc.) possam
estar livres de defeitos ou enganos.
Embora não seja o foco do nosso livro, conhecer sobre revisões formais, no
nosso caso, inspeção, pode ajudar o profissional envolvido com teste de softwa-
re a executar e propor o desenvolvimento dessas atividades a fim de melhorar
os artefatos desenvolvidos e consequentemente melhorar os casos de teste de-
finidos. Além disso, ao aplicar essas técnicas ou disseminar essa mentalidade
de revisão entre todos os envolvidos, a tendência é que o produto e o processo

36 • capítulo 2
tenham sua qualidade melhorada, o que pode influenciar no número de defei-
tos encontrados durante a execução dos cenários de teste.
Nesse ponto, conhecendo uma técnica que ajuda a melhorar os artefatos
usados para definir casos de teste, estamos prontos para darmos mais um
passo e aprender sobre técnicas de teste. Para melhorar o entendimento, va-
mos observar alguns cenários da vida real – será que você se identifica com al-
gum deles?

2.2  Observando cenários da vida real

Olá, aluno! Vamos pensar em uma situação real de duas pessoas que, assim
como você, conhecem teste de software e reconhecem a importância dessa
atividade.
Nossa primeira personagem é Augusta, uma aluna dedicada da área de
computação, atualmente aprendendo uma nova linguagem de programação.
Nossa outra personagem é Graça, um profissional exemplar da área de com-
putação, extremamente preocupada em quão útil e correto para o cliente final
será o software que ela ajuda a desenvolver.
Augusta está no início do semestre e por enquanto ela desenvolve algorit-
mos, sem nenhuma interface gráfica. Para aprender muito bem a sintaxe da
linguagem, ela implementa algoritmos de ordenação ente outros. Por ser uma
aluna dedicada e muito caprichosa, Augusta sempre testa muito bem seus al-
goritmos, pois mesmo quando a entrega não vale nota, nossa personagem se
preocupa com a qualidade do programa pois sabe que assim trilhará um ótimo
futuro como profissional.
©© PIXABAY.COM

Figura 2.3  – 

capítulo 2 • 37
 Como são algoritmos, nossa amiga Augusta consegue conferir linha a li-
nha, para ter certeza que ela sabe o comportamento de cada linha de código e
principalmente, que cada linha de código executa exatamente o que precisa ser
executado. Dessa forma, as chances dos algoritmos de ordenação da Augusta
estarem corretos é muito alta. Por outro lado, Augusta despende um tempão se
dedicando a pensar em dados de entradas para o algoritmo que exercite cada
linha de código... e ainda assim, em alguns casos, quando ela apresenta o algo-
ritmo para o professor ou para algum colega, eles acabam encontrando algum
problema que Augusta não observou antes.
Já nossa personagem Graça faz parte de um dos times Scrum de uma grande
empresa de desenvolvimento de software. Atualmente, ela trabalha no desen-
volvimento de um sistema ERP (Enterprise Resource Planning).
©© PIXABAY.COM

Figura 2.4  – 

Já nossa personagem Graça faz parte de um dos times Scrum de uma grande
empresa de desenvolvimento de software. Atualmente, ela trabalha no desen-
volvimento de um sistema ERP (Enterprise Resource Planning).
No início do desenvolvimento, o ERP do time da Graça também se parecia
com os algoritmos da Augusta. No entanto, com algumas semanas de desenvol-
vimento, o software já tinha muitas funcionalidades – muito código e muitas
interfaces gráficas, parecendo um verdadeiro quebra-cabeça (e tão bem plane-
jado quanto, pois nossa amiga Graça e seus colegas de time sabem da impor-
tância de todas as fases do processo de desenvolvimento de software.).

38 • capítulo 2
 Obviamente que Graça, antes de submeter seu código ao sistema de ge-
renciamento de configuração (como o GitHub -<https://github.com/>- por
exemplo), confere linha a linha dos métodos que ela desenvolve, assim como
a Augusta. No entanto, é importante verificar se os métodos da Graça irão fun-
cionar da forma esperada quando se integrarem com outros métodos da Graça
e de seus colegas.
Para isso, Graça e todo seu time Scrum, antes de entregarem uma versão do
software para o cliente, preparam um ambiente com a nova versão do ERP com
um banco de dados populado com dados reais e “brincam” de cliente – eles
executam todas as funcionalidades do ERP como se fossem os usuários reais
com o intuito de verificar se o que foi desenvolvido está correto e validar se as
funcionalidades pedidas pelo cliente estão da maneira como ele pediu.
Como vocês podem imaginar, em alguns casos Graça e seus colegas ficam
sem tempo para “brincar” de cliente, pois o cliente real tem pressa pelas funcio-
nalidades novas. Em outros momentos, alguns colegas de Graça reclamam que
ao invés de “brincar” de cliente, eles poderiam produzir mais linhas de código
e deixar para o cliente fazer a verificação e a validação do que eles produziram.
Além disso, quanto mais o desenvolvimento do ERP avança, mais funcionalida-
des ficam prontas e o “brincar” de cliente para executar todas as funcionalida-
des exige cada vez mais tempo do time Scrum.
Embora Graça saiba da importância de tudo isso, ela se desanima quando
recebe uma solicitação do cliente para arrumar uma funcionalidade que não
funciona como o esperado.
Querido aluno, agora vamos pensar juntos nos dois cenários que acabamos
de analisar. A pergunta é:

PERGUNTA
Como podemos ajudar nossa amiga Augusta a confiar em seus algoritmos de forma que ela
garanta que todas as linhas de código foram executadas e que mesmo assim, ela gaste o
menor tempo possível?

capítulo 2 • 39
 Considerando o caso da Graça, a pergunta é similar:

PERGUNTA
Como podemos ajudar a Graça e seus colegas de trabalho a evitarem que o cliente receba
uma funcionalidade que não funciona como o esperado e que ao mesmo tempo, eles não
tenham que ficar muito tempo “brincado” de ciente?

Pensou?
A palavra-chave para tudo isso é Teste.
Se observarmos bem, embora a palavra “teste” não tenha sido menciona-
da na apresentação dos dois cenários, você, aluno que já fixou o conteúdo do
primeiro capítulo, sabe que na verdade, tanto Augusta quanto Graça estão tes-
tando o software que elas desenvolveram. A diferença entre os testes realizados
pelas nossas personagens é a técnica de teste que elas utilizam – Augusta utiliza
a técnica caixa preta enquanto Graça utiliza a técnica caixa branca.
Você deve estar se perguntando: “Como assim caixa branca e caixa preta? O
que essas cores significam? Técnica de teste. O que é isso?”
Perguntas importantes querido aluno, e fique tranquilo que iremos usar
apenas essas cores para falar de teste. Agora, vamos seguir em frente para co-
nhecer o que são técnicas de teste e nos aprofundar ainda mais nesse universo.

2.3  Técnica de testes, o que é isso?

Após ler que existem técnicas de teste e ao se lembrar dos dois cenários, que
incluem nossas amigas Augusta e Graça, você pode até pensar: “Entendi tudo! A
técnica caixa preta é para pequenos algoritmos, como o da Augusta, e a técnica
caixa branca é para grandes sistemas, como o da Graça. Certo, professor?”
De jeito nenhum. Pense sempre que o pequeno algoritmo da Augusta na
verdade, tem uma funcionalidade, que pode ser a de ordenar um conjunto de
números, e essa funcionalidade pode fazer parte de um sistema bem maior,
como o ERP da Graça. Por outro lado, o ERP da Graça é, na verdade, um gran-
de conjunto de pequenos algoritmos que em conjunto, implementam diversas
funcionalidades, como cálculos de folha de pagamento etc.

40 • capítulo 2
 Em suma, o que determina a técnica a ser usada é a necessidade da equipe,
do cliente, as características do software, a estratégia de teste que foi planejada,
iremos abordar no próximo capítulo (capítulo 3) e principalmente o dado do
software ao qual você tem acesso – afinal, nem sempre temos acesso ao código
fonte de um software, mas nem por isso temos que deixar de testá-lo.
Além das técnicas de teste mencionadas – caixa branca e caixa preta – é im-
portante que você saiba que existe uma terceira técnica, chamada de técnica
baseada em erros (ou em inglês, fault-based testing).
Na literatura acadêmica sobre teste nós podemos encontrar autores que
apresentam as técnicas de teste de diferentes maneiras. A norma ISO/IEC/IEEE
29119-4 (ISO/IEC/IEEE 29119-4, 2015) define três técnicas de teste:
•  Técnica baseada em especificação, que é a técnica caixa preta menciona-
da acima, também conhecida como técnica funcional;
•  Técnica baseada em estrutura, que é a técnica caixa branca mencionada
acima, também conhecida como técnica estrutural;
•  Técnica baseada em experiência, que é a técnica baseada em erros.

Considerando que as técnicas de teste comumente aplicadas na indústria e

consequentemente as mais conhecidas são as técnicas funcionais (caixa bran-
ca) e estruturais (caixa preta), iremos abordá-las em detalhes neste capítulo.
Sendo assim, vamos seguindo por que tem bastante conhecimento impor-
tante e interessante para você aprender sobre caixa preta e caixa branca e de-
pois poder colocar em prática nos seus trabalhos acadêmicos e na sua equipe
de desenvolvimento de software.

2.4  Teste caixa preta, o teste funcional

Como vimos nos parágrafos anteriores, a técnica de teste caixa preta também é
conhecida como técnica funcional.
Essa técnica pode ser adotada quando a equipe de teste tem acesso a es-
pecificação do sistema. Isso porque a base para definição dos casos de teste é
a especificação do sistema, visto que ao usar essa técnica, o intuito é testar o
sistema do ponto de vista das suas funcionalidades.
Como o próprio nome indica, essa técnica de teste considera que o sistema
a ser testado é uma caixa preta – você não sabe o que tem dentro, só sabe o que
precisa colocar dentro da caixa e o que você espera que sala da caixa. Em outras

capítulo 2 • 41
palavras, trazendo um pouco mais para a realidade do teste, você sabe os dados
que devem colocar dentro da caixa, considerando a especificação das funciona-
lidades que devem estar implementadas no software, e você também sabe qual
a saída de dados esperada. Veja a figura 2.5 para melhor entendimento.

Dados de Dados
entrada Caixa Preta de saída
baseado na (software) baseado na
especificação especificação

Figura 2.5  –  Ilustração da técnica de teste caixa preta.

De acordo com Myers (Myers, 2004), na técnica funcional o objetivo do tes-

tador é não se preocupar com o comportamento interno da estrutura do pro-
grama, ao invés disso, o testador deve se concentrar em encontrar situações nas
quais o sistema não se comporta da forma como foi especificado.
Conhecendo um pouco mais sobre o que é o teste caixa preta, vamos lem-
brar da nossa amiga Graça. Vamos supor que Graça precisa testar uma funcio-
nalidade do ERP que calcula o percentual de horas extras de um funcionário
tendo como base o número de horas padrão trabalhada por mês. Esse requisito
é definido da seguinte forma:

“Como RH, eu quero informar o número de horas trabalhadas e saber o percentual de horas
extras que o funcionário fez, considerando que o número de horas padrão é 40 horas mensais,
para que eu saiba se existe um funcionário que faz mais que 25% de hora extra por mês”.

Com base nessa descrição, Graça sabe que se ela informar que um funcio-
nário trabalhou 50h no mês, ela sabe que o sistema deve informar que esse fun-
cionário fez 25% de hora extra, visto que 10h é 25% de 40h.
No entanto, se lembrarmos no capítulo 1, na seção sobre termos e concei-
tos sobre teste, nós vimos que alguns defeitos são encontrados dependendo da
entrada de dados que é usada no teste. Vimos também que teste por exaustão é
algo quase impossível. E nesse caso, a pessoa que irá testar a funcionalidade do
ERP não poderá dispender tanto tempo testando todas as possibilidades para a
variável número de horas trabalhadas.
Para ajudar o time de teste do ERP (e todos os testadores do mundo), existe
o que chamamos de critérios de teste.

42 • capítulo 2
 De acordo com Maldonado e Fabbri (Maldonado & Fabbri, 2001), os crité-
rios de teste servem para ajudar a definir, selecionar ou revisar os casos de teste
a fim de aumentar as possibilidades de identificação de defeitos e estabelecer
um nível elevado de confiança dos testes. Em outras palavras, como não é pos-
sível testar todas as possibilidades, os critérios ajudam a definir um conjunto
finito de casos de teste que potencialmente podem identificar defeitos - crité-
rios de teste nos dizem quando parar de definir casos de teste.
Cada critério possui seus requisitos de teste, que ajudam a gerar os casos de
teste de forma a satisfazer o critério escolhido e também avaliar a qualidade de
um conjunto de teste existente, analisando quais casos de teste precisam ser
acrescentados ao conjunto para que determinado critério seja atingido.
Para entendermos melhor, vamos pensar da seguinte forma: imagine um
critério de teste fictício chamado “Critério dos números primos menores que
20”. Esse critério diz que toda funcionalidade que requer entrada de números
inteiros deve ser testada usando todos os números primos menores que 20
(lembre-se, é apenas um exemplo). Sendo assim, o requisito desse critério é:
temos que definir casos de teste que considerem como entrada os números 2,
3, 5, 7, 11, 13, 17 e 19. Se formos nos basear em um conjunto existente de casos
de teste, temos que analisar quais números já estão sendo considerados e de-
terminar, se necessário, quais casos de teste devem ser definidos. Se não tiver-
mos casos de teste para esses números, não estamos em conformidade com os
requisitos do critério de teste.
Considerando que temos técnicas diferentes de teste – uma baseada em
código e outra baseada em funcionalidade – os critérios de teste também são
diferentes para testes caixa branca e caixa preta.
Os principais critérios de teste caixa preta são: Particionamento de
Equivalência e Análise do Valor limite.

•  Particionamento de Equivalência
Para aplicar esse critério de teste, precisamos dividir o domínio de entrada de
dados em classes e partições de equivalência. Classes são divididas em válidas e
inválidas e dependendo do requisito e dos dados de entrada, as partições de equi-
valência são definidas – partições de equivalência é quando qualquer valor, den-
tro de um dado intervalo, tem a mesma importância (Myers, 2004). Se a condição
de entrada mencionada no requisito especifica um intervalo (por exemplo, entre
0 e 100) ou um valor específico (número real), devemos definir uma classe válida
e duas inválidas; se a condição de entrada mencionada no requisito especifica

capítulo 2 • 43
um membro de um conjunto (por exemplo, um valor a ser selecionado a partir
de uma lista, valor maior que 40) ou uma condição boolena (sim/não, verdadeiro/
falso etc.) devemos definir uma classe válida e uma inválida (Fabbri, 2009).
No exemplo do requisito de horas extras apresentado acima, temos apenas
um valor de entrada, que é o valor para horas trabalhadas. Qualquer valor in-
formado para horas trabalhadas deveria se comportar da mesma maneira. No
entanto, sabemos que o número esperado de horas trabalhadas é 40 – o que
nos faz entender que a entrada deve ser de um conjunto de valores – valores
maiores que 40. Sendo assim, se o valor de horas trabalhadas for até 40 horas, o
programa se comporta de uma maneira (no caso, não calculando porcentagem
de horas extras). Qualquer valor maior que 40 horas, o programa deve se com-
portar de outra maneira. Resumindo: não devemos esperar que o valor 35 seja
interpretado da mesma maneira que 45, mas 35 deve ser interpretado como
qualquer valor até 40 e, consequentemente, 45 deve ser interpretado como
qualquer valor maior que 40.
Para esse contexto, temos uma classe válida e uma inválida: classe válida:
valor maior que 40; classe inválida; valor menor que 40. Dessa forma, devemos
definir dois casos de teste - um no qual o valor de entrada seja maior que 40; um
no qual o valor de entrada seja menor que 40.
Provavelmente você está se perguntando: “Professor, o valor 40 entra em
qual particionamento?”.
Excelente pergunta! Se uma revisão formal (como vimos na seleção ante-
rior) tivesse sido aplicada no documento de requisitos, provavelmente a am-
biguidade que enfrentamos agora teria sido eliminada. Como não há detalhes
suficientes na especificação, devemos questionar o responsável pelo artefato a
fim de definir o caso de teste adequadamente.
Nesse caso, vamos assumir que 40 não deve ser calculado hora extra e sendo
assim, o valor 40 faz parte da classe inválida. A figura 2.6 ilustra as classes de
equivalência considerando a atualização do requisito.
Particionamento de equivalência
<= 40 > 40

Particionamento de equivalência 1 Particionamento de equivalência 2

Classe inválida Classe válida
Valor para o caso de teste: qualquer Valor para o caso de teste: qualquer
valor menor que 40 valor maior que 40

Figura 2.6  –  Exemplo do critério particionamento de equivalência.

44 • capítulo 2
 Podemos constatar que com apenas dois casos de teste, nós conseguimos
atingir, para esse requisito funcional usado como exemplo, o requisito do crité-
rio de teste Particionamento de Equivalência.

•  Análise do valor limite

O critério de análise do valor limite é complementar ao Particionamento de
Equivalência. O foco desse critério é identificar fontes favoráveis a terem defei-
tos e criar casos de teste para exercitar esses dados (Fabbri, 2009).
Lembre-se da pergunta sobre o valor 40 feita acima. Se a revisão formal for
feita ou então se os casos de teste forem definidos antes da codificação, nós te-
mos a chance de corrigir essa falha de requisito e dessa forma, o desenvolvedor
saberia exatamente como desenvolver. No entanto, revisões formais nem sempre
são feitas e nem sempre os casos de teste são definidos com tanta antecedência.
Por outro lado, casos de teste bem elaborados são feitos para identificar de-
feitos e, se nesse cenário o testador usar o critério de análise do valor limite,
possivelmente o defeito sobre a interpretação do valor 40 seria identificado (se
houvesse algum).
O requisito do critério análise do valor imite é definir casos de teste para
valores de entrada que estão no limite das classes de equivalência. Algo impor-
tante de se verificar é que o tipo de dados deve ser observado com atenção.
Sendo assim, considerando o exemplo anterior, nós devemos pensar em li-
mites e dados propícios a darem problema (ou seja, não estão sendo conside-
rados da forma correta na implementação) – esses serão os valores de entrada
para os casos de teste.
No exemplo ilustrado na figura 2.7, que é referente ao exemplo da figura 2.3,
os limites identificados foram:
– O valor 40 – que está entre as classes de equivalência;
– Os valores 0 e -1 – que, apesar de não estar especificado, entende-
mos que 0 e valores negativos podem não se comportar como qualquer
valor 0 ← 40 e por isso, valores negativos e 0 sempre são usados como
limites quando não há especificação clara sobre eles;
– O valor 744 – que é 31 x 24, ou seja, nenhum funcionário conseguiria
trabalhar mais que 24 horas por dia nos 31 dias do mês. Como não há
uma limitação dos requisitos em relação as entradas, um bom testador
deve considerar o domínio da aplicação, o requisito em si e pensar em
valores que podem resultar em problema.

capítulo 2 • 45
 Análise do valor limite
<= 40 > 40

Valor limite: 0 Valor limite: 40 Valor limite: 744

Valor limite: –1

Figura 2.7  –  Exemplo do critério análise do valor limite.

Sendo assim, com mais quatro casos de teste nós conseguimos a conformi-
dade com os requisitos de outro critério de teste funcional. Esses dois critérios
são extremamente úteis e devem fazer parte da mentalidade de qualquer testa-
dor e qualquer desenvolvedor, pois faz com que todos os artefatos, do requisito
até o código fonte, sejam desenvolvidos de forma a evitar que enganos sejam
cometidos no tratamento desses limites.
Antes de continuarmos e aprendermos sobre teste estrutural, devemos lem-
brar que quanto mais custoso de aplicar um critério de teste, ou seja, quanto
mais casos de teste o critério definir, mais defeitos ele tende a identificar – a
competência está em identificar o mínimo suficiente para encontrar defeitos
sem que o projeto atrase e sem que defeitos críticos cheguem no usuário final.

2.5  Teste caixa branca, o teste estrutural

Como vimos no final da Seção 2.4, a técnica de teste caixa branca também é
conhecida como técnica estrutural.
Essa técnica pode ser adotada quando a equipe de teste tem acesso ao có-
digo fonte do sistema. Obviamente que ter acesso à especificação do sistema
também é desejável, mas é obrigatório o acesso ao código fonte. Essa exigência
é devido ao fato que a base para definição dos casos de teste é o código fonte,
visto que ao usar essa técnica, o intuito é testar o sistema do ponto de vista da
implementação, ou seja, das linhas de código que foram produzidas com o in-
tuito de prover as funcionalidades esperadas do sistema.
Como o próprio nome indica, essa técnica de teste considera que o sistema
a ser testado é uma caixa branca – você sabe exatamente o que tem dentro da
caixa. Você continua tendo que saber o que precisa colocar dentro da caixa e
o que você espera que saia da caixa, como fazemos no teste caixa preta, mas a
grande diferença aqui é que você define “o que colocar dentro da caixa” com
base no que tem dentro da caixa.

46 • capítulo 2
 Em outras palavras, trazendo um pouco mais para a realidade do teste, você
sabe os dados que deve colocar dentro da caixa e sabe qual a saída de dados es-
perada, mas nessa técnica, você decide os dados a serem inseridos na caixa com
base no código fonte do sistema. Veja a figura 2.8 para melhor entendimento.

Dados de Dados
entrada Caixa Branca de saída
baseado no (código fonte) baseado no
código fonte código fonte

Figura 2.8  –  Ilustração da técnica de teste caixa branca.

De acordo com Myers (Myers, 2004), na técnica estrutural o objetivo do tes-

tador é se preocupar com o comportamento de cada uma das estruturas inter-
nas do programa. Em outras palavras, a preocupação é com a lógica que foi im-
plementada. Quando não há especificação do sistema, essa pode ser uma das
formas possíveis de testar o que foi implementado.
Voltando no mesmo exemplo que usamos na seção anterior sobre o ERP da
nossa amiga Graça, podemos considerar que o código-fonte (aqui apresenta-
do em pseudocódigo) para implementar o método das horas extras pode ser o
apresentado na tabela 2.1.

1 inteiro calculo_hextraPercentual(real horasTrabalhadas) {

2 inteiro horasMes, horasExtras;
3 horasMes = 40;
4. SE (horasExtras > 40){
5. horasExtras = horasTrabalhadas - 40;
6 return (horasExtras * 100)/horasMes;
7. SENÃO
8. return 0;
9 }
10.}

Tabela 2.1  –  Exemplo de um código fonte.

Tendo o código fonte em mãos, eu posso pensar em casos de teste que exer-
citem as linhas e que também considerem os tipos dos dados (inteiro, real etc.),
o que pode me ajudar a definir os dados de entrada para cada caso de teste.
Para facilitar a definição dos casos de teste da técnica caixa branca (es-
trutural), a maioria dos critérios dessa técnica é uma representação visual do

capítulo 2 • 47
código a ser testado, chamado de Grafo de Fluxo de Controle ou apenas Grafo
do Programa.
O Grafo de Fluxo de Controle nada mais é que um conjunto de nós conec-
tados por arcos com setas que mostram sua direção – os nós representam um
bloco de comando (isso é, uma sequência atômica de linhas de código – se uma
for executada, todas as outras serão) e os arcos indicam a precedência ou a
transferência de controle (a sequência de execução do código fonte e seus des-
vios). A figura 2.9 exemplifica a representação em grafo de algumas estruturas
de programação. Se observarmos, um programa de computador é uma grande
combinação dessas estruturas (Maldonado & Fabbri, 2001).
Sequência IF While Repeat Case

Figura 2.9  –  Estruturas de programação e a representação em um grafo de fluxo de con-

trole. Adaptado de (Pressman, Engenharia de Software, 2006).

Sendo assim, o grafo de fluxo de controle do código apresentado na tabela

2.1 pode ser definido como o grafo apresentado na figura 2.9, na qual também
é detalhado que trecho do código cada nó representa.
Observando a figura 2.10, podemos entender que o método apresentado na
tabela 2.1 inicia com o chamado desse método e em seguida, as linhas de có-
digo 2, 3 e 4 são executadas sequencialmente – elas são atômicas, não há como
executar uma linha sem executar a outra – o que nos permite representar todas
em um único nó.
Ao executar a linha 4, uma decisão é feita – a execução tanto pode “entrar no
IF” e seguir para as linhas 5 e 6 quanto pode cair no “SENÃO” e executar as li-
nhas 7 e 8. Independentemente de “entrar ou não” n IF, o método termina com
a execução das linhas 9 e 10, representadas no último nó.

48 • capítulo 2
 Grafo de Fluxo de Controle Detalhamento da representação de cada nó

1 1 inteiro calculo hextraPercentual(real horasTrabalhadas) {

1 2 inteiro horasMes, horasExtras;
3 horasMes = 40;
4 SE (horasExtras > 40){

2 3 5 horasExtras = horasTrabalhadas - 40;

2 6 return (horasExtras *100)/horasMes;

4 3 7 SENÃO
8 return 0;

4 9 }
10}

Figura 2.10  –  Grafo de fluxo de controle do exemplo de código apresentado na tabela 2.1.

Sabendo como representar um programa que será testado por meio da

técnica caixa branca, estamos prontos para aprender os critérios de teste des-
sa técnica.
Os critérios de teste da técnica caixa branca são divididos em Teste Baseado
em Fluxo de Controle e Teste Baseado em Fluxo de Dados
Os principais critérios de teste caixa branca Baseado em Fluxo de Controle
são Teste de Comandos e Teste de Ramos.
•  Teste de Comandos ou Teste Todos os nós
Esse critério de teste define como requisito de teste que todos os comandos
dos programas sejam executados ao menos uma vez. Ou seja, se olharmos para
o grafo de fluxo e controle de um programa, temos que criar casos de teste de
forma que todos os nós sejam exercitados ao menos uma vez.
O desafio é criar o menos conjunto de casos de teste possível (para economi-
zar esforço de teste), mas que atinja esse critério.
Outro ponto importante para esse critério é que ao definir os casos de tes-
te o foco deve ser nos comandos que controlam as decisões do sistema, a fim
de direcionar os testes para que todos os nós sejam atingidos (Maldonado &
Fabbri, 2001).
Observando a figura 2.9, podemos entender que dois casos de testes são sufi-
cientes – um que faça a execução do programa caminhar para o nó 2 (ou seja, en-
trar no IF) e outra entrada que faça a execução do programa caminhar para o nó 3
(entrar no SENÃO). Independentemente de qual caminho seguir, o nó 4 sempre
será executado, então, não precisamos definir um caso de teste para esse nó.

capítulo 2 • 49
 Ao planejar esses dois casos de teste, podemos dizer que para o progra-
ma usado como exemplo, os requisitos do critério de teste de Comandos ou
como também é chamado, critério de teste Todos os nós, foram 100% atingidos
e que conseguimos 100% de cobertura do código, ou seja, todas as linhas fo-
ram executadas.
•  Teste de Ramos ou Todas as Arestas ou Todos os Arcos
Esse critério de teste define como requisito de teste que todas as condições
verdadeiras e falsas do programa sejam executadas. Em outras palavras, todos
os arcos (também chamados de arestas) do grafo de fluxo de controle devem ser
exercitados, mesmo que para isso, o mesmo nó seja executado mais de uma vez
(Maldonado & Fabbri, 2001).
Considerando o exemplo da figura 1
2.8, podemos considerar que ao estar
em conformidade com os requisitos
2 3
do critério Todos os Nós, nesse caso,
também conseguimos atingir os requi-
sitos do critério Teste de Ramos, tam-
4
bém conhecido como Todas as Arestas
ou Todos os Arcos. Porém, devemos
considerar que nosso exemplo é bem 5 6 7 8
simples – raramente conseguiremos
satisfazer requisitos de dois critérios
diferentes com o mesmo conjunto de 9
casos de teste. Por outro lado, isso dei-
xa evidente que ao estarem em confor- 10
midade com um critério, muitas vezes
com um pequeno conjunto a mais de 11
casos de teste, outros critérios podem
ser contemplados.
12
Para termos um entendimento
melhor desse critério, observe a figura
2.11, que apresenta um grafo de fluxo 13

de controle mais complexo – para fins

didáticos, não precisamos ter o código 14
fonte desse programa.
Figura 2.11  –  Exemplo de grafo de flu-
xo de controle com muitos arcos.

50 • capítulo 2
 Para sabermos o número de casos de teste necessários para atingir o cri-
tério de Ramos no programa representado na figura, basta identificarmos os
caminhos que farão com que cada arco seja executado ao menos uma vez –
sendo assim, cinco casos de teste nos ajudam a cumprir essa missão. Exemplo
de sequências:

CT 1) 1-2-4-5-14;
CT 2) 1-2-4-5-9-10-9-11-12-13-14
CT 3) 1-2-4-6-9-11-12-13-12-13-14
CT 4) 1-3-4-7-9-10-9-11-12-13-14
CT 5) 1-3-4-8-9-10-9-11-12-13-14

Faça um exercício você – tente definir suas próprias sequências de execu-

ção dos arcos analisando o grafo da figura 2.8. Possivelmente suas sequências
serão diferentes das apresentadas aqui, mas isso não quer dizer que estão er-
radas... Isso é esperado, pois quanto mais arestas e nós, mais possibilidade de
caminhos de execução terá.
Exemplo: o arco que sai do nó 5 e vai até o nó 14 pode ser executado por duas
sequências diferentes: 1-2-4-5-14 e também por meio da sequência 1-3-4-5-14.
Com esse exemplo, fica fácil entendermos mais um ponto importante – es-
tar em conformidade com os requisitos de algum critério de teste não garante
que todos os defeitos serão encontrados. Se utilizarmos a sequência 1-2-4-5-14,
podemos identificar um defeito que não seria executado com outra sequência
– por exemplo, pode existir um defeito de transferência de dados entre os nós
2-4-5 que não existe na sequência 3-4-5. Independentemente da sequência exe-
cutada, o requisito de teste do critério será atingido.
Podemos constatar que quanto mais exigente o critério, mais sequências
serão necessárias para estarem em conformidade com seu requisito e conse-
quentemente, as chances de identificar os defeitos aumentam. Por outro lado,
o esforço de teste também aumenta.
Na literatura podemos encontrar outros critérios de teste estrutural ba-
seados em fluxo de controle, como por exemplo, Teste de Caminho, Teste
de Caminho Base, Teste de Condição, Teste de Condição Múltipla e tantos
outros (Maldonado & Fabbri, 2001). A tendência é que um critério de teste

capítulo 2 • 51
complemente o outro e que o número de casos de teste aumente, a fim de exe-
cutar o maior número de código fonte possível.
Agora que vimos alguns critérios de teste baseado na execução do código,
ou seja, considerando, arcos e nós, muito provavelmente você pensou:
“Professor, quando tenho uma condicional (IF), geralmente meus códigos
não testam apenas uma condição – dentro do IF comumente nós usamos os
operadores lógico (AND, NAND, OR, XOR e NOT), como, por exemplo: “IF ((x >
a) || (y < b))”. Quando eu estiver fazendo um caso de teste para executar um nó
como o nó 1 da figura 2.12, como devo me planejar? Considero a verificação de
x ou de y?”
Caso você não tenha pensado nessa possibilidade, reflita sobre ela...
Obviamente nosso exemplo de condicional foi bem simples, mas você con-
corda que pode existir um defeito em uma parte da condicional e não na condi-
cional inteira? Por exemplo: pode ter um defeito em “y < b” e não em “x > a” – se
nosso caso de teste sempre executar apenas “x > a”, os critérios de teste basea-
dos em controle não irão ajudar a identificação desse defeito.
Para situações como essa temos os critérios baseados em Fluxo de Dados.
Esses critérios usam o “tipo de uso/ocorrência” de uma variável para auxi-
liar na definição de seus critérios. Existem três tipos de ocorrências: def, c-use e
p-use (Maldonado & Fabbri, 2001).

Indica definição, que é quando um valor está sendo atribuído a

DEF uma variável.

Indica uso computacional, que é quando a variável é usada na

C-USE avaliação de uma expressão ou comando de saída.

Indica uso predicativo, que é quando a variável é usada em um

P-USE predicado e consequentemente, afeta o fluxo de controle do
programa.

O principal critério de teste caixa branca Baseado em Fluxo de Dados é

Todos os Usos.

52 • capítulo 2
 •  Todos os usos
Esse critério de teste define como requisito de teste que todos os usos das
variáveis utilizadas em cada comando sejam executados. Para isso, devemos
identificar os usos de todas as variáveis do programa (método, algoritmo),
classificar o uso dessas ocorrências de acordo com def, c-use e p-use e então
construir, para cada variável, uma tabela especificando definição e uso (par
d-u), para que esses dados sejam usados na elaboração dos casos de teste
(figura 2.12).
Grafo de fluxo de Controle com
indicação das definições do algaritmo Definição dos pares

0 d1(x) d1(x) para u2(x)

d1(x) para u3(x)
d1(x) para u5(x)
1

Valores para os pares que

2 3 evercitem o critério
u2(x) u3(x)
0, 1, 2, 4, 5, 6
0, 1, 3, 4, 5
4

5
u5(x)
6

Figura 2.12  –  Exemplo do critério de Fluxos de Dados todos os usos.

Como vimos nessa seção, os critérios de teste nos ajudam a definir bons
casos de teste e a ter um critério de perda, visto que teste por exaustão quase
sempre é inviável de ser conduzido. Com casos de testes otimizados, temos a
chance de detectarmos mais defeitos, e assim, evitar com que eles sejam perce-
bidos pelos usuários finais.
Falando em defeito, depois de reportá-los de maneira adequada (como
vimos no capítulo 1), uma outra atividade deve ser conduzida – a depuração.
Vamos estudar um pouco para saber o que é isso?

capítulo 2 • 53
 CURIOSIDADE
Os nomes das nossas personagens no início do capítulo foram escolhidos como uma home-
nagem a duas grandes mulheres da história da computação. Augusta Ada King, ou Con-
dessa de Lovelace (Dezembro, 1815 – Novembro, 1852), foi uma matemática e escritora
inglesa, considerada a primeira programadora de toda a história, principalmente por ter escri-
to o primeiro algoritmo para ser processado por uma máquina, a máquina analítica de Charles
Babbage. Grace Murray Hopper (Dezembro, 1906 - Janeiro, 1992) foi uma analista de
sistemas da Marinha dos Estados Unidos, sendo entre outras coisas, responsável pela criação
da linguagem de programação Flow-Matic, que serviu como base para a criação da Linguagem
COBOL. Caso queira saber um pouco mais sobre essas e outras mulheres importantes na com-
putação, acesse: <http://www.cs.bris.ac.uk/admissions/what_is_cs/FamousWomen.html>.

2.6  Depuração

Depuração é considerada por muitos uma arte.

Pense na situação: você observa que o carregador do notebook de repente
parou de carregar a bateria do seu aparelho. Qual a causa?
Se nada elétrico funciona na casa, a causa pode estar na chave geral, no sis-
tema que traz energia até a sua casa, na tomada ou até mesmo no carregador.
Você olha para as casas ao redor da sua casa para observar se há energia nas
outras casas; você liga outros equipamentos elétricos para identificar se sua
casa está recebendo energia; você conecta outro equipamento na mesma toma-
da do carregador (ou faz um teste de corrente elétrica); você verifica se o cabo
do carregador está sem problemas visíveis (ou se há um indicativo de que ele
está recebendo energia, como aqueles pequenos leds)... Enfim, você identifica
o problema, pensa em hipóteses e testa o “ambiente” para identificar a causa
do problema.

54 • capítulo 2
 Na verdade, o que você acabou executando hipoteticamente no nosso exem-
plo é, de acordo com Bradley (Bradley, 1985), a aplicação do mais antigo méto-
do científico de investigação que é de localizar a origem do problema, levantar
e investigar hipóteses sobre a ocorrência do problema. Isso é depuração.
De forma geral podemos dizer que depurar é o processo de executar o
software e/ou percorrer o código fonte até entender o defeito previamente
encontrado e identificar o que causa o defeito para que a correção seja feita.
Sendo assim, temos uma constatação importante: a atividade de depuração é
consequência de um teste bem sucedido, afinal, se a depuração é necessária, é
porque um defeito foi encontrado durante os testes do sistema.
Pressman (Pressman, Engenharia de Software, 2006) menciona que a depu-
ração tem como objetivo encontrar e corrigir a causa de um erro de software,
sendo que o objetivo é alcançado por uma combinação de avaliação sistemáti-
ca, intuição e sorte.
De certa forma, o que Pressman (Pressman, Engenharia de Software, 2006)
nos diz é que ao depurar o software, o responsável precisa fazer uma “varre-
dura” sistemática no sistema/código fonte, não deixando nenhum detalhe de
lado, pois nesses detalhes pode estar a causa do erro; contar com sua intuição,
afinal, ao depurar um software geralmente tem-se muitos caminhos a serem
seguidos para executar uma mesma ação – a intuição de que um caminho pode
“dar mais problema que outro” pode fazer com que o depurador encontre a
causa do problema mais rápido. Em relação a sorte, podemos entender que
encontrar a causa do defeito, rápido, depende de um conjunto de escolhas ali-
nhadas - seguir o caminho de execução que levará ao erro, inserir os dados de
entrada que executará o erro e estar em situações de ambiente que levarão ao
erro – sendo assim, contar com a sorte não é um exagero (embora sempre te-
nhamos que lembrar que sorte é um conjunto de preparação e oportunidade).
Meyer (1979) propôs três abordagens para executar a depuração: força bru-
ta, rastreamento e eliminação de causa.

capítulo 2 • 55
 Nessa abordagem, o erro não é analisado sistematica-
mente para se descobrir a causa. Ao invés disso, tenta-se
utilizar o próprio computador para a descoberta, inserindo,
por exemplo, vários comandos de escrita no programa
(mensagens na tela com valores internamente utilizados),
FORÇA BRUTA listagem de memória, rastreadores de execução etc.
Obviamente, o volume de informação produzido por força
bruta pode ajudar a encontrar o erro, mas também pode
exigir um esforço considerável para sua análise e ainda
assim, não identificar o problema.

Nessa abordagem a busca pelo problema inicia-se no local

em que o sintoma foi detectado e rastreia-se o software
RASTREAMENTO (comumente o código fonte) para trás, manualmente, até
(CONHECIDO que o local da causa seja encontrado. Embora seja muito
COMO efetiva à medida que o software cresce, o número de cami-
BACKTRACKING) nhos potenciais para trás também cresce e esta aborda-
gem se torna inviável.

Nessa abordagem a pessoa (ou o time) que está depurando

o sistema supõe uma causa e casos de teste são elaborados
para comprovar ou refutar essa hipótese/suposição. A supo-
ELIMINAÇÃO DE sição da causa geralmente segue o conceito de particiona-
CAUSA mento binário – os dados do defeito são particionados a fim
de isolar causas em potencial e a depuração é feita a fim de
confirmar ou não cada causa em potencial (hipótese).

Independentemente da abordagem seguida, como sempre, é importante

entendermos o processo a ser seguido.
Na figura 2.13 podemos observar o processo de depuração apresentado por
Pressman (Pressman, Engenharia de Software, 2006). Nesse processo entende-
mos que os testes do sistema são executados (casos de teste) e os resultados são
obtidos – no caso, os resultados são os defeitos encontrados. Para cada defeito
reportado o sistema deve ser depurado.

56 • capítulo 2
 Resultados
Casos
de
Teste
Testes
adicionais Causas
suspeitas
Testes de
regressão Depuração

Correções Causas
identificadas

Figura 2.13  –  O processo de depuração (Pressman, Engenharia de Software, 2006)

Quando a causa (ou as causas) é identificada, o software é corrigido – ao fim

de todas as correções, uma nova versão do sistema deve ser gerada e testes de
regressão são executados a fim de identificar se ao eliminar um defeito, outros
defeitos foram gerados.
Quando a causa (ou as causas) do defeito não é identificada, causas suspei-
tas são levantadas, novos casos de teste são gerados e executados (abordagem
– Eliminação de causa). Nesse ponto, voltamos ao início do processo, pois os
novos casos de teste devem gerar novos defeitos que, nesse caso, podem ser
derivações do defeito reportado inicialmente.
Por fim, não podemos nos esquecer de um fator importante – observe que
embora o computador possa ajudar no processo de depuração – vide a abor-
dagem força bruta – a competência de quem está depurando o software é im-
prescindível. No entanto, se unirmos a competência de uma ou mais pessoas,
as chances de sucesso (não só na atividade de depuração) são grandes, afinal,
como o dito popular diz, “duas cabeças juntas pensam melhor que uma”!.
Pontos de vistas diferentes aliados a experiências diferentes permitem que os
erros sejam mais rapidamente encontrados e a atividade de depuração possa
ser feita em menos tempo.

2.7  Teste de ambiente web

Até esse momento foram apresentados conceitos, técnicas e critérios de tes-

te, mas não comentamos em qual tipo de software ou ambiente de software
eles deveriam ser aplicados. Na verdade, tudo que foi apresentado é a essência
de teste de software e são válidas para todos os tipos e ambientes. No entanto,

capítulo 2 • 57
como muitas coisas na vida, o contexto é importante. Sendo assim, há itens im-
portantes que temos que ressaltar quando o software a ser testado é web.
Considerando que a maioria dos sistemas hoje em dia depende da web, é
essencial que você conheça e entenda alguns testes importantes que devem
ser feitos nesse ambiente. Além disso, é importante pensarmos que embora
tenham características específicas, essas estratégias de teste que serão apre-
sentadas a seguir também se aplicam em aplicativos web e aplicativos mobile.
Pressman (Pressman, Engenharia de Software, 2006) salienta estratégias de
teste que devem ser consideradas no ambiente web; teste de conteúdo, teste de
interface, teste de navegação, teste de componente, teste de configuração, de
segurança e de desempenho.

Tem como objetivo encontrar defeitos no conteúdo, como se fosse uma

CONTEÚDO
TESTE DE

revisão de um documento escrito. De fato, sistemas que envolvem muito

conteúdo, em muitos casos contratam não apenas especialistas em
tecnologia, mas especialistas em língua portuguesa (ou outro idioma), mas
encontrar erros gramaticais, de consistência de conteúdo, de imagens etc.

Tem como objetivo navegar entre os componentes de interface e validar

INTERFACE
TESTE DE

a estética do sistema com o usuário, sempre que possível. Dessa forma, é

possível identificar problemas de interação assim como inconsistências ou
ambiguidades na interface.
NAVEGAÇÃO

Tem como objetivo identificar defeitos, problemas que possam existir na

TESTE DE

navegação do usuário dentre as opções do sistema. Uma possibilidade é

usar o diagrama de casos de uso para exercitar cada cenário previsto na
fase de projeto como parte da especificação do software.

58 • capítulo 2
 Tem como objetivo, como o próprio nome diz, encontrar defeitos nos
componentes de conteúdo e funcionais (os que implementam as funcio-
nalidades do sistema) do software. Nesse contexto, a unidade do sistema
do ponto de vista de conteúdo é uma página web, que na verdade, é um
conjunto de conteúdo textual ou de imagem, itens de navegação (menu,
TESTE DE COMPONENTE

botões, links) e itens de processamento (formulários, applets etc.). Outra

unidade considerada no teste de componente do ponto de vista de arqui-
tetura é um componente que oferece um serviço ao usuário final, como
um relatório, ou a um componente de infraestrutura que permite que o
software seja executado, com banco de dados, um WebService etc. De
certa forma, a medida que os testes de componente são realizados, testes
de integração também são feitos, para identificar se há defeitos quando
todos os componentes são exercitados em conjunto. Obviamente o teste
de integração depende da arquitetura que foi planejada, para que a equipe
de teste possa identificar corretamente todos os componentes a serem
considerados.

Tem como objetivo é identificar os defeitos do software em um ambiente

CONFIGURAÇÃO

particular, geralmente o ambiente do cliente, como por exemplo, num

TESTE DE

servidor de aplicação específico. Comumente, cria-se uma matriz para

mapear os possíveis sistemas operacionais, navegadores, plataformas de
hardware e protocolos de comunicação e então o sistema é submetidos a
testes considerando todas as variáveis.
SEGURANÇA

Tem como objetivo, como o próprio nome diz, identificar defeitos em rela-
TESTE DE

ção a segurança dos componentes do sistema. Os testes tentam identi-

ficar pontos vulneráveis para que essas quebras de segurança, quando
existirem, sejam corrigidas e o sistema se torne mais seguro.

capítulo 2 • 59
 Tem como objetivo identificar defeitos em diversos aspectos relacionados
DESEMPENHO ao desempenho do sistema, como tempo de respostas das requisições do
usuário e a corretude das respostas, quando o sistema é utilizado por um
TESTE DE

alto número de usuários; como a análise do componente que prejudica

o desempenho do sistema e aspecto como o impacto que problemas de
desempenho tem no sistema como um todo (afinal, mesmo que um ou
alguns componentes apresentem tempos de respostas elevados, isso não
obrigatoriamente prejudica o desempenho do sistema como um todo).

Lembrando, também, dos conteúdos que aprendemos nas seções anterio-

res, vale lembra que a técnica de teste para esses testes no ambiente web podem
ser tanto a técnica caixa preta quanto caixa branca. Claro que em alguns tipos
de teste uma técnica é mais adequada que a outra - por exemplo, teste de in-
terface é essencialmente um teste caixa preta (funcional). No entanto, o mais
importante de tudo é que você, aluno, saiba desses aspectos importante que de-
vem ser considerados no teste de sistemas web e lembre-se deles não só no mo-
mento de testar, mas também no momento de projetar e desenvolver o sistema.

ATIVIDADES
01. Considere o código Pascal e a definição do algoritmo, ambos apresentados abaixo. Com
o intuito de exercitar o que aprendemos sobre os testes caixa preta e caixa branca, realize
os exercícios a) e b).
Especificação
O algoritmo deve receber como entrada três valores inteiros positivos que são interpreta-
dos como o comprimento dos lados de um triângulo. Por fim, o algoritmo deve informar se o
triângulo definido pelos três valores informados é isósceles, escaleno ou equilátero.

Código fonte
program triangulo;
uses crt;
var
lado1, lado2, lado3: integer;
begin
clrscr;

60 • capítulo 2
 writeln ('digite o primeiro lado : ');
readln (lado1);
writeln ('digite o segundo lado : ');
readln (lado2);
writeln ('digite o terceiro lado : ');
readln (lado3);
//verificar se é possivel formar triangulo;
if (lado1 < (lado2+lado3)) and (lado2<(lado1+lado3))and (la-
do3<(lado1+lado2))then
begin //se for possivel:
//verificar se é equilatero
if ((lado1 = lado2) and (lado2 = lado3)) then
writeln('triangulo equilatero')
//verificar se eh isoceles
else
if ((lado1 = lado2) or (lado1 = lado3)or
(lado2 = lado3)) then
writeln('triangulo isoceles')
else
// verificar se é triangulo escaleno
writeln('triangulo escaleno');
end
else //nao foi possivel formar triangulo
writeln('os tres lados nao formam um triangulo');
end
end
readkey;
end.

a) Defina um conjunto de casos de teste que você julgue adequado para testar este pro-
grama levando em consideração o uso do critério Particionamento de Equivalência, que
como sabemos, faz parte da técnica caixa preta (ou funcional). Para te ajudar, defina
primeiro as classes de equivalência e depois o conjunto de casos de teste.

capítulo 2 • 61
b) Defina um conjunto de casos de teste que você julgue adequado para testar este pro-
grama levando em consideração o uso do critério Todos os Ramos, que como sabemos,
faz parte da técnica caixa branca (ou estrutural). Para te ajudar, desenhe primeiro o
grafo de fluxo de controle e depois, especifique os casos de testes que cobrem todos
os ramos do grafo.

02. Recuperando o que aprendemos na seção sobre depuração e utilizando conceitos de

desenvolvimento ágil de software, reflita: depuração e programação em pares são técnicas
muito diferentes? Quais os aspectos que elas são parecidas e quais elas são diferentes?

03. Pensando nos aspectos de teste, importantes para o ambiente web, liste um defeito
de software para cada tipo de teste feito em ambientes web (teste de conteúdo, teste de
interface, teste de navegação, teste de componente, teste de configuração, de segurança
e de desempenho). Pode ser um defeito que você já ouviu falar ou um defeito que você já
identificou / presenciou nos sistemas que você utiliza no seu cotidiano.

REFLEXÃO
Parabéns, você conseguiu chegar até o final do nosso segundo capítulo. Aqui você já deve
estar sabendo o que é teste de software, a importância desse tipo de atividade no processo
de desenvolvimento, as técnicas e os critérios de teste de cada técnica de software e tam-
bém como as revisões formais, por exemplo, inspeção, podem ajudar na atividade de teste e
na qualidade do software como um todo.
Também já deve estar sabendo o que é depuração e como essa atividade é importante
no contexto de teste. Além disso, você já sabe aspectos importantes que devem ser conside-
rados quando testamos sistemas em ambiente web.
Gostaríamos de recuperar aqui uma discussão que foi realizada anteriormente neste
capítulo sobre a importância de se testar software, seja ele qual tamanho for. Lembra-se das
nossas personagens apresentadas logo no início do capítulo: Augusta e Graça?
Cada personagem foi apresentada em uma situação diferente, e por que não dizer em
épocas da vida diferente – enquanto Augusta se preocupava com a implementação de al-
goritmos de ordenação como parte de exercícios da faculdade, Graça se preocupava com
algoritmos que iam compor um sistema ERP, muito grande, com muitos clientes, como par-
te do trabalho de desenvolvedora de software. Apesar das diferenças, uma lição devemos
aprender com elas: a importância de testar e a importância de conhecer a teoria sobre testes

62 • capítulo 2
para que possamos escolher a técnica e o critério certo para cada situação, cada projeto,
cada software e cada componente.
Por mais que na prática nós não tenhamos o papel de testadores ou que na empresa que
trabalhamos não tenha um critério de teste a ser seguido (o que é muito comum), conhecer e
entender esses conceitos são importantes, pois nos farão pensar neles mesmo que de forma
inconsciente no momento de definir um caso de teste (caso nosso papel seja de analista de
teste/testador) ou no momento de implementar um método, um algoritmo, uma arquitetura,
uma interface de software e assim por diante.
Querido aluno, tenha certeza que esses conceitos de teste que estudamos nesse capítu-
lo fará de você um profissional melhor, que insere menos defeitos no software que desenvol-
ve e que sabe a maneira correta de testá-lo.
Agora, estamos prontos para estudar sobre as estratégias de teste.

LEITURA
Há muitos livros bons sobre teste de software, tanto nacionais quanto importados. Além
disso, livros de Engenharia de Software costumam abordar esse assunto, mesmo que de
forma mais abrangente. Uma leitura bastante interessante que fala sobre teste de software
de forma teórica, porém descomplicada, é o livro “Introdução ao Teste de Software”, de
Márcio Delamaro, José Carlos Maldonado e Mario Jino, todos doutores docentes de reno-
madas universidades. Outra leitura muito interessante para quem pretende se aprofundar
ainda mais no fantástico mundo dos testes é o livro “Base de conhecimento em Teste de
Software” doa autores Aderson Bastos, Emerson Rios, Ricardo Cristalli e Trayahú Moreira,
que tem um viés prático da indústria de software e é um bom material para interessados em
certificações da área. Outro livro que pode ser muito útil para adquirir conhecimento sobre
casos de teste é o livro “How to Break Software: A Practical Guide to Testing” de James
Whittaker, publicado em 2002 pela editora Pearson.

REFERÊNCIAS BIBLIOGRÁFICAS
Bradley, J. (1985). The Science and Art of Debugging. Computerworld.
Fabbri, S. (2009). Atividades de V&V. São Carlos: notas de aula.
Firesmith, D. (11 de 11 de 2013). Using V Models for Testing. Fonte: SEI Blog: <https://insights.sei.
cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html>

capítulo 2 • 63
ISO/IEC/IEEE 29119-4. (2015). ISO/IEC/IEEE 29119-4:2015: Software and systems engineering
-- Software testing -- Part 4: Test techniques. New York: IEEE.
Maldonado, J., & Fabbri, S. (2001). Teste de software. In: A. Rocha, J. Maldonado, & K. Weber,
Qualidade de Software: teoria e prática (pp. 73-84). São Paulo: Prentice Hall.
Myers, G. (2004). Pressman (Pressman, Engenharia de Software, 2006) . New Jersey: John Wiley &
Sons.
Pressman, R. (2006). Engenharia de Software. São Paulo: McGraw-Hill.
Pressman, R. (2011). Engenharia de Software - Uma abordagem profissional. São Paulo: McGraw
Hill - ARTMED.
Sauer, C., JEFFERY, , D., Land., L., & YETTON, P. (2000). The effecticveness of software
development technical review: a behaviorally motivated program of research. IEEE Transactions on
Software Engineering, 1-14.
Travassos, G., & Kalinowski , A. (2004). A computational framework for supporting software
inspections. International Conference on Automated Software Engineering-ASE.

64 • capítulo 2
 3
Teste na
implantação do
sistema
3.  Teste na implantação do sistema
Olá aluno! Que bom que seus estudos sobre teste de software estão progredin-
do bem. É muito bom tê-lo no terceiro capítulo – metade dos capítulos já se
transformou em conhecimento.
No capítulo anterior discutimos sobre técnicas de teste como caixa branca
e caixa preta e seus critérios, além de vermos tópicos importantes como depu-
ração e tipos de teste que devem receber uma atenção especial quando falamos
de sistemas web.
Nesse capítulo vamos contextualizar melhor quando esses testes são execu-
tados – vamos falar de algumas estratégias de teste importantes e a aplicação
delas durante a implantação do sistema. Temos certeza que esse conteúdo será
de extrema importância para sua vida acadêmica e principalmente para sua
carreira profissional.

OBJETIVOS
•  Aprender o que é teste de unidade;
•  Aprender o que é teste de integração;
•  Aprender o que é teste de validação;
•  Aprender o que é teste de sistema e outras estratégias que podem ser executadas nes-
se contexto;
•  Aprender o que é teste de migração.

3.1  Estratégia de teste

Até agora vimos sobre técnicas de teste e critérios de teste. Esses critérios po-
dem nos ajudar a definir o escopo do teste e definir quais casos de teste devem
ser criados. Além disso, também vimos alguns testes importantes que devem
ser feitos em sistemas de ambiente web. Agora, nós estamos prontos para en-
tender sobre estratégia de teste e aprender como podemos planejar as ativida-
des de teste durante o desenvolvimento do sistema.
Na literatura sobre testes podemos encontrar diferentes estratégias de
teste, assim como encontramos diferentes modelos de desenvolvimento. O

66 • capítulo 3
importante, como sempre, é entendermos o modelo e escolher o mais adequa-
do à nossa realidade ou saber adaptá-lo para atingir nosso objetivo.
Um dos modelos básicos, que serviu de inspiração para muitos autores pro-
porem modelos mais detalhados e que ilustra muito bem a estratégia básica de
teste e como ela adere a um processo de desenvolvimento é o apresentado por
Pressman (PRESSMAN, 2006) e está ilustrado na figura 3.1.
Nesse modelo, o processo de engenharia de software básico é apresentado
como um espiral, que engloba também as estratégias de teste que podem ser
utilizadas em cada atividade do processo de engenharia.
De acordo com (PRESSMAN, 2006), ao desenvolver um software é como se
nós fossemos entrando nesse espiral.
Na engenharia de sistemas definimos o papel do software, para que e para
quem ele será útil e também o escopo inicial. Com isso, podemos seguir para
a fase de análise de requisitos, a fim de elicitar, especificar e refinar o que o
software deve oferecer para o cliente, o que não deve oferecer e até mesmo os
critérios de aceitação de cada funcionalidade. Com esses artefatos, partimos
para a fase de projeto que é nada mais que pensar, antes de transformar em
código, como o software deverá ser construído. Com o projeto pronto, é hora
de codificar.
Aí você comenta: “OK professor, essas atividades de desenvolvimento eu já
conheço. E as atividades de teste?”.

Teste de sistemas
Teste de validação
Teste de integração
Teste de unidade

Código

Projeto
Requisitos
Engenharias de Sistemas

Figura 3.1  –  Estratégia de teste (PRESSMAN, 2006).

Pois bem, se pensarmos que a atividade de teste deve acompanhar todo

o desenvolvimento do software, como aprendemos no capítulo 1, é natural

capítulo 3 • 67
pensarmos que cada artefato gerado durante o desenvolvimento do software dê
origem ou sirva de base para executarmos diferentes estratégias de teste.
Olhando novamente na figura 3.1, conseguimos fazer um paralelo de cada
atividade de desenvolvimento com as estratégias básicas de teste. Porém, para
os testes, ao contrário de irmos caminhando para o centro do espiral, vamos
caminhando para sair do espiral.
Com o sistema codificado, ou seja, com o código fonte, podemos criar os
testes unitários. Com as “unidades” testadas, podemos executar testes de inte-
gração, ou seja, testar um conjunto de unidades e verificar se juntas elas funcio-
nam da forma como deveriam e foram arquitetadas. Com o conjunto de unida-
des funcionando e continuando a caminhada para fora do espiral, executamos
o teste de validação, com o intuito de verificar se os requisitos previamente defi-
nidos estão sendo satisfeitos no sistema desenvolvido. Por fim, executamos tes-
tes no sistema como um todo, a fim de verificar se o software e todos os outros
elementos do sistema funcionam como o esperado e atingem o objetivo final.
Devemos ser críticos o bastante e entender que essa representação do
Pressman é genérica, porém, é facilmente aplicada em qualquer modelo de
processo de desenvolvimento. Se usarmos o modelo Cascata, iremos “cami-
nhar” pelo espiral uma única vez, se usarmos modelos evolucionários ou até
mesmo modelos ágeis, iremos “caminhar” nesse espiral inúmeras vezes, quan-
tas forem necessárias até finalizar o projeto. O importante é entender que cada
fase do projeto, cada artefato produzido, servirá de base para diferentes estra-
tégias de teste.
E temos que executar todos estes testes? E qual a diferença entre eles?
Idealmente, sim – cada estratégia de teste tem sua devida importância. No
entanto, sabemos que recurso, esforço e tempo são variáveis extremamente im-
portantes em qualquer projeto. Sendo assim, cabe ao time de desenvolvimento,
quando não for possível aplicar todas as estratégias, decidir qual a mais crítica
e qual o time tem mais capacidade em realizar.
A diferença entre essas estratégias de teste nós iremos ver agora, uma a uma,
e isso permitirá que você entenda melhor a importância de cada uma delas!

CURIOSIDADE
Está interessado em critérios de aceitação, mencionado na Seção 3.2? Cada vez mais os
critérios de aceitação estão sendo utilizados para ajudar todo o time envolvido no desenvolvi-
mento do software. Por estar relacionado com métodos ágeis, seu uso sempre é sugerido na

68 • capítulo 3
especificação das estórias de usuário. No entanto, mesmo que seu ambiente de trabalho não
use estórias de usuário, vale muito a pena pensar em critérios de aceitação – eles serão ex-
tremamente úteis na especificação dos testes. Leia mais em: <http://www.strongandagile.
co.uk/index.php/what-makes-a-good-user-story/>.

CONEXÃO
Outra representação do modelo de processo de desenvolvimento que representa as estraté-
gias de teste é o modelo V (V-Model), apresentado em diferentes versões, por diferentes au-
tores. Assim como todos os modelos, há vantagens e desvantagens e sempre caberá a nós,
profissionais de desenvolvimento de software, adaptarmos para a nossa realidade. O legal de
ler sobre esse modelo é que há uma representação com enfoque nas diversas estratégias de
teste e que fica bem explícito qual artefato é tido como base para cada teste. Fica como dica
a leitura desse blog do Software Engineering Institute (SEI) da Carnegie Mellon University.
<https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html>.

3.2  Teste de Unidade

De acordo com (PRESSMAN, 2006), o teste de unidade dedica esforço de teste

para identificar defeitos na menor unidade do sistema, que pode ser um com-
ponente, um módulo ou, considerando o paradigma orientado a objetivo, que é
o mais comum hoje em dia, uma classe ou um método.
A complexidade dos testes de unidade (ou testes unitários como também
são chamados), assim como os defeitos revelados é limitada pelo escopo bem
definido da unidade.
De acordo com Myers (MYERS, 2004), as vantagens de se realizar testes uni-
tários são:
•  Os testes unitários são uma forma de gerenciar de maneira mais fácil os
elementos de testes (casos de teste, resultado etc.), uma vez que a atenção é
focada inicialmente em unidades menores do programa;
•  Os testes unitários facilitam a tarefa de depuração (que vimos no capítulo
2), uma vez que, quando um defeito for encontrado, o escopo de depuração é
menor, afinal, sabemos em qual unidade ele foi encontrado;
•  Permite que a atividade de teste seja feita de forma paralela, pois várias
unidades podem ser testadas simultaneamente.

capítulo 3 • 69
 Além de dar enfoque à lógica interna da unidade, esse tipo de teste é feito
para garantir que a informação (ou seja, os dados) flui de outras unidades para
a unidade sob teste e da unidade testada para outras, garantindo que aquela
pequena parte do sistema cumpra seu papel sem defeitos.
Como em outras situações, a opção de usar a técnica funcional ou estrutural
depende dos artefatos que o testador tem em mãos. No entanto, o teste unitá-
rio, por considerar a menor unidade do sistema, está intimamente relaciona-
do à fase de codificação do software e por isso, pensar em critérios estruturais
pode ser mais fácil nesse momento.
Além disso, há técnicas de desenvolvimento como o TDD (Test Driven
Development) (BECK, 2003) (SOMMERVILLE, 2011) que prevê que os testes se-
jam programados antes mesmo da unidade a ser testada.
Você deve estar pensando: “Mas professor, um método ou uma classe, por
si só, não faz nada num sistema, um software é o relacionamento, é a troca de
mensagens entre muitos métodos, muitos objetos. Como vou testar essa uni-
dade tão pequena?”.
Se você pensou assim, você está coberto de razão. Quando vamos criar tes-
tes unitários, comumente precisamos criar pseudocontroladores, também co-
nhecidos como drivers, e pseudocontrolados, também conhecidos como stubs.
(PRESSMAN, 2006).
O driver cumpre o papel da unidade que “chama” a unidade a ser testada.
Já o stub faz o papel das outras unidades que são “chamadas” pela nossa uni-
dade. Obviamente que como o intuito não é testar essas unidades adjacentes,
elas são desenvolvidas apenas para dar suporte ao teste. Comumente o driver
nada mais é que um programa principal que recebe os dados do caso de teste
repassa esses dados para a unidade a ser testada e imprime ou registra dados
importante para o teste. De forma similar, comumente os stubs usam apenas a
assinatura igual aos da unidade que estão sendo simuladas e fazem o mínimo
de manipulação dos dados, suficiente apenas para realizar o teste de algum re-
torno, por exemplo.
Por mais que drivers e stubs sejam unidades relativamente simples, o custo
de desenvolvimento delas deve ser considerado no planejamento dos testes.
Na figura 3.2 podemos visualizar melhor o papel do driver e do stub no con-
texto de testes unitários. Além disso, no capítulo 5, você aprenderá sobre como
criar de forma automatizada testes unitários.

70 • capítulo 3
 Driver Interface
Estrutura de dados
Condições-limite
Caminhos independentes
Caminhos de manipulaçãos de erros
Unidade a ser
testada
Casos
de
Stubs Stubs teste

Figura 3.2  –  Ambiente de teste de unidade. Adaptado de PRESSMAN, 2006.

CONEXÃO
Você sabia que você pode automatizar os testes de unidade? Não? Pois é, pode sim. Teremos
outras oportunidades para falar sobre isto na disciplina, mas por ora, é legal você já iniciar al-
gum estudo relacionado a isso, principalmente por que assim o que você acabou de aprender
sobre teste unitário poderá ser melhor consolidado.
A dica que deixo aqui é relacionada ao JUnit, que é uma ferramenta para automatizar o teste
unitário para programas feitos em Java.
Neste link <http://junit.org/junit4/>, você encontrará algumas informações interessan-
tes sobre JUnit. Aqui também: <https://pt.wikipedia.org/wiki/JUnit>.

3.3  Teste de Integração

Nesse momento, já sabemos como testar cada unidade do sistema e sabemos as

vantagens que testes unitários oferecem. No entanto, você deve estar pensando:
“Professor, eu consigo garantir que encontrei defeitos em cada unidade e
que após esses defeitos serem corrigidos, elas funcionarão como o esperado.
No entanto, eu não sei se essas unidades, juntas, funcionaram corretamente. E
agora? Eu deveria garantir isso testando apenas as unidades?”
Pensamento correto. Não, não podemos garantir que se as unidades funcio-
nam corretamente, juntas, elas também funcionarão corretamente.

capítulo 3 • 71
 Pense num time de futebol (figura

© PIXABAY.COM
3.3): se escalarmos apenas craques e 1

colocarmos todos para jogarem jun-

2 3 4 5
tos, dificilmente no primeiro jogo o
time irá ganhar. Precisamos de treino
para garantir que o conjunto de cra- 9 8 7 6

ques jogue de maneira orquestrada e 10 11

obtenha a vitória, não é mesmo?

Cada jogador precisa estar em con-
11

dições físicas e técnicas boas para que

o treino possa ocorrer, que o treinador 10
9 8 7
6

possa verificar qual a posição de cada

um e como o jogo flui com o arranjo 5 2
4 3

do time. Melhorias são identificadas,

cada jogador que precisa de melhorias 1

é treinado e então, o time pode funcio-

nar da forma esperada.
Figura 3.3 – Jogo de Futebol. .

Um sistema pode funcionar da mesma maneira... As unidades estando li-

vres de defeito não garantem que o sistema esteja livre de defeitos. O sistema,
de certa forma, é a integração de todas as unidades e assim, precisamos testar
essa integração.
Para Pressman (PRESSMAN, 2006) o teste de integração é uma maneira sis-
temática de construir a arquitetura do software e identificar defeitos associa-
dos às interfaces (interface, aqui, se refere a forma como as unidades se comu-
nicam, e não a interface gráfica do sistema).
Myers (MYERS, 2004) apresenta duas formas de teste de integração. Uma
forma é a conhecida como integração big-bang, que é testar os módulos/uni-
dades de forma independente e depois combinar todas as unidades, compor
o programa e então testar a integração entre eles. Outra forma é a integração
incremental, que combina um módulo previamente testado de forma unitária
com um conjunto de módulos no qual o teste de integração já foi feito. Após
testar esse novo conjunto, um outro módulo é agregado e assim por diante, até
compor o sistema por completo.

72 • capítulo 3
 A integração big-bang pode até funcionar em alguns casos, mas sua princi-
pal desvantagem é a dificuldade em isolar em qual unidade está o defeito en-
contrado na integração. Já na integração incremental, como podemos imagi-
nar, essa identificação fica mais fácil de ser feita, pois as unidades vão sendo
acrescentadas uma de cada vez.
Optando em realizar teste de integração incremental, temos duas aborda-
gens: uma é a abordagem de teste incremental top-down (ou integração des-
cendente) e a outra abordagem é teste incremental bottom-up (ou integra-
ção ascendente).
Na abordagem top-down a ideia é escolher uma unidade principal e ir adi-
cionando unidades “abaixo” dela. Essa unidade principal pode ser definida
com base no conhecimento que se tem sobre o sistema e suas unidades – de
certa forma, essa unidade fará o papel de driver (como vimos na seção anterior),
que é a unidade/módulo principal na qual as próximas unidades serão integra-
das. Para fazer essa integração e de certa forma ir construindo a árvore que é o
sistema (como vemos em estrutura de dados) pode-se optar em caminhar em
largura ou profundidade. (PRESSMAN, 2006) (SOMMERVILLE, 2011)
Vamos observar a figura 3.4.
O teste de integração usando a abordagem top-down nos pede para escolher
qual unidade/módulo será o U1. Feito isso, escolhemos quem será U2 e então, tes-
tes para identificar se essas unidades funcionam da maneira esperada, são execu-
tados. Se optarmos em caminhar em largura, escolhemos quem será U3. Se optar-
mos em caminhar em profundidade, escolhemos quem será U4. Da mesma forma,
testes para garantir que U1 e U3 (integração primeiro em largura) ou U2 e U4 (in-
tegração primeira em profundidade) funcionam da maneira esperada, devem ser
executados. E assim, as unidades/módulos vão sendo integrados e testados.

U1

U2 U3

U4 U5 U6

U7

Figura 3.4  –  Integração top-down. Adaptado de PRESSMAN, 2006.

capítulo 3 • 73
 Na abordagem de integração bottom-up a ideia é testar a integração de ma-
neira oposta, ou seja, de baixo para cima. Para isso, é necessário identificar mó-
dulos ou conjunto de módulos/unidades que sejam altamente dependentes e
com isso definir o que é chamado de clusters, construções ou aglomerados.
Se lembrarmos do que vimos na seção anterior, figura 3.2, sobre drivers e
stubs, podemos inferir que na abordagem bottom-up, não usamos ou pouco
usamos os stubs (unidades pseudocontroladas), por outro lado, para exer-
citar os clusters, precisamos de drivers (unidades pseudocontroladoras).
(PRESSMAN, 2006)
Para entender melhor, vamos observar a figura 3.5, na qual temos 3 clusters
definidos. Como podemos ver, eles são um conjunto de unidades atômicas, ou
seja, não funciona isoladamente, o que é muito comum nas unidades mais bá-
sicas, módulos abaixo na arquitetura de integração do sistema – por exemplo,
o cadastro de produto em um sistema de loja não funciona sem o cadastro de
tipo de produto.

U1

U2 U3

D1 D2 D3

U U U U U U
Cluster 2
U U7 U U
Cluster 1 Cluster 3

Figura 3.5  –  Integração bottom-up. Adaptado de PRESSMAN, 2006.

Para testar o cluster 1, precisamos de uma unidade para “exercitar” essas

unidades aglomeradas. Sendo assim, definimos um driver (D1). Executamos os
casos de teste e assim, garantimos que defeitos foram encontrados no cluster.
O mesmo se repete com os clusters 2 e 3 e seus respectivos drivers, D2 e D3.
Assim que esses testes são feitos, os driver são removidos e o cluster se in-
tegra com a unidade acima (U2), que se torna parte do cluster. Esse processo se
repete até que a unidade central (provavelmente a que daria início aos testes
na abordagem top-down) se integre a todos os testes de integração que tenham
sido executados.

74 • capítulo 3
 Quando falamos em teste de integração, outra estratégia de teste entra em
pauta: teste de regressão.
Pense comigo, observando a figura 3.5: “Será que não corre o risco de um
trecho de código fonte que está em U1 alcançar (ou exercitar) um outro trecho
de código fonte com defeito que está no cluster 1?” Como não executamos teste
por exaustão (ou seja, não testamos 100% de todas as possibilidades), pode ser
possível que ao testar uma funcionalidade de U1 uma funcionalidade do que
está no cluster 1 se comporte de maneira não esperada. Obviamente esse risco
também existe na abordagem top-down.
Uma forma de identificar esses defeitos é executar testes de regressão. De
acordo com Pressman (PRESSMAN, 2006), teste de regressão é a reexecução de
testes que já foram executados anteriormente com o objetivo de garantir que as
novas integrações não tenham efeitos indesejados – ou seja, defeitos.
De forma mais genérica, Pressman (PRESSMAN, 2006), explica que a cada
nova integração, obviamente o sistema é modificado e dessa forma novos flu-
xos de dados surgem, novas opções de entrada e saída de dados são inseridas e
defeitos podem ser alcançados em unidades que antes funcionavam da manei-
ra esperada. Podemos entender que esse problema também acontece quando
há manutenção do sistema.
Os testes de integração podem ser executados manualmente (principal-
mente quando for caixa preta) ou de forma automatizada, como vamos ver no
capítulo 5, como sugere Sommerville (SOMMERVILLE, 2011), o que faz a equi-
pe de teste ganhar tempo.
Pressman (PRESSMAN, 2006), apresenta três classes de testes de integração
que, de certa forma, ajudam na escolha de quais testes irão compor o ciclo de
regressão. Vamos a eles:
1. Um conjunto representativo de casos de teste que representam/exerci-
tam todas as funcionalidades do sistema;
2. Casos de teste que testam especificamente partes que podem ser afeta-
das com as mudanças e/ou adição de novas unidades;
3. Casos de teste que possuem como foco testar a nova unidade ou unida-
de modificada.

Definir o conjunto mínimo suficiente de casos de testes que irão compor

os testes de regressão é uma tarefa difícil. Claro que a vontade é que, a cada
integração, todos os testes executados anteriormente sejam executados, no

capítulo 3 • 75
entanto, isso tomaria muito tempo e também dificultaria o isolamento do de-
feito e consequentemente, a depuração. As classes apresentadas no parágrafo
anterior podem ajudar, mas a capacidade de entendimento do sistema dos tes-
tadores é algo crucial nesse momento.
De qualquer forma, essa ainda não é a última oportunidade de identificar
defeitos no sistema durantes os testes. Vamos continuar a leitura porque ao
finalizar os testes de integração, passamos para outra estratégia de teste: teste
de validação.

3.4  Teste de validação

Após testar as unidades e a integração das unidades/módulos, podemos pensar

que o sistema está pronto para ser utilizado. Nesse ponto, lembramos de uma
figura de extrema importância para um sistema: o usuário.
O usuário é a pessoa que irá usufruir de todos os benefícios do sistema e
que irá “sentir na pele” a qualidade que o sistema tem - ou seja, se deixarmos
de identificar os defeitos dos testes de unidade e de integração, possivelmente
esse usuário irá sofrer com isso.
No entanto, não podemos garantir que, após essas duas estratégias de tes-
tes serem aplicadas, todos os defeitos foram encontrados. Com o sistema inte-
grado, é o momento de exercitar o sistema como se fossemos os usuários.
Nessa estratégia de teste, a máxima definição de validação, descrita por tan-
tos autores, é muito válida “precisamos saber se foi desenvolvida a coisa certa!”
(SEI, 2010)
De acordo com Pressman (PRESSMAN, 2011), o teste de validação tem como
foco as ações dos usuários e as saídas dos sistemas conhecidas pelo usuário.
Outra boa definição é a que teste de validação determina se o sistema está em
conformidade com os requisitos definidos, se contempla as funcionalidades
para o qual foi desenvolvido e satisfaz os objetivos e necessidades do usuário
(ISTQB, 2016).
No teste de validação, os casos de teste são definidos com base na especi-
ficação dos requisitos funcionais. Outro excelente artefato para direcionar os
testes de validação é o diagrama de Caso de Uso da UML (Unified Modeling
Language), já que esse retrata cenários de uso do sistema, e até mesmo o
Diagrama de Atividades, quando estiverem disponíveis.

76 • capítulo 3
 Além de garantir que o sistema seja exercitado de acordo com os requisitos
funcionais e testar se o sistema está de acordo com esses requisitos, no teste de
validação é o momento de testar se o comportamento, o desempenho, a interfa-
ce e a usabilidade do sistema estão de acordo com o esperado. Nesse momento,
também é uma excelente oportunidade para verificarmos se a documentação
do sistema está adequada.
Conhecimentos detalhados sobre os usuários finais e também sobre dire-
trizes de usabilidade como as Heurísticas de Nielsen (NIELSEN, 1995) e a bi-
blioteca de padrões Welie (WELIE, 2016) podem ser muito úteis para o testador
definir um bom caso de teste de validação.
Ao executar testes de validação, defeitos de implementação podem ser en-
contrados, mas são menos comuns, principalmente quando testes unitários e
de integração foram executados. Os defeitos mais comuns nessa fase são des-
vios dos requisitos especificados e melhorias sugeridas pelo testador, que está
usando o sistema no papel do usuário e devido sua experiência com software
pode identificar melhores maneiras de uso de determinada funcionalidade.
Quando um desvio do requisito é encontrado, é importante identificar se o
requisito foi especificado de maneira errada ou insuficiente – se o requisito es-
tiver errado, é importante que seja atualizado; se estiver insuficiente, é preciso
discutir para saber se o desvio identificado faz sentido e deve ser modificado
no software ou se a maneira como foi implementada é a melhor forma para o
usuário e então, o requisito deve ser atualizado para que a documentação fi-
que coerente.
Em relação às melhorias, o intuito é sempre inseri-las no software para que
o usuário tenha melhor percepção sobre a qualidade do sistema. No entanto,
devemos lembrar que inserir essas melhorias exige esforço e tempo de teste
– muitas vezes, é necessário negociar com o time todo de acordo com o crono-
grama do projeto.
Como podemos imaginar um testador não pode ter a pretensão de garantir
que os testes de validação irão repetir exatamente o comportamento do usuá-
rio. Sendo assim, testes alfa e beta podem ser considerados como uma estra-
tégia de teste, com o objetivo de ter a oportunidade dos usuários reais identi-
ficarem defeitos, como estudamos com mais detalhes no capítulo. Entende-se
por testes alfa, o teste realizado no ambiente de desenvolvimento por equipes
de técnicos independentes ou por usuários em potencial, e testes beta, o teste
realizado em ambiente real por um grupo seleto ou reduzido de usuários reais,

capítulo 3 • 77
3.5  Teste de sistema

Muito bom termos chegado até essa seção. O capítulo 3 está quase chegando ao
fim. Você deve estar pensando:
“Sistema quase testado, professor! Afinal, nosso sistema está integrado, tes-
tado e funcionando da maneira como era esperado, pois, acabei de executar
testes de validação. Correto?”
Errado!
Vamos lembrar nas primeiras aulas sobre software e sistema – sabemos que
o software que desenvolvemos compõe um sistema maior, apoiado por com-
putador, mas que envolve hardware, informação, pessoas, outros periféricos e
tantos outros componentes possíveis.
Daí vem a pergunta:

PERGUNTA
Será que o software devidamente testado usando as estratégias de teste unitário, integração
e validação, funcionará da mesma maneira em qualquer ambiente?

A resposta, você mesmo já sabe: infelizmente, ou felizmente, não!

Imagine o quão diferente é o computador que você utiliza em casa dos com-
putadores que você utiliza na faculdade ou no trabalho. Compare seu compu-
tador com o computador de algum colega. Atrelado a isso, considere versão do
sistema operacional, versão de JVM (Java Virtual Machine), conexão com inter-
net, impressoras, software instalado, antivírus e assim por diante. Extrapole
esse pensamento e compare o seu smartphone com smartphones dos seus co-
legas. Além disso, não podemos nos esquecer que muitos sistemas possuem
em seu ecossistema a integração com outros sistemas e o consumo de outros
serviços, como Web Services (figura 3.6).

78 • capítulo 3
 © PIXABAY.COM

Figura 3.6 –

Se pensarmos 5 minutos nisso, iremos elencar uma lista enorme de confi-

gurações de um sistema que pode gerar defeitos no uso do software que esta-
mos testando.
“Mas, professor, eu não consigo testar o software em todas as possibilida-
des de configuração!”
Realmente, isso seria impossível, mas isso ressalta a importância de especi-
ficarmos o ambiente mínimo que o sistema deve funcionar e também conhecer
o usuário final e o sistema no qual o software deverá funcionar, pois assim, po-
demos executar os testes de sistemas.
Para Pressman (PRESSMAN, 2006), Testes de Sistemas é um conjunto de
testes executados com o objetivo de exercitar todos os componentes que fa-
zem parte do sistema informatizado, ou seja, um sistema que depende de um
software. Apesar de cada teste ter um objetivo específico, o objetivo comum é
identificar, caso exista, defeitos ao exercitar todos os componentes do sistema
em conjunto com o software, que teve suas unidades devidamente testadas, in-
tegradas e seus requisitos validados.
Testes comumente executados na estratégia de teste de sistema são
(PRESSMAN, 2006):

capítulo 3 • 79
 Verifica se o sistema foi desenvolvido considerando mecanismos de prote-

SEGURANÇA
TESTE DE
ção e se esses mecanismos serão suficientes para proteger uma possível
invasão ou uso indevido das informações. Nesse momento, o testador
deve atuar como um hacker e fazer de tudo para invadir o sistema. Tendo
feito a invasão, identifica-se o problema e o sistema é melhorado.

Verifica como o software, no contexto do sistema, se recupera de falhas

RECUPERAÇÃO

(forçadas pela equipe de teste) de forma adequada e sem prejudicar o

TESTES DE

uso do sistema. É importante que o software se recupere de erros (ou da

maioria deles) e também, que seja tolerante a falhas, ou seja, que alguma
falha de processamento ou requisição (por exemplo) não deve causar
falhas em todo o sistema.

Verifica como o software se comporta em ambiente integrado e como ele

TESTE DE DESEMPENHO

responde às requisições. Para executar esse teste e fazer as medições

adequadas (nem mais, nem menos), é importante entender a demanda
de usuários, quantas pessoas usarão o sistema com frequência, picos de
uso etc. Embora seja considerado um teste de sistema, essas medições
de como o sistema se comporta, quanto tempo leva para responder às
requisições e quais requisições são mais demoradas, podem ser medidas
durante a execução de outros testes, como por exemplo, testes de inte-
gração e de validação, que vimos nas seções anteriores.

Verifica a quantidade máxima de carga que o sistema suporta até falhar.

Por quantidade de carga, podemos entender o número de usuário logado,
o tanto de requisições, o volume da massa de dados, quantidade de
TESTE DE STRESS

upload/download e assim por diante. Como o nome indica, o objetivo é

estressar o sistema até que ele falhe – dessa forma, saberemos o limite
de uso do sistema. Pressman (PRESSMAN, 2006) menciona alguns ce-
nários de teste de stress, como testes especiais para simular um número
de interrupções por segundo que é acima do convencional; simular uma
entrada de dados em velocidade maior do que o convencional; cenários
que exigem o uso de muita memória e cenários que exigem a recuperação
de um grande volume de dados.

É importante mencionar que o teste de stress caminha junto com o teste

de desempenho e considerando a natureza desses testes, ferramentas para

80 • capítulo 3
automatizar testes são geralmente necessárias – fique tranquilo que no capítu-
lo 5 abordaremos esse assunto.
A prática nos indica que defeitos comumente encontrados nessa estratégia
de teste são, não limitando-se a essa lista:

• Defeitos relacionados à interface (não estamos falando de interface gráfi-

ca) inadequada nos componentes do sistema, como por exemplo, comunicação
com webservices;
• Incompatibilidade de versões de sistema operacional, como por exemplo, fun-
cionalidades que funcionam como o esperado no Android 4, mas não funcionam no
Android 5;
• Incompatibilidade de recursos, como impressoras, câmeras, monitores, leitores de
dados que podem funcionar e se comunicar bem com o sistema, como podem dificul-
tar esse funcionamento em conjunto;
• Falta de mensagens inadequadas ou que permitam o usuário se recuperar do
erro quando algum componente falha, como por exemplo, um webservice que não
está disponível, impressora não instalada etc.;
• Sistema que não consegue processar muitas requisições ou não consegue man-
ter um número alto de usuários logados.

3.6  Teste de migração

Você está praticamente no fim do capítulo.

Nesse ponto já aprendemos muito sobre diversas estratégias de teste, qual o
contexto que elas são aplicadas e o objetivo de cada uma.
Para entender melhor o teste de migração, que é o assunto da nossa última
seção, vamos pensar no seguinte cenário:
O sistema ERP da nossa amiga Graça, lá do capítulo 3, está em produção.
Diversas estratégias de testes foram aplicadas e o sistema funciona de forma
adequada, agregando valor no negócio do cliente final e otimizando os proce-
dimentos diários dos usuários. Cada melhoria é devidamente documentada,
desenvolvida, testada e entregue ao cliente. Tudo como manda o figurino, tudo
como gostam o desenvolvedor, testador e cliente.

capítulo 3 • 81
 O sistema ERP que a Graça atua está estável e com bastante tempo de uso.
Naturalmente, o volume de dados do banco de dados cresce constantemente e
o volume de acessos também, afinal, a empresa que usa o ERP tem crescimento
muito devido a eficiência do seu serviço.
Pensando em aumentar a capacidade do banco de dados e também do ser-
vidor, a fim de evitar problemas com os dados e com a disponibilidade e de-
sempenho do sistema, a equipe de TI propõe uma mudança de infraestrutura:
mudar a aplicação para um servidor com maior capacidade de processamen-
to e memória, mudar o sistema operacional do servidor (mudar de Microsoft
Windows para Linux, por exemplo) e colocar o banco de dados em um ambien-
te de cluster, para melhorar o tempo de recuperação dos dados e garantir maior
segurança, evitando a perda de dados.
Agora eu pergunto: “Você acha que o time de teste deve estar envolvido nes-
sa migração de sistemas? Afinal, estamos falando de mudanças de infraestru-
tura, não é mesmo?”.
©© PIXABAY.COM

Figura 3.7  – 

A resposta é sim, o time de teste deve estar envolvido. Por quê? Pense nas
seguintes perguntas:

PERGUNTA
•  Será que o software irá funcionar da mesma forma no Linux como funcionada no Microsoft
Windows?

82 • capítulo 3
•  Será que quando um dos nós do banco “clusterizado” não estiver disponível, o sistema vai
ser impactado?

Como podemos responder essas perguntas?

Você, que já estudou mais da metade desse livro, sabe a resposta: testando.
É importante que alguns testes de integração e de validação sejam executa-
dos no contexto de teste de migração, para garantir que a migração de ambien-
te não afetou o sistema como um todo, afinal, um sistema informatizado é a
junção de muitos componentes, incluindo um software.
Sendo assim, podemos entender que o teste de imigração deve ser feito
sempre que exista uma mudança na arquitetura do sistema ou na migração
dos dados (como a troca de tecnologias de gerenciamento de banco de da-
dos). Como exemplo de cenários nos quais testes de migração são relevantes,
Pinkster (PINKSTER, 2016). Cita:
•  Junções de mais sistemas/serviços no sistema atual;
•  Mudança para novo sistema operacional;
•  Substituição, melhoria ou consolidação das tecnologias de armazena-
mento de dados;
•  Virtualização de ambientes;
•  Mudanças na estrutura do banco de dados;
•  Realocação de centro de dados (datacenter);
•  Manutenção feita nos servidores;
•  Aplicação de balanceamento de carga ou qualquer outra mudança rela-
cionada a ajuste de performance.

Esse tipo de teste requer um conhecimento detalhado da arquitetura da

aplicação, da interface e comunicação entre os sistemas envolvidos e da critici-
dade da migração para o negócio como um todo (SQS, 2016).
Um fator de sucesso para garantir que a migração foi realizada e não resul-
tará em erros é executar teste de regressão completo, ou seja, executar todos
os casos de teste do sistema (PINKSTER, 2016). No entanto, sabemos que fato-
res importantes como tempo, esforço, custo e planejamento de projeto podem
não permitir que isso seja feito. Sendo assim, é essencial o conhecimento pro-
fundo do software e do que está sendo modificado no sistema como um todo
para que testes que exercitem cenários críticos sejam executados e defeitos se-
jam encontrados.

capítulo 3 • 83
 Algo muito importante de reforçar é que como vimos no início do livro, os
testes devem ser feitos em um ambiente controlado, reservado para testes. O
mesmo é válido para o teste de migração – jamais devemos migrar algum item
do sistema sem ter testado antes, afinal, é melhor deixar riscos para viagens de
aventuras e esportes radicais, e não para o nosso cliente.
©© PIXABAY.COM

Figura 3.8  – 

ATIVIDADES
01. Observe a figura 3.9 e responda as questões abaixo.

U1

U2 U3

U4 U5 U6 U7 U8

U12
U9 U10 U11

Figura 3.9  –  Exemplificação de arquitetura de unidades/módulos de um sistema.

a) Considerando a estratégia de teste de integração, abordagem top-down, descreva a

sequência de unidades/componentes que seriam integradas e testadas, considerando a
abordagem de caminhar em largura.
b) Considerando a estratégia de teste de integração, abordagem top-down, descreva a
sequência de unidades/componentes que seriam integradas e testadas, considerando a
abordagem de caminhar em profundidade.
c) Considerando a estratégia de teste de integração abordagem bottom-up, descreva a
sequência de unidades/componentes que seriam integradas e testadas.

84 • capítulo 3
02. Escolha algum site ou aplicativo que disponibilize no mínimo um cadastro. Leia as Heu-
rísticas de Nielsen, mencionada na Seção 3.5 (Teste de Validação), e tente avaliar o site
escolhido. Alguma heurística é ferida? Se sim, você considera o problema encontrado grave
ou não?
Não se esqueça de ler as heurísticas e pensar se você segue essas diretrizes no desen-
volvimento dos softwares que você atua.

03. A fim de reforçar o conteúdo, descreva com suas palavras o seu entendimento sobre:
a) Teste de unidade
b) Teste de integração
c) Teste de validação
d) Teste de sistema
e) Teste de migração

04. Descreva o que você entende como sendo a principal diferença entre teste de stress e
teste de desempenho.

05. Considerando o mesmo site ou aplicativo que você elegeu para a atividade 2, pense em
possíveis defeitos que poderiam existir no sistema caso testes de integração, de validação,
de sistema e de migração não tivessem sido executados.

06. No seu dia a dia, você já se deparou com erro em algum sistema informatizado? Se sim,
usando o conhecimento que você acabou de adquirir sobre estratégias de teste, pense, releia
e responda: qual estratégia de teste deveria ter ajudado na identificação desse defeito na
fase de testes?
Exemplo: estou navegando num site de compras que utiliza o webservice do Correio
para informar prazo e preço das diferentes opções de postagem (<http://www.correios.com.
br/para-sua-empresa/servicos-para-o-seu-contrato/precos-e-prazos>). Por algum motivo,
o webservice ficou indisponível no momento que eu estava escolhendo a forma de entrega
da encomenda. Ao invés de me informar da impossibilidade de continuar a operação, eu
visualizo uma mensagem em HTML, com códigos e siglas “estranhos” para alguém que não
conhece HTML. Qual a estratégia de teste que prevê a identificação desse tipo de defeito?
Identifique um cenário como esse no seu dia-dia e faça o exercício de identificar qual a
estratégia de teste relacionada.

capítulo 3 • 85
 REFLEXÃO
Parabéns, você conseguiu chegar até o final do nosso quarto capítulo. Aqui você já deve
estar sabendo o que é teste de software, a importância desse tipo de atividade no processo
de desenvolvimento, as técnicas e os critérios de teste de cada técnica de software e as
diferentes estratégias de teste.
Obviamente que por mais que seja um caminho de sucesso, em algumas situações é
inviável executar todas as estratégias que vimos nesse capítulo. Exemplo: vimos que testes
unitários, idealmente, devem ser automatizados (como veremos no capítulo 5). No entanto,
se o desenvolvedor, por algum motivo, não desenvolveu esses testes, pode ser inviável que
o testador desenvolva. Além disso, dependendo de quão avançado o projeto está, pode ser
inviável para o próprio desenvolvedor criar os testes de unidade.
Outra observação importante é que novas formas de testar surgem a cada dia. Atualmen-
te, além dos testes de unidade, encontramos uma forte tendência em testes de comporta-
mento, conhecimentos como behaviour tests, que são baseados em critérios de aceitação, e
que foram introduzidos junto ao conceito de BDD - Behaviour Driven Development (NORTH,
2006).
Sendo assim, ficamos com a lição de que essas estratégias são básicas e se encaixam
em qualquer modelo de processo de desenvolvimento que você esteja inserido. O importante
é ter o discernimento do projeto como um todo em relação a tempo, esforço, orçamento
e prazos para que a equipe de teste saiba identificar as melhores estratégias, definir os
melhores casos de teste e otimizar essa atividade de forma a identificar o maior número de
defeitos possíveis.
Além desses pontos recuperados, estudamos outras que se encaixam em praticamente
todos os cenários de sistemas informatizados. Vimos as diferentes abordagens de teste de
integração e aprendemos a importância desse tipo de teste para garantir que o software está
sendo entregue sem defeitos de implementação.
A fim de garantir que defeitos nos aspectos funcionais do software sejam repassados
para o cliente, aprendemos sobre o teste de validação. Pensando no sistema como um todo,
lembrando como esse ecossistema é rico e cheio de integrações, estudamos a importância
do teste de sistema. Vimos também diversas estratégias de teste que estão relacionadas ao
teste de sistema.
Por fim, vimos sobre teste de migração e entendemos a importância do time de teste
estar envolvido nessas mudanças do sistema e o quão importante essa estratégia de teste é
em situações de migração.

86 • capítulo 3
 Tenha certeza que esses conceitos de teste que estudamos até esse terceiro capítulo
fará de você um profissional melhor – seja qual área de TI você venha a atuar. Esses co-
nhecimentos farão você inserir menos defeitos no software que desenvolve e obviamente,
farão você saber a maneira correta de testar o software e planejar os melhores testes a
serem executados.
Agora, estamos prontos para estudar sobre testes em ambiente de produção.

LEITURA
No capítulo anterior listamos alguns livros bem conceituados sobre teste e qualidade de
software. Como estamos falando de tecnologia, sabemos que as inovações sempre chegam
e modificam a forma de executarmos nosso trabalho. Por isso, é importante ficar atento
aos fóruns, eventos científicos e da indústria para nos mantermos atualizados e obviamente,
atentos à comunidade na internet. Alguns sites muito interessantes de estar em constante
contato são: <https://strongqa.com/qa-portal>, <http://www.testingexcellence.com>, am-
bos em inglês, e o <http://ibqts.com.br/>, em português.

REFERÊNCIAS BIBLIOGRÁFICAS
BECK, K. Test-driven Development: By Example. London: Addison-Wesley Professional, 2003.
ISTQB. ISTQB. ISTQB Exam Certification, 03 mar. 2016. Disponível em: <http://
istqbexamcertification.com/>.
MYERS, G. J. The Art of Software Testing. New Jersey: John Wiley & Sons, 2004.
NIELSEN, J. 10 Usability Heuristics for User Interface Design. Nielsen Norman Group, 10 jan.
1995. Disponível em: <https://www.nngroup.com/articles/ten-usability-heuristics/>.
NORTH, D. Introducing Behaviour Driven Development. Better Software, p. 10, 2006.
PINKSTER,. Migration testing. Professional Testing, 27 mar. 2016. Disponível em: <http://www.
proftest.nl/presentaties/DAM.pdf>.
PRESSMAN, R. Engenharia de Software. São Paulo: McGraw-Hill, 2006.
PRESSMAN, R. Engenharia de Software - Uma abordagem profissional. São Paulo: McGraw Hill -
ARTMED, 2011.
SEI, S. E. I. CMMI for Development, Version 1.3. Hanscom. 2010.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson, 2011.

capítulo 3 • 87
SQS. Software Quality Service, 27 mar. 2016. Disponível em: <https://www.sqs.com/us/services/
data-migration-testing.php>.
WELIE, M. V. Patterns in interation design. A Pattern Library for Interaction Design, 27 mar. 2016.
Disponível em: <http://www.welie.com/patterns/index.php>.

88 • capítulo 3
 4
Teste de software
em sistemas em
produção
4.  Teste de software em sistemas em
produção

Olá, caro aluno! Que bom que seus estudos sobre teste de software estão pro-
gredindo bem.
É muito bom tê-lo no quarto capítulo, estamos quase no final.
No capítulo anterior discutimos sobre as diversas estratégias de teste no
contexto do processo de desenvolvimento de software. Com o conhecimento
adquirido até esse momento, estamos prontos para prosseguir e entender mais
sobre os testes quando o sistema está em produção, ou seja, está sendo utiliza-
do pelo cliente. Essa fase é crítica, pois geralmente há muitas mudanças e para
o cliente, o sistema não pode falhar – ele deve ser confiável e estar disponível de
acordo com as necessidades definidas.
Temos certeza que esse conteúdo será de extrema importância para sua vida
acadêmica e principalmente para sua carreira profissional.

OBJETIVOS
•  Aprender sobre teste de software nos diversos tipos de manutenção;
•  Aprender sobre conceitos importantes que todo software que está em produção deve ga-
rantir: confiabilidade e disponibilidade.

4.1  Teste de software nos diversos tipos de manutenção

Até agora vimos técnicas e estratégias definidas para nortear a atividade de testes.
Embora não tenhamos reforçado, podemos constatar que tudo que vimos até ago-
ra são práticas que devem ser aplicadas no processo de desenvolvimento do siste-
ma para identificar defeitos, ou seja, todas as atividades devem ser feitas antes do
sistema estar disponível para o cliente – com exceção apenas dos testes alfa e beta.
No entanto, sabemos que o desenvolvimento de um sistema só terminará
quando ele cai em desuso – não é útil para os usuários nem para o negócio que

90 • capítulo 4
ele dá suporte. Por outro lado, dificilmente é dispensado grande esforço de de-
senvolvimento em um software com data para cair em desuso.
Obviamente que o desuso de um software, ou em outras palavras, a morte
desse software, pode acontecer – mudança de ambiente, infraestrutura, moder-
nização etc. são apenas alguns motivos para isso. Por outro, o cenário mais co-
mum é a manutenção do software. A norma ISO/IEC 12207 (ISO, 2008) conside-
ra as atividades de desenvolvimento e de manutenção do software como sendo
processos que compõem o ciclo de vida de um produto de software.
Voltamos ao cenário da nossa amiga Graça, que vimos nos capítulos 2 e 3...
Recapitulando um pouco esse cenário, no capítulo 2 o sistema ERP estava
sendo desenvolvido e testado pela Graça e seus colegas de trabalho. No capítulo
3, o sistema ERP passou por mudanças – o banco de dados foi para um ambien-
te de cluster e o sistema operacional do servidor foi modificado, o que exigiu
testes de migração.
Como podemos imaginar, um sistema ERP (Enterprise Resource Planning)
possui um software realmente grande, com milhares de linhas de código e com
muitas regras de negócio complexas, além de muita parametrização, o que per-
mite o sistema se tornar adaptável a diversos segmentos. No entanto, a necessi-
dade dos usuários muda e o software deve acompanhar isso.
Vamos adicionar três novos eventos no cenário do ERP da desenvolvedo-
ra Graça:

Por motivos legais, uma das empresas que utiliza o ERP

desenvolvido pela nossa amiga Graça precisa começar a
armazenar os exames médicos de seus funcionários dos
últimos 30 anos. Por se tratar de uma empresa na qual
alguns funcionários entram em contato com elementos
SEGUINDO A LEI químicos, a empresa quer que o sistema ERP ajude a
garantir que esses funcionários repitam alguns exames
de 6 em 6 meses. Sendo assim, um relatório e até mesmo
mensagens na interface gráfica do sistema devem ser
implementadas para atender à solicitação do cliente.

capítulo 4 • 91
 Além disso, diretores de outra empresa que utiliza o ERP
solicitaram que eles gostariam de visualizar alguns relató-
rios em um tablet – o ERP foi desenvolvido com tecnolo-
gias que o permitem ser responsivo e embora não tenha
sido desenvolvido para ser utilizado em tablet, os usuários
conseguem acessar o ERP nesse tipo de dispositivo. No
MOBILIDADE entanto, alguns relatórios não são visualizados na maneira
como o são em computadores desktops e notebooks.
Dessa forma, o time de desenvolvimento da Graça deverá
ajustar alguns componentes gráficos para que páginas
de relatórios sejam exibidas de forma otimizada em telas
pequena, de 7 polegadas por exemplo, como é o caso de
alguns tablets.

Como se não bastasse as duas requisições feitas, o time

de suporte (atendimento ao cliente) da empresa que
Graça trabalha recebeu um e-mail desagradável. Uma
funcionária de Recursos Humanos de uma empresa
JOANINHA reportou que tentou atualizar a foto no cadastro de um
funcionário e que embora ela tenha recebido a mensagem
de sucesso e conseguido salvar a alteração, ao acessar
o mesmo cadastro novamente ela observa que a foto não
foi atualizada. Erro em ambiente de cliente.

Como vimos alguns parágrafos atrás, o ERP foi desenvolvido, testado e en-
tregue a diversos clientes. Embora ele ofereça as funcionalidades necessárias
para um ERP e poderia ser considerado “pronto”, sabemos que quando o clien-
te começa a utilizar o sistema, o software entra na fase de manutenção, ou seja,
o software é modificado frequentemente, e é exatamente isso que os clientes
que utilizam o ERP estão pedindo: manutenção.
De acordo com (SOMMERVILLE, 2011), há três categorias de manutenção
de software:

92 • capítulo 4
 O autor salienta que erros de codificação não geram
correções de alto custo, erros de projeto geralmente exige
a reescrita de muitos componentes e linhas de código, o
que torna o custo maior e erros de requisitos são os que
CORREÇÃO DE geram correções de alto custo, pois implica em alterar o
DEFEITOS projeto e reescrever muitas linhas de código, quando não,
escrever novas e inutilizar linhas existentes. No nosso
cenário, o evento “Joaninha” resulta em uma manutenção
de correção de defeitos.

Esse tipo de manutenção é necessária quando o sistema

que o software está inserido sofre alguma alteração e
então, manutenções são necessárias para que o sistema
se adeque a essas mudanças. Isso pode ocorrer com o
ADAPTAÇÃO software em si ou com os sistemas/componentes que ele
AMBIENTAL se comunica. No nosso cenário, o evento “Mobilidade” re-
sulta em uma manutenção de adaptação ambiental, já que
o software deverá ser adaptado para se integrar correta-
mente com o novo dispositivo.

Esse tipo de manutenção ocorre quando os requisitos do

sistema mudam ou precisam ser aprimorados em decor-
rência de mudança de negócio, mudança organizacional e
ADIÇÃO DE até mesmo mudanças legais. Esse é o tipo de manutenção
FUNCIONALIDADE mais frequente, pois ao utilizar o software, o usuário tem a
chance de sugerir melhorias e novos requisitos. No nosso
cenário, o evento “Seguindo a lei” resulta em uma manu-
tenção de adição de funcionalidade.

Sommerville (SOMMERVILLE, 2011) ressalta que outros nomes também

são utilizados para nomear as categorias de manutenção – manutenção cor-
retiva, que é equivalente à correção de defeitos; manutenção adaptativa, que
é equivalente à adaptação ambiental e a manutenção perfectiva, que é equiva-
lente à adição de funcionalidade. Além dessas três categorias, há autores que

capítulo 4 • 93
mencionam a manutenção preventiva, que tem como objetivo identificar pon-
tos que podem gerar erros e corrigir ou refatorar esses pontos antes que o erro
seja percebido. (PRESSMAN, 1995).
Independentemente do tipo de manutenção que é necessária no software, o
fato é que assim como a manutenção impacta no código e consequentemente
na documentação do sistema, os testes também são impactados.
O ISTQB (ISTQB, 2016) define que teste de manutenção são os testes exe-
cutados quando o sistema que está em ambiente operacional (ou ambiente de
produção) é corrigido, modificado ou ampliado.
A prática nos indica três impactos principais nos testes em relação à
manutenção:
1. Novos testes devem ser gerados e executados, pois a manutenção vai ge-
rar uma nova versão do software que precisa ser testada como qualquer outra;
2. Manutenção nos casos de teste e ciclos de teste existentes que são refe-
rentes às áreas de manutenção e
3. Análise de impacto, afinal é necessário entender quais funcionalidades
(ou código fonte) podem ter sido impactadas com a manutenção feita para que
testes de regressão sejam planejados e executados.

Detalhando um pouco mais, vimos nos capítulos iniciais que, logo no início
do ciclo de vida do software, assim que a fase de projeto termina, a definição
dos casos de teste pode ser iniciada. De certa forma, o time de desenvolvimento
começa a codificação e o time de testes começa a definição dos casos de teste.
© PIXABAY.COM

Figura 4.1 –

Quando falamos de manutenção é de extrema importância que essa se-

quência de atividades seja mantida – o time de testes deve estar envolvido na

94 • capítulo 4
fase de definição da mudança e na fase de mudança do projeto, pois precisa
saber quais partes do software serão mais impactadas e então, enquanto o time
de desenvolvimento inicia o seu trabalho, o time de teste inicia o seu (obvia-
mente, quando forem times distintos).
Dependendo da manutenção que será feita e de como ela foi projetada, o
time de teste deve criar novos casos de teste, inseri-los nos ciclos e no plano
de teste. Dependendo da situação, ao invés de criar nos casos de teste, o time
de teste deve identificar o caso de teste que ficará obsoleto após a mudança e
atualizar esse ou esses casos de teste para que ele atenda à modificação que foi
feita. Em outras palavras, assim como o código fonte, o caso de teste também
precisa de manutenção – afinal, se o caso de teste testar uma funcionalidade
que foi alterada e seus passos de teste não foram alterados, o teste sempre irá
falhar e apontar que há erros no software. Além disso, é importante identificar
o que mais pode ter sido afetado pela manutenção e também testar essas fun-
cionalidades para identificar defeitos, caso tenham sido inseridos.
Ao pensarmos na fase de manutenção do software fica ainda mais eviden-
te a estreita relação que temos entre requisitos, projeto, código fonte e casos
de teste. É importante que um seja reflexo do outro e que os times envolvidos
caminhem junto, pois o trabalho de um tem grande impacto no trabalho do
outro time.
Sabemos que principalmente em times ágeis, o software sofre manuten-
ções constantes e em ritmo frenético, pois a todo o momento o cliente está va-
lidando e fazendo requisições. Mesmo em ambientes como esse, é importante
que a representação dos requisitos, independente da forma como são represen-
tados, seja atualizada. O mesmo deve ser feito com outros artefatos de projeto,
arquitetura etc. Esses artefatos devem ser atualizados, pois eles são a fonte de
informação para o time de teste, ou devem estar de acordo com o que foi pedido
pelo cliente para evitar que defeitos sejam entregues para o usuário final.
Além de executar os testes como parte do ciclo de vida do software, os testes
são de extrema importância para garantir confiabilidade e disponibilidade do
software. Esses são requisitos chave para o sucesso do produto e agora que já en-
tendemos o quão importante é o teste no contexto de manutenção de software,
vamos estudar um pouco mais sobre esses e outros conceitos de qualidade e a
relação deles com nosso tema principal: teste.

capítulo 4 • 95
4.2  Requisitos de qualidade de software

Atualmente, sistemas informatizados estão tão incorporados no nosso coti-

diano que é imprescindível que as equipes de desenvolvimento extrapolem os
requisitos técnicos de um sistema e pensem, cada vez mais, em requisitos de
qualidade do software do ponto de vista do usuário final.
Embora esse seja um assunto amplo e que mereça muitas páginas, vamos
nos concentrar em poucas definições do que é qualidade de software. Pressman
(PRESSMAN, 2006) salienta três pontos importantes sobre o tema:

É o ponto básico para se medir qualidade do software. Se o

REQUISITOS software não atende aos requisitos funcionais e não-funcionais
DE SOFTWARE especificados, então não é possível dizer que o há qualidade;

Há diversas normas ou padrões de desenvolvimento que

devem ser seguidos a fim de evitar que haja falta de qualidade.
Podemos citar aqui tanto modelos de processo de desenvol-
vimento (qualidade de processo) como normas, convenções,
NORMAS/ boas práticas e guias de desenvolvimento do software que
CONVENÇÕES disseminam formas adequadas de especificar, modelar, codifi-
car, desenvolver interfaces gráficas, interfaces de comunicação
(qualidade do produto). Se esses critérios são deixados de
lado, quase sempre pode resultar em falta de qualidade;

Quando se trata de software, há um conjunto de requisitos que

comumente não são explícitos, mas que são esperados, como usa-
bilidade, navegabilidade etc. Se um software está em conformidade
com requisitos funcionais, mas peca em relação a esses requisitos
REQUISITOS implícitos, a percepção de qualidade também é prejudicada. Pode-
IMPLÍCITOS mos dizer que aqui estão os requisitos mais difíceis de serem espe-
cificados, os requisitos que são óbvios do ponto de vista do cliente,
mas em alguns casos, difíceis de serem captados pelos desenvolve-
dores - os famosos “Mas é óbvio que isso era esperado!”, “Mas
eu precisava pedir isso?”, “Pensei que isso era padrão!”.

96 • capítulo 4
 Exemplo: quando o cliente pede um software web, para ele, pode ser muito
claro que o software irá funcionar na “internet”, independente de qual disposi-
tivo ele utilize, afinal, internet é internet em qualquer dispositivo. No entanto,
sabemos que é necessário saber de antemão os dispositivos, pois há adaptações
que devem ser feitas para que o software funcione em celulares. Se o cliente não
mencionar “quero usar o sistema no meu celular e no meu tablet”, podemos ter
uma falha de qualidade do ponto de vista do cliente.
Pressman (PRESSMAN, 2006) resume muito bem que:

Qualidade de software é uma mistura complexa de fatores que variam com cada
aplicação diferente e com os clientes que as encomendam.
©© PIXABAY.COM

Figura 4.2  –  .

Na literatura sobre qualidade de software encontramos muitas definições

e muitos requisitos de qualidade – vamos lembrar de alguns dos mais citados
e conhecidos.
McCall, Richards e Walters (MCCALL, RICHARDS e WALTERS, 1977), apre-
sentam o que ficou conhecimento como “Fatores de qualidade de software de
McCall”. De forma resumida (afinal, nosso foco aqui é teste), esses fatores são
divididos em três grupos:
•  Fatores de qualidade de operação do produto, que são: correção, confia-
bilidade, utilização, integridade e eficiência;
•  Fatores de qualidade de revisão do produto, que são: manutenabilidade,
flexibilidade e testabilidade;

capítulo 4 • 97
 •  Fatores de qualidade de transição do produto, que são: portabilidade, reu-
tilização e interoperabilidade.
A norma ISO 9126 (ISO, 2003) também identifica alguns atributos de quali-
dade para software de computador: funcionalidade, confiabilidade, usabilida-
de, eficiência, manutenabilidade e portabilidade.
Olsina e outros (OLSINA, GODOY, et al., 1999) apresentam uma árvore de
requisitos de qualidade para aplicações web, que envolve requisitos de usabili-
dade, funcionalidade, confiabilidade, eficiência e manutenabilidade.
Offut (OFFUT, 2002) incorpora os requisitos de qualidade apresentado por
Olsina e outros quatro requisitos: segurança, disponibilidade, escalabilidade e
prazo de colocação no mercado.
Se agruparmos todos esses estudos feitos, teremos uma lista de requisitos/
atributos/critérios de qualidade, apresentados na Tabela 4.1.

REQUISITOS DE QUALIDADE AUTORES QUE MENCIONAM O CRITÉRIO

(MCCALL, RICHARDS e WALTERS, 1977)
CONFIABILIDADE (ISO, 2003)
(OLSINA, GODOY, et al., 1999)
CORREÇÃO (MCCALL, RICHARDS e WALTERS, 1977)
DISPONIBILIDADE (OFFUT, 2002)
(MCCALL, RICHARDS e WALTERS, 1977)
EFICIÊNCIA (ISO, 2003)
(OLSINA, GODOY, et al., 1999)
ESCALABILIDADE (OFFUT, 2002)
FLEXIBILIDADE (MCCALL, RICHARDS e WALTERS, 1977)
(ISO, 2003)
FUNCIONALIDADE (OLSINA, GODOY, et al., 1999)
INTEGRIDADE (MCCALL, RICHARDS e WALTERS, 1977)
INTEROPERABILIDADE (MCCALL, RICHARDS e WALTERS, 1977)
(MCCALL, RICHARDS e WALTERS, 1977)
MANUTENABILIDADE (ISO, 2003)
(OLSINA, GODOY, et al., 1999)
PRAZO DE COLOCAÇÃO NO MERCADO (OFFUT, 2002)
(MCCALL, RICHARDS e WALTERS, 1977)
PORTABILIDADE (ISO, 2003)
REUTILIZAÇÃO (MCCALL, RICHARDS e WALTERS, 1977)
SEGURANÇA (OFFUT, 2002)
TESTABILIDADE (MCCALL, RICHARDS e WALTERS, 1977)
(MCCALL, RICHARDS e WALTERS, 1977)
UTILIZAÇÃO / USABILIDADE (ISO, 2003)
(OLSINA, GODOY, et al., 1999)

Tabela 4.1  –  Resumo dos requisitos/critérios de qualidade de software.

98 • capítulo 4
 Uma pergunta deve estar martelando na sua cabeça:
“Professor, o que isso tem a ver com teste de software?” Tudo.
Obviamente, alguns desses critérios dependem intimamente com o códi-
go-fonte e arquitetura do sistema (não se limitando a isso), como correção (do
ponto de vista de código), escalabilidade, flexibilidade, interoperabilidade, ma-
nutenabilidade, portabilidade, reutilização.
Outros estão intimamente relacionados com o projeto do software e com
os requisitos especificados, como confiabilidade, correção (do ponto de vista
dos requisitos implementados), eficiência, funcionalidade, integridade, segu-
rança, testabilidade e usabilidade. Outros estão mais relacionados com o plano
de negócio, como prazo de colocação no mercado.
O importante desses critérios para o nosso contexto de teste é que eles de-
vem permear nossas atividades de teste sempre, pois os testes devem ser capa-
zes de identificar alguns desses critérios e alertar sobre o não cumprimento ou
defeitos nesses contextos.
Antes de prosseguirmos, vale a pena reforçar que qualidade de software é
algo que pode e deve ser medido – afinal, só podemos realizar comparações e
fazer afirmações concisas e confiáveis se tivermos parâmetros para isso. Sendo
assim, não se esqueça que uma parte importante relacionada a esses critérios
de qualidade é a medição deles. Para entrar nesse assunto, que merece muito
estudo, consulte materiais específicos sobre o tema, como o livro de “Medidas
de esforço de desenvolvimento de software” de Martins (MARTINS, 2006).
Voltando aos requisitos que devemos nos atentar no momento de teste, va-
mos discutir como a atividade de teste se relaciona com cada um dos requisi-
tos/atributos da tabela 4.1.

Por meio dos testes de integração, de validação e de sistema é importante

termos em mente que o sistema deve ser confiável do ponto de vista técnico,
afinal, a equipe técnica deve confiar nos componentes que fazem parte do sis-
tema (e que muitas vezes, não são desenvolvidos por eles) e principalmente do
CONFIABILIDADE

ponto de vista do usuário, que deve confiar que o sistema funciona da maneira
correta, é seguro (testes de segurança), armazena os dados da maneira corre-
ta, exibe mensagens corretas, emite relatórios corretos e assim por diante. Uma
boa dica é elaborar casos de teste que conferem dados nos bancos de dados,
nos dados enviados e recebidos por webservices, que faz conferência de rela-
tórios gerados etc. Quando há manutenção no sistema, esses testes são fortes
candidatos a fazerem parte dos testes de regressão, pois é preciso garantir que
o sistema continua confiável após qualquer atualização.

capítulo 4 • 99
 Por meio dos testes de unidade, integração, de validação e de sistema é impor-
tante termos em mente o quão correto o sistema está. Se estivermos aplicando
testes estruturais, podemos verificar se o código está correto. Se estivermos
CORREÇÃO

aplicando testes funcionais, podemos validar se os requisitos foram imple-

mentados da maneira como deveria. De certa forma, as famosas perguntas
de verificação e validação são muito pertinentes nesse requisito de qualidade:
“Estamos construindo corretamente o produto?”; “Estamos construindo o
produto certo?”.
DISPONIBILIDADE

Por meio de testes de sistemas, especialmente testes de desempenho e stress,

podemos tentar identificar defeitos que comprometem a disponibilidade de um
software, no entanto, esse critério é altamente relacionado ao ambiente que
ele se encontra, e sabemos o quão difícil é prever todas as possibilidades de
ambiente na atividade de teste.

No contexto de software, eficiência é garantir que o software realize ou permita

realizar certas atividades de maneira correta e em menor tempo, podendo até
EFICIÊNCIA

dizer que o software permite que a atividade seja realizada de forma “mais
esperta” que outra, ou “mais otimizada” que outra forma. Testes de desempenho
também podem ajudar, assim como testes alfa e beta, afinal, a experiência do
usuário é que dirá de maneira mais completa sobre a eficiência de um sistema.
Nesse contexto, escalabilidade significa a capacidade do sistema de atender
ESCALABILIDADE

mais usuários, de funcionar corretamente em arquiteturas maiores etc. Testes

de stress podem ser úteis para identificar defeitos em escalabilidade ou ao
menos apontar a capacidade de escalabilidade atual.

Esse requisito de qualidade está mais relacionado à arquitetura e ao projeto

FLEXIBILIDADE

do software que em relação as funcionalidades, afinal são esses fatores que

determinam a possiblidade e facilidade do sistema sofrer manutenções de adi-
ção de funcionalidades e ter seu uso ampliado. Dificilmente testes, mesmo que
estruturais, identificam problemas que ferem a flexibilidade de um sistema. No
entanto, podem ajudar a identificar “maus-cheiros” no código, conhecidos como
bad-smells (SCHUMACHER, ZAZWORKA, et al., 2010).
INTEGRIDADE FUNCIONALIDADE

Testes de integração, de sistema e de migração são estratégias que original-

mente se preocupam em verificar e validar se as funcionalidades estão em con-
formidade com os requisitos funcionais especificados. Esse é um dos requisitos
de qualidade altamente relacionado a atividade de teste.

Novamente, todas as estratégias de teste podem auxiliar a identificar defeitos

em relação a integridade do sistema como um todo: integridade dos dados, dos
acessos, das informações expostas para os usuários e para os outros compo-
nentes do sistema.

100 • capítulo 4
 Assim como flexibilidade, esse requisito de qualidade está mais relacionado à

INTEROPERABILIDADE
arquitetura e ao projeto do software que em relação as funcionalidades, afinal
são esses fatores que determinam a possiblidade e facilidade do sistema de
comunicar com outros sistemas, ou seja, de inserirmos um novo componente
no sistema atual (como por exemplo, a integração de um sistema ERP com um
sistema de CRM (Customer Relationship Management).

Esse é um requisito também relacionado à arquitetura e ao projeto do soft-

MANUTENABILIDADE

ware, propriamente a forma como foi desenvolvido. Testes podem identificar,

principalmente após testes feitos nas fases de manutenção, que alterações do
código geraram muitos ou poucos defeitos, no entanto, esse critério de quali-
dade pode ser atingido por meio do uso de padrões de desenvolvimento como
reuso ou padrões específicos para manutenção (HAMMOUDA, 2004).

Esse critério, como salientado por (PRESSMAN, 2006), não é relacionado ao

DE COLOCAÇÃO

software propriamente, mas sim em relação a sua gestão. Um software que se

NO MERCADO

propõe a resolver um problema existente precisa estar no mercado antes que

outros o façam, afinal, o primeiro software lançado tende a captar mais usuários
que os que vierem depois. Testes, nesse contexto, apenas podem ajudar a
entregar no mercado um sistema sem defeitos ou com poucos defeitos.
PORTABILIDADE PRAZO

Testes de sistemas e principalmente os de migração podem identificar defeitos

quando uma portabilidade de ambiente e dispositivos é planejada, mas é ne-
cessário que o software tenha sido projetado e desenvolvido para isso.

Esse requisito de qualidade se assemelha ao requisito de Manutenabilidade.

REUTILIZAÇÃO

Testes unitários ajudam a identificar defeitos nas unidades/componentes e

assim, identificar se eles estão prontos para serem reutilizados. No entanto, é
importante que a arquitetura do componente tenha sido projetada para que ele
possa ser reutilizado – técnicas como padrões de projeto, família de produtos
entre outras (GAMMA, JOHNSON, et al., 1994).
Como vimos no capítulo 3, testes de segurança são importantes e devem ser
SEGURANÇA

considerados na estratégia de teste de sistemas. No entanto, vale ressaltar que

requisitos de segurança bem especificados ajudam muito o time de desenvol-
vimento, assim como diretrizes de codificação e de configuração de ambiente
com esse fim.

capítulo 4 • 101
 Teste é um tópico tão importante que é considerado um requisito de qualidade
TESTABILIDADE – ou seja, a atividade de teste é realizada para identificar defeitos e garantir a
qualidade do software, mas é importante que os artefatos do software, como re-
quisitos de projetos e principalmente o código sejam testáveis! O gerenciamen-
to de configuração é uma atividade importante nesse contexto, pois permite a
testabilidade do código fonte de maneira adequada. A revisão dos requisitos
(ou inspeção) é tão importante quanto, pois requisitos ambíguos, por exemplo,
permitem testes ambíguos, o que pode dificultar a identificação de defeitos.
Os testes de validação que vimos no capítulo 3 são ideais para avaliar a usabi-
lidade, facilidade de utilização do software do ponto de vista do usuário. Como
UTILIZAÇÃO /
USABILIDADE

foi dito no capítulo anterior, testes alfa e beta também são importantes, pois
só o usuário poderá opinar sobre a usabilidade do sistema. No entanto, como
foi dito, há diretrizes para ajudar a atingir esse requisito de qualidade, como
as Heurísticas de Nielsen (NIELSEN, 1995) e a biblioteca de padrões Welie
(WELIE, 2016)

Como sabemos, a qualidade de software é algo que deve ser buscado em

conjunto, por todos os envolvidos no processo de desenvolvimento e manuten-
ção. Considerando a equipe de teste, fica claro o papel importante que essa ati-
vidade possui na busca pela qualidade.
Quando o sistema entra em fase de manutenção, esse papel é enfatizado
– afinal, na fase de manutenção, a equipe de teste deve estar atenta no planeja-
mento da atividade para testar o mínimo necessário. Não é possível testar todo
o sistema novamente - para identificar defeitos não só nas funcionalidades que
sofreram manutenção, mas em todas as outras funcionalidades que podem ter
sido afetadas.
Tendo essa visão geral do papel do teste em todos os critérios de qualidade
de software, devemos nos atentar também a aspectos sociotécnicos do software.
Sommerville (SOMMERVILLE, 2011) ressalta que atualmente, os sistemas
de software estão tão enraizados na sociedade que são fundamentais para go-
verno, empresas e indivíduos. Dessa forma, é imprescindível que esses siste-
mas sejam confiáveis e disponíveis.
Embora tenhamos acabado de discutir sobre confiabilidade e disponibili-
dade, vamos olhar para esses critérios com mais atenção na próxima seção.

4.3  Confiabilidade e disponibilidade

De acordo com o dicionário Michaelis (Michaelis, 2016), confiabilidade é:

“Qualidade ou estado daquele ou daquilo em que se pode confiar”.

102 • capítulo 4
 O mesmo dicionário define disponibilidade, entre outras definições, como:
“Qualidade daquele ou daquilo que é ou está disponível”.

©© PIXABAY.COM

Figura 4.3  – 

Pense:
“Você compraria ou instalaria, mesmo que gratuitamente, um software
não confiável?
Se você for utilizar esse software e ele estiver indisponível, você manteria
ele instalado? Recomendaria o software para outra pessoa?”. “O que faz você,
usuário, pensar que um sistema tem qualidade, que ele é confiável?”.
De acordo com Sommerville (SOMMERVILLE, 2011) lembra que (LAPRIE,
1995) foi um dos pioneiros a propor o termo “confiança” para tratar de requisi-
tos de qualidade como disponibilidade, confiabilidade, segurança e proteção,
salientando o quão próximo esses requisitos são.
Hoje em dia, podemos constatar que confiar em um sistema pode ser mais
importante que suas próprias funcionalidades.
Pense comigo:
“Quantas vezes o seu serviço de e-mail falhou e, mesmo assim, você conti-
nua usando o mesmo serviço?”
“Quantas vezes um jogo apresentou algum problema e mesmo assim, você
continuou jogando?”
“Quantas vezes você tentou abrir um arquivo usando navegador A, não con-
seguiu, teve de usar navegador B para esse arquivo, mas mesmo assim, conti-
nuou usando o navegador A como padrão?”

capítulo 4 • 103
 “Quantas vezes um sistema apresentou um erro ao clicar num botão, mas
você contornou isso e acessou a mesma funcionalidade por meio de outro bo-
tão ou item de menu?”

© PIXABAY.COM

Figura 4.4 –

Provavelmente, sua resposta foi sim na maioria das perguntas. Isso corrobo-
ra o fato que muitas vezes, o fator confiança, que envolve tantas percepções, tem
mais peso que um defeito em alguma funcionalidade específica. Interessante
isso, não é mesmo?
Sommerville (SOMMERVILLE, 2011) ressalta algumas razões para que
isso aconteça:
•  Falhas de sistema afetam um grande número de pessoas
– Comumente, um sistema possui funcionalidades que nem mesmo
são utilizadas, ou são utilizadas por poucos. Se elas falharem ou ficarem
indisponíveis, poucas ou nenhuma pessoa será afetada. Por outro lado,
falhas e indisponibilidade em funções utilizadas por muitas pessoas
pode ser grave.
– Exemplo: tempos atrás tivemos indisponibilidade e falhas no sistema
eSocial do governo federal <http://www.esocial.gov.br> causou transtor-
nos para todos os empregadores de funcionários domésticos que preci-
sam pagar impostos. O sistema deixou de ser confiável e precisou de al-
gum tempo para que a população voltasse a confiar nele. (FOLHA, 2016).
•  Usuário muitas vezes rejeitam sistemas não confiáveis, inseguros e
não protegidos
– Se o usuário perceber, por algum motivo, que essas características
estão em um sistema, ele se recusará a usá-lo. Além disso, a empresa que
desenvolveu o sistema também pode perder a confiança do usuário.
– Exemplo: de tempos em tempos, é comum que atualização do
Microsoft Windows falhe e o sistema fique indisponível, exigindo que o
usuário faça a reversão da atualização. Isso é ainda mais grave quando
o usuário não tem essa habilidade e precisa recorrer a um profissional.
Isso aconteceu em 2007 com uma atualização do Windows 7 (G1, 2013).

104 • capítulo 4
 •  Custos de falha de sistema podem ser enormes
– Para alguns sistemas, principalmente os sistemas críticos, falhas ou
indisponibilidade podem causar custos maiores que o custo do próprio
desenvolvimento do produto.
– Exemplo: em 1998, um projeto de sonda espacial da NASA foi des-
truído em órbita após entrar em ângulo errado. Isso aconteceu porque o
software utilizado em terra usava medidas inglesas para calcular os pa-
râmetros, enquanto a sonda realizava os cálculos com o sistema métrico
(Discovery, 2016).
•  Sistemas não confiáveis podem causar perda de informações
– Na maioria das vezes, o mais importante de um sistema é o conjun-
to de dados que ele coleta, armazena e dá manutenção, sendo esse um
procedimento caro, em diversos sentidos. Recuperar dados perdidos ou
corrompidos é extremamente caro, e caso isso não seja possível, muitas
vezes a empresa precisa ressarcir o cliente que foi afetado.
– Exemplo: mesmo empresas de grande porte podem sofrer com
problemas de confiabilidade. Em 2011, uma queda no servidor RC2 da
Amazon prejudicou vários clientes – alguns dados foram recuperados,
mas muitos clientes tiveram seus dados perdidos para sempre e recebe-
ram indenizações da Amazon (IdgNow, 2011).

Além disso, falhas no hardware, falha nas funcionalidades do software e

falhas operacionais, que podem ser causadas por mau uso ou falhas na utili-
zação, também são fatores que devem ser considerados e que afetam a confia-
bilidade de um sistema.
Agora, vamos incluir mais um item que deve ser considerado: utilidade. Isso
mesmo. Quando um sistema não é confiável, mas é útil, ainda é possível que o
usuário utilize esse sistema.
Eu utilizo um software para desenhar as figuras desse livro. Esse software me
permite desenhá-las rapidamente e deixá-las com aspecto agradável aos meus
olhos. Não exige grandes conhecimentos de design, diagramação, nem nada dis-
so, e me permite criar minhas figuras para exemplificar melhor o que preciso.
Por outro lado, esse mesmo software, em alguns momentos, sem motivo aparen-
te, trava, fica indisponível ou avisa que está se recuperando de um erro. Às vezes
é falha no software, às vezes no sistema, como falhas na placa de vídeo etc.
O que eu faço? Deixo de usar o sistema e mudo para outro mais apropriado para
criar imagens? Não, eu crio mecanismos para minimizar os danos que a falha no

capítulo 4 • 105
sistema pode me causar. Em outras palavras, toda vez que termino uma imagem eu
salvo o arquivo e ao terminar o trabalho do dia, envio o arquivo por e-mail.
Mesmo tendo um trabalho extra, o software me é útil e não vou deixar de usá
-lo, mesmo não sendo confiável. A sensação de utilidade é algo que determina o
uso do sistema.
Devido a todos esses fatores é tão complicado afirmar, apenas por meio de
atividades de teste, que um software é confiável ou não. Da mesma forma, con-
fiabilidade é difícil de ser mensurado. Os fatores sociotécnicos são fundamen-
tais nesse critério de qualidade.
Embora seja complicado garantir que o usuário tenha confiança no siste-
ma apenas por meio dos testes realizados, tanto no desenvolvimento quanto na
fase de manutenção, algumas classificações da literatura podem ajudar a equi-
pe a definir casos de teste que tendem a identificar defeitos que prejudiquem
o nível de confiança. Esses casos de teste podem fazer parte de qualquer uma
das estratégias de teste que discutimos no capítulo anterior – no entanto, fazem
mais sentido quanto estamos realizando testes de sistemas e de validação.
Sommerville (SOMMERVILLE, 2011) apresenta quatro dimensões principais
da confiança de um sistema que podem guiar a definição de casos de teste. As qua-
tro dimensões assim como uma sucinta descrição são apresentadas na figura 4.5.

A habilidade do sistema
Disponibilidade de entrega de serviços
quando requisitados.

A habilidade do sistema
Confiabilidade de entrega de serviços
quando requisitados.
Confiança
A habilidade do sistema
Segurança de operarem falhas
catastróficas

A habilidade do sistema
Proteçao de se proteger de ins-
trução acidental ou não.

Figura 4.5  –  Principais propriedades de confiança. Adaptado de Sommerville

(SOMMERVILLE, 2011).

Obviamente, devemos nos atentar ao contexto do sistema que estamos tes-

tando. Se considerarmos um software desktop, não desenvolvido para ser aces-
sado via internet, disponibilidade, nesse contexto, é estar disponível no horário

106 • capítulo 4
designado pelos clientes, ter o servidor de dados disponível todo o tempo de
uso e assim por diante. “Isso faz diferença professor?” Sim! Nesse caso, ao ve-
rificar que o sistema fica indisponível por uma hora durante a madrugada para
criação de backups, eu, como testador, não iria relatar isso como um defeito.
O mesmo pode acontecer com um sistema web – se o cliente aceitar que
o sistema fique indisponível durante uma hora para aplicação de scripts ou
backup, desde que isso esteja nos requisitos, o teste não reporta isso como de-
feito. No entanto, se o cliente pedir que o sistema esteja disponível 100% do
tempo – no caso de ter equipes em turnos diferentes que utilizam o sistema,
por exemplo – a equipe de teste deve reportar isso como um defeito crítico. A
estratégia de backup ou aplicação de scripts deve ser outra.
Sobre confiabilidade, o que permeia esses testes são os requisitos do siste-
ma. Nesse caso, especialmente, todos os testes podem ser úteis. No entanto,
testes de sistema e de validação, que verificam o comportamento do software
no seu ambiente e do ponto de vista do cliente, tendem a identificar mais defei-
tos. Um fator crucial aqui é a qualidade dos requisitos – por exemplo, requisi-
tos de cálculo de impostos devem ter atenção redobrada. Nesse contexto, testes
que envolvem esses e outros requisitos críticos do sistema devem ser comple-
tos e sempre que um mínimo de desvio seja identificado, deve ser reportado
como algo importante, pois fere diretamente a confiabilidade do software.
Segurança e proteção são testes que caminham juntos, e estão claramente defini-
dos na estratégia de teste de sistemas. A equipe de teste deve procurar se especializar
nesse tipo de teste e em alguns casos, procurar consultoria para tais testes – espe-
cialistas em invasão de servidores, de sistemas de comunicação e sistemas de geren-
ciamento de banco de dados. Em testes de segurança, como já vimos, os testadores
devem tentar a todo custo invadir o sistema e corromper arquivos e identificar, além
das falhas de segurança, como o sistema se recupera. Os testes de proteção tentam
verificar se as proteções inseridas no sistema realmente cumprem seu papel.
Novamente, devemos lembrar que a preocupação com confiabilidade do
sistema é uma preocupação que deve permear todo o processo de desenvolvi-
mento e manutenção – desde a definição dos requisitos. Sendo assim, os testes
são atividades complementares para garantir o sucesso do sistema quando es-
tiver em produção.
Com todo esse conhecimento sobre testes, podemos caminhar para o últi-
mo capítulo do nosso livro, que apresentará ferramentas que podem facilitar a
implementação desses e de todos os testes que estudamos até agora.

capítulo 4 • 107
 ATIVIDADES
01. Quais são as categorias de manutenção de software?

02. Pensando nos tipos de manutenção que você acabou de revisar, dê um exemplo de
mudança em um produto de software para cada categoria.
Você pode usar o mesmo sistema/aplicativo utilizado nos exercícios do capítulo 2 para
pensar nas mudanças a serem exemplificada nesse exercício.

03. Escreva com suas palavras o que é confiabilidade de software e porque esse é um
fator importante.

04. Escreva com suas palavras o que é disponibilidade de software e porque esse é um fator
importante.

05. Liste quais são os principais atributos/requisitos de qualidade de software?

06. Com a lista apresentada na atividade 5, escreva, com suas palavras porque você concor-
da que esse é um requisito de qualidade e caso não concorde, explique o porquê.

07. Pense num exemplo de um software que você utilizou e que já apresentou erros. Res-
ponda as questões abaixo:
a) Você continua utilizando esse sistema? Se sim, qual o motivo?
b) Qual foi o impacto desse erro nas suas atividades?
c) Se não, para qual software você migrou? Qual o motivo?

08. Entre em contato com pessoas que foram do ambiente acadêmico – pessoas que tra-
balham em escritórios, órgãos públicos, serviços públicos etc. Repita as perguntas para eles:
a) Já utilizaram algum software que apresentou erros?
b) Qual foi o impacto desse erro nas atividades?
c) Continuam utilizando esse sistema? Se sim, qual o motivo?
d) Se não, para qual software eles migraram? Qual o motivo?

108 • capítulo 4
 REFLEXÃO
Aqui você já deve estar sabendo o que é teste de software, a importância desse tipo de ati-
vidade no processo de desenvolvimento, as técnicas e os critérios de teste de cada técnica
de software. Estratégias e como tudo isso se encaixa quando o sistema está sendo utilizado
pelos usuários finais e comumente, fazem parte de um processo maior que depende do
software – mercados, escritórios de administração, de contabilidade, de recursos humanos,
catracas de ônibus, sistemas de venda on-line e por aí vai.
Pense o tanto de mudanças que ocorre nesses sistemas e o quão crítico algumas falhas
podem ser. Isso porque estamos falando de sistemas de informação convencionais – nem
vamos pensar em sistemas críticos como sistemas de automação etc.
Nesse capítulo exercitamos um pouco o conhecimento sobre qualidade de software.
Como vimos, é um assunto tão amplo que merece um, ou vários livros sobre o assunto. No
entanto, não é possível falar sobre teste de software, confiança e disponibilidade sem tocar
nesse assunto.
Com o conteúdo que discutimos aqui, você está apto a pensar nos seus testes de forma
mais ampla, pensando em critérios de qualidade amplamente discutidos na literatura. Isso
dá a você um poder de argumentação e negociação no contexto de planejamento de teste
muito valioso.
Ao fim desse capítulo também vale salientar a construção de conhecimento que você
está fazendo – ao falarmos de teste no contexto de manutenção, tenho certeza que você
lembrou das aulas de engenharia de software e que agora, você relaciona muito bem os
conceitos de teste com os conceitos de manutenção, de requisitos, de projeto de software e
tudo mais que envolve o ciclo de vida como um todo.
Querido aluno, esses relacionamentos que você faz com todos os conceitos que você
tem aprendido até agora na sua graduação e até mesmo na sua vida profissional são de
grande valor e é isso que fará de você um grande profissional. Isso é fantástico. Exercite
isso sempre.
Com todo esse conhecimento adquirido, estamos prontos para aprendermos um pouco
sobre ferramentas de teste atuais, sempre lembrando que o estudo e a busca por novos con-
ceitos, técnicas, estratégias, abordagens e ferramentas é algo que nunca tem fim.

capítulo 4 • 109
 LEITURA
Esse capítulo reúne muitos conceitos de Engenharia de Software como um todo. Recomen-
do a leitura de livros sobre qualidade de software, como os livros:

“Qualidade de Software: teoria prática” de Ana

Regina Da Rocha, Jose Carlos Maldonado, Kival
Chaves Weber editora Pearson.

“Medição de Software – Guia Prático”, publicado

por Christiane von Wangenheim ,Aldo von Wan-
genheim e Juliana Lino do grupo de Qualidade de
Software (GQS) do Instituto Nacional de Convergên-
cia Digital (INCoD) da Universidade Federal de Santa
Catarina, da editora Bookess.

Para uma leitura mais ampla sobre critérios de qualidade de software, livros abrangentes
de Engenharia de Software são uma ótima pedida: para essa leitura, recomendo os clássicos
“Engenharia de Software” de Roger Pressman da editora Mcgraw Hill – Artmed e também
o livro “Engenharia de Software” de Ian Sommerville da editora Pearson.

110 • capítulo 4
 REFERÊNCIAS BIBLIOGRÁFICAS
DISCOVERY. UOL, 27 mar. 2016. Disponível em: <http://www.brasil.discovery.uol.com.br/ciencia/as-
10-maiores-falhas-da-nasa/>. Acesso em: 10 abr. 2016.
FOLHA. UOL. Folha de São Paulo, 06 jan. 2016. Disponível em: <http://www1.folha.uol.com.br/
mercado/2016/01/1726423-novo-erro-no-esocial-impossibilita-pagamentos-prazo-acaba-na-quinta.
shtml>. Acesso em: 15 abr. 20616.
G1. Globo, 11 abr. 2013. Disponível em: <http://g1.globo.com/tecnologia/noticia/2013/04/veja-
opcoes-para-recuperar-o-windows-com-falha-de-atualizacao.html>. Acesso em: 21 abr. 2016.
GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. London:
Addison-Wesley Professional, 1994.
HAMMOUDA, M. Documenting maintenance tasks using maintenance patterns. Proceedings 8th
European Conference on Software Maintenance and Reengineering. Tampere: IEEE. 2004. p. 37-47.
IDGNOW. Ti Corporativa, 29 abr. 2011. Disponível em: <http://idgnow.com.br/ti-
corporativa/2011/04/29/dados-armazenados-na-nuvem-da-amazon-foram-perdidos-para-sempre/>.
ISO. ISO/IEC TR 9126-2:2003. Software engineering -- Product quality, p. 86, 2003.
ISO. ISO/IEC 12207:2008. Systems and software engineering -- Software life cycle processes, p.
123, 2008.
ISTQB. What is Maintenance Testing? ISTQB, 27 mar. 2016. Disponível em: <http://
istqbexamcertification.com/what-is-maintenance-testing/>.
LAPRIE, J. C. Dependable-Computing: concepts, limits, challenges. 25th IEEE Symposion in
Fault-Tolerant Computing. Passadena: IEEE Press. 1995. p. 401-4112.
MARTINS, M. D. C. Medidas de esforço de desenvolvimento de software. Ribeirão Preto: UniSEB,
2006.
MCCALL, J.; RICHARDS, P.; WALTERS, G. Factors in Software quality. [S.l.]. 1977.
MICHAELIS. Dicionário de Português, 27 mar. 2016. Disponível em: <http://michaelis.uol.com.br>.
Acesso em: 20 abr. 2016.
NIELSEN, J. 10 Usability Heuristics for User Interface Design. Nielsen Norman Group, 10 jan.
1995. Disponível em: <https://www.nngroup.com/articles/ten-usability-heuristics/>.
OFFUT, J. Quality attributes of web software applications. IEEE Software, p. 25-32, 2002.
OLSINA, L. et al. Specifying Quality Characteristics and Attributes for Websites. 1st ICSE
Workshop on Web Engineering. Los Angeles: ACM. 1999.
PRESSMAN, R. Engenharia de Software. Sao Paulo: Pearson Makron Books, 1995.
PRESSMAN, R. Engenharia de Software. São Paulo: McGraw-Hill, 2006.

capítulo 4 • 111
SCHUMACHER, J. et al. Building empirical support for automated code smell detection.
Proceedings of the International Symposium on Empirical Software Engineering and Measurement,
ESEM. Bolzano: ACM. 2010. p. 16-17.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson, 2011.
WELIE, M. V. Patterns in interation design. A Pattern Library for Interaction Design, 27 mar. 2016.
Disponível em: <http://www.welie.com/patterns/index.php>.

112 • capítulo 4
 5
Ferramentas de
teste de software
5.  Ferramentas de teste de software
No capítulo anterior falamos sobre teste de software em sistema em produção,
teste de software nos diversos tipos manutenção, sobre confiabilidade e dispo-
nibilidade. Neste capítulo vamos conhecer algumas das diversas ferramentas
que dão suporte à atividade de teste.
Além disso, ao fim deste capítulo, acreditamos que você terá conhecimento
suficiente para se discutir amplamente os tópicos relacionados a teste de software
e consequentemente, bagagem para explorar ainda mais as ferramentas que
iremos estudar.

OBJETIVOS
•  Conhecer e aprender sobre ferramentas de teste de software;
•  Aprender sobre ferramentas de teste no desenvolvimento de sistema;
•  Aprender sobre ferramentas de teste para o programa;
•  Aprender sobre ferramentas de teste para o ambiente Web;
•  Aprender sobre ferramentas de teste para sistemas em produção.

5.1  Introdução às ferramentas de teste de software

Existem algumas ferramentas que podem auxiliar no processo de teste de soft-

ware. Com o passar dos anos, a ideia de automatizar testes com essas ferra-
mentas se consolidou, pois as organizações perceberam que mesmo com um
maior custo para a implementação dos testes automatizados, o retorno sobre o
investimento viria em seguida, diminuindo, assim, o retrabalho, custo e tempo
de implementação.
Com as ferramentas disponíveis, hoje em dia, se tornou mais fácil garan-
tir que um determinado software tem a devida qualidade para ser entregue ao
cliente/usuário. Muitos benefícios são encontrados na realização de testes uni-
tários, por exemplo, com o auxílio das ferramentas, pois os defeitos são encon-
trados logo na fase inicial de implementação, onde são testadas as menores
unidade de programação possíveis.
Testes funcionais e estruturais garantem que determinadas funcionali-
dades estão de acordo com o especificado pelo requisito de negócio, atingin-
do, assim, o máximo possível de condições válidas e inválidas estabelecidas

114 • capítulo 5
pelos conjuntos de casos de testes para garantir um bom nível de qualidade
de software.
Muitas ferramentas foram criadas/melhoradas para cobrir casos como es-
tes, tendo como objetivo a diminuição de custo e tempo, a automatização de
testes e a facilidade de reportar os resultados com maior acurácia.
Vamos conhecer aqui algumas dessas ferramentas e também veremos
exemplos de como utlizá-las.

5.2  Ferramentas de teste no desenvolvimento de sistema

Como podemos saber se um software não possui defeitos? Temos que testá-lo
para termos uma garantia mínima de que se há defeito, eles foram encontra-
dos. Como exemplo, temos os testes funcionais, que tem como objetivo veri-
ficar o sistema em relação aos seus requisitos. Além disso, testes de aceitação
com o usuário têm a intenção de verificar as funcionalidades em relação às ne-
cessidades atuais do usuário, geralmente realizado por um grupo de usuários
finais, que irão utilizar o sistema na prática.
Por outro lado, é possível que o próprio desenvolvedor possa criar seus pró-
prios testes, e assim minimizar as chances que cada pequeno pedacinho do sis-
tema que ele entrega tenha defeitos. Esse é o chamado teste unitário ou teste
de unidade.
O teste de unidade tem como foco as menores unidades do sistema que po-
dem ser funções, procedimentos, métodos ou classes, e o seu objetivo é identi-
ficar defeitos de lógica e de programação na menor unidade de programação.
Cada unidade do sistema deve ser testada separadamente. Quando um méto-
do é testado, geralmente nenhum outro recurso deve ser capaz de ser atingido,
como, por exemplo, o acesso ao banco de dados, sistemas de arquivos ou de
rede, fornecendo assim uma maior garantia ao sistema com métodos testa-
dos isoladamente.
Existem alguns frameworks bastante utilizados para a realização do teste
de unidade, como o JUnit (JUnit, 2006) e o NUnit (NUnit, 2016), que veremos
a seguir.

JUnit

O JUnit é um framework open-source que dá suporte à criação de testes automati-

zados na linguagem Java (JUnit, 2006). Algumas características do JUnit são:

capítulo 5 • 115
 •  Verifica e compara o resultado esperado com o resultado corrente de uma
determinada operação realizada por meio de assertivas (asserts);
•  É orientado a objeto;
•  Facilita a criação, execução automática de testes e a apresentação
dos resultados;
•  É free e pode ser baixado em <www.junit.org>, porém o JUnit geralmente
já vem configurado nas versões recentes de IDE’s como no Eclipse e Netbeans.

Para realização de teste em programas desenvolvidos na linguagem java de-

vemos seguir as seguintes instruções:
a) Para criar um projeto Java no Eclipse é preciso seguir os seguin-
tes passos:
1. Clique em Arquivo 4. Dê um nome ao projeto
2. Novo 5. Finalizar
3. Projeto Java

Feito isso, crie uma classe Java. Como exemplo básico, uma classe chamada
Calculo.java foi criada e contém os métodos de nome soma, subtração, multi-
plicação e divisão, apresentados na figura 5.1.

Figura 5.1  –  Classe Java com a definição dos métodos.

116 • capítulo 5
 b) Com o projeto Java criado, siga os passos para a criação da classe de
teste JUnit:
1. Clique em Arquivo
2. Novo
3. Caso de Teste JUnit
4. Dê um nome para a classe de teste e de preferência escolha a versão
mais atualizada do JUnit a ser utilizada.

A partir do JUnit 4 existe a anotação @Test para informar que determinado

método é um método de teste a ser executado.
Uma classe de teste chamada CalculoTeste.java foi criada. Utiliza-se a asser-
tiva assertEquals(), para realizar a comparação de dois objetos (resultado espe-
rado e resultado corrente).
Um exemplo de uma classe de teste implementada com o JUnit pode ser
visto na figura 5.2.

Figura 5.2  –  Classe de teste utilizando o JUnit.

capítulo 5 • 117
 Observe que foram implementados um teste para cada método criado. Para
o teste da operação de soma, foi enviado ao método os valores 4 e 2. O resultado
esperado é 6, então, a assertiva assertEquals() vai comparar se o retorno do mé-
todo soma é realmente 6 – se for 6, o teste irá passar, se for diferente de 6, o teste
irá falhar. O mesmo foi feito para os outros três métodos.
Com os testes prontos, é necessário selecionar a classe de teste implemen-
tada e executar como Teste JUnit: Ao rodar o teste unitário, se o retorno do teste
for verdadeiro, uma barra verde é exibida (figura 5.3). Caso contrário, é exibida
uma barra vermelha informando que o teste falhou.
No contexto de casos de teste, quando dizemos “passar”, significa que o
resultado esperado foi o resultado obtido. Quando dizemos “falhar”, significa
que o resultado obtido não foi o resultado esperado e indica que há uma falha
na implementação.

Figura 5.3  –  Execução dos métodos de teste realizada com sucesso.

Condições inválidas também são necessárias para o teste unitário, nos

quais o resultado esperado é diferente do resultado corrente.
Considerando o nosso exemplo anterior, o valor do resultado esperado dos
testes soma e subtração foram alterados, então o retorno da execução do teste
deve ser falso e o JUnit é capaz de apontar em qual linha de código está o erro
de implementação.
Na figura 5.4, é exibido uma execução dos casos de teste figura 5.2. Nesse
caso, o caso de teste apresentado na figura 5.1, linha de código 12, foi alterado de
AssertEquals (6, resultado, 0) para AssertEquals (3, resultado, 0). Considerando
que essa assertiva é para verificar o método soma, que recebeu valores 4 e 2,

118 • capítulo 5
sabemos que o teste irá falhar – não porque o método foi implementado errado,
mas porque a assertiva do teste está errada.
Sendo assim, podemos observar na figura 5.4 que o JUnit irá exibir a asserti-
va que identificou o defeito e a linha de código que ela se encontra – nesse caso,
linha 12.

Figura 5.4  –  Execução dos métodos de teste realizada com falha.

Como podemos observar v, é de extrema importância que o desenvolvedor

dos casos de teste analise se a implementação foi realizada de forma correta ou
se o defeito está no caso de teste que foi automatizado.
Além da assertiva assertEquals(), o JUnit oferece outras opções de assertiva
e assim, o desenvolvedor tem autonomia para escolher a melhor assertiva para
um determinado teste. As principais assertivas existentes no JUnit são:
•  assertEquals: testa igualdade entre dois objetos (esperado x corrente)
•  assertFalse: testa retorno booleano falso
•  assertTrue: testa retorno booleano verdadeiro
•  assertNotNull: testa se o valor de um objeto não está nulo
•  assertNull: testa se o valor de um objeto está nulo
•  assertArrayEquals: testa igualdade de arrays esperados e correntes
•  assertNotSame: testa se dois objetos (esperado x corrente) são diferentes

Em outras palavras, o método setUp() pode ser utilizado para abrir uma co-
nexão com o banco de dados e essa conexão deve ser feita toda vez que um tes-
te for executado, sem precisar instanciar a mesma conexão isoladamente em
cada método de teste, e sim instanciando a conexão uma única vez no método
setUp(). Com o método tearDown(), essa mesma conexão ao banco de dados é
fechada quando os testes são finalizados.

capítulo 5 • 119
 Para facilitar a vida do desenvolvedor, o JUnit disponibiliza o Test Suíte. Por
meio dessa funcionalidade, o desenvolvedor consegue selecionar um conjunto
de testes que serão disparados ao mesmo tempo e ao final, o desenvolvedor vi-
sualiza o resultado da mesma forma que vimos nas figuras 5.3 e 5.4.

NUnit

NUnit é um framework de teste unitário utilizado para todas as linguagens da

plataforma .NET. Seu desenvolvimento foi baseado no JUnit e foi desenvolvido
inteiramente na linguagem C#, tirando proveito de muitos recursos das lin-
guagens da plataforma .NET (NUnit, 2016).
Os testes que serão realizados com o framework NUnit podem ser imple-
mentados com a IDE Visual Studio e o download do NUnit pode ser feito em
<www.nunit.org>.
As assertivas no NUnit são utilizadas para o mesmo fim que as do JUnit, po-
rém são escritas de forma um pouco diferente:
•  Assert.AreEqual: testa igualdade entre dois objetos (esperado x corrente)
•  Assert.AreNotEqual: testa diferença entre dois objetos (esperado
x corrente)
•  Assert.AreSame: testa se dois objetos são os mesmos (esperado x corrente)
•  Assert.Contains: testa se um objeto está contido em um array ou em
uma lista
•  Assert.Greater: testa se um objeto x é maior que um objeto y (mais utiliza-
do em operações matemáticas)

Métodos como setUp() e tearDown(), como os que apresentamos ao falar de

JUnit, também são utilizados para reutilização de código na inicialização e des-
truição de atributos contidos nos testes.
Os testes podem ser executados a partir do console (NUnit-Console) ou pela
interface gráfica (NUnit-GUI). Quando executado no NUnit-Console, automati-
camente o resultado é salvo em formato XML, permitindo assim a produção de
relatórios. A partir da interface (NUnit-GUI) é possível mostrar os resultados de
sucesso ou falha dos testes de forma gráfica, bem como criar conjuntos de tes-
tes (suíte de testes) para serem executados de uma só vez. A figura 5.5 apresenta
um exemplo da interface gráfica.

120 • capítulo 5
Figura 5.5  –  Exemplo da interface do NUnit-GUI.

5.3  Ferramentas de teste para o programa

Após as fases de análise e definição de requisitos, projeto e implementação,

é necessário garantir que as funcionalidades implementadas pelos desenvol-
vedores estejam de acordo com o esperado pelo requisito de negócio, como já
falamos tantas vezes nesse livro.
Para isso, precisamos executar os testes funcionais para garantir a quali-
dade das funcionalidades. Como já vimos, também é importante, sempre que
possível, que testes estruturais também sejam executados, pois isso permitirá
que a cobertura do código fonte seja controlada e permitirá que mais defeitos
sejam encontrados.
No entanto, embora não sejam baseados em código fonte como os testes
estruturais, também podemos criar casos de teste funcionais automatizados.
Atualmente existem 2 ferramentas de automação de testes funcionais que
são bastante disseminadas na comunidade de teste: Selenium (SELENIUM,
2016) e Sikuli (SIKULI, 2016). Veremos um pouco dessas ferramentas a seguir.

Selenium

A ferramenta Selenium é bastante utilizada na indústria de software para a au-

tomação de testes funcionais. A Selenium oferece um conjunto de componen-

capítulo 5 • 121
tes que podem ser utilizados em diferentes contextos e de acordo com o caso de
teste que se quer automatizar. São eles: Selenium IDE (record & play), Selenium
RC (Remote Control), Selenium Grid (concorrência de testes) e Selenium Web-
Driver (alta customização de código).
A Selenium WebDriver é uma das ferramentas mais poderosas da Selenium,
pois se trata de uma versão estendida da Selenium RC com inúmeras vanta-
gens e estende o suporte a vários navegadores e plataformas, ao contrário da
Selenium IDE, que deve ser utilizada apenas no navegador Mozilla Firefox.
Além disso, dá suporte ao desenvolvimento de teste para diversas plataformas
de dispositivos móveis, como Android, IOS e Blackberry.
O primeiro passo para escrever testes funcionais é planejar a arquitetura
que será utilizada antes de começar a codificar os testes. Muitas aplicações, por
vezes, são complexas e possuem uma grande quantidade de telas e de regras de
negócio.
Para aplicações desse tipo é preciso utilizar uma ferramenta mais robusta
para que seja possível uma maior customização de código de teste, garantindo
que esses testes mais “específicos” sejam executados de forma mais eficiente
do que na utilização de uma ferramenta de automação de record and play, por
exemplo, que permite que o desenvolvedor grave os passos que devem ser exe-
cutados, entradas de dados fixas e depois, execute essa “gravação” inúmeras
vezes.
Considerando esse cenário, iremos ver com mais detalhes a ferramenta
Selenium WebDriver, que permitirá que você programe casos de testes robus-
tos para sua aplicação.
De acordo com a homepage da ferramenta Selenium (SELENIUM, 2016), al-
gumas características importantes da Selenium WebDriver são:
•  É compatível com múltiplos navegadores, tais como Google Chrome,
Opera, Mozila Firefox (nativo) entre outros;
•  Possui código aberto;
•  Fornece suporte a diferentes linguagens de programação, tais como Java,
C#, Ruby entre outras;
•  Possui uma grande comunidade de usuários, o que facilita o aprendizado
e a troca de conhecimento.

122 • capítulo 5
 Para criar um projeto Java com Selenium WebDriver é preciso realizar o
download das bibliotecas específicas em <www.seleniumhq.org/download>. e
adicioná-las no build path em um projeto Java. Se preferir, uma ferramenta de
automação de compilação pode ser utilizada para isso, como por exemplo, o
Apache Maven. Como projeto Maven, é necessário somente adicionar algumas
linhas de código no formato XML no arquivo pom.xml que será gerado, como
exibido na figura 5.6.

Figura 5.6  –  Arquivo XML (pom.xml) na utilização do Maven e suas dependências.

Após o projeto ter sido criado, é necessário criar uma classe de teste com
JUnit (ou somente uma classe Java, se preferir).
Para exemplificar o uso do Selenium WebDriver, vamos testar uma funcio-
nalidade utilizando o site do google <http://www.google.com>.
Primeiramente, para ter acesso a algum website, o Selenium WebDriver pre-
cisará de um driver para a comunicação, seja pelo Firefox ou por qual navegador
preferir. Vamos criar um objeto ‘driver’ de uma interface chamada WebDrive,
como pode ser visto na figura 5.7.

capítulo 5 • 123
Figura 5.7  –  Criação do driver no Selenium.

Com o driver criado, podemos começar a implementar o teste funcional

que desejamos. Vamos considerar que queremos testar se uma string de busca
escrita no campo de pesquisar da página do google está retornando os resulta-
dos esperados.
Para isso, observe o HTML do campo “pesquisar” da página do Google, exi-
bido na figura 5.8.

Figura 5.8  –  Código HTML do campo de pesquisa.

Sabendo que a tag ‘name’ é igual ao valor ‘q’, então podemos manipular
o campo de pesquisa com este valor. No nosso exemplo, vamos procurar pela
string “cheese!”.
Observe a figura 5.9 e veja o código que precisamos desenvolver para
esse teste:

124 • capítulo 5
 •  Precisamos instanciar o navegador a ser utilizado, como vimos na figura
5.7;
•  Apontar o driver para o website que será testado (URL do site);
•  Encontrar os elementos da página web;
•  Manipular os elementos;
•  Validar os dados esperados e os dados correntes do conteúdo
dos elementos;
•  Fechar a instância do driver.

Figura 5.9  –  Método de teste no Selenium WebDriver.

Na figura 5.10 podemos ver o resultado da execução desse teste – a página

do Google será aberta e uma busca pela string “Chesse!” é feita.

Figura 5.10  –  Execução do teste no Selenium WebDriver.

capítulo 5 • 125
 O SeleniumWebDriver irá permitir que você crie o caso de teste usando di-
ferentes navegadores e integrando com as funcionalidades de cada navegador
para que você veja a funcionalidade do sistema sendo executada – no nosso
caso, nós conseguimos ver o navegador sendo aberto, a palavra “cheese!” sendo
digitada e assim por diante.
No entanto, para criar casos de teste ainda mais robusto, é importante que
se use o teste funcional com as devidas validações, e para isso uma boa alterna-
tiva é utilizar um framework como o JUnit, que irá te ajudar a criar as devidas
validações dos campos/objetos com o uso das assertivas.
Nem sempre os sites possuem os elementos disponíveis no front-end com
ID’s fixos ou fáceis de serem recuperados por meio de seu nome, por exemplo.
Dessa forma, precisamos de alternativas para recuperá-los com sucesso e as-
sim podermos manipulá-los por meio dos recursos do SeleniumWebDriver.
Algumas dessas alternativas para a recuperação dos elementos são:
•  By ID de um determinado campo no HTML;
•  By Class Name;
•  By Tag Name;
•  By Name;
•  By Link Text;
•  By Partial Link Text;
•  By CSS;
•  By XPATH;
•  Usando JavaScript;

Para mudar de perspectivas como em diferentes janelas ou frames, facil-

mente podemos fazer isso com o uso do switchTo():
– driver.switchTo.window(“windowName”);
– driver.switchTo().frame("frameName");

O que vimos até aqui é um exemplo básico de como criar um caso de teste
com o SeleniumWebDriver. Como sabemos, a melhor forma de aprender pro-
gramação é praticando. Uma vantagem do Selenium WebDriver, como vimos
no início da seção, é que ele possui uma vasta documentação. Sendo assim,
muitos outros exemplos podem ser encontrados na página oficial do selenium:
<http://www.seleniumhq.org/docs/>.

126 • capítulo 5
Sikuli

A ferramenta Sikuli também é uma ferramenta para teste funcional, porém é

baseada em imagem e simula as ações do usuário. Ela possui 2 componentes: a
Sikuli IDE (interface gráfica), que possibilita a escrita de scripts visuais utilizan-
do as imagens de tela (screenshots), e a Sikuli Script que é uma API de scripts
visuais para Jython (uma implementação da linguagem Python que gera byteco-
des para máquinas Java), e é por meio dela que os scripts criados na Sikuli IDE
são processados.
A ferramenta pode ser obtida em:< https://launchpad.net/sikuli/sikulix/>
Códigos customizados também podem ser feitos utilizando a ferramenta
Sikuli com a IDE Eclipse/Netbeans, assim como em projetos Maven para facili-
tar a dependência de bibliotecas, exatamente como vimos na seção de JUnit e
de Selenium.
Como a ferramenta trabalha com imagens, deve-se ter os screenshots dos
objetos/elementos da página que precisaremos ter para identificá-los quando
os testes estiverem sendo executados.
Na figura 5.11 podemos ver um exemplo básico da manipulação dos ele-
mentos da página do Google via programação, utilizando a IDE Eclipse.

Figura 5.11  –  Método de teste utilizando a ferramenta Sikuli.

capítulo 5 • 127
 O objetivo desse teste funcional é verificar se os elementos da página são
encontrados, escrever algum texto no campo de pesquisa do Google e verificar
se a logomarca do Google aparece na tela. Para isso, precisamos implementar:
•  A criação de objeto “screen” para que seja possível identificar os elemen-
tos na tela;
•  App.open para informar a localidade do navegador que iremos executar
os testes;
•  Screen.type para informar o que será digitado em um determinado ele-
mento da página ou mesmo informar uma ação a ser tomada, como por exem-
plo um clique em algum botão;
•  Screen.wait para esperar um certo tempo ou um certo elemento aparecer
na tela.

Para obtermos ainda mais qualidade nos nossos testes funcionais, podemos
também executar testes estruturais, porém para a execução destes devemos ter
acesso ao código fonte da aplicação disponível, como vimos no capítulo 3.
Testes estruturais (caixa branca) são realizados para avaliar o comporta-
mento interno de um componente de software, assim como testes de condi-
ções, testes de fluxo de dados, testes de caminhos e caminhos não executados.
O analista de teste deve ser capaz de analisar todas as possíveis condições para
uma determinada funcionalidade que será testada e criar casos de teste que
cubram essas possibilidades. Com isso, todas as entradas relevantes origina-
das de estrutura de condições serão testadas.
Vamos criar mais casos de testes para garantir que todas as possíveis entra-
das e condições foram testadas. Mas e aí? Como posso medir se meu software
foi 100% testado?
A resposta para isso é: ferramenta EclEmma, que vemos a seguir.

EclEmma

A ferramenta EclEmma (ECLEEMMA, 2016) é uma ferramenta para medir

cobertura de código Java para testes estruturais, extensível ao IDE Eclipse. O
objetivo da EclEmma é mostrar a porcentagem de código fonte que está sen-
do coberta pelos casos de testes executados. Essa ferramenta foi inspirada na
biblioteca EMMA e a partir da versão 2.0 foi baseada na biblioteca JaCoCo de
cobertura de código.

128 • capítulo 5
 A ferramenta EclEmma funciona de forma independente do seu projeto
(como projeto, aqui, vamos entender todo o código fonte do software que está
sendo testado) e pode ser executada a qualquer momento. O download pode ser
feito do site <http://eclemma.org/>.
Sendo assim após inserir a EclEmma no seu projeto, você pode executar os
casos de teste automatizados ou até mesmo executar o sistema por meio da IDE
e executar os casos de teste manuais que, enquanto essa execução acontece, a
EclEmma estará controlando qual linha de código é executada, qual não é exe-
cutada e qual é executada parcialmente.
Observe que a cobertura do código é feita pela EclEmma, mas para saber
se o caso de teste “passou” ou “falhou”, ou seja, se há ou não defeito no siste-
ma, isso depende de como os testes foram executados – se automatizados, a
ferramenta dará essa informação na tela; se manuais, depende de quem estará
executando e da forma como esse registro é feito.
Na figura 5.12 é apresentado um exemplo da interface da EclEmma sendo
utilizada na IDE Eclipse.

Figura 5.12  –  Execução do teste utilizando a ferramenta EclEmma.

capítulo 5 • 129
 Após os testes terem sido melhorados, ou seja, cobrindo maior quantidade
de entradas válidas e inválidas, é preciso executar seus casos de testes como
‘cobertura de código’.
Como resultado, a ferramenta é capaz de colorir as linhas do código fonte
em diferentes cores, cada uma com um significado:

LINHAS DE COR Indica que os testes criados e executados conseguiram

VERDE atingir àquela instrução de código;

LINHAS DE COR Indica que os testes criados e executados não atingem/não

VERMELHA executam aquela instrução; e

Indicam que alguma condição daquela linha de código não

foi atingida/executada pelos testes executados. Para isso,
LINHAS DE COR mais casos de testes devem ser escritos para cobrir tais
AMARELA instruções ou os casos de testes já existentes devem ser
melhorados.

Além da coloração nas linhas de código, um painel é exibido para mostrar a

quantidade, em porcentual, de instruções que foram cobertas. Por padrão, o re-
sultado é aglomerado por classes, mas você pode optar em expandir a exibição
do resultado até em nível de método para a verificação das instruções e desvios
atingidos e não atingidos.
Quando falamos de testes estruturais sempre surge uma pergunta:

PERGUNTA
Quanto de código fonte é preciso testar para garantir que todas as condições foram atingidas?

Obviamente, é altamente recomendável que se teste 100% do código fonte

da aplicação para evitar que algum defeito seja entregue para o cliente. No en-
tanto, como vimos no capítulo 3, há critérios de teste que devem ser aplicados
e dessa forma, podemos ponderar se atingir 100% do código fonte é necessário.
Por exemplo: ao cobrir 50% do código, 100 defeitos foram encontrados. Ao
cobrir 60% do código, 101 defeitos foram encontrados. Ao cobrir 70% do código,

130 • capítulo 5
os mesmos 101 defeitos foram encontrados. Sendo assim, vale a pena conti-
nuar implementando casos de teste estruturais para atingir 100% de cobertura?
Se tivermos tempo, esforço e orçamento “sobrando”, a resposta pode ser sim.
Se algum desses recursos for escasso, você pode tranquilamente optar em ter
70% do código fonte.

5.4  Ferramentas de teste para o ambiente web

Quando o assunto é teste para o ambiente web, além do teste das funcionali-
dades do sistema, vimos no capítulo 3 que outros tipos de teste também são
importantes. Sendo assim, algumas ferramentas foram desenvolvidas para fa-
cilitar esse teste, como é o caso do teste de desempenho.
A automação para o teste de desempenho é uma necessidade do projeto,
pois é preciso medir quais são os limites que os servidores podem aguentar em
relação à quantidade de usuários que podem acessar o sistema ao mesmo tem-
po e também como o sistema vai se comportar nesse ambiente simulado. A
ferramenta JMeter é bastante utilizada para esse tipo de teste.

JMeter

A ferramenta Apache JMeter (JMeter, 2016) é uma aplicação open source,

100% implementada na linguagem Java e seu objetivo é fazer medições de tes-
tes de carga e de performance em sistemas web. Pode ser utilizada tanto para
recursos estáticos quanto dinâmicos (Webservices SOAP/REST), linguagens
web dinâmicas como PHP, Java, ASP.NET etc. Simula grandes cargas em um
servidor, grupo de servidores, rede ou objetos para testar o esforço do servidor.
Algumas características do JMeter são:
•  Realizar testes de performance e de carga com diferentes tipos de
servidores/protocolos:
– Web - HTTP, HTTPS
– SOAP / REST
– FTP
– Banco de dados via JDBC
– LDAP
– Middleware orientado a mensagem (MOM) via JMS
– Mail - SMTP(S), POP3(S) e IMAP(S)
– MongoDB (NoSQL)

capítulo 5 • 131
 – Comandos nativos ou shell scripts
– TCP
•  Total portabilidade e Java 100%
•  Multithread, ou seja, permite concorrência entre threads entre diferentes
funções separadas por grupos de threads

O JMeter disponibiliza um controle de threads, chamado de Grupo de

Threads, no qual é possível configurar o número de threads, ou seja, permite con-
trolar a quantidade de usuários virtuais. Também é possível configurar a quanti-
dade de vezes que cada thread será executada e o intervalo entre cada execução.
Para a realização do teste de carga (quantidade de carga que o servidor su-
porta, pela quantidade de usuários e quantidade de instruções a serem proces-
sadas ao mesmo tempo – ou quase ao mesmo tempo) ou teste de stress (picos
de maior quantidade de carga para testar se determinada quantidade de car-
ga é suportada pelo servidor) é necessário criar um plano de teste. Para isso, o
JMeter disponibiliza os seguintes elementos:

Todos os elementos do plano de teste devem estar sob este

THREAD GROUP grupo, que também controla o número de usuários virtuais;

SAMPLERS São controladores pré-definidos para requisições específicas

CONTROLLERS (inserção de configurações, assertivas etc.);

São controladores mais genéricos e podem ser customizados

LOGIC com a inserção de outros controladores, elementos de confi-
CONTROLLERS guração, assertivas etc.;

São elementos que fornecem acesso às informações obtidas

pelo JMeter durante os testes e que permitirão que o resulta-
LISTENERS do de cada componentes sejam exibidos ao final do caso de
teste;

São elementos que não fazem requisições ao servidor da

CONFIGURATION aplicação (exceto para HTTP Proxy Server), mas podem
ELEMENTS adicionar ou modificar requisições;

132 • capítulo 5
 São elementos utilizados para verificação da igualdade entre
ASSERTIONS a requisição de resposta e a requisição esperada; assim como
as assertions utilizadas pelo JUnit;

São elementos que executam alguma operação antes de

PRE-PROCESSOR fazer a requisição, ou seja, quando esses elementos são
ELEMENTS inseridos no caso de teste, eles serão executados antes das
requisições;

São elementos que executam alguma operação depois de

POST-PROCESSOR fazer a requisição, ou seja, quando esses elementos são
ELEMENTS inseridos no caso de teste, eles serão executados depois das
requisições;

São utilizados para incluir algumas paradas entre as

TIMERS requisições.

A seguir, vamos observar alguns exemplos na execução do teste de carga uti-

lizando a ferramenta JMeter.
Na figura 5.13 pode-se observar o resultado da quantidade de vezes que as
páginas especificadas no campo “Rótulo(Label)” foram acessadas e que são
contadas no campo “Amostras (Samples)” de cada página.

Figura 5.13  –  Execução do teste de carga utilizando a ferramenta JMeter.

capítulo 5 • 133
 Também são mostrados os valores mínimo e máximo do tempo que as pági-
nas gastaram para serem carregadas, assim como o tempo médio, desvio padrão,
porcentagem de erro, vazão e a quantidade de bytes. Com essas informações, po-
demos identificar páginas que demoram mais tempo para serem acessadas. Se
existir a definição do requisito não-funcional sobre performance, podemos até
mesmo definir se o sistema se comporta da forma esperada ou não. Nas figuras
5.14 e 5.15 são exibida outras telas do jMeter que exibem os resultados dos testes
por meio de gráficos, facilitando o entendimento e a comparação.

Figura 5.14  –  Gráfico gerado pela ferramenta JMeter após a execução do teste.

Figura 5.15  –  Servidor utilizado para o teste de carga.

134 • capítulo 5
5.5  Ferramentas de teste para o sistema em produção

Já realizamos testes unitários, funcionais, estruturais, de performance, de

carga e agora o sistema está apto a entrar em produção. O usuário deve ser ca-
paz de utilizar o sistema no seu ambiente de produção? Se os defeitos foram
corrigidos, sim.
Depois de muito trabalho na implementação, verificação e validação das
funcionalidades do sistema, é possível saber quais funcionalidades os usuários
mais usam? Sim!
É bastante importante que a equipe de desenvolvimento implemente a fun-
cionalidade para registro de logs em toda aplicação e que a equipe de testes (ou
equipe de suporte) seja capaz de verificar esses logs em relação às operações/
ações realizadas pelos usuários.
Com acesso aos logs e dependendo de como o registro de logs foi projetado,
é possível identificar não só anomalias no sistema, mas também quais são os
picos de uso do sistema e quais as funcionalidades mais utilizadas.
Outra forma de identificar as funcionalidades mais usadas é por meio do
Teste de Perfil (profiling test).
Testes de perfil são utilizados para verificar quais funcionalidades são mais
utilizadas pelos usuários no dia a dia. Às vezes, muito recurso de teste é preci-
so para garantir a qualidade de uma determinada parte do software, porém o
analista de teste pode não saber a granularidade do uso daquela determinada
funcionalidade pelo usuário em produção e com isso, não direcionar os testes
para as funcionalidades mais utilizadas.
Com o uso do teste de perfil do usuário é possível verificar as partes (fun-
cionalidades) que são mais atingidas (e as menos atingidas também) pe-
los usuários.
Com o teste de perfil do usuário, o analista de teste poderá verificar e medir
qual é a funcionalidade mais utilizada e dessa forma, investir mais esforço nes-
sa parte dos testes. Além disso, pode ser uma boa opção optar em automatizar
os casos de teste das funcionalidades mais utilizadas, o que facilita que todos
os testes sejam executados em cada release.

capítulo 5 • 135
 ATIVIDADES
01. Qual é o tipo de teste que deve ser feito para encontrar e resolver bugs o mais rápido
possível (antes de ser entregue à produção), trazendo menos custo e trabalho para a em-
presa no futuro?

02. O que é preciso para realizar testes unitários com uso do NUnit?

03. Escreva um algoritmo para testar se o resultado de uma tabuada está correto, usan-
do JUnit.

04. Com base no teste funcional, escreva um algoritmo para editar o seu nome em um cam-
po texto fictício de ID “nome” e um botão de ID “confirmar” e valide o resultado com o uso das
assertivas do JUnit que será mostrado em um pop-up (seu nome deverá aparecer na janela
pop-up), com o uso do Selenium WebDriver.

05. Por que é necessário saber qual é a porcentagem de um teste de cobertura?

06. Qual a ferramenta utilizada para medir a cobertura de código Java para testes estrutu-
rais? O que fazer para utilizá-la?

07. Pesquise sobre teste de perfil de usuário.

REFLEXÃO
Neste último capítulo, também o seu último desafio da disciplina, você aprendeu um pouco
sobre ferramentas de teste. Com esses conceitos e exemplos que vimos nesse capítulo atre-
lado com o conhecimento de todos os capítulos anteriores, você está pronto para começar a
implementar seus próprios casos de teste.
Você pode começar a desenvolver seus testes unitários com o JUnit ou NUnit, criar casos
de teste mais robustos usando a Selenium WebDriver, medir a porcentagem de cobertura
dos seus testes com a EclEmma e por fim, realizar testes de desempenho usando a jMeter.
Além dessas ferramentas que conhecemos nesse capítulo é muito importante deixar
claro que muitas outras estão disponíveis no mercado e que provavelmente, muitas outras
ferramentas serão desenvolvidas. O mais importante é que agora você saberá para qual tipo

136 • capítulo 5
de teste cada ferramenta pode ser empregada e saberá como utilizá-las da melhor maneira
nos sistemas que você ajudar a desenvolver.
Esperamos que o que você tenha aprendido aqui na disciplina seja bastante útil não só
no contexto acadêmico, mas também na sua carreira profissional, e que você consiga aplicar
com êxito tudo o que aprendeu sobre teste de software na prática.

LEITURA
Por ser um assunto de grande interesse das empresas que desenvolvem e testam software,
muitos livros estão surgindo sobre o tema. Na literatura nacional podemos encontrar o livro
“Inovação e Automação de Testes de Software” de Leonardo Molinari que pode ser uma
ótima leitura para você se aprofundar um pouco mais nesse universo. Além desse, outros
dois livros são bem interessantes: “Implementing Automated Software Testing: How to Save
Time and Lower Costs While Raising Quality” de Elfriede Dustin, Thom Garrett e Bernie
Gauf e o livro “How Google Tests Software”, de James Whittaker, Jason Arbon e Jeff Carollo.
Como fonte de conhecimento mais detalhado sobre automação de testes, o Núcleo de apoio
à pesquisas em software livre, NAPSol da Universidade de São Paulo – USP, disponibiliza um
curso de longa duração a distância e gratuito <http://napsol.icmc.usp.br/ats/>. Boa leitura!

REFERÊNCIAS BIBLIOGRÁFICAS
ECLEEMMA. EcleEmma. EcleEmma, 27 mar. 2016. Disponível em: <http://eclemma.org/>.
JMETER. JMeter, 27 mar. 2016. Disponível em: <http://jmeter.apache.org/>.
JUNIT. JUnit, 03 27 2006. Disponível em: <http://junit.org/>.
JUNIT. Junit. Junit, 2016. Disponível em: <http://junit.org/>. Acesso em: 15 abr. 2016.
NUNIT. NUnit, 27 mar. 2016. Disponível em: <http://www.nunit.org/>.
NUNIT. NUnit, 27 mar. 2016. Disponível em: <www.nunit.org>.
SELENIUM. Selenium. Selenium, 27 mar. 2016. Disponível em: <www.seleniumhq.org>.
SIKULI. Sikuli. Sikuli, 27 mar. 2016. Disponível em: <www.sikuli.org/>.

capítulo 5 • 137
 ANOTAÇÕES

138 • capítulo 5
ANOTAÇÕES

capítulo 5 • 139
 ANOTAÇÕES

140 • capítulo 5
ANOTAÇÕES

capítulo 5 • 141
 ANOTAÇÕES

142 • capítulo 5
ANOTAÇÕES

capítulo 5 • 143
 ANOTAÇÕES

144 • capítulo 5