Teste de Software

UNIDADE 1
 Para início de conversa

Olá, caro(a) aluno(a), tudo bem?

Meu nome é José Neto, serei o seu professor nesta disciplina de Testes de Software.

Eu sou especialista em Engenharia de Software e mestre em Ciência da Computação, ambos pela Uni-
versidade Federal de Pernambuco.

Trabalho como analista de sistemas desde 2008 e tenho paixão por desenvolvimento de sistemas. Já
trabalhei com diversas linguagens de programação Delphi, PHP, Phyton e desde 2011, trabalho com
linguagem Java para web e recentemente programando para dispositivos móveis (Android). Espero
conseguir passar minhas experiências profissionais a você.

Palavras do Professor

Atualmente, o mundo está cada vez mais informatizado. A maioria dos dispositivos eletrônicos possui
algum tipo de processamento de informação embutido. Relógios, eletrodomésticos, telefones e outros
dispositivos são exemplos disto.

Contextualizando, você historicamente sobre a evolução dos softwares, na década de 60 com o surgimen-
to das linguagens de “alto nível” como Fortran, Pascal e C, possibilitaram que os softwares começassem
a realizar operações cada vez mais importantes. Toda essa evolução rápida dos dispositivos começou com
o surgimento dos sistemas operacionais.

Logo após, as primeiras redes de computadores foram formadas e a troca de informação entre computa-
dores foi o grande marco do futuro que estava por vir, a grande necessidade por softwares que pudessem
exercer diferentes funcionalidades em diversas áreas. O uso comercial de softwares começou a se tornar
cada vez mais comum.

Cada vez mais os aparelhos eletrônicos dependem de algum tipo de inteligência de processamento (sof-
tware). É claro que quando estamos comparando dois dispositivos, a primeira comparação que você faz
é a quantidade de recursos de hardware que cada dispositivo possui. Porém, muitas vezes ao comparar
dispositivos com hardwares bem diferentes muitas vezes nem conseguimos notar a diferença de desem-
penho funcional entre eles. Essa resposta é bem simples, o software é o grande responsável por conse-
guir otimizar os recursos de hardware e melhorar o desempenho destes dispositivos quando comparados
a outros com hardware bem superior.

1
 Orientações da Disciplina

Nesta disciplina você irá aprender sobre testes de software, bem como os tipos e as abordagens de
testes. Na segunda unidade, vamos discutir sobre a elaboração de casos de teste, em seguida, na ter-
ceira unidade vamos aprender sobre criação de testes automatizados e como desenvolver métricas de
testes, e por fim, na quarta unidade vamos falar sobre estimativas para testes e a criação de um plano
de testes.

DEFEITOS DE SOFTWARE

No mundo dos negócios tem muito a perder se houver uma falha no software. Os softwares operam
grandes cadeias de abastecimento, controlam unidades de manufatura, gerencia atendimento a clientes,
fornece acesso simultâneo a um grande volume de informações e entre outra gama de funcionalidades.

Exemplo

Isso significa que uma pequena falha poderá causar problemas graves,
como por exemplo:

• Permitir que um invasor executasse códigos maliciosos;

• Travar e parar de funcionar ao ser exposto a entradas incorretas;
• Expor dados confidenciais da empresa ou de seus usuários;
• Agir inesperadamente realizando operações incorretas.

Querido(a) aluno(a), no mundo ideal de desenvolvimento de software seria mais simples se após a codifi-
cação do sistema, todo código criado estivesse perfeito. Infelizmente, essa não é a realidade.

A regra é que normalmente os códigos não são perfeitos, estes problemas ocorrem por diversas razões.
Muitos sistemas operam com muitos estados, atividades, fórmulas e algoritmos complexos; além disso,
como tratado anteriormente na disciplina de requisitos, desenvolvemos sistemas baseados em requisitos
que na maioria das vezes o cliente está inseguro ou não sabe exatamente qual o comportamento ideal
que aquele requisito deveria ter.

Além de todos esses fatores, um projeto de software quase nunca é desenvolvido por apenas um profis-
sional, há uma equipe envolvida e esse fator é responsável por aumentar a complexidade do desenvolvi-
mento.

Mas então, o que é uma falha no sistema?

2
 Guarde essa ideia!

Geralmente, o software não respondeu corretamente ao executar operações dos requisitos descritos pelo
cliente. Seja um travamento em determinada operação, uma consulta exibindo dados incorretos ou um
comportamento correto de exibição de dados para usuários não autorizados.

A falha pode ser originada de determinadas razões:

• A especificação do sistema pode está incorreta;

• O requisito especificado pode ser impossível de ser codificado corretamente;
• O projeto do sistema pode conter um defeito arquitetural;
• O código fonte pode estar escrito em desacordo com o projeto ou com o requisito.

Listando essas possíveis origens de problemas na construção de um software, você deve ter percebido
que as falhas nem sempre são originadas na fase de codificação de um software. Requisitos mal escritos
ou projetos de análise e modelagem do sistema mal feito, fatalmente irão causar falhas nos sistemas.

Então, como garantir que o software funcionará corretamente durante sua vida útil após a implantação?

A resposta é a seguinte: infelizmente não há garantias que um software irá funcionar 100% corretamente
em 100% do tempo que estiver em operação.

Para tanto, existem técnicas de verificação estudadas pela engenharia de software que de certa forma
tranquilizam os clientes no uso de softwares dentro de seus ambientes corporativos. Tais técnicas têm
o objetivo de descobrir defeitos na aplicação evitando que esses defeitos fossem reproduzidos em am-
bientes de produção na operação do sistema. Essas técnicas de descobrimento de defeitos são
chamadas de Testes de Software, a qual será o foco de nossa disciplina.

TESTES DE SOFTWARE

Afinal de contas, tais testes de software solucionam os problemas?

Claro que sim!

Os testes de software servem para demonstrar aos usuários que o software opera corretamente em
acordo com os requisitos especificados, e para descobrir em quais situações o software reage de maneira
incorreta. Após o desenvolvimento, o primeiro objetivo é realizar a validação do sistema, isso significa
que o software deverá reagir corretamente usando determinado conjunto de casos de teste que refletem
o uso esperado do sistema.

O segundo objetivo deverá ser ir atrás de defeitos, isso significa que você usará casos de testes que
necessariamente não precisam refletir com precisão como o sistema deverá ser usado no ambiente de
produção. O teste é uma das atividades do amplo processo de validação e verificação (V & V) de um
software. 3
Bom, essas duas palavras parecem ser extremamente semelhantes, validação e verificação, porém, na
engenharia de software elas têm sentidos diferentes.

• VALIDAÇÃO significa: eu estou construindo o produto certo?

Isso significa que validação é atestar que o produto que está sendo desenvolvido está de acordo com o
que o cliente especificou.

• VERIFICAÇÃO significa: estamos construindo o produto da maneira certa?

Isso significa que o projeto que está em desenvolvimento está de acordo com o que foi especificado pelos
analistas de requisitos.

Em suma...

O objetivo final da V & V é estabelecer a confiança que o software que foi desenvolvido está
pronto para uso.

O processo de V&V normalmente incluem inspeções e revisões, tais atividades analisam diversos artefa-
tos desenvolvidos ao longo do projeto, tais como:

• Requisitos do sistema;
• Modelos do sistema;
• Esquema de banco de dados;
• Código fonte;
• Testes propostos para o sistema.

Agora você deve estar se perguntando por que a inspeção vai se preocupar com o próprio teste do sistema?

Uma vez que ela é uma espécie de testes para diversas fases do desenvolvimento?

A resposta é bem simples: durante um teste, erros podem mascarar outros erros.

Para deixar claro, durante a execução de um determinado teste, uma saída em desacordo com o resultado
esperado para aquele teste pode ser ocasionada por um defeito encontrado no sistema ou um teste mal
escrito com saídas erradas para a entrada desejada. Por esse motivo, os próprios testes precisam ser
inspecionados para que um erro de escrita do teste não ocasione um registro de um defeito inexistente
no código fonte.

4
 ??? Você sabia?

Caro(a) aluno(a), você sabia que o que é mais comum de se realmente testar é o código fonte?

Sim, após o desenvolvimento de um sistema é essencial que a equipe de testes conduza o processo corre-
tamente com o objetivo de encontrar defeitos no sistema. É muito importante que se registre todos os de-
feitos encontrados, atestando que o software passou por uma avaliação antes de ser entregue ao cliente.

Os tipos mais comuns de defeitos são:

• Defeitos de computação e de precisão: quando alguma parte do algoritmo está errado e a saída
retornada não é a esperada de acordo com as regras estabelecidas.

• Defeitos de documentação: defeitos encontrados na documentação dos requisitos do sistema se-

jam oriundos de regras mal compreendidas ou de restrições inalcançáveis.

