Parametrização de Dados para Automação de Teste – Introdução

Parametrizacao Dados Automacao_menor

Introdução

Quando criamos scrips de automação de teste é muito comum pensar na Massa de Dados (os dados que usaremos para os testes). Como estamos trabalhando com automação trabalhar com os dados hard coded não é uma solução viável, uma vez que a massa de dados pode sofrer alterações, sendo necessário alterar o próprio script de automação.

Neste post veremos a conceituação geral dos teste que iremos executar, o que é um parâmetro hard coded e as formas de parametrização que apresentarei nos futuros posts.

Conceituação Geral

Caso de Teste

Iremos executar um simples preenchimento de um formulário onde o campo Faixa é um fator de alteração em um campo chamado %Taxa, ou seja, quando alteramos a faixa o resultado de %Taxa também é alterado.

Vejamos então uma tabela de decisão para o %Taxa:

Nome Cidade Faixa % Taxa
Jose São Paulo Até 18 anos Os juros serão de 60%
Maria Belo Horizonte Entre 19 e 25 anos Os juros serão de 40%
João Florianópolis Entre 26 e 60 anos Os juros serão de 30%
Carla Vitória Maior que 60 anos Os juros serão de 20%

O teste consiste em preencher todos os campos e validar os resultados ao final.

 

caso_teste_parametros

 

Se você quiser testar manualmente acesse a URL da página de exemplo:
http://eliasnogueira.com/arquivos_blog/post_parametros/

Parametrização hard coded

Uma parametrização hard coded é aquela onde os dados estão fixos no seu script de automação, e a cada execução em outra condição ou com alteração dos dados, é necessário abrir o código, alterá-lo e executa-lo novamente.

Exemplo:

exemplo_Codigo_HardCoded

Você pode notar na parte destacada em vermelho que os dados estão inseridos no próprio script. Isso é uma ação normal mas que nos traz uma grande quantidade de manutenção para trocar os dados a fim de cobrir todos os casos de teste que temos frente a tabela de decisão. Teríamos depois do script pronto mais 3 alterações e também precisaríamos executar o script a cada alteração.

O código completo deste script automatizado está abaixo (mas tente fazer você sozinho heim!)

Tipos de Parametrização

Existem diversos tipos de parametrização para evitar ao máximo as manutenções nos scrips de teste. Veremos, nos próximos posts, duas formas:

  • Parametrização por arquivo de propriedades
  • Parametrização por Data Driven (Guiado a dados)
    • Com JUnit
    • Com TestNG
    • Com JUnit usando arquivos .csv

Fiquem ligados nos próximos posts da série e, qualquer dúvida, deixem um comentário 🙂

 

14 comentários em “Parametrização de Dados para Automação de Teste – Introdução

  1. Olá, Muito legal o assunto,

    Estou tentando entrar no link referente a parte II e a página não é carregada
    Ouve algum problema?

    Parabéns pelo post, estou iniciando em automação e alguns esclarecimentos aqui estão me auxiliando

  2. Muito legal!
    Conheci a parametrização a uns 3 anos atrás quando fiz estágio na Dataprev… realmente o ganho com manutenção é enorme e ainda tem o reuso de código, que ganhamos quando precisamos usar conjuntos de dados diferentes em um mesmo fluxo para testar cenários diferentes.

      1. Então… os testes eram escritos em Java com SilkTest. Os dados do teste eram inseridos em um arquivo csv. O teste lia os dados deste arquivo e atribuía à variáveis do teste. Alguns desses arquivos csv tinhão mais de 1 conjunto de dados que permitia executar o mesmo caso com diversas combinações de dados. (verificar os limites dos campos e strings com diversos tipos de caracteres especiais).
        Atualmente to iniciando automação com protractor e estava fazendo sem pensar em parametrização.. mas teu post me fez relembrar da boa prática 🙂

  3. Elias, quando há projeto com 2 mil casos de testes para automatizar, onde a massa é consumida a cada execução, qual é a melhor maneira para fazer a massa de dados? Um caso de teste para cada planilha? um caso de teste para cada aba de uma planilha?

    Obrigado e Parabéns.

    1. Oi Gustavo,
      Depende muito como tu prefere gerenciar estes dados.
      Dados que serão dependentes de diversos testes podem ser pré cadastrados de antemão na base se tu puder fazer isso.
      Eu adoto a abordagem de ter um arquivo .csv (planilha) para cada caso de teste para isolar qualquer problema que possa ocorrer com os dados.

      Abraço!

  4. Interessante o assunto.
    Na empresa em que trabalho, estamos implementando os testes automatizados.
    Porém o sistema é muito grande e muitas das funcionalidades críticas dependem de outros cadastros.
    Nossa abordagem atual é de criar tudo o que é necessário antes para que um determinado teste funcione, mas e se alguma das telas que eu utilizo parar criar o cenário estiver com problema

    Então como eu poderia proceder nessa situação?
    Estava pensando em já deixar algumas coisas que não são necessariamente críticas já cadastradas, para meu teste se preocupar apenas com a funcionalidade crítica, o que vocês acham?
    E vocês fazem como parar testar funcionalidades críticas que necessitam de muitos outros dados?

    1. Cassio,
      Uma abordagem pode ser o pré-cadastro das informações básicas no próprio banco, manualmente ou através de um script SQL antes de executar um teste. Ai a massa de dados do teste automatizado em si tu usa normalmente, e esta está fortemente ligada (dependente) aos dados do banco.
      Tu podes adotar isso para ter o que é crítico para ti já pré cadastrado.

      Não vai ter como fugir da necessidade de dados. O que eu tenho feito é exatamente a abordagem que te passei: eu já crio uma passa de dados que sei que irão servir para todos os testes. Antes de iniciar a execução (manual ou automatizada) eu executo um script .sql que faz a inclusão destes dados, e depois limpo a base no final.

      Abraço!

  5. Com certeza a parametrização é um ganho enorme na manutenabilidade do script. Utilizo planilhas do excel, onde os casos de teste já são desenhados pensando na massa de dados que será utilizada na automação dos testes.

    1. Show de bola Luiz!
      Esse será o assunto do próximo post desta série, mas co Java.
      Te convido a criar um post em algum lugar para mostrar um exemplo em C#, ou mesmo fazer um “guest post” aqui 🙂

      Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *