Articles

Como Integrar Jenkins & Maven com Selenium?

On Setembro 23, 2021 by

Este artigo faz parte do nosso Hub de Conteúdo. Para recursos mais aprofundados, confira nosso hub de conteúdo no Jenkins Tutorial.

Jenkins é uma das ferramentas populares para integração contínua, gerenciamento de construção e testes de automação. Maven é uma ferramenta popular de automação de construção que é amplamente utilizada para projetos Java. A combinação de integração Selenium, Maven, Jenkins é o auge da integração e implantação contínuas.

Como parte dos testes de automação, temos certeza que a sua equipe vem com inúmeros scripts de automação de testes Selenium dia sim, dia não. Como Selenium em si não é usado para integração contínua, a integração Selenium, Maven e Jenkins são alavancadas para o gerenciamento de construção e integração contínua. Neste artigo, nós analisamos o uso de Maven e Jenkins com Selenium.

Um resumo rápido do post do blog está abaixo:

Overvisão geral do Selenium, Maven, & Jenkins

Maven é uma ferramenta popular de automação de construção que é usada principalmente para projetos Java. A vantagem de usar Maven é que as bibliotecas e plugins Java são baixados de forma dinâmica do Maven 2 Central Repository.

As dependências e outras informações essenciais relacionadas à construção são armazenadas em um arquivo pom.xml do projeto. Uma vez baixadas, as dependências são armazenadas em um cache local (.M2 repositório), e o mesmo é usado para geração de build. Isto simplifica o processo de compilação, já que qualquer nova dependência do projeto tem que ser adicionada apenas no pom.xml, ou seja, não são necessários downloads manuais e pacotes de instalação.

Selenium é um framework de automação de testes amplamente utilizado para validar aplicações web através de diferentes combinações de navegadores, plataformas e dispositivos (ou emuladores). Você pode consultar nossos blogs sobre como o Selenium Grid pode ser usado para testes automatizados de navegadores.

Jenkins é uma ferramenta CI/CD de código aberto que ajuda na automação de atividades relacionadas à construção, teste e implantação. Jenkins tem um amplo ecossistema de plugins, é de código aberto e uma comunidade apaixonada – fatores que podem ser atribuídos às características de Jenkins.

Neste blog Maven e Jenkins com Selenium, estaríamos usando TestNG, que é uma estrutura de teste popular que é inspirada no JUnit. Ele é amplamente usado para áreas de teste como testes funcionais, testes de ponta a ponta, e muito mais.

Estes são o conjunto de ferramentas que estaríamos usando na demonstração:

  • Maven – Ferramenta de gerenciamento de projetos em Java
  • TestNG – Quadro popular de automação de testes
  • Selenium WebDriver – Biblioteca usada principalmente para automação das interações do navegador
  • Jenkins – Ferramenta para Integração Contínua (CI) e Implantação Contínua (CD)

Aqui está o fluxo geral de informações quando Selenium, Maven, e Jenkins estão integrados:

  • Após o desenvolvedor empurrar o código para o repositório (e.g., GitHub), uma compilação Jenkins é acionada.
  • Maven baixa as bibliotecas dependentes & pacotes e começa a executar a compilação. A informação relacionada ao conjunto de testes está disponível em testing.xml, e a mesma também é usada em pom.xml.
  • Um objetivo de compilação (por exemplo, instalar) para executar os testes automatizados está definido. O mesmo é alcançado através do maven-surefire-plugin.
  • O maven-surefire-plugin diz ao TestNG para executar os testes que estão sob a anotação @Test.
  • Dependente do AUT (aplicativo em teste) e do navegador (& Combinação de SO) no qual os testes cross browser são executados, o Selenium WebDriver invoca a instância do navegador correspondente e executa os mesmos testes de automação.
  • Os resultados dos testes são publicados em Relatórios HTML, já que o plugin HTML Publisher é usado para geração de relatórios.
  • Even se um único caso de teste falhou, o teste completo é marcado com o status ‘Failed’.

Vantagens do uso de Maven & Jenkins com Selenium

