Estratégias de Teste de Software

Núcleo de Educação a Distância

www.unigranrio.com.br
Rua Prof. José de Souza Herdy, 1.160
25 de Agosto – Duque de Caxias - RJ

Reitor
Arody Cordeiro Herdy

Pró-Reitor de Administração Acadêmica Pró-Reitora de Ensino de Graduação

Carlos de Oliveira Varella Hulda Cordeiro Herdy Ramim

Pró-Reitor de Pesquisa e Pós-Graduação Pró-Reitora de Pós-Graduação Lato Sensu e Extensão

Emilio Antonio Francischetti Nara Pires

Produção: Fábrica de Soluções Unigranrio Desenvolvimento do material: André Luiz Braga

Copyright © 2018, Unigranrio

Nenhuma parte deste material poderá ser reproduzida, transmitida e gravada, por qualquer meio eletrônico,
mecânico, por fotocópia e outros, sem a prévia autorização, por escrito, da Unigranrio.
Sumário
Estratégias de Teste de Software
Objetivos ........................................................................................... 04
Introdução ......................................................................................... 05
1. Níveis de Teste ..................................................................... 06
1.1 Processo Geral e o Modelo V .................................................. 06
1.2 Unidade .............................................................................. 07
1.2.1 Testes Unitários .................................................................... 07
1.2.2 Testes de Componente .......................................................... 09
1.3 Integração ........................................................................... 10
1.4 Sistema .............................................................................. 11
1.5 Aceitação ............................................................................ 13
2. Tipos de Teste ..................................................................... 14
2.1 Funcionais ........................................................................... 14
2.2 Não Funcionais ..................................................................... 14
3. Técnicas de Teste .................................................................. 16
3.1 Teste por Especificação .......................................................... 16
3.2 Teste Estrutural .................................................................... 17
Síntese ............................................................................................ 19
Referências ........................................................................................ 20
Objetivos
Ao final desta unidade de aprendizagem, você será capaz de:

▪▪ Compreender o que são níveis, etapas, tipos e técnicas de teste

de software;
▪▪ Conhecer todas as etapas de um teste de software;
▪▪ Entender, planejar e executar cada etapa dos níveis das etapas de
teste de software;
▪▪ Entender o que são testes funcionais;
▪▪ Conhecer e saber planejar todos os tipos de testes não funcionais;
▪▪ Conhecer as técnicas de teste e em que níveis e fases elas são aplicadas;
▪▪ Entender o que são e os objetivos das técnicas de teste de
Especificação e Estrutura.

4 Teste e Qualidade de Software

Introdução
A aplicação prática dos testes de software em um projeto de
desenvolvimento se expande, de modo geral, em largura e profundidade. No
aspecto de largura, há vários processos ou níveis de teste que correspondem
a fases específicas do desenvolvimento. No que se refere à profundidade, cada
um desses níveis terá técnicas, metodologias e estratégias a serem empregadas,
que dependerão das características do software em questão.

Primeiramente, analisaremos os processos em largura, dando uma

vista geral em cada um deles. Mais adiante, nos aprofundaremos um pouco
mais nas técnicas que podem ser utilizadas.

Teste e Qualidade de Software 5

1. Níveis de Teste
Vejamos, nos subtópicos a seguir, os níveis de teste existentes.

1.1 Processo Geral e o Modelo V

No início do desenvolvimento da engenharia de software, os testes
eram, geralmente, feitos ao fim do desenvolvimento, isso quando eram feitos.
As pesquisas e a evolução na área acabaram por entender que não se podia
esperar até que um software estivesse no fim do seu desenvolvimento para então
testá-lo. Começou-se a testar antes de seu final, porém, chegou-se à conclusão
de que o teste deveria percorrer e ser executado ao longo de todo o processo
de desenvolvimento. O Modelo V (MARIANI; PEZZÉ, 2007; PEZZÈ;
YOUNG, 2008) é uma forma de mostrar graficamente a relação entre as fases
de desenvolvimento e seus correspondentes níveis de teste, associando o ponto
inicial do processo, em que começam os testes unitários (seção seguinte) abrindo
até os testes finais do sistema apresentado ao usuário, Figura 1. Não confunda
com o numeral cinco, em algarismos romanos (V), trata-se da letra V do alfabeto.

Necessidades e
restrições reais Aceitação do usuário (teste alfa e beta) Produto
entregue
Revisão

Especificações Teste de sistema Integração

do subsistema Análise/
Revisão
Especificações/
Projeto de Teste de Integração Subsistema
subsistema Análise/
Revisão
Especificações
de componentes Teste unitário Componentes

Revisão, pelo usuário, do

comportamento externo à medida que
Validação é definido ou torna-se visível.
Legenda

Verificação

Figura 1: Modelo V. Fonte: Pezzè; Young (2008).

6 Teste e Qualidade de Software

1.2 Unidade

1.2.1 Testes Unitários

Existem muitas variações de tradução para os testes unitários (ou
unit est), que alguns chamam de testes de unidade ou unicidade. Eles são,
em geral, de responsabilidade do programador ou de alguma ferramenta ou
bibliotecas da linguagem de desenvolvimento (ref JUnit). Podem, ainda, ser
realizados por ferramentas automatizadas, mas, de toda forma, caberá ao
programador ou ao desenvolvedor configurar o seu programa para operar no
sistema automatizado.

Importante

Apesar de ser o programador o responsável pelos testes unitários, a equipe de testes deve
observar e aprovar o relatório de testes unitários, seja ele produzido pelo programador ou
pelas ferramentas automatizadas.

Devemos ter em mente que verifica-se uma resistência natural dos

desenvolvedores em realizar os testes unitários. Em muitos casos, declaram
tê-los realizado e assinam os termos de responsabilidade correspondente. Isso
se torna um grande problema, contudo, a verdadeira razão do procedimento
está no fato de que a especificação da granularidade dos testes unitários
muitas vezes se confunde com testes de componentes. Vamos analisar mais
profundamente esse problema a partir do exemplo a seguir:

Imaginemos que determinada função escrita em um código JAVA

execute o seguinte procedimento:

1. Varre uma lista de elementos;

2. Abre um arquivo;
3. Escreve o valor de cada elemento no arquivo.

Essa função recebe como parâmetro a lista que é, na verdade, um

componente da biblioteca padrão da linguagem JAVA, o qual não precisa
ser testado.

Teste e Qualidade de Software 7

 Nesse caso, então, o programador pode questionar: “Por que devo
testar um código que contém basicamente um comando de repetição,
mais um comando de escrita em arquivo da biblioteca da linguagem e
que também é pré-testado?”

Na maioria das linguagens, de fato, todos os elementos estão

previamente testados, mas há que se verificar o quanto existe de código
incluído pelo programador e de componentes.

A grande raiz desse conflito está na forma como o desenvolvedor

estabeleceu o limite entre os testes unitários e os testes de componente.
De modo geral, a orientação de boa prática indica que deve-se estabelecer
testes unitários nas funções que se está desenvolvendo nos pedaços de
código a partir do ponto que o nível de complexidade de utilização de
componentes internos proprietários da linguagem se tornem médios
ou altos.

O que queremos dizer com isso é que, por exemplo, se houver

laço de repetição que contenha uma ou mais estruturas condicionais, esse
trecho já deveria ser submetido a testes unitários.

Por outro lado, para definirmos os limites de um componente,

a primeira regra inevitável está em separar códigos desenvolvidos por
mais de um programador. Em outras palavras, se um programador está
fazendo um pedaço do código e outro programador, um outro pedaço, já
deve-se considerar um teste de componente e, posteriormente, o teste de
integração entre esses dois pedaços.

É possível também que esses dois pedaços de código feitos por

programadores diferentes não estejam componentizados, ou seja, seguindo
a norma de especificação e de projeto de componentes. Esta é, sem
dúvidas, uma falha, mas não da parte de testes, e sim de desenvolvimento.
Não cabe à equipe de testes alterar o projeto dos arquitetos do sistema,
contudo, esta pode ser uma indicação válida e interessante a ser reportada
à equipe de projeto. De toda forma, a equipe de testes deve considerar
esses dois pedaços de código como componentes diferentes a serem
testados e integrados.

8 Teste e Qualidade de Software

 Saiba Mais
Padrões de Projeto – A vasta experiência no desenvolvimento de software ao longo dos
últimos trinta anos permitiu que se coletasse as melhores práticas, arquiteturas e padrões de
construção de software. Uma dessas práticas é a modularização do
código em responsabilidades e assuntos específicos ou
componentização. Elas permitem e facilitam que os processos e
metodologias de teste de software sejam melhor e mais
adequadamente aplicados. Veja mais detalhes sobre estes padrões no
material indicado. Leia mais

