Gestão da Tecnologia: Gestão da Qualidade

Total e Melhoria Contínua de Processo

Aula 09
Testes de Software

Objetivos Específicos
• Apontar benefícios de testes de software como garantia de qualidade.

Temas
Introdução
1 O conceito
2 Tipos de teste
3 Depuração
4 Casos específicos
Considerações finais
Referências

Professor
Marvin Oliver Schneider
 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

Introdução
Na teoria um projeto perfeito deveria ter um resultado perfeito, sendo que todos devem
seguir com rigor aquilo que foi determinado. Mas o mundo não é perfeito.

Sabemos que na prática há muitos desvios e que a busca pela qualidade deve ser um
esforço constante. Como diz o ditado “errar é humano” e o fato que estamos implantando
melhoria, revisando processos, fazendo os projetos da melhor maneira possível não implica a
eliminação automática de todos os erros (PRESSMAN, 2011).

Principalmente quando falamos de um desenvolvimento de software, sendo um processo

muitas vezes complexo e impossível de estimar ou modelar na sua completude, devemos
aplicar uma série de testes, desde o início para garantia de qualidade final.

Esta aula discutirá um pouco sobre a necessidade dos testes, seus tipos e seus desafios.

Antes de ler a aula, veja o vídeo disponível em nossa Midiateca, que retrata a famosa obra
do Empire State Building em Nova York. Quantas vezes já não construímos software de uma
maneira muito parecida, com riscos extremamente críticos? Um software mal desenvolvido
pode gerar prejuízos milionários para empresas ou causar acidentes graves. Reflita um momento
sobre aplicações muito críticas e o que uma simples falha de software poderia causar.

1 O conceito
De acordo com Pressman (2011) testes muitas vezes são mais complicados e complexos
de organizar do que qualquer outra ação envolvendo engenharia de software. Por que isso é
assim? A complexidade de um software requer tanto testes nos componentes quanto na visão
macro para ver se tudo está funcionando bem em conjunto. Testes fazem parte de métodos
de verificação e validação respondendo à pergunta mais técnica “estamos desenvolvendo o
software corretamente?”, mas também à pergunta fundamental “estamos desenvolvendo
o software correto?”. Isso significa que o cliente deve estar presente no processo de testes.
E ele precisa de orientação durante todo o processo, pois dificilmente ele poderá testar de
uma maneira tão detalhada quanto um desenvolvedor por falta do entendimento técnico.
Muitas vezes atividades de teste ainda contam com uma equipe especializada que não faz
parte do pessoal de desenvolvimento em si. Isso ocorre por dois motivos: o primeiro é o
mesmo de um autor lendo e relendo seu texto e sempre passando pelo mesmo erro sem
corrigir. Produtos que nós mesmos desenvolvemos muitas vezes os percebemos com uma
visão bastante restrita e “viciada”. A segunda é o fato que o teste de software visa “criticar”
o produto final para conseguir melhoria. Para quem criou o sistema é uma tarefa dura, já
que o próprio produto está sendo analisado em detalhe. O benefício de uma equipe de teste
independente fica evidente.

Senac São Paulo- Todos os Direitos Reservados 2

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

2 Tipos de teste
Há uma série de testes que devem ser aplicados de acordo com o estágio atual do
desenvolvimento do produto. Pressman (2011) sugere trabalhar a espiral do Gráfico 1 “de
dentro para fora”, ou seja, começar incialmente pelas poucas unidades já desenvolvidas do
software, concentrando-se em aspectos do código para logo em seguida (quando houver um
número propício de funcionalidade já programado) aplicar um teste de integração, focando em
aspectos do projeto. No final do processo, então, chega-se ao teste de validação, comparando o
produto com os requisitos. Não fazendo parte de métodos de engenharia de software de acordo
com Pressman (2011), mas com muita importância para nossa disciplina, ainda temos em um
nível mais alto o teste de sistema que deve testar se o software combina com os processos, as
pessoas, hardware, ou seja, os elementos que não fazem parte do código em si.

