Selen WebDriver: TestNG til test case management og rapportgenerering

I den forrige blog lærte jeg dig, hvordan du kører din første Selenium WebDriver-test. I denne blog vil jeg dække avancerede Selenium WebDriver-koncepter. Jeg har allerede nævnt ganske mange gange, at Selenium WebDriver har begrænsninger med hensyn til testsagshåndtering og generering af testrapporter. Så hvad er alternativet? Et så populært værktøj som selen skal helt sikkert have en løsning, ikke? Det gør det selvfølgelig! Vi kan bruge en kombination af selen og TestNG til at slå denne begrænsning, og det vil være emnet for denne blogs diskussion.

servicenow tutorial for begyndere pdf

Hvis du er ny på Selen og vil have en introduktion til de grundlæggende begreber, kan du starte din rejse herfra: ? De andre kan dog komme i gang med TestNG for Selen fra denne blog.Du skal også vide, at organisationer aktivt jager efter professionelle med , hvilket gør det til en vigtig færdighed for softwaretestere at mestre.

Softwareudviklere fra hele verden er enstemmigt enige om, at skrivning af kode i testsager sparer en god del af deres fejlfindingstid. Hvorfor? Det skyldes, at testcases hjælper med at skabe robust og fejlfri kode. Hvordan gør det det? Ved at bryde hele koden i mindre testtilfælde og derefter ved at evaluere hver af disse testtilfælde for at bestå / mislykkes betingelser, kan vi oprette fejlfri kode. Da Selen ikke understøtter udførelse af kode i testsager, er vi nødt til at bruge TestNG til det samme. Det er her TestNG passer ind i Selenium-rammen.

TestNG står for Test næste generation og det er en open source testautomatiseringsramme inspireret af JUnit og NUnit. Nå, ikke bare inspireret, men en opgradering til disse to rammer. Så du kan spørge, hvad er opgraderingen her?Opgraderingen med TestNG er, at den giver yderligere funktionalitet som: testkommentarer, gruppering, prioritering, parameterisering og sekventeringsteknikker i koden, som ikke var mulig tidligere.

Udover styring af testsager kan selv detaljerede rapporter om test opnås ved hjælp af TestNG. Der vil være et resumé, der viser testsagen, der er mislykket, sammen med den gruppe, som den var en del af, og den klasse, det falder ind under. Når fejl kan lokaliseres nøjagtigt som denne, kan de rettes straks til lindring for udviklere. Nedenstående billede viser, hvordan TestNG fungerer.

Så hvordan får TestNG jobbet gjort? Dette spørgsmål vil blive besvaret idet næste afsnit af denne Selenium WebDriver-tutorial-blog, hvor jeg vil diskutere, hvordan man styrer forskellige testsager ved hjælp af TestNG.

Selen WebDriver med TestNG

Testcases kan defineres og styres på en af ​​følgende måder:

1. Testkommentarer
2. Prioritering
3. Deaktivering af testtilfælde
4. Metodeafhængighed
5. Gruppering
6. Påstande
7. Rapportgenerering

Lad mig begynde at forklarehver af disse funktionaliteter.

Testkommentarer

Lad os først og fremmest stille os dette spørgsmål: Hvorfor skal vi bruge kommentarer? Hvornår kan vi bruge dem? Kommentarer i selen bruges til at kontrollere den næste metode, der skal udføres. Testkommentarer defineres før hver metode i testkoden. Hvis en metode ikke er forud for annoteringer, ignoreres den metode og udføres ikke som en del af testkoden. For at definere dem skal metoder simpelthen kommenteres med ' @Prøve '. Se for eksempel nedenstående kodestykke.

