Qualidade de Software e Atividades de Verificação e Validação

(1)

SCE 5764 – Engenharia de Software Casos de Falhas em Sistemas Qualidade de Software Atividades de V&V Revis˜oes de Software Teste de Software Conclus˜ao

SCE 5764 – Engenharia de Software

Qualidade de Software e

Atividades de Verifica¸

c˜

ao e Valida¸

c˜

ao

Profa. Ellen Francine Barbosa

{francine}@icmc.usp.br

(2)

SCE 5764 – Engenharia de Software Casos de Falhas em Sistemas Qualidade de Software Atividades de V&V Revis˜oes de Software Teste de Software Conclus˜ao

Roteiro

Casos de Falhas em Sistemas

Qualidade de Software

Atividades de V&V

Revis˜

oes de Software

Teste de Software

Conclus˜

ao

(3)

SCE 5764 – Engenharia de Software

Casos de Falhas em Sistemas

Trem “Fantasma” Desastre no Metrˆo de Nova Iorque O Foguete Espacial Challenger O Ve´ıculo Espacial Ariane 5 Casos de Falhas em Sistemas

Qualidade de Software Atividades de V&V Revis˜oes de Software Teste de Software Conclus˜ao

Casos de Falhas em Sistemas I

Software

Fator chave que diferencia produtos modernos.

Sistemas de transportes, m´

edicos, telecomunica¸c˜

oes,

militares, processos industriais, entretenimento, ...

Presente no dia-a-dia das pessoas.

(4)

Casos de Falhas em Sistemas II

Por que devemos nos preocupar com a

qualidade

do

software?

(5)

Trem “Fantasma”

Em 1995 registraram-se falhas nos sensores das

linhas f´

erreas situadas em t´

uneis nos canais ingleses.

Os trens paravam devido `

a suspeita de outro trem

na linha.

A causa disso era a n´

evoa de ´

agua salgada que

“confundia” os sensores.

Motivo da falha:

Provavelmente os requisitos do sistema n˜

ao levavam

em conta a n´

evoa de ´

agua salgada como um

poss´ıvel evento.

Testes e valida¸

c˜

ao apropriados poderiam detectar o

problema.

(6)

Desastre no Metrˆ

o de Nova Iorque

Em 1995 um trem bateu atr´

as de outro, matando o

maquinista e ferindo 54 pessoas.

A distˆ

ancia entre os sinais (projetado em 1918) era

menor que a distˆ

ancia de parada necess´

aria para os

trens atuais (maiores, mais pesados e mais r´

apidos).

Os trens foram atualizados sem modifica¸

c˜

ao no

sistema de controle.

Motivo da falha:

Atualiza¸

c˜

ao de uma parte do sistema sem validar o

sistema como um todo.

(7)

O Foguete Espacial Challenger

A explos˜

ao a bordo do Challenger ´

e uma das falhas

mais not´

aveis da tecnologia moderna.

Em 1986, ap´

os 73 segundos do seu lan¸

camento, uma

explos˜

ao envolveu o foguete matando 7 astronautas.

As investiga¸c˜

oes conclu´ıram que o problema estava

em algumas juntas do motor que n˜

ao estavam

projetadas para a temperatura e press˜

ao ocorrida.

Motivo da falha:

A especifica¸

c˜

ao da press˜

ao n˜

ao estava de acordo

com os requisitos do sistema.

Os testes realizados foram inapropriados para

detectar a falha.

(8)

O Ve´ıculo Espacial Ariane 5

Em 1996, o ve´ıculo espacial Ariane 5 saiu do curso e

explodiu segundos ap´

os o seu lan¸

camento.

Levou uma d´

ecada de desenvolvimento e custou 7

bilh˜

oes de d´

olares.

Os testes insuficientes em componentes reutilizados

do ve´ıculo Ariane 4 foram a causa do acidente.

Motivo da falha:

Erro de software no c´

alculo da velocidade horizontal

do foguete.

A vari´

avel que armazenava este valor tinha 64 bits

(floating point) e foi erroneamente modificada para

16 bits (signed integer).

O valor era maior que 32.767 (maior inteiro),

gerando uma falha de convers˜

ao!!!

(9)

Casos de Falhas em Sistemas

Por que ´

e dif´ıcil construir software com qualidade?

Existe algum

mecanismo

para garantir a qualidade

do software? Como utiliz´

a-lo eficientemente?

(10)

Qualidade de Software

Garantia de Qualidade (SQA) SQA no Processo de Desenvolvimento de Software

Atividades de V&V Revis˜oes de Software Teste de Software Conclus˜ao

Qualidade de Software

Engenharia de Software

Conjunto de princ´ıpios, m´

etodos e t´

ecnicas que tratam o

software como produto de engenharia que requer

planejamento, projeto, implementa¸

c˜

ao e manuten¸

c˜

ao.

Objetivo Principal

Produzir software de

alta qualidade

, com um baixo

custo.

(11)

Qualidade de Software

Qualidade ´

e a totalidade de caracter´ısticas e crit´

erios de

um produto ou servi¸

co que exercem suas habilidades para

satisfazer `

as necessidades declaradas ou envolvidas.

Vis˜

oes de Qualidade de Software

(12)

Garantia de Qualidade

(SQA – Software Quality Assurance) I

Conjunto de atividades t´

ecnicas aplicadas durante

todo o processo de desenvolvimento.

Garantir que tanto o processo de desenvolvimento

quanto o produto de software atinjam os n´ıveis de

qualidade especificados.

Atividades de SQA

Aplica¸c˜

ao de

m´

etodos t´

ecnicos

.

Ajudar o analista a conseguir uma especifica¸

c˜

ao de

qualidade.

Ajudar o projetista a desenvolver um projeto de

qualidade.

Realiza¸

c˜

ao de

revis˜

oes

.

Avaliar a qualidade da especifica¸

c˜

ao, do projeto, do

c´

odigo, ...

(13)

Garantia de Qualidade

(SQA – Software Quality Assurance) II

Atividades de

teste de software

.

Ajudar a garantir que a detec¸

c˜

ao de erros seja

efetiva.

Aplica¸c˜

ao de

padr˜

oes e procedimentos formais

.

Garantir que estes sejam seguidos durante o

desenvolvimento.

Processo de

controle de mudan¸cas

.

Atividade associada ao gerenciamento de

configura¸

c˜

ao de software.

Mecanismos de

medi¸

c˜

ao

.

Apoio no acompanhamento da qualidade de

software.

Avaliar o impacto de mudan¸

cas metodol´

ogicas e

procedimentais.

Anota¸

c˜

ao e manuten¸

c˜

ao de

registros

.

Procedimentos para coleta e dissemina¸

c˜

ao de

informa¸

c˜

oes de garantia de qualidade.

(14)

SQA no Processo de Desenvolvimento de

Software I

(15)

SQA no Processo de Desenvolvimento de

Software II

Aspectos Positivos

O software ter´

a menos defeitos latentes.

Maior confiabilidade resultar´

a em maior satisfa¸c˜

ao

do cliente.

O custo do ciclo de vida global do software ´

e

reduzido.

Os custos de manuten¸c˜

ao podem ser reduzidos.

Aspectos Negativos

Dif´ıcil de ser institu´ıda em pequenas empresas.

Representa uma mudan¸

ca cultural.

(16)

SCE 5764 – Engenharia de Software Casos de Falhas em Sistemas Qualidade de Software Atividades de V&V

Análise Estática Análise Dinâmica

Revis˜oes de Software Teste de Software Conclus˜ao

Atividades de V&V I

Dentre as atividades de SQA est˜

ao as atividades de

verifica¸

c˜

ao

e

valida¸

c˜

ao

de software.

O objetivo ´

e minimizar a ocorrˆ

encia de erros e riscos

associados.

Detectar a presen¸

ca de erros nos produtos de

software.

(17)

Atividades de V&V II

Verifica¸c˜

ao

Assegurar consistˆ

encia, completitude e corretitude

do produto

em cada fase

e

entre fases

consecutivas

do ciclo de vida.

Estamos construindo corretamente o produto?

Assegurar que o produto, ou uma determinada

fun¸

c˜

ao do mesmo, esteja sendo implementado

corretamente.

Verifica-se inclusive se os m´

etodos e processos de

desenvolvimento foram adequadamente aplicados.

(18)

Atividades de V&V III

Valida¸

c˜

ao

Assegurar que o produto sendo desenvolvido

corresponde ao produto correto, conforme os

requisitos do usu´

ario

.

(19)

Atividades de V&V IV

V&V abrangem um amplo conjunto de atividades de

SQA:

Revis˜

oes t´

ecnicas formais

Auditoria de qualidade e configura¸c˜

ao

Monitoramento de desempenho

Simula¸c˜

ao

Estudo de viabilidade

Revis˜

ao da documenta¸c˜

ao

Revis˜

ao da base de dados

Testes

V&V envolvem atividades de

an´

alise est´

atica

e de

an´

alise dinˆ

amica.

(20)

An´

alise Est´

atica

N˜

ao requerem a execu¸

c˜

ao propriamente dita do

produto.

Podem ser aplicadas em qualquer produto

intermedi´

ario do processo de desenvolvimento.

Documento de requisitos, diagramas de projeto,

c´

odigo-fonte, planos de teste, ...

As

revis˜

oes

s˜

ao o exemplo mais cl´

assico de an´

alise

est´

atica.

Inspe¸

c˜

ao

Walkthrough

Peer Review

(21)

An´

alise Dinˆ

amica

Requerem a execu¸

c˜

ao do produto.

C´

odigo ou quaisquer outras representa¸c˜

oes

execut´

aveis do sistema.

Exemplos de atividades que constituem uma an´

alise

dinˆ

amica do produto:

Teste de Software

(22)

SCE 5764 – Engenharia de Software Casos de Falhas em Sistemas Qualidade de Software Atividades de V&V Revis˜oes de Software

Revisões Técnicas Formais Inspe¸cão de Software Walkthrough Peer-Review Reunião de Revisão Técnica

Teste de Software Conclus˜ao

Revis˜

oes de Software I

Meio efetivo para melhorar a

qualidade

de software.

Filtro

para o processo de Engenharia de Software.

Podem ser aplicadas em v´

arios

pontos

durante o

desenvolvimento do software.

Maneira de usar a

diversidade

de um

grupo de

pessoas

para:

Apontar melhorias necess´

arias ao produto.

Confirmar as partes de um produto em que uma

melhoria n˜

ao ´

e desejada ou n˜

ao ´

e necess´

aria.

Realizar um trabalho t´

ecnico de qualidade mais

uniforme de forma a torn´

a-lo mais administr´

avel.

(23)

Objetivo das Revis˜

oes de Software I

Encontrar erros durante o processo de

desenvolvimento, de forma que eles n˜

ao se

transformem em defeitos depois da entrega do

software.

Descoberta

precoce

dos erros.

Melhoria da qualidade j´

a nas primeiras fases do

processo de desenvolvimento.

Aumento da produtividade e diminui¸c˜

ao dos custos.

Erros s˜

ao detectados quando sua corre¸

c˜

ao ´

e mais

barata.

(24)

Objetivo das Revis˜

oes de Software II

´

E uma oportunidade de treinamento.

Aprender por experiˆ

encia

.

Participantes aprendem as raz˜

oes e padr˜

oes em

descobrir erros.

Participantes aprendem bons padr˜

oes de

desenvolvimento de software.

Com o decorrer do tempo....

A revis˜

ao auxilia os participantes a desenvolver

produtos mais f´

aceis de entender e de manter.

(25)

Tipos de Revis˜

oes

Discuss˜

ao informal

de um problema t´

ecnico.

Apresenta¸

c˜

ao

do projeto de software para uma

audiˆ

encia de clientes, administradores e pessoal

t´

ecnico.

Revis˜

oes T´

ecnicas Formais (RTF), as quais incluem

avalia¸

c˜

oes t´

ecnicas do software realizadas em

pequenos grupos.

(26)

Revis˜

oes T´

ecnicas Formais

M´

etodos de RTF:

Inspe¸c˜

ao

Walkthrough

Peer-Review

(27)

Inspe¸c˜

ao de Software

M´

etodo de

an´

alise est´

atica

para verificar a qualidade

de um produto de software.

Pode-se inspecionar tanto produtos de software

como tamb´

em projetos de software.

Diferencial est´

a na sele¸c˜

ao dos aspectos que devem

ser considerados durante a revis˜

ao.

Inspe¸

c˜

ao em Documentos de Requisitos.

Inspe¸

c˜

ao em C´

odigo-fonte.

(28)

(29)

Vantagens da Inspe¸c˜

ao

Detec¸

c˜

ao antecipada de defeitos (inspe¸

c˜

ao de

requisitos).

Aprende-se pela experiˆ

encia.

Participantes aprendem os padr˜

oes e o racioc´ınio

utilizado na detec¸c˜

ao de defeitos.

Participantes aprendem bons padr˜

oes de

desenvolvimento.

A longo prazo...

A inspe¸

c˜

ao convence os participantes a

desenvolverem produtos mais compreens´ıveis e mais

f´

aceis de manter.

As inspe¸

c˜

oes ajudam a integrar o processo de preven¸

c˜

ao

de defeitos com o processo de detec¸

c˜

ao de defeitos.

(30)

T´

ecnicas de Leitura para Inspe¸c˜

ao I

Como detectar defeitos?

Lendo o documento.

Entendendo o que o documento descreve.

Verificando as propriedades de qualidade requeridas.

Problema:

Em geral n˜

ao se sabe como fazer a leitura de

um documento!!!

Raz˜

ao:

Em geral, os desenvolvedores aprendem a escrever

documento de requisitos, c´

odigo, projeto, mas n˜

ao

aprendem a fazer uma leitura adequada dos mesmos.

(31)

T´

ecnicas de Leitura para Inspe¸c˜

ao II

Solu¸

c˜

ao:

Fornecer

t´

ecnicas de leitura

bem definidas.

Benef´ıcios:

Aumenta a rela¸c˜

ao

custo/benef´ıcio

das inspe¸c˜

oes.

Fornece

modelos

para escrever documentos com

maior qualidade.

(32)

(33)

T´

ecnicas de Leitura para Inspe¸c˜

ao IV

O que ´

e uma t´

ecnica de leitura?

Conjunto de instru¸c˜

oes fornecido ao revisor dizendo

como ler

e

o quˆ

e procurar

no produto de software.

Algumas t´

ecnicas de leitura:

Ad-hoc

Checklist

Leitura Baseada em Perspectiva (PBR)

Stepwise Abstraction

(34)

T´

ecnica de Leitura Baseada em Perspectiva

(PBR) I

T´

ecnica de leitura proposta para detectar defeitos

em especifica¸

c˜

oes de requisitos.

Faz com que cada revisor se torne respons´

avel por

uma

perspectiva

em particular.

Possibilita que o revisor melhore sua experiˆ

encia em

diferentes aspectos do documento de requisitos.

Assegura que perspectivas importantes sejam

contempladas.

Cada revisor lˆ

e o Documento de Requisitos com

olhos diferentes.

Benef´ıcios:

Determina uma responsabilidade espec´ıfica para

cada revisor.

(35)

T´

ecnica de Leitura Baseada em Perspectiva

(PBR) II

V´

arias leituras podem ser feitas no Documento de

Requisitos.

O

projetista

que usa o DR para gerar o projeto do

sistema.

O

testador

que, com base no DR, deve gerar casos

de teste para testar o sistema quando este estiver

implementado.

O

usu´

ario

que verifica se o DR est´

a capturando toda

funcionalidade que ele deseja para o sistema.

(36)

T´

ecnica de Leitura Baseada em Perspectiva

(37)

T´

ecnica de Leitura Stepwise Abstraction I

T´

ecnica de leitura utilizada para detectar defeitos

em c´

odigo-fonte.

Code-Reading

Consiste em desenvolver

abstra¸

c˜

oes funcionais

a

partir do c´

odigo-fonte, para determinar a

funcionalidade do programa.

(38)

T´

ecnica de Leitura Stepwise Abstraction II

Os revisores identificam subprogramas no

c´

odigo-fonte e escrevem suas pr´

oprias especifica¸

c˜

oes

para os subprogramas

(abstra¸

c˜

oes de

funcionalidade).

As

abstra¸c˜

oes

constru´ıdas devem ser combinadas em

uma abstra¸c˜

ao mais geral, at´

e que se tenha

capturado a fun¸c˜

ao completa do programa.

Inconsistˆ

encias s˜

ao detectadas comparando a

especifica¸

c˜

ao original com a especifica¸

c˜

ao constru´ıda

por meio das abstra¸

c˜

oes.

(39)

(40)

Walkthrough

Procedimento similar ao procedimento para

condu¸

c˜

ao de uma inspe¸

c˜

ao.

A diferen¸ca fundamental est´

a na maneira como a

sess˜

ao de revis˜

ao ´

e conduzida.

Em vez de ler o programa ou checar os erros por

meio de um checklist, os participantes

simulam

sua

execu¸c˜

ao.

Papel adicional: testador.

Elaborar um pequeno conjunto de casos de teste

(em papel).

(41)

Peer-Review

Conduzida por

pares de programadores.

Mesmo n´ıvel de conhecimento.

Aplicada ao

c´

odigo.

Reuni˜

oes com dura¸

c˜

ao de 1 a 2 horas.

Somente um programa ou parte dele (rotinas) deve

ser revisado.

Resultados s˜

ao publicados em um relat´

orio informal.

(42)

Reuni˜

ao de Revis˜

ao T´

ecnica I

Independentemente do formato da RTF, toda

reuni˜

ao de revis˜

ao deve seguir as seguintes

recomenda¸c˜

oes:

Envolver de 3 a 5 pessoas.

Deve haver uma prepara¸c˜

ao para a reuni˜

ao.

A prepara¸

c˜

ao n˜

ao deve exigir mais de 2 horas de

trabalho de cada pessoa.

A reuni˜

ao deve durar menos de 2 horas.

Deve-se focalizar uma parte

espec´ıfica

do software.

Maior probabilidade de descobrir erros.

(43)

(44)

Diretrizes para Revis˜

ao

Revise o

produto

, n˜

ao o produtor.

Fixe e mantenha uma

agenda

.

Limite

o debate e a refuta¸

c˜

ao.

Relacione as

´

areas problem´

aticas

.

Fa¸

ca

anota¸

c˜

oes

por escrito.

Limite o n´

umero de participantes e insista em uma

prepara¸

c˜

ao

antecipada

.

Desenvolva uma lista de conferˆ

encia

(checklist)

para cada

produto que provavelmente ser´

a revisto.

Atribua

recursos

e uma

programa¸

c˜

ao de tempo

para as

revis˜

oes.

Realize um

treinamento

significativo para todos os revisores.

Reveja suas antigas revis˜

oes.

(45)

SCE 5764 – Engenharia de Software Casos de Falhas em Sistemas Qualidade de Software Atividades de V&V Revis˜oes de Software Teste de Software

Objetivos do Teste Desafios do Teste Limita¸cões do Teste Terminologia de Erros Caso de Teste Técnicas de Teste Etapas de Teste Fases de Teste Conclusão

Teste de Software

An´

alise

dinˆ

amica

do produto de software.

Processo de executar o software de modo

