Verificação, Validação e Teste de Software · •Certificações SCJP e CBTS Apresentação 2...

02/07/2011

1

Verificação, Validação e Teste de Software

Prof. Raquel Silveira

Instituto de Teologia Aplicada - INTA

Gradução:

• Bacharelado em Ciências da Computação – UVA

Pós-Graduação:

• Especialização em Engenharia de Software – INTA

• Mestrado Acadêmico em Ciências da Computação – UECE (em andamento)

Atividades Profissionais

• Prof. Instituto Federal de Educação, Ciência e Tecnologia – IFCE (atual)

• Prof. Universidade Estadual Vale do Acaraú – UVA, Campus Aracati (atual)

• Analista de Sistemas no Instituto Altântico

• Prof. Faculdade IEducare (FIED)

• Prof. Instituto de Pesquisa Vale do Acaraú (IVA)

Títulos

• Certificações SCJP e CBTS

Apresentação

2Verificação, Validação e Teste de Software.

Prof.: Raquel Silveira

Introdução ao Processo de Teste

Processo de Software

- Sequência de práticas que objetiva odesenvolvimento ou a evolução de sistemas desoftware.

- Estas práticas englobam as atividades deespecificação, projeto, implementação, TESTESe caracterizam-se pela interação deferramentas, pessoas e métodos.



Processo de Teste

“Teste é um processo de avaliar um sistema ouum componente de um sistema para verificarse ele satisfaz os requisitos especificados ouidentificar diferenças entre resultadosesperados e obtidos.”




• Testes realizados por desenvolvedores tendem aidentificar menos problemas

• Testes deve um processo paralelo ao desenvolvimento

• Testar software não é uma tarefa simples

• Erros nem sempre são óbvios

• Erros diferentes podem ter a mesma manifestação

• Saber que um programa não está correto nãonecessariamente é saber como corrigir o erro




•Pré-conceitos

– O testador é um inimigo do desenvolvedor.

– A equipe de testes pode ser montada com osdesenvolvedores menos qualificados, pois qualquerum pode testar sistemas.

– Quando estiver tudo pronto, o software seguirápara o pessoal fazer o teste.




02/07/2011

2

Objetivos dos Testes- Encontrar o maior número possível de defeitos no

software.

- Os documentos básicos para definir os objetivos dostestes são os requisitos do negócio.

- A prática de gerar requisitos de testes a partir dosrequisitos de negócio facilita de modo consideráveltraças objetivos capazes de cobrir todas as necessidadesdos usuários.




Objetivo 1. Identificar a magnitude e origem dosriscos associados ao desenvolvimento desoftware, minimizáveis por testes.–Riscos são identificados em todo tipo de projeto.

–Testes podem mitigar riscos, não contigenciar!

Mitigar: atuar para prevenir a ocorrência do fato

Contigenciar: atuar após o fato para minimizarperdas.

Objetivos Principais



Objetivo 2. Executar testes para reduzir riscosidentificados.

–Testes positivos:

• Buscam cenários que funcionam como esperado.

–Testes negativos:

• Buscam cenários que “quebram” o software.

–Esforço planejado para testes

• Combinação de testes positivos e negativos.

• 100% de testes é irreal.




Objetivo 3. Determinar quando os testes estãocompletos.

–Nem 8 nem 80!

• Poucos testes causam incerteza.

• Testes demasiados custam mais caros.

–Testes positivos são os prioritários

• Envolvem o teste dos requisitos do projeto.

–Testes negativos em sequência

• De acordo com a priorização.




Objetivo 4. Gerenciar testes assim como qualqueroutra disciplina de Engenharia de Software.

–Planejar, acompanhar, formar equipe, gerenciar osrecursos.

• Também para testes? Por quê?

–Testadores são escassos

• Assim como desenvolvedores.

• Alocação dos recursos de testes deve sergerenciada com a mesma importância dosrecursos de desenvolvimento.




