Академический Документы
Профессиональный Документы
Культура Документы
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
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.
Prefácio 5
2. Teste no programa 31
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.
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:
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.
10 • capítulo 1
• As disciplinas técnicas desempenharam seu papel de forma adequada
como parte das atividades de SQA?
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):
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.
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.
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 –
capítulo 1 • 15
1 int exemplo_simples(int j) {
2 j = j - 1;
3 j = j / 30000;
4 return j;
5 }
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:
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
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)
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:
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.
Definição de
Requisitos
Projeto de
Software
Implementação
e Teste de Unidades
Integração e
Teste do Sistema
Operação e
Manuteção
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
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
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
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.
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.
capítulo 1 • 27
07. No contexto de teste de software, o que é falha? Dê um exemplo.
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.
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? ”
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):
capítulo 2 • 35
Os defeitos encontrados são corrigidos pelo autor do
RETRABALHO artefato;
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?
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.
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.
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
“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
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.
capítulo 2 • 45
Análise do valor limite
<= 40 > 40
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.
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
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
48 • capítulo 2
Grafo de Fluxo de Controle Detalhamento da representação de cada nó
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.
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
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
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).
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
5
u5(x)
6
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
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.
56 • capítulo 2
Resultados
Casos
de
Teste
Testes
adicionais Causas
suspeitas
Testes de
regressão Depuração
Correções Causas
identificadas
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.
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
Tem como objetivo, como o próprio nome diz, identificar defeitos em rela-
TESTE DE
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
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.
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.
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
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>.
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
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>.
capítulo 3 • 71
Pense num time de futebol (figura
© PIXABAY.COM
3.3): se escalarmos apenas craques e 1
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
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
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.
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.
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?
78 • capítulo 3
© PIXABAY.COM
Figura 3.6 –
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.
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:
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?
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
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.
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:
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 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.
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 –
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
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 – .
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.
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.
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
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
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).
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)
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).
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.
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.
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:
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.
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.
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
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.
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.
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.
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.
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.
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
120 • capítulo 5
Figura 5.5 – Exemplo da interface do NUnit-GUI.
Selenium
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.
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.
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.
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;
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
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
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.
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:
PERGUNTA
Quanto de código fonte é preciso testar para garantir que todas as condições foram atingidas?
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.
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
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
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;
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.
134 • capítulo 5
5.5 Ferramentas de teste para o sistema em produção
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.
06. Qual a ferramenta utilizada para medir a cobertura de código Java para testes estrutu-
rais? O que fazer para utilizá-la?
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