Teste_de_Software_Motivação_e_Conceitos_Basicos

Prévia do material em texto

Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 1 
 
 
 
 
 
Centro de Tecnologia da Informação Renato Archer, CTI 
Ministério da Ciência e Tecnologia, MCT 
 
Teste de Software: Motivação 
e Conceitos Básicos 
 
 
Autores: 
 
Adalberto Nobiato Crespo: Adalberto.crespo@cti.gov.br 
Mario Jino: Jino@dca.fee.unicamp.br 
Miguel Argollo: Miguel.argollo@cti.gov.br 
Paulo Bueno: Paulo.bueno@cti.gov.br 
Celso Penteado de Barros: Celso.barros@cti.gov 
 
 
Outubro/2009 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 2 
 
Teste de Software: Motivação e Conceitos Básicos 
Apresentação 
Este documento apresenta uma introdução ao teste de software, um conjunto de atividades 
de extrema importância para a obtenção de produtos de software de qualidade. Como um 
texto inicial, buscou-se apresentar os conceitos fundamentais de teste de uma forma simples 
e breve. São descritos, dentre outros conceitos de teste: o objetivo; os procedimentos; o 
processo; os tipos; os níveis e as técnicas aplicadas à atividade de teste. 
O objetivo é apontar práticas aceitas como eficazes por profissionais da área e 
também padrões recentes de teste de software, definidos por órgãos como ISO/IEC e IEEE. 
É importante notar que a adoção de qualquer tecnologia de teste por parte das organizações 
ou profissionais envolvidos com o SPB deve ser calcada em uma análise cuidadosa das 
reais necessidades de teste, tendo em vista o objetivo da organização ou do profissional e a 
natureza do software produzido. 
Diferentes usuários podem se interessar prioritariamente por partes distintas deste 
documento. Embora a leitura integral seja recomendada, podem-se identificar duas áreas de 
interesse: aspectos mais técnicos do teste e aspectos mais voltados à política e ao 
gerenciamento do teste. 
As Seções 1, 2, 3 e 11 abordam a motivação, alguns conceitos que são essenciais para 
todos os leitores assim como as conclusões. As Seções 4, 5, 6 e 7 discutem conceitos como 
níveis, ciclos, tipos, técnicas, critérios e ferramentas de teste; conteúdo importante para os 
desenvolvedores de software e os responsáveis pelo teste (gerentes, projetistas e executores 
de teste). As Seções 8, 9, 10 apresentam os conceitos de processo, documentação, análise 
de riscos, e considerações políticas e estratégicas do teste, temas relacionados à gerência 
estratégica de TI, importantes para os responsáveis pela área de qualidade e de processos da 
organização. 
Guias e tutoriais de teste estão sendo desenvolvidos para complementar este 
documento. 
 
 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 3 
 
Conteúdo 
 
1 Introdução: software público, qualidade e teste ............................................................. 4 
2 Teste de software: objetivo, custos e benefícios ............................................................. 5 
3 O sucesso no teste: provocar falhas que mostrem defeitos ............................................ 8 
4 Níveis e ciclos do teste: quando testar .......................................................................... 11 
5 Tipos de teste: o que testar ........................................................................................... 13 
6 Técnicas e critérios de teste: como testar ..................................................................... 15 
 6.1 Critérios da técnica funcional ................................................................................... 17 
 6.2 Critérios da técnica estrutural .................................................................................. 21 
7 Ferramentas de apoio ao teste ...................................................................................... 24 
8 Processo e documentação do teste: como organizar o trabalho .................................. 26 
9 Análise de riscos: priorizar aspectos para o teste .......................................................... 28 
10 Política e processo de teste: o papel do teste na estratégia da organização ................ 29 
11 Conclusão: transformando conceitos de teste em melhores produtos de software .... 31 
 
 
 
 
 
 
 
 
 
 
 
 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 4 
 
1 Introdução: software público, qualidade e teste 
O amadurecimento da indústria de software no Brasil traz consigo um aumento da 
competitividade entre as empresas brasileiras desenvolvedoras e também destas com 
empresas de outros países. Neste contexto, a promoção da qualidade de produtos de 
software é um fator crítico de sucesso. Também de suma importância é o aprimoramento 
dos processos de engenharia e de gestão no desenvolvimento de software, visando permitir 
projetos bem sucedidos, com menores custos e respeitando os limites de prazo. 
O Software Público Brasileiro (SPB) adota um modelo de desenvolvimento de 
software caracterizado pelo compartilhamento de produtos de software, assim como dos 
artefatos e serviços a eles relacionados. A existência de um alto nível de qualidade do 
software, artefatos e serviços compartilhados seguramente tem uma influência positiva para 
o sucesso deste modelo. Deste modo, a adoção de práticas visando avaliar e aprimorar a 
qualidade deve ser estimulada no contexto do SPB. 
O desenvolvimento de software não é uma tarefa fácil e, por ser fortemente baseada 
no trabalho humano, é altamente sujeita a erros. Portanto, por mais que se adotem 
processos de software bem estabelecidos, e que estes sejam executados por pessoas 
capacitadas, usando técnicas e ferramentas adequadas, erros durante o desenvolvimento 
acontecem e resultam em deficiências no software. A atividade de teste visa identificar 
estas deficiências, permitindo assim o aprimoramento dos produtos de software. 
O restante do documento está organizado do seguinte modo. A Seção 2 aborda a 
necessidade do teste e os impactos negativos de um teste inadequado; a Seção 3 define 
alguns conceitos fundamentais; a Seção 4 mostra como o esforço de teste pode ser realizado 
em etapas e ciclos; a Seção 5 apresenta alguns tipos de teste existentes; a Seção 6 descreve 
as principais técnicas e critérios para seleção e avaliação de testes; a Seção 7 cita alguns 
tipos de ferramentas que podem apoiar esta atividade, enquanto a Seção 8 descreve as 
atividades principais e as informações envolvidas em um processo de teste; a Seção 9 
sumariza como a análise de riscos pode ser considerada no teste; a Seção 10 aborda como 
situar estrategicamente o teste em relação aos objetivos da organização. Finalmente, tem-se 
a conclusão na Seção 11. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 5 
 
2 Teste de software: objetivo, custos e benefícios 
Existem diversas definições de teste de software; por exemplo: 
• “Teste é uma atividade direcionada para avaliar um atributo ou capacidade de um 
programa ou sistema e determinar se ele satisfaz os resultados requeridos”1; 
• “Teste é o processo de executar um programa com a intenção de encontrar 
defeitos”2; 
• “Teste é o processo pelo qual se explora e se entende o estado dos benefícios e 
riscos associados com a versão de um sistema de software”3. 
Todas essas definições são válidas e destacam algum aspecto importante da atividade 
de teste. De maneira simplificada podemos entender o teste de software como: “a execução 
do software de uma forma controlada com o objetivo de avaliar se o software se comporta 
ou não conforme especificado”. 
Trata-se, portanto, de uma atividade fundamental para avaliar se o software produzido 
atende aos requisitos levantados com os usuários. No entanto, teste não exclui a realização 
de outras atividades como as inspeções efetuadasnos artefatos produzidos ao longo do 
processo de software. 
Uma questão essencial é: “por que existe a necessidade de se testar software?” Uma 
resposta (provocativa) a esta pergunta tem a forma de outra questão: “você se sentiria 
confortável em ser o passageiro de um vôo em uma aeronave que nunca decolou antes?” 
O processo de projeto e construção de aeronaves envolve uma série de atividades de 
teste da aeronave como um todo e de seus componentes principais (asas, turbinas, sistemas 
eletrônicos, sistemas mecânicos). Essas atividades visam a confirmar as teorias 
consideradas no projeto, obter dados empíricos e avaliar os aspectos não embasados por 
teorias, avaliar a conformidade com padrões de segurança e de desempenho de vôo, além 
de vários outros pontos. Os testes são aplicados em componentes, em subsistemas, e na 
aeronave inteira, incluindo o teste em condições reais de vôo. Esta questão é obviamente 
 
