[TEMPLATE DE PLANO DE TESTES]

<Nome do Projeto>
 Histórico da Revisão

Data Versão Descrição Autor Área/Setor

<dd/mm/aaaa> <x.x> <detalhes> <nome>
Identificação do Plano de Testes: <inserir o Código do Plano de Testes.>

<inserir o Nome do Plano de Testes>

1. Introdução

1.1. Objeto

<Descrição do software a ser testado>

1.2. Objetivo

<Descrição do propósito do teste realizado>

2. Escopo

<Descrição dos diversos tipos de testes que fazem parte deste plano e a lista priorizada dos
itens de software a serem testados. Também faz parte do escopo a lista de itens de software
que não serão testados. Para cada item devem ser especificadas as funcionalidades e
características que serão e as que não serão testadas>

3. Abordagem

<Especifica a forma de realização dos testes. Abrange, entre outros aspectos, as técnicas,
ferramentas e restrições, além disso, são definidos critérios para iniciação, aprovação e
encerramento dos testes. também são definidas as condições para a suspensão e retomada
dos testes.>

4. Missão de Avaliação e Motivação dos Testes

[Forneça uma visão geral da missão e da motivação dos testes que serão conduzidos
nesta iteração]
4.1 Fundamentos

[Forneça uma breve descrição dos fundamentos que justificam o esforço de teste
definido neste Plano de Teste. Inclua informações como, por exemplo, o problema
principal que está sendo resolvido, os principais benefícios da solução, a arquitetura
planejada da solução e um breve histórico do projeto. Quando essas informações
estiverem definidas em outros documentos, você poderá incluir referências a esses
documentos mais detalhados caso seja apropriado. Esta seção só deverá conter de três a
cinco parágrafos]

4.2 Missão de Avaliação

[Forneça uma breve sentença que defina a missão do esforço de avaliação na iteração
atual. Essa sentença poderá incorporar uma ou mais preocupações incluindo:
 - localizar o maior número de erros possível
- localizar problemas importantes
- avaliar os riscos da qualidade perceptível
- informar sobre os riscos perceptíveis do projeto
- certificar segundo um padrão
- verificar uma especificação (requisitos, design ou alegações)
- informar sobre a qualidade do produto
- satisfazer os envolvidos
- informar sobre os testes
- cumprir as determinações do processo
- e assim por diante
Cada missão fornece um contexto diferente para o esforço de teste e altera a maneira
como o teste deverá ser abordado.]

4.3 Motivadores dos Testes

[Forneça um resumo dos principais elementos que motivarão o esforço de teste nesta
iteração. Os testes poderão ser motivados por uma série de fatores como, por exemplo,
riscos de qualidade, riscos técnicos, riscos do projeto, casos de uso, requisitos
funcionais, requisitos não funcionais, elementos de design, falhas ou erros suspeitos,
solicitações de mudança etc.]

5. Itens de Teste-Alvo

A listagem abaixo identifica os itens de software, de hardware e elementos de suporte do

produto que foram identificados como objetivos dos testes. Esta lista representa os itens que
serão testados.

[Forneça uma lista de nível superior dos principais itens que estarão sujeitos a teste.
Essa lista deve incluir itens produzidos diretamente pela equipe de desenvolvimento do
projeto e itens de que dependem esses produtos. Por exemplo, o hardware de
processamento básico, dispositivos periféricos, sistemas operacionais, produtos ou
componentes de terceiros etc. É recomendável agrupar a lista por categoria e atribuir
importância relativa a cada motivador.]

6. Resumo dos Testes Planejados

[Esta seção apresenta os recursos recomendados para o projeto <Nome do Projeto>,
suas principais responsabilidades e seu conjunto de conhecimentos ou de habilidade.]
6.1 Resumo das Inclusões dos Testes

[Esta seção fornece um resumo de nível superior dos testes que serão executados. O
resumo fornecido aqui representa uma visão geral de nível superior dos testes que serão
e dos que não serão executados]
6.2 Resumo dos Outros Candidatos a Possível Inclusão
 [Descreva separadamente as áreas de teste cuja avaliação e investigação você supõe que
poderão ser úteis, mas que ainda não foram suficientemente pesquisadas para justificar
com certeza a importância de examiná-las.]
6.3 Resumo das Exclusões dos Testes
[Forneça um resumo de nível superior dos possíveis testes que poderiam ter sido
conduzidos, mas que foram explicitamente excluídos deste plano. Se você não for
implementar ou executar um tipo de teste, informe claramente que o teste não será
executado ou implementado e justifique por que. A seguir, há exemplos de justificativas
que poderão ser usadas:
- "Esses testes não contribuem para alcançar a missão de avaliação."
- "Não há recursos suficientes para executar esses testes."
- "Esses testes são desnecessários devido aos testes executados por xxxx."
Segundo um prisma heurístico, se você achar que é perfeitamente concebível que um
dos membros de seu público espere que um determinado aspecto de teste seja incluído e
se você não pretender ou não puder incluí-lo, justifique sua exclusão. Se a equipe
concordar que a exclusão é óbvia, você provavelmente não precisará listá-la.]

7. Abordagem dos Testes

[Esta seção apresenta a estratégia recomendada para criar e implementar os testes
necessários. As seções 3, Itens de Teste-Alvo, e 4, Resumo dos Testes Planejados,
identificaram que itens serão testados e que tipos de testes serão executados. Esta
seção descreve como esses testes serão realizados.
Um aspecto a ser considerado na abordagem dos testes é as técnicas que serão usadas.
Deverá ser incluído um resumo de como cada técnica poderá ser implementada, de uma
perspectiva manual e/ou automatizada, e os critérios para comprovar que a técnica é útil
e eficaz. Para cada técnica, forneça uma descrição a seu respeito e defina por que é uma
parte importante da abordagem dos testes resumindo brevemente como ela ajuda a
alcançar a Missão de Avaliação ou como aborda os Motivadores dos Testes.
Outro aspecto a ser discutido nesta seção é os modelos de Erro ou Falha que são
aplicáveis e as maneiras de abordar como avaliá-los.
À medida que definir cada aspecto da abordagem, você deverá atualizar a seção 10,
Responsabilidades, Perfil da Equipe e Necessidades de Treinamento, para documentar a
configuração do ambiente de teste e outros recursos que serão necessários para
implementar cada aspecto.]
7.1 Catálogos Iniciais de Ideias de Teste e Outras Fontes de Referência

[Forneça uma listagem dos recursos existentes que serão consultados para estimular a
identificação e a seleção de testes específicos a serem conduzidos. É fornecido um
Catálogo de Ideias de Teste de exemplo na seção de exemplos do RUP.]
7.2 Tipos e Técnicas de Teste

7.2.1 Teste de Integridade de Dados e de Banco de Dados

