1. Objetivos
2. Requisitos para o Teste
3. Estratégia do Teste
4. Recursos
5. Marcos do Projeto
6. Produtos de Trabalho
7. Tarefas do Projeto

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.

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 [16].

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:

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

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

1. PCs locais
2. PCs remotos.

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

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

As referências aplicáveis são:

1. Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
2. Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
3. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
4. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
5. Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
6. Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
7. Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
8. Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
9. Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
10. Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
11. Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
12. Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
13. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
14. Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT.
15. Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
16. Course Registration System Integration Build Plan for the Architectural Prototype, WyIT430, V1.0, 1999, Wylie College IT.
17. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.

A lista a seguir identifica os itens (casos de uso, requisitos funcionais, requisitos não funcionais) que foram identificados como alvos do teste. Essa lista representa o que será testado.

(Nota: Um release futuro desse Plano de Teste pode utilizar o Rational RequisitePro para vincular diretamente aos requisitos nos Documentos de Caso de Uso e na Especificação Complementar.)

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

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]."

Documento de Visão, seção 12.2: "O sistema deve fazer interface com o Sistema de Faturamento existente e deve suportar o formato de dados conforme definido em [1]."

Documento de Visão, seção 12.2: "O componente servidor do sistema deve operar no Servidor do Campus da Universidade e deve ser executado no Sistema Operacional UNIX."

Especificação Complementar, seção 9.3: "O componente servidor do sistema deve operar no Servidor UNIX do Wylie College."

Documento de Visão, seção 12.2: "O componente do cliente do sistema deve operar em qualquer computador pessoal com um microprocessador 486 ou superior."

Especificação Complementar, seção 9.3: "O componente do cliente do sistema deve operar em qualquer computador pessoal com pelo menos um microprocessador 486."

Especificação Complementar, seção 9.1: "O sistema deve integrar-se ao sistema legado existente (banco de dados do catálogo de cursos) que opera no mainframe DEC VAX da Universidade."

Especificação Complementar, seção 9.2: "O sistema deve integrar-se ao Sistema de Faturamento de Cursos existente que opera no mainframe DEC VAX da Universidade."

2.3 Teste de Ciclo de Negócio

Nenhum.

2.4 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.5 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.6 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.7 Teste de Estresse

Nenhum.

2.8 Teste de Volume

Nenhum.

2.9 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.10 Teste de Failover / Recuperação

Nenhum.

2.11 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.

2.12 Teste de Instalação

Nenhum.

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.

Além das considerações fornecidas para cada teste a seguir, o teste deve ser executado apenas utilizando bancos de dados conhecidos e controlados, em ambientes protegidos.

A estratégia de teste a seguir é genérica por natureza e foi desenvolvida para ser aplicada aos requisitos listados na seção 4 deste documento.

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. Esses sistemas devem ser testados sem os aplicativos (como a interface para os dados). É necessário executar pesquisas adicionais referentes ao DBMS a fim de identificar as ferramentas / técnicas que poderão existir para suportar os testes identificados a seguir.

3.1.2 Teste de Função

Os testes do aplicativo devem ter foco em quaisquer requisitos de destino que possam ser rastreados diretamente para casos de uso (ou funções de negócios) e regras de negócios. A meta desse teste é verificar a adequada aceitação, o processamento e a recuperação dos dados, e a implementação apropriada das 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). A seguir é identificado um esboço do teste recomendado para cada aplicativo:

 

3.1.3 Teste de Ciclo de Negócio

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

3.1.4 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. Além disso, o Teste de UI assegura que os objetos contidos na UI funcionem conforme esperado e estejam em conformidade com padrões corporativos ou do segmento de mercado.

3.1.5 Traçado de Perfil 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. O teste de desempenho normalmente é executado várias vezes, cada uma utilizando uma "carga de segundo plano" diferente no sistema. O teste inicial deve ser executado com uma carga "nominal", semelhante à carga normal observada (ou prevista) no sistema de destino. Um segundo teste de desempenho é executado utilizando uma carga de pico.

Além disso, os testes de desempenho podem ser utilizados para traçar o perfil e ajustar o desempenho de um sistema como uma função de condições, como a carga de trabalho ou configurações de hardware.

NOTA: As transações a seguir se referem a "transações comerciais lógicas." Essas são transações são definidas como funções específicas que se espera que um usuário do sistema execute utilizando o aplicativo, como incluir ou modificar um determinado contrato.

3.1.6 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).

NOTA: As transações a seguir se referem a "transações comerciais lógicas." Essas são transações são definidas como funções específicas que se espera que um usuário do sistema execute utilizando o aplicativo, como incluir ou modificar um determinado contrato.

3.1.7 Teste de Estresse

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

3.1.8 Teste de Volume

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

3.1.9 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. Se houver segurança no nível dos dados, o teste assegura que o usuário "tipo" um pode consultar todas as informações do cliente, incluindo dados financeiros; no entanto, o usuário dois consulta apenas os dados demográficos para o mesmo cliente.

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.

3.1.10 Teste de Failover e Recuperação

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

3.1.11 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. A qualquer momento, muitas combinações diferentes podem estar ativas e utilizando recursos diferentes.

3.1.12 Teste de Instalação

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

3.2 Ferramentas

As seguintes ferramentas serão empregadas para o teste do protótipo de arquitetura:

4.    Recursos

Esta seção apresenta os recursos recomendados para o teste do protótipo de arquitetura do C-Registration, suas principais responsabilidades e seu conhecimento ou configuração de habilidades.

4.1 Funções

Esta tabela mostra as premissas de equipe para o teste do Protótipo.

 

4.2 Sistema

A tabela a seguir descreve os recursos do sistema para o teste do protótipo do C-Registration.

 5.    Marcos do Projeto

O teste do Protótipo de Arquitetura do C-Registration incorpora tarefas de teste para cada um dos esforços de teste identificados nas seções anteriores. Marcos do projeto separados são identificados para comunicar o status e as realizações do projeto.

Consulte o Plano de Desenvolvimento de Software [13] e o Plano de Iteração E1 [14] para obter o planejamento do projeto principal ou de fases gerais.

Tarefa de Marco	Esforço (pd)	Data de Início	Data de Encerramento
Planejamento de Teste do Protótipo	2	12 de março	15 de março
Design de Teste do Protótipo	3	15 de março	18 de março
Desenvolvimento de Teste do Protótipo	4	19 de março	23 de março
Execução de Teste do Protótipo	3	24 de março	26 de março
Avaliação de Teste do Protótipo	1	29 de março	29 de março

 

Os produtos de trabalho das tarefas de teste definidas neste Plano de Teste estão descritos na tabela a seguir.

Produtos de Trabalho	Proprietário	Revisão / Distribuição	Data Comprometida
Plano de Teste	K. Stone	Equipe de Gerenciamento de Projeto Sênior	15 de março
Ambiente de Teste	S. Jones	-	18 de março
Conjunto de Teste	C. Smith e M. Cox	Revisão por Profissional Interno	23 de março
Conjuntos de Dados de Teste	M. Cox	Revisão por Profissional Interno	23 de março
Scripts de Teste	M. Cox	-	23 de março
Stubs de Teste, Drivers	M. Cox	-	23 de março
Relatórios de Defeitos do Teste	C. Smith	Equipe de Gerenciamento de Projeto Sênior	26 de março
Resultados do Teste	C. Smith	-	26 de março
Relatório de Avaliação de Teste	C. Smith	Equipe de Gerenciamento de Projeto Sênior	29 de março

6.1 Conjunto de Teste

O Conjunto de Teste definirá todos os casos de teste e os scripts de teste associados a cada caso de teste.

6.2 Logs do Teste

Está planejada a utilização do RequisitePro para identificar os casos de teste e monitorar o status de cada um. Os resultados de teste serão resumidos no RequisitePro como não-testados, aprovados, aprovação condicional ou com falha. Resumindo, o RequisitePro será configurado para suportar os seguintes para cada caso de teste, conforme definido nas Diretrizes de Atributos de Requisitos [17]:

• Status do Teste
• Número do Build
• Testado por
• Data do Teste
• Notas do Teste

Será de responsabilidade do Testador do Sistema atualizar o status do teste no RequisitePro.

Os resultados de teste serão retidos no Controle de Configuração.

6.3 Relatórios de Defeitos

O Rational ClearQuest será utilizado para registrar e monitorar defeitos individuais.

A seguir são mostradas as tarefas relacionadas ao teste do protótipo de arquitetura do C-Registration:

Direitos Autorais  (c) IBM Corporation 1987, 2004. Todos os Direitos Reservados.

Exemplo da Web do Projeto de Registro em Curso Versão 2001.03