1
 Hetzel, B. 1988, “The Complete Guide to Software Testing (2nd Ed.)”. QED Information Sciences, Inc. 
2
 Myers, G.J., 1979, “The Art of Software Testing”, Addison-Wesley, New York. 
3
 Cem Kaner, James Bach e Bret Pettichord, “Lessons Learned in Software Testing: A Context-Driven 
Approach”, Willey Computer Publishing, 2002. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 6 
 
um exagero proposital; uma aeronave não testada nunca seria liberada para um vôo 
comercial. 
Analogamente, um software não deve ser liberado para uso sem que atividades 
adequadas de teste tenham sido realizadas. Por meio do teste diversas deficiências 
existentes no software, relacionadas a problemas de funcionalidade, desempenho, 
segurança, instalação e utilização podem ser encontradas e removidas, antes que o software 
“entre em vôo”, isto é, seja implantado para o uso dos clientes. 
Enfim, testa-se software porque o desenvolvimento de sistemas envolve uma série de 
atividades em que as possibilidades de ocorrência de erros humanos são inúmeras. Erros 
podem ocorrer logo no início do processo de criação do software, quando objetivos 
definidos podem estar incorretos ou incompletos. Além disso, erros podem ocorrer nas 
demais fases do desenvolvimento, como projeto, codificação e integração do software. 
Essencialmente erros ocorrem pela dificuldade dos seres humanos de executar tarefas e se 
comunicar com perfeição. Esses são os mesmos motivos que justificam o teste rigoroso em 
aeronaves. 
O teste de software não é uma atividade tecnicamente fácil nem barata. A atividade 
de teste representa um percentual significativo do custo total de desenvolvimento do 
software. Estudos mostram que, dependendo do tipo do software e do processo de 
desenvolvimento, o custo do teste tipicamente fica entre 50% e 80% do custo total 4. 
No entanto, é fato reconhecido que a ausência de uma atividade de teste bem 
realizada acarreta um custo total significativamente maior. 
O retrabalho devido à manutenção corretiva de problemas de especificação, projeto e 
programação é uma realidade amplamente conhecida. Estatísticas apresentadas mostram 
ainda que cada R$ 1,00 investido em prevenção de defeitos diminui de R$ 3,00 a R$ 10,00 
os custos de manutenção corretiva. E cada R$ 1,00 investido em remoção de defeitos 
diminui de R$ 2,00 a R$ 5,00 os custos de manutenção corretiva. 
Um estudo do NIST (Instituto Nacional de Padrões e Tecnologia, órgão do 
Departamento de Comércio dos Estados Unidos) aponta impactos negativos de 
 
4
 Boehm, B. W. 1981, “Software Engineering Economics.” 1st. Prentice Hall PTR 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 7 
 
inadequações nas atividades de teste5. Dentre os problemas acarretados pelo teste 
inadequado podem-se destacar: 
• Crescimento do número de falhas em uso devido à má qualidade do software, 
acarretando perdas na reputação da organização e no potencial de negócios futuros; 
• Aumento no custo de desenvolvimento de software, visto que o custo da correção de 
problemas no software cresce ao longo dos estágios do desenvolvimento, tendo seu 
maior valor quando é necessário corrigir problemas em um software já implantado 
no cliente; 
• Atraso para disponibilizar o produto ao mercado devido à ausência de processos e 
técnicas de teste padronizadas e a conseqüente necessidade de criar às pressas uma 
infra-estrutura de teste. 
Esta lista de problemas é mais extensa, e apresenta problemas potencialmente 
dramáticos, no caso de software com altos requisitos de confiabilidade, tais como: software 
de controle de reatores nucleares; software aeroespacial e software de monitoramento de 
leitos em UTIs. O teste inadequado de softwares que manipulam informações de alto valor, 
como dados estratégicos de empresas e informações bancárias, também pode acarretar 
grandes danos financeiros e de imagem às organizações. 
No contexto do SPB as deficiências no teste de um produto de software podem 
acarretar uma perda de reputação deste software entre os seus possíveis usuários, limitando 
consequentemente os potenciais benefícios trazidos pelo software. 
Raymond define o “modelo bazar” de desenvolvimento no qual o código fonte do 
software é disponibilizado publicamente na internet e desenvolvido de forma colaborativa e 
compartilhada por milhares de desenvolvedores espalhados pelo mundo; é o modelo 
utilizado para o desenvolvimento do Kernel do sistema operacional Linux 6. Segundo 
Raymond, ao se usar este modelo de desenvolvimento “quanto mais largamente o código 
fonte estiver disponível para o teste, exame e experimentação, mais rapidamente os “bugs” 
 
5
 The National Institute of Standards and Technology (NIST) Strategic Planning and Economic Analysis 
Group, “The Economic Impacts of Inadequate Infrastructure for Software Testing,” Maio, 2002 
6
 Eric S. Raymond, “The Cathedral & the Bazaar, Musings on Linux and Open Source by an Accidental 
Revolutionary,” Fevereiro, 2001, O´Reilly & Associates, Inc. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 8 
 
serão descobertos”, chamada por ele de “Lei Linus” – referindo-se a Linus Torvalds, 
idealizador do Linux – “given enough eyeballs, all bugs are shallow” 7. Na medida em que 
o SPB caracteriza-se pelo compartilhamento de código fonte e de outros artefatos de 
software, é razoável esperar que as práticas de teste possam ser conduzidas de forma 
eficiente, aproveitando a característica colaborativa do ambiente e o espírito engajado e 
investigativo de muitos membros de comunidades. A utilização de boas práticas de teste 
neste contexto tem o potencial de aumentar a qualidade dos produtos de software e os 
benefícios do SPB à sociedade. 
3 O sucesso no teste: provocar falhas que mostrem defeitos 
O teste de software pode também ser definido como “a execução de 
um software com o objetivo de encontrar defeitos”. Neste caso, fica 
explícita a idéia de que o teste deve exercitar o software de uma 
maneira tal que este falhe, permitindo assim a posterior identificação 
e remoção da causa desta falha. 
Deve-se ter em mente que um defeito (fault ou defect em inglês) é uma anomalia no 
software que pode causar uma falha (exemplos: um comando imperfeito, incompleto, 
ausente ou extra no software). Uma falha (failure) é a ocorrência de uma discrepância entre 
o resultado observado da execução do software e o resultado prescrito pelos requisitos. Um 
erro (error) é um estado incorreto, intermediário ou final, de execução do software que 
pode produzir um resultado incorreto, ou seja, pode levar a uma falha do software. Um 
defeito no software é introduzido devido a algum engano (mistake) cometido em algum 
momento no desenvolvimento do software e não descobertoem atividades de inspeção. 
Por exemplo: o foguete Ariane V explodiu em 1996, cerca de 40 segundos após ter 
decolado 8. O foguete saiu de sua rota programada e se desintegrou devido a forças 
aerodinâmicas. Em uma análise posterior do incidente, verificou-se que o software de 
controle do vôo indicou uma direção errada ao foguete (esta foi a falha) devido a uma 
 
7
 “se os olhos forem suficientes, todos os bugs serão vistos” em uma tradução livre. Ou: “... dados grupos 
grandes o suficiente de testadores-beta e de desenvolvedores, quase todos os problemas serão identificados 
rapidamente e o conserto será óbvio para alguém...”. 
8
 ARIANE 5 Flight 501 Failure Report by the Inquiry Board, Julho, 1996. 
 Centro de Tecnologia da Informação Renato Archer 
 
