Engenharia de Software

Tema da Aula

Teste de Software
I Conceitos e Estratgias

Prof. Cristiano R R Portella

portella@widesoft.com.br

Engenharia de
Software

Conceitos
Teste e Garantia de Qualidade

Importncia do Teste, segundo Deutsch:

O desenvolvimento de software envolve uma srie

de atividades de produo, com alta probabilidade
de insero de erros devido a falhas humanas.
Por causa da falta de habilidade do ser humano de
cumprir tarefas e de comunicar-se com perfeio,
torna-se necessrio garantir a qualidade de software.
A maioria dos erros so humanos e tem origem na
comunicao, entendimento e transformao das
informaes.

Conceitos
Teste e Garantia de Qualidade

Engenharia de
Software

A atividade de teste o processo de executar um

programa com a inteno de descobrir um erro.
Um bom Caso de Teste aquele que tem uma
elevada probabilidade de revelar um erro ainda no
descoberto.
Teste no serve para mostrar a ausncia de defeitos,
mas sim que eles esto presentes.
Durante o teste observamos as falhas.
Na Depurao (debugging) encontramos os defeitos
(causa) para corrigi-los.

Terminologia

Engenharia de
Software

9 Defeito (Fault)
Instruo ou definio incorreta.

9 Falha (Failure)

Resultados incorretos

9 Erro (Mistake)

Falha resultante de ao humana

Fonte: IEEE Std 729, Standard Glossary of Software Engineering Terminology

Durante o teste observamos as falhas. Na depurao do

cdigo encontramos os defeitos (causas) para corrigi-los.

Conceitos
Teste e Garantia de Qualidade

Engenharia de
Software

No existe software livre de defeitos, o que no pode

servir de desculpa para no se aplicar Tcnicas de
Garantia de Qualidade em Software e Testes para
localizao/eliminao de erros.
Um valor tpico de 10 erros/KLOC.
O custo de localizao e remoo de defeitos
aumenta medida em que o ciclo de
desenvolvimento evolui. Quanto antes uma falha for
revelada, menor o custo de reparao e maior a
probabilidade de corrigi-la corretamente.

Conceitos
A Importncia do Teste de Software

Engenharia de
Software

9 Os erros so cometidos:
60% nas fases iniciais do desenvolvimento
40% durante a implementao

9A

Maioria do erros encontra-se nas partes pouco

executadas do cdigo (esconde-se nos cantos);

9 Um

bom teste , no mnimo, to difcil quanto o

desenvolvimento de software (quanto mais
complexo o software, mais difcil a montagem do
teste).

Engenharia de
Software

Engenharia de
Software

Custo de Correo de Erros

Terminologia

A atividade de Teste tambm conhecida como Verificao e

Validao (V&V).
A Verificao refere-se ao conjunto de atividades que garante
que o software implemente corretamente uma funo
especfica.
A Validao refere-se a um conjunto de atividades que
garante que o software construdo rastrevel s
exigncias do cliente.

Terminologia

Engenharia de
Software

Verificao:
Estamos construindo certo o produto ?

Validao:
Estamos construindo o produto certo ?

Atividades de Teste

Engenharia de
Software

1. Planejamento
Definio de Padres
Critrios de Adequao (Parada)
Modelos de Estimativa

2. Projeto de Casos de Teste

3. Execuo dos Casos de Teste

Tcnicas

4. Anlise dos Resultados Obtidos

5. Documentao e Registro

Viso Detalhada do Teste

(Fluxo de Atividades)

Engenharia de
Software

Planejar

Engenharia de
Software

Avaliar

Melhorar

Princpios para um bom Teste

9 Planejar tipo de teste

9 Planejar detalhes da atividade
Plano de Teste
9 Definir o procedimento de testes
9 Definir os resultados esperados
9 Avaliar resultados obtidos (Obtido x Esperado)
9 Melhoramento Contnuo do Processo, redefinindo
tcnicas e a confiabilidade prevista, atravs de
melhoria em: Normas, Polticas, Procedimentos e
Ferramentas de testagem.

Contedo de um
Plano de Teste

