Aula 05 Avaliação de Software

Prévia do material em texto

Avaliação de 
Software
Daniele Cicillini
Aula 5
Índice
• Unidade 3 – Testes de Validação
–3.1 – Teste de Validação
• 3.1.1 – Testes de Caixa Branca
• 3.1.2 – Testes de Caixa Preta
–3.2 – Abordagens dos Testes
–3.3 – Testes Progressivos e Regressivos
–3.4 – Categorias dos Testes de Validação
2
Unidade 3 – Testes de Validação
• O processo de qualidade de software está 
decomposto em fases. Cada fase tem uma 
sequência de execução dos testes a serem 
aplicados.
• OS TESTES DE VERIFICAÇÃO visam 
garantir o processo de desenvolvimento, 
funcionais de software, enquanto OS 
TESTES DE VALIDAÇÃO estão focados na 
garantia da qualidade do produto de 
software.
3
Unidade 3 – Testes de Validação
• Testes de verificação e validação são 
complementares.
• Em hipótese alguma, estes deverão ser 
encarados como atividades redundantes.
• Tanto um quanto o outro possui naturezas e 
objetivos distintos, fortalecendo o processo 
de detecção de erros e aumentando a 
qualidade final do produto. 
4
3.1 – Teste de Validação
• Os testes, além de localizar erros, também 
são necessários para determinar a 
confiabilidade, o desempenho e para validar 
a interface com o usuário.
5
3.1 – Teste de Validação
• O teste de validação tem o seu foco na 
aplicação, uma vez que já existe um produto 
computacional. 
• Seu principal objetivo é identificar o maior 
número possível de erros. 
• O sucesso desse teste está apoiada
no forte planejamento de todas as atividades 
de teste.
6
3.1 – Teste de Validação
• O foco do estágio de teste do sistema é 
garantir que se esteja cobrindo todos os 
requisitos testáveis expressos em um 
conjunto de casos de teste.
• Isso significa que os critérios de conclusão 
se concentrarão na cobertura de teste 
baseada em requisitos. 
7
3.1 – Teste de Validação
• Nos estágios de teste unitário e de 
integração, é possível perceber que a 
cobertura de teste baseada em código é um 
critério de conclusão mais apropriado.
• Existem basicamente duas estratégias 
utilizadas para conduzir o processo de 
validação de software: testes de caixa 
branca e testes de caixa preta.
8
3.1.1 – Testes de Caixa Branca
• Também conhecido como TESTE 
ESTRUTURAL. 
• É aquele em que o analista tem
total acesso à estrutura interna da entidade 
(Código Fonte) sendo analisada e permite, 
por exemplo, que o analista escolha partes 
específicas de um componente para serem
testadas.
9
3.1.1 – Testes de Caixa Branca
• Exemplo:
–Se a definição de uma função g(), para um 
determinado programa, afirma que ela não 
aceita valores negativos, um avaliador 
(Testador) poderia provocar uma chamada 
fun(-1) e descobrir que um tratamento de 
exceções não está corretamente 
implementado.
10
3.1.1 – Testes de Caixa Branca
• Testes como este permite ao avaliador 
concentrar a atenção nos pontos mais 
importantes ou “perigosos” do código, de 
uma maneira mais precisa do que no caso 
do teste caixa-preta. 
• Tais pontos podem até ser identificados 
durante o desenvolvimento e cobertos com 
o uso de assertivas e testes.
11
3.1.1 – Testes de Caixa Branca
• Importante:
–Há, entretanto, um elemento comum entre 
os testes caixa-preta e caixa branca: em 
ambos os casos, o avaliador não sabe 
qual será o comportamento do produto em 
uma determinada situação.
12
3.1.2 – Testes de Caixa Preta
• O Teste de Caixa-Preta ou TESTE 
FUNCIONAL, também é usado no 
desenvolvimento, no problema de 
identificação de sistemas, e advém do fato 
de que ao analisar o comportamento de um 
objeto, ignora-se totalmente sua construção 
interna.
• O teste de caixa-preta é baseado nos 
requisitos funcionais do software.
13
3.1.2 – Testes de Caixa Preta
• Como não há conhecimento sobre a operação 
interna do programa, o avaliador se concentra 
nas funções que o software deve desempenhar.
 
