Plano de Teste

1. Objetivos

1.1 Objetivo

Este documento descreve o plano para testar o protótipo de arquitetura do C-Registration System. Este
documento de Plano de Teste suporta os seguintes objetivos:

 Identificar informações existentes do projeto e o software que deve ser testado.

 Listar os requisitos de teste recomendados (nível alto).
 Recomendar e descrever as estratégias de teste a serem empregadas.
 Identificar os recursos requeridos e fornecer uma estimativa dos esforços de
teste.
 Listar os elementos de produto de trabalho das tarefas de teste.

1.2 Escopo

Este Plano de Teste descreve os testes de integração e do sistema que serão conduzidos no protótipo de
arquitetura após a integração dos subsistemas e componentes identificados no Plano de Integração da
Construção para o Protótipo.

Assume-se que o teste de unidade já forneceu por meio de teste de caixa preta, uma cobertura extensiva
do código fonte e o teste de todas as interfaces do módulo.

O objetivo da montagem do protótipo de arquitetura era testar a possibilidade e o desempenho da

arquitetura selecionada. É crítico que todas as interfaces do sistema e do subsistema sejam testadas, bem
como o desempenho do sistema nesse estágio antecipado. O teste dos recursos e da funcionalidade do
sistema não será conduzido no protótipo.

As interfaces entre os seguintes subsistemas serão testadas:

0. Registro em Curso
1. Sistema Financeiro
2. Catálogo de Cursos.

As interfaces externas para os seguintes dispositivos serão testadas:

0. PCs locais
1. PCs remotos.

As medidas de desempenho mais críticas a testar são:

0. Tempo de resposta para login remoto no sistema de registro em cursos.

1. Tempo de resposta para acesso ao Sistema Financeiro.
2. Tempo de resposta para acesso ao Sistema de Catálogo de Cursos.
3. Tempo de resposta do estudante quando o sistema está carregado com 200
estudantes com login efetuado.
4. Tempo de resposta do estudante quando existem 50 acessos simultâneos ao
banco de dados do Catálogo de Cursos.

1.3 Referências

As referências aplicáveis são:

DOCUMENTAÇÃO DOS SISTEMAS A SEREM TESTADOS!!!

 0. Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
1. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie
College IT.
2. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.

2.    Requisitos para o Teste 

A lista a seguir identifica os itens que foram identificados como alvos do teste. Essa lista
representa o que será testado.

2.1 Teste de Integridade dos Dados e do Banco de Dados

Verificar acesso ao Banco de Dados do Catálogo de Cursos.

Verificar acessos de leitura simultâneos ao registro.

Verificar interrupção durante atualizações do Catálogo de Cursos.

Verificar a recuperação correta de atualizações dos dados do banco de dados.

2.2. Teste de Função

PONTOS DEFINIDOS NO LEVANTAMENTO DE REQUISITOS!!!

Documento de Visão, seção 12.2: "O sistema deve fazer interface com o Sistema de
Banco de Dados de Catálogo de Cursos existente. O C-Registration deve suportar o
formato de dados conforme definido em [2]."

Especificação Complementar, seção 9.3: "O componente servidor do sistema deve

operar no Servidor UNIX do Wylie College."

2.3 Teste de Interface com o Usuário

Verificar a facilidade de navegação utilizando um conjunto de amostras de telas.

Verificar se as telas de amostra estão em conformidade com os padrões da GUI.

Documento de Visão, seção 10: "O Sistema deve ter fácil utilização e deve ser
apropriado para o mercado de destino de estudantes e professores com experiência
em computadores."

Documento de Visão, seção 12.1: "A interface com o usuário de desktop deve estar
em conformidade com o Windows 95/98."

Especificação Complementar, seção 5.1: "A interface com o usuário de desktop deve
estar em conformidade com o Windows 95/98."

Especificação Complementar, seção 5.2: "A interface com o usuário do C-Registration

System deverá ser projetada para facilidade de utilização e deverá ser apropriada
 para uma comunidade de usuários experiente com computadores, sem treinamento
adicional no Sistema."

2.4 Teste de Desempenho

Verificar o tempo de resposta para acesso ao sistema Financeiro externo.

Verificar o tempo de resposta para acesso ao subsistema Catálogo de Cursos

externo.

Verificar o tempo de resposta para login remoto.

Verificar o tempo de resposta para a submissão remota de registro em curso.

Documento de Visão, seção 12.3: "O sistema deverá fornecer acesso ao Banco de
Dados de Catálogo de Cursos legado com um tempo de espera de no máximo 10
segundos."

Especificação Complementar, seção 7.2: "O sistema deverá fornecer acesso ao

Banco de Dados de Catálogo de Cursos legado com um tempo de espera de no
máximo 10 segundos."

2.5 Teste de Carga

Verificar a resposta do sistema quando estiver carregado com 200 estudantes com
logon efetuado.

Verificar a resposta do sistema quando existir 50 acessos simultâneos de estudantes

ao Catálogo de Cursos.

2.6 Teste de Estresse

EX:

Teste de stress é realizado para submeter o software a situações extremas. Basicamente, o

teste de stress baseia-se em testar os limites do software e avaliar seu comportamento.
Assim, avalia-se até quando o software pode ser exigido e quais as falhas (se existirem)
decorrentes do teste.
Os testes de stress são fundamentais em aplicações em que a eficiência seja uma
característica importante. Por exemplo:

 Servidores de arquivos e servidores web, que devem atender a solicitações de

um grande número de clientes;
 Aplicações industriais, tais como o controle de uma refinaria de petróleo;
 Jogos de computador, que precisam de um desempenho aceitável para serem
viáveis comercialmente.

2.7 Teste de Volume

 EX:

O Teste de Volume é um tipo de teste de software realizado para testar um aplicativo de software com
uma determinada quantidade de dados.

O Teste de Volume também é conhecido como Teste de Inundação .

Características do Teste de Volume: A

seguir estão as características do Teste de Volume:

 O desempenho do software diminui com o passar do tempo, pois há uma grande quantidade de
dados extras.
 Basicamente, os dados de teste são criados pelo gerador de dados de teste.
 Apenas uma pequena quantidade de dados é testada durante a fase de desenvolvimento.
 Os dados de teste precisam estar logicamente corretos.
 Os dados de teste são usados para avaliar o desempenho do sistema.

Objetivos do teste de volume:

Os objetivos do teste de volume são:

 Para reconhecer os problemas que podem ser criados com grande quantidade de dados.
 Para verificar o desempenho do sistema, aumentando o volume de dados no banco de dados.
 Para encontrar o ponto em que a estabilidade do sistema diminui.
 Para identificar a capacidade do sistema ou aplicativo.

2.8 Teste de Segurança e Controle de Acesso

Verificar o Logon a partir de um PC local.

Verificar o Logon a partir de um PC remoto.

Verificar a segurança de Logon por meio de mecanismos de nome de usuário e

senha.

2.9 Teste de Configuração

Documento de Visão, seção 12.2: "O componente do cliente do sistema deve ser
executado no Windows 95, no Windows 98 e no Microsoft Windows NT."

Especificação Complementar, Seção 9.4: "A interface baseada na Web do C-

Registration System deve ser executada nos navegadores Netscape 4.04 e Internet
Explorer 4.0.

Especificação Complementar, Seção 9.5: "A interface baseada na Web deve ser
compatível com o ambiente de tempo de execução Java 1.1 VM.

3.    Estratégia do Teste
 A Estratégia de Teste apresenta a abordagem recomendada para o teste dos aplicativos de
software. A seção anterior dos Requisitos de Teste descrevia o que será testado; esta
descreve como será testado.

As principais considerações para a estratégia de teste são as técnicas a serem utilizadas e o

critério para saber quando o teste está concluído.

3.1 Tipos de Teste

3.1.1 Teste de Integridade dos Dados e do Banco de Dados

Os bancos de dados e os processos de banco de dados devem ser testados como sistemas separados.

Objetivo do Teste: Assegurar que os processos e métodos de acesso ao Banco de

Dados funcionem corretamente e sem corrupção de dados.

Técnica:  Chamar cada processo e método de acesso a banco

de dados, propagando cada um com dados válidos e
inválidos (ou pedidos de dados).
 Inspecionar o banco de dados para assegurar que os
dados foram preenchidos conforme planejado e que
todos os eventos do banco de dados ocorreram
adequadamente ou revisar os dados retornados para
assegurar que os dados corretos foram recuperados.

Critérios de Conclusão: Todos os processos e métodos de acesso ao banco de dados

funcionam conforme projetado e sem nenhuma corrupção de dados.

3.1.2 Teste de Função

Os testes do aplicativo devem ter foco em quaisquer requisitos de casos de uso e regras de negócios.
Esse tipo de teste baseia-se em técnicas de caixa preta, ou seja, verificar o aplicativo (e seus processos
internos) interagindo com o aplicativo por meio da GUI e analisar a saída (resultados).

Objetivo do Teste: Assegurar a navegação correta do aplicativo, além da entrada,

processamento e saída de dados.

Técnica:  Executar cada caso de uso, fluxo de caso de uso ou

função, utilizando dados válidos e inválidos, para
verificar o seguinte:
 Os resultados esperados ocorrerão quando forem
usados dados válidos.
 As mensagens de erro / aviso apropriadas sejam
exibidas quando dados inválidos forem utilizados.
 Critérios de Conclusão:  Todos os testes planejados foram executados.
 Todos os defeitos identificados foram tratados.

 
3.1.3 Teste da Interface com o Usuário

O teste da Interface com o Usuário verifica a interação de um usuário com o software. A meta do Teste de
UI é assegurar que a Interface com o Usuário forneça ao usuário o acesso e a navegação adequados por
meio das funções dos aplicativos.

Objetivo do Teste: Objetos e características da janela, tais como menus,

tamanho, posição, estado e foco estão em
conformidade com os padrões.

Técnica:  Criar / modificar testes para cada janela a fim de

verificar a navegação adequada.