Problema do Ano 2000 (Y2K Bug)•Anos: ..., 19 98, 19 99, 19 00 ??•Testes começaram a ser levados a sério por conta

da ameaça do Y2K.•Como garantir que após as correções de datas,

tudo ficaria funcionando corretamente?

•Vocês sabem do bug do ano 2038?O último registro de tempo que pode ser

representado, seguindo o padrão POSIX, é03:14:07 na terça-feira 19 de janeiro de 2038.

Problemas Conhecidos



02/07/2011

3

Qual a proporção de testes nos projetos?

Fred BrooksTrabalhou na IBM, no desenvolvimento do OS/360

Scott BerkunTrabalhou na Microsoft, no desenvolvimento deWindows, MSN e Internet Explorer.

Qual a proporção que eles sugerem?

Break!



Qual a proporção de testes nos projetos?

• Fred Brooks (IBM / 1975)1/3 de planejamento

1/6 de codificação

1/4 de testes

• Scott Berkun (MS / 2005)1/3 de projeto e gerenciamento

1/3 de implementação

1/3 de testes

Break!



Lista elaborada por Everett & McLeod Jr.

1. Riscos de negócio podem ser reduzidos com testes.

2. Testes positivos e negativos contribuem com aredução de riscos.

3. “Testes estáticos” contribuem com testes.

4. Ferramentas de testes automatizados podemcontribuir com redução de riscos.

5. Faça com que os mais altos riscos sejam a primeiraprioridade de testes.

Princípios



6. Faça com que os cenários de negócio maisfreqüentes sejam a segunda prioridade de testes.

7. Análise estatística de padrões e características dedefeitos pode ajudar na estimativa do esforço deteste.

8. Realize os testes do sistema da mesma forma como ousuários irão usá-lo.

9. Assuma que defeitos são resultado de um processo, e não da personalidade dos envolvidos.

10. Realizar teste para identificar defeitos é uminvestimento assim com um custo.

Princípios



• “Testar é caro”– Comparado com o quê?

• Qual é o custo de NÃO testar?– Incerteza sobre cobertura (fiz tudo?)

– Incerteza sobre qualidade (o que fiz está correto?)

• Qual é o custo de encontrar falhasposteriormente?– Desgaste do relacionamento com clientes.

– Má impressão dos usuários.

– Remontagem do time de projeto.

Aspectos Econômicos



• Software falho custa mais para usar

– Usuários terão dificuldade de entendimento(comportamento inconsistente).

– Usuários cometerão mais erros.

• Software falho diminui motivação

– Moral é atingida.

– Produtividade piora.

– Melhor para o time é receber feedbackprontamente e não de forma tardia!




02/07/2011

4

• Vamos fazer as contas– Um erro foi encontrado por um usuário no ambiente de

produção.– Então, qual é o caminho a ser feito para corrigir o problema e

disponibilizar uma nova versão do sistema?

1. Usuário entra em contato (fone, email, carta, fax, tíqueteaberto em sistema de solicitações, etc) e informa o erro.

2. Analista reproduz o erro no ambiente de produção, einforma equipe de desenvolvimento.

3. Desenvolvedor reproduz o erro e encontra a falha.4. Desenvolvedor corrige a falha (em geral a parte mais

rápida).5. Equipe de desenvolvimento disponibiliza nova versão do

sistema.6. Versão do sistema em produção é trocada.7. Usuário consegue utilizar a funcionalidade corretamente

agora...... mas então detecta outro problema!




Qual é o custo de encontrar falhas posteriormente?

O custo de correção dos defeitos encontrados durante aprodução tende a aumentar quanto mais tarde o defeito édetectado.


0

2000

4000

6000

8000

10000

12000

Requisitos Designer Implementação Teste Produção

Regra 10 de Myers



Maximizar valor de negócio

• Testes podem (e devem) ser organizados paramaximizar valor.

•Testes diminuem custos de manutenção.

•Testes diminuem custos de atualização.

•Alinhamento com missão do projeto.

•“20% das funcionalidades agregam 80% do valor.”

Valor de Negócio



•Os softwares devem atender a certos atributos dequalidade e, para isso, precisamos identificar seusobjetivos ou requisitos de qualidade.

•Uma metodologia de qualidade muito usada nomercado é o FURPS.

Atributos de Qualidade

UsabilidadeUsability

ConfiabilidadeReliabilityDesempenho

Perfomance

SuportabilidadeSupportability

FuncionalidadeFunctionality

FURPS



Exercício Rápido

Para cada projeto distribuir 10 fichas entre opções detestes: Funcionalidade, Usabilidade, Confiabilidade,Desempenho e Suportabilidade.


Projeto 1. POS para Operadora de Cartão de Crédito

Projeto 2. Aplicação de Chat para Dispositivos Móveis



Atributos de qualidade

Execução



02/07/2011

5

Funcionalidade

De acordo com a especificação funcional.

- Teste funcional

- Teste de regressão

- Teste de volume




Usabilidade

Facilidade de uso do sistema pelos usuários.

- Teste de interface;

- Teste de usabilidade.




Confiabilidade

Confiabilidade do sistema, a permanência deoperação, a integridade dos dados, aconfiabilidade da estrutura e da aplicação.

- Teste de estrutura

- Teste de estresse




Desempenho

Velocidade de processamento da informação.

- Teste de avaliação de desempenho oubenchmark

- Teste de contenção

- Perfil de desempenho




Suportabilidade

Capacidade do programa de funcionar emdiversos ambientes diferentes.

- Teste de instalação

- Teste de configuração




Exercício Rápido

Um software foi entregue ao cliente e o cliente solicitauma nova modificação. A equipe do desenvolvimentoelabora uma nova release contendo a modificaçãosolicitada, antes de entregar o software é necessária arealização de testes? Qual(is) o(s) tipo(s) de teste deveser realizado nesta situação?




02/07/2011

6

Garantia de Qualidade versus Controle de Qualidade

Garantia de Qualidade: Um processo que assegura queo produto foi produzido conforme os processosorganizacionais.

Controle de Qualidade: Um processo que assegura queo produto funcione conforme os requisitos.




Verificação = Validação ?

Modelo em V



Verificação• Processo de avaliação de um sistema ou

componente para determinar se os artefatosproduzidos satisfazem às especificaçõesdeterminadas.

• “Estamos construindo o produto corretamente?”

Validação• Processo de avaliação para determinar se o

sistema atende as necessidades e requisitos dosusuários.

• “Estamos construindo o produto certo?”

Modelo em V



Modelo em V

Análise de Requisitos

Projeto de Sistema

Projeto de Arquitetura

Projeto de Módulos

Construção

Teste de Unidade

Teste de Componente

Teste Sistêmico

Teste de Aceitação

Modelo em V

Validação(Controle de Qualidade)

Verificação(Garantia de Qualidade)



Modelo em V


Projeto de Sistema


Projeto de Módulos

Construção

Teste de Unidade

Teste de Componente

Teste Sistêmico


Modelo em V

Validação(Controle de Qualidade)

Verificação(Garantia de Qualidade)

Revisão técnica



Modelo em V


Projeto de Sistema


Projeto de Módulos

Construção

Modelo em V

Projeto do Teste de Aceitação

Projeto do Teste Sistêmico

Projeto do Teste de Integração

Projeto do Teste de Unidade

Projeto Prematuro de

Testes



02/07/2011

7

Modelo em V



Modelo em V


Projeto de Sistema


Projeto de Módulos

Construção

Teste de Unidade

Teste de Componente

Teste Sistêmico


Modelo em V

Projeto do Teste de Aceitação

Projeto do Teste Sistêmico

Projeto do Teste de Integração

Projeto do Teste de Unidade



Modelo de integração entre os processos de desenvolvimento e teste


TESTE

Especificação

Execução (1)

Execução (2)

Entrega

DESENVOLVIMENTO

Desenho lógico e físico

Construção

Implantação

Entrega

Verificação

Teste unitário

Teste de integração e Teste de sistema

Teste de aceitação



Revisões de código: Podem reduzir 20% a 30%dos defeitos.

Testes unitários: Podem reduzir 30% a 50% dosdefeitos dos programas.

Testes de sistemas: Podem reduzir 30% a 50%dos defeitos remanescentes.




Projeto prematuro dos testes

– Ao projetar testes, problemas são encontrados.

– Problemas encontrados cedo são mais baratos decorrigir.

– Problemas mais significativos são encontradosprimeiro.

• Então que tal verificar logo?

– Projeto de testes pode impactar os requisitos.

Modelo em V



Ciclo de Vida do Processo de Teste



02/07/2011

8

Ciclo de Vida do Processo de Teste



Antes de planejar

– Defina a estratégia de teste da organização (ou donegócio).

– Identifique as pessoas a serem envolvidas.

–Examine os requisitos e/ou especificaçõesfuncionais (artefatos de entrada para os testes).

– Estabeleça a organização e a infra-estrutura doambiente de testes.

– Defina quais serão os entregáveis e a estrutura dosrelatórios.

Planejamento



Por que o Plano de Teste é importante?

- O Plano de Teste é uma maneira de documentar oprojeto de testes.

- Guia para orientar nos seguintes aspectos:

- Repetição

- Controle

- Cobertura

Planejamento



Plano de Testes

1. Introdução

- Itens de software e funcionalidades a serem testadas.

- Referências a plano de projeto, plano de QA, políticas epadrões organizacionais, plano de configuração.

2. Itens de teste

- Listagem de itens de teste (versões ou revisões desistemas, fases de desenvolvimento).

- Como o sistema chega aos testadores (DVD, Internet,Intranet, Repositório do projeto)

- Referências a documentação ou outros tipos demateriais de apoio.

Planejamento



Plano de Testes

3. Escopo

- Identificar especificações funcionais

4. Não escopo

- Razões para exclusão

5. Abordagem

- Técnicas e ferramentas

- Identificar o grau de cobertura e outros critérios.

- Identificar restrições de ambiente, recursoshumanos, prazos.

Planejamento



Plano de Testes

6. Critérios de execução

- Definição de “sucesso”.

- Definição de “falha”.

7. Critérios de interrupção e continuação

- Interrupção: Caso a condição seja satisfeita, ostestes (ou parte deles) devem ser interrompidos.

- Continuação: sanada a condição de interrupção,quais atividades precisam ser re-feitas antes deretomar as atividades interrompidas.

Planejamento



02/07/2011

9

Plano de Testes

8. Entregáveis

- Plano de Testes.

- Especificações de testes.

- Relatórios.

9. Ambiente de teste

- Espaço físico, equipamentos (hardware).

- Ferramentas de software.

Planejamento



Plano de Testes

10. Papéis e responsabilidades

- Gestão

- Projeto

- Especificação

- Execução

- Registro

- Validação

- Resolução de problemas

- Fornecimento de produtos para os testes

Planejamento



Planejamento

Dimensões do teste

2ª

1ª

3ª

Tipo de teste(O que testar)

Estágio ou níveis de teste(Quando testar)

Técnica de Teste(Como testar)

Funcional

Estrutural

Teste de unidadeTeste de integraçãoTeste de sistemaTeste de aceitação

Teste de funcionalidadeTeste de interfaceTeste de desempenhoTeste de usabilidadeTeste de volume ...



Exercício rápido

Como você testaria uma calculadora?

Elaboração



-Um dos documentos contidos na fase deElaboração é a Especificação de Caso de Teste.

Este documento deve conter: Identificação das condições do teste (pré e pós

condições)

Identificação dos casos de teste (o que testar)

Detalhamento da massa de entrada

Especificação das configurações de ambiente

Definir o tipo de implementação (automática oumanual)

Elaboração



Exemplo de elaboração de caso de teste

Especificação do sistema: Autenticação de Usuário.

Elaboração

Efetuar o login na aplicação com um login válido e senha de, no mínimo 6 (seis) caracteres.

Autenticação

Login

Senha

Esqueceu a senha?

OK LIMPAR



02/07/2011

10


Do requisito do cliente, podemos criar asseguintes idéias de teste:

Elaboração




Elaboração

Título: Senha Inválida

Ambiente: Windows XP

Pré-Condições:- Possuir um usuário válido.

Passo Resultado Esperado

1. O usuário inicia a aplicação.

2. O usuário preenche os campos Login e Senha conforme as idéias de teste.

Verificar se os campos sãopreenchidos corretamente.

3. O usuário seleciona Efetuar Login. Verificar se quando o usuárioinforma uma senha menor que 6 caracteres, o sistema exibe a mensagem: “Senha inválida.”.

4. O usuário confirma a mensagem.



Exercício rápido

Em uma operação de Saque, quais casos de testespoderiam ser identificados? Como seria odetalhamento de um desses casos de teste?

Elaboração



Revisão Técnica

Objetivo

Prevenir defeitos no produto final.

Porquê?

Removem defeitos do produto em todo o ciclode vida.

Como?

Encontrando defeitos em produtosintermediários.

Execução



Revisão Técnica

• Requisitos

- Requisitos funcionais e não funcionais.

- Casos de uso.

•Análise e Projeto

•Código

- Análise Automatizada

- Técnicas

Execução



Revisão Técnica – Requisitos

• Workshop de Requisitos

- Apresentação do escopo e não-escopo do projeto para interessados

- Trabalho preliminar de modelagem das necessidades

- Requisitos

- Caso de uso

- Não Escopo

- Restrições

- Premissas

- Técnica barata, e pode ser realizada em vários ciclos

- Gera comprometimento dos participantes da reunião

Execução



02/07/2011

11

Revisão Técnica – Arquitetura

• Arquitetura é importante

– Então deve ser analisada

• Arquitetura é caro de se mudar

– É mais barato analisar cedo

• Arquitetura afeta o projeto inteiro

– Pessoas interessadas precisam ser envolvidas.

• Requisitos podem ser elicitados cedo

– Arquitetura precisa ser desenhada alinhada com estes.

Execução



Revisão Técnica –Código

• Análise estática de código

– FindBugs, FxCop

• Grande base de anti-padrões

• Personalizáveis: crie suas próprias regras para padrões próprios.

• Inspeção manual

– Inspeção

– Revisão por Par

Execução



Revisão Técnica – Código

• Inspeção

Execução



Revisão Técnica – Código• Revisão por Par

- Dois envolvidos somente:- Autor e Revisor

• Processo simples:1 – Autor prepara artefato e envia para Revisor2 – Revisor realiza revisão invidualmente3 – Revisor registra problemas

( Email, ferramenta própria, post-it, ...)4 – Autor corrige problemas5 – Revisor verifica correções6 – Pronto!

• E se... autor e revisor discordarem?- Bom, deve ter um líder ou gerente nesse projeto, ok?- Não tem mágica, escala o conflito (assim como qualquer outro)

Execução



Revisão Técnica – Código• O que procurar?

– O código executa corretamente os fluxos básicosassociados?

– O código executa corretamente os fluxos alternativosassociados?

• Outros aspectos– Cumpre padrões de arquitetura (e.g. MVC)?– Trechos complexos estão comentados? (análise estática

ajuda aqui)– Testes unitários estão feitos?– Documentação/legibilidade estão boas?– Tratamento de erros foi realizado corretamente?– ...

Execução



Execução

Categorias de teste

Teste de caixa branca (White box)

Teste de caixa preta (Black box)



02/07/2011

12

Execução

Teste de Caixa Branca

Testes de unidade de código;

Testam parte da solução;

São escritos e mantidos pelo programador e devem estar sempre atualizados.



Execução

Teste de Caixa Branca

Quando construímos um teste de unidade, oprincipal desafio é isolar a classe ou trecho decódigo que está sendo testado, para quenenhuma outra classe do sistema seja envolvidano teste e influencie no resultado esperado.



Execução

Cobertura dos testes

Dificilmente consegue-se 100% de coberturade testes.

Quanto maior cobertura dos testes naaplicação, maior a confiabilidade nas alteraçõese novos recursos.



Execução

Cobertura dos testes

Aplicações cobertas por bons testes propiciam:-Facilidade de manutenção;

- Menos problemas e relação de custos emmanutenção.



Execução

Testes de caixa preta

Baseado no executável dosistema/componente.

Testes funcionais;

Testes de aceitação;



Análise estática e análise dinâmicaEstática

Compreende métodos usados paradeterminar ou estimar qualidade de software, quenão envolvem a execução do produto.

DinâmicaCompreende métodos que envolvem

execução do produto, com dados reais e ambientereal ou simulado.

Execução



02/07/2011

13

Tipos de Testes

Testes Unitários

Testes de Integração

Testes Sistêmicos

Testes de Aceitação

Execução



Testes Unitários

• Baixo nível

– Feito por programadores

– Mais foco nos detalhes

• Tratamento de erros

• Completude e corretude de interfaces

– Níveis

• Módulos

• Componentes

• Classes\arquivos

Execução



Testes Unitários

Execução

Teste Unitário



Testes Unitários

- Planejamento

- Como a estratégia eprojeto de teste se aplicaa unidade a ser testada?

- Identificar outroscomponentes de softwareque estarão interagindocom a unidade).

Execução

Teste Unitário



Testes Unitários

- Especificação

- Caso de teste: Objetivo,Estado inicial, Entrada,Resultado esperado.

- Testes precisam serrepetíveis.

Execução

Teste Unitário



Testes Unitários

- Execução

- Casos de testes sãoexecutados.

- Manuais e/ouAutomatizados.

- Definição de cobertura.

- 100% de cobertura éimpraticável.

Execução

Teste Unitário



02/07/2011

14

Testes Unitários

- Registro

- Identificação dasunidades testadas.

- Resultados gerados,comparados comresultados esperados.

- Falhas/erros sãoregistrados e informados.

- Verificar critérios decobertura do projeto.

Execução

Teste Unitário



Testes Unitários

- Verificação decompletude

- Avaliação dos resultadoscomparados com oscritérios de completude.

- Se não atingir...

- re-análise se é preciso mais

Execução

Teste Unitário




- Importante em sistemas modularizados

- Os módulos funcionam corretamente juntos?

- Foco

- Comunicação entre casos de usos.

- Comunicação entre classes.

- Planejamento da integração está intimamenteatrelado ao desenho da arquitetura e das fases doprojeto.

- Estratégia:

- Big-bang ou Incremental

Execução




- Big-Bang

- Na teoria:

- Se eu já testei as unidades isoladamente, porque eunão junto tudo de uma só vez? Vou ganhar tempo!

- Onde está o erro aqui?

- Assumiu que não existem defeitos...

- Na prática

- Fica difícil isolar defeitos (qual unidade falhou?)

- Fica difícil re-testar após correções

- No final, leva mais tempo.

Execução




- Incremental

- Componentes / Módulos são combinados aospoucos

- Baseline 1: Componete A

- Baseline 2: Componente A e C

- Baseline 3: Componente A, B e C

- Vantagens:

- Mais fácil de isolar problemas.

- Mais fácil de re-testar correções.

Execução



Testes Sistêmicos - Funcionais- Testes projetados de acordo com a documentação de

