Menu

Como desenvolver scripts de teste usando as 5 estruturas de automação de teste mais populares (exemplos)

how develop test scripts using top 5 most popular test automation frameworks

Experimente Nosso Instrumento Para Eliminar Problemas

Quando você começa a aprender sobre automação de teste, deve encontrar o termo “estrutura de automação de teste”. Talvez alguns de vocês fiquem incomodados com este termo e comecem a sentir que é algo difícil de entender e ainda mais difícil de implementar.

Este tutorial foi escrito com o objetivo de ajudá-lo a entender as estruturas de automação de teste da maneira mais simples possível. Leia todos os tutoriais neste ' Série de tutoriais de teste de automação aqui .

melhor software de remoção de vírus para pc

Estrutura de automação de teste (em uma linguagem muito simples) é 'conjunto de regras'. As regras nos ajudam a escrever scripts de maneira que resulte em “menor manutenção”.

Para entender completamente o conceito de estrutura, primeiro temos que aprender como escrevemos scripts simples e, em seguida, como implementar uma estrutura neles.

scripts de teste usando estruturas de automação

Na automação de teste, escrevemos scripts. O script é basicamente sobre três 'A's:

  1. ARRANJO
  2. AÇAO
  3. AFIRMAÇÃO

Abaixo estão os detalhes de cada A, com exemplos:

# 1.ARRANJOou Identificação de Objeto

Identificamos objetos (botões, menus suspensos etc.) por seus ids, nomes ou por seus títulos de janela etc.

No caso do aplicativo da web, identificamos por ID de usuário, por XPath ou por CSS ou por nome de classe etc. Se nada funcionar, identificamos os objetos usando as coordenadas do mouse (mas não é um método confiável de identificação de objetos)

Veja este exemplo de Selenium WebDriver (com C #) em que identificamos objetos usando o id. (Aplicativo da Web)

IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));

Outro exemplo de MS Coded UI (aplicativo de desktop)

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Após a identificação, organizamos ou armazenamos esses objetos em UIMaps ou Repositório de objetos para reutilizá-los em nossos scripts. É por isso que esta etapa é chamada ARRANGEMENT.

#dois.AÇAOno objeto identificado

Quando os objetos são identificados, realizamos algum tipo de ação sobre eles com o mouse ou com o teclado.Por exemplo, ou clicamos, ou clicamos duas vezes, ou passamos o mouse sobre ele ou às vezes arrastamos e soltamos. Às vezes, escrevemos em caixas de texto. Portanto, qualquer tipo de ação que realizamos nesses objetos é abordada nesta segunda etapa.