Antes de demonstrarmos o uso da integração de Selenium Maven Jenkins, vamos dar uma olhada nas principais vantagens do uso de Maven e Jenkins com Selenium:

  • Quando uma alteração é feita na implementação, as alterações são implantadas no ambiente de teste. Os testes de automação são realizados continuamente, e os desenvolvedores são mantidos informados sobre os resultados da fase de construção e teste.
  • Suítes de teste que compreendem muitos cenários de teste (ou combinações de teste) podem levar mais tempo para testes de automação. Uma execução noturna de compilação pode ser programada para compilação e execução no servidor Jenkins em tais casos.
  • Como a Maven usa pom.xml, ela reduz a dependência geral do download manual de arquivos jar. Além disso, o tipo ‘Maven Project’ em Jenkins ajuda a começar com Selenium Maven, integração Jenkins com algumas configurações.
  • A configuração de integração Selenium Maven Jenkins é adequada para equipes de desenvolvimento e teste distribuídas em diferentes localizações geográficas.

Prerequisites For Jenkins Selenium Project

For demonstration of Maven and Jenkins with Selenium, the following softwares should be installed (or available) on the machine from where tests are triggered:

  • Eclipse IDE ou IntelliJ IDEA (Maven vem por padrão em ambas IDEs)
  • Jenkins in .war format
  • Configuração do Chrome WebDriver com a versão do navegador Chrome na sua máquina
  • Perfil Microsoft Edge Driver
  • Configuração no LambdaTest (como os testes são executados na grade de selênio baseada na nuvem do LambdaTest)

Demonstrando a integração do Selenium Maven Jenkins

Para fins de economia de tempo, não olharíamos para cada passo da criação de um Projeto Maven. Caso você queira uma rápida recapitulação da Maven com Selenium, você pode consultar este tutorial da Maven para automação de testes Selenium. Os passos usados para criar um projeto Maven no IDEA IntelliJ são similares aos usados na criação de um projeto Maven no IDEA Eclipse.

Test Suite – 1

Test Scenario – 1 (Chrome no Windows 10)

  1. Navigate para esta URL- https://lambdatest.github.io/sample-todo-app/.
  2. Selecionar as duas primeiras caixas de seleção.
  3. Entrar ‘Happy Testing at LambdaTest’ na caixa de texto abaixo com a seguinte id = sampletodotext.
  4. Agora, clique no botão Adicionar e verifique se o texto foi adicionado ou não.

Cenário de teste – 2 (Testes em 4 combinações de browser e SO diferentes)

  1. Navegue para esta URL- https://www.google.com.
  2. Procure por “LambdaTest”.
  3. Clique no primeiro resultado do teste.
  4. Agora, levante um Assert se o título da página não corresponder ao título esperado.

Implementação

As dependências e plugins apropriados têm de ser adicionados no pom.xml do projecto. Aqui estão os pacotes chave (ou frascos) que fazem parte do pom.xml:

  • Selenium 4 (Alpha)
  • TestNG framework (versão 6.9.10)
  • Maven Surefire plugin para execução da suite de testes que faz parte do testng.xml
  • Plugin Maven Surefire Report para gerar o relatório de resultados do teste em formato HTML

Se você pretende adicionar qualquer novo plugin ou jarro ao pom acima.xml, procure o mesmo no Maven Repository e adicione a dependência/plugin correspondente na seção relevante.

A suíte de testes contém dois casos de teste, a saber test_Selenium4_ToDoApp() & test_Selenium4_GoogleSearch(). Como mostrado abaixo, a implementação destes casos de teste é armazenada em arquivos separados, nomeadamente CrossBrowserTest.java e GoogleSearchTest.java, e ambos são parte do pacote org.selénio4.

O cenário de teste test_Selenium4_ToDoApp() destina-se a ser executado no Chrome (Última versão) para o Windows 10. Por outro lado, o cenário de teste test_Selenium4_GoogleSearch() tem que ser executado em 4 combinações diferentes de navegador e SO i.e. Chrome (mais recente) no Windows 10, Edge (84.0) no Windows 10, Chrome (mais recente) no MacOS Mojave, e Firefox (mais recente) no OS X Mavericks.

As entradas em testng.xml para test_Selenium4_GoogleSearch() foram alinhadas de acordo com as capacidades do navegador geradas pelo gerador de capacidades LambdaTest. Abaixo estão os exemplos de capacidades geradas para o Chrome (mais recente) & Combinação Windows 10:

Na implementação, usaríamos os ouvintes do TestNG em Selenium WebDriver para testes de automação. No nível da suite, nós definimos nomes de classes para implementar ouvintes no arquivo TestNG xml. A anotação @listeners no TestNG é usada para adicionar a classe org.selenium4.GoogleSearchTest.

Como mostrado abaixo, o nome do teste ‘Google Search Test – 1’ terá parâmetros de entrada que especificam o navegador, a versão, a plataforma e a resolução de exibição. Estes valores seriam passados para o método de teste como argumentos usando anotações parametrizadas (i.e. @org.testng.annotations.Parameters(value={“browser”, “version”, “platform”, “resolution”}).

1
2
3
4
5
6
7
8
9
10
11
12
13
< ouvintes>
< classe ouvinte-name=”org.selenium4.GoogleSearchTest”/>
</listeners>
<test name=”Google Search Test – 1″>
<parametro name=”browser” value=”Chrome”/>
<parametro name=”version” value=”latest”/>
<parametro name=”platform” value=”Windows 10″/>
<parameter name=”resolution” value=”1600×1200″/>
<classes>
<class name=”org.selenium4.GoogleSearchTest”/>
</classes>
</testado>

CrossBrowserTest.java (Implementação do Cenário de Testes – 1)

GoogleSearchTest.java (Implementação do Cenário de Testes – 2)

Código Walkthrough

Passo 1 – Os pacotes necessários são importados antes do início da implementação propriamente dita. Como a estrutura TestNG é usada para testes; portanto, seus pacotes também são importados antes que suas anotações possam ser usadas.

1
2
3
4
5
org de importação.testng.annotations.AfterClass;
importar org.testng.annotations.BeforeClass;
importar org.testng.annotations.Test;
importar org.junit.org estático.Assert.*;
importar org.junit.Test.*;

Passo 2 – O IExecutionListener é usado para monitorar o início e fim da suíte de testes, pois o cenário de teste seria executado em diferentes combinações de entrada que são passadas através do arquivo TestNG xml.

O IExecutionListener contém dois métodos – onExecutionStart() e onExecutionFinish(). onExecutionStart() é invocado antes do início do teste e onExecutionFinish() é invocado uma vez que as suítes de testes/tes de teste tenham terminado a execução.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
classe pública GoogleSearchTest implementos IExecutionListener {
/* driver estático protegido EdgeDriver; */
String URL = “https://www.google.com/”;
…………………………..
…………………………..
…………………………..
@Override
vazio público onExecutionStart() {
System.out.println(“onExecutionStart”);
}

>

@Override
vazio público onExecutionFinish() {
System.out.println(“onExecutionFinish”);
}

Passo 3 – O método implementado sob @BeforeTest annotation será executado antes que qualquer método de teste pertencente à classe sob essa tag seja executado. Como estamos usando testes parametrizados com TestNG, a anotação @Parameters(value={“browser”, “version”, “platform”, “resolution”}) é adicionada ao método de teste.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
classe pública GoogleSearchTest implementos IExecutionListener {
/* driver EdgeDriver estático protegido; */
String URL = “https://www.google.com/”;
String search_string = “LambdaTest”;
Driver WebDriver = nulo;
…………………………
…………………………
public static String status = “passed”;
public static String username = “user-name”;
public static String access_key = “access-key”;
…………………………
…………………………
@BeforeTest
@Parameters(value={“browser”, “version”, “platform”, “resolution”})
public void testSetUp(String browser, String version, String platform, String resolution) throws Exception {
…………………………
…………………………
}

Estes parâmetros seriam passados valores do testng.xml, parâmetro de amostra mostrado abaixo:

Passo 4 – O método testSetUp é um método parametrizado que tira iterativamente os parâmetros de teste do TestNG.xml até o final do conjunto de testes é encontrado.

Como os testes são executados na nuvem Selenium Grid no LambdaTest, as credenciais consistem em um nome de usuário & um token de acesso que pode ser usado para acessar a LambdaTest Grid – @hub.lambdatest.com/wd/hub.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
teste de vazio públicoSetUp(String browser, Versão String, Plataforma String, Resolução String) lança Exceção {
Capacidades Desejadas = novas Capacidades Desejadas();
capacidades.setCapability(“build”, “Google Search – Maven Parallel Testing with Jenkins Pipeline”);
capabilities.setCapability(“name”, “Google Search – Maven Parallel Testing with Jenkins Pipeline”);
…………………………
…………………………
try {
driver = novo RemoteWebDriver(new URL(“http://” + username + “:” + access_key + “@hub.lambdatest.com/wd/hub”), capabilities);
} catch (MalformedURLException e) {
System.out.println(“Invalid grid URL”);
}
System.out.println(“Started session”);

A API do RemoteWebDrive usa a URL remota e os recursos do navegador que são gerados usando o gerador de recursos LambdaTest e passados para o método na forma de parâmetros de entrada.

1
2
3
4
>

>

driver = novo RemoteWebDriver(novo URL(“http://” + username + “:” + access_key + “@hub.lambdatest.com/wd/hub”), capacidades);
catch (MalformedURLException e)

Passo 5 – O método de teste é implementado sob a anotação @Test. Os métodos Selenium apropriados (findElement, sendKeys, submit, e mais) são usados para localizar o Elemento Web e realizar ações apropriadas sobre o mesmo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Test
teste de vazio público_Selenium4_GoogleSearch() lança InterruptedException {
driver.navigate().to(URL);
driver.manage().window().maximize();
try {
/* Digite o termo de busca na caixa de busca do Google */
search_box = driver.findElement(By.xpath(“//input”));
search_box.sendKeys(search_string);
search_box.submit();
……………………………………
……………………………………
}
……………………………………
……………………………………
}

Passo 6 – Atrasos de bloqueio não é uma boa prática de programação, mas adicionamos poucos atrasos para observar o output.

1
2
3
4
5
6
7
WebElement lt_link = driver.findElement(By.xpath(“//h3”));
lt_link.click();
/* Não é uma boa prática de programação, adicionado para demonstração */
Thread.sleep(5000);
……………………………………
……………………………………

Passo 7 – O método que é implementado em @AfterTest anotação liberta os recursos alocados pelo Condutor Web correspondente instanciado.

1
2
3
4
5
6
7
@Após-Classe
lacrimogéneo público() {
if (condutor != null) {
((JavascriptExecutor) driver).executeScript(“lambda-status=” + status);
driver.quit();
}
}

Test Suite – 2

Test Scenario – 1 (Chrome no Windows 10)

  1. Navigate para a URL https://lambdatest.com
  2. Verifica a Página Título
  3. Compare o título da página com o título esperado
  4. Avalie se os títulos não corresponderem

Implementação

É o mesmo que o que é usado para o Test Suite-1, excepto o artefacto e o groupID.

CrossBrowserTest.java

Para a demonstração de Maven e Jenkins com Selenium, estaríamos executando estas duas suítes de teste em paralelo usando o projeto FreeStyle e Jenkins Pipeline.

Woo-hoo! Obrigado por se inscrever na newsletter semanal do LambdaTest!

Configurando Jenkins para o Projeto Jenkins Selenium

Antes de criar um novo trabalho em Jenkins que constrói o projeto mencionado anteriormente, temos que configurar o ambiente Jenkins.

Passo 1: O caminho de instalação do JDK tem que ser adicionado à Variável de Ambiente do Sistema. Isto também é necessário para JRE (Java Runtime Environment).

Step 2: Baixe o Jenkins em .war e inicie Jenkins executando o seguinte comando no terminal:

1
>

java -Dhudson.model.DirectoryBrowserSupport.CSP=”sandbox allow-scripts allow-popups allow-popups-to-escape-sandbox; style-src ‘unsafe-inline’ *;” -Dsvnkit.http.sslProtocols=TLSv1 -jar Jenkins.war –httpPort=909090

Em vez do 8080 (número de porta padrão usado por Jenkins), iniciamos o serviço Jenkins na porta 9090.

Passo 3: Visite localhost:9090 no navegador para começar a usar Jenkins.

Criar um novo usuário (com privilégios de administrador). Login usando esse nome de usuário para continuar usando Jenkins.

Passo 4: Como o projeto está usando Maven e Jenkins com Selenium, as configurações e caminhos globais para Java & Maven têm que ser configurados em Jenkins. Para configurar estas configurações, navegue para ‘Configurar o Sistema’ na seção ‘Configuração do Sistema’.

No item intitulado ‘Propriedades globais’, adicione as seguintes variáveis de ambiente:

1
2
JAVA_HOME – <Local onde JDK está instalado>
MAVEN_HOME – <Local onde Maven está instalado>

No nosso caso as entradas são as seguintes:

1
2
JAVA_HOME – C:\Arquivos de programa\Java\jdk1.8.0_251
MAVEN_HOME – C:\apache-maven\apache-maven-3.6.3\

Clique em Aplicar e Salvar.

A adição destas variáveis de ambiente na Configuração do Sistema torna as configurações públicas (i.e. pode ser usado para o projeto Jenkins FreeStyle e Jenkins Pipeline).

Passo 5: O HTML Publisher Plugin deve ser instalado antes que a ação pós-construção para os testes possa ser executada. O mesmo pode ser feito navegando para ‘Manage Plugins’ e procurando por ‘HTML Publisher Plugin’ na aba ‘Available’. Clique em ‘Install’ para instalar o plugin.

Note: Para testes cross browser, é recomendado usar o Jenkins no formato .war já que os testes são executados no modo non-headless somente quando o Jenkins é usado no formato .war.

Selenium Maven Jenkins Integration Using FreeStyle Project

Para criar um projeto FreeStyle que usa a integração Selenium Maven Jenkins como demonstração, execute os seguintes passos na Jenkins UI (i.e. localhost:9090/)

(Nota – O número da porta irá variar com base na porta usada por Jenkins)

Passo 1: Na ‘Jenkins UI’, clique em ‘New Item’.

Passo 2: Digite o nome do trabalho como ‘LambdaTest – Integração Selenium Maven Jenkins (Projeto Maven)’ e selecione o projeto ‘FreeStyle’.

Jenkins também fornece uma opção para criar um projeto ‘Maven’ onde as configurações necessárias para a configuração do projeto são mínimas. Entretanto, para esta demonstração, usamos um projeto ‘FreeStyle’.

Step 3: Vá para o projeto ‘Build’ ? Invoque alvos Maven de alto nível’. A versão Maven deve apontar para a versão da Maven instalada na máquina. No nosso caso, é Maven 3.6.3.

Passo 4: Clique em ‘Avançado’ para definir os Objectivos, defina a localização dos ficheiros POM para as duas suites de teste. No nosso caso, as localizações dos projetos estão abaixo:

Como queremos realizar construções paralelas, usamos a seguinte opção com o comando mvn:

1
mvn -T 4 clean install

>

Este comando realizará builds com 4 threads. Na seção ‘Metas’, você deve digitar -T 4 clean install. O mesmo objetivo é definido para as builds Maven para ambos os projetos. Em ‘POM’, dê a localização absoluta de pom.xml

(i.e. Build 1 – C:\Users\Lenovo\IdeaProjects\Maven_Jenkins\pom.xml

Build 2 – C:\Users\Lenovo\IdeaProjects\Maven_Jenkins_2\pom.xml)

Passo 5: A ‘ação pós-Build’ é publicar relatórios HTML que dão informações sobre o cenário geral do teste (ou seja, número de testes aprovados/falhados/skipped, etc.). Selecione ‘Publish HTML Reports’ em ‘Add post-build action’.

Step 6: O plugin Maven Surefire Report analisa os arquivos TEST-*.xml gerados sob ${project_dir}/target/surefire-reports e os renderiza usando DOXIA. Em ‘HTML directory to archive’, digite o caminho absoluto daquele local que contém os relatórios surefire.

Para o Test Suite 1:

1
2
3
Directório HTML para arquivar – ${project_dir_1}/target/surefire-reports
Index Página(s) – índice.html
Título do relatório – Relatório do Cenário 1 Relatório

Para o Test Suite 2:

1
2
3
Directório HTML para arquivar – ${project_dir_2}/target/surefire-reports
Index Página(s) – índice.html
Título do relatório – Cenário de teste 2 Relatório

Passo 7: O projeto está agora pronto para ser construído. Clique na opção ‘Build Now’ para acionar o build.

Step 8: Clique na opção ‘Console Output’ para testemunhar o progresso das etapas de build, teste e relatório.

Passo 9: Como visto nos ‘Logs do Console; os testes são executados com sucesso – cinco casos de teste como parte da primeira suite de testes e um caso de teste como parte da segunda suite de testes.

Aqui estão as screenshots dos relatórios HTML que são gerados para as duas suites de testes pelo HTML Publisher Plugin.

Relatório para Cenário de Teste – 1

>

Relatório para Cenário de Teste – 2

Integração de Maven Jenkins com o Pipeline de Jenkins

Nesta seção de demonstração de Maven e Jenkins com Selenium, nós estaríamos usando o Pipeline Jenkins que usa Domain Specific Language (DSL) para realizar o Pipeline como Código.

A definição de um Pipeline Jenkins é normalmente escrita em um arquivo chamado Jenkinsfile. Este arquivo conteria os passos necessários para executar o Pipeline de Jenkins. Para uma rápida recapitulação do Jenkins Pipeline declarativo, você pode conferir este tutorial do Jenkins Pipeline.

Para integrar Maven e Selenium com o Jenkins Pipeline, você tem que executar os passos mencionados abaixo:

Passo 1: Criar um novo item intitulado ‘LambdaTest – Selenium Maven Jenkins integration (Pipeline Project)’ do tipo ‘Pipeline’.

Passo 2: Na definição de Pipeline, cole o conteúdo de Jenkinsfile como mostrado abaixo. Clique em Aplicar e Salvar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
gasoduto {
agente qualquer
ferramentas {
maven ‘MAVEN_3.6.3’
jdk ‘JDK_1.8.0_251’
}
estágios {
estágio(‘Run Tests’) {
ambiente {
PROJECT_DIR_1 = “C:\\UUTILIZADORES LENOVO PROJECTOS DE IDADEIA “Maven_Jenkins”
PROJECT_DIR_2 = “C: UTILIZADORES LENOVO PROJECTOS DE IDADEIA “Maven_Jenkins_2”
}
paralelo {
fase(‘Cenário de teste 1’) {
agente {
etiqueta “Slave_1”
}
passos {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_1%\\\\pom.xml clean install’
}
post {
success {
publishHTML ()
}
}
}
fase(‘Cenário de teste 2’) {
agente {
etiqueta “Slave_2”
}
passos {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_2%\\pom.xml clean install’
}
post {
sucesso {
publishHTML ()
}
}
}
}
}
}
}

Passo 3: Na seção pós-construção, o HTML Publisher Plugin é usado para criar os relatórios de teste pós-execução para os dois cenários de teste.

Pipeline Walkthrough

Passo 1: Este trabalho específico do Jenkins pode ser executado em qualquer Agente. A seção com a diretiva de ferramentas contém todas as ferramentas que têm que ser instaladas automaticamente. O mesmo é então também adicionado à variável de ambiente PATH.

1
2
3
4
5
6
gasoduto {
agente qualquer
ferramentas {
maven ‘MAVEN_3.6.3’
jdk ‘JDK_1.8.0_251’
}

Na máquina onde os testes serão executados, JDK 1.8.0_251 e Maven 3.6.3 estão instalados. O alias maven e jdk apontam para as respectivas versões Maven e JDK.

Passo 2: A diretiva de ambiente é usada para definir as variáveis de ambiente PROJECT_DIR_1 e PROJECT_DIR_2 que apontam para o local onde os projetos Java estão presentes. Estas variáveis de ambiente podem ser usadas para todos os passos ou passos específicos do estágio, uma vez que são definidas no estágio principal ‘Run Tests’.’

1
2
3
4
5
6
estágios {
estágio(‘Run Tests’) {
ambiente {
PROJECT_DIR_1 = “C:\\UUTILIZADORES LENOVO PROJECTOS DE IDADEIA “Maven_Jenkins”
PROJECT_DIR_2 = “C: UTILIZADORES LENOVO PROJECTOS DE IDADEIA “Maven_Jenkins_2”
}

Passo 3: A directiva paralela em Jenkins é usada para executar os estágios de Pipeline em paralelo. No nosso caso, o Pipeline Jenkins consiste em dois estágios – Cenário de Teste 1 e Cenário de Teste 2.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

>
estágios {
estágio(‘Run Tests’) {
ambiente {
PROJECT_DIR_1 = “C:\\UUTILIZADORES LENOVO PROJECTOS DE IDADEIA “Maven_Jenkins”
PROJECT_DIR_2 = “C: UTILIZADORES LENOVO PROJECTOS DE IDADEIA “Maven_Jenkins_2”
}
paralelo {
fase(‘Cenário de teste 1’) {
…………………………………..
…………………………………..
}
fase(‘Cenário de teste 2’) {
…………………………………..
…………………………………..
}
}
}
}

Passo 4: As ações realizadas em ambas as etapas são exatamente semelhantes, exceto que são realizadas em projetos diferentes. A etapa ‘Test Scenario 1‘ é executada no Nó ‘Slave_1‘ e a etapa ‘Test Scenario 2‘ é executada no Nó ‘Slave_2‘.

1
2
3
4
5
6
7
8
9
10
11
paralelo {
fase(‘Cenário de teste 1’) {
agente {
etiqueta “Slave_1”
}
………….
………….
fase(‘Cenário de teste 2’) {
agente {
etiqueta “Slave_2”
}

Caso pretenda executar a conduta em qualquer agente, pode saltar usando qualquer nome de agente em particular nestas etapas. Você pode consultar o nosso blog What is Jenkins para entender a criação de nós em Jenkins.

No nosso caso, criamos dois nós (Slave_1 e Slave_2) e os fizemos online antes de executar os testes.

Passo 5: No próximo passo, o build é acionado. O comando mvn clean install é então executado no pom.xml que está presente no diretório do projeto. Estamos usando uma máquina Windows para execução e por isso usamos o comando bat (ou batch) para acionar a compilação do Maven.

1
2
3
4
passos {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_1%pom.xml clean install’
}

Passo 6: A ação pós-construção é usada para publicar relatórios HTML para os respectivos estágios. As ações são adicionadas sob a diretiva ‘post’. Nós queremos invocar a criação do relatório de teste somente se a compilação for bem sucedida. Portanto, as ações estão sob a diretiva success.

Como visto na demonstração usando o projeto FreeStyle, reportDir é definido para o local onde os relatórios surefire são gerados (i.e. ${project_dir}/target/surefire-reports). O campo reportFiles está configurado para index.html (i.e. ${project_dir}/target/surefire-reports/index.html).

1
2
3
4
5
6
7
8
9
10
11
12
13
post {
sucesso {
publishHTML ()
}
}

Após o Pipeline ser adicionado ao Jenkinsfile, clique em ‘Build Now’ para iniciar o processo de construção.

Você pode pairar para qualquer Etapa e clicar em ‘Logs’ para dar uma olhada no progresso da execução dessa Etapa em particular. Como visto na foto do Estágio, os dois estágios são executados em paralelo.

Como estamos usando estágios paralelos com Pipeline declarativo em Jenkins, os respectivos casos de teste são executados em paralelo na grade Selenium baseada na nuvem no LambdaTest. Como mostrado abaixo, nosso plano no LambdaTest suporta no máximo cinco testes a serem executados em paralelo.

Como mostrado abaixo, os testes foram executados com sucesso.

O tempo total de execução foi de aproximadamente 6 minutos. Você pode passar para qualquer estágio para ver os logs associados a esse estágio.

Como visto nos logs truncados, é evidente que os passos nos dois estágios foram executados em Parallel:

>

Aqui está a captura de tela dos relatórios HTML que são gerados como parte da ação pós-construção:

>

Brapar até

fonte

Executar testes Selenium em Jenkins dá a flexibilidade de executar testes cada vez que há uma mudança de software, e essas mudanças têm que ser testadas contra diferentes combinações de entrada. Maven é usado em projetos Java, pois facilita a tarefa de gerenciamento de dependências através do arquivo pom.xml.

Projetos estilo árvore em Jenkins devem ser usados para projetos que não são de alta complexidade. O Jenkins Pipeline deve ser usado quando você quiser definir o Pipeline de implantação como código. A diretiva paralela no Pipeline de Jenkins deve ser usada para alavancar a execução paralela de Etapas em Jenkins. O Jenkins Pipeline pode ser integrado com uma grade de selênio baseada em nuvem como o LambdaTest, que também permite integrar Maven e Jenkins com selênio de uma forma mais eficiente.

Esperamos que, seguindo este tutorial, você integre facilmente a Maven e Jenkins com Selênio. Obrigado por ler!

Himanshu Sheth

Com mais de 7 anos de experiência em automação de testes, BDD, TDD, Himanshu Sheth trabalha como engenheiro de automação com LambdaTest. Ele também é um ávido blogger.

Escrito por

Deixe uma resposta

O seu endereço de email não será publicado.