Gráfico 1 – Estratégias de testes.

Fonte: Pressman (2011).

Nota de acessibilidade: O gráfico classifica os testes e sua abrangência referente

ao sistema, sendo que o teste de unidade possui menor abrangência (apenas a unidade
específica) e o teste de sistema maior abrangência (sistema e suas interfaces).

De maneira mais detalhada podemos mencionar os seguintes tipos de teste de sistema:

• Teste de unidade (Gráfico 2): Testa uma unidade de código de maneira separada
concentrando-se em detalhes técnicos da unidade e em todos os caminhos de
processamento. Assim, é um teste muito detalhado que conta com uma série de
casos de teste específicos. Como o sistema muitas vezes ainda não se encontra
pronto na íntegra, interfaces diretas com outros módulos devem ser testadas via
pseudocontroladores (rotinas que controlam o módulo apenas para fins de inserção
de casos de teste) e pseudocontrolados (rotinas que simulam módulos controlados
pela rotina testada, também apenas com a finalidade de execução de testes).

Senac São Paulo- Todos os Direitos Reservados 3

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

Gráfico 2 – Teste de unidade.

Fonte: Pressman (2011).

• Teste de integração: Testes de integração testam a integração dos módulos em um

conjunto de sistema. A necessidade desse tipo de teste se dá através do fato de que
– mesmo funcionando localmente sem muito problema – a junção dos módulos
costuma criar uma dinâmica própria. Claramente um sistema é mais do que a mera
soma dos seus elementos. Pense em uma banda musical na qual todos sabem seu
papel, ensaiaram e estão prontos para tocar, mas não estão alinhados. Claramente
o resultado seria horrível. E um teste de integração trabalho justamente nisso: nas
interfaces para coordenar os esforços e não deixar problemas se tornarem uma
verdadeira avalanche para o sistema como um todo. Pressman (2011) divide os testes
de integração em duas abordagens que devem ser utilizadas de acordo com a maneira
de implementação do sistema:

▫▫ Teste de integração descendente (Gráfico 3): A integração se dá primeiro

através de módulos controladores centrais já desenvolvidos. Conforme o
sistema for progredindo, mais módulos controlados são adicionados. Onde
necessário, utiliza-se pseudocontrolados (“M4” e “M7” no Gráfico 3) para
simular o comportamento dos módulos individuais. Esta abordagem deve ser
utilizada em uma situação de desenvolvimento top-down1.

1 Top-down: “de cima para baixo”, isto é, o desenvolvimento começa primeiro com as rotinas principais controladores para então entrar nos
módulos mais específicos.

Senac São Paulo- Todos os Direitos Reservados 4

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

Gráfico 3 – Integração descendente.

Fonte: Pressman (2011).

▫▫ Teste de integração ascendente (Gráfico 4): A integração se dá primeiro através

de grupos de módulos controlados (chamados de “agregados” no Gráfico 4).
Esses módulos são testados inicialmente pelo uso de pseudocontroladores,
pois os controladores serão desenvolvidos e testados aos poucos. A abordagem
é indicada em uma situação de desenvolvimento bottom-up2.

Gráfico 4 – Integração ascendente.

Fonte: Pressman (2011).

2 Bottom-up: “de baixo para cima”, isto é, o desenvolvimento começa primeiro com os módulos de baixo nível para então progredir aos
controladores que devem juntar e coordenar suas atividades.

Senac São Paulo- Todos os Direitos Reservados 5

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

▫▫ Teste de regressão: Como visto, os testes de integração ocorrem mesmo

que ainda faltem muitas funcionalidades implantadas do sistema, ou seja,
rotinas, controladores e controlados são adicionados ao longo do tempo.
Sempre que haja uma adição de um módulo é necessário testar o software
como um todo. Isso também vale no caso de alterações, pois muitas vezes
eventos considerados “locais” possuem implicações muito maiores e podem
causar contratempos onde menos se espera.

