Fundamentos de Teste de Software

Transcrição

1 Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 4 Projeto de Teste 1

2 SUMÁRIO INTRODUÇÃO... 3 ANÁLISE E PROJETO DE TESTE Identificação das Condições do Teste... 5 Exemplo 1: Caso de Uso Realizar Operação Bancária... 7 Exemplo 2: Cenário EuroBonus Star Alliance Especificar os Casos de Teste... 8 Exemplo 1: Caso de Uso Realizar Operação Bancária... 9 Exemplo 2: Cenário EuroBonus Star Alliance Especificar os procedimentos de teste Exemplo 1: Caso de Uso Realizar Operação Bancária Exemplo 2: Caso de Uso EuroBonus Star Alliance CONCLUSÃO ANEXOS 1 Caso de Uso Realizar Operação Bancária

3 INTRODUÇÃO O segundo módulo do curso apresenta um maior detalhamento dos procedimentos que estão relacionados com o Teste Estático e o Teste Dinâmico. Esta aula irá focar o Projeto de Teste, contemplando sua definição, processo de elaboração, requisitos desejáveis e alguns exemplos para apoiar as definições. Além disso, iremos abordar como traduzir as condições em casos e procedimentos de teste para que o testador tenha o projeto para executar o teste. ANÁLISE E PROJETO DE TESTE O objetivo da Análise e Projeto é produzir o projeto de teste contemplando as condições, casos e procedimentos de teste, e, buscando a maior cobertura possível para alcançar o que foi previsto no plano de teste. O projeto de teste permite a revisão da documentação usada como base para esta atividade, permitindo a antecipação de defeitos no ciclo de vida do teste. Figura 1 Objetivos da análise e projeto de teste O processo para definição do projeto de teste deve ser iterativo e incremental, e acontece antes da execução do teste, haja vista a necessidade de se saber: escopo do que será testado; os produtos de trabalho para serem entradas para o projeto de teste; lista dos resultados esperados pelas atividade; e atividades necessárias para realizar a execução do teste. 3

4 Esse processo tem o foco a busca por informações que possam ser usadas para derivar o projeto do teste, também chamadas de bases para o teste.. Podem ser obtidas através dos requisitos do sistema, especificação técnica, código ou processo de negócio. Nesse contexto, o processo para o projeto de teste compreende 3 atividades: 1. Identificar as Condições do Teste; 2. Especificar os Casos de Teste; e 3. Especificar os procedimentos de Teste. Figura 2 Processo para elaborar o projeto de teste O resultado de cada atividade pode ser documentado conforme o nível de formalidade requerido no contexto do projeto. Projetos mais formais irão demandar documentação extensa, bem controlada e detalhada, por outro lado, o resultado informal pode não trazer nenhum documentação, apenas anotações feitas para que o testador entenda o que é esperado pelas atividades de teste. Figura 3 Formalidade da documentação 4

5 Observa-se que muitas organizações trabalham com uma forma intermediária, onde o nível de formalidade depende do contexto organizacional, cultura do time e maturidade do processo de desenvolvimento, especificamente o processo de teste. O escopo da formalidade do processo também depende das restrições de tempo de um determinado projeto. A cobertura do teste é outro aspecto importante no projeto porque fornece uma idéia quantitativa do tamanho e qualidade do teste, além de promover uma forma para estimar a quantidade de teste que precisa ser realizado. A cobertura busca responder questões relativas a quantidade de teste que será realizado em um projeto. Figura 4 Cobertura do este 1. Identificação das Condições do Teste A primeira atividade do processo tem o objetivo de buscar o escopo do que pode ser testado, que são as condições do teste. Figura 5 Identificação das condições do teste 5