Teste de Software: Motivação e Conceitos Básicos
conversão incorreta de uma variável
defeito). 
Esta conversão produziu um 
erro de overflow, isto é, um valor 
errôneo de uma variável (este foi o 
erro), que ocasionou a resposta 
incorreta do software. O engano foi, 
provavelmente, cometido por um 
programador, que inseriu no 
software um comando de atribuição 
indevido. 
Portanto, para um defei
de uma forma tal que o defeito seja “sensibilizado”
quando o comando defeituoso é executado e cria um
as variáveis internas, por exemplo)
erro seja propagado, ao longo da execução, do ponto onde foi criado
defeituoso) para alguma saída do software, ocasionando uma resposta final incorreta 
(valores incorretos para alguma saída produzida, por exemplo).
 A Figura 1 ilustra a cadeia de eventos que se inicia com um engano e que pode 
resultar em uma falha do software.
Figura 1: C
Em uma visão simplificada, a realização do teste 
a. Selecionar valores para as 
teste (chamados de Dad
partir do conjunto de todos os possíveis valores que podem ser usados para executar 
o software, chamado de 
Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
ftware: Motivação e Conceitos Básicos 
variável tipo real de 64 bits em um inteiro de 16 bits
produziu um 
um valor 
(este foi o 
resposta 
O engano foi, 
provavelmente, cometido por um 
programador, que inseriu no 
software um comando de atribuição 
efeito ser descoberto é necessário que o software seja executado 
de uma forma tal que o defeito seja “sensibilizado” e provoque uma falha
quando o comando defeituoso é executado e cria um estado de erro (valores incorretos para 
ternas, por exemplo). Para que a falha aconteça, é necessário 
ao longo da execução, do ponto onde foi criado (logo após o comando 
para alguma saída do software, ocasionando uma resposta final incorreta 
(valores incorretos para alguma saída produzida, por exemplo). 
A Figura 1 ilustra a cadeia de eventos que se inicia com um engano e que pode 
resultar em uma falha do software. 
Figura 1: Cadeia de Eventos Para a Falha do Software 
Em uma visão simplificada, a realização do teste envolve: 
valores para as Variáveis de Entrada a serem submetidos ao software em 
ados de Entrada ou de Dados de Teste); esta seleção é feita a 
partir do conjunto de todos os possíveis valores que podem ser usados para executar 
o software, chamado de Domínio de Entrada do software. 
Página 9 
 
tipo real de 64 bits em um inteiro de 16 bits (este foi o 
seja executado 
e provoque uma falha. Isto ocorre 
estado de erro (valores incorretos para 
é necessário ainda que este 
(logo após o comando 
para alguma saída do software, ocasionando uma resposta final incorreta 
A Figura 1 ilustra a cadeia de eventos que se inicia com um engano e que pode 
 
a serem submetidos ao software em 
esta seleção é feita a 
partir do conjunto de todos os possíveis valores que podem ser usados para executar 
 Centro de Tecnologia da Informação Renato Archer 
 
Teste de Software: Motivação e Conceitos Básicos
b. Executar o software com os dados de teste
variáveis de entrada e acionar alguma função no software
c. Avaliar se a saída produzida corresponde à 
do software, isto é, se o comportamento e os valores produzidos como resultado da 
execução foram os corretos
Um par dados de entrada
de Teste. Uma coleção de vários
Teste. 
Para a realização do teste, presume
permita avaliar se certo resultado 
acordo com a especificação (ou 
Esta avaliação é feita por meio de um 
papel de oráculo e realiza a comparação “esperado versus obtido”
software falhou ou não. 
A Figura 2 apresenta uma visão simplificada do teste: 
de entrada e a avaliação da saída produzida pelo programa 
esperados. 
Uma limitação inerente à atividade de teste é 
software está correto. O teste pode revelar a 
ausência desses defeitos. Portanto, por mais rigoroso que seja o teste, não é possível 
assegurar que não permaneceram no software defeitos “escondidos”
Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
ftware: Motivação e Conceitos Básicos 
com os dados de teste, ou seja, informar os valores para 
entrada e acionar alguma função no software; e 
se a saída produzida corresponde à saída esperada segundo a especificação 
, isto é, se o comportamento e os valores produzidos como resultado da 
corretos. 
entrada e resultados esperados associados é chamado de um 
de vários casos de teste é referida como um Conjunto
Para a realização do teste, presume-se a existência de algum meio ou dispositivo que 
resultado - ou comportamento - produzido pelo software está de 
acordo com a especificação (ou seja, se é o resultado esperado de um software correto). 
é feita por meio de um oráculo. Normalmente o executor do teste assume o 
realiza a comparação “esperado versus obtido”, identifica
apresenta uma visão simplificada do teste: a execução do programa com dados 
de entrada e a avaliação da saída produzida pelo programa em relação aos resultados 
Figura 2: Visão Simplificada do Teste 
inerente à atividade de teste é sua impossibilidade de provar que um
. O teste pode revelar a presença de defeitos no software, mas não a 
Portanto, por mais rigoroso que seja o teste, não é possível 
que não permaneceram no software defeitos “escondidos”, não encontrados 
Página 10 
 
, ou seja, informar os valores para as 
esperada segundo a especificação 
, isto é, se o comportamento e os valores produzidos como resultado da 
hamado de um Caso 
onjunto de Casos de 
se a existência de algum meio ou dispositivo que 
produzido pelo software está de 
o resultado esperado de um software correto). 
Normalmente o executor do teste assume o 
identificando se o 
a execução do programa com dados 
em relação aos resultados 
 
provar que um 
no software, mas não a 
Portanto, por mais rigoroso que seja o teste, não é possível 
não encontrados 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 11 
 
durante o teste. No entanto, o teste pode dar subsídios para que se avalie o quão confiável 
(ou não) é o software. 
4 Níveis e ciclos do teste: quando testar 
O teste de software é normalmente realizado em uma série de fases, ou níveis: 
• Teste de Unidade; 
• Teste de Integração; 
• Teste de Sistema; e 
• Teste de Aceitação. 
Após o desenvolvimento de cada unidade do software (procedimento, função, método 
ou classe) é realizado o teste de unidade (ou teste unitário), que visa a identificar defeitos 
introduzidos nos algoritmos e estruturas de dados dessas unidades. Em geral, o teste de 
unidade é feito pelo próprio desenvolvedor da unidade. As unidades são então 
incrementalmente integradas e testadas (teste de integração). Esta etapa é realizada pelos 
desenvolvedores ou por elementos de uma equipe de teste e visa a identificar defeitos de 
interface entre as unidades. Depois de integrado, o software é testado “como um todo”: o 
teste de sistema é o nível de teste cujos requisitos são derivados da especificação de 
requisitos funcionais e não funcionais, e é aplicado para verificar se o software e o 
hardware executam corretamente ou não quandointegrados ao ambiente de operação. O 
teste de aceitação é então conduzido para estabelecer se o sistema satisfaz ou não os 
critérios de aceitação definidos com o cliente. 
 Deve-se notar que em cada um desses níveis (unidade, integração, sistema e 
aceitação) diversos ciclos de teste podem ocorrer. Em cada ciclo de teste um procedimento 
de teste é realizado, por meio do qual um ou mais casos de teste são executados. Falhas 
provocadas por casos de teste devem ser registradas para posterior depuração do software 
(localização e remoção dos defeitos) pela equipe de desenvolvimento. No próximo ciclo, 
casos de teste devem ser re-executados para avaliar se os defeitos que ocasionaram as 
falhas foram realmente removidos e se as alterações no software não introduziram 
inadvertidamente outros defeitos. Pode ocorrer também a necessidade de se retornar a um 
nível de teste anterior. Por exemplo: durante o teste de integração podem ser identificados 
 Centro de Tecnologia da Informação Renato Archer 
 
Teste de Software: Motivação e Conceitos Básicos
problemas que requeiram muitas alterações em 
pode ser adequado, além de re
novamente o teste de unidade 
O teste de um software já testado previamente
Teste de Regressão. Este teste busca verificar se as modificações efetuadas não 
introduziram novos defeitos ou ativaram defeitos em partes inalteradas do código; visa 
também avaliar se o software ainda satisfaz os seus r
tipicamente realizado na fase de manutenção, após a realização de mudanças no software 
ou no seu ambiente. Conforme descrito no parágrafo anterior, este teste também pode 
ocorrer ao longo do desenvolvimento do software. 
A Figura 3 ilustra um processo 
sequencialmente: teste de unidade
níveis são mostrados os ciclos
execução de casos de teste. A figura mostra
de teste. 
Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
ftware: Motivação e Conceitos Básicos 
as que requeiram muitas alterações em algum módulo do software. Neste caso, 
pode ser adequado, além de re-executar casos de teste de integração, também realizar 
novamente o teste de unidade do módulo alterado. 
O teste de um software já testado previamente e que sofreu mudanças é chamado de 
. Este teste busca verificar se as modificações efetuadas não 
introduziram novos defeitos ou ativaram defeitos em partes inalteradas do código; visa 
também avaliar se o software ainda satisfaz os seus requisitos. O teste de regressão é 
tipicamente realizado na fase de manutenção, após a realização de mudanças no software 
ou no seu ambiente. Conforme descrito no parágrafo anterior, este teste também pode 
ocorrer ao longo do desenvolvimento do software. 
A Figura 3 ilustra um processo em que os níveis de teste são executados 
quencialmente: teste de unidade, de integração, de sistema e de aceitação.
níveis são mostrados os ciclos que envolvem alterações do software (ou depuração
ão de casos de teste. A figura mostra também o fluxo de retorno a níveis anteriores 
Figura 3: Níveis e Ciclos de Teste 
Página 12 
 
do software. Neste caso, 
executar casos de teste de integração, também realizar 
e que sofreu mudanças é chamado de 
. Este teste busca verificar se as modificações efetuadas não 
introduziram novos defeitos ou ativaram defeitos em partes inalteradas do código; visa 
equisitos. O teste de regressão é 
tipicamente realizado na fase de manutenção, após a realização de mudanças no software 
ou no seu ambiente. Conforme descrito no parágrafo anterior, este teste também pode 
os níveis de teste são executados 
de sistema e de aceitação. Em todos os 
depuração) e a re-
também o fluxo de retorno a níveis anteriores 
 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 13 
 
É importante destacar que não é obrigatório que todos os níveis de teste ocorram para 
que se tenha um teste adequado. A necessidade ou não de realizar cada um desses níveis 
deve ser decidida a partir da análise da situação específica, conforme descrito nas seções 
sobre processos de teste (Seções 8 e 10). 
5 Tipos de teste: o que testar 
Diversos atributos de qualidade do software podem ser avaliados por meio de testes. 
Características de qualidade de software definidas em padrões como a ISO/IEC 9126 9 
podem servir como base para a definição de aspectos do software a serem avaliados por 
meio da realização de testes. Portanto, existem diversos tipos de teste; cada tipo visa à 
avaliação de um aspecto distinto do software e pode ser aplicado em um ou mais níveis de 
teste (unidade, integração, etc.). 
O teste de funcionalidade busca avaliar se o software apresenta um conjunto de funções 
que satisfaça ou não às necessidades levantadas (associadas aos requisitos definidos). 
O teste de desempenho visa a avaliar se o 
software executa as funções previstas satisfazendo ou 
não os requisitos de desempenho definidos (e.g., 
velocidade de processamento, tempo de resposta, uso 
de memória). 
O teste de interoperabilidade avalia a capacidade do 
software em interagir com um ou mais componentes ou 
sistemas. 
O teste de segurança (security) visa a avaliar a habilidade 
do software de impedir o acesso não autorizado – acidental ou 
deliberado – ao software ou a dados. 
O teste de sanidade (smoke test) envolve a execução de um subconjunto dos testes 
projetados que cobrem algumas funcionalidades principais; pode ser realizado 
 
9
 ISO/IEC 9126-1:2001 Software engineering -- Product Quality -- Part 1: Quality model 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 14 
 
periodicamente, ou como uma atividade inicial para avaliar se o software está pronto para 
um esforço maior de teste. 
O teste de estresse simula condições atípicas de utilização do software, provocando 
aumentos e reduções sucessivas de transações que superem os volumes máximos previstos 
para a capacidade de processamento dos componentes ou do sistema. 
O teste de usabilidade visa a determinar quão 
facilmente o produto de software é compreendido, 
apreendido e usado, e quão agradável ele é ao usuário. 
O teste de portabilidade busca avaliar o nível de 
facilidade de transferência de um ambiente de hardware e 
software para outro ambiente. 
O teste de carga consiste em medir o comportamento 
de um componente ou sistema submetido a cargas de 
processamento crescentes para determinar qual nível de 
carga o sistema pode tratar; por exemplo, número de 
usuários ou número de transações. 
O teste de instalação busca avaliar se o software é instalado e desinstalado com sucesso 
ou não em determinado ambiente operacional. 
O teste de recuperação determina a capacidade ou incapacidade de um produto de 
software de restabelecer condições normais de operação e de recuperar dados afetados, em 
caso de falha. 
A determinação de quais tipos de teste devem ser utilizados e em qual (quais) nível 
(níveis) eles devem ser aplicados, ocorre durante a fase de planejamento do teste. Esta 
definição é feita considerando-se as informações disponíveis sobre a natureza do software 
em teste e dos requisitos específicos dos módulos que compõem o software. 
Na maior parte das situações é adequado focar atenção no teste de funcionalidade para 
avaliar os se os requisitos funcionais do software são satisfeitos ou não. Este teste deve ser 
complementado por outros tipos de teste (carga, desempenho, etc) para avaliar se os 
requisitos não funcionais do software são satisfeitos ou não. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 15 
 
6 Técnicas e critérios de teste: como testar 
Esta seção apresenta algumas Técnicas e Critérios de Teste úteis para a seleção de bons 
casos de teste. É importante ressalvar que existem outras técnicas não relatadas aqui; 
procurou-se destacar as técnicas mais usadas na práticaou mais consolidadas na literatura. 
Como este documento apresenta apenas uma visão inicial sobre técnicas e critérios, é 
recomendada a consulta a tutoriais específicos e de literatura especializada para maiores 
informações. 
Uma tarefa fundamental na atividade de teste é a seleção dos casos de teste a serem 
utilizados. Esta seleção é necessária porque o Teste Exaustivo, feito com todas as possíveis 
combinações de valores de entrada, é quase sempre inviável. Por exemplo, considere um 
software que tenha como entrada 15 variáveis, sendo que cada uma delas pode assumir 7 
valores diferentes. Considere ainda que a execução de cada caso de teste demore 1/100 de 
segundo (0,01 segundo). Para realizar o teste exaustivo deste software seriam necessários 
715/100 segundos, o que equivale a 1.505 anos e alguns meses de processamento. 
Tendo em vista o objetivo principal do teste de revelar defeitos e a restrição de que os 
cronogramas e orçamentos sejam cumpridos, é aconselhável a utilização de Técnicas de 
Teste. Estas técnicas estabelecem procedimentos para selecionar - ou criar - os casos de 
teste que resultem em um conjunto de teste eficaz e de tamanho moderado. As técnicas de 
teste determinam a natureza da informação a ser utilizada para se fazer a seleção ou a 
avaliação de conjuntos de teste. Na técnica de Teste Funcional os casos de teste são 
selecionados por meio da análise da especificação do software, ou utilizando modelos 
criados na fase de análise e projeto do software. Na técnica de Teste Estrutural os casos de 
teste são selecionados por meio da análise da estrutura interna do software. Na técnica de 
teste Baseada em Defeitos, casos de teste são selecionados a partir de classes de defeitos 
que podem ser introduzidos ao longo do desenvolvimento do software. A Figura 4 ilustra 
as técnicas funcional e estrutural de teste. 
 
 Centro de Tecnologia da Informação Renato Archer 
 
Teste de Software: Motivação e Conceitos Básicos
As diversas técnicas de teste não são excludentes;
técnicas é recomendada, pois os defeitos revelados pela aplicação de
ser diferentes. 
 A utilização de uma técnica de teste ocorre por meio da aplicação 
de Teste. Um critério de teste determina um conjunto de 
que devem ser exercitados pela realização do teste.
comandos - ou todos os nós 
requeridos os comandos do código do software
deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste. 
A Cobertura do Teste,
percentual de elementos requeridos exercitados por um conjunto de casos 
executados. Por exemplo, o percentual de comandos executados durante o teste seria uma 
medida de cobertura considerando
medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado. 
razoável supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de 
um software é melhor do que outro conjunto de teste
 
10
 O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste 
documento. 
Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
ftware: Motivação e Conceitos Básicos 
Figura 4: Técnicas de Teste 10 
as de teste não são excludentes; na verdade, a utilização de várias 
ada, pois os defeitos revelados pela aplicação de cada uma delas podem 
A utilização de uma técnica de teste ocorre por meio da aplicação de algum
Um critério de teste determina um conjunto de Elementos Requeridos
que devem ser exercitados pela realização do teste. Por exemplo, o critério 
ou todos os nós - da técnica estrutural de teste define como elementos 
o código do software. Neste caso, cada comando do so
deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste. 
este, com respeito a um critério de teste específico, mede
percentual de elementos requeridos exercitados por um conjunto de casos 
. Por exemplo, o percentual de comandos executados durante o teste seria uma 
medida de cobertura considerando-se o critério de teste do exemplo anterior. Deste modo, a 
medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado. 
razoável supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de 
do que outro conjunto de teste que executa apenas 50% dos 
 
O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste 
Página 16 
 
 
a utilização de várias 
cada uma delas podem 
algum Critério 
equeridos do software 
critério todos os 
de teste define como elementos 
. Neste caso, cada comando do software 
deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste. 
com respeito a um critério de teste específico, mede o 
percentual de elementos requeridos exercitados por um conjunto de casos de teste 
. Por exemplo, o percentual de comandos executados durante o teste seria uma 
se o critério de teste do exemplo anterior. Deste modo, a 
medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado. É 
razoável supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de 
que executa apenas 50% dos 
O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 17 
 
comandos. Se um conjunto de casos de teste exercita todos os elementos requeridos pelo 
critério, diz-se que tal conjunto satisfaz o critério. 
Em geral, os critérios de teste podem ser utilizados para: criar um conjunto de casos 
de teste; avaliar um conjunto de casos de teste já criado; ou ainda, servir como uma 
condição para a finalização do teste. 
A seguir é feita uma breve descrição de alguns critérios de teste da técnica funcional e 
da técnica estrutural, as mais usadas na prática. 
6.1 Critérios da técnica funcional 
Os critérios da técnica de teste funcional caracterizam-se por utilizar informações 
originadas da especificação do software como base para a seleção de casos de teste. 
Artefatos criados na fase de análise de requisitos e de projeto do software, tais como o 
documento de requisitos do software ou modelos como diagramas UML, são utilizados 
para criar os casos de teste. 
A idéia essencial da técnica funcional é selecionar dados de teste representativos o 
suficiente para avaliar se as funcionalidades definidas na especificação do software foram 
implementadas corretamente ou não. Para tanto, operações associadas às funcionalidades 
são identificadas e dados de teste que as exercitem são definidos e executados. 
O critério Particionamento de Equivalência divide o domínio de entrada do software 
em classes de equivalência e requer que pelo menos um dado de teste de cada classe seja 
selecionado e executado. Essas classes são definidas pressupondo que todo dado de entrada 
pertencente a uma classe é tratado do mesmo modo, de acordo com a especificação do 
software. Portanto, cada dado de teste selecionado representa os demais dados de testes da 
sua classe de equivalência. 
Por exemplo, se a especificação define que um software recebe como entrada uma 
variável idade, tipo inteiro, que pode variar de 0 a 120 anos (incluindo os extremos), 
poderiam ser identificadas as seguintes classes de equivalência: 
• Classe 1: idade menor que zero – referida como classe de valores inválidos; 
• Classe 2: idade entre 0 e 120 – classe de valores válidos; e, 
• Classe 3: idade maior que 120 – outra classe de valores inválidos. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 18 
 
Ao se executar o software com dados de teste que pertençam às Classes 1 e 3 espera-se que 
os valores fornecidos sejam identificados como não aceitáveis e sejam emitidas mensagens 
apropriadas. Ao se executar o software com um dado de teste que pertença à Classe 2 o 
valorfornecido deve ser aceito e uma saída apropriada deve ser produzida. 
A Figura 5 ilustra as classes de equivalência do exemplo e os dados de teste selecionados 
para exercitar cada classe. 
 
 
 
 
Figura 5: Classes de Equivalência e Dados de Teste 
Dependendo da especificação, se existirem diferentes tipos de tratamento dentro de 
alguma dessas classes, ela deve ser subdividida. Por exemplo, a Classe 2 pode ser 
subdividida em sub-classes: 2.1 – idade entre 0 e 17; 2.2 – idade entre 18 e 20; e 2.3 – idade 
entre 21 e 120. Esta divisão faz sentido e deve ser feita se a especificação do software 
definir tratamentos distintos para estas diferentes faixas de valores. Neste caso a Classe 2 
não é homogênea e, portanto, a execução de apenas um caso de tese da classe seria 
insuficiente. 
Deve-se notar que o modo como as classes de equivalência são definidas influencia 
fortemente a eficácia do critério. Esta definição deve ser feita de forma cuidadosa, 
analisando-se a natureza de cada variável de entrada do programa e a especificação do 
software em teste. 
O critério Análise de Valores Limite complementa o critério Particionamento de 
Equivalência. Freqüentemente as situações de transição de comportamento do software de 
uma classe para outra classe, as situações limite, são implementadas de forma incorreta. 
Estas situações costumam ser inerentemente complexas e acabam induzindo a erros de 
análise, projeto ou codificação. 
Para descobrir defeitos associados a estas situações é recomendada a seleção de dados 
de teste situados nos limites das classes. No exemplo anterior (variável idade, tipo inteiro, 
Classe 2 
(valores válidos) 
Classe 3 
(valores inválidos) 
Classe 1 
(valores inválidos) 
 -39 0 45 120 135 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 19 
 
que pode variar de 0 a 120 anos, incluindo os extremos) os valores limite seriam: 1, 0 e -1, 
referentes ao limite entre as Classes 1 e 2; e 119, 120, 121, referentes ao limite entre as 
Classes 2 e 3, conforme ilustrado na Figura 6. Notar que são selecionados valores 
exatamente no limite, valores imediatamente inferiores e imediatamente superiores ao 
limite. A definição dos valores limite também deve ser feita cuidadosamente, analisando-se 
a natureza de cada variável de entrada do programa e a especificação do software em teste. 
 
 
 
 
Figura 6: Valores Limite e Dados de Teste 
Teste baseado em modelos 
Alguns critérios caracterizam-se por utilizar modelos do software (representações 
intermediárias do software) como base para a seleção de dados de teste. Esses critérios são 
freqüentemente chamados de Teste Baseado em Modelos (Model Based Testing). Modelos 
como Máquinas de Estados Finitas (FSM), ou modelos definidos em linguagens como 
UML (Unified Modelling Language) ou SDL (Specification and Description Language) 
podem ser utilizados para este propósito. 
O Teste Baseado em Casos de Uso utiliza os modelos de Casos de Uso (representação 
definida na UML), criados na fase de análise de requisitos e de projeto do software, para a 
seleção de casos de teste. Casos de Uso são muito usados para especificar o comportamento 
esperado do sistema do ponto de vista dos atores que interagem com o sistema. Como são 
elaborados normalmente em etapas iniciais do processo de desenvolvimento, esses modelos 
são úteis para o projeto antecipado de casos de teste, principalmente os que serão aplicados 
nos testes de sistema e de aceitação do software. 
 
A aplicação do critério de teste é feita nos seguintes passos: 
Classe 3 
(valores inválidos) 
Classe 2 
(valores válidos) 
Classe 1 
(valores inválidos) 
 -1 0 1 119 120 121 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 20 
 
a. Descrever os fluxos de eventos para o caso de uso. Devem ser descritos tanto o 
fluxo de eventos básico como os fluxos alternativos e de exceção. 
b. Definir o conjunto de cenários que serão usados nos testes. Cada cenário pode ser 
formado a partir dos fluxos de eventos identificados bem como das combinações 
desses fluxos. 
c. Definir casos de teste para cada um dos cenários, ou seja, para cada cenário definir 
valores de entrada, ações no software que provoquem a execução do cenário e as 
saídas esperadas. 
d. Executar o software com os dados de teste, avaliar se os resultados produzidos 
correspondem aos esperados, registrar os resultados e os incidentes observados. 
Notar que os passos a, b e c podem ser realizados logo que a especificação dos casos 
de uso esteja pronta e revisada; não é necessário esperar a conclusão da implementação dos 
casos de uso para realizá-los. O passo d pode ser realizado em momentos distintos, 
dependendo do nível do teste realizado: quando os módulos que implementam as funções 
especificadas nos casos de uso estiverem disponíveis (no caso do teste de “partes” do 
sistema); quando o sistema como um todo estiver integrado e disponível (no caso do teste 
de sistema); ou ainda, quando o sistema for utilizado no processo de aceitação pelo cliente 
(no caso do teste de aceitação). 
Naturalmente, outros modelos (da UML ou de outras linguagens) podem ser 
utilizados de forma semelhante para a seleção de casos de teste. Por exemplo, Diagramas 
de Estados (com os Statecharts) podem servir como base para a seleção de casos de teste 
que exercitem transições de estado que podem ocorrer em um objeto. Critérios de teste 
baseados em modelos de estados são úteis para aplicações nas quais muitas transições 
complexas de estado dos objetos são possíveis, tais como sistemas de controle de processos 
e sistemas de telefonia. 
Diagramas de Colaboração, que descrevem a interação entre objetos para especificar 
um comportamento, também podem ser utilizados para seleção de casos de teste. Critérios 
de teste baseados em Diagramas de Colaboração permitem avaliar interações específicas 
entre objetos, formadas por seqüências de comunicações. Os casos de teste visam a 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 21 
 
exercitar e avaliar se as trocas de mensagens, que caracterizam a colaboração de um 
conjunto de objetos, permitem atingir os propósitos definidos na especificação do sistema. 
6.2 Critérios da técnica estrutural 
Na técnica de Teste Estrutural os dados de teste são selecionados por meio da análise da 
estrutura interna do software. Portanto, o código fonte do software deve estar disponível, 
pois ele é utilizado para a seleção dos dados de teste. A motivação para o uso desses 
critérios muitas vezes é feita com questionamentos do tipo: “você confiaria em um software 
se fosse informado que algumas instruções deste software nunca foram executadas antes?” 
Esta pergunta enfatiza que defeitos em trechos não exercitados do código fonte do software 
certamente não serão descobertos. 
Na Técnica Estrutural uma unidade de software (função, procedimento ou método) é 
considerada como o conjunto de seus componentes estruturais. Estes componentes 
estruturais podem ser comandos de desvio (como os comandos: if-then; switch; while e 
repeat) ou outros comandos (instruções como: x = y + 2; read(a,b); x = func(a,b) ). O 
software pode ser representado por um Grafo de Fluxo de Controle (GFC) composto de nós 
– correspondem a blocos de comandos que são sempre executados conjuntamente -, e 
ramos, que correspondem a possíveis desvios no fluxo de execução. O GFC possui um 
único nó de entrada, um único nó de saída, e define um conjunto de caminhos que podem 
ser executados do nó de entrada ao nó de saída, passando por certos comandos e desvios ao 
longo da execução. Quando se executa o software com um dado de teste, algum caminho 
específico será executado no programa (istosó não ocorre caso o software entre em um 
laço infinito). 
A Figura 7 mostra um código fonte em C (identifier.c) e o respectivo GFC 11. Notar 
que o código fonte apresenta no lado esquerdo como comentários o número do nó do GFC 
ao qual o comando pertence. É possível identificar conjuntos de comandos executados 
sempre conjuntamente, por exemplo, os comandos precedidos por /* 01 */ que pertencem 
ao nó 1 do GFC. Pode-se também observar o efeito de comandos de desvio no fluxo de 
 
11
 Código fonte e GFC presentes em: Barbosa E., Maldonado, J., Vincenzi, A., Delamaro, M., Souza, S., Jino, 
M. “Introdução ao Teste de Software”, XIV Simpósio Brasileiro de Engenharia de Software”, 2000. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 22 
 
controle, por exemplo, o comando while presente no nó 4 do grafo, ou o comando if-then-
else iniciado no nó 8. 
 
 
 
 
 
 
 
 
 
 
 
Figura 7: Código Fonte e Respectivo Grafo de Fluxo de Controle 
 
Critérios de teste estrutural estabelecem componentes internos do software como 
elementos requeridos. O critério de teste Todos os Comandos (ou Todos os Nós) requer que 
cada comando do software seja exercitado pelo menos uma vez durante o teste. A 
determinação de dados de teste que exercitem um comando específico requer a análise do 
código fonte do software e a escolha de valores para as variáveis de entrada que provoquem 
a execução do comando. 
Por exemplo, a Figura 8 mostra um trecho de programa no qual há um comando de 
decisão if-then-else e o respectivo GFC. Para que os comandos representados por B sejam 
executados é necessária a seleção de valores de entrada tais que a condição lógica do 
comando if seja satisfeita; por exemplo, valores de entrada que façam com que x tenha 
valor 100 e y tenha valor 30 imediatamente antes do comando if (notar que x e y podem ser 
variáveis de entrada, mas também podem ser computadas internamente, a partir de outras 
variáveis). Outros dados de teste serão necessários para exercitar os comandos 
/* 01 */ { 
/* 01 */ char achar; 
/* 01 */ int length, valid_id; 
/* 01 */ length = 0; 
/* 01 */ printf (“Digite um possível identificador\n”); 
/* 01 */ printf (“seguido por <ENTER>: “); 
/* 01 */ achar = fgetc (stdin); 
/* 01 */ valid_id = valid_starter (achar); 
/* 01 */ if (valid_id) 
/* 02 */ length = 1; 
/* 03 */ achar = fgetc (stdin); 
/* 04 */ while (achar != ‘\n’) 
/* 05 */ { 
/* 05 */ if (!(valid_follower (achar))) 
/* 06 */ valid_id = 0; 
/* 07 */ length++; 
/* 07 */ achar = fgetc (stdin); 
/* 07 */ } 
/* 08 */ if (valid_id && (length >= 1) && (length < 6) ) 
/* 09 */ printf (“Valido\n”); 
/* 10 */ else 
/* 10 */ printf (“Invalido\n”); 
/* 11 */ } 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 23 
 
representados por C; por exemplo, dados que resultem nos valores x = 20 e y = 15 antes do 
comando if. 
 
 
 
 
 
Figura 8: Comando if-then-else e Respectivo Grafo de Fluxo de Controle 
 
 
 
 
Figura 9: Comando if-then e Respectivo Grafo de Fluxo de Controle 
O critério Todos os Ramos requer que cada possível transferência de controle seja 
exercitada pelo menos uma vez. A Figura 9 mostra um trecho de programa com um 
comando condicional if-then. Os dados de teste que satisfazem a condição do if, exercitam 
os comandos representados em B e também os em C. Este critério, no entanto (ao contrário 
do anterior), requer a execução de dados de teste adicionais, que provoquem a transferência 
de controle (ou ramo) do comando if diretamente para os comandos em C (sem passar por 
B). 
O critério Todos os Caminhos requer que cada diferente caminho no GFC seja 
executado pelo menos uma vez. Este critério é geralmente considerado excessivamente 
exigente visto que, em programas reais, a sua aplicação tende a gerar conjuntos muito 
grandes de elementos requeridos. Considere a Figura 10 que mostra um trecho de código 
com dois comandos if-then-else em sequência e o respectivo GFC; note que o segundo 
comando if pertence ao nó D no grafo. A execução de apenas dois casos de teste é 
suficiente para exercitar todos os nós e também todos os arcos do GFC; por exemplo, 
utilizando um caso de teste que exercite a seqüência ABDEG e outro que exercite a 
A …; 
A if (x > y * 2) 
B { … } 
C else 
C { … } 
D …; 
 
A 
B C 
D 
 
A …; 
A If (x > y * 2) 
B { … } 
C …; 
 
A 
B 
C 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 24 
 
seqüência ACDFG. No entanto, para satisfazer o critério todos os caminhos são necessários 
quatro casos de teste, cada um exercitando um caminho do GFC: ABDEG, ABDFG, 
ACDEG e ACDFG. 
 
 
 
 
 
 
Figura 10: Comandos if-then em Sequência e Respectivo Grafo de Fluxo de Controle 
Existem outros critérios estruturais que não serão abordados neste documento. Mais 
informações sobre os critérios apresentados e sobre como utilizá-los encontram-se em 
tutoriais específicos e em literatura especializada. 
7 Ferramentas de apoio ao teste 
As empresas de software são cada vez mais pressionadas a produzir produtos de qualidade 
em curto espaço de tempo. Esta situação coloca uma forte pressão em suas equipes de teste, 
que são levadas a tentar aumentar a cobertura dos testes realizados sem comprometer os 
prazos de entrega do projeto. 
O emprego de ferramentas de apoio pode reduzir o esforço e aprimorar a qualidade 
do teste. Estas ferramentas não são suficientes para automatizar completamente o teste, mas 
podem auxiliar o testador na realização de diversas atividades. 
São exemplos de atividades de teste para as quais se encontram ferramentas de apoio: 
• Definição dos elementos requeridos para o teste: para as diversas técnicas são 
determinados elementos requeridos que podem servir de base para a criação de 
casos de teste; 
A …; 
A if (x > y * 2) 
B { … } 
C else 
C { … } 
D if (z > w) 
E { … } 
F else 
F { … } 
G …; 
 
A 
B C 
D 
E F 
G 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 25 
 
• Avaliação de cobertura atingida no teste e a identificação de elementos requeridos 
não exercitados: para as diversas técnicas são avaliados o nível de cobertura 
atingido (percentual de elementos requeridos exercitados) e os elementos requeridos 
ainda não exercitados. As ferramentas permitem quantificar a qualidade do teste; 
• Captura de eventos e de respostas do 
software: gravação e reprodução de 
informações do teste, tais como: dados de 
entrada, eventos de entrada, interfaces e 
informações mostradas; 
• Execução do teste: execução do software 
com um conjunto de casos de teste e a 
avaliação do resultado produzido. 
Ferramentas podem ser aplicadas tanto para 
o teste de unidade como para o teste de 
sistema; 
• Armazenamento e gerenciamento de informações de teste: manutenção de 
informações de teste – planos, projetos, scritps e casos de teste. Ferramentas 
permitem também o rastreamento de informações associando casos de teste aos 
requisitos do software a serem validados; 
• Armazenamento e gerenciamento de incidentes: registro de informações sobre 
incidentes ocorridos e acompanhamento da resolução; 
• Definição e gerenciamento do processo de teste: definição de aspectos do processo 
de teste como recursos, medidas, atividades e tarefas, e também o gerenciamento da 
execução do processo de teste. 
A adoção de um processo de teste para a organização (veja próximas seções) pode 
incluir a avaliação de quais tipos de ferramentas são adequadas aos objetivos estabelecidos 
para o teste. 
 
 
 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e ConceitosBásicos Página 26 
 
8 Processo e documentação do teste: como organizar o trabalho 
A adoção de um processo bem estabelecido para realizar as diversas atividades da 
engenharia de software contribui positivamente para que se alcance o objetivo pretendido. 
Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, 
métodos, práticas e transformações, usado para atingir uma meta. A atividade de teste de 
software também deve ser conduzida por meio de um processo bem estabelecido. Um 
processo de teste de software é um conjunto de passos parcialmente ordenados constituídos 
por atividades, métodos e práticas, usadas para testar um produto de software. 
Um exemplo de modelo de processo de teste é o ArtProTest (“Artifact Oriented 
Process Model for Testing”) 12,13. Este modelo é baseado em artefatos de teste determinados 
na Norma IEEE Std 829-1998 14 e é formado por subprocessos, definidos e ordenados de 
forma a permitir que o teste seja eficiente e eficaz. 
No subprocesso Planejar é criado o Plano de Teste de Software, que contém, dentre 
outras informações: extensão e abordagem do teste; recursos necessários, equipe e 
treinamento, cronograma de atividades; ambiente operacional; itens a serem testados, o 
nível e abordagem de teste para cada item, atividades, tarefas e respectivos responsáveis, 
além de riscos e planos de contingência no teste. 
O subprocesso Projetar envolve: refinar a abordagem de teste, definir e especificar os 
casos de teste; estabelecer o ambiente e procedimentos de teste. 
O subprocesso Executar envolve: executar, registrar, suspender, retomar, parar, 
encerrar e tratar as contingências no teste. 
O subprocesso Registrar visa relatar a execução dos testes e os incidentes observados 
(defeito no software ou anomalia de funcionamento do ambiente). Também são 
sumarizados os resultados do teste e as avaliações baseadas nesses resultados. 
 
12
 Crespo, A. N.; Silva, O. J. ; Borges, C. A.; Salviano, C. F.; Argollo Junior, M. T. E.; Jino, M. “Uma 
Metodologia para Teste de Software no Contexto da Melhoria de Processo”. III Simpósio Brasileiro de 
Qualidade de Software, 2004. v. 3. p. 271-285. 
13
 Bueno, P.M.S., Crespo A.N., Jino, M., “Analysis of an Artifact Oriented Test Process Model and of Testing 
Aspects of CMMI”. In: 7th International Conference on Product Focused Software Process Improvement, 
Amsterdam., Lecturer Notes in Computer Science. Berlin: Springer-Verlag, 2006. v. 4034. p. 263-277. 
14
 IEEE Std 829 (1998), “IEEE Standard for Software Test Documentation”, IEEE, New York. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 27 
 
É importante destacar que existem diversas atividades associadas a cada subprocesso 
descrito anteriormente, que criam ou utilizam os artefatos que documentam o teste (plano 
de teste, projetos de teste, etc). A definição de como esta informação de teste deve ser 
estruturada em artefatos (isto é, a definição de “templates” de teste) é uma etapa importante 
da implantação de um processo de teste em uma organização. 
O processo de teste deve ser alinhado com o processo de desenvolvimento como um 
todo. Uma alternativa é organizar os subprocessos de teste considerando as principais fases 
do processo de desenvolvimento e associando a cada fase o nível de teste de software 
correspondente – unidades, integração, sistema e aceitação (Modelo V). As atividades de 
teste podem ser iniciadas junto com as atividades de desenvolvimento, logo que as 
informações necessárias estejam disponíveis. Neste caso, o planejamento do teste deve ser 
realizado junto com o planejamento do desenvolvimento, enquanto que o projeto do teste 
de aceitação pode ser iniciado logo que os requisitos do software tenham sido definidos. A 
execução de atividades de teste o mais cedo possível diminui as chances de que esta 
atividade seja feita de forma apressada no final do projeto, devido à necessidade de entregar 
o produto ao cliente. 
 Alguns modelos de processo de desenvolvimento de software, como o Espiral ou o 
RUP, definem iterações (ou ciclos) para o desenvolvimento do software. Ao invés da 
realização seqüencial das atividades de desenvolvimento do software, como no tradicional 
modelo “cascata” 15, são definidas iterações para o desenvolvimento e incrementos (ou 
releases) são associados a cada iteração. Cada incremento envolve a realização das 
atividades para: definição de requisitos, projeto, implementação, integração e testes. Nestes 
casos, as atividades de teste devem ser associadas às atividades de desenvolvimento em 
cada iteração, de modo que haja o adequado replanejamento, projeto, execução e registro 
dos testes. Recomenda-se realizar um planejamento global do teste junto com o 
planejamento do desenvolvimento. O teste final do sistema e o teste de aceitação são 
executados após o término da última iteração do processo de desenvolvimento. 
 
15
 Tipicamente, as atividades realizadas no modelo cascata são: análise de requisitos; projeto do software; 
implementação e teste de unidades; integração e teste de integração; teste de sistema; implantação e teste de 
aceitação. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 28 
 
Alguns modelos mais recentes enfatizam o projeto de testes e sua execução como um 
elemento central do desenvolvimento do software. A abordagem Desenvolvimento Baseado 
em Testes (ou TDD, sigla em inglês) é frequentemente adotada em métodos ágeis, como a 
Programação Extrema (XP). No TDD os casos de teste são criados pelos desenvolvedores 
antes mesmo que o código fonte seja criado. 
9 Análise de riscos: priorizar aspectos para o teste 
Em muitos casos o software em teste possui algumas partes (ou funcionalidades) nas quais 
a ocorrência de uma falha pode acarretar graves conseqüências a seus usuários, podendo 
impactar negativamente seus negócios e eventualmente até mesmo colocar a integridade de 
vidas humanas em risco. Por outro lado, o mesmo software pode possuir partes nas quais a 
ocorrência de falhas, embora não desejável, não seja crítica em termos dos negócios de seus 
usuários, impactando-os somente de forma marginal. 
Neste contexto, uma preocupação fundamental do 
teste é avaliar as funcionalidades do software que sejam 
mais importantes para o negócio de seus futuros 
usuários e propor e desenvolver atividades de teste que 
abordem com o devido cuidado essas áreas. Pensar nos 
testes com a perspectiva dos riscos que as falhas 
possam provocar é um aspecto importante para o 
sucesso do teste. 
A análise de riscos deve ocorrer no planejamento do teste e deve dar subsídios para a 
definição de tipos e técnicas de teste a serem utilizadas em cada parte do software, assim 
como o quão rigoroso deve ser o teste daquela parte do software. Em última análise, a 
consideração dos riscos envolvidos permite alocar os recursos de teste de uma maneira 
prudente, dosando o rigor e o esforço do teste de cada parte do software ao nível requerido 
de confiabilidade. 
 
 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 29 
 
10 Política e processo de teste: o papel do teste na estratégia da 
organização 
A definição de uma Política de Teste é fundamental para qualquer organização que 
pretende definir ou aprimorar as suas atividades de teste. Trata-se, portanto, de um primeiro 
passo importante que servirá de base para definição do processo de teste da organização. 
 A política de teste define, de maneira geral, os objetivos e a visão estratégica em 
relação ao teste. Portanto, deve estar alinhada com a política de qualidade e com os 
objetivos de negócios da organização. Ao se estabelecer uma visão comum sobre o teste 
para todos os envolvidos comesta atividade, obtém-se um alinhamento das iniciativas para 
a utilização ou melhoria do processo de teste, tanto no desenvolvimento como na 
manutenção de software. Recomenda-se, portanto, que a política de teste seja documentada, 
divulgada e tenha um responsável definido. 
A definição de indicadores associados aos objetivos do teste permite a avaliação e a 
melhoria contínua do processo de teste na organização. Tipicamente uma política de teste 
aborda: objetivos e importância do teste; níveis de qualidade a serem atingidos; nível de 
independência da equipe de teste; principais responsabilidades; definição em alto nível do 
processo de teste; e separação entre teste e depuração. 
A partir do momento em que se estabelece “o quê” as atividades de teste devem 
atingir na organização – a Política de Teste – pode-se trabalhar para definir “como” os 
objetivos serão atingidos. A definição do “como” dá-se pelo estabelecimento de um 
processo de teste. Modelos de processos genéricos de teste e modelos de maturidade de 
teste podem servir como inspiração nesta tarefa. 
Um modelo de processo genérico de teste, como é o descrito na Seção 8, pode ser 
adaptado às necessidades específicas de cada organização. Tal tipo de modelo define um 
conteúdo amplo em teste (formado por atividades, métodos, artefatos, etc.) que serve como 
base para o estabelecimento de processos customizados, fundamentados nas necessidades 
de teste específicas de cada organização. O termo Estratégia de Teste também é utilizado 
na literatura com significado semelhante, ou seja, atividades, métodos, artefatos de teste 
adotados por uma organização. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 30 
 
Modelos de maturidade de testes, tais como o Test Process Improvement (TPI) 16 ou 
o Test Maturity Model Integration (TMMi) 17, também podem ser utilizados para definir 
um processo de teste bem como para guiar a sua avaliação e melhoria. O TMMi é 
complementar ao modelo CMMI e aborda aspectos importantes para os gerentes e analistas 
de testes e demais profissionais de qualidade de software. Assim como o modelo em 
estágios do CMMI, o TMMi usa o conceito de níveis de maturidade para a avaliação e 
melhoria do processo de teste. 
A adoção de um processo de teste, feita por meio da customização de um modelo de 
processo genérico de teste, é referida como uma implantação ou configuração de um 
processo de teste na organização. Os modelos de processos genéricos de teste ou os 
modelos de maturidade do teste podem ser utilizados também para aprimorar, de forma 
controlada e gradual, um processo de teste já existente na organização. 
A implantação de um processo de teste deve ser feita de forma cuidadosa, por meio 
da análise das reais necessidades de teste e das possibilidades da organização. Fatores como 
tipo de software desenvolvido, requisitos de confiabilidade e segurança, bem como a 
disponibilidade de recursos humanos e financeiros da organização, devem ser levados em 
conta nesta implantação. Em geral, requisitos rigorosos de confiabilidade e segurança do 
software determinam a definição de processos de teste mais completos, contemplando 
vários níveis, tipos e técnicas de teste. Por outro lado, em muitos casos um processo “leve” 
– com poucos níveis e utilizando técnicas simples e documentando apenas o essencial – 
pode ser o suficiente. 
Processos de teste mais completos demandam um maior esforço por parte da 
organização, mas tendem a propiciar melhores produtos de software, além de evidências 
mais claras da qualidade do teste. 
 
 
 
16
 Koomen, T. and Pol M., (1999), “Test Process Improvement: A practical step-by step guide to structured 
testing”. ACM Press, London, England. 
17
 TMMi Foundation, “Test Maturity Model Integration (TMMi®) Version 2.0”, 2009. 
 Centro de Tecnologia da Informação Renato Archer – CTI/MCT 
 
Teste de Software: Motivação e Conceitos Básicos Página 31 
 
11 Conclusão: transformando conceitos de teste em melhores produtos 
de software 
Este documento apresentou um corpo de conhecimentos fundamentais em Teste de 
Software. O conteúdo foi abordado mais em extensão do que em profundidade, isto é, 
espera-se que o leitor tenha adquirido um conhecimento amplo dos vários aspectos das 
atividades de teste; entretanto, é necessário o aprofundamento nos assuntos específicos 
conforme o interesse e os objetivos específicos. 
Os guias e os tutoriais de teste (em elaboração) irão prover o aprofundamento em 
alguns aspectos tratados de forma rápida neste documento. A literatura específica de teste 
também pode ser útil para este intento. 
Espera-se que com a aplicação do conteúdo apresentado, os diversos atores 
envolvidos com as questões de qualidade e teste das mais diversas organizações possam 
definir ou aprimorar as suas práticas de teste. Em especial, espera-se que todos os 
participantes que compõem o ecossistema do SPB possam se beneficiar da aplicação deste 
conteúdo e também possam contribuir para o aprimoramento do conhecimento público de 
teste de software do SPB.