CASOS DE TESTE
PALESTRANTE: MARCIA SILVA
[email protected]
WWW.EMERSONRIOS.ETI.BR
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.
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;
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
CONCEITOS BÁSICOS - PROCESSOS
Projeto x Processo
O teste também deve ser considerado um projeto;
É importante termos um processo de teste;
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
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 29.119
Conceitos Básicos
Custo do Defeito
8
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
TESTE X
DESENVOLVIMENTO
Casos de Testes
PROCESSO BÁSICO DE TESTE
Planejar
Planejar
Testes
Testes
Projetar
Testes
Executar
Testes
Analisar
Resultados
Gerenciar
Defeitos
12
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.
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.
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
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
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
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 829-2008 (IEEE Standard for Software Test Documentation) descreve um conjunto de documentos para as atividades de teste
de um projeto de software.
18
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
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
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
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
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
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
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
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
ELABORAÇÃO DO CASO DE TESTE
Os seguintes itens devem ser abordados:
Abordagens para determinar os casos de testes – ISO 29.119
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
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
Teste na fase de Especificação
Assegura Qualidade,
Testabilidade,
Testabilidade,
Completude,
Mensurabilidade das demandas,
Entendimento dos Requisitos e
principalmente ANTECIPA PROBLEMAS
29
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
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
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
Rastreabilidade Teste / Requisito
Mudança de
um Requisito
Planejar
Projetar
Testes
Testes
Atualiza/Versiona os
Casos de Testes
Associados
Requisito
Teste
Caso de Teste
Artefatos Gerados
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”.
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
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
CT – Preenchimento www.iteste.com.br
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
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
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.
DETALHANDO A SITUAÇÃO ANTERIOR
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
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 999999, 00000.
44
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.
EXERCÍCIO
CT01 Preenchimento dos campos obrigatório na
tela de transferência.
PERGUNTAS?
FIM
[email protected]
[email protected]
www.emersonrios.eti.br