[Os bancos de dados e os processos de banco de dados deverão ser testados como um
subsistema independente. Esse teste deve testar os subsistemas sem que a Interface do
Usuário do objetivo do teste faça interface com os dados. É necessário efetuar pesquisas
 adicionais referentes ao Sistema de Gerenciamento de Banco de Dados (DBMS) a fim de
identificar as ferramentas e técnicas que poderão existir para suportar os testes
identificados na tabela a seguir.]

Objetivo da Técnica: [Experimentar processos e métodos de acesso a banco de

dados independentes da UI para que você possa observar e
registrar comportamentos-alvo incorretos ou a existência
de dados corrompidos.]

Técnica: [Dispare cada processo e método de acesso a banco de

dados, propagando dados válidos e inválidos ou
solicitações de dados em cada um deles.
Inspecione o banco de dados para assegurar que os dados
foram distribuídos conforme o planejado e que todos os
eventos de banco de dados ocorreram de forma adequada,
ou revise os dados retornados para assegurar que os dados
corretos foram recuperados pelas razões corretas.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]

Ferramentas [A técnica exige as seguintes ferramentas:

Necessárias:
Ferramenta de Automação de Scripts de Teste
restaurador e reprodutor de imagem da configuração básica
ferramentas de backup e de recuperação
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)
ferramentas e utilitários SQL de banco de dados
ferramentas de geração de dados]
Critérios de Êxito: [A técnica suporta o teste de todos os principais processos
e métodos de acesso a banco de dados]

Considerações [Os testes poderão necessitar de drivers ou de um ambiente

Especiais: de desenvolvimento DBMS para inserir ou modificar dados
diretamente no banco de dados.
Os processos deverão ser disparados manualmente.
Deverão ser usados bancos de dados pequenos ou de
tamanho mínimo (com um número limitado de registros)
para aumentar a visibilidade de quaisquer eventos não
aceitáveis.]

7.2.2 Teste de Funcionamento

[O teste de funcionamento do objetivo do teste deve concentrar-se em todos os
requisitos de teste que possam ser diretamente associados a casos de uso ou funções e
regras de negócios. Esse teste tem por fim verificar a adequada aceitação,
processamento e 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 através da Interface
Gráfica do Usuário (GUI) e analisar a saída ou os resultados. A tabela a seguir identifica
um resumo do teste recomendado para cada aplicativo]

Objetivo da Técnica: [Experimentar a funcionalidade do objetivo do teste,

incluindo a navegação, a entrada, o processamento e a
recuperação de dados a fim de observar e registrar o
comportamento-alvo.]

Técnica: [Experimentar os recursos e fluxos ou funções de cada um

dos cenários de caso de uso, utilizando dados válidos e
inválidos para verificar se:
os resultados esperados ocorrerão quando forem usados
dados válidos
as mensagens de erro ou de aviso apropriadas serão
exibidas quando forem usados dados inválidos
cada regra de negócio será aplicada de forma adequada]
Estratégias: [Descreva uma ou mais estratégias que podem ser usadas
pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]

Ferramentas [A técnica exige as seguintes ferramentas:

Necessárias:
Ferramenta de Automação de Scripts de Teste
restaurador e reprodutor de imagem da configuração básica
ferramentas de backup e de recuperação
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)
ferramentas de geração de dados]

Critérios de Êxito: [A técnica suporta o teste de:

todos os principais cenários de caso de uso
todos os principais recursos

Considerações [Identifique ou descreva os itens ou problemas (internos ou

Especiais: externos) que exercem influência sobre a implementação e
a execução do teste de funcionamento.]

7.2.3 Teste de Ciclos de Negócios

[O Teste de Ciclos de Negócios deverá emular as atividades executadas no <Nome do

Projeto> ao longo do tempo. Deverá ser identificado um período como, por exemplo, um
ano, e deverão ser executadas as transações e atividades que ocorreriam durante esse
período de um ano. Isso incluirá todos os ciclos diários, semanais e mensais, assim
como os eventos que mudam com as datas como, por exemplo, lembretes.]

Objetivo da Técnica: [Experimentar processos de segundo plano e do objetivo

do teste de acordo com as programações e os modelos de
negócios necessários, a fim de observar e registrar o
comportamento-alvo.]
Técnica: [O teste simulará vários ciclos de negócios executando o
seguinte:
Os testes destinados a inspecionar o funcionamento do
objetivo do teste serão modificados ou melhorados para
aumentar o número de vezes que cada função é executada,
a fim de simular vários usuários diferentes ao longo de um
período de tempo especificado.
Todas as funções que mudam com as datas ou o tempo
serão executadas usando datas ou períodos de tempo
válidos e inválidos.
Todas as funções que ocorrerem segundo uma
programação periódica serão executadas ou iniciadas no
momento adequado.
O teste incluirá o uso de casos válidos e inválidos para
verificar se:
● Os resultados esperados ocorrerão quando forem
usados dados válidos.
● As mensagens de erro ou de aviso apropriadas
serão exibidas quando forem usados dados
inválidos.
● Cada regra de negócio será aplicada de forma
adequada.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]
Ferramentas [A técnica exige as seguintes ferramentas:
Necessárias:
Ferramenta de Automação de Scripts de Teste
restaurador e reprodutor de imagem da configuração básica
ferramentas de backup e de recuperação
ferramentas de geração de dados]

Critérios de Êxito: [A técnica suporta o teste de todos os ciclos de negócios

essenciais.]

Considerações [Os eventos e as datas do sistema poderão exigir atividades

Especiais: de suporte especiais.
É necessário um modelo de negócios para identificar
requisitos e procedimentos de teste adequados.]

7.2.4 Teste de Interface do Usuário

[O Teste de Interface do Usuário (UI) verifica a interação do usuário com o software. O

teste de UI tem por fim assegurar que a UI forneça ao usuário o acesso e a navegação
adequados através das funções do objetivo do teste. Além disso, o teste de UI assegura
que os objetos contidos na UI funcionem conforme o esperado e estejam em
conformidade com padrões corporativos ou da indústria.]

Objetivo da Técnica: [Experimentar o seguinte para observar e

registrar a conformidade com padrões e o
comportamento-alvo:
A navegação pelo objetivo do teste para verificar
se reflete os requisitos e funções de negócios,
incluindo a navegação janela a janela e campo a
campo, e o uso de métodos de acesso (teclas de
tabulação, movimentos do mouse e teclas
aceleradoras).
As características e os objetos das janelas
poderão ser experimentados como, por exemplo,
menus, tamanho, posição, estado e foco.]

Técnica: [Crie ou modifique testes para cada janela a fim

de verificar a navegação adequada e os estados
de objeto apropriados para cada janela e objeto
do aplicativo.]

Estratégias: [Descreva uma ou mais estratégias que podem

 ser usadas pela técnica para observar, de forma
precisa, os resultados do teste. A estratégia
combina elementos do método através do qual a
observação pode ser feita e das características
dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as
estratégias sejam auto
verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do
êxito ou falha do teste. No entanto, tenha
atenção para reduzir os riscos inerentes à
determinação automática dos resultados.]

Ferramentas [A técnica necessita da Ferramenta de

Necessárias: Automação de Scripts de Teste.]

Critérios de Êxito: [A técnica suporta o teste de cada tela ou janela

principal que será muito usada pelo usuário
final.]

Considerações [Nem todas as propriedades referentes a objetos

Especiais: personalizados e de terceiros poderão ser
acessadas.]

7.2.5 Determinação do Perfil de Desempenho

[Este é um teste de desempenho em que os tempos de resposta, as taxas de transação e
outros requisitos que mudam com o tempo são medidos e avaliados. Este teste tem por
fim verificar se os requisitos de desempenho foram alcançados. Ele é implementado e
executado para determinar o perfil dos comportamentos de desempenho do objetivo do
teste e ajustá-los em função de condições como, por exemplo, configurações de
hardware ou de carga de trabalho.
Observação: As transações da tabela a seguir são "transações de negócios lógicas".
Essas transações são definidas como casos de uso específicos que se espera que um
ator do sistema execute utilizando o objetivo do teste como, por exemplo, adicionar ou
modificar um determinado contrato.]

Objetivo da Técnica: [Experimentar comportamentos referentes a funções de

negócios ou transações funcionais designadas nas
condições abaixo, a fim de observar e registrar o
comportamento-alvo e os dados de desempenho do
aplicativo:
carga de trabalho antecipada normal
carga de trabalho antecipada no pior caso]
Técnica: [Use os Procedimentos de Teste desenvolvidos para o
Teste de Ciclos de Negócios ou de Funcionamento.
Modifique os arquivos de dados a fim de aumentar o
número de transações ou modifique os scripts a fim de
aumentar o número de iterações que ocorrem em cada
transação.
Os scripts deverão ser executados em uma máquina (o
melhor é avaliar o desempenho de um único usuário, uma
única transação) e deverão ser repetidos para vários
clientes (virtuais ou reais, consulte Considerações
Especiais abaixo).]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]

