Articles

Hur integrerar man Jenkins och Maven med Selenium?

On september 23, 2021 by

Denna artikel är en del av vår Content Hub. För mer djupgående resurser, kolla in vår innehållshubb om Jenkins Tutorial.

Jenkins är ett av de populära verktygen för kontinuerlig integration, bygghantering och automatiseringstestning. Maven är ett populärt verktyg för byggautomation som används ofta för Java-projekt. Kombinationen av Selenium, Maven, Jenkins integration är toppen av kontinuerlig integration och distribution.

Som en del av automatiseringstesterna är vi säkra på att ditt team kommer upp med många Selenium test automation scripts varannan dag. Eftersom Selenium i sig inte används för kontinuerlig integration används Selenium, Maven och Jenkins integration för bygghantering och kontinuerlig integration. I den här artikeln tittar vi på användningen av Maven och Jenkins med Selenium.

En snabb sammanfattning av blogginlägget är nedan:

Oversikt över Selenium, Maven, & Jenkins

Maven är ett populärt verktyg för byggautomatisering som främst används för Java-projekt. Fördelen med att använda Maven är att Javabibliotek och plugins hämtas dynamiskt från Maven 2 Central Repository.

Beroendena och annan viktig byggrelaterad information lagras i en pom.xml-fil för projektet. När beroendena har laddats ner lagras de i en lokal cache (.M2 repository), och samma används för bygggenerering. Detta förenklar byggprocessen eftersom alla nya projektberoenden endast behöver läggas till i pom.xml, dvs. det krävs ingen manuell nedladdning och inga installationspaket.

Selenium är ett allmänt använt ramverk för testautomatisering för validering av webbapplikationer över olika kombinationer av webbläsare, plattformar och enheter (eller emulatorer). Du kan hänvisa till våra bloggar om hur Selenium Grid kan användas för automatiserad testning av webbläsare.

Jenkins är ett CI/CD-verktyg med öppen källkod som hjälper till att automatisera aktiviteter relaterade till byggning, testning och distribution. Jenkins har ett omfattande ekosystem för insticksprogram, är öppen källkod och har en passionerad gemenskap – faktorer som kan tillskrivas Jenkins funktioner.

I den här bloggen om Maven och Jenkins med Selenium kommer vi att använda TestNG, som är ett populärt testramverk som är inspirerat av JUnit. Det används i stor utsträckning för testområden som funktionell testning, end-to-end-testning med mera.

Detta är den uppsättning verktyg som vi skulle använda i demonstrationen:

  • Maven – Projekthanteringsverktyg i Java
  • TestNG – Populärt ramverk för testautomatisering
  • Selenium WebDriver – Bibliotek som i första hand används för automatisering av webbläsarinteraktioner
  • Jenkins – Verktyg för Continuous Integration (CI) och Continuous Deployment (CD)

Här är det övergripande informationsflödet när Selenium, Maven och Jenkins är integrerade:

  • När utvecklaren lägger in kod i arkivet (t.ex.g., GitHub) utlöses ett Jenkins-bygge.
  • Maven hämtar de beroende bibliotekens & paket och börjar utföra bygget. Informationen om testsviten finns i testing.xml, och samma information används också i pom.xml.
  • Ett byggmål (t.ex. install) för att köra de automatiserade testerna ställs in. Samma sak uppnås genom maven-surefire-plugin.
  • Maven-surefire-plugin talar om för TestNG att köra de tester som finns under annotationen @Test.
  • Avhängigt av AUT (applikation under test) och webbläsaren (& OS-kombination) som testerna över webbläsargränserna utförs på, anropar Selenium WebDriver motsvarande webbläsarinstans och utför samma automatiseringstester.
  • Testresultaten publiceras i HTML-rapporter, eftersom insticksmodulen HTML Publisher används för rapportgenerering.
  • Även om ett enskilt testfall har misslyckats markeras hela testet med status ”Failed”.’

Fördelar med att använda Maven & Jenkins med Selenium

