CASOS DE TESTE PALESTRANTE: MARCIA SILVA

Transcrição

1 CASOS DE TESTE PALESTRANTE: MARCIA SILVA

2 CONCEITOS BÁSICOS - TESTES O que é Teste de Software? Teste é o processo de executar um programa com o objetivo de verificar sua conformidade em relação aos requisitos especificados.

3 CONCEITOS BÁSICOS - TESTES Porque Testamos? para verificar se o software está fazendo o que foi pedido que ele fizesse num requisito; para garantir que o negócio não vai correr riscos provocados por defeitos em produção; para assegurar a qualidade do software;

4 CONCEITOS BÁSICOS - PROCESSOS Qual a diferença entre Projeto e Processo? Projeto é um empreendimento temporário conduzido para criar um produto ou serviço ou resultado único Fonte: (PMI Project Management Institute PMBok 2008) (Gerenciando Projetos de Teste de Software Editora ArtImagem) Processo - Um processo de Engenharia de Software é formado por um conjunto de passos de processo parcialmente ordenados, relacionados com artefatos, pessoas, recursos, estruturas organizacionais e restrições, tendo como objetivo produzir e manter os produtos de software finais requeridos. Fonte: Wikipédia

5 CONCEITOS BÁSICOS - PROCESSOS Projeto x Processo O teste também deve ser considerado um projeto; É importante termos um processo de teste;

6 CONCEITOS BÁSICOS - PROCESSOS PRINCÍPIO BASE DOS MODELOS DE QUALIDADE Melhores processos Melhores produtos OBJETIVO Melhorar os processos para melhorar os produtos (bens e serviços) 6

7 CONCEITOS BÁSICOS - DEFEITOS O que é Defeito? Qualquer condição que causa um desvio de um resultado baseado no que diz um requisito, um documento de especificação, um documento do usuário, um padrão, ou conforme a experiência ou percepção do técnico, que requeira investigação. Obs.: Defeitos podem ser encontrados em produtos de software ou artefatos de software. Fonte ISO

8 Conceitos Básicos Custo do Defeito 8

9 CONCEITOS BÁSICOS O RUP é um framework de processo iterativo e incremental que provê uma abordagem disciplinada para o desenvolvimento de software Possui duas dimensões: O eixo horizontal representa o aspecto dinâmico do processo e mostra as fases do ciclo de vida à medida que este se desenvolve O eixo vertical representa o aspecto estático do processo, como ele é descrito em termos de disciplinas As disciplinas fundamentais do processo de desenvolvimento de software também estão presentes na estrutura do RUP

10 TESTE X DESENVOLVIMENTO

11 Casos de Testes

12 PROCESSO BÁSICO DE TESTE Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 12

13 CASOS DE TESTE Eu quero Testar mas não sei por onde começar... Um bom começo seria escrever os casos de testes de cada uma das funcionalidades ou requisito do software.

14 CASOS DE TESTE Casos de Testes é um conjunto de condições usadas para: Encontrar defeitos na estrutura interna do software Garantir que os requisitos do software que foi construído seja plenamente atendidos.

15 Pré Requisitos para criação dos Casos de Testes Etapas de Suporte Preparação Produtos Etapas de Realização Requisitos Planejamento Especificação Estratégia de Testes Planos de Teste Especificação Planejamento Roteiros de Teste Casos de Teste Execução Scripts ou procedimentos de teste 15

16 Estratégia de Teste Para planejar os testes, devemos saber: O que pretendemos testar; Quando iremos testar; Como iremos testar Logo, precisamos ter definido a nossa teste. Estratégia de teste. 16

17 PROCESSO DE TESTE PROJETAR MacroMacro-atividade: atividade: Projetar Teste ou Especificar O projeto dos testes (ou especificar teste) contempla a criação dos casos de teste (conforme template) template) e demais artefatos necessários às atividades de execução dos testes conforme definido no Plano de Teste. Na ocorrência de alterações de requisitos, de design ou do código do sistema, durante ou posteriormente a esta atividade, a alteração é feita através de uma solicitação formal de mudança, onde são avaliadas as mudanças necessárias nos artefatos envolvidos. Para tal o projeto deve ser monitorado. Atividade: Atividade: Atividade: Definir os cenários de teste Elaborar Casos de Teste Elaborar Procedimento de Teste 17