6 Uma condição de teste é um item ou evento de um componente ou sistema que pode ser verificado por um ou mais casos de teste, ou, simplesmente, o que pode ser testado, também denominado possibilidades do teste. Não é possível testar tudo visto ser um objetivo impraticável para um projeto. É necessário selecionar um subconjunto de todas as possibilidades existentes para o teste. As técnicas de teste, que serão explicadas futuramente, apóiam a seleção desse subconjunto a partir do total de possibilidades teste disponíveis. As condições do teste se originam a partir da documentação base do projeto, que pode ser: Documento de requisitos; Manuais de sistema; Especificações do produto; Especificações funcionais; Manuais de treinamento; e Feedback de clientes. A coleta dos dados relevante sobre o sistema pode ser feita a partir da análise dos documentos ou através de brainstorm com o time do projeto. Nesse contexto, as características as serem testadas podem ser expressas em termos de condições, requisitos de teste,, ou simplesmente, um item verificável,, que são os itens que serão cobertos através da execução do teste. Nesse âmbito, o critério de completude deve ser levado em questão, pois não se deve esperar 100% de cobertura de código. As condições do teste devem ser selecionadas com base no percentual de cobertura que se deseja alcançar. Uma forma de apoiar a definição da cobertura do teste é a utilização da análise de riscos do produto realizada para priorizar os itens mais importantes a serem alcançados pela cobertura do teste. As condições devem ser escritas de forma a contemplar: Identificação única; Descrição; e Referência para a documentação base. As condições do teste selecionadas irão depender da estratégia e da abordagem detalhada do teste e devem manter rastreabilidade desde sua origem, podendo ser horizontal, por toda a documentação de teste, ou vertical que abrange todos os níveis de documentação no projeto. Além da identificação das condições do teste, é necessário priorizá-las, onde pode-se até adotar a técnica de identificar o dobro de condições de teste necessárias para, então, se priorizar apenas as mais importantes. 6

7 Exemplo 1: Caso de Uso Realizar Operação Bancária O cenário, apresentado através do diagrama de casos de uso, mostra as transações que podem ser realizadas pelos atores: Cliente; Sistema bancário; e Operador de caixa eletrônico. Nesse cenário, os atores interagem para: Retirada de dinheiro; Transferir fundos; Depositar fundos; e Iniciação do sistema. Figura 6: Caso de uso realizar operação bancária O Anexo 1 contempla a descrição detalhada do caso de uso Realizar Operação Bancária. Nesse cenário, é possível obter as seguintes condições de teste. ID Condição Retirada em dinheiro bem-sucedida Caixa eletrônico sem dinheiro Fundos Insuficientes no Caixa Eletrônico Senha Incorreta (novas tentativas) Senha incorreta (sem nova tentativa) Nenhuma Conta/tipo de conta incorreto Saldo Insuficiente em Conta 7

8 Exemplo 2: Cenário EuroBonus Star Alliance O segundo exemplo apresenta um cenário de um programa de fidelidade e acumulo de pontos, conforme descrito a seguir: Para um determinado programa de recompensa, existem 3 níveis de parceria: Básico, Prata e Ouro. O nível de parceria de um passageiro é determinado pelo numero de pontos básicos adquiridos num intervalo de 12 meses. O passageiro irá, automaticamente, mudar para o nível Prata quando acumular pontos durante o período de aquisição. Se você adquirir pontos no mesmo período, você irá para a categoria Ouro. O período de aquisição opera a partir do primeiro dia que você se associa no programa até os 12 meses seguintes. Figura 7: Cenário EuroBonus Star Alliance Algumas condições podem ser extraídas: ID Condição Quando a soma dos seus pontos for menor de , seu status será Básico. Quando a soma dos seus pontos for igual ou maior que , seu nível será Prata. Quando a soma dos seus pontos for igual ou maior que , seu nível será Ouro. 2. Especificar os Casos de Teste A especificação dos casos de teste é a segunda atividade do processo e casos de teste podem ser entendidos como um conjunto de valores de entrada, precondições para execução, resultados esperados e pós-condições da execução. Embora as condições do teste possam ser vagas, os casos de teste devem ser específicos, e são desenvolvidos para um objetivo ou condição de teste específico. Portanto, devem ser elaborados tomando como base as condições do teste. Para a definição dos casos de teste, deve-se observar as condições: Efetividade: tem uma probabilidade razoável de detecção de erros. Exemplar: sejam práticos e tenham pouca redundância. 8

9 Econômico: mantém um razoável custo de desenvolvimento e retorno sobre investimento. Evolução: sejam passíveis de evolução, estruturados e manuteníveis. Figura 8 Identificação dos casos de teste As técnicas de teste, que serão apresentadas posteriormente, apóiam a criação de casos de teste que satisfaçam as condições acima, além de ajudarem a encontrar valores de entrada. A documentação de um caso de teste deve incluir: Identificação única Descrição Referencia para a condição do teste utilizada como base Nesse contexto, pode haver um relacionamento n-n entre as condições e casos de teste. Exemplo 1: Caso de Uso Realizar Operação Bancária Para cada um dessas sete condições, é 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 das condições de caso de uso. Em seguida, para cada condições, identifique pelo menos um caso de teste que contenha a condição apropriada 9