De modo geral, o software desenvolvido dentro das normas e padrões

já terá seus componentes especificados e definidos pelos arquitetos, contudo,
existem algumas metodologias de desenvolvimento (como a metodologia
ágil), em que um grande pedaço da especificação do sistema está na mão de
um mesmo desenvolvedor, o qual nem sempre codifica de forma a separar
componentes e funções unitárias a serem testadas.

1.2.2 Testes de Componente

A boa prática orienta que um componente é definido por um conjunto
de dados e um conjunto de funções que processa esses dados e trabalha em total
desconhecimento do funcionamento interno dos outros componentes aos quais
está conectado. Ele se comunica com outros componentes por meio de interfaces,
definidas como funções com parâmetros a serem passados ou retornados.

Componente

A UML (OMG, 2005), que é a linguagem do processo padrão da

IBM-Rational (IBM COPORATION, 2007) para desenvolvimento de
software, o RUP (KRUCHTEN, 2003) define componente como:

Uma parte modular de um sistema que encapsula seu conteúdo e

cuja manifestação é substituível em seu ambiente. Um componente
define seu comportamento em termos de interfaces fornecida e
requerida. Portanto, um componente serve como um tipo, cuja

Teste e Qualidade de Software 9

 conformidade é definida pelas interfaces fornecida e requerida
(incluindo as semânticas estática e dinâmica).

1.3 Integração
Os testes de integração podem usar casos de teste a partir de casos de
uso, mas, em geral, a granularidade é maior, pois um caso de teste envolveria
um número específico de módulos, portanto, as técnicas serão similares a
testes de componente, comumente, de caixa preta.

No início das áreas de desenvolvimento, havia a crença de que a

modularização poderia garantir o funcionamento integrado dos sistemas. Em
outras palavras: se o programador testa três componentes individualmente e
todos eles passam em 100% dos testes, por que eles não funcionariam uma
vez conectados?

Existe um princípio básico na área de teste que naturalmente refuta

essa teoria, ou seja, testes exaustivos são impossíveis e, mais ainda, o fato
de um módulo ter sido testado e não apresentar defeitos não significa que
acontecerá depois. Obviamente, um defeito que não tenha surgido nos testes
de componente pode aparecer nos testes de integração, repercutindo esse erro
para os outros componentes.

Existe, ainda, um outro aspecto que é um pouco mais matemático: o

princípio das combinações lineares e não lineares.

Exemplo: dois módulos e cada um deles produz uma lista de coisas

diferentes, como pessoas e objetos de consumo. A integração desses modos
será linear porque as pessoas não estão relacionadas com os objetos de
consumo. Porém, se você tem a lista de usuários compradores de um site e
os produtos que ele vende, a lista resultante de produtos comprados por um
comprador não será a mera união das duas listas. A falha de um registro de
compra de um módulo pode ocasionar a venda de um produto que nunca foi
comprado, por exemplo.

Estas são algumas das razões pelas quais os testes de integração devem
ser feitos com conjuntos próprios e a combinação entre os módulos a serem
integrados, devidamente planejada.

10 Teste e Qualidade de Software

1.4 Sistema
Umas das definições mais comuns para os testes de sistema é dizer
que eles correspondem a conectar todos os componentes do sistema e testar
o funcionamento completo unificado, contudo, esta é, de fato, a última
etapa dos testes de integração, que se confunde com um teste de sistema.
Não é incomum uma equipe de testes considerar os testes de sistema como
completados após o fim dos testes de integração.

O equívoco dessa visão é o objetivo do foco dos testes de sistema e

os testes de integração. Neste último, temos que estar atentos à lógica de
cada componente integrado, enquanto nos testes de sistema, observar-se-á do
ponto de vista do usuário (BRAGA, 2016; WAZLAWICK, 2011) sem nos
preocuparmos com a lógica interna do sistema.

Os testes de sistema, geralmente, irão se ater mais às interfaces gráficas

com o usuário (GUI), e os casos de teste serão produzidos, via de regra, a
partir dos casos de uso de mais alto nível, criados a partir dos requisitos de
negócios e de sistema (SOMMERVILLE, 2011a, 2011b).

Se o sistema contiver pacotes externos ou softwares de prateleira que

