Utilizando Appium e TestNG como Alternativa para Execução em Paralelo de Testes Mobile
No mundo Mobile…
Os dispositivos móveis em conjunto com os aplicativos, trouxeram uma série de facilidades para os seus usuários. Hoje temos acesso a um computador poderoso em nossas mãos e cabe a nós usufruir da melhor maneira possível. Porém, quem trabalha desenvolvendo estes aplicativos móveis, se depara com alguns obstáculos durante a jornada de concepção, desenvolvimento e entrega das aplicações. Palavras como multiplataforma, plataforma, modelo, versão, híbrido, nativo e etc., se tornaram corriqueiras no mundo mobile e precisamos pensar em estratégias para lidar com elas.
Paralelismo de Testes
O conceito de paralelismo de testes, nos auxilia a enfrentar alguns obstáculos mas precisamos entender um pouco sobre o que se trata. Em teste de software, quando falamos em paralelismo, é sobre a capacidade de executar dois ou mais testes concorrentes em diferentes condições como: Plataformas, Modelos, Sistemas Operacionais, Versões, etc. É possível adotar a estratégia de executar o mesmo teste em n condições como também existe a possibilidade de executar testes diferentes em n condições. Isso irá depender do seu objetivo: Para o primeiro caso, verificar a portabilidade do mesmo cenário entre plataformas, modelos, sistemas operacionais… e no segundo caso dar vazão para os testes e diminuir o tempo de execução.
Solução para Execução em Paralelo
Quem trabalha com mobile, durante o desenvolvimento dos seus scripts automatizados, já deve ter se deparado com uma arquitetura para suporte a paralelismo semelhante a da imagem abaixo:
Como cliente temos a tecnologia Java, TestNG como framework de testes e java-client como implementação do cliente necessário para comunicação com o Appium Server. O Selenium Grid, que permite orquestrar a execução dos testes em paralelo, funciona como um hub, sendo necessário realizar uma configuração de “nós” que no contexto mobile, serão as instâncias dos Appium Servers e dos dispositivos capacitados a executar os testes.
É possível perceber, nesta arquitetura, alguns pontos de atenção importantes:
- Para execução em cada dispositivo é preciso configurar um “nó” com uma instância do Appium Server, exigindo maior capacidade de hardware para suportar todas estas API’s e também dificultando a manutenção.
- O serviço do Selenium Grid precisa ser agregado na arquitetura do projeto, pois é o responsável por orquestrar as execuções, incluindo mais uma camada de abstração e aumentando também a complexidade de manutenção do projeto.
- É necessário criar arquivos de configuração responsáveis por disponibilizar os serviços do Selenium Grid e posteriormente registrar cada nó no hub, dificultando a escalabilidade do projeto.
Esta arquitetura é funcional, porém precisamos levar em consideração os pontos acima levantados no momento de definição da nossa estratégia de automação. Outras alternativas podem ser analisadas e se forem passíveis de resolver o nosso problema, podemos optar por esta alternativa.
Uma outra abordagem!
A versão 1.7.0 do Appium trouxe uma forma simplificada de trabalhar com múltiplas sessões simultâneas durante a execução de testes e pode ser utilizada em conjunto com o TestNG como uma alternativa para execução em paralelo.
Para auxiliar no apoio a configuração de ambiente, sugiro a leitura do artigo sobre Configuração das Variáveis de Ambiente.
,
Como cliente temos Java, TestNG e o java-client. O TestNG em conjunto com o java-client permite criar uma estrutura capaz de iniciar mais de uma sessão em uma única instância do Appium Server, as seguintes configurações se tornam necessárias:
- name=”Smoke Tests”, é o nome dado a suíte de testes, geralmente representa o tipo de execução, funcionalidade ou um grupo de funcionalidades.
- parallel=”tests”, informa ao TestNG que a execução é paralela para todos os métodos que estão na tag <test>.
- thread-count=”3”, específica a quantidade de threads que podem ser alocadas para a execução. Lembrando que todos os métodos de uma tag <test> são executados em uma thread, mas cada tag <test> estará em um thread separado.
- name=”Google Pixel 2 – 8.0", nome da execução para a tag <test>, neste caso está representando que as execuções desta tag são em um dispositivo da Google.
- name=”deviceName” value=”Google Pixel 2–8.0", nome do dispositivo que será registrado na sessão Appium. (parâmetro obrigatório)
- name=”udid” value=”192.168.243.101:5555”, informação de id único do dispositivo em que será executado o(s) teste(s), pode ser obtido através do comando adb devices, no caso do Android ou idevice_id — list, no caso do iOS.
- name=”systemPort” value=”8200”, parâmetro chave para registro de múltiplas sessões em uma única instância do Appium Server. No caso do Android este parâmetro é o systemPort e no caso do iOS é o wdaPort.
Estes parâmetros informados através do .xml que contempla a suíte de testes, são passados através do TestBase para a classe responsável por montar o objeto da sessão Appium.
public class TestBase {@BeforeClass
@Parameters({"deviceName", "udid", "systemPort"})
public void setUp(String deviceName, String udid, int systemPort)
throws Exception {driver = device.getAndroidDriverSession(deviceName, udid, systemPort, appiumServerUrl);
}
}public class AppiumSessionConfig {public AndroidDriver<MobileElement> getAndroidDriverSession
(String deviceName, String udid, int systemPort)
throws MalformedURLException {DesiredCapabilities capabilities = new DesiredCapabilities();capabilities.setCapability("deviceName", deviceName);
capabilities.setCapability("udid", udid);
capabilities.setCapability("platformName", "Android");
capabilities.setCapability("systemPort", systemPort);
capabilities.setCapability("appPackage", "br.com.lucasbieniek.aat");
capabilities.setCapability("appActivity", "br.com.lucasbieniek.aat.views.MainActivity");return new AndroidDriver<>(new URL("http://127.0.0.1:4723/wd/hub"), capabilities);
}
}
A sessão Appium é montada com base nos parâmetros passados direcionando as chamadas do cliente para um Appium Server localhost na porta 4723. A mesma dinâmica é realizada para as demais execuções, basta informar os parâmetros de execução nas tags <test> do arquivo .xml e alocar a quantidade de threads necessárias para a execução.
Feito isso, o Appium Server fica responsabilizado por orquestrar todas as sessões enviadas pelo cliente, de forma em que seja possível executar os testes em paralelo.
É possível potencializar está arquitetura de execução em paralelo, criando uma farm local com um hub usb alimentado para os dispositivos, utilizar um Mac Mini com todas as ferramentas necessárias configuradas para execução no iOS, criar uma rede dedicada aos dispositivos conectados no farm, para evitar problemas de conexão com a internet. Enfim, são diversas possibilidades… A ideia é trazer mais uma alternativa para a criação da sua arquitetura de testes mobile, fica o espaço para discussão e pensar na solução ideal para o nosso problema.
O código para este exemplo está disponível neste projeto no github e outras informações importantes podem ser obtidas na documentação oficial do Appium.
Obrigado e bom teste! ;)
Contribuições:
Referências:
