Buscar

Aula 10 Avaliação de Software


Continue navegando


Prévia do material em texto

Avaliação de 
Software
Daniele Cicillini
Aula 10
Índice
• Unidade 5 – Documentação do 
Planejamento e Relatórios das Verificações 
e Validações
–5.3 – Plano Mestre de Verificação
–5.4 – Plano Mestre de Validação
–5.5 – Casos de Testes
–5.6 – Norma IEEE 829
2
3.4 Casos de Teste
• Os casos de teste definem com detalhe os 
procedimentos a serem seguidos durante
a execução dos testes.
• 3.4.1 CT1 <Nome>
• Descrição: <Em que consiste esse caso de 
teste? Exemplo: Verificar se um
usuário não autorizado consegue acessar 
as funcionalidades do software.>
3
3.4 Casos de Teste
• Tempo estimado: <Qual é a duração 
estimada desse teste? Exemplo: A
verificação para autenticação deve ser feita 
em até 3 segundos.>
• Critério de saída: <Quais ações ou dados 
de saída são esperados? Exemplo: O
acesso deve ser negado e uma mensagem 
exibida ao usuário.>
4
3.4 Casos de Teste
• Requisitos do ambiente: <Quais os 
requisitos do ambiente para a realização
desse teste? Exemplo: O software a ser 
testado deve estar instalado no ambiente
de testes.>
• Objetivos mapeados: <Quais objetivos 
são mapeados com esse teste? Exemplo:
Obj.1 - Segurança>
5
4 Execução dos Testes
• 4.1 Cobertura
• Essa sessão lista as funcionalidades do 
software que são cobertas pelos testes do
Plano, além de outros aspectos, como 
usabilidade, performance e segurança. Ela
não deve ter um caráter técnico, e sim deve 
ser feita sob o ponto de vista do
usuário, abordando o que interessará a ele 
e refletindo o que será testado através
dos casos de teste.
6
4 Execução dos Testes
• 4.2 Resultados
• A importância de se registrar os resultados 
dos testes é muito grande: eles são a
base para a criação de itens de trabalho 
para reparo e replanejamento durante o
desenvolvimento. 
• E, ao final do desenvolvimento, a 
compilação dos resultados dos testes bem-
sucedidos são um indicativo relevante da 
confiabilidade daquele software.
7
Você se lembra quando estudamos 
sobre o teste de verificação?
5.3 – Plano Mestre de Verificação
8
5.3 – Plano Mestre de Verificação
• A verificação refere-se ao conjunto de 
atividades que garante que o software 
implemente corretamente uma função 
específica. 
• Boehm (BOE81) define essa questão da 
seguinte maneira:
• Verificação: “Estamos construindo certo 
o produto?”
9
5.3 – Plano Mestre de Verificação
• O PLANO MESTRE de verificação é um 
documento de alto nível elaborado no 
processo de verificação do software.
• O plano mestre de verificação aborda os 
seguintes itens:
–Principais atividades de verificação;
–Definição de papeis e responsabilidades da 
equipe de verificação;
–Principais documentos a serem empregados.
10
5.3 – Plano Mestre de Verificação
–Cronograma das etapas da verificação 
–Riscos e contingências
• Subordinado ao Plano Mestre de 
Verificação estão as Estratégias de 
Verificação. 
• Para cada fase da verificação deve haver 
uma estratégia de verificação definida e 
documentada.
11
5.4 – Plano Mestre de Validação
• A VALIDAÇÃO refere-se a um conjunto 
diferente de atividades que garante que o 
software que foi construído é rastreável às 
exigências do cliente.
 
