Selēns WebDriver: TestNG testa gadījumu pārvaldībai un atskaišu ģenerēšanai



Šī Selenium WebDriver apmācība palīdzēs jums izprast nepieciešamību lietot TestNG kopā ar Selenium testa lietu pārvaldībai un detalizētu testa ziņojumu ģenerēšanai.

Iepriekšējā emuārā es iemācīju, kā palaist savu pirmo Selenium WebDriver testu. Šajā emuārā es aplūkošu uzlabotas Selenium WebDriver koncepcijas. Es jau vairākas reizes esmu minējis, ka Selenium WebDriver ir ierobežojumi attiecībā uz testa gadījumu pārvaldību un testa ziņojumu sagatavošanu. Tātad, kāda ir alternatīva? Tik populāram rīkam kā Selēns noteikti ir jābūt risinājumam? Protams, ka tā notiek! Mēs varam izmantot selēna un TestNG kombināciju, lai pārvarētu šo ierobežojumu, un tas būs šī emuāra diskusijas temats.

pārsūtīt failus uz EC2 Windows instanci

Gadījumā, ja jūs esat jauns Selenium lietotājs un vēlaties iepazīties ar pamatjēdzieniem, varat sākt savu ceļu šeit: ? Tomēr citi no šī emuāra var sākt darbu ar TestNG Selenium.Jums arī jāzina, ka organizācijas aktīvi medī profesionāļus , padarot to par programmatūras testētāju svarīgu prasmi apgūt.





Programmatūras izstrādātāji no visas pasaules vienprātīgi piekritīs, ka koda rakstīšana testa gadījumos ietaupa lielu daļu viņu atkļūdošanas laika. Kāpēc? Tas ir tāpēc, ka testa gadījumi palīdz izveidot izturīgu un bez kļūdām kodu. Kā tas to izdara? Sadalot visu kodu mazākos testa gadījumos un pēc tam, novērtējot katru no šiem testa gadījumiem, lai tie izturētu / neizturētu apstākļus, mēs varam izveidot kodu bez kļūdām. Tā kā selēns neatbalsta koda izpildi testa gadījumos, mums ir jāizmanto TestNG. Šeit TestNG iekļaujas selēna sistēmā.

TestNG apzīmē Pārbaudiet nākamo paaudzi un tā ir atvērtā koda testa automatizācijas sistēma, kuru iedvesmojuši JUnit un NUnit. Nu, ne tikai iedvesmots, bet arī šo divu sistēmu jauninājums. Tātad jūs varat jautāt, kas šeit ir jauninājums?Jaunināšana ar TestNG ir tāda, ka tā nodrošina papildu funkcionalitāti, piemēram: testa anotācijas, grupēšanu, prioritāšu noteikšanu, parametru noteikšanu un sekvencēšanas metodes kodā, kas agrāk nebija iespējams.



Papildus testa lietu pārvaldībai, izmantojot TestNG, var iegūt pat detalizētus pārskatus par testiem. Tiks izveidots kopsavilkums, kurā parādīts neveiksmīgais testa gadījums, kā arī grupa, kurā tā bija, un klase, kurā tā ietilpst. Kad kļūdas var precīzi atrast šādā veidā, tās var nekavējoties novērst, lai atvieglotu izstrādātājus. Zemāk redzamais attēls attēlo TestNG darbību.

testng - selēna tīmekļa draiveris

Tātad, kā TestNG paveic darbu? Uz šo jautājumu tiks atbildētsšī Selenium WebDriver apmācības emuāra nākamo sadaļu, kur es apspriedīšu, kā pārvaldīt dažādus testa gadījumus, izmantojot TestNG.



Selēna WebDriver ar TestNG

Testa gadījumus var definēt un pārvaldīt vienā no šiem veidiem:

  1. Pārbaudīt anotācijas
  2. Prioritāšu noteikšana
  3. Testa lietu atspējošana
  4. Metodes atkarība
  5. Grupēšana
  6. Apgalvojumi
  7. Pārskatu ģenerēšana

Ļaujiet man sākt skaidrotkatra no šīm funkcijām.

Pārbaudīt anotācijas

Vispirms uzdosim sev šo jautājumu: kāpēc mums ir jāizmanto anotācijas? Kad mēs tos varam izmantot? Anotācijas selēnā tiek izmantotas, lai kontrolētu nākamo izpildāmo metodi. Testa anotācijas ir definētas pirms katras testa koda metodes. Gadījumā, ja kāda no metodēm nav prefiksēta ar anotācijām, šī metode tiks ignorēta un netiks izpildīta kā testa koda sastāvdaļa. Lai tās definētu, metodes vienkārši jāpapildina ar “ @Pārbaude “. Apskatiet, piemēram, zemāk esošo koda fragmentu.

pakete testng import org.openqa.selenium.WebDriver importēt org.openqa.selenium.firefox.FirefoxDriver importēt org.testng.annotations.AfterClass importēt org.testng.annotations.AfterMethod importēt org.testng.annotations.BeforeClass importēt org.testng.annotations .BeforeMethod importējiet org.testng.annotations.Test publiskā klase TestAnnotations {@Test public void 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 (' Šis koda gabals tiek izpildīts pirms metodes: - myTestMethod ') System.setProperty (' webdriver.gecko.driver ',' C: UsersVardhanworkspaceSeleniumProjectfilesgeckodriver.exe ')} @AfterMethod public void afterMethod () {System.out.println (' Šis gabals Kods tiek izpildīts pēc metodes: - myTestMethod ')} @BeforeClass public void beforeClass () {Syste m.out.println ('Šis koda gabals tiek izpildīts pirms klases izpildes')} @AfterClass public void afterClass () {System.out.println ('Šis koda gabals tiek izpildīts pēc klases izpildes')} }

Iepriekš minētajā kodā jūs būtu pamanījis, ka es neesmu definējis ‘galveno’ metodi. Tomēr man ir definētas 5 citas metodes. Tie ir “myTestMethod”, “beforeMethod”, “afterMethod”, “beforeClass” un “afterClass”. Ievērojiet arī metožu definēšanas secību kodā, jo tās netiks izpildītas tādā pašā secībā.

Metode ‘myTestMethod’ ir anotēta @Pārbaude , un tā ir galvenā metode vai koda daļa, kas jāpilda. Citas anotētās metodes tiks izpildītas pirms un pēc šīs metodes izpildes. Tā kā ‘beforeMethod’ ir anotēts ar @BeforeMethod , tas tiks izpildīts pirms ‘myTestMethod’ izpildes. Līdzīgi “afterMethod” tiek anotēts ar @PēcMetode , un tādējādi tas tiks izpildīts pēc ‘myTestMethod’.

Tomēr ‘beforeClass’ ir anotēts ar @BeforeClass , kas nozīmē, ka tas tiks izpildīts pat pirms pašas klases izpildes. Mūsu klases nosaukums šeit ir TestAnnotations , un līdz tam, pirms klase sāk izpildīt, tiks izpildīts koda fragments iekšā “beforeClass”. Līdzīgi “afterClass” tiek anotēts ar @PēcMetode , un tādējādi tiks izpildīts pēc klases TestAnnotations tiek izpildīts.

Ja jums joprojām ir neskaidrības par izpildes kārtību, tālāk sniegtais fragments jums noteikti palīdzēs.

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

Iepriekš minētā koda izeja būs:

Šis koda gabals tiek izpildīts pirms klases izpildes Šis koda gabals tiek izpildīts pirms metodes: - myTestMethod Inside metode: - myTestMethod 1493192682118 geckodriver INFO Klausīšanās vietnē 127.0.0.1:13676 1493192682713 mozprofile :: profile INFO Izmantojot profila ceļu C: UsersVardhanPofileDataLocmoz .wGkcwvwXkl2y 1493192682729 geckodriver :: marionette INFO Pārlūkprogrammas C palaišana: Program Files (x86) Mozilla Firefoxirefox.exe 1493192682729 geckodriver :: marionette INFO Savienojuma izveide ar Marionette vietnē localhost: 59792 [GPU 6152] Build: faila kļūda: 109 /moz2_slave/m-rel-w32-0000000000000000000000/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 1493192688316 Marionette INFO Klausīšanās portā 59792 2017. gada 26. aprīlī 1:14:49 PM org. openqa.selenium.remote.ProtocolHandshake createSession INFO: Atklāts dialekts: W3C JavaScript kļūda: http://t.dtscout.com/i/?l=http%3A%2F%2Fwww.seleniumframework.com%2FPracticeform%2F&j=, line 1: TypeError: document.getElementsByTagNa es (...) [0] nav definēts Selenium Framework | Practiceform 1493192695134 Marionette INFO Jauni savienojumi vairs netiks pieņemti 2017. gada 26. aprīlī 13:14:57 org.openqa.selenium.os.UnixProcess iznīcināt SEVERE: Nevar nogalināt procesu ar PID 6724. Šis koda gabals tiek izpildīts pēc metodes: - myTestMethod Šis koda fragments tiek izpildīts pēc klases izpildes PASSED: myTestMethod ===================================== ============ Noklusējuma testa testi: 1, neveiksmes: 0, izlaišana: 0 ========================= ======================= ============================= ==================== Noklusējuma komplekts Kopējais testu skaits: 1, Neveiksmes: 0, Izlaišana: 0 =============== ================================

Kā redzams no iepriekš minētās izejas, testu skaits ir 1, bet neizdevās - 0. Tas nozīmē, ka kods ir veiksmīgs. Pat metožu izpildes kārtība būs tādā secībāEsminēts iepriekš.

Kad jūs izpildāt šo kodu savā datorā, Selenium WebDriver veiks jūsu Firefox pārlūka darbību, pārejiet uz Selenium Framework prakses formu, aizveriet pārlūka instanci un parādīs to pašu izvadi, kas parādīts iepriekš jūsu Eclipse IDE.

Es savā kodā esmu izmantojis tikai 5 dažādas anotācijas. Bet ir daudz vairāk anotāciju, kuras var izmantot, lai kontrolētu nākamo izpildāmo metodi. Viss anotāciju saraksts ir izskaidrotstabulazemāk:

@BeforeSuite - Metode anotēta ar @BeforeSuite darbosies, pirms visi komplekta testi būs izpildīti.

@AfterSuite - Metode anotēta ar @AfterSuite darbosies pēc visu komplekta testu izpildīšanas.

@BeforeTest - Metode anotēta ar @BeforeTest darbosies, pirms tiek palaista jebkura klases metode.

@AfterTest - Metode anotēta ar @AfterTest darbosies pēc tam, kad būs izpildītas visas klasē ietilpstošās testa metodes.

@PirmsGroup - Metode anotēta ar @PirmsGroup darbosies pirms katras grupas palaišanas.

@PēcGrupa - Metode anotēta ar @PēcGrupa darbosies pēc katras grupas palaišanas.

@BeforeClass - Metode anotēta ar @BeforeClass darbosies vienu reizi, pirms tiek izmantota pirmā testa metode pašreizējā klasē.

@Pēcstundas - Metode anotēta ar @Pēcstundas darbosies vienu reizi pēc tam, kad būs izpildītas visas testa metodes pašreizējā klasē.

@BeforeMethod - Metode anotēta ar @BeforeMethod darbosies, pirms tiek palaista jebkura testa metode klases iekšienē.

@PēcMetode - Metode anotēta ar @PēcMetode darbosies pēc katras klases testa metodes.

@Pārbaude - Metode anotēta ar @Pārbaude ir galvenā testa metode visā programmā. Ap šo metodi tiks izpildītas citas anotētās metodes.

