|
Os bancos de dados e os processos de banco de dados devem 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
executar pesquisas adicionais referentes ao DBMS (Database Management System) 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 um comportamento de destino funcionalmente incorreto ou dados corrompidos.
|
|
Técnica:
|
Chamar cada processo e método de acesso a banco de dados, propagando cada um com dados válidos e
inválidos ou pedidos de dados.
Inspecionar o banco de dados para assegurar que os dados foram preenchidos conforme planejado e que
todos os eventos do banco de dados ocorreram adequadamente ou revisar os dados retornados para
assegurar que os dados corretos foram recuperados pelas razões corretas.
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 Especiais:
|
Os testes podem exigir drivers ou um ambiente de desenvolvimento DBMS para digitar ou modificar dados
diretamente no banco de dados.
Os processos devem ser chamados manualmente.
Bancos de dados pequenos ou de tamanho mínimo (com um número limitado de registros) devem ser
utilizados para aumentar a visibilidade de quaisquer eventos não aceitáveis.
|
Os teste de função do destino do teste deve ter como foco quaisquer requisitos de teste 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 através da GUI (Interface Gráfica com o Usuário) 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 destino do teste, incluindo a navegação, a entrada, o processamento e
a recuperação de dados a fim de observar e registrar o comportamento do destino.
|
|
Técnica:
|
Experimentar os recursos e fluxos ou funções de casos de uso individuais de cada cenário 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ócios será aplicada adequadamente
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente 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 autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 Especiais:
|
Identifique ou descreva os itens ou problemas (internos ou externos) que exercem influência sobre a
implementação e a execução do teste de função.
|
O Teste do Ciclo de Negócios deve emular as tarefas executadas no <Nome do Projeto> ao longo do tempo. Um período
deve ser identificado, como um ano, e as transações e as tarefas que ocorreriam nesse período de um ano devem ser
executadas. Isso inclui todos os ciclos diários, semanais e mensais, assim como eventos são sensíveis a datas como, por
exemplo, lembretes.
|
Objetivo da Técnica:
|
Experimentar processos de segundo plano e do destino do teste de acordo com os planejamentos e os
modelos de negócios necessários, a fim de observar e registrar o comportamento de destino.
|
|
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á adequadamente aplicada.
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente 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 autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 críticos.
|
|
Considerações Especiais:
|
As datas e os eventos do sistema podem exigir tarefas de suporte especial.
É necessário um modelo de negócios para identificar requisitos e procedimentos de teste adequados.
|
O Teste de UI (Interface com o Usuário) verifica a interação do usuário com o software. A meta do teste de UI é
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 esperado e estejam em conformidade com
padrões corporativos ou do segmento de mercado.
|
Objetivo da Técnica:
|
Experimentar o seguinte para observar e registrar a conformidade com padrões e o comportamento do
destino:
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 menus, tamanho, posição,
estado e foco.
|
|
Técnica:
|
Criar ou modificar 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:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica requer a Ferramenta de Automatização de Scripts de Teste.
|
|
Critérios de Êxito:
|
A técnica suporta o teste de cada tela ou janela principal que será utilizada extensivamente pelo
usuário.
|
|
Considerações Especiais:
|
Nem todas as propriedades de objetos personalizados e de terceiros podem ser acessadas.
|
O gerenciamento de perfis de desempenho é um teste de desempenho no qual tempos de resposta, taxas de transação e
outros requisitos sensíveis à hora são medidos e avaliados. A meta desse teste é 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.
Nota: as transações na tabela a seguir referem-se a "transações de negócios lógicos". Essas transações são
definidas como casos de uso específicos que se espera que um agente do sistema execute utilizando o objetivo do teste,
como incluir 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 a seguir, a fim de observar e registrar o comportamento de destino e os dados de desempenho
do aplicativo:
carga de trabalho antecipada normal
carga de trabalho antecipada no pior caso
|
|
Técnica:
|
Usar os procedimentos de teste desenvolvidos pelo Teste de Função ou Teste dos Ciclos de Negócio.
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 a seguir).
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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:
Transação única ou usuário único: Uma emulação bem-sucedida dos scripts de transação sem que ocorra
nenhum defeito devido a problemas de implementação do teste.
Transações múltiplas ou usuários múltiplos: Uma emulação bem-sucedida da carga de trabalho sem que
ocorra nenhum defeito devido a problemas de implementação do teste.
|
|
Considerações Especiais:
|
O teste abrangente do desempenho inclui ter uma carga de 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, normalmente no formato de chamadas SQL
(Linguagem de Consulta Estruturada).
Criar carga de usuário "virtual" para simular muitos clientes, normalmente 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 utilizada para carregar a rede com "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 executado 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 utilizados para Teste de Desempenho deverão ter tamanhos reais ou ser igualmente
escalados.
|
O teste de carga é um teste de desempenho que sujeita o destino do teste a diferentes cargas de trabalho para medir e
avaliar as capacidades e os comportamentos de desempenho dele, a fim de verificar se este continua a funcionar
adequadamente com 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, 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.
Nota: as transações na tabela a seguir referem-se a "transações de negócios lógicos". Essas transações são
definidas como funções específicas que um usuário do sistema deve desempenhar utilizando o aplicativo, como incluir 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 de destino e os dados de desempenho do sistema.
|
|
Técnica:
|
Utilize os Scripts de Teste de Transação desenvolvidos para os Testes de Ciclo de Negócios ou de Função
como uma base, mas lembre-se de remover as iterações e os retardos 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, por exemplo, cargas máximas 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:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 ocorra nenhum defeito devido a problemas de implementação do teste.
|
|
Considerações Especiais:
|
Os testes de carga devem ser executados em uma máquina dedicada e em um período de tempo dedicado. Isso
permitirá o controle total e a medição exata.
Os bancos de dados utilizados para teste de carga deverão ter tamanhos reais ou ser igualmente
escalados.
|
O teste de stress é um tipo de teste de desempenho implementado e executado para compreender como ocorrem falhas no
sistema devido a condições no limite, ou fora do limite, das tolerâncias esperadas. Normalmente, isso envolve poucos
recursos ou a concorrência de 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.
Nota: as referências às transações na tabela a seguir são de transações de negócios lógicos.
|
Objetivo da Técnica:
|
Experimentar as funções do destino do teste nas condições de stress a seguir a fim de observar e
registrar o comportamento de destino que identifica e documenta as condições sob as quais o sistema
deixa 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
volume ou conjunto de transação de "sobrecarga" (consulte Traçado de Perfil de Desempenho acima)
|
|
Técnica:
|
Usar os testes desenvolvidos pelo Perfil de Desempenho ou Teste de Carga.
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 utilizados 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:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 Stress. O sistema pode ser emulado, com êxito, em uma ou mais
condições definidas como condições de stress e uma observação do estado resultante do sistema poderá
ser capturada durante e após a emulação da condição.
|
|
Considerações Especiais:
|
Gerar stress na rede pode exigir ferramentas da rede para carregar a rede 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.
|
O teste de volume sujeita o destino do teste a grandes volumes de dados para determinar se serão atingidos limites que
farão com que o software deixe de funcionar. Esse teste também identifica o volume ou a carga máxima contínua que o
objetivo do teste pode suportar durante um determinado período de tempo. Por exemplo, se o destino do teste estiver
processando um conjunto de registros de banco de dados para gerar um relatório, um Teste de Volume utilizará 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 destino do teste nos seguintes cenários de elevado volume para observar e
registrar o comportamento de destino:
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.
O tamanho máximo do banco de dados foi alcançado (real ou escalado) e várias consultas ou transações de
relatório são executadas simultaneamente.
|
|
Técnica:
|
Usar os testes desenvolvidos pelo Perfil de Desempenho ou Teste de Carga.
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.
O tamanho máximo do banco de dados é criado (real, escalado ou preenchido com dados representativos) e
vários clientes são utilizados para executar consultas e transações de relatório simultaneamente por
longos períodos.
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 uso do sistema em volume e poderá ser
capturada uma observação sobre as mudanças de estado do sistema durante o teste de volume.
|
|
Considerações Especiais:
|
Qual período de tempo seria considerado aceitável em condições de alto volume, conforme mencionado
anteriormente?
|
O Teste de Segurança e de Controle de Acesso tem como foco duas áreas principais de segurança:
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 do cliente, incluindo
dados financeiros; no entanto, "o tipo de usuário dois" verá apenas os dados pessoais desse mesmo cliente.
A segurança no nível do sistema assegura que apenas os usuários, para os quais o acesso ao sistema foi concedido, sejam
capazes de acessar os aplicativos e apenas por meio dos gateways apropriados.
|
Objetivo da Técnica:
|
Experimentar o destino do teste nas condições a seguir, para observar e registrar o comportamento de
destino:
Segurança no Nível de Aplicativo: um agente pode acessar somente as funções ou os dados para os quais
seu tipo de usuário tenha recebido permissão.
Segurança no Nível de 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 de Aplicativo: Identifique e liste cada tipo de usuário e as funções ou os dados
para os quais cada tipo tem permissão.
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 de Sistema: Consulte as Considerações Especiais a seguir.
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
Ferramenta de Automação de Scripts de Teste
Ferramentas de investigação e contra violação da segurança por "hacker"
Ferramentas de Administração de Segurança do S.O.
|
|
Critérios de Êxito:
|
A técnica suporta o teste das funções apropriadas ou é possível testar os dados afetados pelas
configurações de segurança para cada tipo de agente conhecido.
|
|
Considerações Especiais:
|
O acesso ao sistema deve ser revisado ou discutido com o administrador da rede ou do sistema
apropriado. Talvez esse teste não seja necessário, pois pode ser uma função de administração da rede ou
do sistema.
|
O teste de failover e de recuperação assegura que o destino do teste possa efetuar failover e se recuperar com êxito 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 failover assegura que, ao ocorrer uma condição de
failover, os sistemas alternativos ou de backup "assumam" adequadamente o sistema com falha 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 chamados e o aplicativo ou o sistema é
monitorado e inspecionado para verificar se foi efetuada a recuperação adequada do aplicativo ou do sistema e dos
dados.
|
Objetivo da Técnica:
|
Simular as condições de defeito 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
interrupção, perda de comunicação ou de energia para o DASD (Direct Access Storage Devices) 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álidas
elementos de dados inválidos ou corrompidos no banco de dados
|
|
Técnica:
|
Os testes de Função e de Ciclo de Negócios já criados podem ser utilizados como uma base para criar uma
série de transações para suportar os testes de failover e de recuperação, principalmente para definir
os testes a serem executados para verificar se a recuperação teve êxito.
Interrupção de energia para o cliente: desligue o PC.
Interrupção de energia para o servidor: simule ou inicie procedimentos de desligamento do servidor.
Interrupção via 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).
Interrupção, perda de comunicação ou de energia para o 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). Transações adicionais deverão ser executadas
utilizando os Testes de Ciclo de Negócios e de Função do Aplicativo e deverão ser executados ciclos
completos.
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 Especiais:
|
O teste de recuperação é altamente invasivo. Os 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 ou em uma máquina isolada.
|
O teste de configuração verifica a operação do destino 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 estar ativas utilizando diferentes recursos.
|
Objetivo da Técnica:
|
Experimentar o destino do teste nas configurações de hardware e de software necessárias, a fim de
observar e registrar o comportamento do destino em diferentes configurações e identificar mudanças no
estado da configuração.
|
|
Técnica:
|
Utilize scripts de Teste de Função.
Abra e feche vários softwares relacionados que não sejam o destino do teste, como os aplicativos
Microsoft® Excel® e Microsoft® 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:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 do teste de destino executados em
ambientes de implementação suportados esperados.
|
|
Considerações Especiais:
|
Que software que não seja o destino do teste é necessário, está disponível e acessível no desktop?
Quais os aplicativos 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.
|
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 significa executar uma série de testes que foram desenvolvidos para Teste de
Função.
|
Objetivo da Técnica:
|
Experimentar a instalação do destino 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 o <Nome do Projeto>
atualização: uma máquina em que a mesma versão do <Nome do Projeto> tenha sido instalada
atualização: uma máquina em que uma versão antiga do <Nome do Projeto> tenha sido instalada
|
|
Técnica:
|
Desenvolva scripts automatizados ou manuais para validar a condição da máquina de destino.
nova: <Nome do Projeto> nunca instalado
<Nome do Projeto> a mesma versão ou uma versão mais antiga já instalada
Inicie ou execute a instalação.
Utilizando um subconjunto predeterminado de scripts de Teste de Função, execute as transações.
|
|
Estratégias:
|
Contornar uma ou mais estratégias que podem ser utilizadas pelo técnico para observar exatamente os
resultados do teste. A estratégia combina o método através do qual a observação pode ser feita e as
características dos resultados específicos que indicam um provável êxito ou falha do teste. O ideal é
que as estratégias sejam autoverificadas, 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 Necessárias:
|
A técnica exige as seguintes ferramentas:
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 Especiais:
|
Quais transações de <Nome do Projeto> devem ser selecionadas para constituir um teste que
comprove que o aplicativo <Nome do Projeto> foi instalado com êxito e que não está faltando
nenhum componente de software principal?
|
|
