Diretrizes:  Caso de Teste

Caso de Teste

Um Caso de teste é um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para um objetivo específico como, por exemplo, testar o caminho de determinado programa ou verificar o cumprimento de um requisito específico.

Tópicos

• Explicação
• Obtenção de Casos de Teste a partir de Casos de Uso
• Obtenção de Casos de Teste a partir de Especificações Suplementares

  • Obtenção de Casos de Teste para Testes de Desempenho
  • Obtenção de Casos de Teste para Testes de Acesso/Segurança
  • Obtenção de Casos de Teste para Testes de Configuração
  • Obtenção de Casos de Teste para Testes de Instalação
  • Obtenção de Casos de Teste para Outros Testes Não Funcionais

• Obtenção de Casos de Teste para Testes Unitários

• Testes caixa branca
• Testes caixa preta

• Obtenção de Casos de Teste para o Teste de Aceitação do Produto
• Criação de Casos de Teste Para o Teste de Regressão

Explicação

Nada proporciona satisfação maior ao usuário final, com relação ao software, do que uma visão clara de suas expectativas, para que sejam verificadas e validadas. Os casos de teste refletem os requisitos que devem ser verificados. Entretanto, a verificação desses requisitos pode ser feita de forma diferente e por testadores distintos. Por exemplo, a execução do software para verificar sua função e desempenho pode ser feita por um testador usando técnicas de teste automatizadas, a seqüência de desligamento de um sistema de computadores pode ser realizada por teste manual e observação, ao passo que a participação no mercado e as vendas (também requisitos do produto) serão realizadas através da avaliação do produto e das vendas competitivas.

Como talvez você não consiga verificar todos os requisitos, nem seja responsável por isso, é essencial para o sucesso do projeto selecionar os requisitos mais apropriados e importantes para o teste. Os requisitos escolhidos para verificação representarão um equilíbrio entre o custo, o risco e a necessidade de verificá-los.

A identificação dos casos de teste é importante por vários motivos.

• Os casos de teste constituem a base do design e do desenvolvimento dos Scripts de Teste.
• A "profundidade" do teste é proporcional ao número de casos de teste. O aumento do número de casos de teste gera uma maior confiança na qualidade do produto e no processo de teste, já que cada caso de teste reflete um cenário, uma condição ou um fluxo diferente através do produto.
• A principal avaliação da abrangência do teste é a cobertura baseada em requisitos, de acordo com o número de casos de teste identificados, implementados e/ou executados. Uma sentença como "Executamos e verificamos 95% dos casos de teste críticos" é mais significativa do que a sentença "Já executamos 95% do total de testes".
• A escala do esforço de teste é proporcional ao número de casos de teste. Com uma análise abrangente dos casos de teste, é possível estimar com mais precisão a duração dos estágios subseqüentes do ciclo de teste.
• Os tipos de design e desenvolvimento de testes e os recursos necessários são amplamente controlados pelos casos de teste.

Geralmente, os casos de teste são categorizados ou classificados pelo tipo ou requisito de teste ao qual estão associados e variam de acordo com isso. A melhor prática consiste em desenvolver pelo menos dois casos de teste para cada requisito de teste:

• um caso de teste para demonstrar que o requisito foi atendido, geralmente conhecido como um caso de teste positivo,
• outro caso de teste, conhecido como negativo, refletindo uma condição ou dados inaceitáveis, anormais ou inesperados para demonstrar que o requisito só pode ser atendido sob a condição desejada.

Obtenção de Casos de Teste a partir de Casos de Uso

Os casos de teste para o teste funcional são derivados de casos de uso do objetivo do teste (consulte Artefato: Caso de Uso). É necessário desenvolver casos de teste para cada cenário de caso de uso. Os cenários de caso de uso são identificados através da descrição dos caminhos que percorrer o fluxo básico e os fluxos alternativos, do início ao fim, através do caso de uso.  

No diagrama a seguir, por exemplo, os vários caminhos através de um caso de uso, que refletem o fluxo básico e os fluxos alternativos, são representados com as setas. O fluxo básico, representado pela linha preta e reta é o caminho mais simples através do caso de uso. Cada fluxo alternativo começa no fluxo básico e, depois, de acordo com uma condição específica, é executado. Os fluxos alternativos podem retornar ao fluxo básico (fluxos alternativos 1 e 3), podem originar-se de outro fluxo alternativo (fluxo alternativo 2), ou podem terminar o caso de uso sem retornar a um fluxo (fluxos alternativos 2 e 4).

Exemplos de Fluxos de Eventos em um caso de uso

Após cada caminho possível através do caso de uso mostrado no diagrama acima, é possível identificar os diversos cenários de caso de uso. Começando pelo fluxo básico e depois combinando esse fluxo com os fluxos alternativos, é possível identificar os seguintes cenários de caso de uso: 

OBSERVAÇÃO:  Por praticidade, os Cenários 5, 6 e 8 apenas descrevem uma única execução do loop indicado pelo Fluxo Alternativo 3.    

É possível obter os casos de teste para cada cenário através da identificação da condição específica que causará a execução desse cenário de caso de uso específico.

Por exemplo, suponha que o caso de uso descrito no diagrama acima indicou o seguinte para o Fluxo Alternativo 3:

"Ocorrerá esse fluxo de eventos se o valor digitado no Passo 2 acima, "Digitar o Valor da Retirada" for maior que o saldo atual da conta. O sistema exibirá uma mensagem de aviso e, depois, retornará ao Passo 2 do fluxo básico "Digitar o Valor da Retirada" acima, onde o cliente do banco poderá digitar um novo valor de retirada."

Com essas informações, você pode começar a identificar os casos de teste necessários para a execução do fluxo alternativo 3:

OBSERVAÇÃO: os casos de teste mostrados acima são muito simples, já que nenhuma outra informação foi fornecida. Os casos de teste raramente são tão simples. 

Veja a seguir um exemplo mais realista de obtenção de casos de teste a partir de casos de uso.

Exemplo:

Atores e casos de uso em um caixa eletrônico.

A tabela a seguir contém o fluxo básico e alguns fluxos alternativos para o caso de uso Retirada em Dinheiro no diagrama acima:

É possível obter os cenários a seguir a partir desse caso de uso

OBSERVAÇÃO:  Por praticidade, os loops nos Fluxos alternativos 3 e 6 (Cenários 3 e 7) e as combinações de loops não foram incluídos na tabela acima.   

Para cada um desses sete cenários, é necessário identificar casos de teste. É possível identificar e gerenciar os casos de teste usando matrizes ou tabelas de decisão. Veja a seguir um formato comum, em que cada linha representa um caso de teste individual, e as colunas identificam informações de caso de teste.  Nesse exemplo, para cada caso de teste, há um ID, uma Condição (ou descrição) e todos os elementos que participam do caso de teste (como entrada ou já no banco de dados) e o resultado esperado. 

Para desenvolver a matriz, primeiro identifique quais elementos de dados são necessários para a execução dos cenários de caso de uso. Em seguida, para cada cenário, identifique pelo menos um caso de teste que contenha a condição apropriada para executar o cenário. Por exemplo, na matriz a seguir, V (válido) é usado para indicar que essa condição deve ser VÁLIDA para que o fluxo seja executado, e I (inválido) é usado para indicar a condição que disparará o fluxo alternativo desejado. Na tabela a seguir, "n/a" indica que essa condição não é aplicável ao caso de teste.