Ferramentas [A técnica exige as seguintes ferramentas:

Necessárias:
Ferramenta de Automação de Scripts de Teste
uma ferramenta para a determinação do perfil de
desempenho do aplicativo como, por exemplo, o Rational
Quantify
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)
ferramentas de restrição de recursos como, por exemplo,
enlatados]
Critérios de Êxito: [A técnica suporta o teste de:
Uma única transação ou um único usuário: uma emulação
bem-sucedida dos scripts de transação sem que ocorra
nenhuma falha devido a problemas de implementação do
teste.
Várias transações ou vários usuários: uma emulação bem-
sucedida da carga de trabalho sem que ocorra nenhuma
falha devido a problemas de implementação do teste.]

Considerações [O teste abrangente do desempenho inclui ter uma carga de

Especiais: trabalho em segundo plano no servidor.
Há vários métodos que podem ser usados para executar
esse teste, incluindo:
"Encaminhar as transações" diretamente para o servidor,
geralmente como chamadas de Linguagem de Consulta
Estruturada (SQL).
Criar carga de usuário "virtual" para simular muitos
clientes, geralmente algumas centenas deles. Para se obter
essa carga, geralmente são usadas ferramentas de
Emulação de Terminal Remoto. Essa técnica também pode
ser usada para que a rede fique repleta de "tráfego".
Usar vários clientes físicos, cada qual executando scripts
de teste, para inserir carga no sistema.

O teste de desempenho deverá ser executados em uma

máquina dedicada ou em um período de tempo dedicado.
Isso permitirá o controle total e a medição exata.
Os bancos de dados usados para o Teste de Determinação
de Perfil de Desempenho deverá ter um tamanho real ou
deverão ser dimensionados igualmente em escala.]

7.2.6 Teste de Carga

[O teste de carga é um teste de desempenho que sujeita o objetivo do teste a diferentes

cargas de trabalho para medir e avaliar as habilidades e os comportamentos de
desempenho dele, a fim de verificar se este continua a funcionar adequadamente com
essas diferentes cargas de trabalho. O teste de carga tem por fim determinar e assegurar
que o sistema funcione adequadamente com uma carga de trabalho superior à carga
máxima esperada. Além disso, esse teste avalia as características do desempenho como,
por exemplo, tempos de resposta, taxas de transação e outros aspectos que mudam com
o tempo.
 [Observação: As transações da tabela a seguir são "transações de negócios lógicas".
Essas transações são definidas como funções específicas que se espera que um usuário
final do sistema execute utilizando o aplicativo como, por exemplo, adicionar ou
modificar um determinado contrato.]

Objetivo da Técnica: [Experimentar casos de negócio ou transações designadas

em várias condições de carga de trabalho, a fim de observar
e registrar o comportamento-alvo e os dados de
desempenho do sistema.]

Técnica: [Use os Scripts de Teste de Transação desenvolvidos para

os Testes de Ciclos de Negócios ou de Funcionamento
como uma base, mas lembre-se de remover as iterações e
os atrasos desnecessários.
Modifique os arquivos de dados a fim de aumentar o
número de transações ou modifique os testes a fim de
aumentar o número de vezes que cada transação ocorre.
As cargas de trabalho devem incluir cargas de pico — por
exemplo, diárias, semanais e mensais.
As cargas de trabalho devem representar cargas médias
assim como cargas de pico.
As cargas de trabalho devem representar picos
instantâneos e picos sustentados.
As cargas de trabalho devem ser executadas com
diferentes Configurações do Ambiente de Teste.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]
Ferramentas [A técnica exige as seguintes ferramentas:
Necessárias:
Ferramenta de Automação de Scripts de Teste
Ferramenta de controle e de programação de carga de
transações
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)
ferramentas de restrição de recursos como, por exemplo,
enlatados
ferramentas de geração de dados]

Critérios de Êxito: [A técnica suporta o teste de Emulação de Carga de

Trabalho, que é a emulação bem-sucedida da carga de
trabalho sem que nenhuma falha ocorra devido a problemas
de implementação do teste.]

Considerações [O teste de carga deverá ser executado em uma máquina

Especiais: dedicada ou em um período de tempo dedicado. Isso
permitirá o controle total e a medição exata.
Os bancos de dados usados para o teste de carga deverão
ter um tamanho real ou deverão ser dimensionados
igualmente em escala.]

7.2.7 Teste de Stress