façam parte do sistema, eles podem ser testados aqui, assumindo que sua
integração com o sistema não seja forte. Um dos exemplos mais comuns
são pacotes de geração de relatórios. Estes sistemas, em geral, acessam
diretamente o banco de dados do sistema desenvolvido e criam relatórios com
as especificações do usuário com pouca ou nenhuma interação com o sistema
principal. Por outro lado, pacotes de geração de formatos para impressão que
são usados dentro do sistema quando o usuário deseja uma versão impressa de
uma tela devem ser incluídos na fase de testes de integração.

Esta integração final terá a grande chance de trazer “comportamentos

emergentes”, que é uma outra característica dos testes de sistema.

Veja como o comportamento emergente pode ser definido:

(...) alguns elementos da funcionalidade do sistema só se tornam

evidentes quando colocados juntos. Esse comportamento emergente
pode ser planejado e precisa ser testado. Por exemplo, você pode

Teste e Qualidade de Software 11

 integrar um componente de autenticação com um componente que
atualiza as informações. Assim, você tem uma característica do
sistema que restringe as informações de atualização para usuários
autorizados. Contudo, às vezes, o comportamento emergente não é
planejado ou desejado. É preciso desenvolver testes que verifiquem
se o sistema está fazendo apenas o que ele supostamente deve fazer.
(SOMMERVILLE, 2011a)

Os testes de integração devem refletir situações real life, ou seja,

quando o sistema estiver em pleno funcionamento no cliente. Para tal, é
importante que o cliente forneça dados reais ou o mais próximo possível dos
que serão usados no dia a dia.

Um exemplo bem simplório, mas que ocorre com muita frequência,

está em tamanhos de campos de dados para nomes de pessoas e seus e-mails.
A maioria dos sistemas criados no ocidente não consideram nomes ou e-mails
de mais de 50 caracteres, o que parece bastante natural nas culturas latinas e
anglo-saxônicas; contudo, se observarmos as linguagens de origem indianas
e cantonesas, os nomes próprios e, consequentemente, nomes de e-mails
podem atingir até mais de 150 caracteres. Veja alguns nomes, a seguir, de
esportistas Iranianos e Egípcios, sem considerarmos, ainda, os domínios de
seus e-mails:

▪▪ Khalil Mahmoud K Abir Abdelrahman;

▪▪ Mohanad Ahmed Dheyaa Al-Azzawi;
▪▪ Bashir Asgari Babajanzadeh Darzi.

Importante
A equipe que vai executar os testes de sistema deve ser diferente, para evitar os vícios
já adquiridos nos testes de integração. De preferência, neste ponto, representantes do
cliente são ideais. Segundo Agarwal, Tayal e Gupta (2010), os testes de sistema são, na
verdade, divididos em três partes, Alfa, Beta e Aceitação, sendo os testes Beta feitos por
futuros usuários selecionados do sistema e dos testes. O Alfa é realizados pela mesma
equipe de teste. Outros autores preferem colocar os testes de aceitação como uma quinta
etapa dos testes.

12 Teste e Qualidade de Software

1.5 Aceitação
Alguns autores, como Agarwal, consideram o teste de aceitação
como a última parte do teste de sistema, mas, de modo geral, é visto como
um teste à parte, na última etapa. Também são chamados de “Teste de
Usuário” ou “Teste de Release” e é onde se considera a aprovação formal
(Sign Off) do cliente.

Existem outros testes a serem feitos no final do ciclo de desenvolvimento

que são considerados por alguns autores como parte da fase de testes de
aceitação. De toda forma, eles estarão relacionados com o usuário e o ambiente
final de operação do software:

▪▪ Configuração: alguns sistemas podem ter configurações não

só complexas, mas, também, questões de compatibilidade com
o sistema de desenvolvimento. Em teoria, parece óbvio que um
sistema de desenvolvimento deveria ser igual ao sistema do cliente,
mas, na prática, sempre existem diferenças desconhecidas. Por essa
razão, devemos fazer testes visando a testar as configurações iniciais
e de operação do sistema.
▪▪ Migração: a configuração de um sistema recém-finalizado pode
não ser a única coisa a ser ajustada em sua instalação, mas, muitas
vezes, o processo pode requerer que dados ou processos antigos
sejam portados para o novo sistema ou ambiente. Um processo
de migração pode se tornar tão complexo em alguns casos que
pode vir a ser um projeto em separado. Os testes de migração
são desafiadores, uma vez que os valores de teste não podem ser
simplesmente criados, mas devem refletir as características dos
dados originais que serão migrados. Além disso, após a migração,
os novos dados migrados precisam ser testados e podem não ser
possível compará-los diretamente com os originais, em razão de
uma mudança de estrutura muito drástica. Os casos de teste devem
ser projetados de tal forma a garantir a consistência lógica e de
negócios dos dados, independentemente de sua estrutura.
▪▪ Homologação: após a execução de todos os testes, inclusive a
aprovação do cliente, seria natural supor que o sistema já estaria
aprovado para uso, contudo, em alguns casos, certas categorias