• Defeitos de stress por sobrecarga: todo software é limitado pelo tamanho do volume de dados que
suas estruturas de dados podem suportar. Buffers, pilhas, filas e até mesmo estruturas de banco de
dados precisam ser projetadas de acordo com o volume de dados que deverá receber ao longo do ciclo
de vida de execução do projeto. Quando essas estruturas não suportam o volume de dados, utilizados
falhas que levam a travamentos ou falta de integridade dos dados podem acontecer.

• Defeitos de desempenho: ocorre quando o sistema não responde com a velocidade prescrita pelos
requisitos.

• Defeitos de recuperação: ocorre quando sistema tem uma falha e não consegue se recuperar logo
após a falha. Para ficar mais claro se hipoteticamente haja uma falta de energia, os dados que estavam
sendo processados antes de faltar energia, possam ser recuperados e o sistema continue a processar
quando o sistema voltar ao seu funcionamento.

• Defeitos de projeto: quando os componentes e arquitetura proposta para o sistema não satisfazem
as necessidades tecnológicas para atender as expectativas dos requisitos documentados.

Tipos de testes

Uma vez que, você entendeu a importância que os testes têm em um projeto de desenvolvimento de sof-
tware, é hora de detalharmos o processo de testes.

Na figura a seguir, apresenta um processo tradicional de testes.

5
 Figura 1 – Processo tradicional de testes.
Fonte: http://sereduc.com/dbheFl

A primeira atividade é projetar os casos de testes. Casos de teste são as especificações das entradas para
o teste, os procedimentos que os testadores deverão realizar e as saídas esperadas para aquele caso de
testes. Uma vez que o caso de teste é especificado, é necessário gerar os dados necessários para realizar
um teste. Para deixar claro, imagine que estamos testando um sistema para automatizar as compras de
um supermercado. Para realizar o caso de teste de uma compra é necessário que os produtos que serão
supostamente comprados e esteja cadastrado, o vendedor que realizará a venda também esteja cadastra-
do. Então, esses dados que serão utilizados durante o procedimento de testes, deverão estar presentes
no sistema. Após a geração desses dados é necessário executar o caso de teste, colher os dados gerados
após a execução e comparar a saída do sistema com a saída esperada pelo caso de teste.

Utilizando esse processo padrão de testes, na maioria dos casos, será possível garantir um funcionamen-
to aceitável do produto de software.

Geralmente, um sistema tem de passar por três estágios de testes:

1. TESTES DE DESENVOLVIMENTO

Testes são realizados durante o desenvolvimento para descobrir defeitos, estes incluem todas as ativi-
dades de testes que são realizadas pela equipe de desenvolvimento. Normalmente, o codificador que
desenvolveu o sistema é encarregado de testar o código produzido.

O objetivo dos testes de desenvolvimento é encontrar defeitos ainda na fase de construção do software
barateando o custo de realizar reparos e adequações aos requisitos ainda em seu desenvolvimento. Agora
eu irei detalhar cada tipo de testes de desenvolvimento.

Durante o desenvolvimento o teste pode ocorrer em três níveis de granularidade:

• TESTES UNITÁRIOS: testa unidades individuais do sistema ou classes.

Os testes unitários como já falados anteriormente têm o objetivo de testar as unidades do sistema. Um
sistema desenvolvido no paradigma de orientação a objetos uma unidade seria uma classe específica.

Os testes unitários visam testar todas as partes das unidades, neste caso seria realizar testes para os
métodos das classes. É muito importante garantir a cobertura de testes para todos os métodos, assim
é essencial testar todas as operações associadas ao objeto e colocá-lo em todos os estados possíveis.
6
 Exemplo

Por exemplo, se estamos testando o mesmo sistema do supermercado, devemos realizar operações que
faça o pedido de venda passar por todos os estados como, por exemplo: cadastrado, finalizado, faturado
e cancelado.

Um fator importante que devemos estar atentos é na questão que envolve herança. Uma vez que, a classe
realiza uma especialização a engenharia de software recomenda que os métodos herdados sejam retes-
tados para garantir o funcionamento correto de todas as operações.

Sempre que possível você deve automatizar os testes unitários.

Diversos frameworks de automatização de testes unitários estão disponíveis para uso no mercado, se
você está trabalhando com a linguagem Java, a maior parte da comunidade dos desenvolvedores utiliza
o JUNIT como ferramenta de automatização de testes unitários.

Agora irei fazer um questionamento a você: como você fará para testar unitariamente um método de uma
determinada classe que faz o uso de outro método em outra classe?

E ainda pior, e se essa outra classe ainda não estiver pronta?