▫▫ Teste fumaça: O teste fumaça é uma rotina de teste, frequentemente diária,

(PRESSMAN, 2011) que deve assegurar que pequenos problemas sejam
detectados de maneira pontual, minimizando o risco e ajudando a avaliar o
progresso do software de maneira mais detalhada.

• Testes de validação: Testes de validação devem ajudar a determinar se os requisitos

do cliente foram implementados de maneira correta no sistema. Como há
tradicionalmente muito ruído na comunicação entre times de desenvolvimento e
seus clientes, esses testes são componentes centrais do desenvolvimento garantindo
que não haja surpresas desagradáveis com o produto já em produção.

▫▫ Teste alfa: De acordo com Pressman (2011), testes alfa são testes do
sistema pelo cliente e são executados na presença do(s) desenvolvedor(es),
normalmente até no escritório da software house. Assim, o ambiente é muito
mais controlado e o método deve ser utilizado mais cedo no processo de
desenvolvimento, pegando muitas vezes problemas mais graves e assegurando
a comunicação pontual sobre o assunto entre cliente e desenvolvedor.

▫▫ Teste beta: Com a abordagem dos testes alfa – justamente por se encontrar
em um ambiente mais controlado – é complicado pegar vários problemas
que se apresentam apenas em condições reais. Assim, o cliente deve
continuar testando o sistema em situações reais ou pseudorreais, em seu
escritório e longe dos desenvolvedores que poderiam influenciá-lo. Estes
são os chamados “testes beta” e até empresas de software grandes como a
Microsoft costumam liberar versões dos seus sistemas para teste beta (novas
versões beta do Windows sempre são disponibilizadas a custo zero com a
finalidade de ainda pegar uma série de erros antes da liberação da versão
comercial para o mercado).

▫▫ Teste de aceitação: Tipicamente antes de o sistema entrar em produção o

cliente deve indicar sua aceitação do produto final, executando o teste de
aceitação e assinando o termo de aceite.

• Teste de sistema: Como dito, testes de sistema vão além do mero código, mas como
a interação com o ambiente não pode ser separada da lógica de programação, estes
também devem ser executados.

Senac São Paulo- Todos os Direitos Reservados 6

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

▫▫ Teste de recuperação: Teste que força o sistema a falhar e observe quanto

tempo e esforço ele leva para se recuperar (ou de maneira automática, ou
reiniciado manualmente).

▫▫ Teste de segurança: O testador deve fazer papel de intruso e tentar quebrar

os mecanismos de segurança do sistema, expondo dados particulares,
quebrando protocolos de comunicação, alterando informações, etc. Após
a invasão as correções devem ser feitas até o momento que o custo da
invasão apresenta um custo maior do que a vantagem obtida pela quebra
(PRESSMAN, 2011).

▫▫ Teste de esforço: Esse teste deve demandar dados e funcionalidades do

sistema em quantidades e frequências muito acima do normal, assim
chegando a uma ideia de escalabilidade do sistema.

▫▫ Teste de desempenho: Desempenho em situações reais normais é algo que

precisa sempre ser testado antes de o sistema entrar em produção, pois um
sistema com desempenho inadequado não terá chance de sobrevivência
em um ambiente produtivo. Assim, devemos ver a questão de resposta e
velocidade de manipulação de dados e principalmente analisar questões de
integração com outras soluções.

▫▫ Teste de disponibilização: No caso de o sistema ter que operar com vários

sistemas operacionais/plataformas, ele precisa ser testado e aprovado em
todas essas circunstâncias.

3 Depuração
Achamos um problema. E agora? É nesse momento que devemos começar com o
processo de depuração que conta com uma série de desafios adicionais e muitas vezes
requerem habilidades de “detetive”. Alguns desafios são (PRESSMAN, 2011).

• O sintoma pode aparecer em um contexto específico, mas a causa pode se encontrar