controlado, observando seu comportamento em

rela¸c˜

ao aos requisitos especificados.

Processo de executar um programa com a inten¸

c˜

ao

de encontrar

erros.

O teste bem sucedido ´

e aquele que consegue

determinar casos de teste que resultem na falha do

programa sendo analisado.

(46)

Teste de Software

Como testar esse produto?

Que

casos de teste

utilizar?

Como garantir que o produto n˜

ao cont´

em erros?

Crit´

erios

...

Como decidir se o produto foi

suficientemente

testado

?

(47)

Teste de Software

Como testar esse produto?

Que

casos de teste

utilizar?

Como garantir que o produto n˜

ao cont´

em erros?

Crit´

erios

...

Como decidir se o produto foi

suficientemente

testado

?

(48)

Objetivos do Teste

Revelar a

presen¸

ca de erros.

Inexistˆ

encia de erro:

Software ´

e de alta qualidade?

(49)

Objetivos do Teste

Revelar a

presen¸

ca de erros.

Atrav´

es da atividade de teste pode-se detectar a

presen¸

ca de erros em um programa, embora n˜

ao se

possa concluir a ausˆ

encia deles.

Quando o processo de teste n˜

ao detecta erros...

O teste pode n˜

ao ter sido suficientemente completo

para revelar os erros existentes.

N˜

ao se pode afirmar que o programa esteja isento

de erros e, portanto, correto.

(50)

Objetivos do Teste

Verificar se o software executa

conforme especificado

na documenta¸

c˜

ao do projeto.

Fornecer uma

avalia¸

c˜

ao da qualidade

do software.

Apesar de n˜

ao ser poss´ıvel, por meio de testes, provar

que um programa est´

a correto, estes contribuem para

aumentar a confian¸

ca de que o software desempenha as

(51)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(52)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(53)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(54)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(55)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(56)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(57)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(58)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(59)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(60)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(61)

Desafios do Teste

Algu´

em j´

a testou algum produto de software?

Quais foram os maiores

desafios?

Alguns problemas comuns...

N˜

ao h´

a tempo suficiente para o teste.

Muitas combina¸

c˜

oes de entrada para serem exercitadas.

Dificuldade em determinar os resultados esperados para

cada caso de teste.

Requisitos do software inexistentes ou que mudam

rapidamente.

N˜

ao h´

a tempo para o teste exaustivo.

N˜

ao h´

a treinamento no processo de teste.

N˜

ao h´

a ferramenta de apoio.

Gerentes que desconhecem teste ou que n˜

ao se

preocupam com qualidade.

(62)

Limita¸c˜

oes do Teste

Observe o exemplo a seguir:

1

i n t

b l e c h ( i n t

j ) {

2

j = j − 1 ;

// d e v e r i a

s e r

j = j + 1

3

j = j / 3 0 0 0 0 ;

4

r e t u r n

j ;

5

}

C´

odigo-fonte: blech.java

Considerando o tipo inteiro com 16 bits (2 bytes), o menor

valor poss´ıvel seria -32.768 e o maior seria 32.767, resultando

em

65.536 valores diferentes poss´ıveis.

Haver´

a tempo suficiente para se criar 65.536 casos de teste?

E se os programas forem maiores? Quantos casos de teste

ser˜

ao necess´

arios?

(63)

Limita¸c˜

oes do Teste

1

i n t

b l e c h ( i n t

j ) {

2

j = j − 1 ;

// d e v e r i a

s e r

j = j + 1

3

j = j / 3 0 0 0 0 ;

4

r e t u r n

j ;

5

}

C´

odigo-fonte: blech.java

Quais

valores

escolher?

Entrada (j)

Sa´ıda Esperada

Sa´ıda Obtida

1

0

42

0

0 20000

0

0 -20000

0

(64)

Limita¸c˜

oes do Teste

Nenhum dos casos de testes anteriores revelou o

erro.

Somente quatro valores do intervalo de entrada

v´

alido revelam o erro:

Entrada (j)

Sa´ıda Esperada

Sa´ıda Obtida

-30000

0 -1

-29999

0 -1

30000

1

0 29999

1

0

(65)

Limita¸c˜

oes do Teste

Nenhum dos casos de testes anteriores revelou o

erro.

Somente quatro valores do intervalo de entrada

v´

alido revelam o erro:

Entrada (j)

Sa´ıda Esperada

Sa´ıda Obtida

-30000

0 -1

-29999

0 -1

30000

1

0 29999

1

0

(66)

Limita¸c˜

oes do Teste

Nenhum dos casos de testes anteriores revelou o

erro.

Somente quatro valores do intervalo de entrada

v´

alido revelam o erro:

Entrada (j)

Sa´ıda Esperada

Sa´ıda Obtida

-30000

0 -1

-29999

0 -1

30000

1

0 29999

1

0

(67)

Limita¸c˜

oes do Teste

Corretitude de Programas

Equivalˆ

encia de Programas

Executabilidade

(68)

Terminologia de Erros

Engano x Defeito x Erro x Falha

(Padr˜

ao IEEE 610.12-1990)

Um

engano

introduz um

defeito

no software.

O

defeito

, quando ativado, pode produzir um

erro

.

O

erro

, se propagado at´

e a sa´ıda do software,

constitui uma

falha

.

(69)

Engano x Defeito x Erro x Falha

Considere o comando (z = y + x ) substitu´ıdo por

engano pelo comando (z = y − x ).

Se o defeito introduzido for ativado com (x = 0):

Nenhum valor incorreto para a vari´

avel z ´

e

produzido.

O defeito ´

e ativado mas

n˜

ao

produz um erro e,

conseq¨

uentemente, n˜

ao ocorre uma falha.

Para qualquer outro valor de x (x 6= 0):

A ativa¸

c˜

ao do defeito

produz

um erro na vari´

avel z.

Tal erro, se propagado at´

e a sa´ıda, caracteriza uma

falha.

(70)

Caso de Teste

O segredo do sucesso do teste est´

a no projeto dos

casos de teste.

Um bom caso de teste tem

alta probabilidade

de

revelar um

erro

ainda n˜

ao descoberto.

Casos de teste tamb´

em podem revelar

especifica¸

c˜

oes

incompletas

ou

amb´ıguas.

(71)

Partes de um Caso de Teste

Par ordenado (d; S(d)) no qual d ´

e um elemento

pertencente ao dom´ınio de entrada D e S(d) corresponde

`

a sua respectiva sa´ıda esperada.

Dado de entrada

(inputs).

Dado necess´

ario para uma execu¸

c˜

ao do programa.

Sa´ıda esperada

(outputs).

Resultado de uma execu¸

c˜

ao do programa.

Pressup˜

oe-se a existˆ

encia de um

or´

aculo de teste

.

(72)

Caso de Teste

(73)

Ordem de Execu¸c˜

ao

Existem dois estilos de projeto de casos de teste

relacionados com a

ordem de execu¸

c˜

ao:

Casos de teste em cascata.

Casos de teste independentes.

(74)

Casos de Teste em Cascata

Os casos de teste devem ser executados um ap´

os o

outro, em uma

ordem espec´ıfica.

O estado do sistema deixado pelo primeiro caso de

teste ´

e reaproveitado pelo segundo e assim

sucessivamente.

Vantagem

: Casos de testes tendem a ser pequenos e

simples. F´

aceis de serem projetados, criados e

mantidos.

Desvantagem: Se um caso de teste falhar, os casos

de teste subseq¨

uentes tamb´

em podem falhar.

(75)

Casos de Teste Independentes

Cada caso de teste ´

e inteiramente

auto-contido.

Vantagem

: Casos de teste podem ser executados em

qualquer ordem.

Desvantagem: Casos de teste tendem a ser grandes

e complexos, mais dif´ıceis de serem projetados,

criados e mantidos.

(76)

T´

ecnicas de Teste

Diferentes tipos de teste podem ser utilizados para

verificar se um programa comporta-se como

especificado.

Basicamente, os testes podem ser classificados em

teste caixa-preta

(black-box testing ),

teste caixa-branca

(white-box testing ) e

teste baseado em erros

(error-based testing ).

Esses tipos de teste correspondem `

as chamadas

t´

ecnicas de teste.

(77)

T´

ecnicas de Teste

As t´

ecnicas de teste s˜

ao definidas conforme o

tipo de

informa¸

c˜

ao

utilizada para realizar o teste.

Contemplam diferentes perspectivas do software:

aspecto complementar!!!!

T´

ecnica Caixa-Preta

Os testes s˜

ao baseados exclusivamente na

especifica¸

c˜

ao de requisitos

do programa.

Nenhum conhecimento de como o programa est´

a

implementado ´

e requerido.

T´

ecnica Caixa-Branca

Os testes s˜

ao baseados na estrutura interna do

programa, ou seja, na

implementa¸

c˜

ao

do mesmo.

T´

ecnica Baseada em Erros

Os requisitos de teste s˜

ao derivados a partir dos

erros mais freq¨

uentes

cometidos durante o

processo de desenvolvimento do software.

(78)

Crit´

erios de Teste

Maneira sistem´

atica e planejada para conduzir os

testes.

Fornece indica¸

c˜

oes a respeito de

quais casos de teste

utilizar

de modo a aumentar as chances de revelar

erros no programa.

Quando erros n˜

ao forem revelados...

Estabelecer um n´ıvel elevado de

confian¸

ca

na

corre¸

c˜

ao do programa.

(79)

Crit´

erios de Teste

Propriedades M´ınimas:

1

_{Garantir, do ponto de vista de fluxo de controle, a}

cobertura de todos os

desvios condicionais

.

2

_{Requerer, do ponto de vista de fluxo de dados, ao}

menos um

uso

de todo resultado computacional.

(80)

Requisitos de Teste

Cada crit´

erio estabelece um conjunto de

requisitos

de teste

espec´ıfico.

Casos de teste s˜

ao selecionados de modo a satisfazer

os requisitos estabelecidos pelo crit´

erio em quest˜

ao.

Dados um programa P, um conjunto de casos de

teste T e um crit´

erio C, diz-se que:

T ´

e

C-adequado

para o teste de P se T preencher os

requisitos de teste estabelecidos pelo crit´

erio C.

(81)

Crit´

erios da T´

ecnica Funcional

Particionamento em Classes de Equivalˆ

encia

An´

alise do Valor Limite

(82)

Crit´

erios da T´

ecnica Estrutural

Baseados em Complexidade

Crit´

erio de McCabe (teste do caminho base).

Baseados em Fluxo de Controle

Todos-N´

os

Todas-Arestas

Todos-Caminhos: Simples, Completo, Livre de La¸co,

...

Baseados em Fluxo de Dados

Crit´

erios de Rapps & Weyuker

Todas-Defs, Todos-Usos, Todos-P-Usos, e outros.

Crit´

erios Potenciais-Usos (Maldonado)

Todos-Potenciais-Usos,

(83)

Crit´

erios da T´

ecnica Baseada em Erros

Semeadura de Erros

Teste de Muta¸

c˜

ao

An´

alise de Mutantes (unidade)

Muta¸

c˜

ao de Interface (integra¸

c˜

ao)

(84)

Crit´

erios de Teste

Crit´

erio de Gera¸c˜

ao

Procedimento para escolher casos

de teste para o teste de P.

T ´

e C-adequado

por constru¸

c˜

ao

.

Crit´

erio de Adequa¸

c˜

ao

Predicado para avaliar um conjunto de

casos de teste T no teste do programa P.

Um crit´

erio de adequa¸

c˜

ao C ´

e utilizado para

verificar

se o

conjunto de casos de teste T satisfaz os requisitos de teste

estabelecidos pelo crit´

erio.