Plano de Teste

(1)

Projeto Nostradamus®

Versão 1.0

(2)

Informação do Documento de Requisitos

Título do documento Autor

Comentários Nome do arquivo

Histórico de Revisões

Data Versão Descrição Autor

(3)

Conteúdo

Plano de teste 4

1. Introdução 4

1.1 Objetivos 4

1.2 Contexto do projeto 4

1.3 Escopo 4

1.4 Identificação do projeto 6

2. Requisitos para teste 7

2.1. Falhas e recuperação de testes 7

3. Estratégia de teste 7

3.1. Tipos de testes 8

3.1.1. Dados e integridade do banco de dados 8

3.1.2. Testes de funções 8

3.1.3. Testes da interface com o usuário 9

3.1.4. Testes de performance 9

3.1.5. Testes de instalação 9

3.2. Ferramentas de teste 10

4. Recursos 10

4.1. Regras 10

4.2. Sistema 11

Plano de teste

(4)

1. Introdução

1.1 Objetivos

Este documento reúne as instruções para planejamento dos testes a serem aplicados ao final da 1ª iteração do projeto Nostradamus® a fim de validar por completo os artefatos produzidos nesse período.

O planejamento comporta o modelo de testes a ser utilizado. Um procedimento de testes estabelece as instruções a serem seguidas para realizar os casos de testes, ou seja, trata-se de um manual de testes. Para isso, é necessário levar em conta os seguintes pontos: as condições iniciais para se testar um determinado requisito do sistema, o ponto de partida do teste, as ações a serem realizadas, os resultados esperados e, por fim, os critérios para aprovação.

Além de avaliar se o sistema está funcionando corretamente (objetivando a procura por erros), os testes servem também para verificar como o sistema se comporta durante a execução de uma tarefa, podendo avaliar a performance do mesmo, por exemplo.

1.2 Contexto do projeto

O projeto Nostradamus® vem como um plugin para o MS Project com o intuito de auxiliar os usuários do programa (gerentes de projeto e desenvolvedores) a realizarem em conjunto com o planejamento obtido pela utilização do Project uma estimativa de esforço demandado pelo projeto analisado, relacionando tempo e custo do mesmo.

Para esta 1ª iteração, o Nostradamus® se mostra completo para implementar as estimativas utilizando os métodos de estimativa de Pontos de Função e COCOMO II (COst COnstructive MOdel). Toda a arquitetura foi implementada da maneira descrita no Documento de Arquitetura, restando apenas a realização dos testes a serem descritos neste documento a partir da nossa interface gráfica que já se encontra integrada com a camada de negócios do sistema. Logo, testes como realizar cálculo de estimativa de esforço utilizando Pontos de Função e COCOMO II que envolvem performance de sistema e integridade com banco de dados são alguns dos testes primordiais para garantir o bom desempenho do produto Nostradamus®.

1.3 Escopo

O plano de testes deve documentar os casos de teste, as ações e os procedimentos e parâmetros utilizados nos testes. Devem ser testados desde os casos mais comuns até situações para as quais o sistema não está programado (o que fornece uma boa idéia das limitações do sistema). Devem também ser verificados: interface gráfica, instalação, integridade do banco de dados e se as instruções do Manual de Operação (Manual do Usuário) correspondem ao sistema criado.

Vale ressaltar que nenhum teste é definitivo e prova que o programa está correto, no entanto, a prática deles é indispensável para consolidar um bom projeto. Durante o desenvolvimento do sistema, os modelos de testes podem ser revistos, criando-se assim novas versões de testes que contenham as anteriores e levem em conta novas funcionalidades do sistema.

Para que fosse possível a realização de todos os testes necessários para garantir o funcionamento correto do sistema, foi preciso que se construísse uma plano estruturado que listasse quais tipos e que testes especificamente seriam feitos para tal finalidade. Por isso, o processo de testes do sistema foi dividido em fases que se iniciaram desde a fase de implementação até o final da 1ª iteração quando todas as partes do projeto já estavam integradas. Então, tem-se as seguintes fases (ou tipos) de testes:

1 – Teste unitário

(5)

Os testes unitários foram realizados durante a implementação da camada de dados e negócios para cada funcionalidade criada. Testes foram escritos para ficarem documentados e serem utilizados sempre que necessários, no entanto, essa atividade foi realizada manualmente, isto é, sem o auxílio de ferramentas para automatizar esses testes unitários, mas com sucesso atingido.

2 – Teste de integração

Da mesma maneira que os testes unitários, os testes de integração também foram realizados durante a fase de implementação da camada de dados e negócios de forma a integrar as duas partes e essa camada com a GUI (Graphic User Interface). A questão da integração com o banco de dados será aqui objeto de teste relatado na seção 3 de estratégia de teste feita a partir da nossa interface gráfica, onde os dados armazenados e consultados deverão estar corretos em relação aos dados fornecidos ao sistema.

3 – Teste de backup

Para esse tipo de teste deverão existir cópias de segurança do banco de dados para recuperação ou armazenamento. Esse é um processo específico do banco de dados e da organização e não estará especificado neste documento, pois não diz respeito a um tipo de teste que a equipe possa realizar.