Na matriz acima, os seis casos de teste executam os quatro cenários. Para o Fluxo Básico, o caso de teste CW1 acima é denominado caso de teste positivo. Ele executa, sem desvios, o caminho do Fluxo Básico através do caso de uso. O teste abrangente do Fluxo Básico deve incluir casos de teste negativos para garantir que esse fluxo só seja utilizado quando as condições estiverem corretas. Os casos de teste negativos são representados pelos casos de teste CW2 a 6 (a célula sombreada indica a condição necessária para executar os fluxos alternativos). Embora esses casos de teste sejam negativos para o Fluxo Básico, são positivos para os Fluxos alternativos 2 a 4, e existe pelo menos um caso de teste negativo em cada um desses Fluxos Alternativos (CW1 - o Fluxo Básico).  

O Cenário 4 é um exemplo em que não é suficiente haver apenas um caso de teste positivo e um negativo por cenário. Para testar completamente o Cenário de teste 4 - Senha Incorreta, são necessários pelo menos três casos de teste positivos (para disparar o Cenário 4):

• a senha incorreta é digitada, há novas tentativas, e esse Fluxo Alternativo retorna ao Passo 3 do Fluxo Básico - Digitar a Senha)
• A senha incorreta é digitada, não há novas tentativas, esse Fluxo Alternativo retém o cartão e termina o caso de uso.
• a senha CORRETA é digitada quando não há mais novas tentativas.  Esse Fluxo Alternativo retorna ao Passo 5 do Fluxo Básico - Digitar o Valor. 

Observe que, na matriz acima, nenhum valor real foi digitado para as condições (dados). A vantagem de criar a matriz do caso de teste dessa maneira é a facilidade de ver as condições que estão sendo testadas. Também é muito fácil determinar se casos de teste suficientes foram identificados, já que você precisa apenas observar os Vs e Is (ou como feito aqui - as células sombreadas). Na tabela acima, há diversas condições para as quais não há células sombreadas. Portanto, estão faltando casos de teste como, por exemplo, para o Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto e para o Cenário 7 - Saldo Insuficiente em Conta.

Depois que todos os casos de teste forem identificados, será necessário revisá-los e validá-los para garantir a exatidão e adequação, bem como para eliminar casos de teste redundantes ou equivalentes. Consulte Pontos de Verificação: Caso de Teste para obter mais detalhes.

Após a aprovação dos casos de teste, será possível identificar os valores reais dos dados (na matriz de implementação do caso de teste) e criar os dados de teste (consulte Diretrizes: Dados de Teste para obter mais informações sobre os dados de teste).

Os casos de teste acima são apenas alguns dos necessários para verificar o Caso de Uso de Retirada em Dinheiro, referente a essa iteração. Outros casos de teste necessários contêm:

• Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto: Conta não encontrada ou não disponível
• Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto: A conta não permite retiradas
• Cenário 7 - Saldo em Conta Insuficiente: Valor solicitado maior que o valor contido na conta.

Em futuras iterações, quando outros fluxos forem implementados, os casos de teste serão necessários para:

• Cartões inválidos (informa-se que o cartão foi perdido, roubado, não é de um banco aceito, tem uma tarja danificada etc.)
• Incapacidade de ler um cartão (o leitor de cartões está obstruído, fora de linha ou com defeito)
• A conta está fechada, paralizada ou de outra maneira indisponível
• O valor no caixa eletrônico é insuficiente ou incapaz de compor o valor solicitado (diferente do CW3, visto que uma denominação está fora, mas não todas)
• Incapaz de entrar em contato com o sistema bancário para aprovação
• A rede do banco está fora de linha ou há uma falha de energia durante a transação

Ao identificar os casos de teste funcionais, verifique se:

• foram identificados casos de teste suficientes, positivos e negativos, para cada cenário de caso de uso 
• os casos de teste abordam qualquer regra de negócio implementada pelos casos de uso, garantindo que haja casos de teste, dentro, fora e na condição ou no valor de fronteira da regra de negócio
• os casos de teste abordam quaisquer seqüências de eventos ou ações, como aquelas identificadas nos diagramas de seqüência do modelo de design, ou estados ou as condições de objetos de interface do usuário.
• os casos de teste abordam qualquer requisito especial definido para o caso de uso, como o desempenho mínimo/máximo, às vezes combinado com as cargas ou os volumes de dados mínimos/máximos durante a execução dos casos de uso.

