Selen WebDriver: TestNG For Test Case Management & Report Generation

I forrige blogg lærte jeg deg hvordan du kjører din første Selenium WebDriver-test. I denne bloggen vil jeg dekke avanserte Selenium WebDriver-konsepter. Jeg har allerede nevnt ganske mange ganger at Selenium WebDriver har begrensninger med hensyn til testsaksbehandling og generering av testrapporter. Så, hva er alternativet? Et så populært verktøy som Selen må definitivt ha en løsning, ikke sant? Det gjør det selvfølgelig! Vi kan bruke en kombinasjon av selen og TestNG for å slå denne begrensningen, og det vil være temaet for denne bloggs diskusjon.

hva er pojo om våren

I tilfelle du er ny på Selen, og vil ha en introduksjon til de grunnleggende konseptene, kan du starte reisen herfra: ? Imidlertid kan de andre komme i gang med TestNG for Selen fra denne bloggen.Du bør også vite at organisasjoner aktivt jakter på fagfolk med , noe som gjør det til en viktig ferdighet for programvaretestere å mestre.

Programvareutviklere fra hele verden vil enstemmig være enige i at det å skrive kode i testsaker sparer en god del av feilsøkingstiden. Hvorfor? Det er fordi testtilfeller hjelper til med å lage robust og feilfri kode. Hvordan gjør det det? Ved å bryte hele koden i mindre testsaker, og deretter ved å evaluere hver av disse testsakene for å bestå / mislykkes, kan vi lage feilfri kode. Siden Selen ikke støtter utførelse av kode i testtilfeller, må vi bruke TestNG for det samme. Dette er hvor TestNG passer inn i Selen-rammeverket.

TestNG står for Test neste generasjon og det er et open source-rammeverk for testautomatisering inspirert av JUnit og NUnit. Vel, ikke bare inspirert, men en oppgradering til de to rammene. Så du kan spørre hva er oppgraderingen her?Oppgraderingen med TestNG er at den gir ekstra funksjonalitet som: testkommentarer, gruppering, prioritering, parameterisering og sekvenseringsteknikker i koden som ikke var mulig tidligere.

I tillegg til å håndtere testsaker, kan til og med detaljerte rapporter om tester fås ved å bruke TestNG. Det vil være et sammendrag som viser testsaken som mislyktes, sammen med gruppen som den var en del av, og klassen den faller under. Når feil kan lokaliseres slik, kan de rettes umiddelbart til utvikleres lettelse. Bildet nedenfor viser hvordan TestNG fungerer.

Så hvordan får TestNG jobben gjort? Dette spørsmålet vil bli besvart ineste del av denne Selenium WebDriver-opplæringsbloggen, hvor jeg skal diskutere hvordan jeg kan håndtere forskjellige testsaker ved å bruke TestNG.

Selen WebDriver With TestNG

Testtilfeller kan defineres og håndteres på en av følgende måter:

1. Test merknader
2. Prioritering
3. Deaktivering av testtilfeller
4. Metodeavhengighet
5. Gruppering
6. Påstander
7. Rapportgenerering

La meg begynne å forklarehver av disse funksjonene.

Test merknader

La oss først stille oss dette spørsmålet: Hvorfor trenger vi å bruke kommentarer? Når kan vi bruke dem? Merknader i selen brukes til å kontrollere neste metode som skal utføres. Testkommentarer defineres før hver metode i testkoden. Hvis en metode ikke er prefikset med merknader, vil denne metoden ignoreres og ikke utføres som en del av testkoden. For å definere dem, må metodene bare kommenteres med ‘ @Test ‘. Se på kodebiten nedenfor for eksempel.

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 ugyldig myTestMethod () {System.out.println ('Inside method: - myTestMethod') WebDriver driver = new 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 kode utføres før metoden: - myTestMethod ') System.setProperty (' webdriver.gecko.driver ',' C: UsersVardhanworkspaceSeleniumProjectfilesgeckodriver.exe ')} @AfterMethod offentlig ugyldig etterMethod () {System.out.println (' Dette stykket av kode utføres etter metode: - myTestMethod ')} @BeforeClass public void beforeClass () {Syste m.out.println ('Denne koden utføres før klassen kjøres')} @AfterClass public void afterClass () {System.out.println ('Denne koden utføres etter at klassen er utført')} }

I koden ovenfor, ville du ha lagt merke til at jeg ikke har definert en ‘hoved’ metode. Imidlertid har jeg 5 andre metoder definert. De er 'myTestMethod', 'beforeMethod', 'afterMethod', 'beforeClass' og 'afterClass'. Legg også merke til rekkefølgen på definisjon av metoder i koden fordi de ikke blir utført i samme rekkefølge.

Metoden ‘myTestMethod’ er kommentert med @Test , og det er hovedmetoden eller kodestykket som må utføres. Andre merkede metoder vil bli utført før og etter at denne metoden er utført. Siden ‘beforeMethod’ er kommentert med @BeforeMethod , vil den bli utført før ‘myTestMethod’ kjøres. Tilsvarende er ‘afterMethod’ kommentert med @AfterMethod , og dermed vil den bli utført etter ‘myTestMethod’.

Imidlertid er ‘beforeClass’ kommentert med @BeforeClass , noe som betyr at den vil bli utført selv før klassen selv blir utført. Klassenavnet vårt her er Testkommentarer , og dermed før klassen begynner å bli henrettet, vil kodebiten inne i 'beforeClass' bli utført. Tilsvarende er ‘afterClass’ kommentert med @AfterMethod , og vil dermed bli henrettet etter klassen Testkommentarer blir henrettet.

Hvis du fremdeles har forvirring angående rekkefølgen for utførelse, vil utdraget nedenfor definitivt hjelpe deg.

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

Resultatet av koden ovenfor vil være:

Denne koden utføres før klassen kjøres Denne koden utføres før metoden: - myTestMethod Inside-metoden: - myTestMethod 1493192682118 geckodriver INFO Lytter på 127.0.0.1:13676 1493192682713 mozprofile :: profile INFO Bruker profilbane C: UsersVardhanAppDataLocalTemp emp .wGkcwvwXkl2y 1493192682729 geckodriver :: marionette INFO Starter nettleser C: Programfiler (x86) Mozilla Firefoxirefox.exe 1493192682729 geckodriver :: marionette INFO Koble til Marionette på localhost: 59792 [GPU 6152] ADVARSEL: pipefeil: 109: c: fil: /moz2_slave/m-rel-w32-00000000000000000000/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, linje 346 1493192688316 Marionette INFO Lytter på port 59792 26. april 2017 13:14:49 org. openqa.selenium.remote.ProtocolHandshake createSession INFO: Oppdaget dialekt: W3C JavaScript-feil: http://t.dtscout.com/i/?l=http%3A%2F%2Fwww.seleniumframework.com%2FPracticeform%2F&j=, linje 1: TypeError: document.getElementsByTagNa meg (...) [0] er udefinert Selen Framework | Practiceform 1493192695134 Marionette INFO Nye forbindelser vil ikke lenger bli akseptert 26. april 2017 13:14:57 org.openqa.selenium.os.UnixProcess ødelegger ALVOR: Kan ikke drepe prosessen med PID 6724 Denne koden utføres etter metode: - myTestMethod Denne koden utføres etter at klassen er utført PASSED: myTestMethod ====================================== ============ Standard test Testkjøring: 1, Feil: 0, Hopp over: 0 =========================== ====================================================== ===================== Standard suite Totalt antall test: 1, Feil: 0, Hopp over: 0 ================ ==================================

Som du kan se fra ovennevnte utgang, er antall testkjøringer 1 og mislyktes er 0. Dette betyr at koden er vellykket. Selv rekkefølgen for utførelse av metoder vil være i rekkefølgenJegnevnt tidligere.

Når du utfører denne koden på maskinen din, vil Selenium WebDriver instantiere Firefox-nettleseren din, navigere til Selenium Frameworks praksisskjema, lukke nettleserforekomsten og vise den samme utgangen som vist ovenfor i Eclipse IDE.

Jeg har bare brukt 5 forskjellige merknader i koden min. Men det er mange flere merknader som kan brukes til å kontrollere neste metode som skal utføres. Hele listen over merknader er forklart ibordunder:

@BeforeSuite - Metoden kommentert med @BeforeSuite vil kjøre før alle testene i suiten har kjørt.

@AfterSuite - Metoden kommentert med @AfterSuite vil kjøre etter at alle testene i suiten har kjørt.

@BeforeTest - Metoden kommentert med @BeforeTest kjøres før en testmetode som tilhører en klasse kjøres.

@AfterTest - Metoden kommentert med @AfterTest vil kjøre etter at alle testmetodene som tilhører en klasse har kjørt.

@BeforeGroup - Metoden kommentert med @BeforeGroup vil løpe før hver gruppe kjøres.

@AfterGroup - Metoden kommentert med @AfterGroup vil løpe etter at hver gruppe er kjørt.

@BeforeClass - Metoden kommentert med @BeforeClass kjøres en gang før den første testmetoden i gjeldende klasse påkalles.

@Etter timen - Metoden kommentert med @Etter timen vil kjøre en gang etter at alle testmetodene i gjeldende klasse har kjørt.

@BeforeMethod - Metoden kommentert med @BeforeMethod kjøres før en testmetode i en klasse kjøres.

@AfterMethod - Metoden kommentert med @AfterMethod kjøres etter at hver testmetode i en klasse er kjørt.

@Test - Metoden kommentert med @Test er den viktigste testmetoden i hele programmet. Andre merkede metoder vil bli utført rundt denne metoden.

Skjermbildet av TestNG-rapporten ertil stede nedenfor: -

Prioritering

Vi snakket om hvordan forskjellige metoder som kan defineres slik at de utføres rundt @Test metode. Men hva om du har mer enn en @Test metode og du vil definere kjøringsrekkefølgen mellom dem?

I så fall kan viPomorganisere dem ved å tilordne et nummer til de merkede testtilfellene. Mindre tall, jo høyere prioritet. Prioritet kan tildeles som parametere mens man definerer testtilfellene. Men hvis ingen prioritet er tildelt, vil de merkede testmetodene bli utført i henhold til den alfabetiske rekkefølgen til testene. Se på parametrene for testkommentarene i delen nedenforkode.

Linux-systemadministratorroller og ansvar

@Test (Priority = 2) public static void FirstTest () {system.out.println ('This is the Test Case number Two due of Priority # 2')} @Test (Priority = 1) public static void SecondTest () { system.out.println ('Dette er testsaken nummer ett på grunn av prioritet nr. 1')} @ Test offentlig statisk ugyldig FinalTest () {system.out.println ('Dette er den endelige testsaken fordi det ikke er noen prioritet' )}

Deaktivering av testtilfeller

La meg vise deg noe mer interessant. Hva om du har en kode som strekker seg over en million linjer, som består av hundrevis av testtilfeller, og du bare vil deaktivere en testmetode? Du trenger ikke å slette noen del av koden, i stedet, kan vi bare deaktivere den testmetoden.

Handlingen med å deaktivere en testsak gjøres også via parametere. Vi kan stille inn aktivert attributt til ‘falsk’. Som standard vil alle testtilfeller være aktivert, og derfor trenger vi ikke definere dem hver gang vi skriver en test. Se på parametrene til den tredje og fjerde metoden i delen nedenforkode.

@Test (Priority = 2, enabled = True) public static void FirstTest () {system.out.println ('This is the Test Case number Two due of Priority # 2')} @Test (Priority = 1, enabled = True ) 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 hoppede testsaken fordi dette er deaktivert')} @ Test (aktivert = Sann) offentlig statisk ugyldig FinalTest () {system.out.println ('Dette er den endelige testsaken, som er aktivert og har ingen prioritet ')}

Metodeavhengighet

Nå i tilfelle du har en situasjon der du vil at et stykke kode bare skal utføres hvis det tilfredsstiller en tilstand eller bare hvis en bestemt metode kjøres vellykket, kan vi gjøre det ved å bruke hangOnMethod (). Dette er i utgangspunktet en betingelse for metodeavhengighet der en metode vil bli utført avhengig av en annen metode. Hvis vi i tillegg setter kjør alltid attributt til true, så vil metoden bli utført uavhengig av fail / pass-tilstanden til den avhengige metoden. Se på koden i kodebiten nedenfor.

@Test offentlig statisk ugyldig FirstTest () {system.out.println ('Dette er den første testsaken som skal utføres')} @Test (dependsOnMethods = {'FirstTest'}) offentlig statisk ugyldig SecondTest () {system.out. println ('Dette er den andre testsaken som skal utføres Dette er en avhengig metode')} @Test (avhengerOnMethods = {'SecondTest'}) offentlig statisk ugyldig FinalTest () {system.out.println ('Dette er den siste testen Sak Det vil bli utført uansett. ')}

Nå tar dette oss til et annet viktig aspekt i testenmerknader som er Gruppering .

Gruppering

Nå må du vite at det vil være en rekke metoder som en del av testsaken vår i koden. La oss si at det er 100 testsaker, men vi vil bare utføre 20 testsaker i vår neste test. Tror du vi kan gjøre det? Så klart vi kan.

Vi kan bruke grupper attributt for dette formålet. Vi kan tilordne et gruppenavn til en rekke testsaker og senere velge å utføre gruppen i stedet for hele koden. Se på kodebiten nedenfor for å forståhvordan lage grupper.

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

TestNG påstander

Dette tar oss nå til neste emne i TestNG som er påstander. Som navnet antyder, kan påstander brukes i testmetoder for å bestemme bestått / ikke bestått tilstanden til en test. Basert på den sanne / falske tilstanden til en uttalelse, vil testene bestå / mislykkes.

I koden nedenfor har jeg tatt med 3 testmetoder, hvor den første og tredje metoden har bestått tilstand og den andre metoden vil ha en feiltilstand. 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 offentlig klasse påstander {@BeforeMethod offentlig ugyldig beforeMethod () {System.setProperty ('webdriver.gecko.driver', 'C: UsersVardhanworkspaceSeleniumProjectfilesgeckodriver.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 void 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 ('This is again a pass condition')} }

Når du ser på rapporten som blir generert etter denne utførelsen, vil du legge merke til at av de tre testene mislyktes en og to besto. Et annet viktig poeng å merke seg er at når en påstand mislykkes, vil andre kommandoer / kodelinjer i den testen bli hoppet over. Først når påstanden er vellykket, vil neste kodelinje bli utført i den testen. Sjekk utdataene nedenfor hvor system.out.println har bare utført for den første og tredje metoden.

1493277977348 geckodriver INFO Lytter på 127.0.0.1:47035 1493277977993 mozprofile :: profil INFO Bruker profilbane C: UsersVardhanAppDataLocalTemp ust_mozprofile.Z7X9uFdKODvi 1493277977994 geckodriver :: marionette INFO gtx779: BIOS-program: BIOS-program Koble til Marionette på localhost: 50758 [GPU 6920] ADVARSEL: rørfeil: 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 org.openqa.selenium.remote.ProtocolHandshake createSession INFO: Oppdaget dialekt: W3C Dette er igjen en bestått tilstand Dette er en bestått tilstand PASSERT: getTitle PASSED: testEquality1 FAILED: testEquality2 java.lang.AssertionError: expected [false] but found [true] at org.testng.Assert.fail (Assert.java:93) at org.testng.Assert.failNotEquals (Assert.java: 512) på org.testng.Assert.assertE qualsImpl (Assert.java:134) at org.testng.Assert.assertEquals (Assert.java:115) at org.testng.Assert.assertEquals (Assert.java:304) at org.testng.Assert.assertEquals (Assert.java : 314) ved testng.Assertions.testEquality2 (Assertions.java:38) ved sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (Ukjent kilde) ved sun.reflect.DelegatingMethodAc Source) at java.lang.reflect.Method.invoke (Unknown Source) at org.testng.internal.MethodInvocationHelper.invokeMethod (MethodInvocationHelper.java:108) at org.testng.internal.Invoker.invokeMethod (Invoker.java:661) på org.testng.internal.Invoker.invokeTestMethod (Invoker.java:869) på 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) på org.testng.TestRunner.privateRun (TestRunner.java:744) på ​​org.testng.TestRu nner.run (TestRunner.java:602) på org.testng.SuiteRunner.runTest (SuiteRunner.java:380) på org.testng.SuiteRunner.runSequentially (SuiteRunner.java:375) på 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) at org.testng.TestNG.runSuitesSequentially (TestNG.java:1301) at org.testng.TestNG.runSuitesLocally (TestNG.java:1226) at org.testng.TestNG.runSuites (TestNG.java:1144) at org.testng. TestNG.run (TestNG.java:1115) på org.testng.remote.AbstractRemoteTestNG.run (AbstractRemoteTestNG.java:132) på org.testng.remote.RemoteTestNG.initAndRun (RemoteTestNG.java:230) på org.testng.r .RemoteTestNG.main (RemoteTestNG.java:76) ============================================ ======== Standard test Testkjøring: 3, Feil: 1, Hopp over: 0 =============================== ===================================================== ================= Standardpakke Totalt antall kjøringer: 3, Feil: 1, Hopp over: 0 ======================================= ============

Så det er slutten på konseptene knyttet til testsaksbehandling. Vi sitter igjen med ett tema til, og det er rapportgenerering. Rapportgenerering er det siste emnet i denne Selenium WebDriver-opplæringen fordi rapporter bare kan genereres etter alttestene utføres.

java dobbel til int konvertering

Rapportgenerering

Det viktigste du må merke deg er at rapporten bare genereres via en .xml-fil. Dette betyr, det være seg en metode, eller det være en klasse, eller det være seg en gruppe som du vil teste, de må alle spesifiseres i .xml-filen.

Så først kan du opprette en ny mappe under prosjektet ditt, og opprette en ny fil i den mappen og gi et navn til filen og lagre den med .xml-utvidelsen. Du kan opprette den nye mappen og filen ved å høyreklikke på pakkeutforskeren. Når du har opprettet filen, går du til kildefanen nederst i vinduet og angir konfigurasjonene som spesifisert i utdraget nedenfor.

Den første linjen er definisjonen av XML-dokumenttype. Dette er standard og obligatorisk for alle testrapporter. Men de andre linjene er ganske selvforklarende. Jeg har brukt de åpne kodene for suite, test, klasser og klasser. Klasser tag kan ha en eller flere klasser inni seg. Dermed kan den brukes hvis vi vil generere en rapport der vi tester flere klasser. Dette er nyttig spesielt for utviklere som ønsker å teste et langt stykke kode.

Uansett å komme tilbake til rapporten vår, kan du gi navn til hver suite eller test eller klasse etter at du har åpnet disse kodene, og husk å lukke alle taggene du åpner. Jeg har gitt navnet på min suite som TestNGs , testnavn som Test Kommentarer og klassenavn som testng.TestAnnotations. Vær oppmerksom på at kursnavnet er i formatet ' packagename.classname ’ .

Når du kjører denne filen som TestNG suite, vil kjøringen starte og du vil få detaljerte testrapporter. Du får testutdataene i konsollfanen og resultatet av testpakken i neste fane. Rapporten som jeg har generert for å utføre koden min eriskjermbildet nedenfor. Du vil merke at denne gangen er det et suite navn, testnavn, klassenavn sammen med tiden det tar å utføre hver av dem.

I tilfelle du vil vise HTML-rapporten (indeksrapport eller rapport som kan sendes via e-post), kan du gå til test-utgang mappen inne i prosjektkatalogen i arbeidsområdet ditt. Ved å klikke på dem kan du se rapportene selv på et senere tidspunkt. Nedenfor er skjermbildene deres.

Indeksrapport : -

Rapport som kan sendes via e-post : -

Så det fører oss til slutten av denne Selenium WebDriver-opplæringsbloggen. Det er på tide for deg å sette opp formørkelse på slutten, installere de forskjellige Selen-pakkene, installere TestNG og komme i gang med å skrive testsaker.

Du kan sjekke ut Selenium WebDriver-opplæringsvideoen nedenfor for å være vitne til en demonstrasjon av de forskjellige konseptene som er forklart i denne bloggen.

Selenstrening | TestNG Framework For Selen | Edureka

Denne Edureka Selenium Training-videoen tar deg gjennom detaljene til Selenium WebDriver. Denne Selenium-opplæringsvideoen er ideell for både nybegynnere og fagpersoner som ønsker å pusse opp det grunnleggende i WebDriver-kommandoer og lære hvordan TestNG kan brukes med Selenium for å håndtere forskjellige testsaker.

Hvis du ønsker å lære selen og bygge en karriere i testdomenet, kan du sjekke ut vårt interaktive live-online her, som kommer med 24 * 7 støtte for å veilede deg gjennom hele læringsperioden.

Har du spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.