Testes de SW
Aula 13
Sumário





Objectivos e Responsáveis
Princípios dos Testes
Software fácil de testar
Desenho de casos de teste
Testes
–
Caixa Branca

–
–
Estrutura de controlo
Caixa preta

–
2
Caminho básico
OO
Ambiente, arquitectura e aplicações
Objectivos e Responsáveis

Descobrir erros
–
–

Um bom teste tem uma alta probabilidade de detectar erros não
descobertos
Um teste tem sucesso SE descobrir um erro não detectado
Quem faz
–
–
Engenheiros de SW
Testadores


Engenheiros de SW especialistas em testes
Usuários contratados para o efeito
–
3
Recém licenciada francesa no verão em Londres..
Princípios






4
Os testes deviam detectar desde erros de código até
a satisfação de requisitos
Devem ser planificados
Isolar módulos “suspeitos” e testá-los
profundamente
Começar pelos módulos e terminar no sistema
inteiro
Não é possível fazer testes exaustivos
Realizados por equipas independentes
Software fácil de testar
- características

Observabilidade (o que você vê é o que você testa)
–
–
–
–
–
–
5
–
Saída diferente para cada entrada
Estados e variáveis do sistema podem ser
consultados durante a execução
Estados e variáveis do sistema antigo podem ser
consultados (registos de transacção)
Todos os factores que afectam os resultados são
visíveis
Um resultado incorrecto identifica-se com facilidade
Os erros internos detectam-se automaticamente
O código fonte é acessível
Software fácil de testar
- características

Controlabilidade
(quanto + controlável, + automatizável e optimizável)
–
–
–
–

Todos os resultados possíveis gerados através da combinação
de entradas
Estados e variáveis do sistema são controláveis pelo
programador
Formatos de E/S são estruturados e consistentes
Os testes podem especificar-se, automatizar-se e reproduzir-se
convenientemente
Modularidade
(controlando o âmbito dos testes, os problemas podem ser isolados)
–
–
6
O sistema está construído em módulos independentes
Os módulos podem ser testados independentemente
Software fácil de testar
- características

Simplicidade (há menos que testar)
–
–
–
Simplicidade funcional (características mínimas)
Simplicidade estrutural (que impede propagação de falhas)
Simplicidade do código (selecção de standards, boas práticas
de programação)

Estabilidade (menos mudanças)
–
–
–
–
7
Mudanças não frequentes
Mudanças controladas
Mudanças não invalidam testes
O software lida bem com as falhas
Software fácil de testar
- características

Facilidade de compreensão (+informação, melhores testes)
–
–
–
–

O Desenho foi compreendido
Dependências entre componentes internos foi compreendida
Mudanças ao desenho foram comunicadas
Documentação técnica acessível instantaneamente, está bem
organizada, é exacta, específica e detalhada.
Operatividade (quanto melhor funcionar, + eficientemente se pode
testar)
–
–
–
8
Tem poucos erros
Os erros não bloqueiam a execução dos testes
O produto evolui em fases
Desenho de casos de teste

Caixa preta
–
Testes sobre as interfaces do Produto de SW
Conhecemos a função específica para a qual foi desenhado o
produto. Podemos levar a cabo Testes que demonstram que
cada função está completamente operacional.

Caixa branca
–
9
Testes sobre os detalhes dos procedimentos de cada função
Conhecemos o funcionamento do produto. Podemos desenvolver
testes que asseguram que “todas as peças se encaixam”. Ou seja,
que a operação interna se ajusta às especificações e que todos os
componentes internos foram comprovados de maneira adequada.
casos de teste de Caixa Branca

garantem o exercício de que:
–
–
–
–

Permitem ver
–
–
–

10
Erros lógicos e supostos incorrectos
Fluxo lógico real dum programa
Erros tipográficos
Porém
–

Todos os caminhos independentes são utilizados
Todas as vertentes falsas e verdadeiras das decisões lógicas
Todos os ciclos nos seus limites
Todas as estruturas internas de dados
os testes exaustivos apresentam problemas logísticos tornando
estes testes impossíveis para grandes sistemas de SW
Devemos, então, seleccionar quais são os caminhos lógicos
mais importantes
Teste do caminho básico





11
É uma técnica de teste de caixa branca
Medida da complexidade lógica
Mede o nº de caminhos independentes
Os casos de teste obtidos por este método
garantem que cada instrução seja executada
pelo menos 1 vez
Pode tornar-se impossível, se o sistema for
muito grande..
Testes da estrutura de controlo



Auxiliam as técnicas de Testes de Caixa Branca
Teste da condição
Teste de fluxos de dados
–

caminhos de teste segundo a localização das definições e usos das
variáveis
Testes de ciclos
–
–
–
–
Passar por alto
Passar 1 vez
Passar 2 vezes
Fazer m passos com m<n

–
Fazer n-1, n e n+1

12
exemplo: se o ciclo executa 10 laços, testamos até o laço 3..
exemplo: se o ciclo executa 10 laços, testamos 9, 10 e forçamos 11 laços ..
casos de testes de Caixa Preta
- várias técnicas

Métodos baseados em grafos
–
–
–
Entender os objectos de dados modelados e as suas relações
Definir uma série de testes que verifiquem “que todos os objectos
possuem as relações esperadas entre eles”
Criar um grafo


Método de Particionamento de Equivalencias
–
Analisa as condições de entrada




–

Intervalo, valor específico, membro de um conjunto de valores, booleano
Método da Análise de valores limites
Testes de comparação
Testes da Tábua Ortogonal
–
13
uma colecção de nós que representa os objectos
Domínos de problemas pequenos
Mas que exigem muitas provas exaustivas
(…)
Testes de ambientes, arquitecturas e
aplicações




Testes de interfaces
Testes de arquitectura cliente/servidor
Testes da documentação e facilidades de
ajuda
Testes de sistemas a tempo-real
PLANO DE PROJECTO (lembrem que 40% são testes):
Adicionem estes e outros testes que acharem convenientes…
Principalmente os Testes OO que serão vistos…
14
próxima semana
Testes OO

Processos de SW OO:


16
quando concluir uma iteração de AOO, DOO e Testes OO?
Testes OO para a Lacertae SW