Teste e Qualidade de Software 13

 de sistemas precisam de aprovações burocráticas especiais que
garantam seu funcionamento ou até mesmo procedimentos e dados
específicos que o cliente tenha para aprovação final. Esses testes
são, em geral, executados pela equipe de testes do próprio cliente
ou sob supervisão estrita.

Saiba Mais
O modelo Ágil de desenvolvimento segue uma série de processos
diferentes dos padrões comuns e, como tal, os testes de software
têm metodologias e técnicas diferentes. Veja com mais detalhe as
características dos testes ágeis no material indicado. Leia mais

2. Tipos de Teste
Vejamos, a seguir, os tipos de testes de software.

2.1 Funcionais
Não é uma tarefa muito fácil falar especificamente de testes funcionais,
uma vez que tudo que vimos até agora são, de fato, testes funcionais. Existem
somente duas categorias de teste nesse contexto: os relativos a alguma
funcionalidade e os que visam a garantir alguma característica do sistema que
não está diretamente associada a uma função, ou seja, os não funcionais.

2.2 Não Funcionais

Os requisitos não funcionais de um sistema estão mais focados no
modo como as suas funções são executadas do que propriamente no que elas
fazem. Os testes não funcionais devem garantir que estes requisitos sejam
cumpridos. Existem várias categorias já bastante conhecidas, a maioria dos
sistemas. Por exemplo, a segurança estará relacionada a várias funções, como
o login no sistema ou o acesso aos dados, contudo, terá um requisito geral
indicando as permissões que o sistema deverá ter. Cada sistema adota com

14 Teste e Qualidade de Software

maior ou menor exigência os requisitos, dependendo do seu tipo. No caso
dos sistemas bancários, será o nível de segurança; no caso dos de automação,
será performance.

Entre os requisitos mais conhecidos, podemos citar:

▪▪ Performance: de modo geral, os sistemas que requerem limites

mínimos de performance irão especificar o volume de informação
e processamento ao qual o sistema deve responder. É importante
que os valores dos dados de teste tenham não somente volume,
mas diversidade, para que a performance seja testada em todas as
necessárias funções do sistema.
▪▪ Carga: os requisitos de carga estarão mais ligados ao volume de
dados, então de certa forma, não são muito diferentes dos de
performance, contudo, no caso da carga, a velocidade de resposta
não é tão importante, nem a diversidade dos dados. A carga
corresponderá não somente à capacidade de dados armazenados,
mas à quantidade de acesso às funções, independentemente da
velocidade de resposta. Os sistemas de arquitetura WEB têm,
usualmente, necessidade de testes de carga, como os sites de venda
de produtos. Existem várias ferramentas que simulam uma grande
quantidade de usuários simultâneos acessando o sistema.
▪▪ Estabilidade: está ligada à capacidade de o sistema não falhar e
funcionar continuamente por todo o tempo especificado. Esse tipo
de requisito, geralmente, está associado a sistemas que precisam
funcionar continuamente 24x7 (24h, 7 dias por semana), como
sistemas hospitalares. Costumamos chamar esse requisito de “Alta
Disponibilidade”. Ele estará, de modo geral, mais ligado ao hardware
do sistema e utiliza sistemas redundantes em paralelo, que se alternam
quando um deles falha. Haverá algumas ferramentas automatizadas
capazes de “derrubar” os sistemas para testar a sua estabilidade.
▪▪ Segurança: é um requisito presente em quase todos os sistemas,
visto que, mesmo que um software em si mesmo não necessite
de segurança, poderá conviver com outros softwares na mesma
máquina, abrindo portas para invadir outros sistemas. Os testes
básicos de segurança, na maioria dos casos, envolve testes de
senhas, acessos a áreas do sistema proibidas etc.; contudo, sistemas