[O teste de stress é um tipo de teste de desempenho implementado e executado para

compreender como ocorrem falhas no sistema devido a condições que estão no limite ou
fora do limite das tolerâncias esperadas. Normalmente isso envolve poucos recursos ou
a concorrência por recursos. As condições de poucos recursos revelam como ocorrem
falhas no objetivo do teste que não estão aparentes em condições normais. Outros
defeitos poderão resultar de uma concorrência por recursos compartilhados como, por
exemplo, bloqueios de banco de dados ou largura de banda de rede, embora alguns
desses testes sejam geralmente abordados nos testes funcionais e de carga.
Observação: As transações mencionadas na tabela a seguir são transações de negócios
lógicas.]
Objetivo da Técnica: [Experimentar as funções do objetivo do teste nas
seguintes condições de stress a fim de observar e registrar
o comportamento-alvo que identifica e documenta as
condições que fazem com que o sistema deixe de funcionar
adequadamente:
pouca ou nenhuma memória disponível no servidor
(memória RAM e espaço de armazenamento persistente)
número máximo real ou fisicamente capaz de clientes
conectados ou simulados
vários usuários executando as mesmas transações nos
mesmos dados ou contas
conjunto ou volume de transações que geram "sobrecarga"
(consulte Determinação do Perfil de Desempenho acima)]

Técnica: [Use os testes de Carga ou de Determinação do Perfil de

Desempenho.
Para testar recursos limitados, os testes deverão ser
executados em uma única máquina, e a memória RAM e o
espaço de armazenamento persistente no servidor deverão
ser reduzidos ou limitados.
Para os testes de stress restantes, deverão ser usados
vários clientes, executando-se os mesmos testes ou testes
complementares a fim de produzir o conjunto ou volume de
transações no pior caso.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]
Ferramentas [A técnica exige as seguintes ferramentas:
Necessárias:
Ferramenta de Automação de Scripts de Teste
Ferramenta de controle e de programação de carga de
transações
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)
ferramentas de restrição de recursos como, por exemplo,
enlatados
ferramentas de geração de dados]

Critérios de Êxito: [A técnica suporta o teste de Emulação de Pressão. O

sistema poderá ser emulado, de maneira eficaz, em uma ou
mais condições definidas como condições de stress, e
poderá ser capturada uma observação do estado resultante
do sistema durante e depois de a condição ter sido
emulada.]

Considerações [Para gerar stress na rede talvez seja necessário que as

Especiais: ferramentas da rede a sobrecarreguem com mensagens ou
pacotes.
O armazenamento persistente usado para o sistema deverá
ser reduzido temporariamente a fim de restringir o espaço
disponível para que o banco de dados se desenvolva.
Sincronize o acesso simultâneo dos clientes aos mesmos
registros ou contas de dados.]

7.2.8 Teste de Volume

[O teste de volume sujeita o objetivo do teste a grandes volumes de dados a fim de
determinar se serão atingidos limites que farão com que o software deixe de funcionar.
Esse teste também identifica o volume ou carga máxima contínua que o objetivo do teste
pode suportar durante um determinado período de tempo. Por exemplo, se o objetivo do
teste estiver processando um conjunto de registros de banco de dados para gerar um
relatório, um Teste de Volume usará um grande banco de dados de testes e verificará se
o software se comportou normalmente e gerou o relatório correto.]
Objetivo da Técnica: [Experimentar as funções do objetivo do teste nos seguintes
cenários de elevado volume para observar e registrar o
comportamento-alvo:
O número máximo (real ou fisicamente capaz) de clientes
conectados, ou simulados, todos executando a mesma
função de negócios (desempenho), no pior caso, durante um
longo período de tempo.
Foi atingido o tamanho máximo do banco de dados (real ou
em escala) e várias consultas ou transações de relatório são
executadas simultaneamente.]

Técnica: [Use os testes de Carga ou de Determinação do Perfil de

Desempenho.
Deverão ser usados vários clientes, executando-se os
mesmos testes ou testes complementares a fim de produzir o
conjunto ou volume de transações no pior caso (consulte
Teste de Stress) durante um longo período de tempo.
Será criado o tamanho máximo do banco de dados (real, em
escala ou preenchido com dados representativos) e serão
usados vários clientes para executar consultas e transações
de relatório simultaneamente durante longos períodos de
tempo.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método através
do qual a observação pode ser feita e das características dos
resultados específicos que indicam um provável êxito ou
falha do teste. O ideal é que as estratégias sejam auto
verificadas, permitindo que os testes automatizados façam
uma avaliação inicial do êxito ou falha do teste. No entanto,
tenha atenção para reduzir os riscos inerentes à
determinação automática dos resultados.]
Ferramentas [A técnica exige as seguintes ferramentas:
Necessárias:
Ferramenta de Automação de Scripts de Teste
Ferramenta de controle e de programação de carga de
transações
ferramentas de monitoramento de instalação (registro, disco
rígido, CPU, memória etc.)
ferramentas de restrição de recursos como, por exemplo,
enlatados
ferramentas de geração de dados]

Critérios de Êxito: [A técnica suporta o teste de Emulação de Volume. É

possível emular, de forma eficaz, grandes quantidades de
usuários, dados, transações ou outros aspectos do sistema
utilizados em volume e poderá ser capturada uma
observação sobre as mudanças de estado do sistema
durante o teste de volume.]

Considerações [Que período de tempo seria considerado aceitável para as

Especiais: condições de elevado volume, conforme observado acima?]

7.2.9 Teste de Segurança e de Controle de Acesso

[O Teste de Segurança e de Controle de Acesso concentra-se em duas áreas de

segurança principais:
Segurança no nível do aplicativo, incluindo o acesso aos Dados ou às Funções de
Negócios
Segurança no nível do sistema, incluindo efetuar login ou acessar remotamente o
sistema
Com base no nível de segurança desejado, a segurança no nível do aplicativo assegura
que os atores estejam restritos a funções ou casos de uso específicos, ou que tenham
acesso limitado aos dados disponíveis. 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 assegurará que o "tipo de usuário um" possa ver
todas as informações de um cliente, incluindo dados financeiros. No entanto, o "tipo de
usuário dois" somente verá os dados demográficos referentes ao mesmo cliente.
A segurança no nível do sistema assegura que somente os usuários a que tenha sido
concedido acesso ao sistema serão capazes de acessar os aplicativos e somente através
dos gateways apropriados.]
Objetivo da Técnica: [Experimentar o objetivo do teste nas seguintes condições
para observar e registrar o comportamento-alvo:
Segurança no nível do aplicativo: um ator poderá acessar
somente as funções ou os dados para o quais seu tipo de
usuário tenha recebido permissão.
Segurança no nível do sistema: somente os atores com
acesso ao sistema e aos aplicativos têm permissão para
acessá-los].

