Diretrizes:
|
Cenário 1 | Fluxo Básico | |||
---|---|---|---|---|
Cenário 2 | Fluxo Básico | Fluxo Alternativo 1 | ||
Cenário 3 | Fluxo Básico | Fluxo Alternativo 1 | Fluxo Alternativo 2 | |
Cenário 4 | Fluxo Básico | Fluxo Alternativo 3 | ||
Cenário 5 | Fluxo Básico | Fluxo Alternativo 3 | Fluxo Alternativo 1 | |
Cenário 6 | Fluxo Básico | Fluxo Alternativo 3 | Fluxo Alternativo 1 | Fluxo Alternativo 2 |
Cenário 7 | Fluxo Básico | Fluxo Alternativo 4 | ||
Cenário 8 | Fluxo Básico | Fluxo Alternativo 3 | Fluxo Alternativo 4 |
Nota: Por praticidade, os Cenários 5, 6 e 8 descrevem apenas 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:
"Este fluxo de eventos ocorrerá se o valor em dólar digitado na Etapa 2 anterior, "Digitar o Valor da Retirada" for maior que o saldo atual da conta. O sistema exibe uma mensagem de aviso e, em seguida, torna a unir o fluxo básico na Etapa 2 "Digitar o Valor da Retirada" anterior, em que o cliente do banco pode 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:
ID de Caso de Teste | Cenário | Condição | Resultado Esperado |
---|---|---|---|
TC x | Cenário 4 | Etapa 2 - Valor da Retirada > Saldo da Conta | Retorna à Etapa 2 do fluxo básico |
TC y | Cenário 4 | Etapa 2 - Valor da Retirada < Saldo da Conta | Não executa o Fluxo Alternativo 3, segue o fluxo básico |
TC z | Cenário 4 | Etapa 2 - Valor da Retirada = Saldo da Conta | Não executa o Fluxo Alternativo 3, segue o fluxo básico |
Nota: os casos de teste mostrados anteriormente são muito simples, já que nenhuma outra informação foi fornecida. Os casos de teste raramente são tão simples.
Um exemplo mais realista de derivação de casos de teste a partir dos casos de uso é fornecido a seguir:
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:
Fluxo Básico | Esse Caso de Uso começa com o caixa eletrônico no Estado Pronto.
O Caso de Uso termina com o caixa eletrônico no Estado Pronto.
|
---|---|
Fluxo Alternativo 1 - Cartão Inválido. | Na Etapa 2 do Fluxo Básico - Verificar o Cartão Bancário, se o cartão não for válido, será ejetado com uma mensagem apropriada. |
Fluxo Alternativo 2 - Caixa Eletrônico sem Dinheiro | Na Etapa 5 do Fluxo Básico 5 - Opções do Caixa Eletrônico, se o caixa eletrônico estiver sem dinheiro, a opção "Retirada em Dinheiro" não estará disponível. |
Fluxo Alternativo 3 - Fundos insuficientes no caixa eletrônico | Na Etapa 6 do Fluxo Básico - Digitar o Valor, se o caixa eletrônico não contiver fundos suficientes para fornecer o valor solicitado, o sistema exibirá uma mensagem apropriada e retornará à Etapa 6 do fluxo básico - Digitar o Valor. |
Fluxo Alternativo 4 - Senha Incorreta | Na Etapa 4 do Fluxo Básico - Verificar a Conta e a Senha, o cliente tem três chances de digitar a senha correta.
Se for digitada uma senha incorreta, o caixa eletrônico exibirá a mensagem apropriada, e se houver novas tentativas, esse fluxo retornará à Etapa 3 do Fluxo Básico - Digitar a Senha. Se na última tentativa o número PIN digitado estiver incorreto, o cartão será retido, o caixa eletrônico retornará ao Estado Pronto, e esse caso de uso será encerrado. |
Fluxo Alternativo 5 - Nenhuma Conta | Na Etapa 4 do Fluxo Básico - Verificar a Conta e a Senha, se o Sistema bancário retornar um código indicando que a conta não foi encontrada ou que ela não permite retiradas, o caixa eletrônico exibirá a mensagem apropriada e retornará à Etapa 9 do Fluxo Básico - Devolver o Cartão. |
Fluxo Alternativo 6 - Fundos Insuficientes na Conta | Na Etapa 7 do Fluxo Básico - Autorização, o Sistema bancário retorna um código indicando que o saldo da conta é inferior ao valor digitado na Etapa 6 do Fluxo Básico - Digitar o Valor, o caixa eletrônico exibe a mensagem apropriada e retorna à Etapa 6 do Fluxo Básico - Digitar o Valor. |
Fluxo Alternativo 7 - Alcançado o valor máximo diário para retirada | Na Etapa 6 do Fluxo Básico - Autorização, o Sistema bancário exibe um código indicando que, com essa solicitação de retirada, o cliente terá excedido o valor máximo permitido em um período de 24 horas; o caixa eletrônico exibe a mensagem apropriada e retorna à Etapa 6 do Fluxo Básico - Digitar o Valor. |
Fluxo Alternativo x - Erro de Log | Se na Etapa 10 do Fluxo Básico - Recibo, não for possível atualizar o log, o caixa eletrônico entrará no "modo de segurança" em que todas as funções serão suspensas. Um alarme apropriado será enviado ao Sistema Bancário para indicar que o caixa eletrônico suspendeu a operação. |
Fluxo Alternativo y - Encerramento | O cliente pode, a qualquer momento, decidir terminar a transação (sair). A transação é parada e o cartão ejetado. |
Fluxo Alternativo z - "Desvio" | O caixa eletrônico contém vários sensores que monitoram funções distintas, como alimentação, pressão exercida nas várias portas e passagens, e detectores de movimento. Se a qualquer momento um sensor for ativado, um sinal de alarme será enviado à Polícia e o caixa eletrônico entrará no "modo de segurança" em que todas as funções serão suspensas até que sejam executadas as ações de reinício/reinicialização apropriadas. |
Na primeira iteração, de acordo com o plano de iteração,
é necessário verificar se o caso de uso Retirada em Dinheiro foi
implementado corretamente. O caso de uso ainda não foi totalmente implementado, apenas
os fluxos a seguir foram implementados:
- Fluxo Básico - Retirada de um valor predefinido ($10, $20, $50, $100)
- Fluxo Alternativo 2 - Caixa Eletrônico sem Dinheiro
- Fluxo Alternativo 3 - Fundos insuficientes no caixa eletrônico
- Fluxo Alternativo 4 - Senha Incorreta
- Fluxo Alternativo 5 - Nenhuma Conta/Tipo de Conta Incorreto
- Fluxo Alternativo 6 - Fundos Insuficientes na Conta
Os cenários a seguir podem ser derivados desse caso de uso:
Cenário 1 - Retirada em dinheiro bem-sucedida | Fluxo Básico | |
---|---|---|
Cenário 2 - Caixa eletrônico sem dinheiro | Fluxo Básico | Fluxo Alternativo 2 |
Cenário 3 - Fundos Insuficientes no Caixa Eletrônico | Fluxo Básico | Fluxo Alternativo 3 |
Cenário 4 - Senha Incorreta (novas tentativas) | Fluxo Básico | Fluxo Alternativo 4 |
Cenário 5 - Senha incorreta (sem nova tentativa) | Fluxo Básico | Fluxo Alternativo 4 |
Cenário 6 - Nenhuma Conta/tipo de conta incorreto | Fluxo Básico | Fluxo Alternativo 5 |
Cenário 7 - Saldo em Conta Insuficiente | Fluxo Básico | Fluxo Alternativo 6 |
Nota: 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 anterior.
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. Um formato comum é mostrado a seguir, em que cada linha representa um caso de teste individual e as colunas identificam informações de caso de teste. Neste exemplo, para cada caso de teste, há um ID, uma Condição (ou descrição) e todos os elementos de dados 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) é utilizado para indicar que essa condição deve ser VÁLIDA para que o fluxo básico seja executado e I (inválido) é utilizado para indicar a condição que chamará o fluxo alternativo desejado. Na tabela a seguir, "n/a" indica que esta condição não é aplicável ao caso de teste.
ID do TC | Cenário/Condição | Senha
|
N{\super o} da Conta
|
Valor Digitado
(ou escolhido)
|
Valor na Conta
|
Valor no Caixa Eletrônico
|
Resultado Esperado |
---|---|---|---|---|---|---|---|
CW1. | Cenário 1 - Retirada em Dinheiro Bem-sucedida | V | V | V | V | V | Retirada em dinheiro bem-sucedida. |
CW2. | Cenário 2 - Caixa Eletrônico sem Dinheiro | V | V | V | V | I | Opção Retirada em Dinheiro indisponível, fim do caso de uso |
CW3. | Cenário 3 - Fundos insuficientes no caixa eletrônico | V | V | V | V | I | Mensagem de aviso, retorno à Etapa 6 do Fluxo Básico - Digitar o Valor |
CW4. | Cenário 4 - Senha Incorreta (> 1 nova tentativa) | I
|
V | n/a | V | V | Mensagem de aviso, retorno à Etapa 4 do Fluxo Básico, Digitar a Senha |
CW5. | Cenário 4 - Senha Incorreta (= 1 nova tentativa) | I
|
V | n/a | V | V | Mensagem de aviso, retorno à Etapa 4 do Fluxo Básico, Digitar a Senha |
CW6. | Cenário 4 - Senha Incorreta (= 0 novas tentativas) | I
|
V | n/a | V | V | Mensagem de aviso, cartão retido, fim do caso de uso |
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. Esses casos de teste negativos são representados pelos casos de teste CW2 - 6 (a célula sombreada indica a condição necessária para executar os fluxos alternativos). Embora CW2 - 6 consista em casos de teste negativos para o Fluxo Básico, eles são positivos para os Fluxos Alternativos 2 - 4 e há 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):
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 casos de teste suficientes forem identificados, será necessário revisá-los e validá-los para assegurar a exatidão e adequação, bem como para eliminar casos de teste duplicados, equivalentes ou de alguma maneira redundantes. Consulte Conceitos: Lista de Idéias de Teste para obter detalhes adicionais. Consulte também a seção Definindo Dados de Teste para Casos de Teste para obter detalhes adicionais.
ID do TC | Cenário/Condição | Senha
|
N{\super o} da Conta
|
Valor Digitado
(ou escolhido)
|
Valor na Conta
|
Valor no Caixa Eletrônico
|
Resultado Esperado |
---|---|---|---|---|---|---|---|
CW1. | Cenário 1 - Retirada em Dinheiro Bem-sucedida | 4987 | 809 - 498 | 50,00 | 500,00 | 2.000 | Retirada em dinheiro bem-sucedida. Saldo da conta atualizado para 450,00 |
CW2. | Cenário 2 - Caixa Eletrônico sem Dinheiro | 4987 | 809 - 498 | 100,00 | 500,00 | 0,00 | Opção Retirada em Dinheiro indisponível, fim do caso de uso |
CW3. | Cenário 3 - Fundos insuficientes no caixa eletrônico | 4987 | 809 - 498 | 100,00 | 500,00 | 70,00 | Mensagem de aviso, retorno à Etapa 6 do Fluxo Básico - Digitar o Valor |
CW4. | Cenário 4 - Senha Incorreta (> 1 nova tentativa) | 4978
|
809 - 498 | n/a | 500,00 | 2.000 | Mensagem de aviso, retorno à Etapa 4 do Fluxo Básico, Digitar a Senha |
CW5. | Cenário 4 - Senha Incorreta (= 1 nova tentativa) | 4978
|
809 - 498 | n/a | 500,00 | 2.000 | Mensagem de aviso, retorno à Etapa 4 do Fluxo Básico, Digitar a Senha |
CW6. | Cenário 4 - Senha Incorreta (= 0 novas tentativas) | 4978
|
809 - 498 | n/a | 500,00 | 2.000 | Mensagem de aviso, cartão retido, fim do caso de uso |
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:
Em futuras iterações, quando outros fluxos forem implementados, os casos de teste serão necessários para:
Ao identificar os casos de teste funcionais, verifique se:
Consulte a seção Definindo Dados de Teste para Casos de Teste para obter orientação adicional.
Nem todos os requisitos de um destino de teste serão refletidos em artefatos de requisitos funcionais, como especificações de casos de uso. Os requisitos não funcionais, como desempenho, segurança e acesso, e os requisitos de configuração especificam comportamentos ou características adicionais do destino do teste e são, geralmente, documentados separadamente dos requisitos funcionais. A Especificação Suplementar é uma das principais origens para derivação de casos de teste para esses requisitos adicionais.
Veja a seguir as diretrizes para obtenção desses casos de teste adicionais:
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:
Como nos casos de teste para testes funcionais, normalmente haverá mais de um caso de teste por cenário ou requisito de uso. É comum definir vários casos de teste caso - por exemplo, um que esteja abaixo do valor limite de desempenho (taxa média de transações), outro no valor limite (taxa alta de transações) e um terceiro caso de teste acima do valor limite (taxa máxima de transações).
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:
Uma prática comum é capturar casos de teste para testes de desempenho em matrizes tabulares semelhantes às utilizadas para o teste funcional.
Consulte a seção Definindo Dados de Teste para Casos de Teste para obter detalhes adicionais.
Aqui estão alguns exemplos dos diferentes tipos de Testes de Desempenho:
Para o Teste de Carga:
ID do TC | Carga de Trabalho | Condição | Resultado Esperado |
---|---|---|---|
PCW1. |
1 (Caixa eletrônico único) |
Transação de Retirada Concluída |
A transação concluída (sincronização independente do ator) ocorre em < 20 segundos |
PCW2. |
2 (1.000 caixas eletrônicos simultâneos) |
Transação de Retirada Concluída |
A transação concluída (sincronização independente do ator) ocorre em < 30 segundos |
PCW3. |
3 (10.000 caixas eletrônicos simultâneos) |
Transação de Retirada Concluída |
A transação concluída (sincronização independente do ator) ocorre em < 50 segundos |
Para o Teste de Esforço:
ID do TC | Carga de Trabalho | Condição | Resultado Esperado |
---|---|---|---|
SCW1. |
2 (1.000 caixas eletrônicos simultâneos) |
Bloqueio do banco de dados - 2 caixas eletrônicos solicitando a mesma conta |
Solicitações do caixa eletrônico em fila |
SCW2. |
2 (1.000 caixas eletrônicos simultâneos) |
A comunicação com o Sistema Bancário não está disponível |
A transação está em fila ou seu tempo está esgotado |
SCW3. |
2 (1.000 caixas eletrônicos simultâneos) |
A comunicação com o Sistema Bancário termina durante a transação |
Uma mensagem de aviso é exibida |
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 caixa eletrônico, é possível executar diversos fluxos de eventos de caso de uso para o ator "Cliente de Banco" se seu cartão e conta forem do banco que possui o caixa eletrônico versus o "Cliente de Banco" que utiliza um cartão (e conta) de um banco concorrente, ou tenta utilizar um cartão bancário não participante.
Siga as mesmas diretrizes listadas acima para os casos de teste funcionais.
Consulte a seção Definindo Dados de Teste para Casos de Teste para obter orientação adicional.
Exemplo de casos de teste para Segurança e Acesso:
ID do TC | Condição | Cartão
(V indica cartão válido) |
Leitor de Cartões
(V indica que o leitor está funcionando corretamente) |
Rede do Banco | Resultado Esperado |
---|---|---|---|---|---|
ACW1. | Na Rede Bancária | V | V | V | Todos os Casos de Uso disponíveis |
ACW2. | Fora da rede bancária | V | V | I | Apenas caso de uso de retirada em dinheiro |
ACW3. | Não é possível ler o cartão | I | V | V | Mensagem de Aviso, Cartão ejetado |
ACW4. | Cartão indicado como roubado | I | V | V | Mensagem de Aviso, cartão retido |
ACW5. | Cartão expirado | I | V | V | Mensagem de aviso, cartão retido |
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:
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:
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.
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:
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.
O teste de aceitação do produto é o teste final antes da implementação do software. A meta do teste de aceitação é verificar se o software está pronto e pode ser utilizado pelos usuários finais para executar as funções e tarefas para as quais o software foi construído. Esse teste geralmente envolve mais do que a execução da preparação 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 anteriormente (formais) ou um subconjunto (informais). Independentemente da profundidade dos casos de teste, é necessário haver um acordo entre eles e os critérios 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 muito 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 a maneira de avaliá-lo.
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. Utilize 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:
Depois que os casos de teste são analisados e existe um acordo / aprovação geral sobre eles, é possível identificar os valores reais dos dados com mais detalhes (por exemplo, na matriz de implementação do caso de teste) e criar os artefatos dos dados de teste.
Rational Unified Process
|