|
  

 

Ricardo de Almeida Falbo

Tópicos Especiais ± Qualidade de Software

2008/2
Departamento de Informática
Universidade Federal do Espírito Santo
  
_ Teste de Integração
_ Teste de Classe
_ Teste de Interação
_ Teste de Componente
_ Teste de Caso de Uso
_ Teste Baseado em Máquina de Estados
_ Teste de Sistema

| 

  
     

 
 |
   
 
_ ÿbjetivo: 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 ÿÿ?
| 

  
     
 
 |
   
 !!
_ 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.

| 

  
     

 
|
   
 !!
_ 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.

| 

  
     

 "
|
   
 !!
_ 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.

| 

  
     

 #
 |
  %


_ Ëisto 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).

| 

  
     

 $
 |
  %


_ 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?
| 

  
     
 
 |
  %


_ Seqüência Mínima
_ abrir ± estabelecerLimite ± depositar ± retirar ±
encerrar
_ ÿutros casos de teste possíveis: Infinitos...
_ Seqüências Ëá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
| 

  
     
 &
 |
  %


_ 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

| 

  
     

 '
 
 (
  )
 
_ ÿ 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.

| 

  
     

 ''
 
 (
  )
 
_ 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.

| 

  
     

 '
 
 (
  )
 
_ Seja a seguinte classe Conta.

_ Que operações mudam o estado?

_ Que casos de teste considerar?

| 

  
     

 '
 
 (
  )
 
_ ÿperações que mudam o estado:
_ estabelecerLimite, depositar, retirar
_ ÿperações que não mudam o estado:
_ obterLimite, obterSaldo, obterExtrato
_ Seqüência Mínima
_ abrir ± estabelecerLimite ± depositar ± retirar ±
encerrar
_ Partições Ëálidas:
_ abrir ± estabelecerLimite ± depositar ±
[estabelecerLimite | depositar | retirar ]n ± retirar ±
encerrar
_ abrir ± estabelecerLimite ± depositar ± [obterLimite |
obterSaldo | obterExtrato]n ± retirar ± encerrar

| 

  
     

 '
 
 (
  )
*
_ Categoriza as operações com base nos atributos
que elas usam (Pressman, 2006):
_ ÿperações que usam o atributo sem modificá-lo
_ ÿperações que modificam o valor do atributo
_ ÿperações que não usam o atributo

| 

  
     

 '"
 
 (
  )
*
_ Seja a seguinte classe Conta.

_ Que operações usam / modificam / não

usam cada um dos atributos?

| 

  
     

 '#
 
 (
  )
*
_ Atributo limiteCredito
_ Usam: obterLimite, obterSaldo, obterExtrato, retirar
_ Modificam: estabelecerLimite
_ Não usam ou modificam: abrir, depositar, encerrar
_ Atributo saldo
_ 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.

| 

  
     

 '$
 
 (
  )%  

_ 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:
_ ÿperações de inicialização
_ ÿperações de consulta (que não alteram o estado da
classe)
_ ÿperações com atribuição (que alteram o estado da
classe)
_ ÿperações de término

| 

  
     

 '

 (
  )%  

_ ÿperações de inicialização:
_ abrir
_ ÿperações de consulta:
_ obterLimite
_ obterSaldo
_ obterExtrato
_ ÿperações de atribuição:
_ estabelecerLimite
_ depositar
_ retirar
_ ÿperações de término:
_ encerrar

| 

  
     

 '&
 |
  %


_ 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 m
 de
teste da 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.
_ Ëantagens:
_ 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).
| 

  
     
 '
   + )  |
  %


_ ÿ que testar?
_ Basicamente, deseja-se testar se uma
implementação reflete exatamente sua
especificação e nada além disso.
_ ÿ 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).

| 

  
     

 
   + )  |
  %


_ Quando testar?
_ Assim que uma classe está pronta para ser
codificada, seu plano de teste pode ser
elaborado.
_ ÿ 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).

| 

  
     

 
   + )  |
  %


_ Como testar?
_ Classes são testadas através de m
  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.

| 

  
     

 
   + )  |
  %


_ 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.

| 

  
     

 "
   |
  %


_ 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

| 

  
     

 #
 |
  
 



_ 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 ÿÿ 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 ÿÿ é crítica para
a correção do programa (McGregor e Sykes,
2001).

| 

  
     

 $
 ,
)
|-
 
  
%



_ 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.
_ ÿbjeto 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).

| 

  
     

 
 |
  
 
_ 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?

| 

  
     

 &
 

.   
 (
 /

_ Adaptação para o paradigma ÿÿ 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.

| 

  
     

 
 |
 (
% )0 1  
_ 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.

| 

  
     

 '
 |
  
 
_ 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).

| 

  
     

 
 *
  ) 
+  |

_ 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).

| 

  
     

 
 *
  )2  
3  
+ 
_ 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).

| 

  
     

 
 *
  ) 
+ 
%

_ 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).

| 

  
     

 "
 |
  %)  4

 3  
2
33 
 %) 

_ 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).

| 

  
     

 #
 |
  %
 /

_ Testa a interação no contexto da realização de
um caso de uso.
_ ÿ 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).