Pārskata TestNG ekrānuzņēmums irklāt zemāk: -

Prioritāšu noteikšana

Mēs runājām par to, kā dažādas metodes, kuras var definēt tā, lai tās tiktu izpildītas ap @Pārbaude metodi. Bet ko darīt, ja jums ir vairāk nekā viens @Pārbaude metodi un vēlaties definēt izpildes kārtību starp tām?

Tādā gadījumā mēs varamPrioritizējiet tos, piešķirot numuru anotētajām pārbaudes lietām. Mazāks skaits, augstāka prioritāte. Nosakot testa gadījumus, prioritāti var piešķirt kā parametrus. Bet, ja prioritāte netiek piešķirta, anotētās testa metodes tiks izpildītas saskaņā ar testu alfabētisko secību. Apskatiet testa anotāciju parametrus zemākkods.

@Test (Prioritāte = 2) public static void FirstTest () {system.out.println ('Šis ir 2. gadījums, jo 2. prioritātes dēļ ir otrais gadījums')} @Test (Priority = 1) public static void SecondTest () { system.out.println ('Šis ir 1. gadījums, jo ir prioritāte Nr. 1')} @Test public static void FinalTest () {system.out.println ('Šī ir pēdējā testa lieta, jo nav prioritātes') )}

Testa lietu atspējošana

Ļaujiet man jums parādīt kaut ko interesantāku. Ko darīt, ja jums ir kods, kas aptver miljonu rindu un sastāv no simtiem testa gadījumu, un vēlaties atspējot tikai vienu testa metodi? Tā vietā jums nav jāizdzēš neviena koda daļa, mēs vienkārši varam atspējot šo testa metodi.

Pārbaudes gadījuma atspējošana notiek arī ar parametru palīdzību. Mēs varam iestatīt iespējots atribūtam “nepatiesa”. Pēc noklusējuma visi testa gadījumi būs iespējoti, tāpēc mums tie nav jādefinē katru reizi, kad rakstām testu. Apskatiet trešās un ceturtās metodes parametrus zemākkods.

@Test (Prioritāte = 2, iespējots = True) publiskais statiskais anulējums FirstTest () {system.out.println ('Šis ir 2. gadījums, jo 2. prioritāte ir prioritāte')} @Test (Prioritāte = 1, iespējots = True ) public static void SecondTest () {system.out.println ('Šis ir 1. testa gadījums 1. prioritātes dēļ')} @Test (iespējots = nepatiesa) public static void SkippedTest () {system.out.println ( 'Šis ir izlaists testa gadījums, jo tas ir atspējots')} @Test (iespējots = True) public static void FinalTest () {system.out.println ('Šī ir pēdējā testa lieta, kas ir iespējota un kurai nav prioritātes ')}

Metodes atkarība

Tagad, ja jums ir situācija, ka vēlaties, lai koda fragments tiktu izpildīts tikai tad, ja tas atbilst nosacījumam vai tikai tad, ja konkrēta metode tiek veiksmīgi izpildīta, tad mēs to varam izdarīt, izmantojot atkarīgsOnMethod (). Būtībā tas ir metodes atkarības nosacījums, kad metode tiks izpildīta atkarībā no citas metodes. Ja mēs papildus iestatītu alwaysRun atribūtu true, tad metode tiks izpildīta neatkarīgi no izvēlētās metodes fail / pass nosacījuma. Apskatiet kodu zemāk esošajā koda fragmentā.

@Test public static void FirstTest () {system.out.println ('Šis ir pirmais izpildāmais testa gadījums')} @Test (atkarīgsOnMethods = {'FirstTest'}) public static void SecondTest () {system.out. println ('Šis ir otrais testa gadījums, kas jāizpilda. Šī ir atkarīgā metode')} @Test (atkarīgsOnMethods = {'SecondTest'}) public static void FinalTest () {system.out.println ('Šis ir pēdējais tests Lieta Tas tik un tā tiks izpildīts. ')}