Exemplo 1 : (Selenium WebDriver com C #)

txtServer.Clear(); txtServer.SendKeys(“Some sample text”);

Exemplo 2 : (MS Coded UI com C #)

Mouse.Click(buttonAdd);

# 3.AFIRMAÇÃO

A afirmação é basicamente verificar o objeto com algum resultado esperado. Por exemplo, se pressionarmos 2 + 3 na calculadora, a tela deverá mostrar 5. Nesse caso, nosso resultado esperado é 5. Este conceito já foi explicado em nosso primeiro tutorial.

Aqui, damos um exemplo de afirmação:

Assert.AreEqual('5', txtResult.DisplayText);

Quase todo script escrito em automação de teste contém essas três coisas: Arrangement, Action e Assertion.

Agora dê uma olhada em um script completo que contém todas essas etapas. O script abrirá uma calculadora, pressione 1 + 6 e verifique se a tela mostra 7 ou não.

script de teste para estrutura de automação

Exemplo A:

(TestMethod) (TestMethod) public void TestCalculator() { var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //Object identification part (ARRANGEMENT) //----*Calculator Window----*// WinWindow calWindow = new WinWindow(app); calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; //----*Button1 ----*// WinButton btn1 = new WinButton(calWindow); btn1.SearchProperties(WinButton.PropertyNames.Name) = '1'; //----*Button Add ----*// WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add'; //----*Button 6 ----*// WinButton btn6 = new WinButton(calWindow); btn6.SearchProperties(WinButton.PropertyNames.Name) = '6'; //----*Button Equals ----*// WinButton btnEquals = new WinButton(calWindow); btnEquals.SearchProperties(WinButton.PropertyNames.Name) = 'Equals'; //----*Text Box Results----*// WinText txtResult = new WinText(calWindow); txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; //(ACTIONS Part) // Click '1' button Mouse.Click(btn1); // Click 'Add' button Mouse.Click(btnAdd); // Click '6' button Mouse.Click(btn6); // Click 'Equals' button Mouse.Click(btnEquals); //evaluate the results (ASSERTIONS) Assert.AreEqual('7', txtResult.DisplayText, “Screen is not displaying 7); //close the application app.Close(); }

O que você aprenderá:

O que há de errado com esse script?

O script é fácil de entender e espero que você tenha entendido o conceito de três 'A's no exemplo acima. Mas nem tudo está bem com esse script.

Este script não permite fácil manutenção. Pegue o exemplo da calculadora novamente, se tivermos que escrever casos de teste para cada função da calculadora, haverá muitos casos de teste. Se houver 10 casos de teste e em cada teste, temos que definir o mesmo objeto, então se ocorrer alguma mudança no nome ou id do objeto, temos que mudar a parte de identificação do objeto em 10 casos de teste.

Por exemplo, veja o exemplo do botão ADICIONAR no script.

WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';

Digamos que esta linha seja usada em 10 casos de teste. Agora, na próxima versão da calculadora, o desenvolvedor alterou o nome do botão de “Adicionar” para “Mais”. Agora, quando executarmos nossos casos de teste, eles falharão e temos que mudar a linha acima para isso em 10 casos de teste.

btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Plus';

Portanto, temos que melhorar esse caso de teste. Devemos seguir o famoso princípio DRY em nossa codificação. DRY significa “Do Not Repeat Yourself”. Devemos escrever a parte de identificação do objeto de tal maneira que o objeto deve ser identificado apenas em um lugar e deve ser chamado em todos os lugares.

Dê uma olhada no script aprimorado.

Exemplo B:

//defining the objects outside the script and only once. ApplicationUnderTest app = null; public WinWindow calWindow { get { WinWindow _calWindow = new WinWindow(app); _calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; _calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; return _calWindow; } } public WinText txtResult { get { WinText _txtResult = new WinText(calWindow); _txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; return _txtResult; } } //making functions for similar kind of tasks public void ClickButton(string BtnName) { WinButton button = new WinButton(calWindow); button.SearchProperties(WinButton.PropertyNames.Name) = BtnName ; Mouse.Click(button); } public void AddTwoNumbers(string number1, string number2) { ClickButton(number1); ClickButton('Add'); ClickButton(number2); ClickButton('Equals'); } //Test case becomes simple and easy to maintain. (TestMethod) public void TestCalculatorModular() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers('6', '1'); //evaluate the results Assert.AreEqual('7', txtResult.DisplayText, “screen is not displaying 7”); //close the application app.Close(); }

No exemplo acima, separamos o calWindow e txtResult objetos e mova-os para o topo para que possam ser usados ​​em diferentes métodos de teste. Nós os definimos apenas uma vez e podemos usá-los em quantos casos de teste quisermos.

Também criamos duas funções. ClickButton () que aceita um nome de botão e clica nele e AddTwoNumbers () que pega quaisquer dois números e os soma usando o clique no botão função dentro dele.

No momento em que começamos a “melhorar” nosso código e torná-lo reutilizável e sustentável, significa que estamos fazendo uso de qualquer framework de automação. Agora fica interessante.

Veja também=> Por que precisamos da estrutura para automação de teste?

tem cinco frameworks populares em automação de teste :

  1. Linear
  2. Modularidade
  3. Orientado por dados
  4. Orientado por palavras-chave
  5. Híbrido

Vamos agora explicar cada estrutura com a ajuda de suas características.

# 1. Estrutura Linear:

Características

  • Tudo relacionado a um script é definido dentro dos scripts.
  • Não se preocupa com abstração e duplicação de código
  • Gravar e reproduzir normalmente geram código linear
  • Fácil de começar
  • Pesadelo de manutenção.

Ao ler as 5 características acima da Estrutura Linear, podemos facilmente relacionar nosso Exemplo A a elas. Este exemplo está basicamente usando a estrutura Linear, tudo relacionado a um script é definido dentro do script. O janela de chamada e TxtResult são definidos dentro do script. O script não se preocupa com abstração e duplicação de código. É também um pesadelo de manutenção, como expliquei anteriormente.

Então, por que devemos usar essa estrutura?

Essa estrutura pode ser usada em projetos de pequena escala onde não há muitas telas de IU. Além disso, quando usamos qualquer ferramenta de automação pela primeira vez, ela normalmente gera código na forma linear. Assim, podemos aprender sobre qual código é gerado pela ferramenta de automação para ações específicas. Além desses motivos, essa estrutura deve ser evitada em seu script.

=> Veja aqui o exemplo de Linear and Keyword Framework com exemplo de QTP.

# 2. Estrutura da Modularidade:

Características

  • Os objetos são definidos uma vez e reutilizáveis ​​em todos os métodos de teste.
  • Métodos pequenos e diretos são criados para funcionalidades individuais
  • O caso de teste é a coleção desses pequenos métodos e objetos reutilizáveis
  • Isso nos permite escrever código sustentável.

Lendo as características acima, podemos relacionar nosso Exemplo B a essas características. Nesse exemplo, criamos uma abstração movendo o calWindow para o topo e defini-lo dentro de uma propriedade que pode ser usada em qualquer lugar. Criamos duas funções pequenas e independentes chamadas ClickButton () e AddTwoNumbers () . Combinamos essas duas pequenas funções para criar nosso script final que testa a funcionalidade “Adicionar” da calculadora.

como faço para encontrar uma chave de segurança de rede

Isso resulta em uma manutenção mais fácil. Se ocorrer alguma mudança na IU da calculadora, teremos que mudar apenas nas funções. Nossos scripts permanecerão intactos. Esta estrutura é muito utilizada em automação. O famoso Page Object Framework (que é usado com Selenium) também é um tipo de estrutura de modularidade. Distribuímos todo o aplicativo da web em páginas separadas. Os botões, menus suspensos e caixas de seleção de cada página são definidos dentro da classe dessa página. Se ocorrer alguma alteração no site, temos que alterar apenas essa classe de página e as outras páginas permanecem intactas. Isso resulta em melhor manutenção e legibilidade mais fácil dos scripts.

A única desvantagem dessa estrutura é que ela requer bons conceitos orientados a objetos e fortes habilidades de desenvolvimento. Se você tiver esses, esta estrutura é altamente recomendada.

# 3. Estrutura baseada em dados:

Características:

  • Os dados de teste (valores de entrada e saída) são separados do script e armazenados em arquivos externos. Pode ser um arquivo .csv, uma planilha do Excel ou um banco de dados.
  • Quando o script é executado, esses valores são selecionados de arquivos externos, armazenados em variáveis ​​e substituem os valores embutidos no código, se houver.
  • Muito útil em locais onde o mesmo caso de teste deve ser executado com entradas diferentes.

Exemplo C:

Queremos executar o caso de teste add com três entradas diferentes.

Os dados são
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5

Armazenamos esses dados (entrada e saída) em um arquivo CSV externo.

Exemplo de estrutura baseada em dados

(DataSource('Microsoft.VisualStudio.TestTools.DataSource.CSV', '|DataDirectory|\data.csv', 'data#csv', DataAccessMethod. Sequential ), DeploymentItem('TestCalc\data.csv'), TestMethod) public void TestCalculatorDataDrivsen() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers(FromCSV.ADD1, FromCSV.ADD2); //evaluate the results Assert.AreEqual(FromCSV.Sum, txtResult.DisplayText); //close the application app.Close(); }

No script acima, definimos nossa fonte de dados na parte superior do script, que é um arquivo .csv.

Fornecemos o caminho desse arquivo .csv e informamos ao script para analisá-lo “Sequencialmente”. Isso significa que o script será executado tantas vezes quanto houver linhas presentes no arquivo CSV. Em nosso caso, o script será executado 3 vezes. Em cada corrida, ele somará os dois números definidos nas duas primeiras colunas e verificará se a soma desses dois números corresponde ao número presente na terceira coluna.

Existem várias vantagens desta estrutura. Todos os valores são armazenados fora do script, portanto, se ocorrer alguma alteração na próxima construção, basta alterar os dados do arquivo externo e o script permanecerá intacto.

A segunda vantagem é que o mesmo script pode ser executado para entradas diferentes. Veja o exemplo de um ERP em que você tem que testar o cadastro de 100 funcionários. Você pode escrever um script e armazenar os nomes e outros dados relacionados aos funcionários em um arquivo externo. Você executará um script e ele será executado 100 vezes. Cada vez com dados de funcionários diferentes. Você pode detectar facilmente em quais dados o script não consegue registrar o funcionário. Será uma vantagem adicional quando você estiver fazendo um teste negativo.

=> Veja aqui o exemplo de estrutura baseada em dados e híbrida com exemplo de QTP.

# 4. Estrutura baseada em palavras-chave:

Características:

  • Tanto os dados quanto as ações são definidos fora do script.
  • Exigiu o desenvolvimento de palavras-chave para diferentes tipos de ações.
  • A funcionalidade que temos que testar é escrita passo a passo em forma tabular usando as palavras-chave que desenvolvemos e os dados de teste. Armazenamos esta tabela em arquivos externos, assim como a estrutura orientada a dados.
  • O script analisará essa tabela e executará as ações correspondentes.
  • Permite que o testador manual que não sabe sobre codificação faça parte da automação até certo ponto.

Exemplo D:

Definimos os dados (por exemplo, 1 + 3 = 4), bem como as ações (por exemplo, clicar, limpar etc.) em um arquivo Excel em formato tabular.

Exemplo de estrutura baseada em palavras-chave

O script se tornará algo assim (o código abaixo foi escrito apenas para fins de compreensão)

(TestMethod) public void TestCalculator() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); Table tb = ReadFromExcel(); Foreach(WinRow row in tb) { WinCell Window = row.Cells(“Window”); WinCell Control = row.Cells(“Control”); WinCell Action = row.Cells(“Action”); WinCell Arguments = row.Cells(“Arguments”); UITestControl c = GetControl(Control.Text,Window.Text); If(Action.Text == “Click”) Mouse.Click (c); If (Action.Text == “Clear”) c.Clear(); if(Action.Text == “Verify Result”) Assert.AreEqual(c.Text, Arguments.Text) //….and so on } }

O script acima é apenas um analisador do arquivo excel. Ele analisa o arquivo do Excel linha por linha e procura palavras-chave para executar as respectivas ações. Se encontrar a palavra-chave “Click”, irá clicar no objeto definido. Se encontrar “Verificar Resultado”, ele executará a asserção.

Existem várias vantagens de usar a estrutura orientada por palavras-chave.

A primeira vantagem é que essa estrutura é muito útil nos cenários em que há grandes chances de mudanças nos casos de teste. Se alguma etapa for alterada em um caso de teste, não precisamos tocar no código. Só precisamos atualizar o arquivo excel e o script será atualizado.

Você pode definir todos os seus scripts em um arquivo do Excel e entregar esse arquivo do Excel aos testadores manuais para adicionar novos scripts ou atualizar os existentes. Dessa forma, os testadores manuais também podem se tornar parte da automação de teste porque não precisam codificar nada. Eles irão apenas atualizar este arquivo excel quando houver necessidade e os scripts serão atualizados automaticamente.

A segunda vantagem é que seu script se torna independente de ferramenta. Você pode manter seus scripts em um arquivo do Excel e se precisar alterar sua ferramenta de automação em algum ponto, você pode alterá-la facilmente escrevendo um analisador do Excel em outra ferramenta.

A desvantagem dessa estrutura é que você precisa inventar palavras-chave para vários tipos de ações. Em projetos de grande escala, haverá tantas palavras-chave que você precisa lembrar e organizar seus scripts e palavras-chave. Isso em si se torna uma tarefa complicada em um ponto.

Em alguns cenários complexos, onde os objetos não podem ser facilmente identificados e precisamos usar as coordenadas do mouse e outras técnicas, esta estrutura não é muito útil.

Orientado por palavras-chave ainda é uma estrutura favorita para muitos testadores de automação. Estrutura do robô do Google é uma estrutura popular baseada em palavras-chave que é apoiada por uma comunidade ativa.

# 5. Estrutura de automação de teste híbrido:

Características:

  • A combinação de duas ou mais das técnicas acima, tirando de seus pontos fortes e minimizando seus pontos fracos.
  • A estrutura pode usar a abordagem modular junto com uma estrutura baseada em dados ou baseada em palavras-chave.
  • A estrutura pode usar scripts para executar algumas tarefas que podem ser muito difíceis de implementar em uma abordagem baseada em palavras-chave puras.

Em palavras simples, estrutura híbrida, use a combinação das técnicas acima mencionadas. Podemos usar uma estrutura baseada em dados que também é modular por natureza. Para alguns casos de teste, podemos usar a abordagem baseada em palavras-chave e, para o restante, podemos usar o modular. Portanto, sempre que combinamos duas ou mais técnicas mencionadas neste artigo, estamos na verdade usando uma abordagem híbrida.

tipos de casos de teste em teste de software

Conclusão

Espero que essa estrutura de automação de teste não seja mais um termo assustador para você agora. Tentei explicar as estruturas mais populares da forma mais simples possível.

Os frameworks estão aqui para tornar sua vida mais fácil. Eles o ajudam a escrever scripts confiáveis ​​e sustentáveis. Sem usar frameworks, o campo de automação de teste é um pesadelo. Para cada pequena mudança no aplicativo, você deve alterar seu código em centenas de lugares.

Portanto, a compreensão dessas estruturas é essencial para todos os testadores que desejam experimentar a automação de testes.

Na nossa próximo tutorial nesta série, aprenderemos 'Execução e relatórios de automação de teste'.

Se eu perdi alguma coisa neste artigo ou você precisa fazer alguma pergunta, sinta-se à vontade para perguntar na seção de comentários.

PREV Tutorial # 4 | PRÓXIMO Tutorial # 6

Leitura recomendada

^