| 

  
     

 $
 1 )4,

)  5 6

|
  
 

  

Ô

 w 


 

    
     

  


 





 
     



  
 

 

  
 
 


   ! "# 

  
 
 


!   "#  ! !
  
 
 


         
!  
 
 


 ! ! !

 
 
 


 "#  "#  "# 
   
 
 


      
$ %  


 "#  ! !
& ! 
  !  
 
 "#  ! !
 !  
'!  
!        
  ( 
 !  
'
  
!     "#  "# 

 !  
 
      "#  "# 

  !  
 
   "#  "# 
  !  
 
      "#  "# 
)    

w   

 "#  ! !

| 

  
     

 
 1 )4,

)  5 6

|
  
 

  

Ô

 w 


 

    
     

  


 





 
     



*
 +!,

 "#  ! !
- .  / 
 
 


 "#  ! !

0 

12   
12  
      

 
12  
         
! 
12  
      
! 
12  
         


12  
      
  
12  
      

| 

  
     

 &
 |
  %
 /

_ 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).

| 

  
     

 
 |
  %
 /

_ 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).

| 

  
     

 '
 1 )4,

)  5 6

|
  
 

Ô

 w 


 

    
     


 
 
 




 
       "   
 
   
 
! 
!
  
    
 
    
     
 

 



3
4  
5  
 



 /  '  6 
   '  6 
 



 +6
  ' +6

 
  
 
   
7
 
7
  
 


3
  4
    


 
7

| 

  
     

 
 1 )4,

)  5 6

 
 
      # 
$ 
"    % 
 
  
  &


   

   
8    
5 |
 . :
 6 '  
 
9 
9   
 ; 
 



7   
8    
5 |
 . :
 6 '  
 
9 
<9   
 ; 
 5$


   
   
8  /  |
 . :
 6 ' '  6 
== / >>   (

   
899    |
 . :
 6 ' '  6 
 


  (

   
8<    
5 |
 . :
 6 '  
 
  
 6 5
 


  
   
   (
   
8<  +6
  |
 . :
 6 ' ' +6
  (
 

(   
8  
7
 |
 . :
 6 '  
 

   ; 
   


 
7
8<  
7

?   
8$   
8 |
 . :
 6 '  
 
$ ; 
 5$  


    
7

 
7
8  
7
8

| 

  
     

 
 1 )4,

)  5 6

|
  
 

Ô

 w 


 

    
     


 
 
 




 
       "   
 
  

 ! 
!
& ! 
  !   

 

     


3
    
4 

77   34 <=8=8<<@
  
3 4 <=8 =8<


  ?

 
  
77   34 =<><<@ '77   
  

  <
<<@
3 4 =< >< '   


 < <

| 

  
     

 
 1 )4,

)  5 6

 
 
     
   # 
$ 
"    % 

  
& 

 8 

   |
 . :
 6 '   

  ; 
   


77   348-<@ <=8=8<<@
  
3 48* <=8 =8<
&7 

 8 

   |
 . :
 6 '   

  ; 
 5$     


77   348A<@ <=8=8<<@

  
3 48& <=8 =8<
& 

 8  ?

   !6
 B   ' 
 ?   
   
   
'
 ?  
& 

 8 
 
 !6
 B   ' 

 



     
   
   
'C 
6 D

| 

  
     

 "
 1 )4,

)  5 6

 
 
     
   # 
$ 
"    % 

  
& 77   348< <=8=8<<@ !6
 B   '    

3 

6 
4   
     

  
'B      
  
& 77   348<<@ <=8=8<<@ !6
 B   '    

3 

6 
4   
     

  
'B   
  
  
&( 77   348E<@ =<><<@ !6
 B   '  '77   
3 

6 
4   
      

  
'   < <<@
       
&? 77   348<<5@ =<><<@ !6
 B   '  '77   
3 

6 
4   
      

  
'   < <<@
    
  

| 

  
     

 #
 |
 (
 )789  
 

_ 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.

| 

  
     

 $
 |
 (
 )789  
 

_ 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.

| 

  
     

 
 |
 (
 )789  
 

_ Usar o diagrama de estados para determinar a
seqüência de eventos a serem exercitados.
_ ÿs 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.

| 

  
     

 &
 |
  *

 )
_ 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).

| 

  
     

 "
 |
  
 )
_ Teste do sistema completo ou de um incremento
a ser implantado provendo algum grau de
funcionalidades para usuários finais.
_ ÿ 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.
_ ÿs tipos de teste nesta fase estão direta ou
indiretamente relacionados a requisitos, tanto
funcionais quanto não funcionais.

| 

  
     

 "'
 |
  
 )
_ ÿs testes de sistema que enfocam requisitos
funcionais são análogos aos testes de
subsistema. ÿu 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.

| 

  
     

 "
 |
  
 )
_ 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.

| 

  
     

 "
 |
  
 )
_ >á 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 >ardware 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

| 

  
     

 "
 6 
:

_ Booch, G., Rumbaugh, J., Jacobson, I., ¢


m¢
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., @ 


m 


 
 m  , Addison-
Wesley, 2001.
_ Pressman, R.S., O
m  . 6a
edição, McGraw>ill, 2006.

| 

  
     

 ""