4 – Teste de sistema

O teste de sistema vai se referir, sobretudo, à questão da performance descrita no documento de plano de projeto, onde as consultas ao plugin Nostradamus® não deverá exceder 15 segundos, quando utilizado numa máquina com as configurações de hardware determinadas nesse mesmo plano de projeto. No entanto, testes de performance (assim como o uso) em configurações diferentes desta não garantem o bom funcionamento do plugin.

5 – Mensagens de erro

Testes induzindo a erros (programados) do sistema também são importantes porque indicam se o sistema está reagindo com o comportamento esperado e se as mensagens de erro são objetivas, orientando o usuário a solucionar o problema e não impedindo o progresso do mesmo no sistema. Elas serão exibidas com um mínimo de impacto no fluxo da aplicação.

6 – Teste de disponibilidade

Estes testes se referem ao fato que o sistema não deverá ficar indisponível por erros de utilização dos usuários. Sua recuperação deve ser imediata e os usuários deverão ser orientados para não tornar a repetir o erro. Logo, assim como o item 5, testes induzindo o sistema a erros esperados pelo mesmo devem ser realizados.

7 – Teste de interface gráfica

Além de testar a integridade com o banco de dados que diz respeito à questão da comunicação entre a GUI e a camada mais baixa do sistema, testes de usabilidade do sistema também é realizado com a interface, onde a mesma deverá prover a comunicação entre o usuário e o sistema para que o usuário tenha fácil acesso a todas as funcionalidades do sistema e de forma objetiva. A GUI deverá ser amigável e as informações deverão estar bem intuitivas. Estes testes são feitos submetendo uma determinada quantidade de usuários ao uso do produto e verificando a maneira como ela está sendo utilizada.

1.4 Identificação do projeto

A tabela abaixo identifica a documentação utilizada para produzir o plano de teste:

Documento Criado ou

reutilizado

Recebido ou revisado

Autor ou fonte

Notas

(6)

Especificação de requisitos Criado Revisado OnTop Todos os documentos foram revisados pois houveram modificações na arquitetura do sistema e no documento de requisitos

Requisitos funcionais Criado Revisado OnTop Todos os documentos foram

revisados pois houveram modificações na arquitetura do sistema e no documento de requisitos

Relatório de casos de uso Criado Revisado OnTop Todos os documentos foram

Plano de proejto Criado Revisado OnTop Todos os documentos foram

Especificaões de projeto Criado Revisado OnTop Todos os documentos foram

Protótipo Criado Revisado OnTop Todos os documentos foram

Modelo de negócios Criado Revisado OnTop Todos os documentos foram

Modelo de dados Criado Revisado OnTop Todos os documentos foram

Regras de negócios Criado Revisado OnTop Todos os documentos foram

(7)

2. Requisitos para teste

A lista abaixo identifica aqueles itens – casos de uso, requisitos funcionais e requisitos não funcionais – que foram identificados como alvos para os testes. Esta lista representa o que será testado.

2.1. Falhas e recuperação de testes

Pode ocorrer uma falhas devido a uma variedade de mal-funcionamento de hardware e sottware.

Esse teste visa garantir a recuperação de dados que possam ser corrompidos de alguma forma, através de falhas no sistema operacional ou do hardware, bem como, garantir o perfeito funcionamento por falhar que possam ocorrer durante a execução do nosso sistema.

Nos testes de recuperação o sistema é inserido em situações extremas visando simular o que poderia acontecer caso ocorra uma falha. Neste caso garante os dados do banco sejam consistentes.

Objetivo do teste: Vereficicar os seguintes erros que possam ocorrer:

 Ciclos Incompletos (filtro de interrupção de dados ,processo de sicronização de dados).

 Ponteiros e chaves inválidas no Banco de dados

 Elementos inválidos e corrompidos no banco de dados

Técnica: Para testar os ponteiros, os campos e as chaves do banco basta corromper manaulmente e diretamente no banco de dados.

(falta complemetar!!!!!!!!!!!!!!)

Critério de Termino: Em todos os casos acima, a aplicação na base de dados, e no sistema, em cima da conclusão de procedimentos de recuperação, retorna a um estado sabido e, desejável.

Considerações especiais:  A equipe de banco de dados deve estar presente.

 O teste deve rodar por horas em uma máquina isolada.

3. Estratégia de teste

A estratégia de teste apresenta a abordagem recomendada para o teste do software. O tópico passado, Requisitos para teste, descreveu o que será testado – esse tópico descreve como isso será feito.

3.1. Tipos de testes

3.1.1. Dados e integridade do banco de dados

O banco de dados e os processos de persistência foram testados como subsistemas dentro do Nostradamus®. Esses subsistemas foram testados sem utilizar a interface com o usuário do projeto, de forma a testar de maneira mais eficiente. Foram feitos testes de inclusão e remoção, verificando a consistência das operaões.

(8)

Objetivo do teste Garantir a integridade dos dados após operações de inclusão/remoção.

Técnica  Utilizar cada método de acesso ao banco passando como parâmetros valores válidos e inválidos, e após isso testar busca pelos dados

 Inspecionar a base de dados para garantir que os dados foram incluídos/removidos da forma que deveriam ter sido

