SIN 221 - Engenharia de

Software I
Profa. Liziane Santos Soares
liziane.soares@ufv.br
TESTE DE SOFTWARE
Profa. Liziane Santos Soares
liziane.soares@ufv.br
Erro Humano
• Por melhores que sejam as técnicas de modelagem e
especificação de software…

• por mais disciplinada e experiente que seja a equipe de

desenvolvimento…

• sempre haverá um fator que faz com que o teste de software seja
necessário:

o erro humano.
Fundamentos
• Um erro (error) é uma diferença detectada entre o resultado
de uma computação e o resultado correto ou esperado.
• Um defeito (fault) é uma linha de código, bloco ou conjunto
de dados incorretos, que provocam um erro observado.
• Uma falha (failure) é um não funcionamento do software,
possivelmente provocada por um defeito, mas também com
outras causas possíveis.
• Um engano (mistake), ou erro humano, é a ação que
produz ou produziu um defeito no software.
Verificação, Validação e Teste
• Testes permitem:
• analisar o software para ver se ele está sendo construído de
acordo com o que foi especificado (conformidade com
requisitos).
• analisar o software construído para ver se ele atende às
verdadeiras necessidades dos interessados (aceitação)
• analisar o software para verificar se ele funciona corretamente
(bugs)
Depuração
• A depuração é a atividade que consiste em buscar a causa do erro, ou
seja, o defeito oculto que a está causando.

• O fato de se saber que o software não funciona não significa que

necessariamente se saiba qual ou quais são as linhas de código que
provocam esse erro (inspeção e revisão de código e debug)
Níveis de Teste de Funcionalidade

• Unidade

• Integração

• Sistema

• Aceitação

• Regressão

• Operação
Teste de Unidade
• Os testes de unidade são os mais básicos e usualmente consistem em
verificar se um componente individual do software (unidade) foi
implementado corretamente.

• Esse componente pode ser um método ou procedimento, uma classe

completa ou ainda um pacote de funções ou classes de tamanho pequeno
a moderado.

• Usualmente, essa unidade ainda estará isolada do sistema do qual fará

parte.
Exemplo (verificar se um método foi
corretamente implementado em uma
classe)
• Classe Livro

• Método setISBN(umisbn:string).

• A especificação do método estabelece que ele deve trocar o valor do

atributo ISBN do livro para o parâmetro passado, mas, antes disso,
deve verificar se o valor do ISBN passado não corresponde a um
ISBN já cadastrado (porque uma regra de negócio estabelece que dois
livros não podem ter o mesmo ISBN).
Testes que devem ser feitos

• Inserir um ISBN que ainda não consta na base e verificar se o

atributo do livro foi adequadamente modificado.

• Inserir um ISBN que já existe na base e verificar que a exceção

foi sinalizada, como esperado.
Ferramentas para teste
• Junit: um framework gratuitamente distribuído que permite inserir comandos
específicos de verificação no programa que acusarão os erros caso venham a ser
encontrados.
• Uma lista de frameworks de teste para mais de 70 linguagens de programação
pode ser encontrada em:
– https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
Estratégias de teste

• Testes de partição, nos quais se identificam grupos de entradas que têm

características comuns e devem ser processados ​da mesma maneira.

Você deve escolher os testes de dentro de cada um desses grupos.

• Testes baseados em diretrizes, em que você usa diretrizes de testes para escolher
casos de teste.

Essas diretrizes refletem a experiência anterior dos tipos de erros que os
programadores cometem frequentemente no desenvolvimento de componentes.
 Testes de partição
• Muitas vezes, os dados de entrada e resultados de saída, caem em diferentes
classes, em que todos os membros de uma classe estão relacionados.
• Cada uma dessas classes é uma partição de equivalência ou domínio, em que o
programa se comporta de uma forma equivalente para cada membro da classe.
• Casos de testes devem ser escolhidos a partir de cada partição.

EXEMPLO

Problema: número primo (divisível apenas por ele mesmo ou por 1)

Função implementada: retorna true se primo, e false caso contrário.

