ES 14 - Testes de Software

(1)

Régis Simão

1/45

Testes de Software

(2)

Testes de Software

Agenda



_Introdução



_{Testes para a detecção de defeitos}



_{Testes de integração}



_{Testes orientados a objetos}



_{Workbenches de testes}



_Bibliografia

(3)

Régis Simão

3/45

Testes de Software

Introdução



_Objetivos

 Explicar uma série de técnicas de testes, que são utilizadas para

descobrir defeitos em programas

 Descrever as diretrizes que apoiam os testes de interfaces de

componentes

 Explicar as abordagens específicas dos testes de componentes e dos

testes de integração para sistemas orientados a objetos

 Explicar os princípios de operação de apoio de ferramentas CASE para

(4)

Testes de Software

Introdução

Testar programas para identificar a

presença de defeitos

(5)

Régis Simão

5/45

Testes de Software

Introdução



_{Processo de Testes}

 Testes de Componentes

 Testes de componentes de programas individuais

 Geralmente é responsabilidade do desenvolvedor de componentes (exceto em sistemas críticos)

 Testes são derivados da experiência dos desenvolvedores



Testes de Integração

 Testes de grupos de componentes integrados para criar um sistema ou subsistema

 Responsabilidade de um time independente de testes

(6)

Testes de Software

Testes para a Detecção de Defeitos



_{O objetivos destes testes são descobrir defeitos nos programas}



_{Um teste de defeito de sucesso é aquele que faz que o programa se}

comporte de uma forma anômala



_{Testes mostram a presença, não a ausência de defeitos}



_{Priorização dos Testes}

 Somente testes exaustivos podem mostrar que um programa está livre de

defeitos. Contudo testes exaustivos são impossíveis

 Testes devem exercitar as funcionalidades dos sistemas, não os seus

componentes

 Os testes de regressão são mais importantes que os testes de novas

funcionalidades

(7)

Régis Simão

7/45

Testes de Software

Testes para a Detecção de Defeitos



_{Dados de Testes e Casos de Testes}

 Dados de Testes  Massa de dados que é definida para testar o sistema



_{Casos de Testes  Entradas que são usadas para testar o sistema e}

saídas esperadas para as entradas, se o sistema funcionar de acordo

com a especificação

(8)

Testes de Software

Testes para a Detecção de Defeitos



_{Testes Caixa Preta}

 Uma técnica de teste onde os programas são vistos como caixas pretas,

não se conhece a estrutura interna do programa

 Os casos de testes do programa são baseado na sua especificação



_{O planejamento de testes podem começar cedo durante o processo de}

(9)

Régis Simão

9/45

Testes de Software

Testes para a Detecção de Defeitos

(10)

Testes de Software

Testes para a Detecção de Defeitos



_{Partição de Equivalência}

 Dados de entrada e de saída normalmente são divididos em classes,

onde os membros de uma classes estão relacionados

 Exemplos de classes: números primos, números negativos, números

positivos, strings sem branco

 Cada uma dessas classes é uma partição equivalente, onde o programa

comporta-se de um modo equivalente para cada membro de uma classe

(11)

Régis Simão

11/45

Testes de Software

Testes para a Detecção de Defeitos

(12)

Testes de Software

Testes para a Detecção de Defeitos



_{Partição de Equivalência}

 Entradas e saídas de conjuntos de equivalência

 Se a entrada é um inteiro de 5 dígitos entre 10000 e 99999, partições equivalentes são < 10000, 10000 – 99999 e > 100000

(13)

Régis Simão

13/45

Testes de Software

Testes para a Detecção de Defeitos

(14)

Testes de Software

Testes para a Detecção de Defeitos



_{Especificação de uma Rotina de Busca}

 Partições de Entrada

 Entradas que atendam as pré-condições

 Entradas que uma pré-condição não trate

 Entradas onde o elemento é membro de um vetor (array)

 Entradas onde o elemento não é membro do vetor



_{Orientação para os testes}

 Teste o software com um conjunto que tenha somente um valor  Use conjuntos com diferentes tamanhos

 Derive os testes de forma que os elementos da primeira, do meio e da última

posições sejam acessados

(15)

Régis Simão

15/45

Testes de Software

Testes para a Detecção de Defeitos

(16)

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Estrutura}

 Às vezes chamado de testes de caixa branca