Critério de término: Todos os métodos de acesso ao banco foram testados sem corrupção de dados Considerações especiais:  Os métodos foram testados sem utilização da interface gráfica para

possibilair o teste com uma maior gama de valores.

 Os processos foram invodados manualmente

 Foi usado um banco de dados reduzido de forma a facilitar a identificação de erros.

3.1.2. Testes de funções

O teste de funções visa testar os requisitos que podem ser mapeados diretamente em casos de uso ou regras de negócios. O objetivo destes testes é verificar a aceitação correta das entradas do usuário e a correta implementação das regras de negócio. Esta iteração é feita a partir da interface gráfica, e deve se analisar as saídas do sistema.

Objetivo do teste Garantir o funcionamento da navegação, entrada de dados, processos e recuperação de dados

Técnica Executar cada caso de uso verificando

 Resultado esperado quando a entrada é válida

 Mensagem de erro esperada quando a entrada é inválida.

 Cada regra de negócio está sendo executada corretamente Critério de término  Todos os testes planejados foram executados

 Todos os erros encontrados foram identificados

Considerações especiais Identificar todas as influências externas/internas que podem influenciar na implementação/execução dos testes

3.1.3. Testes da interface com o usuário

Esse teste verifica a iteração do usuário com o software, via a GUI. O objetivo desse teste visa verificar que a interface oferece ao usuário o acesso apropriado e a navegação para as funções do sistema.

Além disso deve ser verificado que a interface funciona como deveria.

(9)

Objetivo do teste Verificar os seguintes tópicos:

 Garantir que a navegação no sistema corresponde com as funções implementadas e os requisitos especificados, incluindo os métodos de acesso(tab, mouse...)

 Características dos botões, menus e etc correspondem com o padrão do projeto

Técnica Criar testes de navegação/funcionamento para cada janela do aplicativo Critério de término Cada janela é testada e é verificado que corresponde aos requisitos desejados Considerações especiais Nem todas as propriedades das janelas podem ser acessadas pelo

usuário(resize...)

3.1.4. Testes de performance

O teste de performance visa avaliar o desempenho do sistema sob diferentes condições e garantir que o sistema ainda funcione corretamente sob essas condições de funcionamento. Tem como objetivo garantir que o tempo de resposta não vá ultrapassar o tempo de resposta previsto, para toda operação do sistema em que o tempo de resposta é importante.

Objetivo do teste Verificar o tempo de resposta dos casos de uso sob diferentes condições Técnica  [Use tests developed for Function or Business Cycle Testing.

 Modify data files to increase the number of transactions or the tests to increase the number of times each transaction occurs.]

Completion Criteria: [Multiple transactions or multiple users: Successful completion of the tests without any failures and within acceptable time allocation.]

Special Considerations:  [Load testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement.

 The databases used for load testing should be either actual size or scaled equally.]

3.1.5. Testes de instalação

Este teste tem como objetivo verificar erros que podem ocorrer durante a instalação do plug-in.

Objetivo do teste Verificar que o software é instalado corretamente, atendendo as seguintes especificaões:

 Uma nova instalação

 Tentativa de instalar mais de uma vez Técnica  Testar os casos citados acima

(10)

Critério de término Testar os dois casos citados acima em diferentes máquinas sem que ocorram erros

Considerações especiais Verificar a existência do MS Project

3.2. Ferramentas de teste

O sistema será testado manualmente utilizando a função de debug do Microsoft Visual Studio 2003, para verificar passo a passo o que está acontecendo com as variáveis internas do sistema.

4. Recursos

Esta seção apresenta os recursos humanos e do sistema recomendados para o projeto Nostradamus, suas funcionalidades principais, e seu conjunto de conhecimento ou de habilidade.

4.1. Regras

A tabela abaixo mostra as suspostas alocação para equipe de testes.

Recursos Humanos

Função Recursos mínimos necessários Tarefas especifiacas

Gerente de Teste Ter uma visão geral do projeto

Responsabilidades:

 Prover conhecimento tecnico

 Alocar recurso apropriados

 Prover um relatorio a gerencia

Designer de Teste Identifica, prioriza e implementa o caso de teste.

Responsabilidades:

 Confeccionar o plano de teste

 Gerar o modelo de teste

 Avalia a eficacia do esfoco de teste

Analista de Teste Executa os testes.

Responsabilidades:

 Executas os testes

 Registra dos resultados

 Corrige os erros

 Modifica o documento de requisitos

(11)

Administrador do Banco de

Dados Assegura o ambiente de dados.

Responsabilidades:

 Testar a persistência dos dados

Designer Identifica e define as operacoes, os atributos e as

associacoes das classes de testes.

Responsabilidades:

 Identifica e define as classes de testes

 Identifica e define os pacotes de testes

4.2. Sistema

A seguinte tabela determinou os recursos de sistema para o projeto testado.

Recursos do Sistema

Recursos Nome / Tipo

Banco de dados MySQL DataBase Server version 4.1

Máquinas Pentium III 256MB RAM