77e27485-a66c-4d07-b9b8-a21613d3290b

Prévia do material em texto

W
BA
08
81
_V
1.
0
TESTE E INSPEÇÃO DE 
SOFTWARE: TÉCNICAS 
E AUTOMATIZAÇÃO
2
Stella Marys Dornelas Lamounier
São Paulo 
Platos Soluções Educacionais S.A 
2021
TESTE E INSPEÇÃO DE SOFTWARE: TÉCNICAS 
E AUTOMATIZAÇÃO
1ª edição
3
2021
Platos Soluções Educacionais S.A
Alameda Santos, n° 960 – Cerqueira César
CEP: 01418-002— São Paulo — SP
Homepage: https://www.platosedu.com.br/
Diretor Presidente Platos Soluções Educacionais S.A 
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Turchetti Bacan Gabiatti
Camila Braga de Oliveira Higa
Giani Vendramel de Oliveira
Gislaine Denisale Ferreira
Henrique Salustiano Silva
Mariana Gerardi Mello
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Henrique Salustiano Silva
Revisor
Marcilyanne Moreira Gois
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Carolina Yaly
Mariana de Campos Barroso
Paola Andressa Machado Leal 
Dados Internacionais de Catalogação na Publicação (CIP)_____________________________________________________________________________________ 
Lamounier, Stella Marys Dornelas
 L236t Teste e inspeção de software: técnicas e 
 automatização / Stella Marys Dornelas Lamounier, – São 
 Paulo: Platos Soluções Educacionais S.A., 2021.
 44 p.
 
 ISBN 978-65-89881-94-0
 
 1. Teste de software. 2. Inspeção. 3. Testes 
 automatizados I. Título. 
 