• A partir da especificação são determinadas as 
saídas esperadas para certos conjuntos de 
entrada de dados.
• Esse tipo de teste reflete, de certa forma, a óptica 
do usuário, que está interessado em se servir do 
programa sem considerar os detalhes de sua 
construção.
14
3.1.2 – Testes de Caixa Preta
• O teste é particularmente útil para revelar 
problemas, tais como:
• funções incorretas ou omitidas;
• erros de interface;
• erros de comportamento ou desempenho;
• erros de iniciação e término.
15
3.1.2 – Testes de Caixa Preta
• Exemplo:
• O avaliador deve buscar simular erros que 
um usuário pode cometer e que fogem da 
especificação do programa:
–usar como data de nascimento a data atual 
ou uma data futura;
–preencher campos com um número 
insuficiente de caracteres (por exemplo, 
digitar apenas “123” para CPF ou telefone);
16
3.1.2 – Testes de Caixa Preta
–códigos de CPF ou de CEP errados;
–preencher campos como nome com valores 
muito grandes (por exemplo, copiar - colar 
um texto de 10 Kbytes num campo);
–deixar campos de entrada vazios ou 
preenchê-los com espaços brancos ou 
zeros (sobretudo campos de preenchimento 
obrigatório);
17
3.1.2 – Testes de Caixa Preta
–usar valores negativos para números, como 
valor a pagar;
–não respeitar tipos de dados (por exemplo, 
digitar letras ou símbolos em um campo 
“idade”.
18
3.2 – Abordagens dos Testes
• Abordagens de teste dizem respeito à 
profundidade da análise a ser realizada. 
• Em outras palavras, a abordagem de um 
teste define se o que interessa são apenas 
as respostas geradas pelo item em teste ou 
se o seu comportamento interno também 
deve ser levado em conta.
19
3.2 – Abordagens dos Testes
• Comparação entre as abordagens de Teste:
20
Figura – Abordagens fundamentais dos testes. Fonte Bartié, 2002.
3.3 – Testes Progressivos e 
Regressivos
• Os TESTES PROGRESSIVOS são testes 
elaborados de acordo com a criação de 
novas funcionalidades do software.
• Nesta abordagem é necessário testar 
somente as inovações do software, 
assumindo que nenhum erro foi introduzido 
após seu processo de desenvolvimento.
21
3.3 – Testes Progressivos e 
Regressivos
• Sendo assim para este teste assume que as 
funcionalidades existentes não são tratadas 
e considera-se que as novas alterações no 
código não impactaram na estrutura 
existente anteriormente.
22
3.3 – Testes Progressivos e 
Regressivos
• Já os TESTES REGRESSIVOS é uma 
abordagem que reexecuta um subconjunto 
(total ou parcial) de testes previamente 
executados.
• Seu objetivo é garantir que uma alteração 
ou criação de nova funcionalidade não 
causou impactos nas estruturas já 
existentes. 
23
3.3 – Testes Progressivos e 
Regressivos
• Para o teste regressivo toda nova versão do 
produto deveria ser submetida a uma nova 
sessão de testes, a fim de assegurar que 
estes novos segmentos não afetaram outras 
partes do produto.
24
3.4 – Categorias dos Testes de 
Validação
• Como todo processo são divididos em 
etapas ou categorias, os testes de validação 
também possui as suas divisões.
• Segundo Bartié (2002) ele afirma que o 
objetivo de todo teste é detectar os erros 
existentes no produto de software, porém a 
realização de todas as categorias de testes 
descrita a seguir não reflete a realidade 
vivenciada pelas equipes de teste.
25
3.4 – Categorias dos Testes de 
Validação
• Porém Bartié afirma que a realização de 
todas estas categorias demandaria um 
esforço muito grande, então se faz 
necessário selecionar as categorias a 
utilizar conforme o perfil do produto.
26
3.4 – Categorias dos Testes de 
Validação
A) Testes de Funcionalidade: Para Bartié (2002), o 
direcionamento dos testes funcionais deve ser 
realizado com base nos documentosde 
especificação funcional. Este documento 
descreve o comportamento da aplicação nos 
diversos cenários existentes para cada requisito 
de negócio. A principal característica desta 
categoria de testes é o grande foco nos negócios, 
com isso, garante-se que não exista diferença 
entre os requisitos funcionais e o comportamento 
do software construído.
 27