Consulte também Diretrizes: Dados de Teste para obter informações adicionais sobre os dados de teste.

Obtenção de Casos de Teste a partir de Especificações Suplementares

Nem todos os requisitos de um objetivo de teste serão refletidos em casos de uso. Requisitos não-funcionais, como desempenho, segurança e acesso, e requisitos de configuração especificam comportamentos ou características adicionais do objetivo do teste. A Especificação Suplementar é a principal fonte de obtenção de casos de teste para esses comportamentos adicionais.

Veja a seguir as diretrizes para obtenção desses casos de teste adicionais:

• Obtenção de Casos de Teste para Testes de Desempenho
• Obtenção de Casos de Teste para Testes de Segurança/Acesso
• Obtenção de Casos de Teste para Testes de Configuração
• Obtenção de Casos de Teste para Testes de Instalação
• Obtenção de Casos de Teste para outros testes não-funcionais

Obtenção de Casos de Teste para o Teste de Desempenho

A principal entrada para os casos de teste de desempenho são as Especificações Suplementares que contêm os requisitos não-funcionais (consulte Artefato: Especificações Suplementares). Use as seguintes diretrizes ao obter casos de teste para o teste de desempenho:

• verifique se há pelo menos um caso de teste identificado para cada sentença na especificação suplementar, que indica um critério de desempenho. Geralmente, os critérios de desempenho são expressos como tempo por transação, número de transações/usuários ou percentis.
• verifique se há pelo menos um caso de teste identificado para cada caso de uso crítico. Os casos de uso críticos são aqueles identificados nas sentenças acima e/ou no documento de análise de carga de trabalho (consulte Artefato: Documento de Análise de Carga de Trabalho), que deve ser avaliado através de medidas de desempenho.

Como nos casos de teste para testes funcionais, normalmente haverá mais de um caso de teste por caso de uso/requisito. É mais comum haver um caso de teste que esteja abaixo do valor limite de desempenho, outro no valor limite e um terceiro acima desse valor.

Além dos critérios de desempenho acima, verifique se você conseguiu identificar as condições específicas que afetam os tempos de resposta, inclusive:

• Tamanho do banco de dados - quantos registros existem?
• Carga de trabalho - número e tipo de usuários finais simultâneos, número e tipo de transações simultâneas em execução
• Características do ambiente (configuração de hardware, netware e software)

Capture casos de teste para o teste de desempenho em matrizes semelhantes às usadas para o teste funcional.

Consulte também Diretrizes: Dados de Teste para obter informações adicionais sobre os dados de teste.

Veja a seguir alguns exemplos dos diferentes tipos de Testes de Desempenho:

Para o Teste de Carga:

Para o Teste de Esforço:

Obtenção de Casos de Teste para Segurança/Testes de Acesso

Os atores e os casos de uso descrevem a interação entre os usuários externos do sistema e as ações executadas pelo sistema a fim de gerar um valor para determinado ator. Os sistemas complexos contêm vários atores, e é essencial desenvolvermos casos de teste para garantir que apenas esses atores especificados executem os casos de uso. Isso ocorrerá especialmente se houver diferenças no fluxo de eventos do caso de uso com base no tipo de ator.

Por exemplo, nos casos de uso de caixas eletrônicos, será possível executar diversos fluxos de eventos de caso de uso para o ator "Cliente de Banco" se seu cartão e sua conta forem do banco que possui o caixa eletrônico versus o "Cliente de Banco" que usa um cartão (e conta) de um banco concorrente, ou tenta usar um cartão bancário não participante.

Siga as mesmas diretrizes listadas acima para os casos de teste funcionais.