Pois bem, é uma das coisas fantásticas do desenvolvimento de software. Existe um recurso chamado
mock de objetos o qual você vai simular uma saída de dados padrão que será realizada quando houver
uma determinada entrada. Assim, um método que dependa de outra classe para funcionar corretamente
pode ser testado individualmente levando em consideração que se o outro método funcionar corretamen-
te na forma esperada, o comportamento do seu método irá executar com sucesso.

É um pouco complicado à primeira vista entender esse conceito de “mockar” outras chamadas, mas vou
dar um exemplo simples de entender. Imagine que você está escrevendo um método que calcula a quan-
tidade de salários mínimos de um determinado valor.

Exemplo

Então, para ficar mais simples vamos supor que o salário mínimo seja de 500,00 reais.

E o seu método faz as seguintes operações:

1. Recupera o valor a ser calculado como parâmetro;

2. Chama o método getSalarioMinimo() de uma classe chamada SalarioMinimo;
3. Calcula a quantidade de salários mínimos presentes no valor passado;
4. Retorna esse valor.

7
Se você quer testar unitariamente a corretude do seu método, você precisa excluir as influências externas
do seu método fazendo a simulação dos dados obtidos de fontes externas. Então você vai criar um mock
para o método getSalarioMínimo() forçando uma determinada saída de dados desse método.

Entretanto, se você receber como parâmetro o valor de 1.000,00 reais, você irá assumir que sempre o
método getSalárioMínimo() vai responder a saída de 500,00 reais e o método para estar correto deverá
retornar o valor 2. Então, o objetivo de fazer mocks é garantir que sua lógica estar correta assumindo
dados obtidos de influências externas ao seu método (será controlado), para garantir que unitariamente
seu algoritmo está realizando as operações corretamente.

Quando isoladamente cada unidade realiza operações corretas, podemos passar para um próximo estágio
de testes, que representa testar a integração das unidades que estão em um mesmo componente.

• TESTES DE COMPONENTES: várias unidades são integradas e agrupadas no mesmo

componente, neste tipo de testes a preocupação deve concentrar-se em testar as interfaces entre os
componentes.

Os componentes de um software são compostos por diversas unidades que interagem entre si. Se esti-
vermos falando em um sistema de automação comercial temos, por exemplo, componentes de vendas,
compras, estoque e etc. Em um sistema de software, cada componente é projetado para receber uma
determinada entrada, executar uma ou diversas operações e retornar alguma saída. Essas regras que
determinam qual entrada que um componente recebe e qual saída esperada são chamadas de interface.

No ato de realizar testes em componentes, os erros mais comuns são:

• Mal uso de interface: erros acontecem na hora de enviar a entrada esperada por um determi-
nado componente, e ao trocar um dado de entrada inevitavelmente o processamento realizado será
equivocado e consequentemente a saída também sofrerá falha.

• Mau entendimento de interface: quando a especificação do componente não é bem escrita ou

quando o cliente do componente não entende devidamente qual o comportamento do componente.
As operações propostas pelo componente não executam o processamento esperado e o resultado é
inevitavelmente errado. Se você chamar um componente que executa uma busca binária e passa como
parâmetro um vetor desordenado é um exemplo clássico de um erro comum. A busca irá falhar, pois, o
dado que foi passado não atende aos requisitos da funcionalidade proposta pelo componente.

Infelizmente, testes de componentes precisam ser testes mais elaborados, pois como falado anteriormen-
te, se você fez testes unitários, todas as unidades foram testadas isoladamente, mas existem erros que
podem ser explorados na hora da integração de unidades.

8
 Exemplo

Por exemplo, se você tem uma unidade que implementa uma fila para um buffer, normalmente essas filas
são finitas e você passa uma fila infinita, provavelmente o sistema irá reagir de uma forma inesperada.

Outro erro comum de componente é quando o sistema utiliza componentes externos, muitas vezes progra-
mamos o sistema assumindo que a resposta do serviço sempre virá correta, são erros comuns de serem
pegos em testes de componentes.

• TESTES DE SISTEMA: realiza testes no sistema como um todo com objetivo de integrar todos
os componentes desenvolvidos.

Os testes de sistemas visam testar o funcionamento do software completo, realizando operações de