Teste e Qualidade de Software 15

 em que a segurança pode vir a ser um requisito mais crítico pode
ser necessária a intervenção de profissionais especialistas em quebra
de segurança. Em muitas organizações, empregam-se os chamados
hackers (invasores de sistemas), para provar a qualidade da segurança
dos seus sistemas.
▪▪ Usabilidade: é um dos testes principais e praticamente indispensável
à maioria dos sistemas. Por mais eficiente que um sistema seja, se for
muito complexo, de forma que o seu usuário não consiga usá-lo, ele se
torna inútil. Existem formas de atender a este requisito, e uma delas está
nas especificações do usuário; porém, ao longo do tempo, a engenharia
de software foi desenvolvendo vários critérios gerais a serem aplicados
à usabilidade de todos os softwares. Por exemplo, critérios de cor da
interface com o usuário, tempo de resposta de uma funcionalidade,
utilização por pessoas com dificuldades visuais etc. (BRAGA, 2016;
GRAHAM; EVANS, 2007; PEZZÈ; YOUNG, 2008).

3. Técnicas de Teste
Algumas metodologias são utilizadas no momento da realização dos
testes de software. A seguir, conheceremos, em detalhes, cada uma delas.

3.1 Teste por Especificação

Essa metodologia de testes, pertencente à categoria dos testes funcionais
(AGARWAL, 2010; BARBOSA et al., 2004; PEZZÈ; YOUNG, 2008) e
também chamados de testes de caixa preta, é geralmente utilizada nos testes de
componente (SOMMERVILLE, 2011a, 2011b). O seu objetivo é determinar,
independentemente da implementação interna de um módulo ou componente, se
a sua saída produz os valores esperados dada uma certa entrada de acordo com as
suas especificações. Ela vai identificar os seguintes tipos de erros ou problemas:

▪▪ Funcionalidades não implementadas;

▪▪ Erros no modelo de dados;
▪▪ Problemas de acesso a fontes de dados externas;

16 Teste e Qualidade de Software

 ▪▪ Interfaces não implementadas ou incorretas;
▪▪ Classes de dados de entrada inválidas;
▪▪ Combinações raras de valores de entrada.

Existem duas categorias para essa metodologia de testes, Figura 2, os

funcionais positivos e negativos. O primeiro caso é quando colocamos entradas
válidas e verificamos o resultado esperado. No segundo caso, utilizamos valores
de entrada inválidos e, neste caso, haverá dois tipos de valores esperados:
o primeiro seria a indicação de uma condição de erro, como um aviso ou
registro em um relatório; o segundo, seria, obviamente, não obter nenhuma
saída válida. Vamos imaginar, por exemplo, que colocamos um usuário e
senha incorretos. Deveríamos esperar um relatório de erro ou, na melhor das
hipóteses, nenhuma ação do sistema; contudo, se o sistema aceitar a senha
incorreta e deixar o usuário se conectar, será um defeito de terríveis proporções.

Entradas inválidas
Dados de teste de Ie
entrada

Sistema

Valores de saída que

Dados de saída De indicam a presença
esperados de defeitos

Figura 2: Testes funcionais. Fonte: Agarwal et al. (2010).

3.2 Teste Estrutural

Os testes estruturais, também chamados de “Teste de Caixa Branca”,
em contraposição aos testes de caixa preta, visam a, como o próprio nome
pode indicar, testar internamente os componentes desenvolvidos. Existe grande
chance de um teste de caixa preta não identificar uma falha que esteja ocorrendo
dentro do componente ou módulo.

Teste e Qualidade de Software 17

 Imagine, por exemplo, um componente que processe a venda de
vários produtos e o resultado total da venda pareça correto, mas apenas por
coincidência dos produtos, sendo testados não apresentarem valores decimais,
uma vez que o caminho interno do componente falha para valores decimais que
não foram testados.

Uma outra situação, até mais comum, são componentes cujo teste de caixa
preta é mais difícil de ser realizado por meio de pares de valores de teste entrada e
saída. Isso porque tais componentes podem ter sua saída diretamente enviada para
um sistema externo ou separado, como um banco de dados ou um servidor remoto.
Torna-se mais prático realizar testes internos na estrutura de tais componentes.

Esses testes, muitas vezes, se confundem ou são de fato utilizados nos