18 ELABORAÇÃO DO TESTE A tarefa de elaboração do teste é coberta por 3 documentos: Especificação de Desenho ou Design (Projeto) de Teste Trata-se de um detalhamento da abordagem apresentada no Plano de Teste e identifica as funcionalidades e características a serem testadas pelo projeto. Este documento também identifica os casos e os procedimentos de teste, se existirem, e apresenta os critérios de aprovação. Especificação de Caso de Teste Define os casos de teste, incluindo dados de entrada, resultados esperados, ações e condições gerais para a execução do teste. Utilizaremos a nomenclatura de Plano de Caso de Teste para este documento gerado. Especificação do Procedimento de Teste Identifica todos os passos necessários para operar o sistema e exercitar os Casos de Testes especificados, de maneira a cobrir o Projeto de Teste planejado. Os procedimentos de testes formam um documento separado com a intenção de que seja seguido passo a passo, sem ocorrências não previstas. A Norma IEEE Std (IEEE Standard for Software Test Documentation) descreve um conjunto de documentos para as atividades de teste de um projeto de software. 18

19 PROCESSO DE TESTE PROJETAR TESTE Atividade: Definir Cenários de Teste Descrição: O Analista de Teste com base nos requisitos de teste Descrição: ou nos casos de uso, e usando o Plano de Teste como referência, deve definir os Cenários de Teste e que servirão posteriormente para a elaboração dos Procedimentos (ou Roteiro) de Teste. Responsáveis: Participantes: Artefatos: Ferramentas: Analista de Teste Analista de Sistemas, Testador Plano de Teste, Requisitos, Casos de Uso (testáveis) Precisam ser definidas

20 DESENHO OU PROJETO DE TESTE PADRÃO IEEE 829 Introdução Identificador Escopo Referências Detalhes deste nível do desenho (projeto) de teste Features (ou funcionalidades) a serem testadas Abordagem refinada Casos de Teste com a sua respectiva identificação Critérios de passagem e falha por feature ou funcionalidade Entregáveis Global Glossário Procedimentos de alterações do documento e histórico de alterações 20

21 PROCESSO DE TESTE PROJETAR TESTAR Atividade: Elaborar Casos de Teste Descrição: O Analista de Teste define e elabora os casos de Descrição: teste baseados nas especificações dos casos de uso ou requisitos e em especificação suplementar (caso exista), exista), tomando como base o Plano de Teste. Os testes não funcionais, caso existam, como, por exemplo, teste de desempenho, também devem estar definidos, nos casos de teste. Responsáveis: Participantes: Artefatos: Ferramentas: Analista de Teste Analista de Sistemas, Testador Plano de Teste, Caso de Teste Precisam ser definidas

22 CASO DE TESTE PADRÃO IEEE 829 Introdução (uma por documento) Identificador do documento Escopo Referências (itens de teste) Contexto Notas para descrição Detalhes (um por caso de teste) Identificador do caso de teste Objetivos Especificações de entrada Especificações de saída Necessidades de ambiente Requisitos ou procedimentos especiais Dependências entre casos de teste Referências (Itens de teste) Requisitos Projeto de teste e features Guia do Usuário Guia Operacional Guia de Instalação Etc... Global Glossário Procedimentos de alterações do documento e histórico de alterações 22

23 PROCESSO DE TESTE PROJETAR TESTE Atividade: Elaborar Procedimentos de Teste (ou Roteiro de Teste) Descrição: Os procedimentos de teste devem ser elaborados com Descrição: o intuito de manter a sequencia necessária para a execução dos casos de teste que se enquadrem nesta situação. Responsáveis: Participantes: Artefatos: Ferramentas: Analista de Testes Analista de Sistemas,Testador Casos de Teste, Procedimentos de Teste Precisam ser definidas

24 PROCEDIMENTOS DE TESTE PADRÃO IEEE 829 Introdução Identificador do documento Escopo Referências Relações com outros documentos de procedimentos Detalhes deste nível do desenho (projeto) de teste Entradas, saídas e requisitos especiais Ordem para execução dos casos de teste Global Glossário Procedimentos de alterações do documento e histórico de alterações 24

25 O caso de Teste como centro motivador do teste O que motivou o meu teste? Onde devo testar? Configurações Requisitos Caso de Teste Iteração Quando devo testar? Implementação Como devo testar? 25

26 ELABORAÇÃO DO PLANO DE CASO DE TESTE Para a elaborar os casos de teste a partir do requisitos especificados devedeve-se considerar os seguintes itens: Identificar todos os cenários contidos nas especificação existente; Para cada cenário, identificar um ou mais casos de teste; Para cada caso de teste, identificar condições de execução; Adicionar os dados para as condições nos casos de teste. 26

27 ELABORAÇÃO DO CASO DE TESTE Os seguintes itens devem ser abordados: Abordagens para determinar os casos de testes ISO Teste Dinâmico -Teste que para ser executado precisa de um código de programa Teste Estático - Teste que para ser executado não precisa de um código de programa, exemplo, revisão, verificação, inspeção Identificação das condições de testes: Identificação dos casos de testes (o que testar) Deve conter uma definição de cada caso de teste identificado Detalhamento da massa de entrada, de Saída ( resultante ) Critérios especiais para geração da massa de Teste, com o nome do responsável Necessidades de ambiente Especificar as necessidades adicionais de equipamentos Definir agenda de levantamento (como testar) Cronograma Interdependências Listar as interdependências entre os Casos de Testes. 27

28 TESTE NA FASE DE ESPECIFICAÇÃO Elaboração dos Casos de Teste para a revisão da especificação Checklist Recomenda Recomenda-se o uso de templates para a revisão 28

29 Teste na fase de Especificação Assegura Qualidade, Testabilidade, Testabilidade, Completude, Mensurabilidade das demandas, Entendimento dos Requisitos e principalmente ANTECIPA PROBLEMAS 29

30 ALGUNS EXEMPLOS DE PERGUNTAS: 1. O Objetivo da especificação está de fácil entendimento? 2. Os Atores estão definidos? 3. Existem regras de navegabilidade em documentação Suplementar ou na própria especificação? 4. Todas as exceções descritas estão sendo citadas no corpo da especificação? 5. Todas as telas (protótipos), possuem detalhamento de atributos? 6. Todos os campos do tipo "combo","lista "combo","lista" combo","lista" e "caixa de seleção" estão definidos quanto a sua ordenação? 7. Todos os campos das telas estão definidos quanto a sua obrigatoriedade de preenchimento? 8. Todos os campos das telas estão definidos quanto ao seu tamanho? 30

31 ALGUNS EXEMPLOS DE PERGUNTAS: 9. Todos os campos das telas estão definidos quanto ao seu tipo? 10. Todos os campos que recuperam dados estão definidos quanto ao seu valor padrão? 11. A seqüência lógica da especificação está bem descrita? 12. Todas as Regras de Negócio estão citadas? 13. Todos os cenários possíveis estão descritos? 14. Todas as opções (Botões) da tela principal estão descritas como fluxos? 15. A indentação está refletindo a correta funcionalidade? 16. Todas os campos do tipo data estão sendo validados quanto ao conteúdo, formato inválido e data inválida? 17. Todas as mensagens estão inteligíveis e corretamente descritas nas suas respectivas ações do sistema? 31

32 Testabilidade Relatório de Testabilidade Cliente Projeto Caso de Uso Analisado Responsável pela Análise Nº Texto Sim Test center Não N/A Considerações Projeto em Resposta ao teste Sim Não Considerações 1 O objetivo e especificação está de facil entendimento? 2 Os atores estão definidos? Existem regras de nvaegabilidade em documentação 3 Suplementar ou na própria especificação? Todas as exceções descritas estão sendo citadas no 4 corpo da especificação? Todas as telas (protótipos), possuem detalhamento de 5 atributos? Todos os campos do tipo "combo", "lista" e "caixa de 6 seleção" estão definidos quanto a sua ordenação? Todos os campos das telas estão definidos quanto a sua 7 obrigatoriedade de preenchimento? Checklist Todos os campos das telas estão definidos quanto ao 8 seu tamanho? Todos os campos das telas estão definidos quanto ao 9 seu tipo? Todos os campos que recuperam dados estão definidos 10 quanto ao seu valor padrão? Análise de Testabilidade Testabilidade Caso de Uso