Tagad tas mūs noved pie vēl viena svarīga testa aspektaanotācijas, kas ir Grupēšana .

Grupēšana

Tagad jums jāzina, ka kodā būs vairākas metodes kā daļa no mūsu testa gadījuma. Pieņemsim, ka ir 100 testa gadījumu, bet nākamajā testā mēs vēlamies izpildīt tikai 20 testa gadījumus. Vai jūs domājat, ka mēs to varam? Protams mēs varam.

ko vārda telpa nozīmē c ++

Mēs varam izmantot grupas šim nolūkam. Mēs varam piešķirt grupas nosaukumu vairākiem testa gadījumiem un vēlāk izvēlēties grupas izpildi visa koda vietā. Lai saprastu, skatiet zemāk redzamo koda fragmentukā izveidot grupas.

@Test (groups = {'MyGroup'}) public static void FirstTest () {system.out.println ('Šī ir grupas daļa: MyGroup')} @Test (groups = {'MyGroup'}) publiskā statika void SecondTest () {system.out.println ('Šī ir arī grupas daļa: MyGroup')} @Test public static void ThirdTest () {system.out.println ('Bet šī nav daļa no Grupa: Mana grupa ')}

TestNG apgalvojumi

Tagad mēs nonākam pie nākamās TestNG tēmas, kas ir apgalvojumi. Kā norāda nosaukums, apgalvojumus var izmantot testa metodēs, lai noteiktu testa izturēšanas / neizturēšanas nosacījumu. Pamatojoties uz apgalvojuma patieso / nepatieso nosacījumu, testi izturēs / neizdosies.

Zemāk esošajā kodā esmu iekļāvis 3 testa metodes, kur pirmajai un trešajai metodei ir nokārtots nosacījums, bet otrajai metodei - neizdošanās nosacījums. Skatiet kodu pats.

pakete 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 publiskās klases apgalvojumi {@BeforeMethod public void beforeMethod () {System.setProperty ('webdriver.gecko.driver', 'C: UsersVardhanworkspaceSeleniumProjectfilesgeckodriver.exe')} public boolean 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 ('Šis ir caurlaides nosacījums')} @ Pārbaudīt publiski void testEquality2 () {Assert.assertEquals (true, isEqual (10, 11)) System.out.println ('Šis ir kļūmes stāvoklis')} @Test public void getTitle () {WebDriver draiveris = jauns FirefoxDriver () draiveris. get ('https://www.gmail.com') virknes nosaukums = driver.getTitle () Assert.assertEquals (nosaukums, 'Gmail') System.out.println ('Šis atkal ir caurlaides nosacījums')} }

Aplūkojot pārskatu, kas tiek ģenerēts pēc šīs izpildes, pamanīsit, ka no trim testiem viens neizdevās un divi izturēja. Vēl viens svarīgs aspekts, kas jāņem vērā, ir tāds, ka, neapgalvojot apgalvojumu, citas testa komandas / koda rindas tiks izlaistas. Tikai tad, kad apgalvojums būs veiksmīgs, šajā testā tiks izpildīta nākamā koda rinda. Pārbaudiet izeju zemāk, kur system.out.println ir izpildījis tikai pirmo un trešo metodi.