3.4 – Categorias dos Testes de 
Validação
B. Teste de Usabilidade: Para Rios e Moreira 
(2003), os testes de usabilidade têm como meta 
simular as condições de uso da aplicação sob a 
perspectiva do usuário. Sendo assim, este tipo 
de teste tem como foco verificar a facilidade de 
navegação entre as telas da aplicação, a clareza 
dos textos e das mensagens apresentadas ao 
usuário, o volume reduzido de interações para 
realizar uma determinada função, o padrão 
visual e etc.
28
3.4 – Categorias dos Testes de 
Validação
C. Testes de Carga: Conforme Bastos 
(2006), os testes de carga servem 
basicamente para avaliar como uma 
aplicação e toda sua infraestrutura se 
comportam quando se aplica um volume 
de transações superiores aos volumes 
máximos previstos para esta aplicação e 
quando se aplica variações bruscas de 
transações. 
29
3.4 – Categorias dos Testes de 
Validação
D. Testes de Volumes: Segundo Bartié 
(2002), os testes de volume são 
caracterizados por determinar os limites 
de processamento e a carga da aplicação 
e de toda a sua infraestrutura. Este tipo de 
teste é conduzido de forma contínua, 
aumentando o volume das operações 
realizadas com a aplicação, até que se 
atinja o limite máximo.
30
3.4 – Categorias dos Testes de 
Validação
E. Testes de Configuração: Para Molinari 
(2006), esta categoria de testes tem por 
finalidade executar o software sobre 
inúmeras configurações de software e de 
hardware. A meta deste teste é garantir 
que a solução funcione corretamente 
sobre os diversos ambientes previstos nas 
fases de levantamento de requisitos.
31
3.4 – Categorias dos Testes de 
Validação
F. Testes de Compatibilidade: Bartié 
(2002) afirma que esta categoria tem por 
finalidade executar a aplicação 
interagindo com as versões anteriores de 
outras aplicações ou dispositivos físicos. 
O objetivo deste teste é garantir que as 
novas versões de um software estão 
suportando antigas versões.
32
3.4 – Categorias dos Testes de 
Validação
G. Testes de Segurança: Segundo Rios e 
Moreira Filho (2003), este tipo de teste 
tem como objetivo encontrar as falhas de 
segurança que podem comprometer a 
confidencialidade e a integridade das 
informações, provocar perdas de dados 
ou interrupções de processamento.
33
3.4 – Categorias dos Testes de 
Validação
• Existem ainda outros tipos de testes como:
–Testes de Desempenho;
–Testes de Confiabilidade e Disponibilidade;
–Testes de Recuperação;
–Testes de Instalação.
• A grande finalidade para esses vários tipos 
de testes é para garantir a qualidade do 
produto final.
34
Avaliação de 
Software
Daniele Cicillini
Atividade 5
35
Atividade
• Questão de Concurso para  Analista em TI e 
Comunicação – Órgão PROCEMPA – 
Banca FGV, 2014.
1)A verificação dinâmica está baseada nas 
três dimensões de testes, listadas a seguir:
tipos de teste, técnicas de teste 
e níveis de teste. 
36
Atividade
Assinale a opção que apresenta somente 
itens da dimensão tipos de teste que foca o 
usuário final.
a)Teste de Aceitação – Teste de Regressão – 
Teste Estrutural;
b)Teste de Funcionalidade – Teste de 
Desempenho – Teste de Unidade;
c)Teste de Interface – Teste de Carga – Teste 
de Segurança;
37
Atividade
d) Teste Funcional – Teste de Volume – 
Teste de Sistema;
e) Teste de Usabilidade – Teste de 
Funcionalidade – Teste de Integração.
38
Atividade
• A alternativa correta é a C.
39
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39