Entradas possíveis: todos os números primos ou não

Partições de equivalência:

- números primos : 1,3,5,7,11, …..

- números não primos: 2,4,6,9,…..
-0
- números negativos

===> Selecionar um representante de cada

partição para realizar os testes, aumentando
Assim a cobertura de testes
 Testes de partição
• Escolher representantes de grupos de valores e valores limites que estressem o
método a ser testado.
 Testes de partição
• Exemplo: rotina Busca (key: int; S: sequence) // procura o elemento Key em
uma sequencia S
• Diretrizes de teste
• Testar o software com seqüências que têm apenas um valor único, ou são
vazias.
• Usar seqüências de tamanhos diferentes em testes diferentes.
• Derivar testes de tal modo que o primeiro, o médio e o último elementos
da seqüência sejam acessados.
 Testes de partição
• Diretrizes de teste
• Escolher entradas que forcem o sistema a gerar todas as
mensagens de erro.
• Projetar entradas que causem o transbordamento dos buffers de
inputs.
• Repetir a mesma entrada ou uma série de entradas inúmeras
vezes.
• Forçar a geração de saídas inválidas.
• Forçar os resultados de cálculos serem muito grandes ou muito
pequenos
 Testes de partição
• Exemplo: rotina Busca (key: int; S: sequence) // procura o elemento Key em
uma sequencia S
• Diretrizes de teste
• Testar o software com seqüências que têm apenas um valor único, ou são
vazias.
• Usar seqüências de tamanhos diferentes em testes diferentes.
• Derivar testes de tal modo que o primeiro, o médio e o último elementos
da seqüência sejam acessados.
 Testes de integraçao
• Testam a integração de unidades já testadas

• Existem duas abordagens de integração:


Não incremental (“big-bang”):

todas as unidades são integradas de uma só vez

esforço de preparação menor

esforço para diagnóstico e correção de falhas é maior
• Incremental

as unidades são integradas gradualmente

esforço para diagnóstico e correção de falhas é menor
 Testes de integraçao
• Integrar os componentes incrementalmente simplifica a
localização de erros.
Teste de Sistema

• Visa verificar se a versão corrente do sistema permite

executar processos ou casos de uso completos do ponto
de vista do usuário que executa uma série de operações de
sistema em uma interface (não necessariamente gráfica) e
sendo capaz de obter os resultados esperados.
Exemplo (caso de uso a ser testado)
Base para roteiros de teste (útil em liberações de releases)
Teste de Aceitação

• O teste de aceitação é usualmente realizado pelo usuário

ou cliente, usando a interface final do sistema.

• Ele pode ser planejado e executado exatamente como o

teste de sistema, mas a diferença é que é realizado pelo
usuário final ou cliente e não pela equipe de
desenvolvimento.
Teste de regressão
• O teste de regressão é executado sempre que um sistema em
operação sofre manutenção.
• O problema é que a correção de um defeito no software, ou
modificação de alguma de suas funções pode ter gerado novos
defeitos.
• Neste caso, devem ser executados novamente todos os testes de
unidade das unidades alteradas, bem como os testes de
integração e sistema sobre as partes afetadas.
• O teste de regressão tem esse nome porque se ao se aplicarem
testes a uma nova versão na qual versões anteriores passaram, e
essa nova versão não passar, então se considera que o sistema
regrediu.
Teste de release
• Teste de release é o processo de testes de uma versão
particular de um sistema que se destina para uso fora da
equipe de desenvolvimento.

• Geralmente, os testes de release são um processo de

teste caixa-preta, em que os testes são derivados
somente a partir da especificação do sistema.

• Testes de release são uma forma de teste do sistema: com

ênfase no que a release apresenta como objetivo
Testes Suplementares
• Interface com Usuário:

verificar se a interface permite realizar as atividades previstas nos casos de uso de
forma eficaz e eficiente

verificar a conformidade das interfaces com normas ergonômicas que se apliquem.

• Performance :

Importante para operações que serão realizadas com muita frequência ou de forma
iterativa.