1493277977348 geckodriver INFO klausīšanās vietnē 127.0.0.1:47035 1493277977993 mozprofile :: profile INFO Profila ceļa C izmantošana: UsersVardhanAppDataLocalTemp ust_mozprofile.Z7X9uFdKODvi 1493277977994 pārlūkprogramma geckodriveres :: marionette INFO :: Marionette INFO :: Marionette INFO Savienojuma izveide ar Marionette vietnē localhost: 50758 [GPU 6920] BRĪDINĀJUMS: caurules kļūda: 109: fails c: / builds / moz2_slave / m-rel-w32-000000000000000000000000 / build / src / ipc / chromium / src / chrome / common / ipc_channel_win. cc, line 346 1493277981742 Marionette INFO Klausīšanās ostā 50758 2017. gada 27. aprīlī 12:56:22 org.openqa.selenium.remote.ProtocolHandshake createSession INFO: Atklāts dialekts: W3C Tas atkal ir atbilstošs nosacījums. getTitle PASSED: testEquality1 FAILED: testEquality2 java.lang.AssertionError: paredzams [nepatiess], bet atrasts [true] vietnē org.testng.Assert.fail (Assert.java:93) vietnē org.testng.Assert.failNotEquals (Assert.java: 512) vietnē org.testng.Assert.assertE qualsImpl (Assert.java:134) pie org.testng.Assert.assertEquals (Assert.java:115) pie org.testng.Assert.assertEquals (Assert.java:304) vietnē org.testng.Assert.assertEquals (Assert.java : 314) vietnē testng.Assertions.testEquality2 (Assertions.java:38) vietnē sun.reflect.NativeMethodAccessorImpl.invoke0 (vietējā metode) vietnē sun.reflect.NativeMethodAccessorImpl.invoke (nezināms avots) vietnē sun.reflect.DinegorMethod Avots) vietnē java.lang.reflect.Method.invoke (Nezināms avots) vietnē org.testng.internal.MethodInvocationHelper.invokeMethod (MethodInvocationHelper.java:108) vietnē org.testng.internal.Invoker.invokeMethod (Invoker.java:66) vietnē org.testng.internal.Invoker.invokeTestMethod (Invoker.java:869) vietnē org.testng.internal.Invoker.invokeTestMethods (Invoker.java:1193) vietnē org.testng.internal.TestMethodWorker.invokeTestMethods (TestTetMethods) ) vietnē org.testng.internal.TestMethodWorker.run (TestMethodWorker.java:109) vietnē org.testng.TestRunner.privateRun (TestRunner.java:744) vietnē org.testng.TestRu nner.run (TestRunner.java:602) vietnē org.testng.SuiteRunner.runTest (SuiteRunner.java:380) vietnē org.testng.SuiteRunner.runSequential (SuiteRunner.java:375) vietnē org.testng.SuiteRunner.privateRun (SuiteRunn .java: 340) vietnē org.testng.SuiteRunner.run (SuiteRunner.java:289) vietnē org.testng.SuiteRunnerWorker.runSuite (SuiteRunnerWorker.java:52) vietnē org.testng.SuiteRunnerWorker.run (SuiteRunnerWorker.ja vietnē org.testng.TestNG.runSuitesSequential (TestNG.java:1301) vietnē org.testng.TestNG.runSuitesLocally (TestNG.java:1226) vietnē org.testng.TestNG.runSuites (TestNG.java:1144) vietnē org.testng. TestNG.run (TestNG.java:1115) vietnē org.testng.remote.AbstractRemoteTestNG.run (AbstractRemoteTestNG.java:132) vietnē org.testng.remote.RemoteTestNG.initAndRun (RemoteTestNG.java:230) vietnē org.testng .RemoteTestNG.main (RemoteTestNG.java:76) ======================================= ======== Noklusējuma testa testi: 3, neveiksmes: 1, izlaišana: 0 ============================= =================== ================================= ================ Noklusējuma komplekts Kopējais testu skaits: 3, Neveiksmes: 1, Izlaišana: 0 ===================================== ============

Tātad, tas ir jēdzienu gals, kas saistīts ar testa gadījumu pārvaldību. Mums paliek vēl viena tēma, proti, atskaišu veidošana. Pārskatu veidošana ir pēdējā tēma šajā Selenium WebDriver apmācībā, jo pārskatus var izveidot tikai pēc visiemtesti tiek veikti.

ir pēcdiploma students un apgūst to pašu

Pārskatu ģenerēšana

Vissvarīgākais, kas jums jāņem vērā, ir tas, ka pārskats tiks ģenerēts tikai ar .xml failu. Tas nozīmē, vai tā būtu metode, vai tā būtu klase, vai grupa, kuru vēlaties pārbaudīt, tās visas ir jānorāda .xml failā.

Tātad vispirms jūs varat izveidot jaunu mapi zem sava projekta un izveidot jaunu failu tajā mapē un piešķirt failam nosaukumu un saglabāt to ar paplašinājumu .xml. Jauno mapi un failu varat izveidot, ar peles labo pogu noklikšķinot uz pakotņu pārlūka. Kad esat izveidojis failu, loga apakšdaļā dodieties uz cilni avots un ievadiet konfigurācijas, kā norādīts zemāk esošajā fragmentā.

 

Pirmā rinda ir XML dokumenta veida definīcija. Tas ir standarts un obligāts visiem testa ziņojumiem. Bet pārējās rindas ir diezgan pašsaprotamas. Esmu izmantojis atvērtos tagus komplektiem, testiem, nodarbībām un klasēm. Klases tagā var būt viena vai vairākas klases. Tādējādi to var izmantot, ja mēs vēlamies izveidot pārskatu, kurā mēs pārbaudām vairākas klases. Tas ir ērti īpaši izstrādātājiem, kuri vēlas pārbaudīt garu koda fragmentu.

Jebkurā gadījumā atgriežoties pie mūsu ziņojuma, pēc šo tagu atvēršanas varat nosaukt katru komplektu, testu vai klasi un atcerieties aizvērt katru atvērto tagu. Esmu devis savu komplekta nosaukumu kā TestNGs , testa nosaukums kā Pārbaude Anotācijas un klases nosaukums kā testng.TestAnnotations. Ņemiet vērā, ka klases nosaukums ir formātā ' packagename.classname ” .

Palaižot šo failu kā TestNG komplektu, tiks sākta izpilde, un jūs saņemsiet detalizētus testa ziņojumus. Pārbaudes rezultātu jūs saņemsiet konsoles cilnē un testa komplekta rezultātu nākamajā cilnē. Ziņojums, ko esmu izveidojis sava koda izpildei, iriekšāzemāk redzamais ekrānuzņēmums. Jūs ievērosiet, ka šoreiz ir komplekta nosaukums, testa nosaukums, klases nosaukums, kā arī laiks, kas vajadzīgs katra no tiem.

Gadījumā, ja vēlaties skatīt HTML pārskatu (Index report vai Emailable-report), varat doties uz testa rezultāts darba mapē projekta direktorijā. Noklikšķinot uz tiem, jūs varat apskatīt pārskatus pat vēlāk. Zemāk ir viņu ekrānuzņēmumi.

Indeksa ziņojums : -

Nosūtīt ziņojumu pa e-pastu : -

Tādējādi mēs nonākam līdz šī Selenium WebDriver apmācības emuāra beigām. Ir pienācis laiks iestatīt aptumsumu savā galā, instalēt dažādas Selenium paketes, instalēt TestNG un sākt rakstīt savus testa gadījumus.

Jūs varat apskatīt tālāk sniegto Selenium WebDriver apmācības video, lai redzētu dažādus šajā emuārā izskaidrotos jēdzienus.

Selēna apmācība Selēna testNG ietvars | Edureka

Šis Edureka Selenium Training video iepazīstinās jūs ar padziļinātu informāciju par Selenium WebDriver. Šis Selenium apmācības video ir ideāli piemērots gan iesācējiem, gan profesionāļiem, kuri vēlas pilnveidot WebDriver komandu pamatus un uzzināt, kā TestNG var izmantot kopā ar Selen, lai pārvaldītu dažādus testa gadījumus.

Ja vēlaties uzzināt selēnu un veidot karjeru testēšanas jomā, apskatiet mūsu interaktīvo tiešsaistes tiešraidi šeit ir pieejams 24 * 7 atbalsts, kas palīdzēs jums visu mācību laiku.

Vai mums ir jautājums? Lūdzu, pieminējiet to komentāru sadaļā, un mēs ar jums sazināsimies.