_{Derivação dos casos de testes de acordo com a estrutura do programa. O}

conhecimento sobre o programa é usado para identificar casos de testes

adicionais

 O objetivo é exercitar todos os comandos do programa (não todas as

(17)

Régis Simão

17/45

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Estrutura ou}

Caixa Branca – Implementação

em Java de uma Rotina de

(18)

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Estrutura ou Caixa Branca}

 Partições de Equivalência para a Rotina de Pesquisa Binária

 Pré-condições satisfeitas, elemento está no conjunto

 Pré-condições satisfeitas, elemento não está no conjunto

 Pré-condições não satisfeitas, elemento está no conjunto

 Pré-condições não satisfeitas, elemento não está no conjunto

 Conjunto de entradas com um único valor

 Conjunto de entradas com um número impar de valores

(19)

Régis Simão

19/45

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Estrutura ou Caixa Branca}

(20)

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Estrutura ou Caixa Branca}

(21)

Régis Simão

21/45

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Caminho}

 O objetivo dos testes de caminho é garantir que o conjunto de casos de

testes percorrem todos os caminhos do programa pelo menos uma vez

 O ponto inicial para os testes de caminho é um grafo de fluxo de

programa, onde os nós representam decisões do programa e arcos

representam o fluxo de controle

 Grafo de Fluxo do Programa

 Descreve o fluxo de controle do programa. Cada ramo é mostrado com um caminho em separado e laços são mostrados como uma seta de volta ao nó que representa a condição do laço

 Usado como base para cálculo da computação ciclomática

(22)

Testes de Software

Testes para a Detecção de Defeitos



_{Testes de Caminho}

 Complexidade Ciclomática

 O número mínimo de casos de testes para testar todas os caminhos dos programa é igual a complexidade ciclomática

 A complexidade ciclomática é igual ao número de condições simples no programa + 1

 Útil se usado com cuidado. Todos os caminhos são executados, mas nem todas as combinações de caminhos são executadas



Caminhos Independentes

 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

 Casos de testes devem ser derivados de forma que todos os caminhos sejam executados

(23)

Régis Simão

23/45

Testes de Software

Testes para a Detecção de Defeitos

(24)

Testes de Software

Testes de Integração



_{Testar todo o sistema ou subsistema composto de componentes}

integrados



_{Testes de integração devem ser testes de caixa preta com testes}

derivados da especificação do sistema



_{A principal dificuldade é localizar os erros quando eles acontecem}



_{Testes de integração incremental reduzem este problema}

(25)

Régis Simão

25/45

Testes de Software

Testes de Integração

(26)

Testes de Software

Testes de Integração



_{Abordagens para os Testes de Integração}

 Testes Top-Down

 Inicia-se com o sistema de alto nível e integra-se de cima para baixo, trocando componentes individuais pelos stubs quando necessário



Testes Botton-Up

 Integra-se componentes individuais em níveis até o sistema completo ser criado

(27)

Régis Simão

27/45

Testes de Software

Testes de Integração

(28)

Testes de Software

Testes de Integração



_{Utilização das Abordagens de Testes de Interação}

 Validação Arquitetural

 O teste de integração top-down é melhor na descoberta de erros na arquitetura do sistema



Demonstração do Sistema

 O teste de integração top-down permite uma demonstração limitada nos estágios iniciais do desenvolvimento



_{Implementação dos testes}

 Normalmente mais fácil com os testes de integração botton-up

 Observação dos testes

 Ambas as abordagens têm problemas. Códigos extras podem ser necessários para se observar os testes

(29)

Régis Simão

29/45

Testes de Software

Testes de Integração



_{Testes de Interface}

 Ocorrem quando módulos ou subsistemas são integrados para criar

grandes sistemas

 Os objetivos são detectar falhas devido aos erros de interface ou

interpretações inválidas sobre as interfaces

 Particularmente importantes para o desenvolvimento orientado a objetos,

(30)

Testes de Software

Testes de Integração

(31)

Régis Simão

31/45

Testes de Software

Testes de Integração



_{Tipos de Interface}

 Interfaces de Parâmetros

 Quando dados são passados de um componente para outro



_{Interfaces de Memória Compartilhada}

 Quando um bloco de memória é utilizado por um componente para guardar os

dados e outro componente ler os dados do bloco de memória



