Tipos de Testes de Software-v3 [Modo de Compatibilidade]disciplinas.lia.ufc.br/es10.1/arquivos/Tipos...

©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


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


� Á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.


• 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


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


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


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


e as saídas esperadas para essas entradas, quando o sistema opera de acordo com suas especificações.

Processo de teste para a detecçãode defeitos


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.

Teste de caixa preta


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


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



� 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



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


Between 4 and 10Less than 4 More than 10

34 7

1110


Between 10000 and 99999Less than 10000 More than 99999

999910000 50000

10000099999

Input values

Number of input values

Especificação de uma rotina debusca

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


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


� 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 deequivalê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


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


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


� 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


Mid-point

Elements < Mid Elements > Mid

Busca binária – casos de teste


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

– 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 programaEste tipo de caso de teste deve ser usado com cuidado.

Complexidade ciclomática


� 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


� 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


� 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

BT2

T1A

T1

A


T3

T4

T5

C

D

T3

T4

B

C

T2

T3

B

Test sequence1

Test sequence2

Test sequence3

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


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


Level 2stubs

Level 3stubs

Teste de integração bottom-up

Level NLevel NLevel NLevel NLevel NTesting

sequence

Testdrivers


Level N–1 Level N–1Level N–1

Testdrivers

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


• 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


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 interfaceTestcases


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


� 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


� 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


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


� 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


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


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.


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


� 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


� 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)

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


• Entrada de pedidos de relatório com reconhecimentoassociado e uma saída final de um relatório

• Pode ser testado criando dados brutos, certificando-se quesão resumidos apropriadamente

• Usar os mesmos dados brutos para testar o objetoWeatherData

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


� 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


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


� 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


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.


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.

Tipos de Testes de Software-v3 [Modo de Compatibilidade]disciplinas.lia.ufc.br/es10.1/arquivos/Tipos...

Documents

Transcript of Tipos de Testes de Software-v3 [Modo de Compatibilidade]disciplinas.lia.ufc.br/es10.1/arquivos/Tipos...