pakke testng import org.openqa.selenium.WebDriver import org.openqa.selenium.firefox.FirefoxDriver import org.testng.annotations.AfterClass import org.testng.annotations.AfterMethod import org.testng.annotations.BeforeClass import org.testng.annotations .BeforeMethod importerer org.testng.annotations.Test offentlig klasse TestAnnotations {@Test public annullerer myTestMethod () {System.out.println ('Inde metode: - myTestMethod') WebDriver driver = ny FirefoxDriver () driver.get ('http: //www.seleniumframework.com/Practiceform/ ') String title = driver.getTitle () System.out.println (title) driver.quit ()} @BeforeMethod public void beforeMethod () {System.out.println (' This stykke kode udføres før metode: - myTestMethod ') System.setProperty (' webdriver.gecko.driver ',' C: UsersVardhanworkspaceSeleniumProjectfilesgeckodriver.exe ')} @AfterMethod offentlig ugyldig efterMethod () {System.out.println (' Dette stykke kode udføres efter metode: - myTestMethod ')} @BeforeClass offentlig ugyldig førClass () {Syste m.out.println ('Dette stykke kode udføres, før klassen udføres')} @AfterClass public void afterClass () {System.out.println ('Dette stykke kode udføres, efter at klassen er udført')} }

I ovenstående kode ville du have bemærket, at jeg ikke har defineret en 'hoved' metode. Jeg har dog defineret 5 andre metoder. De er 'myTestMethod', 'beforeMethod', 'afterMethod', 'beforeClass' og 'afterClass'. Bemærk også rækkefølgen af ​​definition af metoder i koden, fordi de ikke udføres i samme rækkefølge.

Metoden 'myTestMethod' er kommenteret med @Prøve , og det er hovedmetoden eller kodestykket, der skal udføres. Andre annoterede metoder udføres før og efter denne metode er udført. Da 'beforeMethod' er kommenteret med @BeforeMethod , det udføres, før 'myTestMethod' udføres. Tilsvarende er 'afterMethod' kommenteret med @AfterMethod , og således vil den blive udført efter 'myTestMethod'.

Imidlertid kommenteres 'beforeClass' med @BeforeClass , hvilket betyder, at det vil blive udført selv før klassen selv udføres. Vores klasse navn her er TestBemærkninger , og således før klassen begynder at blive eksekveret, udføres kodestykket inde i 'beforeClass'. Tilsvarende er 'afterClass' kommenteret med @AfterMethod , og således udføres efter klassen TestBemærkninger udføres.

Hvis du stadig har forvirring med hensyn til ordren til udførelse, så vil nedenstående uddrag helt sikkert hjælpe dig.

1. BeforeSuite 2. BeforeTest 3. BeforeClass 4. BeforeMethod 5. Test 6. AfterMethod 7. AfterClass 8. AfterTest 9. AfterSuite

Outputtet af ovenstående kode vil være:

Dette stykke kode udføres før klassen udføres Dette stykke kode udføres før metode: - myTestMethod Inde metode: - myTestMethod 1493192682118 geckodriver INFO Lytter på 127.0.0.1:13676 1493192682713 mozprofile :: profil INFO Brug af profilsti C: BrugereVardhanAppDataLocalTemp emp .wGkcwvwXkl2y 1493192682729 geckodriver :: marionette INFO Start browser C: Program Files (x86) Mozilla Firefoxirefox.exe 1493192682729 geckodriver :: marionette INFO Tilslutning til Marionette på localhost: 59792 [GPU 6152] ADVARSEL: rørfejl: 109: c: c: /moz2_slave/m-rel-w32-00000000000000000000/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 1493192688316 Marionette INFO Lytter på port 59792 26. april 2017 13:14:49 org. openqa.selenium.remote.ProtocolHandshake createSession INFO: Registreret dialekt: W3C JavaScript-fejl: http://t.dtscout.com/i/?l=http%3A%2F%2Fwww.seleniumframework.com%2FPracticeform%2F&j=, line 1: TypeError: document.getElementsByTagNa mig (...) [0] er udefineret Selen Framework | Practiceform 1493192695134 Marionette INFO Nye forbindelser accepteres ikke længere 26. april 2017 13:14:57 org.openqa.selenium.os.UnixProcess ødelæg ALVOR: Kan ikke dræbe processen med PID 6724 Dette stykke kode udføres efter metode: - myTestMethod Dette stykke kode udføres efter klassen er udført PASSED: myTestMethod ====================================== ============ Standard test Testkørsel: 1, Fejl: 0, Spring over: 0 ========================== ====================================================== ===================== Standard suite Samlede testkørsler: 1, Fejl: 0, Spring over: 0 ================ ==================================