_{Interfaces de Procedimento}

 Quando um subsistema encapsula um conjunto de procedimentos a serem chamados por outros subsistemas

 Interfaces de Passagem de Mensagem

(32)

Testes de Software

Testes de Integração



_{Erros de Interface}

 Mau Uso da Interface

 Um componente chama outro componente e provoca um erro no uso de sua interface, por exemplo, ordem errada dos parâmetros



Mau Entendimento da Interface

 Um componente faz interpretações erradas de um outro componente e quando o invoca, o resultado é uma resposta não esperada



_{Erros de timing}

 Os componentes operam em diferentes velocidades e uma informação

(33)

Régis Simão

33/45

Testes de Software

Testes de Integração



_{Diretrizes para Testes de Integração}

 Projete os testes de forma que os parâmetros de um procedimento

estejam nos limites extremos

 Sempre teste parâmetros do tipo ponteiro com ponteiros nulos



_{Projete testes que causem o componente falhar}

 Use testes de estresse em sistemas de passagens de mensagem



_{Em sistemas de memória compartilhada, varie a ordem em que os}

(34)

Testes de Software

Testes de Integração



_{Testes de Estresse}

 Exija do sistema além da carga máxima projetada. Estressar o sistema

normalmente força que os defeitos apareçam

 Estressar o sistema testa as falhas de comportamento. Sistemas não

devem falhar catastroficamente. Os testes de estresse buscam a perda

inaceitável de serviços ou dados

 Particularmente relevante para sistemas distribuídos que podem exibir

(35)

Régis Simão

35/45

Testes de Software

Testes Orientados a Objetos



_{Os componentes a serem testados são classes que são instanciados}

como objetos



_{Os objetos possuem granularidade maior que funções individuais, de}

forma que a abordagem de teste caixa branca necessita ser estendida



_{Não há um topo de sistema para aplicar a integração e os testes top-down}



_{Níveis de Testes}

 Testes de operações associadas aos objetos



Testes de classes

 Testes de grupos de objetos que cooperam entre si



_{Testes do sistema OO completo}

(36)

Testes de Software

Testes Orientados a Objetos



_{Testes de Classes}

 A cobertura de testes completa de uma classe envolve

 Testar todas as operações associadas com um objeto

 Atribuição e leitura de todos os atributos do objeto

 Testar o objeto em todos os possíveis estados



_{Herança torna mais difícil projetar testes de classes, por que a}

(37)

Régis Simão

37/45

Testes de Software

Testes Orientados a Objetos



_{Interface do Objeto Estação Meteorológica}

 Casos de testes são necessários para

todas as operações

 Use o modelo (diagrama) de estados para

identificar as transições de estado a serem

testados

 Exemplos de seqüência de testes

 Desativado  Aguardando  Desativado

 Aguardando  Calibrando  Testando  Transmitindo  Aguardando

 Aguardando  Coletando  Aguardando  Resumindo  Transmitindo  Aguardando

(38)

Testes de Software

Testes Orientados a Objetos



_{Integração de Objetos}



_{Níveis de integração são menos distintos em sistemas orientados a}

objetos



Testar um grupo de objetos está relacionado com a integração e o teste

do conjunto de objetos colaborando entre si



_{Abordagens para Testar um Grupo de Objetos}



_{Testes baseados em Cenários ou Casos de Uso}

 O teste é baseado em uma interação do usuário com o sistema

 Tem a vantagem de testar as funcionalidades do sistema como se fosse o próprio usuário



_{Testes de Threads}

 Testa a resposta do sistema a uma entrada em particular ou a um conjunto de

eventos de entrada

(39)

Régis Simão

39/45

Testes de Software

Testes Orientados a Objetos



_{Testes baseados em Cenários}

 Identificam cenários a partir de casos de uso e complementam com

diagramas de interação que mostram como os objetos são envolvidos

nos cenários

 Considere o cenário em um sistema de estação metereológica, onde um

relatório é gerado



_{Testando a Estação Metereológica}

 Seqüência de Métodos Executados:

 ControladordeComunicacao:requisitar  EstacaoMetereologica:relatar  DadosMetereologico:resumir



_{Entradas e Saídas}

 A entrada de um pedido de relatório com uma confirmação associada e uma saída final de um relatório

 Pode ser testado pela criação de dado brutos e garantir que é resumido corretamente