integração de componentes. O principal objetivo e verificar se as interfaces entre os componentes estão
funcionando de forma correta e gerar uma versão estável do sistema. O teste de sistema se assemelha
muito aos testes de componentes, o objetivo é garantir que as integrações funcionem, porém em uma es-
cala maior. Bom, se você prestar atenção, normalmente nos testes de componentes não é possível testar
um requisito funcional completo, pois cada requisito funcional normalmente demanda funcionalidades
de diversos componentes. É recomendado que testes de sistema fossem baseados em casos de uso, na
disciplina de análise e modelagem de sistemas e requisitos você consegue relembrar sobre casos de uso.

Testar sistema com casos de uso forçam que as interações entre os componentes ocorram e os possíveis
defeitos apareçam durante esse tipo de teste. Para maioria dos sistemas é difícil saber o quanto o teste
de sistema é essencial e quando você deve parar de testar o sistema. Para isso, você precisa modelar
quais possíveis cenários de testes é possível para cada funcionalidade. É importante que todas as funcio-
nalidades do sistema acessadas por meio de menus sejam testadas. Ao final, quando as correções para
os defeitos encontrados forem realizadas, a equipe de gerência de configuração deverá gerar um release
do sistema para testes de usuário.

2. TESTES DE RELEASE

Uma equipe especializada em testes realiza testes em versões completas antes da disponibilização para
os usuários finais.

Testes de release é o processo de testar um release de um software por uma equipe de testes externa a
equipe de desenvolvimento. A grande diferença para o teste de sistema, é que nos testes de release exis-
te uma equipe especializada própria para execução de testes. O objetivo principal é atestar que o sistema
desenvolvido está pronto para o uso final.

Nesta fase, os testes a seguir são realizados:

9
 • Testes baseados em requisitos: um dos princípios básicos da engenharia de software é que os
requisitos precisam ser testáveis, isso significa que um requisito precisa ser escrito de forma que um
caso de testes possa ser projetado para ele. Então, para cada requisito é necessário escrever um caso
de testes para que possa ser verificável e seus critérios de aceitação possam ser alcançados.

• Testes de cenário: é uma abordagem que você precisa entender a regra de negócio do cliente,
e desenvolver cenários típicos de uso, para que a release seja testada.

• Testes de desempenho: uma vez que houve a integração do sistema como um todo, é possível
realizar testes que garantam a confiabilidade e o desempenho do sistema. Esses testes permitem
testar que o sistema irá suportar a carga de informações a qual foi projetado. Normalmente são reali-
zadas diversas baterias de testes aumentando gradualmente a carga de dados até que o desempenho
do sistema se torne insuportável.

3. TESTES DE USUÁRIO: potenciais usuários do sistema realizam uma bateria de testes antes de
o sistema ter a versão final implantada no ambiente de produção.

Testes de usuários ou de cliente é um estágio após a release aprovada no qual os um grupo de usuários
finais vão fornecer entradas para o sistema. Pode ser um processo formal no qual os usuários irão exe-
cutar testes de aceitação ou um processo informal, em que os usuários finais experimentam o sistema
desenvolvido para avaliar se as expectativas criadas foram atendidas durante o desenvolvimento.

Esses testes são importantes por serem realizados em ambientes do cliente, assim possuem efeito fun-
damental sobre a confiabilidade, desempenho, usabilidade e robustez de um sistema. Testes nesses
ambientes externos são necessários, pois é impossível para uma equipe de desenvolvimento replicar o
ambiente de produção de um sistema, assim comportamentos diferentes dos já testados podem ocorrer.

Existem três tipos de testes de usuário:

• Testes alfa: usuários trabalham com a equipe de desenvolvimento para testar o software no
ambiente de desenvolvimento.

• Testes beta: testes realizados pelos usuários para fazer experimentação do sistema desenvolvido.

• Testes de aceitação: testes formais realizados pelos usuários para atestar que o software foi
aceito e está pronto para ser utilizado.

10
 Palavras Finais

Nesta unidade introduzimos os conceitos de testes, a importância que os testes de software têm no
ciclo de vida de um software, os tipos e as abordagens de testes. Na próxima unidade, continuaremos a
detalhar mais sobre o processo de testes de um sistema.

Acesse o Ambiente Virtual

Lembre-se: é muito importante que você realize todas as atividades disponíveis no Ambiente Virtual de
Aprendizagem (AVA), pois possuem caráter avaliativo.

Espero você na nossa próxima unidade. Bons estudos!

Referências Bibliográficas

Sommerville, I; Engenharia de software 9 ed. 2011; 528p

Pfleeger, S. L.; Engenharia de software: teoria e prática 2004.
Pressman, R.; Engenharia de Software: uma abordagem profissional 7 ed. 2011.

11