Critérios de Conclusão: Verificação com êxito de cada janela permanecer consistente com o
benchmark ou dentro do padrão aceitável de layout.
 

3.1.4 Teste de Desempenho

O teste de desempenho mede tempos de resposta, taxas de transação e outros requisitos sensíveis ao
tempo. A meta do teste de Desempenho é verificar e validar se os requisitos de desempenho foram
alcançados.

Objetivo do Teste: Validar o Tempo de Resposta do Sistema para funções de negócios

ou transações.

Técnica:  Utilizar Scripts de Teste desenvolvidos para testar o

Modelo de Negócio (Teste do Sistema).

 Os scripts devem ser executados em uma máquina (o

melhor é avaliar o desempenho de um único usuário,
uma única transação) e repetidos com vários clientes
(virtuais ou reais).

Critérios de Conclusão:  Transação Única / usuário único: Conclusão com êxito

dos scripts de teste sem nenhum defeito e na alocação
de tempo esperada.
  Várias Transações / vários usuários: Conclusão com
êxito dos scripts de teste sem nenhum defeito e dentro
de alocação de tempo aceitável.

3.1.5 Teste de Carga

As medidas do teste de carga sujeitam o sistema em teste a cargas de trabalho variáveis para avaliar a
capacidade do sistema em continuar a funcionar corretamente sob essas diferentes cargas de trabalho. A
meta desse teste de carga é determinar e assegurar que o sistema funcione adequadamente com uma
carga de trabalho superior à carga máxima esperada. Além disso, o teste de carga avalia as características
de desempenho (tempos de resposta, taxas de transação e outros aspectos sensíveis ao tempo).

Objetivo do Teste: Verificar o Tempo de Resposta do Sistema para casos de negócios

ou transações designadas sob condições de carga de trabalho
variáveis.

Técnica:  Utilizar os testes desenvolvidos para o Teste do

Negócio.

 Modificar os arquivos de dados (a fim de aumentar o

número de transações) ou os testes a fim de aumentar
o número de vezes que cada transação ocorre.

Critérios de Conclusão:  Várias Transações / vários usuários: Conclusão com

êxito dos testes sem nenhum defeito e dentro de
alocação de tempo aceitável.

3.1.6 Teste de Estresse

Esta seção não é aplicável ao teste do protótipo de arquitetura.

3.1.7 Teste de Volume

Esta seção não é aplicável ao teste do protótipo de arquitetura.

3.1.8 Teste de Segurança e Controle de Acesso

O Teste de Segurança e de Controle de Acesso tem como foco duas áreas principais de segurança:

Segurança do aplicativo, incluindo o acesso aos Dados ou às Funções de Negócios.

Segurança do sistema, incluindo acesso remoto ao sistema.

A segurança do aplicativo assegura que, com base na segurança desejada, os usuários têm restrição a
funções específicas ou estão limitados aos dados que estão disponíveis a eles. Por exemplo, todos têm
permissão para inserir dados e criar novas contas, mas apenas os gerentes poderão excluí-los.

A segurança do sistema assegura que apenas os usuários, para os quais o acesso ao sistema foi
concedido, sejam capazes de acessar os aplicativos e apenas por meio dos gateways apropriados.

Objetivo do Teste: Segurança de Função / Dados: Verificar se o usuário pode acessar

apenas as funções / dados para os quais seu tipo de usuário tenha
recebido permissão.

Segurança do Sistema: Verificar se apenas os usuários com acesso

ao sistema e aplicativo(s) têm permissão para acessá-los.

Técnica:  Segurança de Função / Dados: Identificar e listar cada

tipo de usuário e as funções / dados para os quais
cada tipo tem permissão.

 Criar testes para cada tipo de usuário e verificar a

permissão criando transações específicas para cada
tipo de usuário.

 Modificar o tipo de usuário e executar novamente os

testes para os mesmos usuários. Em cada caso,
verificar se as funções / dados adicionais estão
corretamente disponíveis ou se têm seu acesso
negado.

Critérios de Conclusão: Para cada tipo de usuário conhecido, a função / dados apropriados
estão disponíveis e todas as transações funcionem como esperado
e sejam executadas.
 
3.1.9 Teste de Configuração

O teste de configuração verifica a operação do software em diferentes configurações de software e de

hardware. Na maior parte dos ambientes de produção, as especificações de hardware específicas para as
estações de trabalho cliente, as conexões de rede e os servidores de banco de dados variam. As estações
de trabalho cliente podem ter softwares diferentes carregados, como aplicativos, drivers etc.

Objetivo do Teste: Validar e verificar se os Aplicativos cliente funcionam corretamente

nas estações de trabalho cliente prescritas.

Técnica:  Utilizar scripts de Teste de Integração.

  Abrir / fechar diversos aplicativos do PC, como parte
do teste ou antes do início do teste.

 Executar transações selecionadas para simular

atividades do usuário para dentro e fora de diversos
aplicativos de PC.

Critérios de Conclusão: Para cada combinação do Protótipo e aplicativo de PC, as

transações são concluídas com êxito e sem falhas.