Fundamentos em Teste de Software

Módulo 4 – Elaborando os testes

Érika Hmeljevski – 2010

Onde estamos?
 Projetando os testes

Atividades:

1. Análise dos Testes

 Verificação dos requisitos;
 Rastreabilidade dos testes;
 Testabilidade dos requisitos (é possível verificar a
implementação? como?).

2. Especificação dos Testes

 Elaborar os cenários de teste;
 Elaborar os casos de teste;
 Estruturar os scripts de teste.
 Revisões e Inspeções
Revisão técnica ou inspeção de software
É um processo que visa melhorar a qualidade dos produtos
desenvolvidos e criar condições para reduzir os prazos e os
custos de desenvolvimento, pela drástica redução do re-trabalho
estimado em 44% (Boehm - 1987).

“Uma inspeção remove de 60% a 65% dos defeitos existentes em um

produto, seja um documento ou um código.”

(T.Capers Jones no livro “Estimating Software Costs”)

 Revisões
Formais
Um grupo de pessoas seguindo procedimentos formais, se
dedica a descobrir defeitos em produtos (documentos ou códigos).

Informais
Normalmente feita entre os técnicos envolvidos. Não existem
restrições sobre a validade do defeito e/ou a solução para a correção.

Regras para revisão ou inspeção técnica (QAI):

 Deve sempre existir um documento de registro de defeitos;
 Quem deve sofrer revisão é o produto, nunca o produtor;
 Defeitos devem ser identificados e nunca corrigidos;
 Todos os membros da equipe de revisão devem ser responsáveis pelo
resultado do trabalho de revisão.
 Beneficios de se investir em revisões
Segundo Glenford Myers no seu livro “The Art of Software Testing”
lançado em 1979 :

 Os testes unitários podem remover entre 30% e 50% dos defeitos dos
programas;
 Os testes de sistemas podem remover entre 30 e 50% dos defeitos
que sobrarem;
 Desta forma os sistemas podem ir para produção ainda com 49% de
defeitos;
 Por último ele afirma que revisões de códigos podem ainda reduzir
entre 20% e 30% destes defeitos.

Segundo o QAI 36% dos erros encontrados nos softwares são

provenientes de codificação e 64% dos erros de desenho e análise, a
maior parte dos erros está nas fases onde corrigí-los custa muito
menos.
 Análise dos Testes
Utilize técnica de Inspeção/ Revisão

Durante a análise, deve ser verificado:

 Se cada requisito está identificado – visando possibilitar a correlação

entre o requisito e a especificação do teste;

 Estabelecer a “rastreabilidade” dos testes;

 Se existem requisitos contraditórios, ambíguos ou ausentes;

 Se cada requisito e a especificação como um todo é “entendível”;

 A forma de verificar a implementação do requisito (método para testar

durante o teste formal).
 Especificação dos Testes

 O produto da Análise é a base para a Especificação.

 O testador deve implementar a técnica ou método de testar cada

requisito.

Produtos da Especificação:

 Cenários de Teste

 Casos de Teste

 Scripts de teste
 Derivação do Caso de Teste

Os casos de testes são derivados de uma especificação formal que

define os requisitos

Requerimentos, Casos de Uso, etc

Casos de
Teste
Requerimentos
Casos de Uso
 Derivação do Caso de Teste

Requisitos : Latim requisitu

Condição exigida para a

consecução de um certo
fim.

 Fluxo Básico
 Fluxo Alternativo

Ao percorrer os possíveis
caminhos diversos cenários
são identificados RUP – IBM rational [RUP 2002]
O caso de Teste como centro motivador
do teste
O que motivou o meu teste ? Onde devo testar ?

Requisitos Configurações

Caso de Teste

Iteração Implementação

Quando devo testar ? Como devo testar ?

 Tipos de Casos de Testes
Casos de Teste Positivos

 Faz o que foi requerido?

Casos de Testes Negativos

 Agredir o software

 Rede desconectada, portas indisponíveis.

 Valores estranhos

 Disco: arquivo não encontrado, disco cheio,etc.

 Memória: Memória insuficiente, etc.

 Casos de Teste - Definição
Caso de teste é a especificação mais detalhada do
teste, composta por:

 Conjunto de entradas
 Condições de execução
 Resultados esperados

Tendo como objetivo verificar os requisitos especificados do sistema

Os casos de teste estabelecem quais informações serão empregadas durante

os testes dos cenários e quais serão os resultados esperados,
estabelecendo a massa crítica de teste necessária para validar todos os
requisitos do software
 Cenário de Teste

Transferência “DOC para conta de terceiros”

 Requisitos de Teste
Dentro deste cenário de teste podemos destacar requisitos de
testes:
 CT01 Preenchimento dos campos obrigatórios na tela de
transferência
 CT02 Validação de CPF
 CT03 Conta Destino inválida
 CT04 Transferência de valores negativos,etc.
Caso de Teste – Número de confirmação inválido

Preencher o campo número de confirmação

com um número inválido

O Sistema apresenta
uma mensagem
Padrão de Qualidade do Caso de Teste

 Efetivo – Testar o que se planejou testar

 Econômico – Sem passos desnecessários

 Reutilizável – Possa ser repetido

 Rastreável – Possa identificar o requisito a ser testado

 Autoexplicativo – Possa ser testado por qualquer pessoa

Problemas na Elaboração dos Casos
de Teste
Considere a seguinte situação:

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
 Detalhando a situação anterior
1 – Deve operar em diferentes Browsers:
Para esta situação podemos
considerar a possibilidade de
 Internet Explorer 5  Internet Explorer 7
criarmos 1296 diferentes
 Internet Explorer 6  Netscape 9
combinações de ambientes
 Netscape 8  Firefox 3
para cada caso de teste criado.
 Firefox 2  Opera 9
2 - Deve poder usar diferentes plug-ins:RealPlayer, MediaPlayer, não usar
nenhum;

3 - Rodar em diferentes sistemas operacionais nas máquinas clientes:

 Windows 98  Fedora

 Linux  Windows XP
 Windows 2000  Windows Vista

4 - Deve receber páginas por diferentes servidores : IIS, WebLogic e

Apache.
5 - Deve rodar em diferentes servidores: Windows 2000, Windows Server
2003, NTLinux.
 Exemplo de Caso de Teste
Funcionalidade: Incluir usuário

Caso de Teste:

Passo: Preencher a tela de usuário com seus campos

obrigatórios e selecionar a opção incluir

Resultado esperado: Mensagem de Incluído com sucesso

Ambiente de teste: Máquina cliente com sistema

operacional Windows 2000, utilizando o Internet Explorer 6.0
como Browser, recebendo páginas de um servidor com Apache e
ter um servidor de Websphere em Linux.
 Como escolher?
 Não testar, simplesmente desistir por causa do número elevado de
combinações.
 Testar todas as combinações possíveis .
 Escolher uma ou duas combinações e torcer para ter sido uma boa
escolha.
Fazer uma lista de todas as combinações possíveis e escolher as
mais importantes.
 Fazer uma lista de todas as combinações possíveis e escolher
subconjuntos randomicamente.
 Escolher um subconjunto que possa ser o mais provável de se
encontrar mais defeitos.
 Escolher o teste mais fácil, ignorando os mais usados e que
agreguem mais valores.
Problemas na Elaboração dos Casos

Testes exaustivos são impraticáveis.

Escolher bons casos de testes (dados de entrada e

comportamento esperado) é fundamental para que
um teste seja bem sucedido,
isto é, detecte os erros existentes.
Métodos para Elaboração de Casos
de Teste

 Step-by-Step

 Causa-efeito

 PairWise

 Classes de equivalência

 Análise de valores limítrofes

 Método Step-by-Step
1. Listar os requisitos de teste baseado nas especificações do
sistema:

Identificar os requisitos óbvios do teste lembrando que os requisitos não

são indicações exatas das entradas e saídas, mas sim idéias do que deve
ser testado.
2. Adicionar requisitos de teste para cobrir adequadamente o
domínio de cada entrada:
Consiste em testar valores médios, limites e que extrapolem as condições
limites, entradas ilegais e condições de erro.

3. Listar um caso de teste para cada requisito de teste:

Pensar nos vários requisitos de teste em várias perspectivas de forma a
detectar diferentes tipos de defeitos. Essa abordagem ajuda a testar a
confiabilidade do sistema sob o uso constante.
 Método Step-by-Step
4. Revisar os casos de teste completando o que for necessário:
Listar todos os casos de teste verificando a aplicabilidade a cada
especificação do sistema.

5. Escrever um caso de teste:

Para cada teste considerar as entradas e saídas, entradas especiais, a
configuração necessária para execução e definir como o testador saberá
se o teste passou ou falhou.

6. Agrupar os casos de teste em scripts de teste:

Neste passo é possível ser mais eficiente agrupando.
 Método Causa-Efeito
Esta técnica oferece um representação concisa das condições
lógicas e das ações correspondentes.

A técnica segue 4 passos:

1. Causas (condições de entrada) e efeitos (ações) são

relacionados para um módulo e um identificador é
atribuído a cada um.

1. Uma situação de causa-efeito é desenvolvida.

2. Essa situação é convertida numa tabela de decisão.

3. As regras da tabela são convertidas em casos de teste.

 Método Causa-Efeito

Exemplo:
Programa de cobrança de chamadas telefônicas
obs: Valores das chamadas são definidos de acordo
com a duração, destino e faixa de horário

Tipo Chamada Horário Duração Valor

Local 6h/24h 1h X
DDD 21h/9h 10 min Y
DDI 0h/6h 1 min Z
 Método Causa-Efeito
Funcionalidade: Calcular valor da chamada