10 para executar o condições. 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. ID do TC Condição CW1. Condição 1 - Retirada em Dinheiro Bemsucedida V V V V V CW2. Condição 2 - Caixa Eletrônico sem Dinheiro V V V V I CW3. Condição 3 - Fundos insuficientes no caixa eletrônico CW4. CW5. CW6. Senha No da Conta Valor Digitado (ou escolhido) Valor na Conta V V V V I Condição 4 - Senha I V n/a V V Incorreta (> 1 nova tentativa) Condição 4 - Senha I V n/a V V Incorreta (= 1 nova tentativa) Condição 4 - Senha Incorreta (= sem novas tentativas) I V n/a V V Valor no Caixa Eletrônico Resultado Esperado Retirada em dinheiro bemsucedida. Opção Retirada em Dinheiro indisponível, fim do caso de uso Mensagem de aviso, retorno ao Passo 6 do Básico - Digitar o Valor Mensagem de aviso, retorno ao Passo 4 do Básico, Digitar a Senha Mensagem de aviso, retorno ao Passo 4 do Básico, Digitar a Senha Mensagem de aviso, cartão retido, fim do caso de uso Exemplo 2: Cenário EuroBonus Star Alliance O exemplo 2 apresenta outra forma de documentar o caso de teste, de maneira mais simplificada e relacionado o caso de teste com a condição, conforme tabela abaixo. 10

11 ID Condição 11 Quando a soma dos seus pontos for menor de , seu status será Básico. 2 Quando a soma dos seus pontos for igual ou maior que , seu nível será Prata. 3 Quando a soma dos seus pontos for igual ou maior que , seu nível será Ouro. ID Caso de Teste 1.01 Checar se a soma negativa de pontos não é permitida Checar se a soma de menos de pontos irá definir o nível Básico de parceria Checar se a soma de pontos for maior de e menor de irá garantir o nível Prata de parceria Checar se a soma de mais de pontos irá definir o nível Ouro de parceria. 3. Especificar os procedimentos de teste A atividade de especificar os procedimentos de teste adota uma seqüência de ações para executar um caso de teste que devem ser exclusivamente numerados, que acontece após a especificação detalhada dos casos de teste. Figura 9 Identificação dos procedimentos do teste Figura 10 Diferença entre script e procedimentos do teste 11

12 O termo procedimento está, normalmente, relacionado ao teste manual enquanto o termo script está associado com procedimentos automatizados. O grau de detalhamento depende de quem irá executar o teste e sua documentação deve incluir: Identificação única para o procedimento de teste; Descrição dos propósitos; Referência para os casos de teste e/ou condições do teste e/ou documentação a ser coberta pelo procedimento. Descrição das precondições a serem alcançadas antes do início da execução do teste. Casos de teste de baixo nível incluídos. Procedimento de Teste: Identificação do procedimento: Propósito: Caso de Teste Relacionado: Passos: Lembre-se que a elaboração da especificação do teste é uma atividade iterativa. Um procedimento não deve incluir muitos e nem poucos casos de teste. Exemplo 1: Caso de Uso Realizar Operação Bancária Para o exemplo do caso de uso Realizar Operação Bancária, um dos procedimentos de teste existentes é para a retirada de dinheiro bem-sucedida. Procedimento de Teste: Retirada de dinheiro bem-sucedida. Identificação do procedimento: 01 Propósito: Realização bem sucedida do saque no caixa eletrônco. Caso de Teste Relacionado: CW1 Passos: 1. O cliente informa um número da conta verdadeiro para o sistema. 2. O cliente fornece senha para logar no sistema. 3. O sistema informa o valor disponível na conta do cliente. 4. O sistema informa o valor disponível para saque no caixa eletrônico. 5. O cliente informa o valor do saque desejado. 6. O caixa entrega o dinheiro para o cliente. 7. O caso de teste se finaliza. Exemplo 2: Caso de Uso EuroBonus Star Alliance No contexto do cenário EuroBonus Star Alliance, adicionamos um campo no template de descrição dos procedimentos de teste, que é a informação das pré-condições para que o procedimento possa ser executado. Esse campo tem caráter opcional e pode ser 12