Consulte também Diretrizes: Dados de Teste para obter informações adicionais sobre os dados de teste.

Exemplo de casos de teste para Segurança e Acesso:

Obtenção de Casos de Teste para Testes de Configuração

Em sistemas distribuídos comuns, pode haver várias combinações de hardware e software permitidas que serão suportadas. O teste deve ser executado para verificar se o objetivo do teste funciona ou é executado de forma aceitável em configurações distintas, como em diversos sistemas operacionais, navegadores ou velocidades de CPU. Além disso, o teste também precisa abranger combinações de componentes para detectar defeitos provenientes de interações dos diversos componentes, por exemplo, garantir que a versão das DLLs instaladas por um aplicativo não entre em conflito com as versões das mesmas DLLs esperadas por outro aplicativo.

Para obter casos de teste para testes de configuração, use as seguintes diretrizes:

• Verifique se há pelo menos um caso de teste identificando cada configuração crítica. Para isso, basta identificar as configurações de hardware e software necessárias para o ambiente de objetivo do teste e priorizar as configurações, garantindo que as mais comuns sejam testadas primeiro, inclusive:
  • Suporte a impressoras
  • Conexões de rede - redes locais e de longa distância
  • Configurações de servidor - drivers e hardware de servidor
  • Outros softwares instalados na área de trabalho e/ou servidores
  • Versões de software para todos os softwares instalados
• Verifique se há pelo menos um caso de teste para cada configuração suscetível a problemas. Essas configurações podem conter:
  • Hardware com o pior desempenho.
  • Software co-residente com um histórico de problemas de compatibilidade.
  • Clientes que acessam o servidor através da conexão LAN/WAN mais lenta possível.
  • Recursos insuficientes (CPU lenta, memória ou resolução mínima, espaço em disco etc.)

Obtenção de Casos de Teste para Testes de Instalação

O teste de instalação precisa verificar se é possível instalar o objetivo do teste em todos os possíveis cenários de instalação. Os cenários de instalação podem incluir a instalação do objetivo do teste pela primeira vez ou a instalação de uma nova versão ou build desse objetivo de teste (em uma máquina com a versão anterior). O teste de instalação também deve garantir que o objetivo do teste seja executado de forma aceitável quando ocorrerem condições anormais, como espaço em disco insuficiente.

Os casos de teste devem abranger os cenários de instalação do software, inclusive:

• Mídia de distribuição, por exemplo, disquetes, CD-ROM ou servidor de arquivos.
• Nova instalação.
• Instalação completa.
• Instalações personalizadas.
• Instalações de atualização.

Os programas de instalação para software cliente-servidor têm um conjunto especializado de casos de teste. Diferente dos sistemas baseados em host, o programa de instalação geralmente é dividido entre o servidor e o cliente. Desse modo, é importante que o teste de instalação execute a instalação de todos os componentes do objetivo do teste, inclusive o cliente, as camadas intermediárias e os servidores.

Obtenção de Casos de Teste para outros Testes Não Funcionais

O ideal é que você encontre todos os recursos necessários para obter os casos de teste nos artefatos Modelo de Casos de Uso, Modelo de Design e Especificação Suplementar. Contudo, não é incomum que, nesse ponto, você precise complementar o que for encontrado.

Estes são alguns exemplos:

• Casos de teste para Testes Operacionais (para verificar se o software funciona quando em uso por "muito tempo" entre falhas).
• Casos de teste que investigam gargalos de desempenho, recursos de volume do sistema ou forçam uma falha no objetivo do teste.

Na maioria dos casos, você pode encontrar esses casos de teste criando variáveis ou agregados dos casos de teste que você obteve a partir daqueles identificados anteriormente.

Obtenção de Casos de Teste para o Teste Unitário

O teste unitário exige a avaliação da estrutura interna da unidade e de suas características comportamentais. O teste da estrutura interna exige  conhecimento de como a unidade foi implementada. Os testes baseados nesse conhecimento são denominados testes caixa branca. O teste das características comportamentais de uma unidade concentram-se nos comportamentos da unidade que podem ser observados externamente, sem conhecimento nem preocupação com sua implementação. Os testes baseados nesse método são conhecidos como testes caixa preta. A obtenção de casos de teste com base nos dois métodos é descrita a seguir.

Testes Caixa Branca

Teoricamente, você deve testar todo caminho possível através do código. Atingir essa meta nas unidades, embora sejam muito simples, é impraticável ou quase impossível. Na pior das hipóteses, você deve testar todos os caminhos decisão-a-decisão (caminho DD) pelo menos uma vez, o que resulta na execução de todas as instruções. Em geral, uma decisão é uma instrução if, e um caminho DD é aquele que une duas decisões.

Para atingir esse nível de cobertura de teste, recomenda-se escolher dados de teste que permitam avaliar cada decisão de todas as maneiras possíveis. Com essa finalidade, os casos de teste devem garantir que:

• Toda Boolean expression produza como resultado true e false. Por exemplo, a expressão (a<3) OR (b>4) produz como resultado quatro combinações de true/false
• Todo loop infinito é testado uma ou mais vezes, ou então não é testado.

Use as ferramentas de cobertura de código para identificar o código não experimentado pelo teste caixa branca. O teste de confiabilidade deve ser realizado simultaneamente com o teste caixa branca.

Exemplo:

Suponha que você execute um teste de estrutura em uma função que seja membro da classe Conjunto de Inteiros. O teste - com a ajuda de uma pesquisa binária - verifica se o conjunto contém determinado inteiro.

A função-membro e seu fluxograma correspondente. As setas pontilhadas ilustram como você pode usar dois casos de teste para executar todas as instruções pelo menos uma vez.

Teoricamente, para que uma operação seja totalmente testada, o caso de teste deve percorrer todas as combinações de rotas contidas no código. No membro, há três rotas alternativas dentro do while-loop. O caso de teste pode percorrer o loop várias vezes ou nenhuma. Se o caso de teste não percorrer o loop, haverá apenas uma rota através do código. Se ele percorrer o loop uma vez, haverá três rotas. Se percorrer duas vezes, haverá seis rotas e assim por diante. Portanto, o número total de rotas será 1+3+6+12+24+48+..., o que, na prática, é um número não gerenciável de combinações de rota. Esse é o motivo pelo qual você deve escolher um subconjunto de todas as rotas. Neste exemplo, você pode usar dois casos de teste para executar todas as instruções. Em um caso de teste, você pode escolher Conjunto de Inteiros = {1,5,7,8,11} e t = 3 como os dados de teste. No outro caso de teste, você pode escolher Conjunto de Inteiros = {1,5,7,8,11} e t = 8.

Consulte Diretrizes: Teste Unitário para obter informações adicionais

Testes Caixa Preta

A finalidade de um teste caixa preta é verificar o comportamento especificado da unidade, sem observar como a unidade implementa esse comportamento. Os testes caixa preta se concentram e se baseiam na entrada e saída da unidade.

Particionamento de equivalência é uma técnica destinada a reduzir o número de testes necessário. Para cada operação, você deve identificar as classes de equivalência dos argumentos e os estados dos objetos. Uma classe de equivalência é um conjunto de valores de acordo com o qual o objeto deve se comportar. Por exemplo, um Conjunto contém três classes de equivalência: vazio, algum elemento e cheio.

Use as ferramentas de cobertura de código para identificar o código não experimentado pelo teste caixa branca. O teste de confiabilidade deve ser realizado simultaneamente com o teste caixa preta.

As duas subseções a seguir descrevem como identificar os casos de teste através da seleção dos dados deteste para argumentos específicos.

Casos de Teste baseados em Argumentos de Entrada

Um argumento de entrada é aquele usado por uma operação. Você deve criar casos de teste usando argumentos de entrada para cada operação, em cada uma das seguintes condições de entrada: 

• Valores normais de cada classe de equivalência.
• Valores na fronteira de cada classe de equivalência.
• Valores fora das classes de equivalência.
• Valores inválidos.

Lembre-se de tratar o estado do objeto como um argumento de entrada. Se, por exemplo, você testar uma operação de adição em um Conjunto de objetos, deverá testar a adição com valores de todas as classes de equivalência do Conjunto, ou seja, com um Conjunto completo, com algum elemento no Conjunto e com um Conjunto vazio.

Casos de Teste baseados em Argumentos de Saída

Um argumento de saída é aquele alterado por uma operação. Um argumento pode ser de entrada ou de saída. Selecione a entrada para que a saída esteja de acordo com o seguinte:

• Valores normais de cada classe de equivalência.
• Valores na fronteira para cada classe de equivalência.
• Valores fora das classes de equivalência.
• Valores inválidos.

Lembre-se de tratar o estado do objeto como um argumento de saída. Se, por exemplo, você testar uma operação de exclusão em uma Lista, deverá escolher valores de entrada de modo que a Lista fique cheia, contenha algum elemento ou fique vazia após a execução da operação (teste com valores de todas as respectivas classes de equivalência).

Se o objeto for controlado por estado (a reação varia de acordo com o estado do objeto), você deve usar uma matriz de estado, conforme a mostrada na figura a seguir.

Uma matriz de estado para teste. Você pode testar todas as combinações de estado e de estímulos na base da matriz.

Consulte Diretrizes: Teste Unitário para obter informações adicionais

Obtenção de Casos de Teste para o Teste de Aceitação do Produto

O teste de aceitação do produto é o teste final antes da implantação do software. O objetivo desse teste é verificar se o software está pronto e pode ser usado pelos usuários finais para executar as funções e as tarefas para as quais o software foi criado. Esse teste geralmente envolve mais do que a verificação da integridade do software. Também envolve todos os artefatos de produto fornecidos ao(s) cliente(s), como treinamento, documentação e pacotes. 

É possível obter casos de teste para o(s) artefato(s) de software de acordo com o descrito nas seções anteriores. Dependendo do grau e da formalidade do teste de aceitação do produto, os casos de teste serão iguais ou semelhantes aos identificados acima (formais) ou um subconjunto (informais). Independentemente da profundidade dos casos de teste, é necessário haver um acordo entre eles e o Plano de Aceitação do Produto antes que o teste do produto seja implementado e executado.

A avaliação dos artefatos que não são de software varia principalmente de acordo com o artefato que está sendo avaliado. Consulte as Diretrizes e as Listas de Verificação de cada artefato específico que não seja de software para obter informações sobre a finalidade e a maneira de avaliá-lo.

Criação de Casos de Teste para o Teste de Regressão

O teste de regressão compara dois builds ou duas versões do mesmo objetivo de teste e identifica diferenças como possíveis defeitos. Desse modo, ele pressupõe que uma nova versão deve se comportar como uma versão anterior e verifica se defeitos não foram introduzidos como resultado das mudanças.

O ideal é que todos os casos de teste em uma iteração sejam usados como casos de teste nas iterações posteriores. Use as diretrizes a seguir para identificar, criar e implementar os casos de teste que maximizam o valor do teste de regressão e da reutilização, ao mesmo tempo que minimizam a manutenção:

• Garanta que o caso de teste identifique apenas os elementos de dados críticos (os necessários para criar/suportar a condição que está sendo testada)
• Garanta que cada caso de teste descreva ou represente um conjunto exclusivo de entradas ou uma seqüência de eventos que resulte em um comportamento exclusivo do objetivo do teste.
• Elimine casos de teste redundantes ou equivalentes
• Agrupe os casos de teste cujo estado inicial do objetivo do teste e cujo estado dos dados de teste sejam os mesmos

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process