Engenharia de
Software

9 Processo de Teste
Descrio de cada fase do Teste (Estratgia)

9 Rastreabilidade de Requisitos

Planejamento de teste para cada requisito

9 Itens que sero Testados

Descrio detalhadas de cada Item que ser

testado (Modelo, Manual, Programa, etc..)

9 Cronograma

Alm do Tempo, Matriz de Alocao de Recursos x

Atividades-Fases

Engenharia de
Software

Contedo de um
Plano de Teste

9 Procedimentos de Registro
Definio das Mtricas e Padronizao dos
mecanismos de registro de resultados, para que o
processo de teste possa ser medido

9 Requisitos de Hardware, Software e Rede

Lista de recursos necessrios para o teste

9 Descrio das Restries

Restries que afetaro o processo de teste (Ex:

Deficincia de Pessoal, Treinamento de Pessoal,
Aquisio de Software, etc...)

Tipos de Teste nas respectivas

Fases do Desenvolvimento

Engenharia de
Software

Tipos de Testes

Engenharia de
Software

9 Teste

Unitrio: Teste dos Mdulos (ou Classes)

individualmente (cada unidade).

9 Teste de Integrao: Teste da Integrao entre os

mdulos (ou classes). Teste do Projeto do Software.

9 Teste

de Validao (ou aceitao): Teste pra

verificar se o produto de software atende os
requisitos (conformidade com os Requisitos).

9 Teste de Sistema: Combinao de diferentes testes

para por a prova todos os diferentes elementos do

sistema (foram adequadamente integrados ?
Realizam corretamente as funes ?)

Engenharia de
Software

Engenharia de
Software

Tipos de Teste
Durante o Desenvolvimento

Progresso dos Testes

Teste Unitrio

Engenharia de
Software

Foco: Atividade de verificao na menor unidade do

software (mdulo, classe, programa, etc..)
Abordagem Prtica:
1. Aplicar Tcnicas Funcionais (viso externa do
produto de software entradas e sadas)
2. Depois, complementar com tcnicas estruturais
(viso interna do produto de software - algoritmo)

Engenharia de
Software

Teste de Integrao

Foco: Atividade Sistemtica para verificar a

Construo da Estrutura do software e tambm
para a interface (comunicao) entre os mdulos

9 Porque Teste de Integrao necessrio?

Dados podem se perder na Interface entre os Mdulos

Um mdulo pode ter efeito inadequado sobre outro
Combinao de Sub-funes podem no gerar a
funo principal desejada
Estruturas Globais podem afetar o software

10

Teste de Integrao

Engenharia de
Software

Abordagem incremental

9 Teste

atravs de segmentos de mdulos que se

integram;

9 Complexidade controlvel: mdulos so integrados

dois a dois;

9 Trs formas:
top-down
bottom-up
sanduche

Integrao
Top-Down x Bottom-UP

Engenharia de
Software

Mdulo 1

T
O
P
D
O
W
N

Mdulo 2

Mdulo 3

Mdulo 5

Mdulo 7

Mdulo 4

Mdulo 6

Mdulo 8

B
O
T
T
O
M
U
P

Mdulo 9

11

Estratgias de Teste
Abordagem Top-Down

Engenharia de
Software

Abordagem Top-Down:
Inicia-se a integrao pelo primeiro mdulo at o
ltimo da hierarquia (de cima para baixo).

9 Duas abordagens:

Em Largura: Integra-se, a princpio, todos os mdulos

subordinados
Em Profundidade: Integra-se todos os mdulos de
um caminho de controle do software (que implementa
uma certa funcionalidade) da estrutura do software

9 Problema Logstico: Uso obrigatrio de stubs

Estratgias de Teste
Abordagem Top-Down

Engenharia de
Software

9 Stubs:

Mdulos simplificados que substituem

outros de nvel mais avanados ainda no
integrados (top-down).

9 Como lidar com esse problema logstico?

Adiar a execuo de alguns casos de teste que
certamente causaro a chamada do mdulo que
ainda no foi construdo;
Criar stubs que simulem as principais funes do
mdulo no construdo.

