Cap. 19/ Cap.

13

Estratégias de Teste de
Software
 O que é e Por quê?

“Uma organização de software gasta 40% do esforço de projeto total em teste.”

Especificação de teste =
documentação do plano
estratégico de condução do
teste;
V&V

Verificação: o processo está

realizando tudo o que foi
proposto a ser feito?
Validação: o produto
produzido é o que o usuário
realmente precisa?
Teste de Software -> Garantia de
Qualidade
Para que um software possa ser testável deve
conter 7 características:

 Operabilidade
 Observabilidade
 Controlabilidade
 Decomponibilidade
 Simplicidade
 Estabilidade
 Compreensibilidade
ITG (independent test group)
O ideal seria que testes forem feitos
diariamente, mas isto não ocorre!

O que fazer?
 Estratégia Global
1. Teste de Unidade: Analisa cada componente e seu código fonte;
2. Teste de Integração: Foca o projeto e a arquitetura do software;
3. Teste de Validação: Analisa se os requisitos documentação
estão no software construído;
4. Teste do Sistema: Testa o sistema como um todo, combinando
todos os elementos do sistema;
 Psceudocontrolador
 Psceudocontrolado

SOFTWARES
Teste de Integração

“ Se todos eles funcionam individualmente,

por que você duvida que vão funcionar
quando colocados em conjunto?”
Big-bang
 Fazer tudo depois testar iniciará um ciclo de
“explosões” de erros!

A integração incremental é o oposto

 São testados pequenos incrementos, fáceis
de isolar e corrigir;
Estratégias incrementais de integração

 Integração descendente: top-down;

 Integração ascendente: bottom-up (não
necessita de psceudocontrolados
complexos);
 Teste de Regressão
 Teste Fumaça
Módulo Crítico
 O que é?
 Por que devemos identificá-lo?

•Aborda vários requisitos do software;

•Tem um alto nível de controle;
•É complexo ou propenso a erro;
•Tem requisitos de desempenho bem definidos.
Teste de Validação
 Software convencional e orientado a objetos
são tratados da mesma maneira;
 O importante é o que o cliente entenderá!
 Deve-se basear na seção Critérios de
Validação da especificação dos requisitos para
o teste;
Testes A e Ω

 Desenvolvedor e Usuário Final

 Usuário Final
Teste de Sistema
 Teste de Recuperação
 Teste de Segurança
 Teste de Estresse (Teste de Sensibilidade)
 Teste de Desempenho
A Arte da Depuração

Causas do erro e
reparação
Antes de fazer a correção...

 A causa do efeito está produzida em outra

parte do programa?
 Qual o “próximo defeito” que pode ser
introduzido pelo concerto que estou prestes a
fazer?
 O que poderíamos ter feito para prevenir a
ocorrência desse defeito?
Cap.18/ Cap.14

Técnicas de Teste de Software

Para que seja bom deve revelar um
erro ainda não descoberto;

“A atividade de teste não pode mostrar a

ausência de Bugs; ela só pode mostrar se
defeitos de software estão presentes.”
Testes...
Teste da Interface
“...entrada adequadamente
aceita e saída é corretamente
produzida;(...) sem se preocupar

Black Box com a estrutura lógica interna

do software.”

White
Box
Teste lógico
“...exercitar as estruturas de
dados internas.”
 Teste

White Box Black Box

 Grafo de Fluxo
1
Nó
Ramo
2,3
Nó
Predicativo 4,5
6
R2

7 R3
8
R1
Região
9
10
R4

11
Cálculo da CC:

 O numero de regiões do grafo de fluxo;

 V(G)=E-N+2
V(G) -> complexidade ciclomática
E -> numero de ramos
N -> numero de nós
 V(G)=P+1
V(G) -> complexidade ciclomática
P -> numero de nós predicativos
Particionamento de Equivalência

 Define um caso de teste que descubra classes

de erros;
 Divide as partes envolvidas com a caixa preta
em classes de equivalência que representa
um conjunto de estados Válidos ou Inválidos;
 As Classes são definidas de acordo com as
condições de entrada que podem ser de
intervalo, valor conjunto ou booleana;
Análise de Valor de Limite

 Boundary Value Analysis – BVA

 “... Leva à escolha de casos de teste que põe a
prova os valores fronteiriços.”
 Completa o particionamento de equivalência;
Teste de Matriz Ortogonal

 “O teste de matriz ortogonal permite que

você projete casos de teste que fornecem
máxima cobertura com numero razoável de
casos de teste.”
 Teste de Ambientes, Arquiteturas e Aplicações Especializadas

Teste de Arquiteturas Cliente/Servidor Teste de Sistemas de Tempo Real

Teste da Documentação e
Teste de IGU
Teste de Função de Testes de Banco de
Dispositivos de Ajuda
Teste
Testes de Comunicação Testes
Aplicação Testes de Servidor Dados Testes de Teste de Tarefa
Transação Comportamental
em Rede intertarefas
Teste de Sistema
Padrões de Teste

 “ Padrões de teste podem ajudar uma equipe

de software a se comunicar mais efetivamente
sobre teste e entender melhor as influencias
que levam a abordagens de teste específicas.”

Exemplos Representativos:
 Teste aos pares
 Interface de teste separada
 Teste de cenário
Referências

 PRESSMAN, Roger S. Engenharia de

Software. ed. trad. e rev. São Paulo:Makron
Books, 1995. Cap. 18-19.
 PRESSMAN, Roger S. Engenharia de
Software. 5 ed. Cap. 13-14.
 http://www.io.com/~wazmo/qa/
 http://www.sqatester.com/