Som du kan se fra ovenstående output, er antallet af testkørsler 1 og mislykkedes 0. Dette betyder, at koden er vellykket. Selv rækkefølgen af ​​udførelse af metoder vil være i rækkefølgenjegnævnt tidligere.

Når du udfører denne kode på din maskine, starter Selenium WebDriver din Firefox-browser, navigerer til Selenium Framework's praksisform, lukker browserinstansen og viser den samme output som vist ovenfor i din Eclipse IDE.

Jeg har kun brugt 5 forskellige kommentarer i min kode. Men der er mange flere kommentarer, som kan bruges til at kontrollere den næste metode, der skal udføres. Hele listen over kommentarer er forklaret ibordunder:

@BeforeSuite - Metoden kommenteret med @BeforeSuite kører, før alle testene i pakken er kørt.

@AfterSuite - Metoden kommenteret med @AfterSuite kører, når alle testene i pakken er kørt.

@BeforeTest - Metoden kommenteret med @BeforeTest kører, før en testmetode, der tilhører en klasse, køres.

@AfterTest - Metoden kommenteret med @AfterTest kører efter at alle testmetoder, der tilhører en klasse, er kørt.

@BeforeGroup - Metoden kommenteret med @BeforeGroup kører, før hver gruppe køres.

@AfterGroup - Metoden kommenteret med @AfterGroup kører efter hver gruppe er kørt.

@BeforeClass - Metoden kommenteret med @BeforeClass kører en gang, før den første testmetode i den aktuelle klasse påberåbes.

hvad er en java ide

@Efter skole - Metoden kommenteret med @Efter skole kører en gang, efter at alle testmetoder i den aktuelle klasse er kørt.

@BeforeMethod - Metoden kommenteret med @BeforeMethod kører, før en testmetode inde i en klasse køres.

@AfterMethod - Metoden kommenteret med @AfterMethod kører efter hver testmetode inde i en klasse er kørt.

@Prøve - Metoden kommenteret med @Prøve er den vigtigste testmetode i hele programmet. Andre annoterede metoder vil blive udført omkring denne metode.

Screenshotet af TestNG-rapporten ertil stede nedenfor: -

Prioritering

Vi talte om, hvordan forskellige metoder, der kan defineres, så de udføres omkring @Prøve metode. Men hvad hvis du har mere end en @Prøve metode, og du vil definere udførelsesordren mellem dem?

I så fald kan viPgenoplive dem ved at tildele et nummer til de kommenterede testsager. Jo mindre antallet er, jo højere prioritet. Prioritet kan tildeles som parametre, mens testsagerne defineres. Men hvis der ikke er tildelt nogen prioritet, vil de annoterede testmetoder blive udført efter testens alfabetiske rækkefølge. Se på parametrene for testkommentarerne i nedenstående stykkekode.

@Test (Prioritet = 2) offentlig statisk ugyldighed FirstTest () {system.out.println ('Dette er Test Case nummer to på grund af Prioritet # 2')} @Test (Prioritet = 1) offentlig statisk ugyldig SecondTest () { system.out.println ('Dette er test sag nummer et på grund af prioritet nr. 1')} @ Test offentlig statisk ugyldig FinalTest () {system.out.println ('Dette er den sidste test sag, fordi der ikke er nogen prioritet' )}

Deaktivering af testtilfælde

Lad mig vise dig noget mere interessant. Hvad hvis du har en kode, der spænder over en million linjer, der består af hundreder af testsager, og du kun vil deaktivere en testmetode? Du behøver ikke at slette nogen del af koden i stedet, kan vi simpelthen deaktivere denne testmetode.

Handlingen med at deaktivere en testsag udføres også via parametre. Vi kan indstille aktiveret attribut til 'falsk'. Som standard vil alle testcases være aktiveret, og derfor behøver vi ikke definere dem hver gang vi skriver en test. Se på parametrene for den tredje og fjerde metode i nedenstående stykkekode.

@Test (Prioritet = 2, aktiveret = Sand) offentlig statisk ugyldig FirstTest () {system.out.println ('Dette er test sag nummer to på grund af prioritet nr. 2')} @ Test (Prioritet = 1, aktiveret = Sand ) public static void SecondTest () {system.out.println ('This is the Test Case number One due to Priority # 1')} @Test (enabled = false) public static void SkippedTest () {system.out.println ( 'Dette er den springede test sag, fordi dette er blevet deaktiveret')} @ Test (aktiveret = Sand) offentlig statisk ugyldig FinalTest () {system.out.println ('Dette er den sidste test sag, som er aktiveret og har ingen prioritet ')}

Metodeafhængighed

I tilfælde af at du har en situation, hvor du kun vil udføre et stykke kode, hvis det opfylder en betingelse, eller kun hvis en bestemt metode udføres med succes, så kan vi gøre det ved at bruge afhænger af metode (). Dette er grundlæggende en betingelse for metodeafhængighed, hvor en metode udføres afhængigt af en anden metode. Hvis vi desuden indstiller kør altid attribut til sand, så vil metoden blive udført uanset fail / pass-tilstanden for den afhængige metode. Se på koden i nedenstående kodestykke.

@Test offentlig statisk ugyldig FirstTest () {system.out.println ('Dette er den første test sag, der skal udføres')} @Test (dependsOnMethods = {'FirstTest'}) offentlig statisk ugyldig SecondTest () {system.out. println ('Dette er den anden testtilfælde, der skal udføres Dette er en afhængig metode')} @Test (hangOnMethods = {'SecondTest'}) offentlig statisk ugyldig FinalTest () {system.out.println ('Dette er den sidste test Sag Det vil blive udført alligevel. ')}

Nu fører dette os til et andet vigtigt aspekt i testenkommentarer, som er Gruppering .

Gruppering

Nu skal du vide, at der vil være en række metoder som en del af vores testsag i koden. Lad os sige, at der er 100 testsager, men vi vil kun udføre 20 testsager i vores næste test. Tror du, vi kan gøre det? Selvfølgelig kan vi det.

Vi kan bruge grupper attribut til dette formål. Vi kan tildele et gruppenavn til et antal testsager og senere vælge at udføre gruppen i stedet for hele koden. Se på nedenstående kodestykke for at forståhvordan man opretter grupper.

@Test (grupper = {'MyGroup'}) offentlig statisk ugyldig FirstTest () {system.out.println ('Dette er en del af gruppen: MyGroup')} @Test (grupper = {'MyGroup'}) offentlig statisk ugyldigt SecondTest () {system.out.println ('Dette er også en del af gruppen: MyGroup')} @Test offentlig statisk ugyldig ThirdTest () {system.out.println ('Men dette er ikke en del af Gruppe: Min gruppe ')}

TestNG påstande

Dette fører os nu til det næste emne i TestNG, som er påstande. Som navnet antyder, kan påstande bruges i testmetoder til at bestemme en bestået / ikke-godkendt tilstand. Baseret på den sande / falske tilstand i en erklæring, vil testene bestå / mislykkes.

I nedenstående kode har jeg inkluderet 3 testmetoder, hvor den første og tredje metode har en godkendt tilstand, og den anden metode vil have en fejltilstand. Se koden selv.

pakke testng import org.testng.annotations.Test import org.testng.annotations.BeforeMethod import org.openqa.selenium.WebDriver import org.openqa.selenium.firefox.FirefoxDriver import org.testng.Assert import org.testng.annotations.AfterMethod offentlige klasse påstande {@BeforeMethod offentlig ugyldig førMethod () {System.setProperty ('webdriver.gecko.driver', 'C: BrugereVardhanworkspaceSeleniumProjectfilesgeckodriver.exe')} offentlig boolsk isEqual (int a, int b) {if (a == b ) {return true} else {return false}} @Test public void testEquality1 () {Assert.assertEquals (true, isEqual (10, 10)) System.out.println ('This is a pass condition')} @Test public ugyldig testEquality2 () {Assert.assertEquals (true, isEqual (10, 11)) System.out.println ('This is a fail condition')} @ Test public void getTitle () {WebDriver driver = new FirefoxDriver () driver. get ('https://www.gmail.com') String title = driver.getTitle () Assert.assertEquals (title, 'Gmail') System.out.println ('Dette er igen en godkendt betingelse')} }

Når du ser på rapporten, der genereres efter denne udførelse, vil du bemærke, at ud af de tre tests, en mislykkedes, og to bestod. Et andet vigtigt punkt at bemærke er, at når en påstand mislykkes, springes andre kommandoer / linjer med kode i denne test over. Først når påstanden er en succes, udføres den næste kodelinje i denne test. Tjek outputtet nedenfor hvor system.out.println har kun udført til den første og tredje metode.

1493277977348 geckodriver INFO Lytter på 127.0.0.1:47035 1493277977993 mozprofile :: profil INFO Brug af profilsti C: BrugereVardhanAppDataLocalTemp ust_mozprofile.Z7X9uFdKODvi 1493277977994 geckodriver :: marionette INFO gendan browser = Forbindelse til Marionette på localhost: 50758 [GPU 6920] ADVARSEL: rørfejl: 109: fil c: / builds / moz2_slave / m-rel-w32-00000000000000000000 / build / src / ipc / chromium / src / chrome / common / ipc_channel_win. cc, linje 346 1493277981742 Marionette INFO Lytter på port 50758 27. april 2017 12:56:22 PM org.openqa.selenium.remote.ProtocolHandshake createSession INFO: Registreret dialekt: W3C Dette er igen en godkendt betingelse Dette er en godkendt betingelse PASSED: getTitle PASSED: testEquality1 FAILED: testEquality2 java.lang.AssertionError: forventet [false] men fundet [true] ved org.testng.Assert.fail (Assert.java:93) ved org.testng.Assert.failNotEquals (Assert.java: 512) på org.testng.Assert.assertE qualsImpl (Assert.java:134) ved org.testng.Assert.assertEquals (Assert.java:115) ved org.testng.Assert.assertEquals (Assert.java:304) ved org.testng.Assert.assertEquals (Assert.java : 314) ved testng.Assertions.testEquality2 (Assertions.java:38) ved sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) ved sun.reflect.NativeMethodAccessorImpl.invoke (Ukendt kilde) ved sun.reflect.DelegatingMethodAccessor Kilde) på java.lang.reflect.Method.invoke (Ukendt kilde) ved org.testng.internal.MethodInvocationHelper.invokeMethod (MethodInvocationHelper.java:108) på org.testng.internal.Invoker.invokeMethod (Invoker.java:661) på org.testng.internal.Invoker.invokeTestMethod (Invoker.java:869) ved org.testng.internal.Invoker.invokeTestMethods (Invoker.java:1193) på org.testng.internal.TestMethodWorker.invokeTestMethods (Test.jethodWor ) på org.testng.internal.TestMethodWorker.run (TestMethodWorker.java:109) ved org.testng.TestRunner.privateRun (TestRunner.java:744) på ​​org.testng.TestRu nner.run (TestRunner.java:602) ved org.testng.SuiteRunner.runTest (SuiteRunner.java:380) ved org.testng.SuiteRunner.runSequentially (SuiteRunner.java:375) ved org.testng.SuiteRunner.privateRun (SuiteRunner .java: 340) på org.testng.SuiteRunner.run (SuiteRunner.java:289) på org.testng.SuiteRunnerWorker.runSuite (SuiteRunnerWorker.java:52) på org.testng.SuiteRunnerWorker.run (SuiteRunnerWorker.java:86) ved org.testng.TestNG.runSuitesSequentially (TestNG.java:1301) ved org.testng.TestNG.runSuitesLocally (TestNG.java:1226) ved org.testng.TestNG.runSuites (TestNG.java:1144) ved org.testng. TestNG.run (TestNG.java:1115) ved org.testng.remote.AbstractRemoteTestNG.run (AbstractRemoteTestNG.java:132) ved org.testng.remote.RemoteTestNG.initAndRun (RemoteTestNG.java:230) ved org.testng.r .RemoteTestNG.main (RemoteTestNG.java:76) =========================================== ======== Standard test Testkørsel: 3, Fejl: 1, Spring over: 0 ============================== ===================================================== ================ Standardpakke I alt testkørsel: 3, Fejl: 1, Spring over: 0 ======================================= =============

Så det er slutningen af ​​begreberne relateret til test sagsstyring. Vi står tilbage med endnu et emne, og det er generering af rapporter. Rapportgenerering er det sidste emne i denne Selenium WebDriver-tutorial, fordi rapporter kun kan genereres efter alttest udføres.

hvad er funktioner i sql

Rapportgenerering

Det vigtigste, du skal bemærke, er, at rapporten kun genereres via en .xml-fil. Det betyder, det være sig en metode, eller det være en klasse, eller det være sig en gruppe, som du vil teste, de skal alle angives i .xml-filen.

Så først kan du oprette en ny mappe under dit projekt og oprette en ny fil inde i den mappe og give filen et navn og gemme den med .xml-udvidelse. Du kan oprette den nye mappe og fil ved at højreklikke på pakkeudforskeren. Når du har oprettet filen, skal du gå til kilde-fanen nederst i vinduet og indtaste konfigurationerne som angivet i nedenstående uddrag.

Den første linje er definitionen af ​​XML-dokumenttype. Dette er standard og obligatorisk for alle testrapporter. Men de andre linjer er ret selvforklarende. Jeg har brugt de åbne tags til suite, test, klasser og klasse. Klasser tag kan have en eller flere klasser inde i det. Således kan den bruges, hvis vi vil generere en rapport, hvor vi tester flere klasser. Dette er praktisk især for udviklere, der ønsker at teste et langt stykke kode.

Under alle omstændigheder at komme tilbage til vores rapport, kan du navngive hver suite eller test eller klasse efter åbning af disse tags og huske at lukke hvert tag, du åbner. Jeg har givet mit suite navn som TestNG'er , testnavn som Prøve Kommentarer og klasse navn som testng.TestAnnotations. Bemærk, at holdnavnet er i formatet '' packagename.classname ’ .

Når du kører denne fil som TestNG-suite, starter udførelsen, og du får de detaljerede testrapporter. Du får testoutputtet i din konsolfane og resultatet af testpakken i den næste fane. Den rapport, jeg har genereret til udførelse af min kode, erinedenstående skærmbillede. Du vil bemærke, at denne gang er der et suite-navn, testnavn, klassenavn sammen med den tid, det tager at udføre hver af dem.

Hvis du vil se HTML-rapporten (indeksrapport eller e-mail-rapport), kan du gå til test-output mappe inde i projektmappen i dit arbejdsområde. Ved at klikke på dem kan du se rapporterne selv på et senere tidspunkt. Nedenfor er deres skærmbilleder.

Indeksrapport : -

E-mailbar rapport : -

Så det bringer os til slutningen af ​​denne Selenium WebDriver tutorial blog. Det er tid for dig at konfigurere formørkelse ved din afslutning, installere de forskellige Selenium-pakker, installere TestNG og komme i gang med at skrive dine testcases.

Du kan tjekke nedenstående Selenium WebDriver tutorial-video for at være vidne til en demonstration af de forskellige koncepter, der er forklaret i denne blog.

Selenstræning | TestNG Framework For Selen | Edureka

Denne Edureka Selenium-træningsvideo fører dig gennem de detaljerede detaljer i Selenium WebDriver. Denne Selenium-vejledningsvideo er ideel til både begyndere og fagfolk, der ønsker at opfriske det grundlæggende i WebDriver-kommandoer og lære, hvordan TestNG kan bruges med Selenium til styring af forskellige testsager.

Hvis du ønsker at lære selen og opbygge en karriere inden for testdomænet, så tjek vores interaktive live-online her kommer der 24 * 7 support til at guide dig gennem din læringsperiode.

Har du et spørgsmål til os? Nævn det i kommentarfeltet, og vi vender tilbage til dig.