• Da mesma forma que na verificação, Boehm 
(BOE81), define essa questão da seguinte 
maneira:
Validação: “Estamos construindo o 
produto certo?”
12
5.4 – Plano Mestre de Validação
• Para a validação não é diferente da 
verificação pois há também o plano mestre, 
que é um documento que descreve os 
objetivos de tudo que deve ser testado na 
fase de validação de software.
–Estabelecer a visão da equipe de validação 
do software; 
–Uniformizar os conhecimentos, experiências 
e expectativas dos diversos grupos que 
integram o processo de desenvolvimento de 
software.
13
5.5 – Casos de Testes
• É o documento de registro de todo o 
planejamento dos testes de estabelecendo 
o que será testado. 
• Sua finalidade é identificar o maior número 
de cenários e variações de determinado 
requisito de software.
14
5.5 – Casos de Testes
• Os casos de testes determinam as 
informações empregadas durante os testes 
dos cenários e os resultados esperados, 
estabelecendo a massa critica de testes 
para validar os requisitos do software.
15
5.6 – Norma IEEE 829
• IEEE 829,1 também conhecido como o 
Padrão 829 para Documentação de Teste 
de Software, é um padrão IEEE que 
especifica a forma de uso de um conjunto 
de documentos em oito estágios definidos 
de teste de software, cada estágio 
potencialmente produzindo seu próprio tipo 
de documento.
16
5.6 – Norma IEEE 829
• O padrão especifica o formato desses 
documentos mas não estipula se todos eles 
devem ser produzidos, nem inclui qualquer 
critério de conteúdo para esses 
documentos.
17
5.6 – Norma IEEE 829
• A norma descreve um conjunto de 
documentos que cobrem as tarefas de 
planejamento, especificação e relatório de 
testes.
–Plano de Teste que apresenta o 
planejamento para a execução do teste 
identifica os itens e as funcionalidades a 
serem testados, as tarefas além dos riscos 
associados com a atividade de teste.
18
5.6 – Norma IEEE 829
• Há também a tarefa de especificação de 
testes que é composta por 3 documentos 
(Especificação de Projeto de teste, 
Especificação de caso de Teste, 
Especificação de Procedimento de teste) 
que principalmente identifica os casos e os 
procedimento de teste, critérios de 
aprovação, define dados de estrada e 
resultados esperado, além de especificar os 
passos para a execução dos testes.
19
5.6 – Norma IEEE 829
• Já os relatórios são cobertos por 4 
documentos (Diário de teste, Relatório de 
Incidente de Teste, Relatório-Resumo de 
teste, Relatório de Encaminhamento de Item 
de Teste) que visam registrar detalhes 
relevantes, eventos que ocorrem durante os 
testes e resultados das atividades.
20
5.6 – Norma IEEE 829
• Um detalhe importante é que esta norma 
separa as atividades de teste em três 
etapas: preparação do teste, execução do 
teste e registro do teste. Mais do que 
apresentar um conjunto de documentos, 
esta norma apresenta um conjunto de 
informações necessárias para teste de 
produtos, independentemente do tamanho 
ou complexibilidade do software. Se bem 
utilizado, servirá de auxílio para gerência.
21
5.6 – Norma IEEE 829
• Independente da forma em que os 
documentos serão adaptados para os testes, 
é importante que incluam o planejamento, 
projeto, os casos de teste e os 
procedimentos de teste. Além disso, os 
resultados/incidentes ocorridos durante o 
teste devem ser adequadamente registrados 
e condensados num relatório final.
22
Avaliação de 
Software
Daniele Cicillini
Atividade 10
23
Atividade
• Questão para a Prova: Analista de Teste 
de Qualidade. Ano: 2009. Banca: FGV. 
Órgão: MEC.
• Analise a citação a seguir.
"Um conjunto de atributos que têm impacto 
na capacidade do software de manter o seu 
nível de desempenho dentro de condições 
estabelecidas por um dado período de 
tempo." 
24
Atividade
• A Norma que integra os conceitos de 
ambiente, estratégias e planejamento de 
testes é conhecida por:
a)ISO 12207.
b)ISO 15504.
c)ISO 9126.
d)IEEE 829.
e)MPS.BR.
25
	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