För att demonstrera användningen av Selenium Maven Jenkins-integration ska vi ta en titt på de viktigaste fördelarna med att använda Maven och Jenkins med Selenium:

  • Varhelst en ändring görs i implementationen distribueras ändringarna på testmiljön. Automatiseringstester utförs kontinuerligt och utvecklarna hålls informerade om resultaten från bygg- och teststadiet.
  • Testsviter som består av många testscenarier (eller testkombinationer) kan ta längre tid för automatiseringstestning. En nattlig byggkörning kan schemaläggas för att byggas och utföras på Jenkins-servern i sådana fall.
  • Då Maven använder pom.xml minskar det totala beroendet av manuell nedladdning av jar-filer. Dessutom hjälper typen ”Maven Project” i Jenkins till att komma igång med Selenium Maven, Jenkins integration med några få konfigurationsinställningar.
  • Den Selenium Maven Jenkins integrationsuppsättningen lämpar sig för utvecklings- och testteam som är distribuerade över olika geografiska platser.

Förutsättningar för Jenkins Selenium-projekt

För demonstration av Maven och Jenkins med Selenium bör följande programvaror vara installerade (eller tillgängliga) på maskinen från vilken testerna utlöses:

  • Eclipse IDE eller IntelliJ IDEA (Maven är standard i båda dessa IDE:
  • Jenkins i .war-format
  • Chrome WebDriver som matchar versionen av webbläsaren Chrome på din maskin
  • Microsoft Edge Driver
  • Konto på LambdaTest (eftersom testerna utförs på LambdaTests molnbaserade Selenium Grid)

Demonstration av Selenium Maven Jenkins-integration

För att spara tid, skulle vi inte titta på varje steg i skapandet av ett Maven-projekt. Om du vill ha en snabb sammanfattning av Maven med Selenium kan du läsa den här Maven-handledningen för Selenium-testautomatisering. De steg som används för att skapa ett Maven-projekt i IntelliJ IDEA liknar dem som används för att skapa ett Maven-projekt i Eclipse IDE.

Test Suite – 1

Test Scenario – 1 (Chrome on Windows 10)

  1. Navigera till den här URL- https://lambdatest.github.io/sample-todo-app/.
  2. Välj de två första kryssrutorna.
  3. Inför ”Happy Testing at LambdaTest” i textrutan nedan med följande id = sampletodotext.
  4. Klicka nu på knappen Lägg till och kontrollera om texten har lagts till eller inte.

Testscenario – 2 (Testar på 4 olika kombinationer av webbläsare och operativsystem)

  1. Navigera till denna URL- https://www.google.com.
  2. Sök efter ”LambdaTest”.
  3. Klicka på det första testresultatet.
  4. Skapa nu en Assert om sidtiteln inte matchar den förväntade titeln.

Implementation

De lämpliga beroendena och plugins måste läggas till i projektets pom.xml. Här är de viktigaste paketen (eller burkarna) som ingår i pom.xml:

  • Selenium 4 (Alpha)
  • TestNG-ramverket (version 6.9.10)
  • Maven Surefire-plugin för exekvering av testsviten som är en del av testng.xml
  • Maven Surefire Report-plugin för att generera testresultatrapporten i HTML-format

Om du har för avsikt att lägga till något nytt plugin eller jar till ovanstående pom.xml, sök efter samma sak i Maven Repository och lägg till motsvarande beroende/plugin i det relevanta avsnittet.

Testsviten innehåller två testfall, nämligen test_Selenium4_ToDoApp() & test_Selenium4_GoogleSearch(). Som framgår nedan lagras genomförandet av dessa testfall i separata filer, nämligen CrossBrowserTest.java och GoogleSearchTest.java, och båda är en del av paketet org.selenium4.

Testscenariot test_Selenium4_ToDoApp() är tänkt att exekveras på Chrome (senaste versionen) för Windows 10. Å andra sidan måste testscenariot test_Selenium4_GoogleSearch() utföras på fyra olika kombinationer av webbläsare och operativsystem, dvs. Chrome (senaste version) på Windows 10, Edge (84.0) på Windows 10, Chrome (senaste version) på macOS Mojave och Firefox (senaste version) på OS X Mavericks.

Posterna i testng.xml för test_Selenium4_GoogleSearch() har anpassats i enlighet med webbläsarkapaciteterna som genererats av LambdaTest capabilities generatorn. Nedan visas de exempelkapaciteter som genererats för Chrome (senaste) & Windows 10-kombinationen:

I genomförandet skulle vi använda TestNG-lyssnare i Selenium WebDriver för automatiseringstestning. På svitnivå definierar vi klassnamn för att implementera lyssnare i TestNG xml-filen. Annotationen @listeners i TestNG används för att lägga till klassen org.selenium4.GoogleSearchTest.

Som visas nedan kommer testnamnet ”Google Search Test – 1” att ta emot inparametrar som specificerar webbläsare, version, plattform och skärmupplösning. Dessa värden skulle skickas till testmetoden som argument med hjälp av parametriserade annotationer (dvs. @org.testng.annotations.Parameters(value={”browser”, ”version”, ”platform”, ”resolution”}).

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

CrossBrowserTest.java (Genomförande av testscenario – 1)

GoogleSearchTest.java (Implementation of Test Scenario – 2)

Code Walkthrough

Steg 1 – De nödvändiga paketen importeras innan själva implementationen påbörjas. Eftersom TestNG-ramverket används för testning importeras även dess paket innan dess annotationer kan användas.

1
2
3
4
5
import org.testng.annotations.AfterClass;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;
import static org.junit.Assert.*;
import org.junit.Test.*;

Steg 2 – IExecutionListener används för att övervaka starten och slutet av testsviten, eftersom testscenariot skulle exekveras på olika inmatningskombinationer som skickas via TestNG xml-filen.

IExecutionListener innehåller två metoder – onExecutionStart() och onExecutionFinish(). onExecutionStart() åberopas innan testet startar och onExecutionFinish() åberopas när testerna/testsviterna har avslutats.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class GoogleSearchTest implements IExecutionListener {
/* protected static EdgeDriver driver; */
String URL = ”https://www.google.com/”;
…………………………..
…………………………..
…………………………..
@Override
public void onExecutionStart() {
System.out.println(”onExecutionStart”);
}
@Override
public void onExecutionFinish() {
System.out.println(”onExecutionFinish”);
}

Steg 3 – Den metod som implementeras under @BeforeTest-annotationen kommer att köras innan någon testmetod som tillhör klassen under den taggen körs. Eftersom vi använder parametrerad testning med TestNG läggs annotationen @Parameters(value={”browser”, ”version”, ”platform”, ”resolution”}) till testmetoden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class GoogleSearchTest implements IExecutionListener {
/* protected static EdgeDriver driver; */
String URL = ”https://www.google.com/”;
String search_string = ”LambdaTest”;
WebDriver driver = null;
…………………………
…………………………
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 {
…………………………
…………………………
}

Dessa parametrar skulle få värden från testng.xml, exempelparametern visas nedan:

Steg 4 – Metoden testSetUp är en parameteriserad metod som iterativt tar testparametrarna från TestNG.xml tills testsviten är slut.

Då testerna utförs i Selenium Grid-molnet på LambdaTest består autentiseringsuppgifterna av ett användarnamn & en åtkomsttoken som kan användas för att få tillgång till LambdaTest Grid – @hub.lambdatest.com/wd/hub.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void testSetUp(String browser, String version, String platform, String resolution) throws Exception {
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability(”build”, ”Google Search – Maven Parallel Testing with Jenkins Pipeline”);
capabilities.setCapability(”name”, ”Google Search – Maven Parallel Testing with Jenkins Pipeline”);
…………………………
…………………………
try {
driver = new RemoteWebDriver(new URL(”http://” + användarnamn + ”:” + access_key + ”@hub.lambdatest.com/wd/hub”), capabilities);
} catch (MalformedURLException e) {
System.out.println(”Invalid grid URL”);
}
System.out.println(”Startad session”);

API:et RemoteWebDrive använder fjärr-URL:n och webbläsarkapaciteterna som genereras med hjälp av LambdaTest-kapacitetsgeneratorn och som överförs till metoden i form av inparametrar.

1
2
3
4
try {
driver = new RemoteWebDriver(new URL(”http://” + username + ”:” + access_key + ”@hub.lambdatest.com/wd/hub”), capabilities);
}
catch (MalformedURLException e)

Steg 5 – Testmetoden implementeras med hjälp av annotationen @Test. De lämpliga Selenium-metoderna (findElement, sendKeys, submit med flera) används för att hitta webbelementet och utföra lämpliga åtgärder på detsamma.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Test
public void test_Selenium4_GoogleSearch() throws InterruptedException {
driver.navigate().to(URL);
driver.manage().window().maximize();
try {
/* Ange sökbegreppet i Googles sökruta */
search_box = driver.findElement(By.xpath(”//input”)));
search_box.sendKeys(search_string);
search_box.submit();
……………………………………
……………………………………
}
……………………………………
……………………………………
}

Steg 6 – Att blockera fördröjningar är inte en bra programmeringspraxis, men vi har lagt till några fördröjningar för att observera resultatet.

1
2
3
4
5
6
7
WebElement lt_link = driver.findElement(By.xpath(”//h3”)));
lt_link.click();
/* Ingen bra programmeringspraxis, läggs till för demonstration */
Thread.sleep(5000);
……………………………………
……………………………………

Steg 7 – Metoden som implementeras under @AfterTest-annotationen frigör de resurser som tilldelats av den instansierade motsvarande WebDriver.

1
2
3
4
5
6
7
@AfterClass
public void tearDown() {
if (driver != null) {
((JavascriptExecutor) driver).executeScript(”lambda-status=” + status);
driver.quit();
}
}

Testföljd – 2

Testscenario – 1 (Chrome på Windows 10)

  1. Navigera till URL:en https://lambdatest.com
  2. Kontrollera sidan Title
  3. Genomför sidans titel med den förväntade titeln
  4. Assert om titlarna inte stämmer överens

Implementation

Det är samma som den som används för Test Suite-1, med undantag för artifactId och groupID.

CrossBrowserTest.java

För demonstrationen av Maven och Jenkins med Selenium skulle vi exekvera dessa två testsviter parallellt med hjälp av FreeStyle-projektet och Jenkins Pipeline.

Woo-hoo! Tack för att du anmälde dig till LambdaTests veckobrev!

Inställning av Jenkins för Jenkins Selenium-projektet

För att skapa ett nytt jobb i Jenkins som bygger det tidigare nämnda projektet måste vi ställa in Jenkins-miljön.

Steg 1: Installationsstigen för JDK måste läggas till i System Environment Variable. Detta krävs även för JRE (Java Runtime Environment).

Steg 2: Ladda ner Jenkins i .war-format och starta Jenkins genom att utföra följande kommando i terminalen:

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=9090

Istället för 8080 (standardportnummer som används av Jenkins) startar vi Jenkins-tjänsten på port 9090.

Steg 3: Besök localhost:9090 i webbläsaren för att börja använda Jenkins.

Skapa en ny användare (med administratörsrättigheter). Logga in med det användarnamnet för att fortsätta använda Jenkins.

Steg 4: Eftersom projektet använder Maven och Jenkins med Selenium måste de globala inställningarna och sökvägarna för Java & Maven konfigureras i Jenkins. För att konfigurera dessa inställningar navigerar du till ”Configure System” i avsnittet ”System Configuration”.

I punkten ”Globala egenskaper” lägger du till följande miljövariabler:

1
2
JAVA_HOME – <Ställe där JDK är installerat>
MAVEN_HOME – <Ställe där Maven är installerat>

I vårt fall är posterna som nedan:

1
2
JAVA_HOME – C:\Program Files\Java\jdk1.8.0_251
MAVEN_HOME – C:\apache-maven\apache-maven-3.6.3\

Klicka på Apply and Save.

För att lägga till dessa miljövariabler i systemkonfigurationen blir inställningarna offentliga (dvs.kan användas för Jenkins FreeStyle-projektet och Jenkins Pipeline-projektet).

Steg 5: HTML Publisher Plugin bör installeras innan åtgärden efter byggandet för testerna kan utföras. Samma sak kan göras genom att navigera till ”Manage Plugins” och söka efter ”HTML Publisher Plugin” på fliken ”Available”. Klicka på ”Install” för att installera insticksmodulen.

Anmärkning: För testning mellan olika webbläsare rekommenderas det att använda Jenkins i .war-formatet, eftersom testerna endast utförs i det icke-huvudlösa läget när Jenkins används i .war-formatet.war-formatet.

Selenium Maven Jenkins-integration med hjälp av FreeStyle-projektet

För att skapa ett FreeStyle-projekt som använder Selenium Maven Jenkins-integration som demonstration utför du följande steg på Jenkins UI (i.localhost:9090/)

(Obs – portnumret varierar beroende på vilken port som används av Jenkins)

Steg 1: I ”Jenkins UI” klickar du på ”New Item”.

Steg 2: Ange jobbnamnet som ”LambdaTest – Selenium Maven Jenkins integration (Maven Project)” och välj ”FreeStyle” projekt.

Jenkins erbjuder också ett alternativ för att skapa ett ”Maven”-projekt där de konfigurationsinställningar som krävs för att konfigurera projektet är minimala. För den här demonstrationen har vi dock använt ett ”FreeStyle”-projekt.

Steg 3: Gå till ”Build” ? ’Invoke top-level Maven targets’. Maven-versionen ska peka på den version av Maven som är installerad på maskinen. I vårt fall är det Maven 3.6.3.

Steg 4: Klicka på ”Advanced” (Avancerat) för att ställa in Goals (mål), ställ in platsen för POM-filer för de två testsviterna. I vårt fall är projektplaceringarna nedan:

Då vi vill utföra parallella byggen använder vi följande alternativ med kommandot mvn:

1
mvn -T 4 clean install

Detta kommando kommer att utföra byggen med 4 trådar. I avsnittet ”Goals” ska du ange -T 4 clean install. Samma mål sätts för Maven-byggnaderna för båda projekten. I ”POM” anger du den absoluta platsen för pom.xml

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

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

Steg 5: ”Post-Build-åtgärden” är att publicera HTML-rapporter som ger information om det övergripande testscenariot (t.ex. antal tester som klarats/felaktiggjorts/hoppats, etc.). Välj ”Publish HTML Reports” i ”Add post-build action”.

Steg 6: Insticksmodulen Maven Surefire Report analyserar de genererade TEST-*.xml-filerna under ${project_dir}/target/surefire-reports och renderar dem med DOXIA. I ”HTML directory to archive” anger du den absoluta sökvägen till den plats som innehåller surefire-rapporter.

För Test Suite 1:

1
2
3
HTML-katalogen till arkiv – ${project_dir_1}/target/surefire-reports
Indexsida(n) – index.html
Rapporttitel – rapport om testscenario 1

För testsekvens 2:

1
2
3
HTML-katalogen att arkivera – ${project_dir_2}/target/surefire-reports
Indexsida(n) – index.html
Report Title – Test Scenario 2 Report

Steg 7: Projektet är nu redo att byggas. Klicka på alternativet ”Build Now” (bygg nu) för att starta byggandet.

Steg 8: Klicka på ”Console Output” (konsolutgång) för att bevittna framstegen i bygg-, test- och rapporteringsfaserna.

Steg 9: Som framgår av ”Console logs; the tests are executed successfully – five test cases as part of the first test suite and one test case as part of the second test suite.

Här är skärmdumparna av de HTML-rapporter som genereras för de två testsviterna av HTML Publisher Plugin.

Rapport för testscenario – 1

Rapport för testscenario – 2

Selenium Maven Jenkins Integration med hjälp av Jenkins Pipeline

I det här avsnittet om demonstration av Maven och Jenkins med Selenium, använder vi Jenkins Pipeline som använder Domain Specific Language (DSL) för att realisera Pipeline som kod.

Definitionen av en Jenkins Pipeline skrivs normalt in i en fil som heter Jenkinsfile. Denna fil skulle innehålla de steg som krävs för att köra Jenkins Pipeline. För en snabb sammanfattning av den deklarativa Jenkins Pipeline kan du kolla in denna Jenkins Pipeline-tutorial.

För att integrera Maven och Selenium med Jenkins Pipeline måste du utföra de steg som nämns nedan:

Steg 1: Skapa ett nytt objekt med titeln ”LambdaTest – Selenium Maven Jenkins integration (Pipeline Project)” av typen ”Pipeline”.

Steg 2: I Pipeline-definitionen klistrar du in innehållet i Jenkinsfile enligt nedan. Klicka på Apply (tillämpa) och Save (spara).

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
pipeline {
agent any
tools {
maven ’MAVEN_3.6.3’
jdk ’JDK_1.8.0_251’
}
stages {
stage(’Run Tests’) {
environment {
PROJECT_DIR_1 = ”C:\\Users\\Lenovo\IdeaProjects\\\Maven_Jenkins”
PROJECT_DIR_2 = ”C:\\Users\\Lenovo\\\IdeaProjects\\Maven_Jenkins_2”
}
parallell {
stage(’Testscenario 1’) {
agent {
label ”Slave_1”
}
steps {
echo ’maven clean’
bat ’ mvn -f %PROJECT_DIR_1%\pom.xml clean install’
}
post {
success {
publishHTML ()
} }
}
}
stage(’Test Scenario 2’) {
agent {
label ”Slave_2”
}
steps {
echo ’maven clean’
bat ’ mvn -f %PROJECT_DIR_2%\pom.xml clean install”
} }
post {
success {
publishHTML ()
}
}
}
}
}
}
}

Steg 3: I avsnittet efter byggandet används HTML Publisher Plugin för att skapa testrapporterna efter utförandet för de två testscenarierna.

Pipeline Walkthrough

Steg 1: Det här specifika Jenkinsjobbet kan köras på vilken Agent som helst. Avsnittet med tools-direktivet innehåller alla verktyg som måste installeras automatiskt. Samma sak läggs sedan också till i miljövariabeln PATH.

1
2
3
4
5
6
pipeline {
agent any
tools {
maven ’MAVEN_3.6.3’
jdk ’JDK_1.8.0_251’
}

På den maskin där testerna ska utföras är JDK 1.8.0_251 och Maven 3.6.3 installerade. Aliasnamnen maven och jdk pekar på respektive Maven- och JDK-versioner.

Steg 2: Miljödirektivet används för att definiera miljövariablerna PROJECT_DIR_1 och PROJECT_DIR_2 som pekar på den plats där Java-projekten finns. Dessa miljövariabler kan användas för alla steg eller stegspecifika steg eftersom de definieras i huvudsteget ”Run Tests”.’

1
2
3
4
5
6
stage {
stage(’Run Tests’) {
environment {
PROJECT_DIR_1 = ”C:\\Users\\Lenovo\IdeaProjects\\\Maven_Jenkins”
PROJECT_DIR_2 = ”C:\\Users\\Lenovo\\\IdeaProjects\\Maven_Jenkins_2”
}

Steg 3: Paralleldirektivet i Jenkins används för att köra Pipeline-stegen parallellt. I vårt fall består Jenkins Pipeline av två steg – testscenario 1 och testscenario 2.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
stages {
stage(’Run Tests’) {
environment {
PROJECT_DIR_1 = ”C:\\Users\\Lenovo\IdeaProjects\\\Maven_Jenkins”
PROJECT_DIR_2 = ”C:\\Users\\Lenovo\\\IdeaProjects\\Maven_Jenkins_2”
}
parallell {
stage(’Testscenario 1’) {
…………………………………..
…………………………………..
}
steg(’Testscenario 2’) {
…………………………………..
…………………………………..
}
}
}
}

Steg 4: De åtgärder som utförs i båda stegen är exakt likadana förutom att de utförs på olika projekt. Steg ”Test Scenario 1” utförs på noden ”Slave_1” och steg ”Test Scenario 2” utförs på noden ”Slave_2”.

1
2
3
4
5
6
7
8
9
10
11
parallell {
stage(’Testscenario 1’) {
agent {
etikett ”Slave_1”
}
………….
………….
stage(’Testscenario 2’) {
agent {
label ”Slave_2”
}

Om du har för avsikt att köra pipelinen på någon agent kan du hoppa över att använda ett visst agentnamn i dessa steg. Du kan hänvisa till vår blogg Vad är Jenkins för att förstå skapandet av noder i Jenkins.

I vårt fall skapade vi två noder (Slave_1 och Slave_2) och gjorde dem online innan vi körde testerna.

Steg 5: I nästa steg utlöses byggandet. Kommandot mvn clean install utförs då på pom.xml som finns i projektkatalogen. Vi använder en Windows-maskin för utförandet, därför har vi använt kommandot bat (eller batch) för att utlösa Maven-bygget.

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

Steg 6: Åtgärden efter byggandet används för att publicera HTML-rapporter för respektive steg. Åtgärderna läggs till under direktivet ”post”. Vi vill bara anropa skapandet av testrapporten om byggningen är framgångsrik. Därför ligger åtgärderna under success-direktivet.

Som framgår av demonstrationen med FreeStyle-projektet sätts reportDir till den plats där surefire-rapporter genereras (dvs. ${project_dir}/target/surefire-reports). Fältet reportFiles är inställt på index.html (dvs. ${project_dir}/target/surefire-reports/index.html).

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

När pipelinen har lagts till i Jenkinsfile klickar du på ”Build Now” (bygg nu) för att starta byggprocessen.

Du kan hovera över ett steg och klicka på ”Logs” (loggar) för att se hur utförandet går för just det steget. Som framgår av ögonblicksbilden av Stage exekveras de två stegen parallellt.

Då vi använder parallella steg med deklarativ pipeline i Jenkins exekveras respektive testfall parallellt på det molnbaserade Selenium-nätet på LambdaTest. Som framgår nedan stöder vår plan på LambdaTest högst fem tester som ska exekveras parallellt.

Som framgår nedan har testerna exekverats framgångsrikt.

Den totala exekveringstiden var cirka 6 minuter. Du kan hålla muspekaren över varje steg för att visa de loggar som är kopplade till det steget.

Som framgår av de förkortade loggarna är det uppenbart att stegen i de två stegen utfördes parallellt:

Här är en skärmdump av HTML-rapporterna som genereras som en del av åtgärden efter byggandet:

Varning

källa

Avkörning av Selenium-tester i Jenkins ger flexibiliteten att köra testerna varje gång en programvaruförändring görs, och dessa ändringar måste testas mot olika inmatningskombinationer. Maven används i Javaprojekt eftersom det underlättar hanteringen av beroenden genom pom.xml-filen.

Freestyle-projekt i Jenkins bör användas för projekt som inte är av hög komplexitet. Jenkins Pipeline bör användas när du vill definiera deployment Pipeline som kod. Parallelldirektivet i Jenkins Pipeline bör användas för att utnyttja den parallella utförandet av Stages i Jenkins. Jenkins Pipeline kan integreras med ett molnbaserat Selenium Grid som LambdaTest, som också låter dig integrera Maven och Jenkins med Selenium på ett mer effektivt sätt.

Vi hoppas att du genom att följa den här handledningen enkelt kan integrera Maven och Jenkins med Selenium. Tack för att du läste!

Himanshu Sheth

Med 7+ års erfarenhet av testautomatisering, BDD, TDD arbetar Himanshu Sheth som automationsingenjör på LambdaTest. Han är också en ivrig bloggare.

Skrivet av

Lämna ett svar

Din e-postadress kommer inte publiceras.