Grandes aprendizados vêm a partir de grandes desafios….
Recentemente recebi um grande desafio, de implementar uma automação de testes de uma aplicação desktop, sem utilizar o Sikuli. O Sikuli é uma ferramenta bastante conhecida para automação de aplicações desktop, porém é baseada em reconhecimentos de imagens para realização das ações. Para quem tiver interesse em conhecer mais do Sikuli, segue o link da documentação. Quem sabe futuramente eu traga um artigo sobre o Sikuli :D
Mas a diretriz inicial foi não usar o Sikuli… Então vamos cair em campo para procurar opções.
De imediato escolhi o RobotFramework como framework de automação principal para o aplicativo. Robot Framework é uma estrutura de automação genérica de código aberto. Pode ser usado para automação de teste e automação de processos robóticos.
A escolha do RobotFramework se deu por algumas características primordiais para um framework de automação. Primeiro que é um framework opensource e com uma comunidade bastante ativa, o que facilita na atualização do framework como também em fóruns e discussões para resoluções de dúvidas e questionamento. Segundo ponto importante do RobotFramework é a escrita dos testes, Robot Framework tem sintaxe fácil, utilizando palavras-chave legíveis de fácil leitura e entendimento do comportamento dos testes, podendo até ser utilizado como documentação do comportamento da aplicação. E por fim tem uma rica biblioteca de funções, que possibilitam criar testes de aplicações GUI, Mobile, Web, APIs e Desktop.
E nos estudos das bibliotecas do RobotFramework encontrei o ZOOMBA. Desenvolvida e mantida pela Accruent, o Zoomba é uma coleção de bibliotecas que abrangem automação de GUI, API REST, API SOAP, Mobile e Windows Desktop (WinAppDriver) usando Robot Framework. Essas bibliotecas são extensões das bibliotecas existentes SeleniumLibrary, Requests, SudsLibrary e AppiumLibrary.
Já vimos que o Zoomba dá suporte a testes de Windows Desktop e isso nos interessa bastante. Então vamos entender como essa biblioteca funciona e vamos rodar ao menos um exemplo prático.
Para os testes de Windows Desktop o Zoomba utiliza a biblioteca DesktopLibrary. E biblioteza usa como base a AppiumLibrary para personalizar a automação dos testes das aplicações Desktop. A AppiumLibrary é uma biblioteca para testes mobile, mas o Zoomba utilizou as keywords base da AppiumLibrary como Open Application ou Click Element para melhor desempenho nas janelas da app.
Mas antes de iniciarmos os exemplos do nossos testeswindows desktop, temos que fazer algumas configurações no sistema operacional para que nossos testes funcionem.
Primeiro temos que garantir que temos instalado o WinAppDriver (abreviação de Windows Application Driver). O WinAppDriver é um serviço para dar suporte à automação de teste de interface do usuário, semelhante ao Selenium, só que em aplicativos do Windows.
A instalação do WinAppDriver é simples, basta seguir os seguintes passos:
- 1 – Iremos acessar o Github e baixar a versão mais atualizada do Windows Application Driver.
- 2 – Após realizar o download basta executar e instalar, de preferência em uma máquina com Windows 10, onde será criada e executadas as suites de testes.
- 3 – Habilitar o Modo Desenvolvedor nas configurações do Windows; (Vide explicação abaixo).
- 4 – Abra uma janela do terminal e execute o arquivo WinAppDriver.exe que deve estar na pasta do WinAppDriver que foi criada durante a instalação. Provavelmente deverá estar em C:\Program Files (x86)\Windows Application Driver.
Após esses passos teremos o Windows Application Driver executando na máquina e escutando as requisições para o endereço IP e porta (127.0.0.1:4723). Logo esse ip e porta, será a URLRemote que iremos configurar para abrir a aplicação windows desktop.
No passo 3, vimos que temos que habilitar o Modo Desenvolvedor do windows. Para quem ainda não tem conhecimento, vamos ver como configuramos no Windows.
Então aqui vai um passo a passo de como ativar o modo desenvolvedor do Windows 10.
1. Abra o menu iniciar
2. Escolha a opção “Configurações”
3. Selecione a opção Atualização e Segurança
5. Clique sobre a chave de Modo Desenvolvedor
Com isso finalizamos a configuração do Modo Desenvolvedor no seu Windows 10. Agora precisaremos de mais uma ferramenta do Windows que irá nos ajudar bastante no mapeamento dos componentes do app, estou falando do Inspecione.
Inspecione é uma ferramenta baseada no Windows que permite que você selecione qualquer elemento de interface do usuário e exiba os dados de acessibilidade do elemento. Você pode exibir propriedades de automação da interface do usuário da Microsoft e padrões de control. Inspecionar também permite testar a estrutura de navegação dos elementos de automação na árvore de automação da interface do usuário e os objetos acessíveis na hierarquia do Microsoft acessibilidade ativa.
O inspecionar é instalado com o SDK (Software Development Kit) do Windows e está localizado na \ pasta bin \ < version > \ < > do caminho de instalação do SDK (Inspect.exe). No meu caso o caminho path do Inspecione ficou, C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\Inspect.exe.
Caso você não tenha ainda o SDK do Windows instalado, pode baixar no link https://developer.microsoft.com/en-us/windows/downloads/sdk-archive/ e seguir os passos para instalação.
Ao executar o Inspect.exe a aplicação irá abrir e automaticamente reconhecer os elementos das aplicações que estiverem aberta no windows, com isso você irá escolher a aplicação de foco e sim pode inspecionar os dados dos elementos, o Inspecione é bem similar ao Appium Desktop para quem está acostumado com automação mobile.
Quando você começa a inspeção, a exibição de árvore mostra o local do elemento de interface do usuário selecionado no momento na hierarquia do elemento e a exibição de dados mostra as informações de Propriedade do elemento da interface do usuário selecionado. Por padrão, inspecione rastreia o foco do teclado ou do mouse. Conforme as alterações de foco, a exibição de dados é atualizada com as informações de Propriedade do elemento com foco.
Como vimos na figura acima, ao selecionar qualquer elemento na árvore de visualização, as propriedades do elemento são exibidas na área de DataView, essas informações serão importantes no momento que iremos mapear, nos nossos testes, os elementos nas quais iremos realizar as ações de automação.
Para maiores informações ou esclarecimentos sobre como funciona ou como configurar o Inspecione, podem acessar a página de documentação do WIndows, ai você encontrar uma gama de informações que poderá lhe ajudar.
Agora vamos para o momento mais esperado desse artigo, como iremos automatizar nossos testes para aplicações Windows desktop com o Zoomba Library e o RobotFrameworl.
Inicialmente iremos considerar que você já tenha o RobotFramework já instalado em sua estação de trabalho, logo precisaremos instalar o Zoomba e isso é muito fácil. Em seu terminal digite o comando pipinstallrobotframework-zoomba
Eu estou utilizando o VsCode como IDE para desenvolvimento dos testes automatizados, é uma IDE bastante interessante, principalmente pela quantidade de plugins disponíveis para auxiliar no dia a dia. Mas fica a critério de qualquer um a IDE para criação dos testes, inclusive qualquer editor de texto poderá ser utilizado.
Primeiramente vamos criar o nosso arquivo de teste robot, que irei chamar de zoombaCalculator.robot, pois iremos utilizar a aplicação da Calculadora nativa do Windows como aplicação para testes.
Lembrando que não iremos nos aprofundar nas do RobotFramework, nosso foco é explicar a escrita das keywords, configurações e testes do zoomba, no arquivo .robot .
Para ter acesso as Keywords da biblioteca Zoomba, basta configurar o settings do nosso arquivo .robot com a importação das bibliotecas específica e/ou necessárias para o tipo de teste que irá realizar,
*** Settings ***
Library Zoomba.APILibrary
Library Zoomba.GUILibrary
Library Zoomba.SOAPLibrary
Library Zoomba.MobileLibrary
Library Zoomba.DesktopLi
Para iniciar e parar uma aplicação Windows Desktop, usaremos o recurso do RobotFramework (Setup/Teardown), onde no Setup iremos iniciar aplicação para cada teste executado (garantindo que a aplicação estará no seu estado inicial) chamando as keyword Driver Setup ouLaunchApplication. Já no Teardown iremos fechar a aplicação (para garantir que o estado da aplicação não afete o próximo teste), podendo utilizar as keywordsQuitApplication, Driver Teardownou Close AllApplication.
*** Settings ***
Documentation Zoomba Desktop Library Tests.
Library Zoomba.DesktopLibrary
Suite Setup Start App
Test Setup Launch Application
Test Teardown Quit Application
Suite Teardown Driver Teardown
Force Tags Windows
Para conhecer mais sobre como se comportar as keywords utilizadas no Setup e TearDown consulte a documentação da DesktopLibrary do Zoomba.
Nosso próximo passo é agora configurar a nossa aplicação.
Para isso iremos criar duas váriavéis, que ficará na sessão de Variables do nosso arquivo de teste robot, onde iremos definir a variável de REMOTE_URL e a APP. A REMOTE_APP será o caminho no qual iremos associar ao WinAppDriver (que executamos anteriormente e deixamos executando) e como vimos acima, o WinAppDriver fica escutando a url http://127.0.0.1:4723, e será justamente essa url que iremos alimentar nossa variável. Na variável APP iremos colocar ou o AppID da aplicação Windows ou colocamos o path do caminho até o arquivo executável da aplicação desktop. Para nosso exemplo iremos utilizar a aplicação nativa do Windows a Calculadora, logo a sua AppID é Microsoft.WindowsCalculator_8wekyb3d8bbwe!App.NO ssa sessão Variable então ficará assim:
*** Variables ***
${REMOTE_URL} http://127.0.0.1:4723
${APP} Microsoft.WindowsCalculator_8wekyb3d8bbwe!App
Mas se eu quiser utilizar o AppID de uma outra aplicação nativa do Windows ou qualquer outra aplicação Desktop, como eu faço para saber o AppID? Não se preocupe, irei demonstrar como é fácil descobrir o AppId da aplicação Windows.
Primeiro passo é abrir o terminal “PowerShell”, para tanto basta clicar no botão iniciar e digitar “PowerShell” e abrir a aplicação.
Uma vez aberta basta copiar e executar esse o comando abaixo e ver a mágica acontecer.
get-StartApps | Where-Object {$_.Name -like '*Application Name*'}
Onde o ‘Aplication Name’ é o nome da aplicação Windows, que deverá se diferenciar conforme a lingua padrão do seu sistema operacional. Exemplo se seu windows estiver em inglês você usará o comando com o ‘Aplication Name’ em inglês get-StartApps | Where-Object {$_.Name –like ‘*Calculator*’}, caso o seu windows estiver em português o ‘Aplication Name’ deverá ser preenchido com o nome da aplicação em português
get-StartApps | Where-Object {$_.Name -like ‘*Calculadora*’}
Já configuramos as bibliotecas do Zoomba, como também os Setup e Teardown na sessão de Settings, como também já adicionamos as variáveis de configuração da app na sessão Variables, mas antes de iniciar os nossos testes temos que realizar apenas mais uma configuração.
Na Suite Setup aplicamos uma keyword Setup App, essa keyword foi criada na sessão Keywords e ela é responsável pela configuração e para abrir a aplicação Windows e ativando o WinAppDriver. Vamos dar uma olhadinha nessa keyword.
*** Variables ***
${REMOTE_URL} http://127.0.0.1:4723
${APP} Microsoft.WindowsCalculator_8wekyb3d8bbwe!App
*** Keywords ***
Start App
[Documentation] Sets up the application for quick launching through 'Launch Application' and starts the winappdriver
Driver Setup
Open Application ${REMOTE_URL} platformName=Windows deviceName=Windows app=${APP}
Maximize Window
Quit Application
A Keyword Start App utiliza 4 outras keywords da biblioteca DesktopLibrary, porém vamos nos atentar a mais importante a Open Application. Lendo a documentação dessa keyword verificamos que ela necessita de ao menos 4 argumentos para conseguir abrir a aplicação que iremos testar, informando a url que será utilizada pela WinAppDriver e o AppId, que vimos anteriormente como identificar. Os argumentos de platformName e deviceName terá como valor padrão Windows.
Open Application ${REMOTE_URL} platformName=Windows deviceName=Windows app=${APP}
As demais keywords utilizadas pelas Start App são para lançar e maximizar a aplicação após aberta.
Feita toda a configuração necessária vamos agora ver a robot trabalhar… vamos criar o nosso primeiro caso de teste e testar se nossa configuração estará correta.
Então vamos na DesktopLibrary e vamos observar as keyworks interessantes que podemos usar na automação dos nossos testes. Uma keyword interessante de se analisar é a Wait For And Click Element, ela espera que um elemento esteja disponível na tela e após isso clicará nesse elemento, o elemento é mapeado e identificado pelo seu locator.
Todas as palavras-chave na DesktopLibrary que precisam localizar um elemento na página usam um argumento localizador. É nesse momento que usaremos o Inspecione, essa ferramenta será importante para identificar o locator do elemento a se manipular, onde teremos várias informações disponíveis por elemento, então abaixo segue uma tabela que mostra a estratégia do localizador que você deve usar para encontrar os elementos com os atributos correspondentes.
Voltando para o testes vamos utilizar a keyword Wait For And Click Element, onde iremos esperar e clicar no botão 2 da calculadora, então vamos abrir o Inspect.exe para que possamos conseguimos identificar os parametros de locator do botão 2. Então seguindo a tabela acima vimos que temos o accessibility_id é o AutomatinId que é o valor “num2Button”, o name temos o valor “Dois, e class (que no inspecione é o ClassName) o valor “Button”. Diante desses valores a melhor estratégia é utilizar o AutomartionId.
Então nossa keyword ficará assim:
Wait For And Click Element accessibility_id=num2Button
Para finalizar nosso primeiro teste, vamos validar que após clicar no botão 2 o valor “2” estará visível no campo de resultado da calculadora. Para tal iremos utiliza a keyword Wait Until Element Contains que irá esperar até que o elemento mapeado pelo locato, apareça na tela. Uma observação interessante, que o DesktopLibrary por padrão tem um timeout de 10 segundos, logo essa keyword irá aguardar pelo elemento por até 10 segundos.
Seguindo a mesma premissa anterior a keyword ficará assim:
Wait Until Element Contains accessibility_id=CalculatorResults 2
O nosso teste, que chamei de Esperar E Clicar No Botão Dois, terá apenas as duas keywords acima analisada, logo temos como primeiro teste.
*** Test Cases ***
Esperar E Clicar No Botão Dois
Wait For And Click Element accessibility_id=num2Button
Wait Until Element Contains accessibility_id=CalculatorResults 2
Nosso arquivo .robot ficou assim:
Agora já podemos rodar nosso teste e verificar se está tudo dando certo até o momento.
Para rodar o teste em RobotFramework, no terminal rodamos o comando:
>> robot zoombaCalculator.robot
Verificamos que os testes rodaram com sucesso.
Para finalizar vamos criar alguns testes para mapear os outros tipos de locator. No teste anterior utilizamos o accessibility_id, então vamos criar mais dois testes com locator de ClassName, xpath e Name.
Seguindo os mesmos passos para criação do teste anterior, vamos abrir novamente a calculadora e o Inpect.exe, escolher os botões que serão pressionados e inspecionar cada elemento e capturar as informações. Logo os novos testes ficaram assim:
Esperar E Clicar no Botao Quatro Via XPath
Wait For And Click Element xpath=//Button[@Name="Quatro"]
Wait Until Element Contains accessibility_id=CalculatorResults 4
Esperar E Clicar no Botao Cinco Via Name
Wait For And Click Element name=Cinco
Wait Until Element Contains accessibility_id=CalculatorResults 5
Esperar E Clicar no Botao Seis Via ClassName
Wait For And Click Element class=Button
Agora é reexecutar e validar os resultados.
Todos os testes passaram. Agora é soltar a criatividade e implementar mais testes com os diversos keywords da DesktopLibrary.
Espero que tenham gostado e que possa ser de utilidade para vocês.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?