Tipos de Testes de Software v3

Prévia do material em texto

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1
Teste de Software
Teste de defeitos
� Testar os programas para 
estabelecer a presença de 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 2
estabelecer a presença de 
defeitos no sistema
Objetivos
� Entender as técnicas de teste que são 
engrenadas para descobrir falhas de programa
� Introduzir guias para teste de interface
� Entender abordagens específicas para testes 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 3
� Entender abordagens específicas para testes 
orientados a objetos
� Entender os princípios do suporte da 
ferramenta CASE para teste
Tópicos
� Testes de componentes e de integração
� Testes de defeitos
� Testes orientados a objetos
Área de trabalho de teste
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 4
� Área de trabalho de teste
O processo de teste
� Testes de componentes
• Testes de componentes de programas individuais.
• Usualmente os programadores assumem a responsabilidade 
pelo teste de seu código (exceto em caso de sistemas 
críticos).
• Testes são derivados da experiência do desenvolvedor.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 5
• Testes são derivados da experiência do desenvolvedor.
� Testes de integração
• Testes de grupos de componentes integrados para formar 
subsistemas ou sistemas completos.
• Uma equipe independente de teste faz o teste de integração.
• Os testes são baseados em uma especificação do sistema.
Fases do teste
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 6
Teste para detecção de defeitos
� O objetivo de testes para a detecção de 
defeitos é revelar defeitos nos programas.
� Um teste bem sucedido é aquele que revela a 
presença de um defeito (faz com que o 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 7
presença de um defeito (faz com que o 
programa se comporte de maneira anômala)
� Testes mostram a presença e não a ausência 
de defeitos.
� Somente um teste exaustivo pode mostrar que 
um programa está livre de defeitos. Contudo, 
teste exaustivo é impossível
� Os testes deviam exercitar as capacidades do 
sistema ao invés de seus componentes
Prioridades do teste 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 8
sistema ao invés de seus componentes
� Testar funcionalidades antigas é mais 
importante do que testar as novas
� Testar situações típicas é mais importante do 
que limitar casos de valor
� Dados de teste - entradas criadas para testar o 
sistema.
� Casos de teste - Entradas para testar o sistema 
e as saídas esperadas para essas entradas, 
Dados de teste e Casos de teste
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 9
e as saídas esperadas para essas entradas, 
quando o sistema opera de acordo com suas 
especificações.
Processo de teste para a detecção
de defeitos
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 10
Teste de caixa preta
� Uma abordagem para testar onde o programa é 
considerado como uma “caixa-preta”.
� Os casos de teste para testar o programa são 
baseados na especificação do sistema.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 11
baseados na especificação do sistema.
� O planejamento dos testes podem começar nos 
primeiros estágios do processo de software.
Teste de caixa preta
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 12
Particionamento de equivalência
� Dados de entrada e resultados de saída caem 
em diferentes classes onde todos os membros 
de uma classe são relacionados 
� Cada uma dessas classes é uma partição de 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 13
� Cada uma dessas classes é uma partição de 
equivalência onde o programa se comporta de 
uma maneira equivalente para cada membro da 
classe
� Casos de teste devem ser escolhidos de cada 
partição.
Particionamento de equivalência
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 14
� Entradas e saídas do sistema são particionadas 
em “conjuntos de equivalência”
• Se a entrada é um inteiro de 5 dígitos entre 10.000 e 99.999, 
partições de equivalência são números < 10.000, números 
entre 10.000 e 99. 999 e números > 99. 999
Particionamento de equivalência
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 15
entre 10.000 e 99. 999 e números > 99. 999
� Escolher casos de teste nos limites das 
partições:
• 00000, 09999, 10000, 99999, 10001
Particionamento de equivalência
Between 4 and 10Less than 4 More than 10
3
4 7
11
10
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 16
Between 10000 and 99999Less than 10000 More than 99999
9999
10000 50000
100000
99999
Input values
Number of input values
Especificação de uma rotina de
busca
procedure Search (Key : ELEM ; T: ELEM_ARRAY;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pré-condição
-- a seqüência tem pelo menos um elemento
T’FIRST <= T’LAST
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 17
T’FIRST <= T’LAST
Pós-condição
-- O elemento é encontrado e é referenciado por L
( Found and T (L) = Key)
ou
-- O elemento não está na seqüência
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
� Entradas que estão de acordo com a pré-
condição: seqüência com no mínimo um 
elemento. 
Entradas onde a pré condição não vale.
Rotina de busca - partições de entrada
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 18
� Entradas onde a pré condição não vale.
� Entradas onde o elemento chave é um 
elemento da seqüência.
� Entradas onde o elemento chave não é um 
membro da seqüência.
Diretrizes de testes (sequências)
� Teste o software com seqüências que possuem 
somente um único valor.
� Use diferentes seqüências, de diferentes 
tamanhos, em diferentes testes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 19
tamanhos, em diferentes testes.
� Derive testes de maneira que o primeiro, o 
médio e o último elemento da seqüência sejam 
acessados.
� Teste com seqüências de comprimento zero.
Rotina de busca - partições de
equivalência
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 20
� Algumas vezes chamado testes de “caixa 
branca”.
� Derivação de casos de teste de acordo com a 
estrutura do programa. O conhecimento do 
Teste estrutural
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 21
estrutura do programa. O conhecimento do 
programa é usado para identificar casos de 
testes adicionais.
� O objetivo é exercitar todos os enunciados do 
programa. 
Teste “caixa branca”.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 22
Binary search (Java)
� Pré-condições satisfeitas, elemento chave incluído na 
matriz 
� Pré-condições satisfeitas, elemento chave não incluído 
na matriz 
Pré-condições não satisfeitas, elemento chave incluído 
Busca binária - partições equivalentes
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 24
� Pré-condições não satisfeitas, elemento chave incluído 
na matriz 
� Pré-condições não satisfeitas, elemento chave não 
incluído na matriz 
� A entrada tem um único valor
� A entrada tem um número ímpar de valores
� A entrada tem um número par de valores
Busca binária - partições equivalentes
Equivalence class boundaries
©Ian Sommerville 2000 Software Engineering,6th edition. Chapter 20 Slide 25
Mid-point
Elements < Mid Elements > Mid
Busca binária – casos de teste
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 26
Teste de caminho
� O objetivo do teste de caminho é assegurar que o 
conjunto de casos de teste permite que cada caminho 
do programa seja executado pelo menos uma vez
� O ponto de partida para o teste de caminho é um 
gráfico de fluxo do programa, no qual os nós 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 27
gráfico de fluxo do programa, no qual os nós 
representam as decisões do programa, enquanto os 
arcos representam o fluxo de controle
� Enunciados com condições são, dessa forma, nós no 
gráfico de fluxo
� Descreve o fluxo de controle do programa, 
Cada ramo é mostrado como um caminho 
separado e loops são mostrado por setas, por 
uma seta fazendo a volta, de volta para o nó de 
Gráficos de Fluxo do Programa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 28
condição do loop
� Usado como base para computar a 
complexidade ciclomática 
� Complexidade ciclomática = Número de ramos 
– Número de nós +2
� O número de testes para testar todos os enunciados de 
controle é igual a complexidade ciclomática 
� A Complexidade ciclomática é igual ao número de 
condições em um programa
Este tipo de caso de teste deve ser usado com cuidado. 
Complexidade ciclomática
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 29
� Este tipo de caso de teste deve ser usado com cuidado. 
Isso não implica na adequação do teste 
� Embora todos os caminhos sejam executados, todas as 
combinações de caminho não são executadas
1
2
3
while bottom <= top
if (elemArray [mid] == key
bottom > top
Gráfico de fluxo para busca 
binária
4
65
7
(if (elemArray [mid]< key8
9
� 1, 2, 3, 8, 9
� 1, 2, 3, 4, 6, 7, 2
� 1, 2, 3, 4, 5, 7, 2
� 1, 2, 3, 4, 6, 7, 2, 8, 9
Caminhos independentes
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 31
� 1, 2, 3, 4, 6, 7, 2, 8, 9
� Casos de teste devem ser projetados para 
executar todos esses caminhos.
� Um analisador de programa dinâmico pode ser 
usado para verificar que os caminhos estão 
sendo executados
Testes de integração
� Testes feitos em sistemas completos ou 
subsistemas, compostos de componentes 
integrados.
� Testes de integração devem ser desenvolvidos 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 32
� Testes de integração devem ser desenvolvidos 
a partir da especificação do sistema.
� A maior dificuldade é a localização de erros.
� Integração incremental reduz esse problema.
Testes de integração incremental
T2
T1A
B
T2
T1A
T1
A
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 33
T3
T4
T5
C
D
T3
T4
B
C
T2
T3
B
Test sequence
1
Test sequence
2
Test sequence
3
Abordagens para o teste de integração
� Teste de integração top-down
• Começa com os componentes de alto nível de um sistema, e 
a integração se dá de cima para baixo em uma hierarquia de 
componentes. Componentes individuais em um nível mais 
baixo na hierarquia são representados por stubs.
Teste de integração bottom-up
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 34
� Teste de integração bottom-up
• Envolve integrar e testar os módulos de nível inferior na 
hierarquia e, então, subir na hierarquia de módulos, até que o 
módulo final seja testado. 
� Na prática, a maioria das integrações envolve a 
combinação dessas estratégias.
Teste de integração top-down
Level 2Level 2Level 2Level 2
Level 1 Level 1Testing
sequence . . .
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 35
Level 2
stubs
Level 3
stubs
Teste de integração bottom-up
Level NLevel NLevel NLevel NLevel N Testing
sequence
Test
drivers
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 36
Level N–1 Level N–1Level N–1
Test
drivers
Abordagens de teste
� Validação da arquitetura
• Os testes top-down oferecem maior probabilidade de descobrir erros 
na arquitetura de sistema
� Demonstração do sistema
• Os testes de integração top-down permitem a demonstração de um 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 37
• Os testes de integração top-down permitem a demonstração de um 
sistema de trabalho limitado em uma fase inicial do desenvolvimento.
� Implementação de teste 
• São geralmente mais fáceis com o teste bottom-up
� Observação de teste
• Problemas com ambas as abordagens. Código extra são 
necessários para observar os testes.
� Ocorrem quando módulos ou subsistemas são 
integrados para criar sistemas maiores.
� Objetivo é detectar erros devido a erros ou 
suposições inválidas sobre interfaces.
Testes de interface
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 38
suposições inválidas sobre interfaces.
� Particularmente importante para o 
desenvolvimento orientado a objeto, uma vez 
que os objetos são definidos por suas 
interfaces
Teste de interface
Test
cases
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 39
BA
C
Tipos de interfaces 
� Interfaces de parâmetros
• Os dados transmitidos de um processo para outro 
� Interfaces de memória compartilhada 
• Bloqueio de memória é compartilhado entre os processos
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 40
� Interfaces de procedimento 
• Sub-sistemas encapsulam um conjunto de processos para 
serem chamados por outros sub-sistemas
� Interfaces de transmissão de mensagem
• Sub-sistemas requerem serviços de outros sub-sistemas 
Erros de interface
� Mau uso da Interface
• Um componente chamador chama outro componente e 
produz um erro no uso de sua interface
» Ex: parâmetros na ordem errada
� Má interpretação da Interface
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 41
� Má interpretação da Interface
• Um componente chamador cria suposições incorretas sobre o 
comportamento do componente chamado
� Erros de tempo
• O componente chamador e o chamado operam em 
velocidades diferentes e informações fora de data são 
acessadas
Guia de teste de Interface
� Projeta testes de forma que os parâmetros de um 
procedimento chamado estão nos extremos de suas 
faixas
� Sempre testar parâmetros indicadores com indicadores 
nulos
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 42
nulos
� Projetar testes que causem falhas no componente
� Usar o teste de estresse em sistemas transmissores de 
mensagem
� Em sistemas de memória compartilhada, variar a ordem 
na qual os componentes são ativados
Teste de estresse
� Exercitar o sistema além de sua carga máxima de 
projeto. Estressar o sistema geralmente faz com que os 
defeitos venham à tona
� Estressando o comportamento de falha de teste do 
sistema. Os sistemas não devem ter falhas 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 43
sistema. Os sistemas não devem ter falhas 
catastróficas. Testes de estresse devem checar perdas 
inaceitáveis de serviço ou dados
� Particularmente relevante para sistemas distribuídos 
que podem apresentar sérias degradações quando a 
rede fica sobrecarregada
� Os componentes a serem testados são classes 
de objetos que são instanciadas como objetos.
� Objetos individuais são, muitas vezes, maiores 
do que funções isoladas, então a abordagem 
Teste orientado ao objeto
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 44do que funções isoladas, então a abordagem 
de teste de caixa-branca deve ser estendida.
� Não existe um nível superior óbvio para 
integração e teste top-down.
Níveis de teste
� Testar operações associadas com os objetos.
� Testar classes de objetos.
� Testar agrupamentos de objetos cooperativos.
Testar o sistema orientado a objeto completo.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 45
� Testar o sistema orientado a objeto completo.
Testes de classes de objetos
� A cobertura completa de testes de uma classe 
envolve
• Testar todas as operações associadas com um objeto
• Estabelecimento e a interrogação de todos os atributos do 
objeto
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 46
objeto
• Exercitar o objeto em todos os estados possíveis
� Herança dificulta o projeto de testes de classe 
de objetos, pois as informações a serem 
testadas não são localizadas
Interface de objeto de uma estação 
meteorológica
� Cases de teste são necessários 
para todas as operações 
� Use um modelo de estado para 
identificar transições de estado 
para teste
identifier
reportWeather ()
calibrate (instruments)
test ()
WeatherStation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 47
para teste
� Exemplos de seqüências de 
teste 
• Fechar→ Esperar→ Fechar
• Esperar → Calibrar → Testar → Transmitir →
Esperar
• Esperar → Coletar → Esperar → Resumir →
Transmitir→ Esperar
test ()
startup (instruments)
shutdown (instruments)
Integração de objetos
� Níveis de integração são menos distintos em 
sistemas orientados a objetos.
� Testes de clusters se ocupam com a integração 
e teste de objetos que cooperam entre si.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 48
e teste de objetos que cooperam entre si.
� Clusters devem ser identificados utilizando-se 
o conhecimento de suas operações e as 
características do sistema implementadas por 
esses clusters.
Abordagens para o teste de cluster
� Teste de casos de uso ou cenário
• O teste é baseado nas interações de um usuário com o 
sistema
• Tem a vantagem de testar as características do sistema como 
são experimentadas pelos usuários
Teste de seqüência
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 49
� Teste de seqüência
• Testa a resposta do sistema a eventos como processar 
seqüências através do sistema
� Teste de interação de objetos
• Testa seqüências de interações de objetos que param quando 
uma operação de objeto não solicita serviços de um outro 
objeto
Teste baseado em cenário
� Identificar cenários de casos de uso e 
suplementá-los com diagramas de interação, 
que mostram os objetos envolvidos no cenário
� Considerar esse cenário no sistema da estação 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 50
� Considerar esse cenário no sistema da estação 
meteorológica onde um relatório é gerado
Coletar dados sobre o tempo
:CommsController
request (report)
acknowledge ()
report ()
:WeatherStation :WeatherData
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 51
summarise ()
reply (report)
acknowledge ()
send (report)
Teste da estação meteorológica
� Seqüência de métodos executados
• CommsController:requerer → WeatherStation:reportar →
WeatherData:resumir
� Entradas e saídas
• Entrada de pedidos de relatório com reconhecimento
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 52
• Entrada de pedidos de relatório com reconhecimento
associado e uma saída final de um relatório
• Pode ser testado criando dados brutos, certificando-se que
são resumidos apropriadamente
• Usar os mesmos dados brutos para testar o objeto
WeatherData
Uma área de trabalho de teste
� O teste é uma fase cara do processo. Uma área 
de trabalho de teste nos dá ferramentas para 
reduzir o tempo necessário e o custo total do 
teste
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 53
� A maioria das áreas de trabalho de teste são 
sistemas abertos porque as necessidades do 
teste são específicas à organização
� É difícil integrar com projeto fechado e áreas de 
trabalho de análise
Uma área de trabalho de teste
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 54
Tete de adaptação de área de trabalho
� Os scripts podem ser desenvolvidos para os 
simuladores de interface de usuário e padrões 
para geradores de dados de teste
� Saídas de testes podem precisar ser 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 55
� Saídas de testes podem precisar ser 
preparadas manualmente para comparação
� Comparadores de arquivos de propósito 
especial podem ser desenvolvidos
Pontos chave
� É mais importante testar as partes do sistema mais 
comumente utilizadas do que as partes que são 
exercitadas raramente.
� Partição de equivalência é uma maneira de derivar casos 
de teste. Partições são conjuntos de dados onde o 
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 56
de teste. Partições são conjuntos de dados onde o 
programa deve se comportar de maneira equivalente.
� Teste de caixa preta é baseado na especificação do 
sistema. Não precisa analisar o código fonte.
� Teste estrutural baseia-se na análise do programa para 
determinar os caminhos a serem executados e a seleção 
de casos de teste.
Pontos chave
� Os testes de integração testes de integração se 
concentram no teste das interações entre os 
componentes.
� Os testes de interface testes de interface procuram 
descobrir defeitos nas interfaces ou nos módulos.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 57
descobrir defeitos nas interfaces ou nos módulos.
� Para testar as classes de objetos testar as classes 
de objetos, deve-se testar todas as operações, 
atributos e estados.
� Sistemas orientados à objetos devem ser integrados 
integrados em torno de clusters clusters de objetos.