Caso de Teste 001:

Entrada: Local igual a Florianópolis, horário igual a 12:00 e

duração igual a 0:45.

Resultado esperado: O resultado do valor calculado pelo sistema

para esta chamada deve ser igual a X.
 Método Pair-Wise

Teste de Combinação Dupla é um dos

critérios de teste baseado na
especificação, que requer que para cada
par de parâmetros de entrada de um
sistema, cada combinação de valores
válidos destes dois parâmetros seja
coberto ao menos por um caso do teste.
 Método Classe de Equivalência
Introduzida por Myers em 1979 - Usada para reduzir o número de casos
de teste a um nível controlável, mantendo uma cobertura razoável

Consiste em dividir todas as combinações possíveis em

classes

Exemplos:

Vamos supor que o campo idade deva ter valores dentro dos
seguintes limites:
18 <= idade <= 65

Isto daria as seguintes classes de equivalência para serem testadas:

idade menor ou igual a 18;
idade entre 18 e 65;
idade maior do que 65.
Casos de teste derivado de classes de
equivalência
CT – 001 campo idade invalido
Entrada = 10
Resultado = valor inválido

CT – 002 campo idade invalido

Entrada = 70
Resultado = valor inválido

CT – 003 campo idade valido

Entrada = 35
Resultado = valor correto
 Método Valores Limítrofes

 Valida valores limites (Valores de Fronteira )

 Situações com alta incidência de erros
 Complementa o método de Classes de Equivalência

Vamos supor que o campo idade deva ter valores dentro dos
seguintes limites:
18 <= idade <= 65

Os valores limítrofes são:

Idade igual a 17,
Idade igual a 18,
Idade igual a 19,
Idade igual a 64,
Idade igual a 65,
Idade igual a 66.
Casos de testes baseados no metodo de
valores limitrofes
CT-001
Entrada: idade igual a 17
Resultado esperado: valor invalido
CT-002
Entrada: idade igual a 18
Resultado esperado: valor valido
CT-003
Entrada: idade igual a 19
Resultado esperado: valor valido
CT-004
Entrada: idade igual a 64
Resultado esperado: valor valido
CT-005
Entrada: idade igual a 65
Resultado esperado: valor valido
CT-006
Entrada: idade igual a 66
Resultado esperado: valor invalido
 Desafios para um Caso de Teste
1 - Mudança de Requisito

 Manter-se sempre bem informado – Rastreabilidade

 Descobrir onde estão os maiores riscos de mudanças nos

requisitos

 Construa seu caso de teste com variáveis no meio do texto

 Compartilhe a responsabilidade do retrabalho com a

gerência do projeto

 Identificar o documento que serviu de base para a

elaboração
 Desafios para um Caso de Teste
2- Mudança de Cronograma

 Diminuição do prazo – compartilhe a responsabilidade /

mudança de escopo

 Tente manter a elaboração na frente da execução, pelo

menos um cenário

 “Enxugue” o caso de teste de forma a ganhar tempo na

elaboração

 Escrever o caso de teste enquanto testa

 Desafios para um Caso de Teste
3 - Rotatividade da Equipe de Teste

 Possuir sempre material de consulta a padrões,

templates e exemplos, etc.

 Treinamento

36
Por que utilizar Templates?

 Impede “pânico da página em branco”

 Socorre o desorganizado

 Construção em padrões

 Imprime testes “elegantes”

 Auxilia os recursos de testes a localizar

informações
Exemplo utilizando Template
Exemplo de Caso de Teste
Exemplo de Caso de Teste
Exemplo de Caso de Teste
Exemplo de Caso de Teste
Exemplo de Caso de Teste
 Considerações sobre geração de
Scripts de Teste
 Gerar um script para cada caso de teste a ser automatizado
(independência de scripts);
 Caso um falhe na execução, não interfere na execução dos demais;
 Scripts automatizados devem ter o ponto de partida em comum.

Características:

Os scripts desenvolvidos contêm as seguintes ações:

Navegação da interface
Funções específicas de negócio
Pontos de verificação
 Manual X Automático

Tempos de Execução de Testes por Casos de Uso

(a) Simples; (b) Intermediário; (c) Complexo
 Considerações Finais

 No caso da automação, o esforço do primeiro ciclo de um caso de uso

é a junção da codificação com a execução de um teste e um re-teste dos
seus scripts. Nos ciclos seguintes, são adicionados apenas os esforços
referentes à execução de scripts (teste e reteste).

 A automação gerou um volume elevado de esforço no começo de sua

implantação,devido à fase de aprendizagem com as ferramentas de
automação e os processos organizacionais de teste.

 A comparação das abordagens de testes manuais e automatizados se

mostrou limitada em alguns casos. As análises comprovaram a
ineficiência da automação de teste em projetos que seguem ciclo de vida
cascata e que não apresentem mais de dois ciclos de teste.
Dúvidas