You are on page 1of 2

22/8/2014 Casos de Testes Funcionais

http://testersoftware.blogspot.com.br/2010/08/casos-de-testes-funcionais.html 1/3
23rd August 2010
Teste Funcional tem como objetivo medir a qualidade funcional de componentes de um sistema.
Quando se realiza um teste funcional está na verdade confrontando com o que se espera que o
sistema vá fazer, ou seja, incluindo entrada de dados, processamento e resposta. A seguir são
apresentadas algumas dicas de técnicas para montar os casos de testes funcionais.
Dica 1: Se você criou os seus requisitos de teste ou tem pelo menos o suficiente para iniciar o teste,
fica mais fácil definir a técnica de teste a ser usada do projeto e execução do caso de teste, vá para a
dica 3;
Dica 2: Se você não tem requisito de teste e/ou não trabalha ou e/ ou não precisa criar segundo a
orientação da sua empresa, então ai vão as dicas de como fazer os requisitos de teste. Ele podem ser
levantado de documentos formais, especificações de usuário e casos de uso (caso esteja usando
UML). Deve ser de fácil entendimento, claro e deve conter as devidas explicações. A estrutura de
requisitos de teste é composta pela:
Identificação do requisito de teste: É um número ou identificador único;
Descrição: Sumária e detalhada;
Status: É a posição atual no ciclo de vida de um requisito de teste;
Relacionamento e dependência: Relacionamento e dependência para com requisitos e casos de
testes.
Ajuda muito ter requisito de testes para criar casos de testes. Vá para a próxima dica;
Dica 3: Leia a documentação que tem em mãos, e se não tiver nada, defina em linhas gerais o que
você precisa testar. Vá para próxima dica;
Dica 4: Se você possui algum caso de uso como base para planejar o seu teste siga as dicas e
orientações para extrair os casos de teste de casos de uso. A partir da estrutura normal de um caso de
uso, detectam-se duas formas de derivar casos de teste a partir do caso de uso que são:
Derivação textual: Cada caminho deve ser mapeado, pois de cada caminho estaremos extraindo
um requisito de teste. Cada variação dentro do próprio caminho definira o conjunto de teste;
Derivação visual: Todo o caso de uso tem um desenho de todos os fluxos de eventos juntos, que
pode ser usado como base na derivação visual;
Por tanto, se a situação se aplica ao seu caso, use essas dicas e continue lendo;
Dica 5: Se o seu sistema como um todo possui estados como exemplo usuário ativo, inativo ou
bloqueado que precisa ser testado, use o teste de transição de estado. Em especial é recomendável
usa-lo quando existir algum diagrama de transição de estados. Para quem usa UML, essa ferramenta
possui um diagrama de transição de estados que é usado para modelar ou mostrar "estados" de
objetos. Se a situação se aplica ao seu caso, use esta dica e continue lendo;
Dica 6: Pode ser usada alguma lógica que possa ser extraída de algum documento ou pode usar as
técnicas de teste de equivalência de classe, teste de valor limite, teste por tabela de decisão, pairwise
testing, teste de transição de estado, teste de análise de domínio e testes planejados versus testes
exploratórios. Se a situação se aplica ao seu caso, use essa dica e continue;
Dica 7: Se a tela de teste possui campos, mas sem muitas situações que se entrelacem exemplo que
campo A depende de B, que depende de C, basta usar combinações. Pode usar neste caso o teste de
array ortogonal e inserir mais algumas combinações que você achar pertinentes. Se a situação se
Casos de Testes Funcionais
22/8/2014 Casos de Testes Funcionais
http://testersoftware.blogspot.com.br/2010/08/casos-de-testes-funcionais.html 2/3
aplicar ao seu caso, use essa dica e continue;
Dica 8: Se a sua tela possui muitos campos com muitas com muitas situações que se entrelaçam, tais
como regras de negócio, faça as combinações que você acha pertinentes em função das regras que
seu teste pede. Neste caso é aconselhável usar teste por tabela
de decisões se o nível de complexidade for alto ou médio. Se a situação se aplica ao seu caso, use
essa dica e continue;
Dica 9: Para cada campo insira situações de teste que contemplem o teste de valor limite. Aqui você
precisa testar e validar os valores de fronteira usados em cada campo. Se a situação se aplicar ao seu
caso, use essa dica e continue;
Dica 10: Se você precisar deduzir casos de testes a partir de regras ou conjunto de regras, pode ser
interessante usar o teste de equivalência de classe. Se a situação se aplicar ao seu caso, use essa
dica e continue;
Dica 11: Se você precisa testar e validar valores que trabalhem com domínio ou conjuntos e que
tenham regras matemáticas envolvidas, pode ser interessante usar o teste de analise de domínio. Se a
situação se aplicar ao seu caso, use essa dica e continue;
Dica 12: Não esqueça de testar, caso exista envolvimento com algum Banco de Dados, os dados lidos,
eliminados ou gravados. Muitas vezes aparece o dado certo na tela, mas está gravado errado no
Banco de Dados;
Dica 13: Insira casos de testes que permitam verificar e comparar logs das aplicações envolvidas. Uma
informação pequena no meio de um log pode ser a chave para a descoberta ou comprovação de um
grande erro;
Dica 14: Insira e complemente os casos de testes levantados com a situação que você deduziu e
observou. Por exemplo, se você usou array ortogonal, complete com algumas combinações que
possam gerar mais casos de testes. Colocando de forma mais simples: combine os testes levantados a
partir da técnica adequada + teste vitais levantando a partir de regras de negocio essenciais + seu
bom senso de observação e dedução;
Referência:
MOLINARI, Leonardo. Teste de Software. Produzindo Sistemas Melhores e Mais Confiáveis. 1. ed. São
Paulo: Érica, 2003.
Postado há 23rd August 2010 por Rosangela Geremia Roessler

3
Visualizar comentários
Jeanne Trovão 27 de janeiro de 2012 01:48
Olá, Rosângela, adorei o post.
Sobre a dica 12, vc conhece alguma ferramenta de teste funcional que faça essa validação no banco
de dados? trabalho com isso mas essa parte da validação no banco é manual e gostaria de otimizar.
se souber de alguma será de grande ajuda! :)
Responder
Roberto Jr 25 de setembro de 2012 15:04