Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
IC-U
NICAMP
Eliane Martins
Testes de Software
Fun
damentos
criado: S
etem
bro / 2
001
alterado: S
et / 2009
Fundamentos
3
IC-U
NICAMP
Eliane Martins
Referências
G.J.M
yers.TheArt of SoftwareTesting. JohnWiley
& Sons, 1979.
B.Beizer. Software TestingTechniques. Internatio
nalT
homsonCom
puter
Press, 2ª ed, 1990.
E.M
artin
s, Verificação e Validação de Software. N
otas de Curso.
R.S.Pressman. SoftwareEngineering. APractitiner’sApproach. 4ª edição,
1997.
R.Binder. TestingOO Systems. Add
ison
Wesley, 2000.
W. de Pádua Paula Fº. Engenharia de Software. E
d. LTC, 2ª ed., 2002.
I. Som
merville. Software Engineering. 8ª ed, 2007.
M.E.Delam
aro etal. Introdução ao Teste de Software. 2007.
P. A
mmann, J. O
ffutt. Introduction to Software Testing. 2008.
Fundamentos
4
IC-U
NICAMP
Eliane Martins
Técnicas de V&V
•Verificação dinâm
ica
–envolve a execução do produto (cód
igo ou m
odelo executável)
–visa encontrar falhas ou erros no produto
exem
plos:
•simulação
•execução sim
bólica
�testes
Fundamentos
5
IC-U
NICAMP
Eliane Martins
•Qual o
objetivo dos testes?
•Quando começam
?
•Quem deve aplicá-los?
•Quando term
inam
?
Fundamentos
6
IC-U
NICAMP
Eliane Martins
Qual o
objetivo dos testes?
•Executar o produto de swcom o intuito de
detectar a presença de falhas [Myers]
•Pode mostrar a presença de falhas em um
sw, mas nunca a sua ausência [Dijkstra]
(IEEE) processo de execução de um sistema ou componente
sob condições especificas para detectar diferenças entre os
resultados obtidos e os esperados
�Teste não prova que o swestá correto!
Fundamentos
7
IC-U
NICAMP
Eliane Martins
Não é objetivo dos testes ...
•Construção e avaliação de protótipos
•Verificação (estática ou dinâmica) de modelos
•Revisão de documentos ou código
•Análise estática automatizada de código
•Análise dinâm
ica de código visando descobrir problemas
tais com
o vazamento de mem
ória, entre outros
•Depuração (debugging) de program
as
�estas atividades com
plem
entam os testes m
as não serão
consideradas com
o testes
Fundamentos
8
IC-U
NICAMP
Eliane Martins
Princípios
[Myers79
]
�Dados de teste devem ser definidos para dados válidos,
inválidos e inoportunos
�Evite testar seus próprios program
as, a m
enos que seja
com auxílio de um
a ferram
enta
�Determine se o swfaz o que é esperado, m
as também se
não faz algo in
desejável
�Nunca planeje testes assum
indo que não serão encontradas
falhas
Fundamentos
9
IC-U
NICAMP
Eliane Martins
Princípios
[Myers79
]
�Nunca jo
gue fora casos de teste, a não ser que vá jogar
o sw
fora também
�A probabilidade de detectar falhas em
uma parte do
swé proporcional ao nº de falhas já detectadas
�Um bom
caso de teste é aquele que tem alta
probabilidade de detectar novas falhas
�Verifique cuidadosamente os resultados de cada caso
de teste
�Testes devem ser planejados desde o início do
desenvolvimento
Fundamentos
10
IC-U
NICAMP
Eliane Martins
Mais princípios
•Casos de teste não são substitutos para a especificação:
–Casos de teste precisam
da especificação para serem
construídos
–Casos de teste precisam
da especificação para a análise dos
resultados
•Execuções com
defeito devem
ser convertidas em casos de
teste
–Servirão para testar se as correções apropriadas foram
feitas
–Falhas “ressuscitam
”, i.e, podem
reaparecer em
futuras
mod
ificações do software
[B. M
eier. S
even principles of software testing. IEEE Com
puter, Ago
/200
8, pp9
9-10
1]
Fundamentos
11
IC-U
NICAMP
Eliane Martins
Quando começam
os testes?
•As atividades de teste devem ser in
iciadas cedo no ciclo de
vida
•As atividades de testes devem
ser in
tegradas às atividades
de desenvolvim
ento
•Procedimentos de teste podem ser descritos desde a fase de
Especificação do Sistema
Fundamentos
12
IC-U
NICAMP
Eliane Martins
Testes no ciclo de vida do software
Requisitos
Arquitetura &
Projeto
Cod
ificação
& Testes de Unidade (ou Com
ponente)
Operação & M
anutenção
Testes de Aceitação
Testes de Sistemas
Análise
Testes de Integração
Testes de Regressão
Uni
dades
Sistema
Plataform
a
Subsistem
as
ou Pacotes
Fundamentos
13
IC-U
NICAMP
Eliane Martins
Escopodos testes
•Esc
opode testes é a coleção
de unidadesde in
teresse
•Uma
unid
adepode
ser um
afunção
(ouum
método), uma
classe, um grupo
de funções
ouclasses, e atémesmoum
componenteexecutávelcom umainterface de program
ação
(API) bem
definida
•Dependendodo escopo, ostestes podem
ser divididosnas
seguintesfases:
–Testes de Unidades
–Testes de Integração
–Testes de Sistemas
–Testes de Aceitação
Fundamentos
14
IC-U
NICAMP
Eliane Martins
Testes de Unidades
•Uma unidade pode ser :
–Módulo ou Função
–Classe
–Pequenos grupos de classes (clusters)
–Com
ponente
–Um serviço
Fundamentos
15
IC-U
NICAMP
Eliane Martins
Testes de Integração
•Grandes grupos de classes
•Subsistem
as
•Com
ponentes
•Com
posição de serviços
Fundamentos
17
IC-U
NICAMP
Eliane Martins
Testes de Aceitação
•Validação do sistem
a:–
o sistem
a está pronto para uso?
–O sistema atende aos requisitos de operação?
Sistema
Componentes externos
Componentes externos
Plataform
a: sw e hw
Fundamentos
19
IC-U
NICAMP
Eliane Martins
O processo de testes
Planejamento
Projeto
Implem
entação Execução
Verificação de Término
Manutenção
Balanço Final
(baseado
em IEEE Std. 100
8/87
-Std. for SwUnitT
esting
[Paula00
])
determ
inar objetivos dos testes (o que testar?)
determ
inar estratégia para criar os
testes que atendam
aos objetivos
executar os casos de testes
determ
inar se objetivos
foram atingidos
Avaliar o processo de testes
Atualizar testes para refletir m
udanças no swe nos objetivos
gerar casos de testes executáveis
Fundamentos
20
IC-U
NICAMP
Eliane Martins
Planejamento
•Visa responder as seguintes questões:
–Quem?
–O quê?
–Quando?
–Onde?
–Porquê?
–Com
o?
equipe de testes; u
suários
requ
isito
s? casos de uso? m
ódulos? ...
cronograma
local; am
biente hw e sw
critérios de com
pletude
métod
os e técnicas
� Plano de Teste
Fundamentos
21
IC-U
NICAMP
Eliane Martins
Planos de Testes
•Saída da fase de planejam
ento. D
eve-se criar um
plano de teste para cada fase:
–Testes de Unidades
–Testes de Integração
–Testes de Sistemas
–Testes de Aceitação
Fundamentos
22
IC-U
NICAMP
Eliane Martins
Decidindo o quê testar
•Dado que tem
po,
recu
rsosou p
esso
alsão escassos, os
sistem
as cada vez mais complexos, com
o garantir a
qualidade mesmo assim? �
testes baseados em
riscos
•Realizar análise de riscos para
–priorizar esforços
–alocar m
elhor os recursos
�
–qu
ais componentes devem
ser m
ais cuidadosam
ente enfocados
Fundamentos
23
IC-U
NICAMP
Eliane Martins
Testes baseados em riscos
•Princípio de Pareto(regra 80/20):
–Vilfredo Pareto, economista italiano, trabalhando em
seu jardim
constatou que:
•80% das pêras �
produzidas por 20%
das árvores
•Será que esse padrão se refletia em outras áreas?
–80% das terras �
20% da população
–80% dos lu
cros �
20% dos funcionários
–80% dos problem
as �
20% dos clientes
–80% das decisões �
20% de um
a reunião
–...
Fundamentos
24
IC-U
NICAMP
Eliane Martins
Aplicando regra 80/20 ao software
�No software:
�80% dos defeitos são decorrentes de falhas em
20%
dos
componentes.
�como achar esses 20% vitais?
�Resultados de outras atividades de V&V (revisões, ...):
�Quais os “cam
peões” de falhas severas ou mod
eradas??
�Métricas
�Que com
ponentes apresentam as piores m
étricas??
Fundamentos
25
IC-U
NICAMP
Eliane Martins
O processo de testes
Planejamento P
rojeto
Implem
entação Execução
Verificação de Término
Manutenção
Balanço Final
(baseado
em IEEE Std. 100
8/87
-Std. for SwUnitT
esting
[Paula00
])
determ
inar objetivos dos testes (o que testar?)
determ
inar estratégia para criar os
testes que atendam
aos objetivos
executar os casos de testes
determ
inar se objetivos
foram atingidos
Avaliar o processo de testes
Atualizar testes para refletir m
udanças no swe nos objetivos
gerar casos de testes executáveis
Fundamentos
26
IC-U
NICAMP
Eliane Martins
Projeto de Testes
•Objetivo
–buscar subconjunto finito
de entradas (e estados) que irão a
lcança
r
e ativaras falh
as(faultsoubugs) existentes, gerando e
rrosque
irão se
pro
pagaraté as saídas, le
vando à
oco
rrên
ciade d
efei
tos
(failures)
•Saída: especificação de testes
Fundamentos
27
IC-U
NICAMP
Eliane Martins
Especificação dos testes
•Saída da fase de Projeto de testes, m
ostrando detalhes sobre os
testes a serem
realizados
•Deve ficar separada do Plano de Testes para que possa ser
reutilizada em
diversos planos
•A especificação pode ser textual (testes m
anuais) ou codificada
em algum
a linguagem (testes autom
atizados)
Fundamentos
28
IC-U
NICAMP
Eliane Martins
Exemplo de descrição textual
Pro
cedim
ento
: Inclusão de Usuário
Iden
tifica
ção: P
CT-01
Obje
tivo Verificar a in
clusão de um
usuário no bdBD_E
XFlu
xo:
1. Abrir in
terface
Tel
a d
e U
suári
os
2. Selecionar N
ovo
3. Inserir N
om
e, L
ogin, S
enha
4. “Clicar” S
alv
ar
5. Selecionar Pes
quisar
procedim
ento de testes
Iden
tifica
ção: C
T01
Item
a tes
tar: caso de uso IncluirUsuário
Entr
adas:
Cam
po
Valo
r
Nom
eUsuário1
Login
Usu1
Senha
uuu
Saíd
as es
per
adas:
Cam
po
Valo
r
Nom
eUsuário1
Log
inUsu1
Pro
cedim
ento: P
CT-01
Dep
endên
cias: banco de dados de teste
deve estar vazio
caso de teste
[dePaula00
]
Fundamentos
29
IC-U
NICAMP
Eliane Martins
O processo de testes
Planejamento
Projeto
Implem
entação Execução
Verificação de Término
Manutenção
Balanço Final
(baseado
em IEEE Std. 100
8/87
-Std. for SwUnitT
esting
[Paula00
])
determ
inar objetivos dos testes (o que testar?)
determ
inar estratégia para criar os
testes que atendam
aos objetivos
determ
inar se objetivos
foram atingidos
Avaliar o processo de testes
Atualizar testes para refletir m
udanças no swe nos objetivos
executar os casos de testes
gerar casos de testes executáveis
Fundamentos
30
IC-U
NICAMP
Eliane Martins
Implem
entação dos testes
•Preparação do
ambiente de testes, tornando
disponíveis todos os recursos necessários
•Instalação e con
figu
ração do
s itens a testar
•Instalação e con
figu
ração das ferram
entas e
compo
nentes de teste
•Criação dos casos e procedimentos de testes
executáveis, caso sua execução seja automática
Fundamentos
31
IC-U
NICAMP
Eliane Martins
Exemplo de im
plem
entação de testes
•Uso de JU
nit
–Framework
que perm
ite
•Im
plem
entar e executar testes de unidade
•Linguagem
JAVA
•Gratuito
, muito utilizado, separa código de teste de código do
produto
–Onde obter mais inform
ações:
[JUnit] http://www.junit.org. Ú
ltim
o acesso
em 20/06/05.
Fundamentos
32
IC-U
NICAMP
Eliane Martins
JUnit
•Exemplo
–Classe
Calculadora.java
publicclassCalculadora {
privatefloatnum1;
privatefloatnum2;
privatefloatresultado;
publicCalculadora() {
} publicfloatsoma(floata, floatb) {
return(a+b);
} publicfloatsubtracao(floata, floatb) {
return(a-b);
} publicfloatdivisao(floata, floatb) {
return(a/b);
} publicfloatmultiplicacao(floata,
floatb) {
return(a*b);
}
}
Fundamentos
33
IC-U
NICAMP
Eliane Martins
JUnit
•Exemplo
–Criando uma
classe de teste
importjunit.framework.TestCase;
importCalculadora;
publicclassCalculadoraTestextends
TestCase
{
privateCalculadora calculadora;
publicvoidtestDivisao() {
floatresultado;
Calculadora calculadora;
calculadora = new Calculadora();
resultado = this.calculadora.
divisao(1.0/5.0);
assertEquals(resultado, 0.2);
} publicstaticvoidmain(String args[]) {
new CalculadoraTest(“testDivisao”);
}
}
Instancia a classe em teste
Testa um m
étod
o
Analisa o resultado
Fundamentos
34
IC-U
NICAMP
Eliane Martins
O processo de testes
Planejamento Projeto
Implem
entação Execução
Verificação de Término
Manutenção
Balanço Final
(baseado
em IEEE Std. 100
8/87
-Std. for SwUnitT
esting
[Paula00
])
determ
inar objetivos dos testes (o que testar?)
determ
inar estratégia para criar os
testes que atendam
aos objetivos
determ
inar se objetivos
foram atingidos
Avaliar o processo de testes
Atualizar testes para refletir m
udanças no swe nos objetivos
gerar casos de testes executáveis
executar os casos de testes
Fundamentos
35
IC-U
NICAMP
Eliane Martins
Execução do
s testes
Testes
executáveis
Sis
tem
a d
eA
uto
ma
çã
o d
e
Te
ste
s
Implem
entação
Sistema em
Teste
Saída esperadas
Veredicto:
Passou / N
ão passou
Entradas de teste
Saídas observadas
Fundamentos
36
IC-U
NICAMP
Eliane Martins
O processo de testes
Planejamento Projeto
Implem
entação Execução
Verificação de Término
Manutenção
Balanço Final
(baseado
em IEEE Std. 100
8/87
-Std. for SwUnitT
esting
[Paula00
])
determ
inar objetivos dos testes (o que testar?)
determ
inar estratégia para criar os
testes que atendam
aos objetivos
determ
inar se objetivos
foram atingidos
Avaliar o processo de testes
Atualizar testes para refletir m
udanças no swe nos objetivos
executar os casos de testes
gerar casos de testes executáveis
Fundamentos
37
IC-U
NICAMP
Eliane Martins
Verificação de térm
ino
Planejamento Projeto
Implem
entação Execução
Balanço Final
Critérios de completeza
atingidos?
Sim
Não
Critérios de teste foram
atendidos?
Falhas prioritárias
foram eliminadas?
Fundamentos
38
IC-U
NICAMP
Eliane Martins
O processo de testes
Planejamento Projeto
Implem
entação Execução
Verificação de Término
Manutenção
Balanço Final
(baseado
em IEEE Std. 100
8/87
-Std. for SwUnitT
esting
[Paula00
])
determ
inar objetivos dos testes (o que testar?)
determ
inar estratégia para criar os
testes que atendam
aos objetivos
executar os
procedim
entos de testes
determ
inar se objetivos
foram atingidos
Avaliar o processo de testes
Atualizar testes para refletir m
udanças no swe nos objetivos
gerar casos de testes executáveis
Fundamentos
39
IC-U
NICAMP
Eliane Martins
Balanço final
•Obtenção de m
étricas:
–Avaliação do produto
–Avaliação do processo de testes
•Lições aprendidas
•Com
pletar Relatório de Testes
–Balanço dos defeitos observados
–Relação entre as falhas corrigidas e os defeitos observados
–Tem
po estim
ado e real: realização dos testes + correções + retestes
–Defeitos observados por caso de teste
Fundamentos
40
IC-U
NICAMP
Eliane Martins
Balanço final
•Análise de causa-raiz (Root C
ause Analysis):
–Quais as causas das falhas encontradas?
–É possível evitar que elas voltem a aparecer em
próximos projetos?
–É possível d
etectá-las m
ais cedo?
Melhoria do processo
Fundamentos
41
IC-U
NICAMP
Eliane Martins
Testar não é tudo
•Testar não é a única form
a de detectar falhas em um sw
–testes devem
com
plem
entar outras formas de V&V e não substitu
í-las
–há falhas que dificilm
ente seriam reveladas através de testes
ex.: vazamento de mem
ória (memoryleak), baixa usabilidade, deadlock
•“L
eis de Beizer” [B
eizer90]:
–Para
doxo d
o P
estici
da: cada métod
o/técnica usada deixa falhas
residuais que não são detectáveis por esse m
étodo/técnica
–Barr
eira
da C
om
ple
xid
ade: a com
plexidade do sw(e das falhas que
este contém) cresce até um limite em
que não podem
os m
ais controlá-lo
Fundamentos
43
IC-U
NICAMP
Eliane Martins
Objetivo
•Buscar as entradas (e estados) que irão a
lcança
re
ativaras
falh
as(bugs) existentes, gerando e
rrosque irão se
pro
pagar
até as saídas, le
vando à
oco
rrên
ciade d
efei
tos (failures)
espec
ific
açã
o
implem
entação
entrada
saída
esperada
saída
observada
= ⇒
passou
≠⇒
não passou
(defeito)
falh
a
oráculo
veredicto
Fundamentos
44
IC-U
NICAMP
Eliane Martins
Com
o alcançar estes objetivos?
•Para observar defeitos nos testes, 3 condições são
necessárias:
–Alcançabilidade
Alcançabilidade
Alcançabilidade
Alcançabilidade: o
local com
a falha deve ser alcançada durante
a execução
–Infecção
Infecção
Infecção
Infecção: a falha é ativada, gerando um erro, i.e, estado incorreto
do program
a
–Propagação
Propagação
Propagação
Propagação: o
estado incorreto deve se propagar até que o
programa gere algum
as saídas incorretas
Fundamentos
45
IC-U
NICAMP
Eliane Martins
Exemplo
•Suponha o seguinte trecho de código:
read(x)
y = x + x
�deveria ser y = x * x
if (y > x) thenwrite(“o quadrado de x é maior
que x”)
elsewrite(“o quadrado de x não é
maior que x”);
para que valores de x a falha seria revelada?
Fundamentos
46
IC-U
NICAMP
Eliane Martins
Exemplo 1
read(x)
y = x + x
�deveria ser y = x * x
if (y > x) thenwrite(“o
quadrado de x é maior
que x”)
elsewrite(“o
quadrado de x não é
maior que x”);
Entrada: x
= 1
Saída esperada: “o quadrado de x não é maior que x”
xy
1***
�Falha!
Fundamentos
47
IC-U
NICAMP
Eliane Martins
Exemplo 2
read(x)
y = x + x
�deveria ser y = x * x
if (y > x) thenwrite(“o
quadrado de x é maior
que x”)
elsewrite(“o
quadrado de x não é
maior que x”);
Entrada: x
= 1
Saída esperada: “o quadrado de x não é maior que x”
xy
1***
12
Alcançou instrução com falha
�Erro!
Infecção
�Falha!
Fundamentos
48
IC-U
NICAMP
Eliane Martins
Exemplo 3
read(x)
y = x + x
�deveria ser y = x * x
if (y > x) thenwrite(“o
quadrado de x é maior
que x”)
elsewrite(“o
quadrado de x não é
maior que x”);
Entrada: x
= 1
Saída esperada: “o quadrado de x não é maior que x”
xy
1***
12
Alcançou instrução com falha
�Erro!
Infecção
Saída: “o quadrado de x é
maior que x”
Propagação
do erro
�Falha!
Defeito!
Fundamentos
49
IC-U
NICAMP
Eliane Martins
Exercício
public static int
OddOrPos(int[] x){
//retorna o nro. de
// elementos de x que são
// ímpares ou positivos
int count=0;
for (int i=0; i<x.length;
i++)
{
if (x[i]%2==1||x[i]>0)
{ count++ }
} return count;
}
•Identifique a falha do program
a.•
Ache um
caso de teste que não
encontre a falha.
•Se possível, encontre um
caso de
teste que encontre a falha m
as que
não produza um
erro
•Se possível, encontra um
caso de
teste que produza o erro m
as não leve
a um
defeito. (não se esqueça do
contador de programa ou PC)
•Identifique o estado errôneo
produzido pelo caso de teste dado
(não esqueça o PC)
Teste: x = [-3,-2,0,1,4]
Saída esperada: 3
Fundamentos
50
IC-U
NICAMP
Eliane Martins
Projeto de Testes -Objetivo
•Objetivo
–buscar subco
nju
nto
fin
itode entradas (e estados) que
irão a
lcança
re
ativaras falh
as(bugs) existentes,
gerando
erro
sque irão se
pro
pagaraté as saídas,
levando à
oco
rrên
ciade d
efei
tos
•Dificuldade
–como encontrar esse subco
nju
nto
fin
ito?
Fundamentos
51
IC-U
NICAMP
Eliane Martins
Ideal
•Dado que testes são úteis quando
revelam a presença de falhas ...
•Dado que quanto m
ais se executar
um software mais chances se tem de
ativar as falhas ...
Quanto mais
exaustivos os
testes, mais falhas
podem ser
encontradas,
certo?
Fundamentos
52
IC-U
NICAMP
Eliane Martins
Sob
re a im
possibilidade de testes exaustivos (1)
•Teste exaustivo
(ou
com
pleto) con
siste em
...
Exercitar o componente em teste (CeT) diante de
todas as combinações possíveis de entradas?
–O nº de com
binações de entradas de um
swpode ser
enorme:
ex.: um programa que lê uma cadeia de 10
caracteres requer 2610combinações!
Fundamentos
53
IC-U
NICAMP
Eliane Martins
Sob
re a im
possibilidade de testes exaustivos (2)
•Teste exaustivo consiste em
...
Exercitar todos os caminhos de execução possíveis?
•ca
min
ho d
e ex
ecuçã
o= seqüência de instruções com
eçando em um ponto
de entrada e term
inando em um pon
to de saída.
–Possível se o programa não tem loops(exp
lícitos ou im
plícitos), senão, o
nº de seqüências de execução pod
e ser muito grande ou in
finito
ex.: o trecho de código abaixo :
for(inti = 0; i < n; ++i ) {
if( x[i]div2 == 0) somapar= somapar+ x [i]
elsesomaimpar= somaimpar+ x [i];
} possui 2n+ 1 (para n> 0) seqüências possíveis de
execução, considerando as repetições
Fundamentos
54
IC-U
NICAMP
Eliane Martins
Projeto de Testes -Solução
•Objetivo
–buscar subco
nju
nto
fin
itode entradas (e estados) que irão
alc
ança
re
ativaras falh
as(bugs) existentes, gerando e
rros
que irão se
pro
pagaraté as saídas, le
vando à
oco
rrên
ciade
def
eito
s
•Dificuldade
–como encontrar esse subco
nju
nto
fin
ito?
�
–Uso de mod
elos
–Uso de critériospara a seleção de testes
Fundamentos
55
IC-U
NICAMP
Eliane Martins
Uso de um
modelo
•Mod
elos de desenvolvimento [S
iegel96]
–R
eq
uis
ito
s: m
odelam
o problem
a–
Pro
jeto: m
odelam
a solução para o
prob
lema
–C
ód
igo
fo
nte: m
odelam
a im
plem
entação
da solução
•Falhas
–hipóteses sobre falhas prováveis (de swou
de hw)
Model
os
de
base
Fundamentos
56
IC-U
NICAMP
Eliane Martins
Classificação das técnicas de projeto de testes
Modelo de base
Especificação
de Requisitos
de Projeto
Código
Falhas
Modelo de teste
Modelo do sistema
ou componente
Modelo do
programa
Modelo de
Falhas
Técnica de teste
Baseado na especificação
(caixa preta)
Baseado na implementação
(caixa branca)
Baseado em falhas
Fundamentos
57
IC-U
NICAMP
Eliane Martins
Mais algumas questões na geração de testes
•Com
o selecion
ar as entradas a serem
usadas nos testes ?
•Com
o decidir se um (compo
nente de) sw
já foi suficientem
ente testado ?
Fundamentos
58
IC-U
NICAMP
Eliane Martins
Critérios de teste
•Um c
rité
riode teste
Cdeterm
ina um
conjunto finito de
elem
entos do m
odelo de teste que devem ser exercitados
durante os testes
•Requisito de teste( R
TC): elemento do modelo de teste que
precisa ser coberto
Ex.: mod
elo de teste = diagram
a de casos de uso
critér
io( C) = to
dos os casos de uso devem ser exercitados ao m
enos
1 vez
requisitos de
test
e( R
TC) = { to
dos os casos de uso do diagram
a }
também chamados de
elem
ento
s re
quer
idos
Fundamentos
60
IC-U
NICAMP
Eliane Martins
•Medida de qualidade dos testes:
–mede o qu
ão com
pleto é um
conjunto de testes (T) com relação ao
critério adotado
–é dada na form
a de uma proporção:
nº d
e r
eq
uis
ito
s d
e t
este
(R
TC)
ex
erc
ita
do
s
nº t
ota
l R
TC
•O nível cobertura permite responder à questão: “quando
term
inam
os testes?”
Porque?
Cob
ertura de testes