12

Estratgias de Teste
Abordagem Top-Down

Engenharia de
Software

Tipos de Stubs:

Estratgias de Teste
Abordagem Top-Down

Engenharia de
Software

Tipos de stubs:
1. Mostra mensagem de trace (entrei no stub)
2. Mostra a lista de parmetros que foi passada (recebi
a=8, b=9, x=a:\dados.mdb)
3. Retorna um valor, previamente armazenado em um
tabela (no stub) ou em um arquivo externo
4. Recebe parmetros, faz um busca na tabela (interna
ou arquivo externo e retorna valor para o mdulo
chamador)

13

Estratgias de Teste
Abordagem Top-Down

Engenharia de
Software

Processo de Integrao (incremental):

1. Testa-se o primeiro mdulo
2. A cada Passo:
Substitui-se um
subordinado

"stub"

por

um

novo

mdulo

Mdulo testado permanece

Engenharia de
Software

Integrao Top-Down
Profundidade 1/3

Stub

Stub

14

Engenharia de
Software

Integrao Top-Down
Profundidade 2/3

Stub

Engenharia de
Software

Integrao Top-Down
Profundidade 3/3

15

Integrao Top-Down
Definio da Seqncia de Teste

Engenharia de
Software

Seqncia de teste:
M1 M2
M1 M2 M5
M1 M2 M5 M8
M1 M2 M6;
Mas se M6 for necessrio
para que M2 funcione
corretamente:
M1 M2
M1 M2 M6
M1 M2 M5
M1 M2 M5 M8 .

Estratgias de Teste
Abordagem Bottom-Up

Engenharia de
Software

Abordagem Bottom-Up:
Mdulos so integrados partindo-se do ltimo da
hierarquia (de baixo para cima).

9 Novo

problema logstico: Um "driver" deve ser

providenciado para coordenar as entradas, sadas

e chamadas do mdulo (substituir stubs por driver).

9 Driver:

Programa

de

controle

escrito

para

coordenar a entrada e sada do Caso de Teste

(navegao).

16

Engenharia de
Software

Estratgias de Teste
Abordagem Bottom-Up

Tipos de Drivers:

Engenharia de
Software

Estratgias de Teste
Abordagem Bottom-Up

Processo de Integrao:
1. Mdulo de nvel mais baixo so mapeados em
clusters (conjunto de mdulos que executam
alguma funo do software)
2. Driver coordena a entrada e sada dos dados
3. Cluster testado (mesmo que incompleto)
4. Troca-se o driver pelo mdulo hierarquicamente
superior (integra-se cada cluster pouco a pouco)

17

Estratgias de Teste
Abordagem Bottom-Up

Engenharia de
Software

Driver

Driver

Driver

Cluster 3
Cluster 1
Cluster 2

Estratgias de Teste
Abordagem Bottom-Up

Engenharia de
Software

Driver

Driver

Driver

1- Driver D1 usado para testar

Cluster 1.
2- Driver D2 usado para testar
Cluster 2.
3- Quando o bloco Ma estiver
pronto, ele substituir os drivers
D1 e D2.
4- Driver D3 usado para testar
Cluster 3.
5- Quando o bloco Mb estiver
pronto ele substituir o Driver D3.
6- O Driver D4 ser criado para
testar Ma e Mb.
7- Quando o bloco Mc estiver
pronto ele substituir o Driver D4
integrando Ma e Mb

18

Estratgias de Teste
Top-Down ou Botton-Up

Engenharia de
Software

Top-Down
Desvantagens

Necessidade de criar
stubs

Vantagens Testa antes as

principais funes de
controle.

Botton-Up
O programa no existe
como entidade at que o
ltimo mdulo seja
adicionado. Necessidade
de criar drivers (mais
fceis que stubs)
Projeto de Caso de
Teste mais fcil pela
ausncia de stubs.

Estratgias de Teste
Top-Down ou Botton-Up

Engenharia de
Software

Definir os mdulos crticos e dar prioridades a eles

(quanto mais rpidos testa-los, melhor).
Dependendo de sua posio na estrutura do produto,
escolher a abordagem.
Mdulos crticos:

9 Abordam diversos requisitos do software;

9 Tem elevado nvel de controle (ponto alto na
estrutura);

9 complexo ou propenso a erros; e

9 Tem restries de desempenho definidas.

19

Engenharia de
Software

Estratgias de Teste
Teste de Sistema

BU
TD

Engenharia de
Software

Estratgias de Teste
Abordagem Alternativa (Sanduche)

Abordagem Combinada ou Sanduche

9 Mistura as melhores caractersticas das anteriores

9 Deve-se avaliar sua aplicabilidade caso a caso
9 Define-se um linha base (ponto de inflexo) na
estrutura de integrao dos mdulos:
Acima da linha: TOP-DOWN
Abaixo da linha: BOTTOM-UP

20

Estratgias de Teste
Abordagem Sanduche

Engenharia de
Software

Top-Down

Bottom-Up

Engenharia de
Software

Projeto de Casos de Teste

Caso de Teste: Entrada, Sada Esperada.

9 To difcil quanto o projeto do produto

9 Poucos gostam de teste; menos pessoas gostam de
projetar Casos de Teste
Software lgico; Teste ainda mais abstrato;
Esforo de teste parece desperdiado se no forem
expostas falhas no software;

21

Projeto de Casos de Teste

Engenharia de
Software

Teste Exaustivo o Ideal: Todos os erros sero

identificados e corrigidos (porm impraticvel).
1 Lei: Paradoxo do Pesticida
Todo mtodo usado para prevenir erros/defeitos
ineficaz para algum tipo de erro/defeito.

2 Lei: Barreira da Complexidade

A complexidade do software (e consequentemente
dos erros) cresce em funo dos limites de nossa
habilidade em gerenciar aquela complexidade.

Engenharia de
Software

Executar os Casos de Teste

9 Preparar os Scripts de Teste.

9 Executar o Conjunto de Casos de teste (Test Suite)
em batch .

9 Armazenar o Test Suite.

9 Ferramentas automatizadas de teste aumentam a
produtividade da execuo dos casos de teste.

22

Anlise dos Resultados

Engenharia de
Software

9 Verificar cada resultado obtido contra o esperado;

9 Anotar todas as ocorrncias (no conformidades);
9 Resolver cada ocorrncia individualmente,
considerando as possibilidades:
Erro de Codificao
Erro de Anlise e/ou Especificao
Erros de Teste.

Engenharia de
Software

Depurao

Quando um teste bem sucedido revela uma falha, a

depurao (debugging) o processo de localizao
do defeito e sua remoo.
Pode ser um processo emprico, pois muitas vezes a
manifestao externa do erro (falha) e sua causa
interna (defeito) no tem relao bvia entre si.
O processo de depurao tenta ligar o sintoma a uma
causa provvel, que se encontrada ser corrigida.
Se a causa no for descoberta, ser projetado novo
Caso de Teste para validar uma suspeita de causa
da falha.

23

Depurao

Engenharia de
Software

Teste de Regresso

Engenharia de
Software

Teste de Regresso:
Repetio dos testes j executados, a fim de garantir
que as novas modificaes no introduziram novos
defeitos em aspectos do software que j haviam sido
testados e depurados.
Ferramentas de testagem permitem que os testes de
regresso sejam realizados de maneira automtica e
rpida.

24

Depurao

Engenharia de
Software

O processo de depurao torna-se particularmente

difcil quando:

9 Sintoma e causa esto distantes;

9 O sintoma desaparece (temporariamente)

quando

outro erro corrigido;

9 O sintoma causado por no-erro (por exemplo o

resultado de um arredondamento em cascata);

9 Sintoma

causado por erro humano (difcil de

rastrear);

9 Sintoma causado por erro de timing (executado no

momento errado);

Engenharia de
Software

Depurao

O processo de depurao torna-se particularmente

difcil quando:

9 Condies

de entrada difceis de reproduzir com

preciso (por exemplo em aplicaes de tempo real);

9 Sintoma