cenários de uso existente- Casos de uso

- Executado por grupo independente!

- Primeiro passo- Rascunhar um caso de teste para os cenário principal e

alternativos

- Segundo passo- Inserir detalhes como intervalos, regras de negócio, valores de

validação

- Na hora de executar- Seguir o roteiro que é definido nos casos de testes.

Execução



02/07/2011

15

Testes Sistêmicos

- Tentem a próxima coisa!

- Quando estiver testando, não pare, não retorne aocomeço ...

- ... Faça o que o usuário fará em seguida!

- Exemplo:

- Tela de modificação de senha.

Execução



Testes Sistêmicos – Não Funcionais

- Desempenho:

- Grande massa de dados ou usuários

- Picos de utilização ou acesso

- Robustez:

- Sistema não pára de funcionar ao longo do tempo

- Ex.: Impressoras fiscais, sites de comércio eletrônico

- Segurança:

- Importante para sistemas com dados sensíveis

- Não envolve só infra-estrutura

Execução



Testes Sistêmicos – Não Funcionais- Usabilidade:

- Verifica se a interface é fácil de usar e intuitiva

- Quase sempre subjetivo, por isso deve envolver ousuário sempre que possível

- Pode ser objetivo também:- Exemplo: 1-buy click da Amazon

- Navegação por teclado

- Acessibilidade

- Internacionalização:- Sistema precisa trabalhar com múltiplas línguas

- Vai testar só com o português ou inglês?

- Os textos cabem nos espaços da interface?

Execução



Testes Sistêmicos – Priorização

•Está acabando o tempo, o que priorizo?

•Testes positivos–Verifique até onde já foram realizados os testes

–Do que sobrou, o que agrega mais ao cliente?

–Testes positivos abrangem as funcionalidades quemais agregam ao cliente

•Testes negativos–Verifique até onde já foram realizados os testes

–Qual o tipo de erro mais recorrente?

–Ataque os erros mais comuns

Execução



Testes de Aceitação

•Teste realizado pelos usuários.

•Garantir que tudo o que foi definido nosrequisitos tenha sido incluído no produto.

•Em alguns casos, os testadores auxiliam osusuários a executar essa atividade.

Execução



Processo de Teste



Testes de ValidaçãoTestes de Verificação

Espeficicação de Requisitos

Verificação de Requisitos

Modelagem do Software

Verificação da Modelagem

Codificação

Verificação do Código

Unidade Desenvolvida

Validação da Unidade

Unidades Finalizadas

Validação da Integração

CAIXA BRANCA

REVISÕES

Software Finalizado

Validação do Sistema

Software Finalizado

Validação / Aceite

CAIXA PRETA

02/07/2011

16

Caso ocorra algum erro, reportamos um defeito com osseguintes dados:

Sumário

Passo para reprodução

Severidade

Ambiente

Além de registrar os problemas, ao final de cada fase énecessário realizar um relatório sumarizando a quantidadede problemas identificados e verificar a necessidade de umreteste.

Registro dos Problemas Identificados no Teste



Descrição:Montar um Plano de Teste para os seguintes

sistemas:1. Sistema de Controle Acadêmico2. Sistema de Controle de Estoque3. Sistema de Locação de Automóveis4. Sistema de Clínica Odontológica5. Sistema de Transação Monetária

Itens do Plano de Teste: 1. Introdução, 2. Itens de teste, 3. Escopo, 4.Não escopo, 5. Abordagem, 6. Critérios de execução, 7. Critérios deinterrupção e continuação, 8. Entregáveis, 9. Ambiente de Teste, 10.Papéis e Responsabilidades.

Trabalho da Disciplina



Verificação, Validação e Teste de Software · •Certificações SCJP e CBTS Apresentação 2...

Documents

Transcript of Verificação, Validação e Teste de Software · •Certificações SCJP e CBTS Apresentação 2...