Teste de Software
Parte 4
Ricardo de Almeida Falbo
Tópicos Especiais – Qualidade de Software
2008/2
Departamento de Informática
Universidade Federal do Espírito Santo
Agenda







Teste
Teste
Teste
Teste
Teste
Teste
Teste
de Integração
de Classe
de Interação
de Componente
de Caso de Uso
Baseado em Máquina de Estados
de Sistema
Tópicos Especiais - Qualidade de Software 2008/2
2
Teste de Integração




Objetivo: verificar se as partes, quando
colocadas para trabalhar juntas, não conduzem a
erros.
Todas as técnicas de teste se aplicam, com
destaque para o teste funcional.
Questão importante: Como agrupar os módulos
para se testar a integração entre eles?
No paradigma procedimental (Pressman, 2006):




Integração não incremental (big-bang)
Integração Ascendente (bottom-up)
Integração Descendente (top-down)
E no paradigma OO?
Tópicos Especiais - Qualidade de Software 2008/2
3
Teste de Integração OO

Níveis de Teste de Integração:


Teste de Classe: testa a interação entre métodos de
uma classe, usando o conjunto de atributos de uma
instância.
Teste de Interação ou Interclasse: testa a colaboração /
interação entre classes. Inicia-se sem prover ainda uma
funcionalidade completa, avançando para a interação
no contexto de um componente ou caso de uso.
Tópicos Especiais - Qualidade de Software 2008/2
4
Teste de Integração OO

Teste de Componente: Quando um componente é
implementado usado a tecnologia de objetos, ele pode
ser visto como um conjunto de classes que provê uma
porção significativa de funcionalidade, acessível por
meio de um conjunto de interfaces especificando os
comportamentos disponíveis.


Perspectiva do desenvolvedor de componente: testa a
colaboração entre classes que compõem um componente,
bem como as suas interfaces contratuais públicas.
Técnicas funcionais e estruturais podem ser aplicadas,
pois o código-fonte está disponível.
Perspectiva do cliente de componente: quando um
componente desenvolvido independentemente é integrado
a uma aplicação, o código pode não estar disponível,
dificultando a atividade de teste. Neste caso, apenas
critérios funcionais são aplicáveis.
Tópicos Especiais - Qualidade de Software 2008/2
5
Teste de Integração OO


Teste de Caso de Uso: testa a colaboração entre classes
no contexto de um caso de uso ou fluxo de eventos de
um caso de uso.
Teste de Subsistema: testa partes de um sistema,
contendo vários componentes e realizando vários casos
de uso.
Tópicos Especiais - Qualidade de Software 2008/2
6
Teste de Classe




Visto como um teste de integração, o teste de
classe visa testar a integração de métodos e
atributos de uma classes.
Aspecto importante a verificar: restrições na
ordem de invocação de suas operações (muitas
vezes implícitas) estão sendo satisfeitas?
Seqüência mínima de teste: aquele que exercita
o histórico de vida comportamental mínimo de
um objeto da classe.
Além da seqüência mínima, há muitas
combinações possíveis de invocação de
operações (Pressman, 2006).
Tópicos Especiais - Qualidade de Software 2008/2
7
Teste de Classe



Seja a seguinte classe Conta.
Qual a seqüência de testes mínima a ser
feita?
Que outros casos de teste são possíveis?
Tópicos Especiais - Qualidade de Software 2008/2
8
Teste de Classe

Seqüência Mínima


abrir – estabelecerLimite – depositar – retirar –
encerrar
Outros casos de teste possíveis: Infinitos...

Seqüências Válidas


abrir – estabelecerLimite – depositar – [obterLimite |
estabelecerLimite | depositar | retirar | obterSaldo |
obterExtrato]n – retirar – encerrar
Seqüências Inválidas






estabelecerLimite – depositar – retirar – encerrar
abrir – depositar – retirar – encerrar
abrir – estabelecerLimite – retirar – encerrar
abrir – estabelecerLimite – depositar – encerrar
abrir – estabelecerLimite – depositar – retirar – encerrar depositar
etc
Tópicos Especiais - Qualidade de Software 2008/2
9
Teste de Classe


Necessidade de reduzir o número de casos de
teste
Teste Aleatório ou Randômico


Casos de teste para diferentes seqüências
(normalmente válidas) de operações são gerados
aleatoriamente.
Teste de Partição no Nível de Classe



Análogo ao critério Particionamento de Equivalência.
Casos de teste são projetados para exercitar cada
categoria (válida ou inválida).
Alguns critérios:



Partição Baseada em Estado
Partição Baseada em Atributo
Partição Baseada em Categoria
Tópicos Especiais - Qualidade de Software 2008/2
10
Partição Baseada em Estado


O termo “estado” neste contexto designa o
estado interno de um objeto dado pelo seu
conjunto de atributos e não apenas os estados
definidos por uma máquina de estados da
classe.
Categoriza as operações em duas grandes
classes:


operações que podem mudar o estado de um objeto da
classe, ou seja, que alteram o valor de atributos da
classe e
operações que não podem mudar o estado de um
objeto da classe.
Tópicos Especiais - Qualidade de Software 2008/2
11
Partição Baseada em Estado



Casos de teste são projetados de modo a
exercitarem separadamente as operações que
mudam o estado e aquelas que não mudam o
estado (Pressman, 2006).
A seqüência mínima de teste é usada como
base.
Introduzem-se operações da partição nessa
seqüência, respeitando a ordem da seqüência
mínima, para gerar casos de teste com
seqüências válidas.
Tópicos Especiais - Qualidade de Software 2008/2
12
Partição Baseada em Estado



Seja a seguinte classe Conta.
Que operações mudam o estado?
Que casos de teste considerar?
Tópicos Especiais - Qualidade de Software 2008/2
13
Partição Baseada em Estado

Operações que mudam o estado:


Operações que não mudam o estado:


obterLimite, obterSaldo, obterExtrato
Seqüência Mínima


estabelecerLimite, depositar, retirar
abrir – estabelecerLimite – depositar – retirar –
encerrar
Partições Válidas:


abrir – estabelecerLimite – depositar –
[estabelecerLimite | depositar | retirar ]n – retirar –
encerrar
abrir – estabelecerLimite – depositar – [obterLimite |
obterSaldo | obterExtrato]n – retirar – encerrar
Tópicos Especiais - Qualidade de Software 2008/2
14
Partição Baseada em Atributo

Categoriza as operações com base nos atributos
que elas usam (Pressman, 2006):



Operações que usam o atributo sem modificá-lo
Operações que modificam o valor do atributo
Operações que não usam o atributo
Tópicos Especiais - Qualidade de Software 2008/2
15
Partição Baseada em Atributo


Seja a seguinte classe Conta.
Que operações usam / modificam / não
usam cada um dos atributos?
Tópicos Especiais - Qualidade de Software 2008/2
16
Partição Baseada em Atributo

Atributo limiteCredito




Atributo saldo




Usam: obterLimite, obterSaldo, obterExtrato, retirar
Modificam: estabelecerLimite
Não usam ou modificam: abrir, depositar, encerrar
Usam: obterSaldo, obterExtrato, encerrar
Modificam: abrir, depositar, retirar
Não usam ou modificam: estabelecerLimite, obterLimite
Casos de Teste: pelo menos um caso de teste
dentro de cada uma das partições.
Tópicos Especiais - Qualidade de Software 2008/2
17
Partição Baseada em Categoria


Categoriza as operações com base na função
genérica que cada uma realiza.
Por exemplo, uma categorização que estende a
partição baseada em estado:




Operações
Operações
classe)
Operações
classe)
Operações
de inicialização
de consulta (que não alteram o estado da
com atribuição (que alteram o estado da
de término
Tópicos Especiais - Qualidade de Software 2008/2
18
Partição Baseada em Categoria

Operações de inicialização:


Operações de consulta:




obterLimite
obterSaldo
obterExtrato
Operações de atribuição:




abrir
estabelecerLimite
depositar
retirar
Operações de término:

encerrar
Tópicos Especiais - Qualidade de Software 2008/2
19
Teste de Classe


Para cada classe, é importante definir se a
mesma deve ser testada de forma separada ou
no contexto de uma parte maior do sistema
(p.ex., componente, caso de uso etc).
Essa definição deve baseada nos seguintes
fatores (McGregor e Sykes, 2001):



Papel da classe no sistema (criticidade) e risco
associado à mesma
Complexidade da classe, medida em termos do número
de estados, operações e associações com outras classes
Esforço associado com o desenvolvimento do driver de
teste da classe.
Tópicos Especiais - Qualidade de Software 2008/2
20
Planejamento de Teste de Classe



Quem deve testar?
Geralmente, classes são testadas pelos próprios
desenvolvedores, sendo que seu plano de teste
pode ser feito por outra pessoa.
Vantagens:




Minimiza o número de pessoas que devem conhecer a
especificação da classe.
Facilita a implementação dos casos de teste, pois o
testador conhece a implementação da classe.
Driver de teste pode ser usado para depuração.
Desvantagens:

Problemas no entendimento da especificação são
propagados para o teste (McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
21
Planejamento de Teste de Classe




O que testar?
Basicamente, deseja-se testar se uma
implementação reflete exatamente sua
especificação e nada além disso.
O esforço para testar se a implementação
contém apenas o que foi especificado pode ser
alto e, portanto, deve ser avaliado em relação ao
risco associado à classe.
Se após a execução de vários de casos de teste,
ainda há código não coberto, é possível que
exista comportamento indesejado na classe
(McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
22
Planejamento de Teste de Classe




Quando testar?
Assim que uma classe está pronta para ser
codificada, seu plano de teste pode ser
elaborado.
O teste de uma classe deve ser executado antes
que a mesma seja usada em outras partes do
software.
Caso a implementação mude, os testes devem
ser executados novamente podendo ser
alterados ou não (quando não alterados, está-se
aplicando teste de regressão) (McGregor e
Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
23
Planejamento de Teste de Classe



Como testar?
Classes são testadas através de drivers de teste,
construindo o ambiente necessário à execução
dos casos de teste (McGregor e Sykes, 2001).
Uso de ferramentas pode ajudar, aumentando a
produtividade do teste de classe.
Tópicos Especiais - Qualidade de Software 2008/2
24
Planejamento de Teste de Classe



Quanto testar?
Avaliar criticidade e riscos associados à classe
(relação custo-benefício) (McGregor e Sykes,
2001).
Aplicar técnicas de teste de classe para
minimizar o número de casos de teste, mas com
uma boa cobertura.
Tópicos Especiais - Qualidade de Software 2008/2
25
Plano de Teste de Classe









Nome da Classe:
Desenvolvedor:
Testador:
Criticidade:
Seqüência Mínima:
Considerações sobre o Projeto da Suíte de Teste
Casos de Teste (organizados por tipo)
Resultados
Considerações sobre a Cobertura da Suíte de
Teste
Tópicos Especiais - Qualidade de Software 2008/2
26
Teste de Interação ou Interclasse



Uma interação é uma requisição feita por um
objeto (o transmissor) a outro (o receptor) para
executar uma das operações do receptor.
Um programa OO consiste de uma coleção de
objetos que colaboram para resolver um
problema.
Assim, a correta colaboração (ou interação)
entre objetos em um programa OO é crítica para
a correção do programa (McGregor e Sykes,
2001).
Tópicos Especiais - Qualidade de Software 2008/2
27
Formas Típicas de Interação entre Classes





Mensagens passadas a outros objetos.
Uma operação pública que recebe como
parâmetro um ou mais objetos.
Uma operação pública que retorna um objeto.
Objeto que mantém uma referência a outro
como parte de seus atributos (atributo
implementando uma associação).
Um método de uma classe que cria uma
instância de outra classe como parte de sua
implementação (muitas vezes, um objeto
temporário).
Tópicos Especiais - Qualidade de Software 2008/2
28
Teste de Interação

Como testar?




Usando classes de teste
Usando o próprio programa de aplicação (p.ex., caso de
uso + estrutura de acesso ao caso de uso)
Teste funcional é o mais usado, mas observar o
código pode ser importante para definir o que
testar (para identificar quais formas de interação
estão presentes e entre quais classes).
Questão: Como agrupar classes para testar sua
integração?
Tópicos Especiais - Qualidade de Software 2008/2
29
Estratégia de Integração Baseada no Uso



Adaptação para o paradigma OO da estratégia
ascendente de integração.
Começa testando as classes servidoras ou
primitivas, i.e., as classes que não usam outras
classes.
Depois de testar as classes primitivas, testam-se
as classes dependentes (ou não primitivas) que
dependem apenas das classes já testadas e
assim sucessivamente.
Tópicos Especiais - Qualidade de Software 2008/2
30
Teste Baseado no Caminho de Execução



Integra o conjunto de classes necessárias para
responder a uma entrada ou um evento do
sistema.
Cada caminho de execução é testado e integrado
individualmente.
Teste de Componente e Teste de Caso de Uso se
enquadram nesta estratégia.
Tópicos Especiais - Qualidade de Software 2008/2
31
Teste de Interação



Testes de interação baseados apenas nas
especificações de operações públicas são
consideravelmente mais diretos que os baseados
nas implementações das mesmas.
Quando a abordagem baseada no uso é aplicada
integralmente, são necessários apenas testes
baseados nas especificações de operações
públicas.
Quando algumas das classes não são testadas
individualmente, contudo, tais testes podem não
ser suficientes (McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
32
Abordagem de Projeto e Teste

A abordagem de projeto (design) adotada tem
grande influência no projeto de casos de teste.


Ex.: Criação de objetos: teste na interface, aplicação ou
domínio?
É possível classificar as abordagens de projeto
em duas grandes categorias:


Abordagem defensiva: assume que pouca ou nenhuma
checagem de valores de parâmetros vai ocorrer antes
das mensagens serem enviadas para objetos da classe.
Abordagem de projeto por contrato: assume que as
pré-condições são checadas antes que a mensagem
seja enviada e que a mensagem não é enviada se os
parâmetros estão fora dos limites aceitáveis (McGregor
e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
33
Abordagem Defensiva de Projeto




Poucas pré-condições estabelecidas.
Necessidade de muitas checagens internas de
violação de restrições sobre atributos.
Muitos resultados possíveis (sobretudo de
exceção).
Necessidade de um maior número de casos de
teste nas classes que recebem mensagens, de
modo a checar valores de entrada que produzem
exceções e, por conseguinte, maior esforço no
teste de classe (McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
34
Abordagem de Projeto por Contrato




Muitas pré-condições estabelecidas.
Pouca ou nenhuma checagem interna de
violação de restrições sobre atributos.
Poucos resultados possíveis (especialmente de
exceção).
Necessidade de um maior número de casos de
teste nas classes que enviam mensagens, de
modo a checar valores de entrada que produzem
exceções e, por conseguinte, maior esforço no
teste de interação (McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
35
Teste de Componente: Perspectiva de
Desenvolvedor de Componentes


Um componente pode ser visto como um
agregado de objetos e, portanto, o teste de
componentes é muito similar ao teste de
interações entre conjuntos de objetos.
Um componente é tipicamente maior do que
uma classe e, por conseguinte, é mais difícil
obter boa cobertura de código usando um
critério funcional baseado na especificação do
componente (McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
36
Teste de Caso de Uso




Testa a interação no contexto da realização de
um caso de uso.
O que testar? Testar as partes mais usadas e
mais críticas com um alcance mais amplo de
entradas do que as partes menos usadas e
menos críticas.
Perfil de uso: classificação dos casos de uso
baseada em uma combinação de freqüência e
criticidade.
Riscos associados ao caso de uso devem ser
levados em conta e estão fortemente
relacionados à criticidade do caso de uso
(McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
37
Exemplo: Ferramenta GeRis
Teste de Caso de Uso – Perfil de Uso
Projeto:
Documento Base:
1
Documento de Especificação de Requisitos – Versão 1.1
Tipo
Freq.
Criti.
Importância
Criar Nova Versão de Plano de Riscos
Curso Normal
Baixa
Alta
Média
Criar Nova Versão de Plano de Riscos
Curso Alternativo
Média
Alta
Alta
Criar Nova Versão de Plano de Riscos
Curso de Exceção
Baixa
Baixa
Baixa
Alterar Versão de Plano de Riscos
Curso Normal
Alta
Alta
Alta
Consultar Versão de Plano de Riscos
Curso Normal
Média
Média
Média
Excluir Versão de Plano de Riscos
Curso Normal
Baixa
Baixa
Baixa
Curso Normal
Média
Alta
Alta
Curso Normal
Média
Alta
Alta
Efetuar Avaliação de Risco: Ação de
mitigação aplicada
Curso Alternativo
Baixa
Baixa
Baixa
Efetuar Avaliação de Risco: Risco ocorreu
Curso Alternativo
Baixa
Média
Média
Efetuar Avaliação de Risco
Curso de Exceção
Baixa
Média
Média
Excluir Avaliação de Risco
Curso Normal
Baixa
Média
Média
Excluir Avaliação de Risco
Curso de Exceção
Baixa
Média
Média
Curso Normal
Média
Alta
Alta
Caso de Uso
Fluxo de Eventos
Controlar Versão de Plano de Riscos
2
Identicar Riscos
3
Avaliar Risco
4
Geris
Definir Riscos Gerenciados
Efetuar Avaliação de Risco
Tópicos Especiais - Qualidade de Software 2008/2
38
Exemplo: Ferramenta GeRis
Teste de Caso de Uso – Perfil de Uso
Projeto:
Documento Base:
Caso de Uso
Geris
Documento de Especificação de Requisitos – Versão 1.1
Fluxo de Eventos
Tipo
Freq.
Criti.
Importância
5
Planejar Ações
Curso Normal
Média
Alta
Alta
6
Finalizar Versão de Plano de Riscos
Curso Normal
Média
Alta
Alta
7
Cadastrar Conseqüência
Criar Nova Conseqüência
Curso Normal
Baixa
Baixa
Baixa
Criar Nova Conseqüência
Curso de Exceção
Baixa
Baixa
Baixa
Alterar Conseqüência
Curso Normal
Baixa
Baixa
Baixa
Alterar Conseqüência
Curso de Exceção
Baixa
Baixa
Baixa
Consultar Conseqüência
Curso Normal
Baixa
Baixa
Baixa
Excluir Conseqüência
Curso Normal
Baixa
Baixa
Baixa
Tópicos Especiais - Qualidade de Software 2008/2
39
Teste de Caso de Uso




Um caso de uso contém um conjunto de fluxos
de eventos, incluindo cursos normais,
alternativos e de exceção.
Cada fluxo de eventos inclui a ação tomada por
um ator e a resposta produzida pelo sistema.
Esses dois elementos correspondem às partes
básicas de um caso de teste de caso de uso.
Para a construção de um caso de teste, valores
específicos de entrada são definidos, assim como
os correspondentes resultados esperados.
Selecionando diferentes valores para um fluxo
de eventos, dá-se origem a diferentes casos de
teste (McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
40
Teste de Caso de Uso


Partições de Equivalência podem ser criadas,
levando-se em consideração fluxos de eventos
normais, alternativos e de exceção.
Para cada caso de uso / fluxo de exceção:




Identificar os valores que devem ser informados pelo
ator.
Identificar partições de equivalência para cada entrada.
Construir tabelas de combinações de valores das várias
partições de equivalência.
Construir casos de teste exercitando essas combinações
(McGregor e Sykes, 2001).
Tópicos Especiais - Qualidade de Software 2008/2
41
Exemplo: Ferramenta GeRis
Teste de Caso de Uso
Projeto:
Documento Base:
Versão:
1
Geris
Documento de Especificação de Requisitos
1.1
Caso de Uso
Fluxo de Eventos
Entradas
Classe de
Equivalência
Válida
Controlar Versão de
Plano de Riscos
Criar Nova Versão de Plano de
Riscos (curso normal)
nome da versão
cadeia de
caracteres, exceto
apenas espaços
Criar Nova Versão de Plano de
Riscos (curso alternativo)
versão base
Classe de
Equivalência
Inválida
Saida Esperada
nova versão criada
cadeia vazia
Erro: nome inválido
cadeia contendo
apenas espaços
Erro: nome inválido
nome já existente
Erro: nome já
existente
versão base
selecionada
Tópicos Especiais - Qualidade de Software 2008/2
nova versão criada
contendo os dados
da versão base
42
Exemplo: Ferramenta GeRis
Caso de
Teste
Entradas
Classe de
Equivalência
Exercitada
Critério Utilizado
Saida Esperada
1.1.a
nome da versão =
"Versão 1"
cadeia de caracteres,
exceto apenas
espaços
Teste Funcional Sistemático:
Valor típico esperado
nova versão criada
1.1.b
nome da versão =
"Versão 1.0"
cadeia de caracteres,
exceto apenas
espaços
Teste Funcional Sistemático:
Valor típico esperado, 2o
elemento
nova versão criada
1.1.c
nome da versão =
<<cadeia vazia>>
cadeia vazia
Teste Funcional Sistemático:
Valor ilegal
Erro: nome inválido
1.1.d
nome da versão = " "
cadeia contendo
apenas espaços
Teste Funcional Sistemático:
Valor ilegal
Erro: nome inválido
1.1.e
nome da versão = 1.0
cadeia de caracteres,
exceto apenas
espaços
Teste Funcional Sistemático:
Entrada válida, mas que
pode ser interpretada como
tipo ilegal
nova versão criada
1.1.f
nome da versão = 1.0
nome já existente
Teste Funcional Sistemático:
Valor ilegal
Erro: nome já
existente
1.1.g
nome da versão = 1.1
versão base
selecionada
Teste Funcional Sistemático:
Valor típico esperado
nova versão criada
contendo os dados
da versão base
nome da versão = 1.2
nome da versão =
1.2
versão base = 1.1
versão base = 1.1
Teste Funcional Sistemático:
Valor típico esperado, 2o
elemento
nova versão criada
contendo os dados
da versão base
versão base = 1.0
1.1.h
Tópicos Especiais - Qualidade de Software 2008/2
Resultado da
Execução do
Teste
43
Exemplo: Ferramenta GeRis
Teste de Caso de Uso
Projeto:
Documento Base:
Versão:
3
Geris
Documento de Especificação de Requisitos
1.1
Caso de Uso
Fluxo de Eventos
Entradas
Classe de
Equivalênc
ia Válida
Avaliar Risco
Efetuar Avaliação de
Risco (curso
normal)
risco a ser
avaliado
risco selecionado
probabilidade (p)
0 <= p <= 100%
impacto (i)
0 <= i <= 10
Classe de
Equivalênci
a Inválida
Saida Esperada
avaliação de risco
criada para o
risco
selecionado
risco a ser
avaliado
nenhum risco
selecionado
probabilidade (p)
p< 0 ou p > 100%
Erro: probabilidade
deve ser um
valor entre 0
e 100%
impacto (i)
i < 0 ou i > 10
Erro: impacto deve
ser um valor
entre 0 e 10
Tópicos Especiais - Qualidade de Software 2008/2
44
Exemplo: Ferramenta GeRis
CasoTeste
Entradas
Classe de Equivalência
Exercitada
Critério Utilizado
Saida Esperada
3.1.a
risco a ser avaliado =
qualquer
risco selecionado
Teste Funcional Sistemático: Valor
típico esperado
probabilidade (p) = 60%
0 <= p <= 100%
avaliação de risco
criada para o
risco
selecionado
impacto (i) = 5
0 <= i <= 10
risco a ser avaliado =
qualquer
risco selecionado
Teste Funcional Sistemático: Valor
típico esperado, 2o elemento
probabilidade (p) = 80%
0 <= p <= 100%
avaliação de risco
criada para o
risco
selecionado
impacto (i) = 3
0 <= i <= 10
3.1.c
risco a ser avaliado =
nenhum
nenhum risco selecionado
Análise de Valor Limite: Condição
de entrada especificando uma
quantidade de valores:
Nenhum valor de entrada
3.1.d
risco a ser avaliado =
quaisquer dois riscos
mais de um risco
selecionado
Análise de Valor Limite: Condição
de entrada especificando uma
quantidade de valores: Qte
máxima + 1
3.1.b
Tópicos Especiais - Qualidade de Software 2008/2
Resultado
45
Exemplo: Ferramenta GeRis
CasoTeste
Entradas
Classe de Equivalência
Exercitada
Critério Utilizado
Saida Esperada
3.1.e
probabilidade (p) = 0
(demais dados válidos)
0 <= p <= 100%
Análise de Valor Limite: Condição
de entrada especificando um
intervalo de valores: Limite inferior
avaliação de risco
criada para o risco
selecionado
3.1.f
probabilidade (p) = 100%
(demais dados válidos)
0 <= p <= 100%
Análise de Valor Limite: Condição
de entrada especificando um
intervalo de valores: Limite superior
avaliação de risco
criada para o risco
selecionado
3.1.g
probabilidade (p) = -0.1%
(demais dados válidos)
p< 0 ou p > 100%
Análise de Valor Limite: Condição
de entrada especificando um
intervalo de valores: Valor menor do
que o limite inferior
Erro: probabilidade
deve ser um valor
entre 0 e 100%
3.1.h
probabilidade (p) = 100,1%
(demais dados válidos)
p< 0 ou p > 100%
Análise de Valor Limite: Condição
de entrada especificando um
intervalo de valores: Valor maior do
que o limite superior
Erro: probabilidade
deve ser um valor
entre 0 e 100%
Tópicos Especiais - Qualidade de Software 2008/2
Resultado
46
Teste Baseado em Máquina de Estados


Uma máquina de estados especifica as
seqüências de estados pelos quais um objeto
passa durante seu tempo de vida em resposta a
eventos, juntamente com as respostas a esses
eventos (Booch et al., 2006).
Pela definição acima, testes baseados em uma
máquina de estados aplicam-se a uma classe e,
portanto, podem ser vistos como um tipo de
teste de classe. Isso é verdade sobretudo
quando um diagrama de estados é elaborado na
fase de projeto, com as transições entre estados
correspondendo a métodos da classe.
Tópicos Especiais - Qualidade de Software 2008/2
47
Teste Baseado em Máquina de Estados


Quando um diagrama de estados da fase de
análise é usado como base para o teste, muitas
vezes, as transições correspondem a fluxos de
eventos de casos de uso. Assim, é necessário
que cada um desses fluxos de eventos tenha
sido testado e integrado.
Nesta visão, um teste baseado em máquina de
estados visa testar a integração de vários casos
de uso, tendo como foco uma classe.
Tópicos Especiais - Qualidade de Software 2008/2
48
Teste Baseado em Máquina de Estados




Usar o diagrama de estados para determinar a
seqüência de eventos a serem exercitados.
Os casos de teste devem cobrir todos os
estados.
Cada uma das transições deve ser exercitada
pelo menos uma vez.
Eventos inválidos devem ser testados para ver
se o sistema refuta a sua ocorrência.
Tópicos Especiais - Qualidade de Software 2008/2
49
Teste de Subsistema


Após testar casos de uso isoladamente ou no
contexto de uma máquina de estados, pode ser
útil, ainda, testar se os vários casos de uso se
comportam adequadamente no contexto de um
subsistema.
Testes de ciclo de vida do domínio: realizar os
processos de negócio (casos de uso) como eles
tipicamente acontecem (McGregor e Sykes,
2001).
Tópicos Especiais - Qualidade de Software 2008/2
50
Teste de Sistema



Teste do sistema completo ou de um incremento
a ser implantado provendo algum grau de
funcionalidades para usuários finais.
O foco dos testes de sistema não é exatamente
procurar defeitos que conduzam a falhas, mas
procurar defeitos que representem variações
entre o que o sistema realmente faz e os
requisitos especificados para ele.
Os tipos de teste nesta fase estão direta ou
indiretamente relacionados a requisitos, tanto
funcionais quanto não funcionais.
Tópicos Especiais - Qualidade de Software 2008/2
51
Teste de Sistema


Os testes de sistema que enfocam requisitos
funcionais são análogos aos testes de
subsistema. Ou seja, visam testar se os vários
casos de uso se comportam adequadamente no
contexto, agora, do sistema (ou do incremento a
ser implantado).
Mas agora é muito importante também que
usuários testem efetivamente o sistema, pois
pode haver problemas na especificação dos
requisitos. Testes dessa natureza são ditos
testes de aceitação.
Tópicos Especiais - Qualidade de Software 2008/2
52
Teste de Sistema



Para testar requisitos funcionais, testes de ciclo
de vida do domínio podem ser aplicados.
A idéia de perfil de uso (teste de caso de uso)
também pode ser aplicada.
Para testar requisitos não funcionais (RNF), é
necessário:



Definir RNFs como atributos mensuráveis.
Projetar casos de teste que detectem a presença ou
ausência desses atributos.
Executar os casos de teste e analisar os resultados.
Tópicos Especiais - Qualidade de Software 2008/2
53
Teste de Sistema

Há diversos tipos de testes de sistemas, focando
alguma particularidade ou tipo de RNF, tais
como:









Teste de Implantação (instalação/remoção do sistema)
Teste de Inicialização
Teste de Configuração de Hardware e Software
Teste de Ambiente (rodar vários programas ao mesmo
tempo, simulando situações típicas do usuário)
Teste de Exceção e Recuperação
Teste de Desempenho
Teste de Segurança
Teste de Estresse
etc
Tópicos Especiais - Qualidade de Software 2008/2
54
Referências




Booch, G., Rumbaugh, J., Jacobson, I., UML Guia
do Usuário, 2a edição, Editora Campus, 2006.
Delamaro, M.E., Maldonado, J.C., Jino, M.,
Introdução ao Teste de Software, Série Campus
– SBC, Editora Campus, 2007.
McGregor, J.D., Sykes, D.A., A Practical Guide to
Testing Object-Oriented Software, AddisonWesley, 2001.
Pressman, R.S., Engenharia de Software. 6a
edição, McGrawHill, 2006.
Tópicos Especiais - Qualidade de Software 2008/2
55