intermitente (particularmente comum em

sistemas embutidos); e

9 Sintoma

tem causas distribudas por diferentes

tarefas (mltiplas causas concorrentes).

25

Engenharia de
Software

Depurao

Geralmente, medida em que passa o tempo de

depurao, os erros remanescentes so mais sutis,
demandando mais esforo ou diminuindo a
probabilidade de sua localizao.

Engenharia de
Software

Depurao

Abordagens de depurao:
1. Fora Bruta:
Mtodo mais comum e menos eficiente, deixa que o
prprio computador descubra o erro, usando traces
e instrues inseridas para ajudar a determinar o
momento da falha.
2. Backtracking:
Abordagem usada em pequenos programas. A
pesquisa inicia-se no local onde a falha foi
descoberta; rastreia-se o cdigo para trs. A
complexidade do cdigo pode aumentar muito o
nmero de caminhos a serem rastreados.

26

Depurao

Engenharia de
Software

Abordagens de depurao:
3. Eliminao da causa:
Uma hiptese de causa imaginada e um Caso de
Teste montado para provar ou refutar a hiptese.
Uma lista de todas as possveis causas gerada.

Engenharia de
Software

3. Eliminao da causa:
O que
no
Quando
no
Onde
no
Em que extenso
no

Depurao

_____________
_____________
_____________
_____________
_____________
_____________
_____________
_____________
The Method (Brown & Sampson).

27

Engenharia de
Software

Depurao

A correo de um defeito pode introduzir outras falhas.

Trs perguntas simples (Van Vleck) devem ser
feitas ao se remover o defeito:
1. A causa do defeito reproduzida em outra(s) partes
do software (bloco padro copiado ou padro de
programao) ?
2. A correo do defeito pode introduzir nova falha
(parte do programa fortemente acoplada a
estruturas lgicas ou estruturas da informao) ?
3. O que poderia ser feito para eliminar essa falha
desde o princpio (abordagem de Garantia de
Qualidade de Software) ?

Engenharia de
Software

Revises Tcnicas Formais (FTR)

Tambm chamadas de walkthroughs, inspees,

revises round-robin etc uma tcnica de garantia
da qualidade de software (atividade guarda-chuva),
que tem os seguintes objetivos:
9 Descobrir erros de funo, lgica ou implementao
9 Verificar se o software atende aos requisitos
9 Verificar se documentao tcnica atende padres
e formalismo
9 Obter software desenvolvido de maneira
estruturada e uniforme
9 Tornar os projetos mais administrveis.

28

Engenharia de
Software

Revises Tcnicas Formais (FTR)

Reunio de Reviso Tcnica Formal:

9 Durao mxima de 2 horas;

9 De 3 a 5 participantes;
9 Somente desenvolvedores (sem chefias);
9 Analisar o produto e no o desenvolvedor;
9 Definir lder e anotador;
9 Preparar material para os participantes; e
9 Apontar os problemas e no tentar resolve-los.

Engenharia de
Software

Exerccio

Em grupo de 4 alunos, crie um formulrio que ser

usado para Plano de Teste, contendo no mnimo,
as seguintes informaes:

29

Exerccio

Engenharia de
Software

9 Nome do Sistema;
9 Nome do(s) mdulos em teste (ou produto todo);
9 Fase do ciclo de vida em que cada teste ser
9
9
9
9
9
9
9

realizado;
Tcnicas empregadas e respectivas ferramentas;
Responsvel(eis) pela aplicao do teste;
Cronograma de teste (incio-fim-durao);
Responsvel(eis) pelo registro dos resultados;
Responsvel(eis) pela verificao e aprovao;
Critrios para a concluso de cada fase; e
Normas/padres a serem seguidos,

Exerccio

Engenharia de
Software

Seu trabalho :

9 Dispor as informaes no melhor arranjo possvel.

9 Incluir as informaes que o grupo entender
necessrio (com certeza elas existem).
Use o material de aula, a bibliografia recomendada e a
criatividade, para incluir campos necessrios ao
formulrio.

9 Fazer um teste (terico) de aplicao do formulrio.

30