13 utilizando quando se deseja especificar o estado inicial mandatório para execução do procedimento de teste. A tabela abaixo representa o procedimento de teste para um caso de teste escolhido e o detalhamento de todos os procedimentos existentes para esse contexto fica a cargo da estratégia de testes adotada no projeto. Procedimento de Teste: Checar soma negativa Identificação do procedimento: 01 Propósito: Checar se o nível Básico de parceria é definido. Precondição: O cliente ter acumulado menos de Caso de Teste Relacionado: Passos: 1. O passageiro informa o número do cartão de parceria. 2. O passageiro informa a senha do sistema. 3. O passageiro efetua login no sistema. 4. O passageiro verificar o tipo básico de parceria. 5. O procedimento se finaliza. CONCLUSÃO Portanto, esta aula apresentou os passos para elaboração do projeto de teste, contemplando o detalhamento do processo, forma de realizar a identificação das condições do teste, como derivá-las para os casos e procedimentos de teste. Além disso, alguns exemplos foram mostrados para consolidar a teoria apresentada. 13

14 ANEXO 1 Caso de Uso Realizar Operação Bancária Básico Alternativo 1 - Cartão Inválido. Alternativo 2 - Caixa Eletrônico sem Dinheiro Alternativo 3 - Fundos insuficientes no caixa eletrônico Alternativo 4 - Senha Incorreta Esse Caso de Uso começa com o caixa eletrônico no Estado Pronto. 1. Iniciar Retirada - O cliente insere o cartão bancário no leitor de cartões do caixa eletrônico 2. Verificar o Cartão Bancário - O caixa eletrônico lê o código da conta a partir da tarja magnética do cartão bancário e verifica se ele é um cartão aceitável. 3. Digitar a senha - O caixa eletrônico pede a senha do cliente (4 dígitos) 4. Verificar o código da conta e a senha - O código da conta e a senha são verificados para determinar se a conta é válida e se a senha digitada está correta. Para esse fluxo, a conta é válida e a senha está corretamente associada a essa conta. 5. Opções do caixa eletrônico - O caixa eletrônico exibe as diversas alternativas disponíveis. Nesse fluxo, o cliente do banco sempre seleciona "Retirada em Dinheiro." 6. Digitar o Valor - O caixa eletrônico solicita o valor a ser retirado. Para esse fluxo o cliente seleciona um valor predefinido (R$ 10, R$ 20, R$ 50 ou R$ 100). 7. Autorização - O caixa eletrônico inicia o processo de verificação com o Sistema Bancário, enviando o ID do Cartão, a Senha, o Valor e as Informações de conta como uma transação. Para esse fluxo, o Sistema Bancário está on-line e responde com uma autorização para concluir a retirada em dinheiro, atualizando o saldo da conta de forma apropriada. 8. Fornecimento - O Dinheiro é fornecido. 9. Devolução do Cartão - o Cartão do Banco é devolvido. 10. Recibo - O recibo é impresso e fornecido. O caixa eletrônico também atualiza o log interno de forma apropriada. O Caso de Uso termina com o caixa eletrônico no Estado Pronto. No Passo 2 do Básico - Verificar o Cartão Bancário, se o cartão não for válido, será ejetado com uma mensagem apropriada. No Passo 5 do Básico - 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. No Passo 6 do 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á ao Passo 6 do fluxo básico - Digitar o Valor. No Passo 4 do 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á ao Passo 3 do Básico - Digitar a Senha. 14

15 Alternativo 5 - Nenhuma Conta Alternativo 6 - Fundos Insuficientes na Conta Alternativo 7 - Atingido o valor máximo diário para retirada Alternativo x - Erro de Log Alternativo y - Encerramento Alternativo z - "Paralisação" 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. No Passo 4 do 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á ao Passo 9 do Básico - Devolver o Cartão. No Passo 7 do Básico - Autorização, o Sistema bancário exibe um código indicando que o saldo da conta é inferior ao valor digitado no Passo 6 do Básico - Digitar o Valor; o caixa eletrônico exibe a mensagem apropriada e retorna ao Passo 6 do Básico - Digitar o Valor. No Passo 6 do 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 ao Passo 6 do Básico - Digitar o Valor. Se no Passo 10 do 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. O cliente pode, a qualquer momento, decidir terminar a transação (encerrar). A transação é interrompida e o cartão é ejetado. 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 não foi totalmente implementado. Apenas os seguintes fluxos foram implementados: Básico - Retirada de um valor predefinido (R$ 10, R$ 20, R$ 50, R$ 100) Alternativo 2 - Caixa Eletrônico sem Dinheiro Alternativo 3 - Fundos insuficientes no caixa eletrônico Alternativo 4 - Senha Incorreta Alternativo 5 - Nenhuma Conta/Tipo de Conta Incorreto Alternativo 6 - Fundos Insuficientes na Conta 15