testes unitários, apesar do fato de que um teste estrutural, via de regra, seria
realizado em um componente inteiro e agregando o equivalente a vários testes
unitários. Os agentes de teste, nesse caso, em geral, serão desenvolvedores, pois
devem conhecer bem a estrutura interna dos componentes e os Casos de Teste
criados devem garantir percorrer cada caminho dos fluxos de decisão, repetição,
assim como os seus limites. Em outras palavras, se um pedaço de código tem
um laço de repetição que vai de 0 até o número de componentes de uma lista,
não é necessário verificar cada execução do laço mas a primeira, a última e
alguma intermediária por segurança (AGARWAL et al., 2010). O princípio do
teste exaustivo não é viável, portanto, o conjunto de testes sempre será finito
(BARBOSA et al., 2004; DELAMARO; MALDONADO; JINO, 2016).

Figura 3: Testes estruturais. Fonte: Agarwal et al. (2010).

18 Teste e Qualidade de Software

Síntese
Nesta unidade, vimos as três dimensões mais importantes na construção
e execução do teste de software. Na primeira dimensão, abrimos em largura
para mostrar os níveis ou processos de teste de software aplicados em todas as
fases. Na segunda dimensão, aprofundamos cada um dos níveis de cada fase
com as técnicas detalhadas que serão aplicadas para construção dos valores e
metodologias de testes. Por fim, o plano funcional e não funcional dessas duas
dimensões, em que verificamos a influência e a repercussão de cada função
em características não funcionais, ou seja, como o sistema deverá funcionar,
como aspectos de segurança, performance etc.

O conteúdo dessa unidade permitirá que acompanhemos, revisemos e

aprovemos os planos de teste criados para o software.

Teste e Qualidade de Software 19

Referências
AGARWAL, B. B.; TAYAL, S. P.; GUPTA, M. Software Engineering &
Testing: an introduction. Jones and Barlett Publishers, 2010.

BARBOSA, E. F. et al. Introdução ao teste de software: notas didáticas

do ICMC. Disponível em: <http://pbjug-grupo-de-usuarios-java-da-
paraiba.1393240.n2.nabble.com/attachment/2545944/0/>. Acesso em: 21
ago. 2018.

BRAGA, P. H. C. Teste de Software. São Paulo: Pearson Education do

Brasil., 2016.

CRAIG LARMAN. Utilizando UML e padrões. Disponível em:

<https://books.google.com.br/books?id=hzl2tmT8QkUC&pg=PA4
43&dq=Padroes+de+Projeto&hl=pt-BR&sa=X&ved=0ahUKEwj54_
ex5ffcAhUMg5AKHePVCyIQ6AEITjAH#v=onepage&q=Padroes%20
de%20Projeto&f=false>. Acesso em: 21 ago. 2018.

DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao

teste de software. 2 ed. Rio de Janeiro: Elsevier, 2016.

ELESSANDRA ESTEVÃO. Agile testing: o que é? Disponível em:

<https://www.concrete.com.br/2017/02/20/agile-testing-o-que-e/>.
Acesso em: 21 ago. 2018.

GRAHAM, D.; EVANS, I. Foundations of software testing. Product details

Paperback. Thomson Press.

KRUCHTEN, P. Introdução ao RUP: Rational Unified Process. 2 ed.

Ciência Moderna, 2003.

20 Teste e Qualidade de Software

MARIANI, L.; PEZZÉ, M. Testing Object-Oriented Software. In Emerging
Methods, Technologies, and Process Management in Software Engineering,
p.85-108. Disponível em: <https://doi.org/10.1002/9780470238103.ch5>.
Acesso em: 21 ago. 2018.

OBJECT MANAGEMENT GROUP – OMG. Unified Modeling Language

Specification Version 2.0: Needham, MA. Disponível em: <https://www.
omg.org/spec/UML/2.0>. Acesso em: 21 ago. 2018.

PEZZÈ, M.; YOUNG, M. Teste e análise de software: processo, princípios

e técnicas. Porto Alegre: Bookman, 2008.

SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson,

2011a/b. Disponível em: <http://tmv.edu.in/pdf/Diploma Syllabus/Computer/
TY_fifth_sem/Fifth Semester Curriculum.pdf.> Acesso em: 21 ago. 2018.

WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientada

a objetos. 2 ed. Campus, 2010.

Teste e Qualidade de Software 21