CDD 005
____________________________________________________________________________________________
Evelyn Moraes – CRB 010289/O
© 2021 por Platos Soluções Educacionais S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser 
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, 
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de 
sistema de armazenamento e transmissão de informação, sem prévia autorização, 
por escrito, da Platos Soluções Educacionais S.A.
4
SUMÁRIO
Introdução a testes de softwares _____________________________ 05
Técnicas de Teste de Software _______________________________ 21
Técnicas de Inspeção de Software ____________________________ 39
Processos e Casos de Testes automatizados _________________ 54
TESTE E INSPEÇÃO DE SOFTWARE: 
TÉCNICAS E AUTOMATIZAÇÃO
5
Introdução a testes de softwares
Autoria: Stella Marys Dornelas Lamounier
Leitura crítica: Marcilyanne Moreira Gois
Objetivos
• Apresentar os conceitos fundamentais sobre testes 
de software.
• Conscientizar os alunos sobre a importância de 
utilizar testes de software no ciclo de vida de um 
sistema.
• Especificar as diferenças verificação e validação de 
testes.
• Apresentar ao aluno as principais técnicas de 
inspeção de software.
6
1. Testes de software, uma visão geral
Desenvolver softwares com qualidade é um desafio para a maioria dos 
profissionais da área de tecnologia. Por mais que se planeje e estude a 
construção de um sistema computacional, erros humanos são passíveis 
de acontecer, porém, é importante ter em mente que esses erros devem 
ser corrigidos e solucionados o quanto antes possível.
Portanto, estudar sobre testes de software fará com que estes erros 
sejam possíveis de serem encontrados, de modo que o profissional seja 
capaz de corrigi-los antes mesmo de serem entregues ao cliente ou 
lançados no mercado.
Nos últimos anos, a indústria de software, principalmente no Brasil, tem 
empregado inúmeros recursos na busca de sistemas com qualidade, 
eficiência e com o mínimo de erros possíveis, visando, assim, redução 
nos custos, tempo de desenvolvimento e manutenção, o que corrobora 
com sua qualidade.
Para isso, adicionar testes de softwares ao ciclo de vida de um sistema 
(requisitos, projeto, codificação, testes e manutenção) se torna cada vez 
mais importante do que testá-lo quando o projeto já se encontra pronto, 
em sua versão final.
Neste cenário, sabemos que o software já tem seu papel importante na 
sociedade, visto que sua criação repleta de erros/ defeitos pode agravar 
situações que envolvem até vidas humanas, como o ocorrido com o 
software Patriot (1991), onde um erro matemático de arredondamento 
numérico calculou de formar incorreta o tempo de projeção para 
detectar e atacar mísseis e, desse modo, o Patriot ignorou a presença 
de mísseis inimigos acarretando a morte de 28 soldados e mais de 100 
feridos. Um outro exemplo, agora somando um prejuízo financeiro, foi 
uma falha no recurso de visualizar como, do Facebook (2018), permitindo 
o roubo das chaves digitais na rede social, onde os dados de mais 
7
de 50 milhões de usuários puderam ser visualizados, possibilitando, 
assim, a invasão de contas e exposição de dados pessoais. Este ataque 
ocasionou, para a empresa, um prejuízo de 13 bilhões em valor de 
mercado.
De acordo com Bohem (1976), quanto mais tarde um defeito for 
identificado, mais elevado é seu custo. Os custos de descobrir e corrigir 
aumentam exponencialmente na proporção em que o trabalho evolui, 
principalmente, na fase de desenvolvimento do projeto, ou seja, quanto 
mais cedo e mais rápido um erro é encontrado, menos dispendioso fica 
sua correção, principalmente, se encontrado na fase de testes.
Boehm (1981) apresenta, na Figura 1, o custo relativo da correção de 
defeitos encontrados em cada uma das atividades de desenvolvimento 
de um sistema.
Figura 1 - Custo relativo para corrigir um defeito
Fonte: adaptado de Pressman (2011, p. 367).
8
Pode-se notar que, no gráfico, estão presentes as principais fases de 
desenvolvimento de um software (requisitos, projeto, codificação, testes 
e manutenção). Se um erro for descoberto nas fases iniciais, como, por 
exemplo, em requisitos, seu custo de correção é mínimo. Quanto mais 
o sistema ganha forma, mais complexo se torna e a descoberta de um 
erro já nas fases finais, como na manutenção, pode onerar seu custo de 
forma significante.
Outro ponto importante é demonstrado por Pressman (2011), na Figura 
2, e se trata do gráfico curva de desgaste, que apresenta, inicialmente, 
uma curva idealizada, demonstrando o software já testado e pronto 
para ser entregue ao cliente. Posteriormente, é exibida a curva real 
que descreve o software sofrendo mudanças ao longo do tempo, 
isto é, durante todo seu processo de vida, essas alterações podem 
ocorrer muito antes que a primeira versão chegue a ser entregue, 
consequentemente, estas mudanças ocorridas ocasionam um aumento 
da taxa de defeitos, deixando que o software não esteja de acordo com 
a versão inicial. Desse modo, é perceptível, na figura, que quanto mais 
o tempo passa, mais falhas o sistema apresenta, introduzindo novos 
problemas
Figura 2–Curva idealizada
Fonte: Pressman (2011, p. 33).
9
Construir sistemas não é uma tarefa considerada simples, vários fatores 
devem ser levados em consideração para que sua complexidade não 
aumente na mesma proporção em que o software é criado. Problemas 
como erro humano são fáceis de serem cometidos, resultando na 
criação de um produto diferente daquele que foi estabelecido na fase de 
levantamento de requisitos. É preciso possuir habilidades que vão desde 
a interpretação até a execução de métodos e ferramentas da Engenharia 
de Software e, mesmo assim, é impossível criar um software livre de 
erros ou defeitos. O que é possível é que, por meio de testes, criar 
sistemas com o mínimo de erros possíveis.
Um exemplo clássico que demonstra o erro real de um algoritmo é o 
cálculo matemático em que se deseja saber a média das notas de um 
aluno. O desenvolvedor pode ter declarado variáveis como tipo inteiro, 
mas o correto seria variáveis do tipo real, uma vez que, haverá médias 
do tipo float (real), outro exemplo neste mesmo algoritmo é a não 
utilização de algumapolítica de segurança que certifique os principais 
pontos da política a ser implementada em um determinado sistema.
Desse modo, é preciso saber avaliar qual técnica é a mais apropriada 
no software a ser desenvolvido e se esta consegue identificar os erros 
e a mal implementação dos algoritmos, verificando classes, métodos, 
procedimentos, funções etc.
Lembrando que o planejamento de testes sempre deve estar de acordo 
com os requisitos levantados no início da criação do projeto, ou seja, o 
planejamento deverá ocorrer quando o documento de requisitos estiver 
sido aceito e antes do início da codificação do sistema.
Outra premissa é a importância de se ter profissionais para realização 
de testes: são os testadores, que tem como responsabilidade prever 
estimativas de atividades de testes, auxiliar a equipe a automatizar e 
desenvolver códigos de testes, garantir que os testes estão de acordo 
com o planejado e construir feedbacks para a manutenção do projeto.
10
2. Defeito versus erro versus falha
É importante saber diferenciar erros, defeitos e falha, o Institute of 
Electrical and Electronic Engineers (IEEE), ou Instituto de Engenheiros 
Elétricos e Eletrônicos, principal órgão responsável pelo fornecimento 
de normas e padrões para a Engenharia elétrica, da Computação 
e Eletrônica, mensura que um Defeito (default) é uma imperfeição 
ou deficiência em um produto de trabalho em que este não atende 
aos seus requisitos ou especificações e precisa ser consertado ou 
substituído, ou seja, demonstra que um artefato de software não está 
trabalhando corretamente, a maioria dos defeitos é ocasionado pela 
falha humana, como, por exemplo: uma instrução ou comando feito de 
maneira erronea.
O erro é caracterizado pela IEEE como a diferença entre um valor ou 
condição computada, observada ou medida, e o valor ou condição 
verdadeira, especificada ou teoricamente correta, ou seja, é a 
apresentação de um resultado incorreto resultante de uma ação 
humana, como mencionado no código abaixo em que a função do 
algoritmo é a soma de dois números inteiros sendo que por algum 
descuido o desenvolvedor digitou o * ao invés de +, alterando a saída 
que seria resultado 6, mas devido ao erro de codificação o resultado 
obtido é 8, gerando um defeito no sistema, isto é, o programa executa a 
multiplicação e não a soma de duas entradas como desejado.
def soma (a, b){
return a * b;
print ( soma(2, 4))
Ainda de acordo com o órgão regulador da IEEE, a falha se refere a um 
resultado operacional do software diferente do que foi especificado ou 
esperado pelo usuário, ou seja, o software é incapaz de executar 
uma determinada tarefa dentro dos limites estabelecidos.
11
Uma falha pode ser causada por diferentes tipos de erros e vários erros 
podem nunca causar uma única falha.
Ainda de acordo com Pressman (2011), é necessário saber identificar 
corretamente erros de defeitos: erros são encontrados internamente, 
antes da entrega para uso em produção, tanto por pessoas da própria 
organização desenvolvedora do software quanto pelo usuário, 
normalmente, durante os ciclos de teste, revisão e apresentações.
Defeitos são encontrados externamente, em ambiente de produção, 
pelo usuário do software. Sua ocorrência também é denominada 
incidente ou incidente em produção.
A Figura 3 demonstra a fronteira de cada um dos termos, divididos cada 
um em seu universo, onde é demonstrado que um defeito pode gerar 
um erro que, posteriormente, ocasiona as falhas que são responsáveis 
por executar algum comportamento inesperado.
Figura 3–Defeitos, erro e falha
Fonte: Engenharia de Software (2007, p. 55).
Lembre-se de que os testes são atividades que devem ser planejadas e 
organizadas com antecedência para que seus processos sejam definidos 
de acordo com um template e técnicas que serão aplicadas no projeto e 
métodos de testes.
12
3. Verificação e validação
Como já mencionado, criar softwares não é tarefa fácil, requer muito 
empenho e conhecimento humano. Erros acabam surgindo no decorrer 
de seu desenvolvimento, mesmo com o emprego de ferramentas e 
métodos da Engenharia de Software. Existe uma série de atividades 
que, além dos testes, devem ser seguidas para que estes erros não 
perdurem, isto é, para serem descobertos antes mesmo da liberação ao 
cliente final, são chamadas de Validação e Verificação ou pela sigla V e V e 
podem ser aplicadas não apenas ao produto final, mas em várias etapas 
durante o ciclo de vida do software, cada fase com sua técnica particular.
Esses dois processos de Validação e Verificação são formas de avaliar, 
demonstrar e controlar a qualidade de um software, avaliando se 
estes processos são capazes de satisfazer tanto a satisfação quanto a 
necessidade definida pelo cliente.
Além de softwares, os processos V e V são capazes de analisar também 
documentos, manuais, modelos e demais artefatos, como também a 
forma de analisar o software, sendo consideradas as análises estáticas e 
análise dinâmicas.
A análise estática reflete sobre a garantia da qualidade do software, não 
é necessário um modelo executável, sendo assim, este tipo de análise 
poderá ser utilizado em todas as fases de desenvolvimento, verificando 
tanto o desenvolvimento, os processos ou o produto.
A análise dinâmica é muito utilizada, como o software já está na fase de 
execução, verificando se as saídas obtidas estão de acordo com saídas 
esperadas.
Segundo Pressman (2011), Verificação e Validação podem ser entendidas 
como:
13
Verificação refere-se ao conjunto de tarefas que garatem que o software 
implementa corretamente a função específica. Validação refere-se a um 
conjunto de tarefas que asseguram que o software foi criado e pode ser 
rastreado segundo um conjunto de requisitos do cliente. (PRESSMAN, 211, 
p.402)
A verificação, segundo o Capability Maturity Model Integration (CMMI), 
ou Modelo Integrado de Maturidade em Capacitação, tem como 
característica garantir que produtos de trabalhos selecionados cumpram 
com seus requisitos solicitados, ou seja, se estamos construindo o 
software de maneira correta por meio de técnicas corretas para sua 
criação, como, por exemplo, o uso correto de diagramas e casos de 
testes, requisitos de software, padrões, práticas.
Pressman (2011), destaca que classificação a verificação, como qualquer 
artefato ou documento de um software, pode ser verificado por meio 
de revisões ou até mesmo uma auditoria, desde que o produto esteja 
seguindo os requisitos especificados.
Uma técnica muito utilizada na verificação de software é a Programação 
em pares, onde dois desenvolvedores trabalham em um mesmo bloco 
de código. Pode-se dizer que existem dois papéis, um é o piloto e ou 
outro, o navegador: o primeiro é o responsável por diligenciar o código, 
enquanto o segundo é o responsável por revisar e analisar todo o 
código, apontando os erros e possíveis melhorias.
Diferente da verificação, a validação é responsável por demonstrar se o 
produto criado ou até mesmo um componente cumpre o uso pretendido 
quando colocado em um ambiente desejado, isto é, se o produto atende 
as necessidades do cliente, se realmente está construindo um sistema 
certo, por exemplo: a criação de protótipos que demonstram ao usuário 
a interface do sistema. Também é possível validar manuais, materiais de 
treinamento, interfaces, modelos, ou até mesmo o próprio software.
14
Na fase de testes podem ser realizados processos de verificação 
e validação, na verificação é realizada uma grande quantidade de 
verificação, onde é possível verificar se os testes estão corretos e 
possuem uma cobertura adequada, enquanto na validação utiliza os 
testes de aceitação, isto é, o cliente e os stakeldors aprovam o software 
(validam), quanto mais verificação e validação for feita, mais chance terá 
de se atender as especificações ou necessidades dos clientes.
Lembrando que não existe técnica certa de se fazer validação e 
verificação, cabe ao responsável pelo projeto aplicar qual modelo se 
adaptaaos processos da empresa.
4. Inspeção de software
Em diversas áreas que abrangem o desenvolvimento de um software, 
muitas são as variáveis responsáveis por sua criação, mas deve-se 
considerar como aspectos importantes o esforço, custo, tempo e 
produtividade no seu desenvolvimento. A medida que o processo de 
desenvolvimento aumenta o seu custo, o retrabalho também aumenta. 
Neste aspecto, é imprescindível criar iniciativas de encontrar formas 
mais precisas de detecção de erros no início da criação de um projeto 
de software, isto pode ser feito utilizando uma técnica que oferece baixo 
custo e qualidade, reduzindo o retrabalho, e é a chamada revisão de 
artefatos.
Um artefato de software é uma subparte do software, é algo que 
compõe o ciclo de desenvolvimento do sistema, que vai desde a fase 
da análise até a entrega do produto final para o cliente, fornecendo 
um documento em que todas as pessoas envolvidas em sua criação 
obtenham informações que coletivamente possam se comunicar a 
respeito do software a ser criado.
15
Podemos citar como artefatos de softwarem vários diagramas da UML, 
como o diagrama de classes, os requisitos levantados para a criação do 
projeto ou até mesmo um caso de uso e outros que já se encontram 
em fase de desenvolvimento, como os módulos, manuais, código fonte, 
plano de avaliação de risco etc. A Figura 4 exemplifica dois modelos de 
artefatos, o caso de uso e, posteriormente, o Diagrama de Classes, todos 
criados pela ferramenta Lucid.
Figura 4–Representação de Artefatos – Diagrama de 
caso de uso e classes
Fonte: elaborada pela autora.
A inspeção de software pode ser caracterizada como a revisão de 
qualquer um artefato de software, é uma técnica capaz de testá-los, 
sendo caracterizado como uma revisão, a fim de detectar os defeitos 
bem definidos. Sua análise é feita de forma estática, capaz de verificar 
a qualidade do sistema por meio de regras, técnicas e processos bem 
definidos. Inúmeras são as técnicas de inspeção existentes, mas todas 
têm como intuito minimizar as inconsistências presentes nos artefatos, 
ou seja, sua principal responsabilidade é de descoberta antecipada de 
falhas.
Ainda segundo Fagan (1986), a inspeção visa encontrar erros, lendo, 
entendendo o que o documento descreve e checando, por meio de um 
checklist, as propriedades de qualidades requeridas, composto por seis 
fases: planejamento, apresentação, preparação, reunião de inspeção, 
retrabalho e acompanhamento.
16
O primeiro registro de inspeção de software foi proposto por Fagan 
(1976), que demonstrava de forma detalhada o processo de revisão. 
A Figura 5 demonstra como é feita a inspeção de software, que tem 
como característica detectar de forma bem definida os defeitos de um 
software. Neste modelo, existem duas presenças principais: o papel e a 
atividade.
Figura 5–Fases da inspeção de software
Fonte: adaptado de Fagan (1976, p. 12-13).
O papel é representado por pessoas, cada uma com uma função, como 
listado a seguir:
Moderador (planejamento e continuação): sua responsabilidade 
é de gerenciamento e orientação aos demais membros da equipe 
de inspeção, também é responsável por realizar o planejamento 
da inspeção, analisando a técnica a ser utilizada, seus documentos, 
selecionar inspetores e distribuir entre a equipe os documentos a serem 
inspecionados e marcar as reuniões. É importante que este profissional 
tenha consigo características de liderança, saiba identificar os pontos 
17
fortes e fracos da equipe. Este papel, na maioria das vezes, está ligado 
ao cargo de gerente de qualidade.
Inspetor (preparação individual): durante o processo de 
desenvolvimento de um software são gerados inúmeros documentos 
que devem ser inspecionados, este é o papel do inspetor, são 
profissionais que detém um grande conhecimento sobre o projeto, 
estudando cada artefato individualmente, procurando possíveis defeitos 
que, posteriormente, são repassados ao moderador. Este papel pode 
ser desempenhado por engenheiros de qualidade ou testadores de 
software.
Autor (retrabalho): são os profissionais responsáveis por produzir 
todos os documentos (artefatos) referentes ao sistema, ao longo de seu 
desenvolvimento. A construção destes artefatos deverá ser realizada 
sempre de forma objetiva e clara, facilitando a inspeção. Tem como 
outra responsabilidade corrigir defeitos encontrados pelos inspetores e 
confirmados pelo moderador, desse modo, após a correção, o material 
é reenviado ao moderador que o analisa e qualifica a qualidade do 
artefato inspecionado. Um autor pode ser um analista de sistema, 
clientes ou desenvolvedor de software.
As atividades no processo de Inspeção de software são divididas em 
cinco principais etapas:
Planejamento: esta fase é de responsabilidade do moderador que 
tem como objetivo organizar a equipe que participará do processo de 
inspeção, separa os materiais a serem inspecionador e define o local 
para as reuniões.
Preparação individual: os inspetores são responsáveis por analisar 
cada material de forma individual, criando anotações e listar possíveis 
inconsistências.
18
Reunião de Inspeção: o intuito é analisar e acertar as divergências 
encontradas no processo e se realmente são verdadedeiras, a presença 
do moderador, do inspetor e do autor é imprescindível neste momento.
Retrabalho: são corrigidos pelo autor os defeitos encontrados e 
repassados ao moderador.
Continuação: todos os artefatos e documentação corrigidas na etapa 
de retrabalho são repassadas ao moderador, que é o responsável por 
decidir se aquele artefato deve ou não ser inspecionado novamente.
Por que é tão importante inspecionar software?
Empresas que desenvolvem software gastam, em média, com um 
esforço de retrabalho, cerca de 50% do esforço total no desenvolvimento 
de um projeto, o ideal seria redividir este retrabalho em pequenas 
atividades, como ilustrado na Figura 6.
 
Figura 6–Inspeção em diferentes artefatos
Fonte: adaptado de Kalinowski (2004, p.16).
Cada uma das etapas (requisitos, projeto de alto nível, projeto 
detalhado, código, execução dos testes, plano de testes, caso de testes) 
representa um artefato de software que pode ser inspecionado. É 
19
importante lembrar que desde o início da criação de um software, no 
lavamento de requisitos, é importante realizar a inspeção.
Se a inspeção for realizada em etapas menores, é possível obter 
bons resultado. A Figura 7 demonstra um comparativo de custo no 
desenvolvimento de um software, quando as inspeções são aplicadas e 
quando não se utiliza as técnicas.
Figura 7–Comparativo na aplicação e não aplicação 
das técnicas de inspeções
Fonte: adaptado de Kalinowski (2004, p. 21).
Portanto, inspecionar software envolve e rigoroso planejamento e 
interação entre pessoas que revisam os artefatos e reuniões, para 
discutir e diagnosticar defeitos, para que o autor do artefato possa 
corrigir a tempo de criar uma avaliação final sobre a necessidade ou não 
de uma nova inspeção.
Isso pode trazer diversos tipos de benefícios, como, por exemplo: 
produtos mais inteligíveis, aprendizado, integração.
20
Referências
BOEHM, B. W. Software Engineering. ACM, v. 30, n. 5, p. 416-429, 1976.
BOEHM. B. W. Software Engineering Economics. Prentice Hall, 1981.
FAGAN, M. E. Design and code inspections to reduce errors in program 
development. IBM System J., v. 15, n. 3, p. 183-211, 1976.
FAGAN, M. E. Advances in software inspections. IEEE Transactions on software 
engineering, [s.l.], v. 12, n. 7, 1986. Disponível em: http://www.mfagan.com/pdfs/
aisi1986.pdf. Acesso em: 22 jun. 2021.
FAGAN, M. E. Design and code inspections to reduce errors in program 
development. IBM System J., v. 15, n. 3, p. 183-211, 1976.
KALINOWSKI, M. Infraestrutura computacional de apoio ao processo de 
inspeção de software. Dissertação de Mestrado, programa de pós-graduação de 
Engenharia. Rio de Janeiro: Universidade Federal do Rio de Janeiro, 2004. Disponivel 
em: https://www.cos.ufrj.br/uploadfile/publicacao/2087.pdf.Acesso: 23 jun. 2021.
KALINOWSKI, M. Introdução à Inspeção de Software. Revista Engenharia de 
Software: qualidade de software, v. 1, 2008.
LUCID SOFTWARE INC.2021. Disponível em: https://www.lucidchart.com/pages/pt. 
Acesso: 18/04/2021.
NETO, A.; DIAS, C. Introdução a teste de software. Engenharia de Software 
Magazine, v. 1, p. 22, 2007.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed., 
McGraw-Hill. Porto Alegre: BookMan, 2011.
SOFTWARE. Inspections: an industry best practice. IEEE Computer Society. 1996.
WHEELER, D. A.; BRYKEZYNSKI, B.; MEESON, R. N. Software inspections: an industry 
best practice. IEEE Computer Society, 1996.
http://www.mfagan.com/pdfs/aisi1986.pdf
http://www.mfagan.com/pdfs/aisi1986.pdf
https://www.cos.ufrj.br/uploadfile/publicacao/2087.pdf
https://www.lucidchart.com/pages/pt
21
Técnicas de Teste de Software
Autoria: Stella Marys Dornelas Lamounier 
Leitura crítica: Marcilyanne Moreira Gois
Objetivos
• Apresentar as atividades de testes de software.
• Abortar as principais estratégias de técnicas de 
testes.
• Compreender os níveis de testes e sua relação com 
o desenvolvimento de software.
• Apresentar técnicas e ferramentas de testes.
22
1. Introdução a técnicas de software
Muitas vezes, o desenvolvimento de software pode ser uma tarefa 
complexa, o levantamento de requisitos de forma objetiva e eficiente é 
essencial para o desenvolvimento de software e a satisfação do cliente.
O desenvolvimento de software tem buscado incansavelmente a 
produção de sistema que agregue qualidade e custo-benefício, desse 
modo, são importantes atividades de testes de software, buscando o 
desenvolvimento de sistemas com maiores qualidade e custo-benefício.
Neste contexto, os testes de software são ferramentas de extrema 
importância para que o desenvolvimento evolua, de forma que quanto 
menos erros forem apresentados, maior será a garantia de qualidade 
demonstrada. Esses testes não podem ser apenas meros coadjuvantes 
no ciclo de vida do software, deverão estar implementados de forma que 
suas funcionalidades sejam dotadas de técnicas e métodos, assegurando 
maior controle das atividades e, consequentemente, aumentando o nível 
de qualidade e a satisfação dos clientes. Para isso, é necessário adotar 
atividades e técnicas de testes de software, desde sua fase de concepção 
até sua entrega, para garantir a qualidade total do produto.
É importante ressaltar a importância de se ter um ambiente de testes, 
de forma a assegurar que sejam alcançados os melhores resultados. A 
Figura 1 ilustra como é dividido este ambiente, em que cada parte possui 
um tipo de teste particular, com suas devidas responsabilidades.
23
Figura 1–Ambientes de testes
Fonte: Rios; Moreira (2013, p. 128).
A realização destes testes em ambientes distintos tem características 
assegurar que o projeto seja desenvolvido com alto padrão de 
qualidade, independente da fase em que esteja.
De acordo com Martins e Moreira (2013), em um ambiente de testes, 
cada membro da equipe possui um papel, mas cabe ao arquiteto de 
testes preparar o ambiente para sua execução, montando de forma 
coordenada o ambiente. A equipe será responsável por executar o 
trabalho, escolher de forma correta as ferramentas a serem utilizadas.
2. Fases das atividades de testes
Atividades de testes, inúmeros fatores podem colaborar para que os 
erros aconteçam, e estes erros podem estar presentes em qualquer 
fase da criação do sistema, mas, antes mesmo de se falar nas técnicas 
apropriadas a serem empregadas, durante as atividades de testes, é 
importante ter em mente que estas atividades são divididas em fases 
e que cada uma delas tem um papel crucial para que o software possa 
24
ser entregue com a qualidade esperada, ou seja, com o mínimo de erros 
possíveis.
De forma geral, podemos elencar estas atividades em três fases 
distintas: testes de unidade, teste de integração, teste de sistemas, 
conforme apresentado na Figura 2.
Figura 2–Pirâmides de testes de software
Fonte: Bortoluci; Duduchi (2015, p. 3 apud COHN, 2013, [n. p.]).
Na parte inferior da pirâmide estão os testes unitários, são as atividades 
responsáveis por testar cada unidade do sistema separadamente; no 
meio encontram-se as atividades de testes de integração, responsáveis 
por testar a integração dos módulos do sistema; e por fim, no topo da 
pirâmide, encontram-se os testes de sistemas, responsáveis por analisar 
se o software como um todo está de acordo com os requisitos funcionais 
e não funcionais levantados, a seguir o detalhamento de cada atividade.
O teste de unidade ou unitários tem como objetivo testar pequenas 
unidades em um sistema, ou seja, verificar pequenas unidades que 
compõem o sistema. Cada parte é testada isoladamente, verificando 
se está de acordo com o que foi levantado, geralmente, a pessoa 
25
responsável por sua realização é o próprio desenvolvedor, que tem 
propriedade testar as classes ou métodos implementados. Pode-se 
dizer que um teste unitário corresponde a um trecho de código que 
executa outro trecho de código e verifica se está tudo correto. A a Figura 
3 demonstra como é executado o teste unitário em classes, utilizando 
orientação a objetos.
Figura 3–Classe calculadora
Fonte: elaborada pela autora.
A Figura 4 representa uma classe denominada calculadora, que tem 
como funcionalidade calcular a soma entre números no método Somar 
( ), posteriormente, é feito o teste unitário com a criação de uma outra 
classe, chamada de Testa_Calculadora, como representado na Figura 3.
Figura 4–Teste Unitário na classe Testa_Calculadora
Fonte: elaborada pela autora.
Na figura, é ilustrada a classe de teste de unidade, onde é criado um 
método denominado Testa_Soma ( ), com responsabilidade de testar se 
a soma realizada na classe calculadora está sendo realizada de forma 
correta ou não.
Após a realização dos testes nas unidades separadas, devem-se realizar 
os testes de integração, responsáveis por verificar se estas unidades 
26
quando combinadas se comunicam corretamente, ou seja, observar se a 
junção destas não possuem erros que podem comprometer o sistema. 
Nesta atividade, é preciso ter um grande conhecimento sobre o sistema. 
Desse modo, sua execução fica a cargo da equipe de desenvolvimento.
As atividades de testes de integração devem estar realizadas quando:
Após serem testados as unidades individualmente, a ênfase é dada na 
construção da estrutura do sistema. À medida que as diversas partes são 
colocadas para trabalhar juntas, é preciso verificar se a interação entre 
elas funciona de maneira adequada e não leva erros. (DELAMARO; JINO; 
MALDONADO, 2013, p. 3)
Por fim, os testes de sistemas, também conhecidos como testes de 
interface com o usuário, compõem as atividades que verificam se todos 
os requisitos estão de acordo com o especificado e se foram realmente 
atendidos. Isso ocorre após a revisão de todos os componentes, ou seja, 
essa atividade verifica se o que foi especificado está sendo atendido 
ou atinja um padrão de qualidade que proporciona o aumento da 
probabilidade de ser adquirido pelo usuário final.
Também tem como finalidade analisar interações de um site, um 
programa ou aplicativo, por meio do uso dos botões, barras de tarefas, 
padrão de cores e fontes. Essas atividades correspondem a inspecionar 
as funcionalidades do software, se são fáceis e claras para uso, se 
possuem uma interface amigável e a não presença de erros que podem 
ser visualizados pelo usuário.
Alguns parâmetros devem ser verificados pelo profissional que 
executará essa atividade: padronização de cores e fontes, estilos de 
ícones, preenchimento de campos obrigatórios, atalhos, padronização 
de botões e ícones, tipos de dados, instrução de telas etc.
De acordo com Delamaro, Jino e Maldonado (2013, p .4), é recomendado 
também realizar os testes de regressão, como uma atividade realizada 
27
na etapa de manutenção de software. Um sistema ao longo de seu 
ciclo de vida sofrealgum tipo de manutenção, sendo assim, é possível 
apresentar algum tipo de erro ou defeito durante o processo de 
modificação. Neste contexto, é fundamental a utilização dos testes de 
regressão, a fim de detectar se estes reparos possuem algum tipo de 
problema, isto é, verificar se as implementações estão de acordo com 
os novos requisitos e que os requisitos anteriores ainda se encontram 
válidos.
Os testes de regressão são importantes devido a sua responsabilidade 
de garantir que as manutenções ou implementações de novas 
funcionalidades, realizadas ao longo do tempo, não insiram novos erros 
que podem comprometer toda a qualidade do software. Um exemplo 
da utilização deste teste é quando o desenvolvedor modificar o código 
fonte e acrescenta uma nova funcionalidade, posteriormente, o teste é 
executado, a fim de verificar falhar até então inexistentes.
3. Técnicas de testes de software
Independentemente do tipo de projeto ou aplicação que o profissional 
esteja trabalhando, é preciso entender de forma bem objetiva a 
importância de utilizar a técnica correta e que mais se adapta ao tipo 
de sistema a ser testado. Inúmeras são as técnicas que podem ser 
realizadas para avaliar diferente aspectos, responsáveis em evitar que 
o sistema apresente bugs ou retorne alguma notificação inesperada, o 
que geraria grande frustração por parte do cliente. Destacaremosestaca 
algumas técnicas importantes ao longo do texto.
3.1 Testes de usabilidade
Durante o processo de desenvolvimento de uma aplicação, é frequente 
a apresentação de erros. Os testes de usabilidade são realizados 
28
durante toda a fase de criação do software por profissionais que são 
responsáveis pelo seu desenvolvimento. Uma das formas de tentar 
minimizar erros e garantir um software de qualidade é garantir que a 
usabilidade esteja empregada no sistema por meio da realização de 
testes de usabilidade.
É fundamental antes de entrar no processo de testes de usabilidade, 
destacar o que é usabilidade:
A usabilidade é a característica que determina se o manuseio de um 
produto é fácil e rapidamente aprendido, dificilmente esquecido, não 
provoca erros operacionais, oferece alto grau de satisfação para seus 
usuários e resolve eficientemente as tarefas para as quais ele foi projetado. 
(FERREIRA, LEITE, 2003, p. 3)
O termo usabilidade é utilizado para facilitar a execução de uma 
tarefa específica, recurso ou ferramenta, demonstrada de forma clara 
e simplificada, ou seja, ao serem executadas não devem chamar a 
atenção para si, mas para a facilidade de sua utilização, aprendizagem 
e satisfação na sua operação pelo usuário. A usabilidade é relacionada 
à eficácia e eficiência da interface diante do usuário e pela reação do 
usuário diante desta.
Os testes de usabilidade seguem esta linha, avaliar o grau de satisfação 
do usuário, avaliar a experiência do usuário com o software, onde os 
participantes envolvidos são capazes de avaliar o grau de satisfação 
na utilização do sistema, se seus critérios estão de acordo com a 
usabilidade pretendida, registrando a consistência da interface, layout, 
acesso às funcionalidades, entre outras. Também é possível obter os 
melhores resultados para que, em uma aplicação futura, seja aplicada, 
minimizando custo e tempo.
São diversas ferramentas para os testes de usabilidades, umas bem 
simples e objetivas, como checklist e formulários, como mostrado no 
exemplo abaixo, em que é possível identificar no formulário para a 
29
realização de testes de usabilidade, o número de participantes (público-
alvo), demonstrar um cenário especifico, criar tarefas e elaborar as 
perguntas objetiva e precisas.
Exemplo:
Número de participantes: 15.
Cenário: Uma empresa de desenvolvimento de software recrutou 
pessoas para realizar uma análise em um site de e-commerce.
Tarefas:
• Visite a página inicial por 20 segundos e diga o que achou.
• Abra uma conta.
• Realize a compra de um produto.
• Insira a forma de pagamento.
• Finalize a compra.
Perguntas
1. Conseguiu realizar a tarefa rapidamente?
2. Quantas páginas o usuário teve que visitar para realizar o 
cadastro?
3. Quantas páginas o usuário teve que visitar para realizar a compra?
4. Qual é a impressão que o usuário tem sobre o site, ao final do 
teste?
5. As fontes e cores do site são legíveis ou prejudicam o usuário na 
realização da tarefa?
6. Os usuários apreciaram o site? Recomendaria esse sistema para 
seu amigo? (0=Não e 10=Com certeza)
30
Público-alvo: usuários que tenham que já realizam compras on-line 
há mais de cinco anos e estão entre 20 e 45 anos, sexo feminino e 
masculinho, renda mínima de três salários mínimos.
Uma boa prática para a realização destes testes é recrutar pessoas 
desconhecidas, que entendem da regra de negócio, o que evita a 
formação de opiniões participais, facilitando a realização das tarefas de 
forma a se descobrir possíveis erros.
Portanto, deve-se ter em mente que não existe apenas esta técnica 
para ser utilizada em testes de usabilidade, é possível utilizar sistemas 
automatizados que garantem também eficiência e eficácia nas tarefas 
realizadas.
3.2 Teste funcional ou de caixa preta
O teste funcional também é amplamente conhecido como teste de 
caixa preta, possui este nome por não depender do conhecimento do 
comportamento interno do software, isto é, para sua compreensão, 
o testador não precisa ter um conhecimento técnico do código fonte 
desenvolvido, mas, ao mesmo tempo, precisa ser detentor de alto 
conhecimento das funcionalidades que operam todo o sistema. Sua 
estrutura é definida de acordo com os requisitos funcionais do software, 
baseando-se nas especificações onde as saídas desejadas devem 
estar de acordo com o esperado, por isso, não se deve levar em conta 
detalhes de sua construção, como módulos, classes, código fonte.
Testes de caixa preta são, na maioria das vezes, utilizados para verificar 
a perspectiva do usuário, realizando a verificação e correção do sistema 
com base nos seus requisitos funcionais, que, na maioria das vezes, são 
capazes resolver erros de interface, comportamentos, erros de iniciação 
ou término de um sistema, como, por exemplo, um sistema que aceita 
apenas números inteiros positivos em seus campos. A Figura 5 ilustra 
31
como é executado o teste de caixa preta, por exemplo, um sistema que 
em um dos seus campos aceita apenas como entrada números inteiros, 
o testador realiza os testes com números negativos ou decimais para 
verificar se o requisito está funcionando conforme o especificado: deve-
se preencher o campo apenas com números inteiros, os passos em 
que o testador verifica a entrada com números decimais ou números 
negativos e espera uma resposta sobre esta verificação, ou seja, se o 
sistema aceita apenas o que foi especificado. Desse modo, nota-se que o 
teste tenta buscar os erros que o usuário pode cometer.
Figura 5 –Teste funcional ou caixa preta
Fonte: elaborada pela autora.
Teste funcional ou de caixa preta são baseados em especificações 
e consideram apenas entradas aceitas pelo componente (função) e 
saídas esperadas. Visa identificar anomalias de código, interfaces, 
fontes de dados e performance, preocupando-se apenas com critérios 
fundamentais dos sistemas e não com sua estrutura lógica interna.
Alguns critérios podem ser adotados para os testes funcionais, entre 
eles, destacam-se o particionamento de equivalência e a análise de valor 
limite.
3.2.1 Particionamento por equivalência
Segundo Delamaro, Jino e Maldonado (2013), o particionamento por 
equivalência tem como finalidade tornar a quantidade de dados a serem 
testadas finitas, diminuindo drasticamente o tempo com testes que, por 
32
muitas vezes, se tornam complexos e repetitivos. Este critério divide a 
entrada nas chamadas classes por equivalência e, desse modo, após a 
definição destas classes, pode-se assumir que qualquer elemento da 
classe pode ser considerado um representante fiel dela e qualquer um 
destes elementos tem o poder de secomportar de forma similar, isto é, 
caso apresente algum erro, qualquer outro elemento também detecta 
este erro, caso não tenha a detecção, nenhum outro também detectará.
Suas classes são definidas por um conjunto de classes válidas e 
inválidas, como meio de entrada para testes, geralmente, sendo 
apresentadas uma classe válida e duas classes inválidas.
Após a identificação das classes válidas e inválidas, é necessário 
determinar os casos de testes, de modo ao escolher um elemento da 
classe que gere um novo caso de teste responsável por englobar o maior 
número de classes possível, conforme mensurado no exemplo abaixo.
Um campo de entrada (input field) referente ao ano de aniversário aceita 
valores de 1900 até 2020. A Figura 6 demonstra as classes válidas e 
inválidas do exemplo.
Figura 6–Particionamento por equivalência
Fonte: elaborada pela autora.
Após feito o particionamento por equivalência, é fundamental a 
realização do caso de teste para que haja uma maior cobertura dos 
testes, conforme ilustrado no Quadro 1.
33
Quadro 1–Caso de teste
Caso de teste 
(nome)
Valores Status
C1 2000, 1984,1901 Válido.
C2 1277, 1899 Inválido.
C3 2029, 2021 Inválido.
Fonte: elaborado pela autora.
Portando, os testes de caixa preta demonstram que é impossível testar 
exaustivamente todas as entradas de um programa, sendo possível 
por meio dele obter a mesma qualidade, utilizando uma quantidade 
de testes efetivos e capazes de cobrir as possíveis entradas, a fim de se 
obter os resultados esperados
3.2.2 Análise de valor limite
A análise de valor limite é utilizada para teste de valores com intervalos 
numéricos, onde é possível descobrir os limites do campo que se deseja 
testar, ou seja, que seja capaz de testar um valor inferior ao limite, o 
valor limite e, finalmente, o valor superior, sendo um complemento dos 
resultados obtidos do particionamento por equivalência.
Vale ressaltar que a análise obtém um grande conjunto de dados de 
entrada e o divide em pequenos subconjuntos e, ao invés de escolher 
os dados a serem testados de forma aleatória, devem ser selecionados 
considerando o valor limitante de cada uma das classes de equivalência. 
O exemplo mostrado no quaer abaixo relata, de forma simples, como é 
feita a utilização desse modelo de teste.
34
Um campo de entrada (input field) referente a idade aceita valores maior 
igual a 18 anos e menor igual a 60 anos, conforme ilustrado no Quadro 2.
Quadro 2–Técnica do valor limite
Intervalo de valores 
inválidos (Inferior)
Intervalo de 
valores válidos
Intervalo de valores 
Inválidos (Superior)
15, 16, 17 18, 19, 20........58, 59, 60 61, 62, 63, 64.....
Fonte: elaborado pela autora.
O exemplo demonstra que é preciso testar apenas um valor inválido 
para inferior e posterior, isto é, o resultado não se modificará se 
testarmos valores que não estejam no limite do valor inválido, então, 
deve-se testar apenas a idade 17 (inferior) e 61 (superior) para intervalos 
inválidos e para o intervalo válido 18 e 60 anos de idade.
3.3 Testes estrutural ou de caixa branca
Diferentes dos modelos apresentados anteriormente, os testes 
estruturais estão preocupados com o fluxo do código fonte dos 
sistemas, sendo que o profissional (testador) deve ter conhecimento do 
código fonte a ser testado.
Este modelo apresenta como característica avaliar o comportamento 
interno do sistema, analisando o comportamento do software, a fim 
de avaliar o fluxo de dados condições, caminhos lógicos a serem 
percorridos.
(1) Utilizando métodos de caixa-branca é possível criar casos de testes que: 
garantem que todos os caminhos independentes de um módulo foram 
exercitados pelo menos uma vez, (2) exercitam todas as decisões nnos 
seus estados verdadeiro e falso, (3) executam todos os cilcos em seus 
35
limites e dentro de suas fronteiras operacionais, e (4) exercitam estruturas 
de dados internas para assegurar a sua validade. (PRESSMAN, 2011, p. 431.
Uma técnica de caixa branca comumente utilizada é o teste de caminho 
básico, onde o projetista de software pode medir a capacidade lógica 
de um projeto e utilizá-la para guiar o número de caminhos a serem 
executados. Nesse contexto, é possível executar pelo menos uma vez as 
instruções de um programa.
Este modelo é, em sua essência, uma notação de grafo de fluxo, 
onde temos as arestas ilustradas pelas setas no grafo, e sua função 
é representar o fluxo de controle do grafo e são análogas ao fluxo de 
controle do grafo. Temos também a presença do nó do grafo, representa 
um ou mais comandos procedurais. As arestas sempre terminarão 
em um nó, independente se este nó apresenta ou não uma condição 
(PRESSMAN, 2011, p. 432). A Figura 7 ilustra a notação sobre o grafo de 
fluxo.
Figura 7–Construções estruturadas no grafo de fluxo
Fonte: Pressman (2011, p. 432).
Com a análise do fluxo do grafo, é possível realizar o teste de caminho 
básico, um exemplo da sua utilização é demonstrado na Figura 7.
36
Para realizar a análise, é preciso ter ciência do que se refere a 
complexidade ciclomática, sendo uma regra que mede o número de 
fluxo que um código pode seguir, ou seja, quantos testes devem ser 
executados para a verificação de todos os fluxos que o código fonte deve 
tomar para que seja garantida toda a cobertura necessária de testes. 
Seu cálculo matemático é expresso por:
V(G)=Arestas–Nós+2
Nesse cálculo, as arestas são as setas do grafo e nós, os círculos. 
Vejamos o exemplo mostrado na Figura 8
Figura 8–Pseudocódigo–Saque
Fonte: elaborada pela autora.
A figura representa um pseudocódigo simples para saque em um caixa 
eletrônico, conforme os passos descritos:
1. Início do grafo: onde o usuário digira o valor do saque no campo 
de entrada, posteriormente, o sistema lê este valor.
37
• O saldo do cliente é de 2000,
Passa-se para a próxima etapa:
2. Se o saque for menor ou igual ao saldo, o caminho é percorrido 
pelo lado 2.
3. Ao contrário, é percorrido o caminho 3.
4. Independente do caminho a ser percorrido (2 ou 3), o algoritmo 
terminar a no nó 4 (fim algoritmo).
A partir deste pseudocódigo, é possível criar o grafo como mostrado na 
Figura 9.
Figura 9–Fluxo de Grafo
Fonte: elaborada pela autora.
Aplicando a notação matemática da complexidade matemática, é 
possível chegar ao seguinte resultado:
V(G)=Arestas- Nós+2 => 4 – 4 + 2 => 2
Desse modo, podemos concluir que, no algoritmo mencionado, é 
possível a realização de dois testes de caminho básico, isto é, há dois 
caminhos que podem seguir para se obter um resultado.
38
Nesse sentido, pode-se observar que as técnicas de software 
podem trazer várias vantagens para auxiliar nas condução de testes, 
possibilitando eliminar ambiguidades ou talvez reduzir o tempo de 
testes. Além disso, também traz uma elaboração rigorosa no que o 
sistema realmente fazer, são diversos métodos a serem utilizados, 
resultando em casos de testes a partir do modelo escolhido, devendo 
levar em conta a adaptação do método escolhido ao sistema a ser 
testado.
Referências
BORTOLUCI, R.; DUDUCHI, M. Um estudo de caso do processo de testes 
automáticos e manuais de software no desenvolvimento ágil. In: X Workshop de 
Pós-Graduaçao e Pesquisa do Centro Paula Souza. 2015.
DELAMARO, M.; JINO, M.; MALDONADO, J. Introdução ao teste de software. Rio de 
Janeiro: Elsevier Brasil, 2013.
FERREIRA, S. B. L.; LEITE, J. C. S. do P. Avaliação da usabilidade em sistemas 
de informação: o caso do sistema submarino. Revista de Administração 
Contemporânea, v. 7, n. 2, p. 115-136, 2003. Disponível em: https://rac.anpad.org.
br/index.php/rac/article/view/220. Acesso em: 24 jun. 2021.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional, 7. ed., 
McGraw-Hill., Porto Alegre: BookMan, 2011.
RIOS, E.; MOREIRA, T. Teste de software. Rio de Janeiro: Alta Books, 2013.
https://rac.anpad.org.br/index.php/rac/article/view/220
https://rac.anpad.org.br/index.php/rac/article/view/220
39
Técnicas de Inspeção de Software
Autoria: Stella Marys DornelasLamounier 
Leitura crítica: Marcilyanne Moreira Gois
Objetivos
• Apresentar as atividades de testes de software.
• Abortar as principais estratégias de técnicas de testes.
• Compreender os níveis de testes e sua relação com 
o desenvolvimento de software.
• Apresentar técnicas e ferramentas de testes.
40
1. Introdução a técnicas de Inspeção de 
Software
Para garantir sistemas que possam satisfazer as perspectivas dos 
usuários, é preciso seguir dois objetivos fundamentais:
1. Construir sua qualidade desde o início, iniciando na fase de 
levantamento de requisitos, nos quais devem ser claramente 
documentados e especificados. 
2. A qualidade do software deve ser seguramente mantida ao 
longo de todo o ciclo de vida do software (análise, projeto, 
implementação, integração e operação).
Seguindo esses objetivos, é possível reduzir o custo com a correção 
de defeitos que aumenta exponencialmente a medida que o software 
se torna mais complexo, por isso, é importante encontrar defeitos o 
quanto antes e, para isso, as inspeções de software, segundo Fagan 
(1976), têm se mostrado eficientes, reduzindo custos e retrabalho e, 
consequentemente, aumentando a qualidade do sistema.
Antes de aplicar as técnicas de inspeção, devemos, primeiramente, saber 
distinguir inspeção de testes de software, por mais que os dois possuam 
características semelhantes, se completam, isto é, juntos trabalham na 
remoção de erros como relatado:
A inspeção encontra defeitos não encontrados em teste e teste encontra 
defeitos não encontrados na fase de inspeção ou que tenham sido 
inseridos depois da fase de Inspeção. (PAGLIUSO; DE ANDRADE; VILLAS-
BOAS, 2002, p. 107)
A inspeção é uma técnica de revisar artefatos de software e documentos, 
de modo a verifcar insconsistências de cada um, independente da fase 
de desenvolvimento. Pode-se verificar desde o código fonte, diagramas 
da UML ou documentos de requisitos. Esta técnica é considerada 
41
estática, pois não é necessário que o sistema seja executado para sua 
aplicação, possuindo, assim, processos muito bem definidos.
Já os testes de softwares, são considerados modelos dinâmicos, ou seja, 
para a detecção de defeitos, muitas vezes, é necessário que o software 
seja executado.
Conforme citado, ambas as técnicas caminham juntas, mas cada uma 
capturam defeitos diferentes e em diferentes fases de desenvolvimento 
do software, desse modo, é sempre importante a aplicação das duas 
técnicas, a fim de identificar possíveis erros nos artefatos.
Uma das principais características da inspeção é que para sua execução, 
não necessariamente precisa de uma versão do código fonte já 
implementada, os defeitos identificados podem ser removidos antes 
antes de se passar para a etapa de desenvolvimento.
A Capability Maturity Model Integration (CMMI) ou Modelo de Capacidade 
e Maturidade Integrado, é caracterizado um modelo de referência para 
boas práticas e diretrizes na melhoria no processo de desenvolvimento 
de sistemas, seu objetivo é auxiliar empresas de software a melhorar o 
desenvolvimento e manutenção de seus produtos e serviços, tornando-
as mais maduras. Essas práticas, segundo a Software Engineering Institute 
(SEI), a qualidade do software está amplamente ligada a qualidade do 
processo que o desenvolve.
A CMMI defende a prática de inspeção com o objetivo de assegurar a 
qualidade do produto e do processo, pois, uma vez os dados coletados, 
serão utilizados para a correção de defeitos bem como para uma 
melhoria contínua no processo de desenvolvimento do software.
Segundo Sommerville (1996), para introduzir a inspeção nestes 
processos de software, uma organização pode considerar as seguintes 
sugestões:
42
• Selecionar uma lista de prováveis erros no início do processo e ir 
alimentando de acordo com seu surgimento.
• Maior prepação da equipe, mesmo que considerada pequena, com 
treinamentos para a utilização destas técnicas.
Revisões
Existem várias maneiras de se realizar as revisões em um software. Um 
exemplo bem simples é realizar pequenas reuniões na hora do café, 
em uma empresa de desenvolvimento, onde são trocadas informações 
relevantes e as técnicas discutidas neste ambiente, mas não se limita 
a apenas isso. Segundo Pressman (2011), estas revisões são divididas 
basicamente em revisões formais e informais.
Revisões informais:
Os processos não são estruturados, não existe planejamento ou alguma 
preparação antecipada, nem agendamento de reuniões ou algum 
acompanhamento sobre os erros encontrados, mas não impede que 
existam listas de verificação genérica e acompanhamento das ções 
necessárias pelos revisores.
Em geral, esse tipo de revisão é considerada menos eficaz do que a 
abordagem formal que veremos a seguir. Um bom exemplo deste 
tipo de revisão é a aplicação de testes de mesa, onde o verificador 
juntamente com um colega da equipe, examinam o protótipo do 
sistema, utilizando uma lista de verificações para interfaces, como 
mostrado a seguir:
• Apresentação precisa de barras de rolagem.
• Padronização de cores, tipo e tamanhos de fonte.
• As opções de navegação estão identificadas de maneira clara para 
o usuário?
43
Revisões formais:
São controles específicos da qualidade do software, na maioria das 
vezes, são realizadas por engenheiros de software, que tem como 
objetivos: identificar erros de função, implementação ou lógica em 
um código fonte; garantir que o software foi implementado de acordo 
com os requisitos definidos; diagnosticar que o software foi criado de 
maneira uniforme, isto é, obedece às técnicas de padrão exigidas pela 
equipe de desenvolvimento.
Este modelo é dotado de reuniões padronizadas, planejadas 
antecipadamente e que contam com a participação de todos os 
membros da equipe. Geralmente, são revistos artefatos resultantes, 
como, por exemplo, o código fonte de um componente ou parte do 
modelo de requisitos.
Nestas reuniões de revisão são discutidos os artefatos modificados, 
se após sua modificação serão aceitos por completo ou em partes. 
Posteriormente, os membros envolvidos na modificação dos artefatos 
assinam um documento de aprovação indicando sua participação e 
concordância sobre o que foi revisado, e quais são as novas descobertas.
Um dos modelos mais utilizados em técnicas de inspeção é o formato 
V, apresentado na Figura 1, onde em cada uma das fases de criação 
do software é realizado o processo de inspeção, que, posteriormente, 
apresentará um feedbck das fases inspecionadas.
44
Figura 1–Técnica de inspeção em V
Fonte: Pagliuso, De Andrade e Villas-Boas (2002, p.108).
Podemos observar, na Figura 1, as fases que compõem a criação de 
um projeto (requisitos, arquitetura, design, código). Após a finalização 
de cada uma destas fases, é realizada uma inspeção e, só ao final da 
ocorrência de todas as inspeções, são realizados os testes contidos na 
pirâmide de testes (testes de unidades, de integração e de sistemas), 
cada um representando uma particularidade do sistema.
Técnicas de inspeção:
Dentre as técnicas de inspeção de software, pode-se destacar as 
seguintes:
Checklist:
Ckecklists são amplamente utilizados para inspecionar e validar 
requisitos, devido a sua facilidade de construção e utilização, que 
45
contém uma estrutura de questões genéricas que devem ser 
respondidas (sim/não), auxiliando o inspetor a detectar erros sem a 
presença de guias específicos ou sem que haja outro tipo de sistema 
para testes. Trata-se de um conjunto de questões fornecidas aos 
inspetores que, quando a resposta for não, presume-se que um erro 
ou defeito foi encontrado e deve ser registrado, conforme relatado na 
taxonomia de defeitos.
Segundo Shull (1998), a taxonomia de defeitos descreve os principais 
tipos de defeitos que um sistema pode conter em suas classes. As 
classes são divididas em duas categorias: omissão e comissão, a primeira 
demonstra os defeitos causados pela não apresentação de informação 
no processo de levantamento de requisitos, isto é, informaçõesque 
não estão expostas; já a comissão trata os defeitos em informações que 
foram relatadas de forma incorreta ou ambígua nos requisitos.
Ainda de acordo com o autor, os tipos de defeitos podem ser divididos 
em: falta de informação, informação ambigua, relevante, inconsistente, 
incorreto e diversos; todos tratam de tipos de defeitos classificados de 
acordo com a necessidade apresentada.
Os checkilists, em geral, são desenvolvidos de acordo com os fatos e 
dados históricos de defeitos já ocorridos, verificados pela equipe que 
compõem a empresa, sendo a experiência adquirida pelos revisores 
uma das maneiras mais eficazes de se levantadar dados para a criação 
do documento.
O emprego do checklist no processo de revisão pode se descrito como:
A mais empregada para a detecção de defeitos no contexto de inspeções 
de software, sob a abordagem de aumentar a efetividade da revisão e 
diminuir a relação de custo por defeito ao focar a atenção do revisor 
num conjunto pré-definido de questões. Os revisores respondem a essas 
questões enquanto lêem um artefato de software, atribuindo uma das três 
46
opções de resposta Sim, Não e Não se Aplica. (LAITENBERGER, ATKINSON, 
1988, p. 494-503)
Em resumo, podemos dizer que o fundamento do checklist é uma lista 
de perguntas ou afirmações, que guiam o inspetor para a detecção de 
erros nos artefatos do sistema.
Perspectiva baseada em leitura
A Técnica Perspectiva baseada em Leitura, também é conhecida como 
PBR (Perspective-Base Reading), é utilizada na aplicação de inspeção de 
documentos feitos em linguagem natural, é constituídos por instruções 
direcionadas para os três profissionais que estão envolvidos no 
documento de requisitos: o testador, o projetista e o usuário, em que 
cada um dos revisores buscam encontrar possíveis erros de acordo 
com sua especificidade de um cenário recebido, isto é, cada um recebe 
os documentos a serem inspecionados em forma de cenários que 
consistem na construção de um documento com questões e atividades 
que auxiliam a organização na resolução de problemas.
Esta técnica tem como forte característica a distribuição de 
responsabilidade por cada revisor envolvido, onde cada um é 
responsável por uma perspectiva particular, evitando que as atividades a 
serem realizadas não sejam revisadas duplicadamente ou sobrepostas e 
garantindo que todos os documentos tenham sido checados e cobertos. 
A Figura 2 demonstra a utilização da técnica PBR no desenvolvimento de 
um software.
47
Figura 2–Técnica baseada em perspectiva
Fonte: Melo (2009, p. 7).
A figura ilustra que o Documento de Requisitos (DR) é avaliado de 
formas diferentes, ou seja, cada um dos três profissionais (projetista, 
testador e usuário), detém de um olhar critíco e particular ao papel 
que foi determinado. Nesse sentido, o projetista utiliza o DR para 
gerar o projeto de sistemas, o testador utiliza para além dos casos de 
testes gerados, para testar o sistema por completo quando estiver 
implementado e, por fim, o usuário final, que, por meio do Documento 
de Requisitos, verifica as funcionalidades do sistema, se estão de acordo 
com as especificações levantadas.
Vale ressaltar que para todas essas etapas são criados cenários com 
cada uma das perspectivas citadas, isto é, um cenário projetista, um 
cenário testador e um cenário usuário.
Uma outra técnica conhecida e aplicada pelos revisores, com 
características simples é a Técnica de leitura Ad-Hoc, segundo Martins 
(2021). Nessa técnica não é utilizado nenhum método ou técnica formal 
para sua realização, cada leitor lê o documento a seu modo e interpreta 
de acordo com sua experiência, conforme sua intuição, por isso, é 
importante que os profissionais que utilizam essa técnica tenham ampla 
experiência.
48
Existem outras técnicas que podem ser empregadas na inspeção de 
software, cabe a equipe de inspeção categorizar qual técnica deve ser 
utilizada para seu tipo de sistema. Deve-se sempre levar em conta 
o tamanho e a complexidade do sistema, só assim será possível 
inspecionar o software para garantir a qualidade tão desejada.
Etapas de inspeção do software
Aplicar técnicas adequadas é fundamental para a detecção antecipada 
de erros e falhas, fazendo com que estes problemas não ultrapassem 
para a fase seguinte, mas é necessário saber diferenciar cada uma das 
etapas envolvidas para que haja uma leitura e entendimento correto do 
documento de requisitos, descrevendo as propriedades de cada uma.
Basicamente, as etapas são compostas por seis fases, cada uma com 
sua particularidade e responsabilidade diferente,: planejamento, 
apresentação, preparação, reunião de inspeção, retrabalhado e 
continuação.
Também é composta por uma equipe, onde cada membro possui 
um papel importante e singular em cada uma das fases: moderador, 
inspetor, e o autor, segundo Fagan (1986). A Figura 3 ilustra como são 
divididas as etapas e os papéis de cada profissional no processo de 
inspeção de software
49
Figura 3–Etapas e papéis na inspeção de software
Fonte: Porto (2009. p. 46).
Incialmente, abordaremos o papel de cada um dos membros e 
categorizaremos sua importância no desenvolvimento do processo de 
software.
Moderador: é o líder da equipe, tem com papel conduzir as reuniões 
e os demais membros, garantindo o sucesso de todo o processo de 
inspeção. Sua principal responsabilidade é verificar se as inspeções 
aplicadas são realmente necessárias. Deve possuir boa relação 
interpessoal, habilidade para lidar com equipes diversas.
Inspetor: tem como papel fundamental tentar encontrar o maior 
número de erros durante o processo de inspeção. Pode-se dizer que 
todos os membros da equipe possuem o papel de inspetor, pois estão 
ali envolvidos no projeto, são os responsáveis por encontrar os erros nos 
artefatos de forma precisa, sem que haja qualquer tipo de omissão e, 
como o próprio nome já diz, sua atribuição é inspecionar os documentos 
dos artefatos
50
Autor: é a própria pessoa que criou o artefato que será inspecionado, 
seu papel é corrigir defeitos apresentados e tirar possíveis dúvidas 
no decorrer das reuniões, como dito, são os próprios criadores 
da documentação do software, podem ser analistas de sistemas, 
desenvolvedores ou até mesmo os clientes.
Pode-se destacar as etapas a serem realizadas durante o processo de 
inspeção. É importante ressaltar que cada fase possui uma ou mais 
pessoas responsáveis, como destacado na Figura 3.
Planejamento: é nesta etapa que tudo começa, é onde são escolhidos, 
pelo moderador, a equipe de inspeção. É realizada a organização e 
separação dos documentos utilizados que passarão pelo processo 
de inspeção. A equipe recebe as instruções essenciais. É nessa etapa 
que também é definido o local em que serão realizadas as sessões de 
inspeção.
Detecção: tem como objetivo encontrar os defeitos nos artefatos, 
cada inspetor selecionado tem como atribuição realizar atividades que 
detectem os defeitos nos documentos selecionados e, posteriormente, 
registrandar em uma lista com as discrepâncias produzidas.
Coleção: quando os erros são identificados por mais de um inspetor, 
todas as listas são selecionadas e excluídos os erros ambíguos, 
evitando, assim, o retrabalho e mantendo apenas um registro de cada 
discrepância apresentada.
Discriminação: os membros da equipe, que fazem parte do processo de 
inspeção discutem os problemas de discrepâncias apresentados. Com 
isso, apenas os defeitos são registrados em um documento, chamado 
de lista de defeitos, que, posteriormente, será repassado ao autor para 
possível correção.
51
Retrabalho: o autor do artefato, tendo em posse a lista de defeito, 
seleciona o defeito que foi atribuído, reproduzindo um relatório com as 
correções realizadas.
Continuação: esta última fase é de responsabilidade do moderador que 
terá que decidir se uma nova inspeção deve ou não ser realizada, ou 
seja, é o responsável por tomar a decisão se o artefato deve ou não ser 
inspecionado novamente.
Benefícios na aplicaçãode inspeção de software
Os benefícios gerados pela aplicação das técnicas de inspeção são 
muitos, e estão associados ao custo, a produtividade, tempo e esforço, 
mas é preciso que o inspetor esteja muito bem treinado e apto para 
diagnosticar os erros nos artefatos o quanto antes, além de estabelecer 
padrões para o desenvovimento de software, obtendo resultados mais 
satisfatórios
Segundo Kalinowski (2008), o esforço gerado com retrabalho em um 
software pode chegar a 50% do esforço total de uma equipe, o que, 
concomitantemente, gera maior custo e um elevado gasto com tempo e 
mão de obra. A Figura 4 ilustra a distribuição do retrabalho, conforme a 
produção para cada uma das fases do desenvolvimento.
52
Figura 4–Distribuição de retrabalho
.
Fonte: Kalinowski (2008, p. 69).
O gráfico descreve que com o avanço das etapas do desenvolvimento, o 
retrabalho tende a aumentar. Um dos motivos é que requer um maior 
esforço para a correção de defeitos nas etapas finais. Pode-se observar 
um aumento do percentual de retrabalho, como, por exemplo, nas 
fases de teste de código e de unidade. Nos requisitos, não há tanta 
distribuição de retrabalho, e no projeto de alto nível, que são fases 
iniciais, pode-se se observar uma carga menos de retrabalho quando 
comparado aos demais.
Assim, é importante a utilização da inspeção de software para a 
detecção precoce dos defeitos, bem nas fases iniciais, quando já tem 
uma percepção do sistema a ser criado. Executando essas correções, 
pode-se chegar a uma diminuição no custo e no esforço do retrabalho, 
em mais ou menos 10% a 20%, gerando melhorias na qualidade tão 
pretendida, segundo Kalinowski (2008).
53
Referências
BORTOLUCI, R.; DUDUCHI, M. Um estudo de caso do processo de testes 
automáticos e manuais de software no desenvolvimento ágil. In: X Workshop de 
Pós-Graduaçao e Pesquisa do Centro Paula Souza. 2015.
DELAMARO, M.; JINO, M.; MALDONADO, J. Introdução ao teste de software. Rio de 
Janeiro: Elsevier Brasil, 2013.
FERREIRA, S. B. L.; LEITE, J. C. S. do P. Avaliação da usabilidade em sistemas 
de informação: o caso do sistema submarino. Revista de Administração 
Contemporânea, v. 7, n. 2, p. 115-136, 2003. Disponível em: https://rac.anpad.org.
br/index.php/rac/article/view/220. Acesso em: 24 jun. 2021.
KALINOWSKI, M. Introdução à inspeção de software. Revista Engenharia de 
Software: qualidade de software, v. 1, 2008. Disponível em: http://www-di.inf.puc-
rio.br/~kalinowski/publications/KalinowskiS07.pdf. Acesso em: 24 jun. 2021.
MARTINS, E. R. Ensino, pesquisa e desenvolvimento na Engenharia Eletrônica 
e Computação. Finer Sistemas, 2012.Ponta Grossa: Atena, 2021. Disponível 
em https://www.finersistemas.com/atenaeditora/index.php/admin/api/
artigoPDF/45729. Acesso: 24 jun. 2021.
PAGLIUSO, Priscilla BB; DE ANDRADE TAMBASCIA, Claudia; VILLAS-BOAS, André. 
Melhoria da Inspeção de Requisitos segundo a técnica de Leitura Baseada em 
Perspectiva. SEMINCO Seminário de Computação, XI, p. 105-116, 2002.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional, 7. ed., 
McGraw-Hill., Porto Alegre: BookMan, 2011.
RIOS, E.; MOREIRA, T. Teste de software. Rio de Janeiro: Alta Books, 2013.
https://rac.anpad.org.br/index.php/rac/article/view/220.
https://rac.anpad.org.br/index.php/rac/article/view/220.
http://www-di.inf.puc-rio.br/~kalinowski/publications/KalinowskiS07.pdf.
http://www-di.inf.puc-rio.br/~kalinowski/publications/KalinowskiS07.pdf.
https://www.finersistemas.com/atenaeditora/index.php/admin/api/artigoPDF/45729.
https://www.finersistemas.com/atenaeditora/index.php/admin/api/artigoPDF/45729.
54
Processos e Casos de Testes 
automatizados
Autoria: Stella Marys Dornelas Lamounier 
Leitura crítica: Marcilyanne Moreira Gois
Objetivos
• Demonstrar as principais diferenças de testes 
manuais versus testes automatizados.
• Desenvolver habilidades nas atividades de teste de 
software.
• Identificar principais técnicas de automação de testes.
• Apresentar ferramentas de automação.
• Implementar testes.
55
1. Introdução a processos e casos de testes 
automatizados
Garantir a qualidade em sistemas computacionais ainda é um grande 
desafio para as empresas de desenvolvimento e, a cada dia, os 
softwares se tornam mais complexos e necessitam de maior precisão, 
além de satisfazer as necessidades do cliente, o software deve ser 
seguro, eficiente, de fácil manutenção e, sobretudo, flexível a potenciais 
mudanças durante seu processo de criação e evolução.
Testes, revisões e inspeções em softwares são etapas fundamentais no 
sucesso de qualquer tipo de sistema e podem ser aplicados em todas as 
etapas de desenvolvimento para garantir bom desempenho.
1.1 Testes manuais versus testes automatizados
Engana-se que testes podem ser feitas apenas de forma manual, isto 
é, executados apenas com a interferência humana. Em vários casos e 
etapas, é possível a utilização de testes automatizados, que também 
garantem a qualidade desejada em um tempo reduzido e com maior 
precisão. 
Os testes manuais, aliados a práticas de revisão e inspeção, que tem 
como característica a buscas por erros em artefatos de software, de 
maneira precoce, por sua vez, também possuem importante papel na 
garantia de qualidade, onde a equipe que desenvolve o sistema deverá 
ser capaz de estudar e analisar o problema e pensar em uma solução 
para, posteriormente, implementá-la. 
Nesse contexto, os testes manuais são realizados, a fim de verificar 
que se as funcionalidades do sistema estão conforme os requisitos 
levantados, além de identificar erros e corrigi-los de modo que possam 
ser realizados quantas vezes forem necessários, o que, por muitas vezes, 
56
torna este tipo de teste dispendioso, cansativo e repetitivo, levando aos 
testadores a não verificar criteriosamente as mudanças significativas no 
código fonte, é neste cenário que surgem erros e defeitos acarretando 
prejuízos financeiros para a empresa de desenvolvimento e frustrando 
os clientes.
Muitas empresas ainda adotam técnicas de desenvolvimento de 
software tradicionais, com a utilização de processos rígidos e técnicas 
Ad-Hoc, provocando ainda mais o surgimento de fatores críticos, tais 
como o surgimento de erros de regressão, impedimento a evolução e a 
flexibilidade de correção dos softwares.
Os testes automatizados, por sua vez, vieram trazer uma posição 
contrária aos modelos manuais, ou seja, realizar testes de forma que 
não haja a interferência humana e com o mesmo objetivo garantir e 
melhorar a qualidade do sistemas.
Quando se fala de automação de testes, deve-se levar em conta que as 
ações e atividades são pré-definidas e analisam um conjunto de ações 
específicas, que, após criados, facilmente podem ser reutilizados.
Testes automatizados podem ser definidos como: 
Programas ou scripts simples que exercitam funcionalidades do sistema 
sendo testado e fazem verificações automáticas nos efeitos colaterais 
obtidos. A grande vantagem desta abordagem, é que todos os casos de 
teste podem ser facilmente e rapidamente repetidos a qualquer momento 
e com pouco esforço. (BERNARDO; CON, 2008, p. 2)
Várias vantagens podem ser vistas com a utilização dessa abordagem 
automatizada, como rapidez em tempo de execução, conforme ilustrado 
na Figura 1. Além disso, traz maior flexibilidade, reprodutibilidade e 
execução de uma variedade de testes em paralelo, quantas vezes forem 
necessárias, de forma ágil e segura. Essas características, muitas vezes, 
encontradas em testes manuais podem ser solucionadas, contribuindo 
57
para minimizar a quantidade de erros e defeitos, aumentando a 
qualidade desejada.
Figura 1 - Tempo de execução em testes
 
Fonte: Peres (2012, [n. p.]).
A figura relata a diferença temporal no dois tipos de testes, manuais 
versus automatizados, que são subdivididos em categorias. É notada 
grande diferença no tempo de execução de cada um deles, como, por 
exemplo: ao realizar a atividade de testes manuais nos campos de login 
inválidos, testes manuais sãoexecutados levando até 20 segundos e 
os automatizados apenas 6 segundos. Seguindo essa mesma linha, 
destacamos as outras funcionalidades, primeiramente, o tempo para 
testes manuais e, depois, para automatizados, como validar clientes, 
79 segundos para o primeiro e 24 para o segundo, cadastrar usuário 
42 segundos versus 16 segundos. Desse modo, é notória a diferença 
no tempo de execução quando se utiliza os testes manuais, trazendo, 
assim, mais agilidade e precisão nas correções. 
Testar software sempre fez parte do cotidiano das empresas, de 
forma simples e manual, sem a utilização de técnicas computacionais. 
58
Entretanto, a ideia de executar os testes de forma automatizada está 
marcada em um passado recente. Só por volta da década de 1990 é 
que começaram a surgir as principais ferramentas especializadas para 
auxiliar os testadores e facilitar estes processos. Estas ferramentas 
possuem como características a separação do bloco de código de 
testes e do sistema, evitando que a parte a ser testada influencie no 
comportamento do sistema, como é o caso dos testes automatizados de 
Unidade, segundo Bernardo (2011).
A automação de testes tem sido empregada em diversos tipos 
de metodologias de software, desde aos modelos convencionais, 
como o Cascata, Modelos Espiral e Rational Unified Process (RUP), 
que, por muitas vezes, são considerados fiéis aos testes manuais 
e, principalmente, os modelos mais flexíveis, que utilizam, em sua 
abordagem, as Metodologias Ágeis.
Na Metodologia Ágil, seu controle de qualidade está associado a 
flexibilidade de correção nos requisitos, tanto funcionais quanto 
não funcionais, e também ao uso de automatização de testes de 
forma contínua e com o mínimo de esforço necessário pelo testador, 
possibilitando a verificação da qualidade mesmo após a implementação 
do sistema.
Os testes automatizados, quando comparados aos testes manuais, 
são considerados de baixo custo de criação e manutenção, pois não 
exigem tanto grau de conhecimento quanto os processos manuais e 
possuem maior segurança quando se fala em depuração de erros e 
documentação de testes.
Empresas de desenvolvimento buscam a todo momento minimizar 
tempo e esforço em testes de software, seja de forma manual ou 
automatizada. O Quadro 1 mostra um comparativo de custo/ esforço 
dos modelos de testes citados.
59
Quadro 1 - Teste manual versus teste automatizado
Teste manual Teste automatizado
• Grande esforço na sua criação 
e manutenção.
• Baixa reutilização.
• Dependência de linguagem 
natural.
• Lentos na execução.
• Permite exploração em 
diversas situações.
• Exigência de profissionais com 
experiência em testes.
• Grande esforço na sua criação e 
manutenção.
• Alta reutilização.
• Ações programadas.
• Incapazes de lidar com situações 
inesperadas.
• Rápidos.
• Suscetíveis a pequenas 
mudanças.
• Repetíveis. 
• Exigência de profissionais 
altamente capacitados.
Fonte: elaborado pela autora.
Pode-se observar, no Quadro 1, que cada um dos modelos apresentados 
possui particularidades, o que acarreta a importância de cada um no seu 
contexto de teste. Vale ressaltar que as principais particularidades dos 
modelos automatizados é o tempo de execução mais rápido, o menor 
custo e a alta reutilização, quando comparado aos testes manuais.
Portanto, testes automatizados estão sendo aplicados e disseminados 
em empresas de software, lembrando que esta técnica não se limita 
apenas a novas metodologias, mas a qualquer modelo que deseja 
aplicar testes de forma rápida, precisa e com o mínimo de esforço, por 
meio de ferramentas que facilitem a manutenção do código.
60
2. Processo de automação de testes
Para executar testes automatizados, deve-se seguir uma linha de 
atividades para que, ao final de sua implementação, a equipe tenha 
trabalhado de forma organizada e objetiva, evitando, assim, gastos 
desnecessários e atrasos na entrega dos sistemas. A seguir, os processos 
que uma empresa de desenvolvimento deve seguir para garantir uma 
melhor organização na automatização de testes, segundo Dustin (1999).
• Decidir automatizar testes: nesta fase, a empresa estuda se o 
custo com teste vale o retorno esperado, os paradigmas utilizados 
e tipos de testes a serem empregados.
• Aquisição de uma ferramenta de automação de testes: 
são analisados os critérios para selecionar a ferramenta mais 
adequada ao ambiente da empresa e que possa trazer maior 
qualidade e melhor custo-benefício.
• Introdução a automação de testes na organização: são criadas 
as diretrizes para introduzir os testes automatizados, é verificada 
a modificação dos testes, já implantados por atividades quem 
envolvem os testes automatizados.
• Planejamento, projeto e desenvolvimento dos testes 
automatizados: os testes automatizados já fazem parte da 
realidade da empresa, todas as etapas de automação devem 
seguir as diretrizes da instituição, os testes devem estar alinhados 
ao ciclo de vida do software, com planejamento detalhado e que 
cubra todas as fases possíveis.
• Execução e controle de automação de testes: são realizadas as 
execuções de testes no ambiente, controle de qualidade a partir de 
métricas e indicadores de eficiência.
61
• Revisão e melhoria do processo: nesta fase, são apresentados 
feedbacks e atividades de avaliação com objetivo de melhorar os 
processos de automação de testes e qualidade.
Após a abordagem dos processos apresentados, a empresa já é capaz 
de escolher quais tipos devem ser empregados e quais ferramentas 
mais adequadas que auxiliarão os testadores para a detecção de erros 
no Sistema.
1.2 Tipos de testes automatizados
Neste tópico, serão abordados os testes automatizados que possuem 
maior aplicabilidade em empresas de desenvolvimento, bem como 
ferramentas de automação de testes utilizadas durante o processo de 
testes automatizados.
Como definir a ferramenta certa? Deve-se considerar os benefícios, 
funcionalidades, custos que trará ao ambiente e, principalmente, criar 
um documento comparativo (benchmark), que auxilia a equipe a testar 
de forma automatizada os processos de software.
1.2.1 Testes de unidade
Os testes de unidade têm como objetivo verificar a correção de 
erros em trechos menores do código fonte. Em geral, são testados 
em blocos, classes ou até mesmo constantes, como dito, nesta fase, 
que são testadas menores partes do sistema, garantindo que uma 
classe ou uma unidade de código esteja de acordo com aquilo que foi, 
inicialmente, planejado, ou seja, na fase de levantamento de requisitos. 
Normalmente, este tipo de teste é feito de forma isolada dos demais 
componentes do sistema, sendo que pode ocorrer precocemente, 
mesmo antes da implementação das unidades, como, por exemplo, se o 
código de um determinado cálculo matemático está sendo executado de 
62
forma correta, isto é, se o resultado obtido está de acordo com o que se 
espera.
Neste contexto, é importante ressaltar que a empregabilidade de testes 
de Unidade como “um teste que deve ser executado pelo programador 
em ambiente de testes, que deve demonstrar que o programa atende ao 
conjunto de requisitos especificados no projeto” (KOOMEN; POL, 1999, 
[n. p.] apud SILVA, 2010, p. 35).
Os testes de unidade podem ser aplicados de forma manual. utilizando, 
por exemplo, as técnicas de caixa preta ou de caixa branca. Essa 
escolha dependerá do que deve ser testado para garantir o sucesso do 
sistema, por exemplo, se você deseja testar um código fonte, então a 
melhor opção é o teste de caixa branca, especialmente o que mostra 
os caminhos de execução que o testador deve percorrer para que se 
teste os possíveis cenários, fluxos, condições. Em contrapartida, se você 
deseja testar funcionalidades do software, o ideal é utilizar o teste de 
caixa preta.
Quando aplicados em testes de automação, a técnica envolve a 
utilização de ferramentas computacionais que auxiliam o processo 
de teste, tornando-o mais rápido e seguro. Atualmente, no mercado, 
existem várias ferramentas