Técnica: [Segurança no nível do aplicativo: Identifique e liste cada

tipo de usuário e as funções ou os dados para os quais
cada tipo tem permissão de acesso.
● Crie testes para cada tipo de usuário e verifique
cada permissão criando transações específicas para
cada tipo de usuário.
● Modifique o tipo de usuário e execute novamente os
testes para os mesmos usuários. Em cada caso,
verifique se as funções ou dados adicionais estão
corretamente disponíveis ou se têm seu acesso
negado.
Acesso no nível do sistema: Consulte Considerações
Especiais abaixo.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]

Ferramentas [A técnica exige as seguintes ferramentas:

Necessárias:
Ferramenta de Automação de Scripts de Teste
Ferramentas de investigação e contra a violação da
segurança por "hackers"
Ferramentas de Administração da Segurança do Sistema
Operacional]
Critérios de Êxito: [A técnica suporta o teste das funções apropriadas. É
possível também que os dados afetados pelas
configurações de segurança sejam testados para cada tipo
de ator conhecido.]

Considerações [O acesso ao sistema deverá ser revisto ou discutido com o

Especiais: administrador de sistemas ou de rede adequado. Talvez
esse teste não seja necessário, já que poderá ser uma das
funções da administração de sistemas ou de rede.]

7.2.10 Teste de Tolerância a Falhas e de Recuperação

[O teste de tolerância a falhas e de recuperação assegura que o objetivo do teste possa
tolerar e se recuperar de uma série de falhas de hardware, software ou de rede com perda
indevida de dados ou da integridade dos dados.
Para os sistemas que devem ser mantidos em execução, o teste de tolerância a falhas
assegura que, ao ocorrer uma condição de tolerância a falhas, os sistemas alternativos
ou de backup "assumirão" adequadamente o papel do sistema danificado sem qualquer
perda de dados ou transações.
O teste de recuperação é um processo de teste antagonista em que o aplicativo ou o
sistema é exposto a condições extremas, ou condições simuladas, para gerar falhas
como, por exemplo, falhas de Entrada/Saída (E/S) de Dispositivo, ou ponteiros e chaves
de banco de dados inválidos. Os processos de recuperação são disparados e o aplicativo
ou o sistema é monitorado e inspecionado para verificar se foi efetuada a recuperação
adequada do aplicativo ou do sistema e de dados.]
Objetivo da Técnica: [Simular as condições de falha e experimentar os
processos de recuperação (manuais e automatizados) para
restaurar o estado conhecido e desejado do banco de
dados, dos aplicativos e do sistema. Os seguintes tipos de
condições estão incluídos no teste para observar e registrar
o comportamento após a recuperação:
interrupção da energia para o cliente
interrupção da energia para o servidor
interrupção da comunicação através dos servidores de rede
perda da comunicação ou interrupção da energia para os
DASD (Dynamic Access Storage Devices, Dispositivos de
Armazenamento de Acesso Dinâmico) e os controladores
DASD
ciclos incompletos (processos de filtragem de dados
interrompidos, processos de sincronização de dados
interrompidos)
ponteiros ou chaves de banco de dados inválidos
elementos de dados inválidos ou corrompidos no banco de
dados]
Técnica: [Os testes de Funcionamento e de Ciclos de Negócios
poderão ser usados como uma base para criar uma série de
transações para suportar os testes de tolerância a falhas e
de recuperação e principalmente para definir os testes que
serão executados para verificar se a recuperação teve êxito.
Interrupção da energia para o cliente: desligue o PC.
Interrupção da energia para o servidor: simule ou inicie
procedimentos de desligamento do servidor.
Interrupção através de servidores de rede: simule ou inicie
uma perda de comunicação com a rede (desconecte
fisicamente os cabos de comunicação ou desligue os
servidores ou roteadores de rede).
Perda da comunicação ou interrupção da energia para os
DASD e os controladores DASD: simule ou elimine
fisicamente a comunicação com um ou mais DASDs ou
controladores DASD.
Depois que as condições acima ou as condições simuladas
tiverem sido alcançadas, as transações adicionais deverão
ser executadas e, quando o estado desse segundo ponto do
teste for atingido, os procedimentos de recuperação
deverão ser disparados.
O teste de ciclos incompletos utiliza a mesma técnica
descrita acima, exceto pelos processos de banco de dados
propriamente ditos, que deverão ser anulados ou
prematuramente encerrados.
O teste das condições a seguir exige que seja atingido um
estado conhecido do banco de dados. Vários campos,
ponteiros e chaves de banco de dados deverão ser
corrompidos manualmente e diretamente no banco de
dados (através das ferramentas de banco de dados). As
transações adicionais deverão ser executadas usando os
Testes de Ciclos de Negócios e de Funcionamento do
Aplicativo e deverão ser executados ciclos completos.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]
Ferramentas [A técnica exige as seguintes ferramentas:
Necessárias:
restaurador e reprodutor de imagem da configuração básica
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)
ferramentas de backup e de recuperação]