O teste consiste em executar a operação e mensurar seu tempo, avaliando se está
dentro dos padrões definidos.

• Segurança
• Recuperação de Falha
• Instalação
Testes Suplementares
• Interface com Usuário:

verificar se a interface permite realizar as atividades previstas nos casos de uso de
forma eficaz e eficiente

verificar a conformidade das interfaces com normas ergonômicas que se apliquem.

• Performance :

Importante para operações que serão realizadas com muita frequência ou de forma
iterativa.

O teste consiste em executar a operação e mensurar seu tempo, avaliando se está
dentro dos padrões definidos.
Testes Suplementares
• Segurança

Integridade:
– é uma forma de garantir ao receptor que a informação que ele recebeu é
correta e completa.

Autenticação:
– é a garantia de que um usuário realmente é quem ele diz ser e que os
documentos, programas e sites realmente sejam aqueles que se espera que
sejam.

Autorização:
– é o processo de verificar se alguma pessoa ou sistema pode ou não
acessar determinada informação ou sistema.
• Confidencialidade:
– segurança de que quem não tem direito à informação não possa obtê-la.
Teste de recuperação de falha
• Quando um sistema tem requisitos suplementares referentes a
tolerância ou recuperação de falhas, estes devem ser testados
separadamente.
• Basicamente, busca-se verificar se o sistema de fato atende aos
requisitos especificados relacionados a esta questão.
• Normalmente trata-se de situações referentes a:
– Queda de energia no cliente ou no servidor.
– Discos corrompidos.
– Problemas de comunicação.
– Quaisquer outras condições que possam potencialmente provocar a
terminação anormal do programa ou a interrupção temporária de
seu funcionamento.
Técnicas de Teste
• Testes estruturais ou caixa-branca:

– são testes que são executados com conhecimento do código

implementado, ou seja, eles testam a estrutura do programa em
si.

• Testes funcionais ou caixa-preta:

– são testes executados sobre as entradas e saídas do

programa sem que se tenha necessariamente conhecimento do
seu código fonte.
Teste caixa-preta
• Não verificam como ocorre o processamento, mas apenas o
resultado produzido
• O responsável pelo teste não possui acesso algum ao código
fonte ou estrutura interna do que foi desenvolvido.
• São efetuadas operações sobre as diversas funcionalidades para
verificar se o resultado gerado está de acordo com o esperado.
Teste caixa-branca
• Objetivo: determinar defeitos na estrutura interna do software.
• Neste método, o responsável pelo teste tem acesso ao código fonte da
aplicação e pode construir códigos para efetuar a ligação de bibliotecas e
componentes.
• Os casos de teste são elaborados para cobrir todas as possibilidades do
programa, exercitando todos os caminhos de execução.
• Dessa maneira, todas as variações originadas por estruturas de
condições são testadas.
Resumo sobre testes
• Testes de software podem ser classificados sob várias perspectivas

De acordo com o Teste de Validação

objetivo do teste Teste de Defeitos

De acordo com técnica do teste Teste Caixa-Branca (TCB)

Teste Caixa-Preta (TCP)

Teste de Componente
De acordo com a parte
Teste Unitário Teste de Integração
do sistema que é testada
Teste de Sistema Teste de Release
Teste de Regressão

Testes de usuário* Teste de aceitação (consiste em grande parte em

teste de requisito)
Bibliografia Básica
- Sommerville, I. Engenharia de Software. 10a ed. São Paulo: Pearson,
2019. (Disponível na biblioteca virtual da Pearson.)
- PRESSMAN, R. Engenharia de Software. Rio de Janeiro, RJ, McGraw-Hill
- Paula Filho, W. P. Engenharia de software: fundamentos, métodos e
padrões. Rio de Janeiro, RJ, LTC, 2009.
- Raul Sidnei Wazlawick. Engenharia de Software: Conceitos e Práticas,
Elsevier, 2013
- Valente, M.T. Engenharia de Software Moderna: Princípios e Práticas para
Desenvolvimento de Software com Produtividade 2020 (disponível
em:https://engsoftmoderna.info/)
Até a próxima!