©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
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
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
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. baseados na especificação do sistema.
O planejamento dos testes podem começar nos
primeiros estágios do processo de software.
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 10
Less than 4 More than 10 3
4 7
11 10
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 16
Between 10000 and 99999
Less than 10000 More than 99999 9999
10000 50000
100000 99999
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. 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
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 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
condição do loop
Usado como base para computar a
complexidade ciclomática
Complexidade ciclomática = Número de ramos
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
6 5
7
(if (elemArray [mid]< key 8 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.
Testes de integração incremental
T2 T1 A B T2 T1 A 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 2 Le vel 2
Level 2 Level 2
Level 1 Testing Level 1
sequence . . .
Le vel 2 stubs
Le vel 3 stubs
Teste de integração bottom-up
Level N Level N Le vel N Level N Level N Testing sequence Test drivers Level N–1 Level N–1 Level 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
B A
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
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
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
do 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
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 summarise () reply (report) 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
• 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
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.