em uma rotina ou um local muito afastado desse contexto. Assim, por exemplo, uma
declaração incorreta de uma constante no início de um código refletirá em um local
completamente distinto.

• O sintoma pode ser algo temporário. O cliente pode relatá-lo, mas o analista pode
não conseguir pegá-lo em situações não sendo reais. Às vezes a análise pode requerer
muita paciência de todos os lados.

• Erro humano pode estar envolvido e assim pode não se tratar de um erro, e sim de
um processamento correto baseado em manuseio incorreto.

Senac São Paulo- Todos os Direitos Reservados 7

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

• Pode haver erros de sincronia em uma situação com vários sistemas rodando. O
sistema pode herdar problemas de outros.

Há uma série de abordagens de depuração que mais se adequam a cada situação:

• A abordagem de “força bruta” busca encontrar erros em dados gerados

automaticamente como logs e dumps, normalmente com muito ruído e assim
requerendo muito esforço do analista.

• No caso do “backtracking” analisa-se o código a partir de um incidente de maneira retroativa.

É claro que essa técnica nem sempre pode ser utilizada, vistos os desafios anteriores.

• Muitas vezes o processo requer uma análise mais profunda com um levantamento
de dados específicos e com a análise de hipóteses. Nesse ponto, outros analistas
experientes podem ser de grande valor para o encontro e a eliminação do problema.

Gráfico 5 – Processo de depuração.

Fonte: Pressman (2011).

O processo de depuração então parte do resultado negativo do teste (Gráfico 5) para a

depuração. Caso haja apenas suspeitas, testes adicionais devem ser executados e levados em
consideração.

No caso da identificação das causas as devidas correções devem ser feitas e precisamos
testar o efeito dessas alterações no software como um todo através de um teste de regressão.

Senac São Paulo- Todos os Direitos Reservados 8

 Gestão da Tecnologia: Gestão da Qualidade Total e Melhoria Contínua de Processo

4 Casos específicos
Como há muitos sistemas diferentes, os testes devem se adequar à situação concreta.
Para ilustrar melhor esse desafio, aqui apenas alguns pontos específicos:

• Em aplicações Web um dos testes centrais é o teste de esforço, pois de um dia para o
outro o número de acessos pode aumentar muito levando à indisponibilidade do sistema.

• Aplicações Web que manipulam dados sigilosos precisam cuidar em especial da

parte de segurança e os respectivos testes devem ser um dos focos, pois o sistema
estará disponível para um universo muito grande de usuários, entre estes também
especialistas em segurança.

• Testes de integração ascendentes ou descendentes são de difícil execução em

um sistema desenvolvido orientado a objetos, pois o sistema em si normalmente
não comporta esse ponto de vista de hierarquia. Em vez disso, juntam-se classes
colaboradoras, segue-se o fluxo de eventos ou a sistemática de classes independentes
e classes dependentes.

Considerações finais
Testes contribuem de maneira fundamental para a qualidade de um sistema. Nesta aula
vimos tipos de teste de software, o processo de depuração e seus desafios, bem como alguns
casos específicos e suas consequências nos testes.

Caso já tenha desenvolvido um sistema, como foi o processo de testes? Houve alguma
organização via casos de teste? Um grupo independente cuidou dos testes, ou apenas os
desenvolvedores testaram? Como foi o envolvimento do cliente?

Muitas vezes há como melhorar o processo atual de teste. Os benefícios em termos de

qualidade – e assim de satisfação de usuário – são muito interessantes.

Para quem gostaria de se aprofundar mais nesta matéria ainda indico a obra de Delamaro
(2012).

Referências
DELAMARO, Marcio Eduardo; JINO, Mario; MALDONADO, José Carlos. Introdução ao teste de
software. São Paulo: Campus, 2012.

PRESSMAN, Roger S. Engenharia de Software: Uma abordagem profissional. Porto Alegre:

AMGH, 2011.

Senac São Paulo- Todos os Direitos Reservados 9