33 Rastreabilidade Teste / Requisito Mudança de um Requisito Planejar Projetar Testes Testes Atualiza/Versiona os Casos de Testes Associados Requisito Teste

34 Caso de Teste

35 Artefatos Gerados

36 CENÁRIOS DE TESTES (EXEMPLO REAL) Cenário de teste é o caminho ou situação a ser testada Em um Caso de Uso de Transferência Bancária, um dos cenários é a Transferência DOC para conta de terceiros.

37 Teste de Cenário Teste de Sistema Para se testar este cenário de especificação, devemos criar um cenário de teste para validar esta funcionalidade. Este cenário de teste, deve seguir os seguintes passos: Pré Condição Estar logado internet bank e existir Banco e Conta Corrente de origem Passos 1. Selecionar opção de Transferência 2. Preencher Dados Destinatário Código do Banco Agência Conta Corrente CPF do Destinatário Valor 3. Verificar o saldo da conta de origem, 4. Transferir o valor da conta origem para conta destino, 4. Consultar novamente o saldo da conta origem, verificando que o saldo inicial menos o valor transferido é igual ao saldo atual, 5. Imprimir comprovante de transferência 37

38 Dentro deste cenário de teste podemos destacar diversos casos de testes: CT01 Preenchimento dos campos obrigatório na tela de transferência CT02 Validação de CPF CT03 Conta Destino inválida CT04 Transferência de valores negativos e muitos outros 38

39 CT Preenchimento inválido do campo número de confirmação Preencher o campo número de confirmação com um número inválido O Sistema apresenta uma mensagem 39

40 EXEMPLO DE CASO DE TESTES Considere as seguintes situações: 1 Um Sistema web com os seguintes requisitos não-funcionais: Deve operar em diferentes Browsers Deve poder usar diferentes plug-ins Rodar em diferentes sistemas operacionais nas máquinas clientes Deve receber páginas por diferentes servidores Deve rodar em diferentes servidores Exemplo de Caso de teste Testar o requisito funcional Manter Usuário O sistema deve: - incluir usuário - alterar usuário - excluir usuário

41 EXEMPLIFICANDO CENÁRIO Funcionalidade Uma das funcionalidades Incluir usuário. - um dos Testes: Passo: Passo Preencher a tela de usuário com seus campos obrigatórios e selecionar a opção incluir. Resultado esperado: esperado Mensagem de Incluído com sucesso. Ambiente de teste: teste Máquina cliente com sistema operacional windows 2000, utilizando o Internet explorer 6.0 como Browser, recebendo páginas de um servidor com IIS e ter um servidor de Websphere em Linux.

42 DETALHANDO A SITUAÇÃO ANTERIOR

43 Algumas tecnícas para derivar Casos de Teste As técnicas de especificação usam vários princípios para a derivação dos casos de teste, teste, alguns dos quais estão abaixo listados: listados: Classes de equivalência; equivalência; Análise Análise de valores limítrofes; limítrofes; 43

44 Classes de Equivalência e Análise de Valores Limítrofes Vamos supor que o campo idade deva ter valores dentro dos seguintes limites: limites: 18 <= idade <= 65 Isto daria as seguintes classes de equivalência para serem testadas: testadas: idade menor ou igual a 18; idade entre 18 e 65; idade maior do que 65. O caso de teste deveria incluir o seguinte: seguinte: Entrada = 10 - Resuldado = valor inválido Entrada = 35 - Resultado = valor correto Entrada = 70 - Resultado = valor inválido Além disso os valores limítrofes 17,18 e 19 e 64, 65 e 66 deveriam também ser testados ou um valor absurdo do tipo ,

45 CONCLUSÃO O número de casos de teste a serem criados e executados muitas vezes vai depender do prazo de teste ou de outros fatores. Além disso, não basta a nossa intuição, precisamos escrever cada um dos casos de teste. teste. A mensagem é simples, quanto mais casos de teste usarmos tanto mais profundo será o nosso teste e tanto maior será a qualidade do software.

46 EXERCÍCIO CT01 Preenchimento dos campos obrigatório na tela de transferência.

47 PERGUNTAS?

48 FIM