Critérios de Êxito: [A técnica suporta o teste de:

Um dos desastres simulados envolvendo uma ou mais
combinações do aplicativo, banco de dados e do sistema.
Uma ou mais recuperações simuladas envolvendo uma ou
mais combinações do aplicativo, banco de dados e do
sistema em um estado conhecido desejado.

Considerações [O teste de recuperação é altamente invasivo. Os

Especiais: procedimentos para desconectar cabos (simular perda de
energia ou de comunicação) talvez não sejam desejáveis ou
viáveis. Poderão ser necessários métodos alternativos
como, por exemplo, ferramentas de software de
diagnóstico.
Serão necessários Recursos dos Sistemas (ou Operações
de Computador), Bancos de Dados e Grupos de Redes.
Esses testes deverão ser executados após o expediente de
trabalho ou em uma máquina isolada.]

7.2.11 Teste de Configuração

[O teste de configuração verifica o funcionamento do objetivo do teste 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. Nas estações de trabalho
cliente, poderão ser carregados diferentes softwares (por exemplo, aplicativos, drivers
etc) e, a qualquer momento, muitas combinações diferentes poderão ficar ativas
utilizando diferentes recursos.]

Objetivo da Técnica: [Experimentar o objetivo do teste nas

configurações de hardware e de software
necessárias, a fim de observar e registrar o
comportamento-alvo em diferentes
configurações e identificar mudanças no estado
da configuração.]
Técnica: [Use Scripts de Teste de Funcionamento.
Abra e feche vários softwares relacionados que
não sejam o objetivo do teste como, por
exemplo, os aplicativos Microsoft Excel e Word,
como parte do teste ou antes do início do teste.
Execute as transações selecionadas para
simular atores interagindo com softwares que
sejam o objetivo do teste e com os que não
sejam o objetivo do teste.
Repita o processo acima, minimizando a
memória convencional disponível na estação de
trabalho cliente.]

Estratégias: [Descreva uma ou mais estratégias que podem

ser usadas pela técnica para observar, de forma
precisa, os resultados do teste. A estratégia
combina elementos do método através do qual a
observação pode ser feita e das características
dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as
estratégias sejam auto verificadas, permitindo
que os testes automatizados façam uma
avaliação inicial do êxito ou falha do teste. No
entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos
resultados.]

Ferramentas [A técnica exige as seguintes ferramentas:

Necessárias:
restaurador e reprodutor de imagem da
configuração básica
ferramentas de monitoramento de instalação
(registro, disco rígido, CPU, memória etc)

Critérios de Êxito: [A técnica suporta o teste de uma ou mais

combinações dos itens de teste-alvo executadas
em ambientes de implantação suportados
esperados.]
Considerações [Que software que não seja o objetivo do teste é
Especiais: necessário, está disponível e acessível na área
de trabalho?
Que aplicativos são normalmente usados?
Que dados estão em execução nos aplicativos;
por exemplo, uma grande planilha aberta no
Excel ou um documento de 100 páginas no
Word?
O NetWare, os servidores de rede, os banco de
dados, entre outros, de todos os sistemas
também precisam ser documentados como parte
desse teste.]

7.2.12 Teste de Instalação

[O teste de instalação tem duas finalidades. A primeira é assegurar que o software possa
ser instalado em diferentes circunstâncias (como uma nova instalação, uma atualização e
uma instalação completa ou personalizada) em condições normais e anormais. Entre as
condições anormais estão o espaço insuficiente no disco, a falta de privilégios para criar
diretórios e assim por diante. A segunda finalidade é verificar se, depois de instalado, o
software funcionará corretamente. Isso geralmente implica executar uma série de testes
que foram desenvolvidos como parte dos Testes de Funcionamento.]

Objetivo da Técnica: [Experimentar a instalação do objetivo do teste em cada

configuração de hardware exigida nas condições a seguir
para observar e registrar o comportamento da instalação e
as mudanças no estado da configuração:
nova instalação: uma nova máquina, em que nunca foi
instalado anteriormente o <Nome do Projeto>
atualização: uma máquina em que foi instalado
anteriormente o <Nome do Projeto>, na mesma versão
atualização: uma máquina em que foi instalado
anteriormente o <Nome do Projeto>, na versão antiga]
Técnica: [Desenvolva scripts automatizados ou manuais para validar
a condição da máquina-alvo.
● novo: nunca instalado
● mesma versão ou versão mais antiga instalada
Inicie ou execute a instalação.
Utilizando um subconjunto predeterminado de scripts de
Teste de Funcionamento, execute as transações.]

Estratégias: [Descreva uma ou mais estratégias que podem ser usadas

pela técnica para observar, de forma precisa, os resultados
do teste. A estratégia combina elementos do método
através do qual a observação pode ser feita e das
características dos resultados específicos que indicam um
provável êxito ou falha do teste. O ideal é que as estratégias
sejam auto verificadas, permitindo que os testes
automatizados façam uma avaliação inicial do êxito ou falha
do teste. No entanto, tenha atenção para reduzir os riscos
inerentes à determinação automática dos resultados.]

Ferramentas [A técnica exige as seguintes ferramentas:

Necessárias:
restaurador e reprodutor de imagem da configuração básica
ferramentas de monitoramento de instalação (registro,
disco rígido, CPU, memória etc.)

Critérios de Êxito: [A técnica suporta o teste da instalação do produto

desenvolvido em uma ou mais configurações de
instalação.]

Considerações [Que transações de devem ser selecionadas para constituir

Especiais: um teste que comprova que o aplicativo de foi instalado
com êxito e que não está faltando nenhum componente de
software principal?]

8. Critérios de Entrada e de Saída

8.1 Plano de Teste
8.1.1 Critérios de Entrada de Plano de Teste
[Especifique os critérios que serão usados para determinar se a execução do Plano de
Teste poderá ser iniciada.]
8.1.2 Critérios de Saída de Plano de Teste
[Especifique os critérios que serão usados para determinar se a execução do Plano de
Teste foi concluída ou se a continuação da execução não será vantajosa.]
8.1.3 Critérios de Suspensão e de Reinício
[Especifique os critérios que serão usados para determinar se os testes deverão ser
prematuramente suspensos ou concluídos antes que o plano tenha sido totalmente
executado. Especifique também segundo que critérios os testes poderão ser reiniciados.]
8.2 Ciclos de Teste
8.2.1 Critérios de Entrada de Ciclo de Teste
[Especifique os critérios que serão usados para determinar se o esforço do próximo
Ciclo de Teste deste Plano de Teste poderá ser iniciado.]
8.2.2 Critérios de Saída de Ciclo de Teste
[Especifique os critérios que serão usados para determinar se o esforço de teste do Ciclo
de Teste atual deste Plano de Teste é considerado suficiente.]
8.2.3 Término Anormal do Ciclo de Teste
[Especifique os critérios que serão usados para determinar se os testes deverão ser
prematuramente suspensos ou concluídos para o ciclo de teste atual, ou se o futuro build
a ser testado deverá ser alterado.]
9. Produtos Liberados
[Nesta seção, liste os vários artefatos que serão criados pelo esforço de teste e que
serão produtos liberados úteis aos vários envolvidos do esforço de teste. Não liste todos
os produtos do trabalho; liste apenas os que propiciam benefícios diretos tangíveis aos
envolvidos e os que permitem medir o êxito do esforço de teste.]
9.1 Sumários de Avaliação de Testes
[Forneça um breve resumo da forma e do conteúdo dos sumários de avaliação de testes
e indique com que frequência eles serão gerados.]
9.2 Geração de Relatórios sobre Cobertura de Teste
[Forneça um breve resumo da forma e do conteúdo dos relatórios usados para medir a
extensão do teste e indique com que frequência eles serão gerados Forneça uma
indicação referente ao método e às ferramentas usados para registrar, medir e reportar a
extensão do teste.]

9.3 Relatórios da Qualidade Perceptível

Forneça um breve resumo da forma e do conteúdo dos relatórios usados para medir a
qualidade perceptível do produto e indique com que frequência eles serão gerados.
Forneça uma indicação referente ao método e às ferramentas usados para registrar,
medir e reportar a qualidade perceptível do produto. Você poderá incluir análises dos
Incidentes e Solicitações de Mudança ao longo da Cobertura de Teste.]
9.4 Registros de Incidentes e Solicitações de Mudança

[Forneça um breve resumo do método e das ferramentas usados para registrar, rastrear e
gerenciar incidentes dos testes, as solicitações de mudança associadas e seus status.]
9.5 Conjunto de Testes de Regressão e Scripts de Teste de Suporte
[Forneça um breve resumo dos recursos dos testes que serão liberados para permitir
testes de regressão contínuos dos builds subsequentes do produto, a fim de ajudar a
detectar as regressões na qualidade do produto.]
9.6 Produtos de Trabalho Adicionais
[Nesta seção, identifique os produtos de trabalho que são opcionais ou os que não
 deverão ser usados para medir ou avaliar a execução bem-sucedida do Plano de Teste.]
9.6.1 Resultados Detalhados dos Testes
[Trata-se de um conjunto de planilhas do Microsoft Excel relacionando os resultados
determinados para cada caso de teste ou refere-se ao repositório dos registros de testes
e dos resultados determinados mantidos por um produto de teste especializado.]
9.6.2 Scripts de Teste Funcionais Automatizados Adicionais
Estes scripts consistem em um conjunto dos arquivos de código-fonte dos scripts de
teste automatizados ou no repositório do código-fonte e dos executáveis compilados
referentes aos scripts de teste mantidos pelo produto de automação de testes.]
9.6.3 Guia de Teste
[O Guia de Teste abrange um amplo conjunto de categorias incluindo Catálogos de Idéias
de Testes, Orientações de Práticas Adequadas, Padrões de Teste, Modelos de Erros e de
Falhas, Padrões de Design de Automação etc.]
9.6.4 Matrizes de Rastreabilidade
[Utilizando uma ferramenta como o Rational RequisistePro ou o Microsoft Excel, forneça
uma ou mais matrizes de relacionamentos de rastreabilidade entre os itens rastreados.]

10. Fluxo de Trabalho de Teste

[Forneça um resumo do fluxo de trabalho a ser seguido pela equipe de teste no
desenvolvimento e na execução deste Plano de Teste.
O fluxo de trabalho de teste específico que você usará deve ser documentado
separadamente no Caso de Desenvolvimento do projeto. Ele deve explicar como o
projeto personalizou o fluxo de trabalho de teste básico do RUP (normalmente fase a
fase). Na maior parte dos casos, é recomendável que, nesta seção do Plano de Teste,
você insira uma referência à seção relevante do Caso de Desenvolvimento. Poderá ser
útil e suficiente simplesmente incluir um diagrama ou uma imagem ilustrando o fluxo de
trabalho de teste.
Os detalhes mais específicos das tarefas de teste individuais poderão ser definidos de
várias maneiras diferentes, dependendo da cultura do projeto. Veja os exemplos a seguir:
poderão ser definidos como uma lista de tarefas nesta seção do Plano de Teste ou em
um apêndice complementar
poderão ser definidos em uma programação central do projeto (frequentemente em uma
ferramenta de programação como o Microsoft Project)
poderão ser documentados em listas de tarefas "dinâmicas" individuais para cada
membro da equipe, que geralmente são muito detalhadas para serem inseridas no Plano
de Teste
poderão ser documentados em um quadro branco localizado em um local central e
atualizado dinamicamente
poderão simplesmente não serem documentados formalmente
Com base na cultura de seu projeto, você deverá listar suas tarefas de teste específicas
aqui ou fornecer um texto descritivo explicando o processo utilizado por sua equipe para
efetuar o planejamento detalhado de tarefas. Você também poderá fazer referência ao
local em que os detalhes serão armazenados, se for adequado.
Para os Planos de Teste Mestre, é recomendável evitar o planejamento detalhado de
tarefas, que freqüentemente será um esforço improdutivo se efetuado como uma
atividade antecipada no início do projeto. Um Plano de Teste Mestre poderá descrever, de
maneira útil, as fases e o número de iterações, e fornecer uma indicação dos tipos de
teste que geralmente são planejados para cada Fase ou Iteração.
 Observação: Nos casos em que as informações referentes a processos e ao
planejamento detalhado forem registradas em um local central e separadamente deste
Plano de Teste, você terá que gerenciar os problemas originados pelo fato de existirem
cópias duplicadas das mesmas informações. Para evitar que os membros da equipe
consultem informações desatualizadas, é recomendável, nesse caso, inserir o mínimo
possível de informações sobre processos e planejamento no Plano de Teste para facilitar
a constante manutenção das informações e, portanto, simplesmente fazer referência ao
material que se encontra no "Plano Mestre".]
11. Necessidades Ambientais
[Esta seção apresenta os recursos não humanos necessários ao Plano de Teste.]
11.1 Hardware Básico do Sistema
Os conjuntos de tabelas a seguir apresentam os recursos do sistema necessários ao esforço
de teste descrito neste Plano de Teste.
[É possível que os elementos específicos do sistema de teste não sejam totalmente
compreendidos nas iterações iniciais, sendo assim, espera-se que esta seção seja
preenchida ao logo do tempo. É recomendável que o sistema simule o ambiente de
produção, reduzindo o acesso concorrente e o tamanho do banco de dados, se e quando
for necessário.]
[Observação: Adicione ou exclua itens conforme o necessário.]

Recurso Quantidade Nome e Tipo

Servidor de Banco de
Dados
Rede ou Sub rede
Nome do Servidor A ser definido
Nome do Banco de
Dados

A ser definido

A ser definido

PCs de Teste Cliente

Inclua requisitos de
configuração especiais

A ser definido

Repositório de Teste
Rede ou Sub-rede
Nome do Servidor
A ser definido

A ser definido
PCs de A ser definido
Desenvolvimento de
Teste

11.2 Elementos de Software Básicos do Ambiente de Teste

São necessários os seguintes elementos de software básicos no ambiente de teste deste
Plano de Teste.
[Observação: Adicione ou exclua itens conforme o necessário.]

Nome do Elemento de Versão Tipo e Outras Observações

Software

NT Workstation Sistema Operacional

Windows 2000 Sistema Operacional

Internet Explorer Navegador da Internet

Netscape Navigator Navegador da Internet

Microsoft Outlook Software Cliente de E-Mail

Network Associates Software de Detecção e

McAffee Virus Checker Recuperação de Vírus

11.3 Ferramentas de Produtividade e de Suporte

Serão utilizadas as seguintes ferramentas para suportar o processo de teste deste Plano de
Teste.
[Observação: Adicione ou exclua itens conforme o necessário.]

Categoria ou Tipo de Nome da Marca da Fornecedor ou Versão

Ferramenta Ferramenta Desenvolvida
Internamente

Gerenciamento de
Teste

Controle de Defeitos

Ferramenta ASQ para

teste funcional

Ferramenta ASQ para

teste de desempenho

Gerador de Perfil ou
Monitor de Cobertura
de Teste

Gerenciamento de
Projeto

Ferramentas DBMS
11.4 Configurações do Ambiente de Teste
Devem ser fornecidas e suportadas as seguintes Configurações de Ambiente de Teste para
este projeto.

Nome da Configuração Descrição Implementada na Configuração

Física

Configuração do usuário comum

Mínima configuração suportada

Motivada por funções visuais e

motoras

Sistema Operacional Internacional

de Dois Bytes

Instalação de Rede (não cliente)

12. Responsabilidades, Perfil da Equipe e Necessidades de Treinamento

[Esta seção apresenta os recursos necessários para abordar o esforço de teste no Plano
de Teste; as responsabilidades principais e os conjuntos de conhecimentos ou de
habilidades exigidos desses recursos.]
12.1 Pessoas e Papéis
Esta tabela mostra as suposições referentes ao perfil da equipe do esforço de teste.
[Observação: Adicione ou exclua itens conforme o necessário.]

Recursos Humanos

Papel Recursos Mínimos Responsabilidades ou

Recomendáveis Comentários Específicos
(número de papéis alocados em tempo
integral)

Gerente de Supervisiona o
Testes gerenciamento.
Entre as
responsabilidades estão
incluídas:
● planejamento e
logística
● combinar missão
● identificar
motivadores
● adquirir recursos
apropriados
● apresentar
relatórios de
gerenciamento
● defender os
interesses do
teste
 ● avaliar a eficiência
do esforço de
teste

Analista de Teste Identifica e define os teste

específicos a serem
conduzidos.
Entre as
responsabilidades estão
incluídas:
● identificar ideias
de teste
● definir detalhes
dos testes
● determinar os
resultados dos
testes
● documentar
solicitações de
mudança
● avaliar a qualidade
do produto

Designer de Teste Define a abordagem

técnica referente à
implementação do
esforço de teste.
Entre as
responsabilidades estão
incluídas:
● definir a
abordagem dos
testes
● definir a
arquitetura de
automação de
teste
● verificar as
técnicas de teste
● definir os
elementos de
testabilidade
● estruturar a
implementação
dos testes
Testador Implementa e executa os
testes.
Entre as
responsabilidades estão
incluídas:
● implementar os
testes e os
conjuntos de
testes
● executar os
conjuntos de
testes
● registrar os
resultados
● analisar as falhas
dos testes e
possibilitar a
recuperação
posterior
● documentar
incidentes

Administrador do Assegura a manutenção e

Sistema de Teste o gerenciamento dos
recursos e do ambiente
do teste.
Entre as
responsabilidades estão
incluídas:
● administrar o
sistema de
gerenciamento de
teste
● instalar e suportar
o acesso às
configurações do
ambiente de teste
e aos laboratórios
de teste, bem
como a
recuperação deles

Administrador do Assegurar o
Banco de Dados, gerenciamento e a
Gerente do Banco manutenção dos recursos
de Dados e do ambiente dos dados
de teste (banco de
dados).
Entre as
responsabilidades estão
incluídas:
 ● suportar a
administração dos
dados de teste e
das plataformas
de teste (banco de
dados)

Designer Identifica e define as

operações, os atributos e
as associações das
classes de teste.
Entre as
responsabilidades estão
incluídas:
● define as classes
de teste
necessárias para
suportar os
requisitos de
estabilidade
conforme definido
pela equipe de
teste

Implementador Implementa as classes de

teste e os pacotes de
teste e efetua testes
unitários nos mesmos.
Entre as
responsabilidades estão
incluídas:
● cria os
componentes de
teste necessários
para suportar os
requisitos de
testabilidade
conforme definido
pelo designer

12.2 Perfil da Equipe e Necessidades de Treinamento

Esta seção resume como abordar o perfil da equipe e o treinamento dos profissionais que
ocuparão os papéis de teste no projeto.
[O modo como abordar o perfil da equipe e o treinamento dos profissionais varia de
projeto para projeto. Se esta seção integrar um Plano de Teste Mestre, indique em que
pontos do ciclo de vida do projeto serão necessárias diferentes habilidades e um número
diferente de integrantes da equipe. Se for um Plano de Teste de Iteração, você deverá
concentrar-se principalmente em que momento, durante a Iteração, poderá ocorrer um
treinamento e de que tipo ele será.
Reflita sobre suas necessidades de treinamento e planeje uma programação de
treinamento com base em uma abordagem que sustente que o treinamento só deverá ser
realizado no momento certo. Há sempre a tentação de realizar o treinamento muito antes
 de quando ele será realmente necessário, em um período em que a equipe de teste esteja
aparentemente ociosa. Quando isso é feito, corre-se o risco de os ensinamentos do
treinamento já terem sido esquecidos justamente no momento em que forem
necessários.
Procure por oportunidades de combinar a compra de ferramentas de produtividade com
o treinamento dessas ferramentas e retarde o treinamento, de comum acordo com o
fornecedor, apenas para o momento em que for realmente necessário. Se tiver um
número de pessoas suficiente, é recomendável realizar um treinamento personalizado,
possivelmente no próprio local de sua organização.
Frequentemente, a equipe de teste necessita do suporte e das habilidades dos membros
de outras equipes, que não a integram de forma direta. Certifique-se de programar, no
seu plano, a participação adequada de Administradores de Sistema, Administradores de
Banco de Dados e Desenvolvedores, que são profissionais necessários para viabilizar o
esforço de teste.]

Observações:

O plano de teste é um dos documentos produzidos na condução de um projeto. Ele funciona

como:
- Um “integrador” entre diversas atividades de testes no projeto;
- Mecanismo de comunicação para os stakeholders (isto é a equipe de testes e
outros interessados);
- Guia para execução e controle das atividades de testes.

O plano de teste, que pode ser elaborado pelo gerente de projeto ou gerente de testes, visa
planejar as atividades a serem realizadas, definir os métodos a serem empregados, planejar a
capacidade necessária, estabelecer métricas e formas de acompanhamento do processo.

Estas são as tarefas relacionadas a teste:

1.Planejar Teste

2.Identificar os Requisitos de Teste

3.Avaliar o Risco

4.Desenvolver a Estratégia de Teste

5.Identificar os Recursos de Teste

6.Criar Programação
7.Gerar Plano de Teste

8.Projetar Teste

9.Análise da Carga de Trabalho

10.Identificar e Descrever Casos de Teste

11.Identificar e Estruturar Procedimentos de Teste

12.Revisar e Acessar a Cobertura de Teste

13.Implementar Teste

14.Registrar ou Programar Scripts de Teste

15.Identificar a funcionalidade específica de Teste no modelo

de design e de implementação

16.Estabelecer Conjuntos de Dados Externos

17.Executar Teste

18.Executar os Procedimentos de Teste

19.Avaliar a Execução do Teste

20.Recuperar-se de uma Interrupção de Teste

21.Verificar os Resultados

22.Investigar os Resultados Inesperados

23.Registrar Defeitos

24.Avaliar Teste

25.Avaliar Cobertura de Caso de Teste

26.Avaliar Cobertura de Código

27.Analisar os Defeitos

28.Determinar se os Critérios de Conclusão e os Critérios de

Sucesso do Teste foram obedecidos