Meny

Topp 10 selen unntak og hvordan du håndterer disse (nøyaktig kode)

top 10 selenium exceptions

Prøv Instrumentet Vårt For Å Eliminere Problemer

Håndtering av Selen WebDriver-unntak ved hjelp av rammeverk for unntakshåndtering - Opplæring i Selenium # 19

Å få et unntak i automatiseringskode er veldig vanlig. ‘Unntak’ som ordet indikerer, er et spesielt eller uvanlig tilfelle.

Utførelse av automatiseringskode kan vanligvis ikke utføres som forventet på grunn av mange faktorer involvert i utførelse, for eksempel nettverksstabilitetsproblemer, Internettproblemer, serverstabilitet osv. Vi kan få unntak på grunn av utilstrekkelig ventetid eller feil syntakser, parametere etc.

Unntakshåndtering i Selen 2

I den siste opplæringen til WebDriver lærte vi om tre forskjellige typer viktige webelementer som Webtabeller, rammer og dynamiske elementer og deres håndteringsmekanismer i selenskript

Før du går videre med Framework tutorials i dette Selen trening serien, her i denne opplæringen vil vi lære om typer unntak og hvordan man håndterer unntak i Java og Selenium-skript . Utviklere / testere bruker rammeverk for unntakshåndtering for å håndtere et unntak i selenskript.

Hva du vil lære:

Hva er et unntak?

Unntak er hendelser som skyldes at Java-programmet slutter brått uten å gi forventet produksjon. Java gir et rammeverk der en bruker kan håndtere unntak.

Prosessen med å håndtere unntak kalles unntaksbehandling.

Unntak må håndteres fordi de bryter normal gjennomføring av et program. En av de viktigste intensjonene med unntaksbehandling er å forhindre dette bruddet og fortsette programutførelsen. Noen ganger kan det være lurt å utføre noen serie handlinger for å oppstå med et bestemt unntak.

Når et unntak oppstår, opprettes et unntaksobjekt som teknisk kalles ‘ Kaster et unntak ’ og vi legger til Prøv / fange blokker som,

try { // Protected code } catch (ExceptionName e) { // Catch block }

#1) Kodestykket som kan kaste et unntak legges til i prøveblokken.

#to) Catch-setningen fanger unntaket og tar det som en parameter.

# 3) Når det ikke kastes noe unntak, blir prøveerklæringen utført og ikke fangstuttalelsen.

Eksempel : Når selen-skript mislykkes på grunn av feil locator, bør utvikleren kunne forstå årsaken til feilen, og dette kan lett oppnås hvis unntaket håndteres riktig i programmet.

Etter min erfaring er det best å prøve å unngå WebDriver-unntak når det er mulig og fange virkelig unntakstilfeller. Bruk prøve / fangst til å håndtere ting som går galt og er utenfor min kontroll.

Unngå de jeg kan fange andre!

Dette er den beste strategien som har fungert for meg.

For eksempel, vurdere en testside som tar mer enn vanlig tid å laste på en testserver. Vi vil få hyppige unntak mens vi gjør handlinger på denne siden. Så, i stedet for bare å fange dette hver gang, kan vi

  • Legg til en ventekommando og prøv å unngå et unntak
  • Bruk 'Try / Catch' for å håndtere i tilfelle det har oppstått en virkelig eksepsjonell sak

Dermed reduserer sjansen for unntak.

Unntak i selen webdriver

Fordeler og ulemper ved Unngå håndtering

Fordeler

Ulemper

1) Denne tilnærmingen reduserer sjansene for å få unntak.1) Øker kodelinjene fordi du legger til ekstra kode for å unngå unntak
Hvis et unntak fortsatt er fanget, vil det 2) være et virkelig eksepsjonelt tilfelle som er verdt å sjekke2) Bør ha en bedre forståelse av Web Driver API, kommandoer og unntak
Reduser feilsøkingstiden. Automasjonskoden er ment for å finne feil, og du vil ikke se for mange uønskede 3) unntak og finne årsakene bak hver av dem
4) I Catch-blokken behandler du mer gyldige saker
5) Reduser falske feil
6) Tydeligere rapport

I denne opplæringen vil vi diskutere Unngå og håndter tilnærming for de 10 vanligste unntakene i Selenium WebDriver. Før det, la oss få en grunnleggende forståelse av Exception Handling og Try / Catch-blokker.

Typer av unntak i Java og Selen

Nedenfor har vi beskrevet typer unntak og de forskjellige måtene hvordan vi kan bruke rammeverk for unntakshåndtering i selenskript.

Det er tre typer unntak:

  1. Sjekket unntak
  2. Ukontrollert unntak
  3. Feil

Klassehierarkiet med unntak og feil:

Unntakshåndtering i selen

# 1) Merket unntak: Merket unntak håndteres i kompileringstiden, og det gir kompileringsfeilen hvis det ikke blir fanget og håndtert i kompileringstiden.

Eksempel : FileNotFoundException , IO Unntak etc.

# 2) Uhaket unntak: I tilfelle det ukontrollerte unntaket har en kompilator ikke mandat til å håndtere. Kompilatoren ignorerer i løpet av kompileringstiden.

Eksempel : ArrayIndexoutOfBoundException

# 3) Feil: Når et scenario er dødelig og programmet ikke kan komme seg, kaster JVM en feil. Feil kan ikke håndteres av prøvefangstblokken. Selv om brukeren prøver å håndtere feilen ved å bruke Try catch block, kan den ikke gjenopprette fra feilen.

Eksempel : Påstandsfeil , OutOfMemoryError etc.

Avvikshåndtering

Prøv og fang blokkering:

prøvefangst blokker brukes vanligvis til å håndtere unntak. Type unntak er angitt i fangstblokk som forventes å komme. Når et unntak kommer i prøveblokk, går kontrollen umiddelbart til fangstblokken.

Eksempel :

try { br = new BufferedReader(new FileReader('Data')); } catch(IOException ie) { ie.printStackTrace(); }

Det kan være flere fangstblokker for en forsøksblokk, avhengig av typen unntak.

Eksempel :

try { br = new BufferedReader(new FileReader('Data')); } catch(IOException ie) { ie.printStackTrace(); } catch(FileNotFoundException file){ file.printStackTrace(); }

kaster Unntak:

kaster nøkkelord i java brukes til å kaste et unntak i stedet for å håndtere det. Alle avmerkede unntak kan kastes etter metoder.

Eksempel :

public static void main(String() args) throws IOException { BufferedReader br=new BufferedReader(new FileReader('Data')); while ((line = br.readLine()) != null) { System.out.println(line); } }

endelig blokkere:

endelig , blokk utfører uavhengig av utførelse av prøvefangstblokk og den kjøres umiddelbart etter at prøve / fangstblokk er fullført.

I utgangspunktet kan filstenging, databaseforbindelse osv. Lukkes i endelig blokk.

Eksempel :

try { br = new BufferedReader(new FileReader('Data')); } catch(IOException ie) { ie.printStackTrace(); } Finally { br.close(); }

I eksemplet ovenfor, BufferReader strømmen er stengt i endelig blokk. br.close () vil alltid kjøre uavhengig av utførelse av forsøksfangst.

Merk : endelig kan blokk eksistere uten noen fangstblokk. Det er ikke nødvendig å ha en fangstblokk alltid.

Det kan være mange fangstblokker, men bare en endelig blokk kan brukes.

selskaper som tilbyr produkttesting hjemme

Kastbar : Throwable er en overordnet klasse for feil og unntak. Generelt er det vanskelig å håndtere feil i java. Hvis en programmerer ikke er sikker på typen feil og unntak, anbefales det å bruke Throwable-klassen som kan fange både feil og unntak.

Eksempel :

try { br = new BufferedReader(new FileReader('Data')); } catch (Throwable t) { t.printStackTrace(); }

Vanlige unntak i Selen WebDriver

Selen har sitt eget unntak. Mens programmerer utvikler selen, må en programmerer håndtere eller kaste disse unntakene.

Nedenfor er noen eksempler på unntak i selen:

Alle unntaksklasser for kjøretid i Selenium WebDriver kommer under superklassen WebDriverException.

Webdriver unntak

Selv om det er mange unntaksklasser under WebDriverException, ser vi ofte de nedenfor.

  • NoSuchElementException
  • NoSuchWindowException
  • NoSuchFrameException
  • NoAlertPresentException
  • InvalidSelectorException
  • ElementNotVisibleException
  • ElementNotSelectableException
  • TimeoutException
  • NoSuchSessionException
  • StaleElementReferenceException

Detaljer :

ElementNotVisibleException : Hvis selen prøver å finne et element, men elementet ikke er synlig på siden

NoAlertPresentException : Hvis en bruker prøver å håndtere en varslingsboks, men varselet ikke er til stede.

NoSuchAttributeException : Mens du prøver å få attributtverdi, men attributtet er ikke tilgjengelig i DOM.

NoSuchElementException : Dette unntaket skyldes tilgang til et element som ikke er tilgjengelig på siden.

WebDriverException : Unntak kommer når en kode ikke kan initialisere WebDriver.

Unngå og håndtere vanlige unntak

La oss diskutere Unngå og håndter tilnærming for de ovennevnte unntakene:

# 1) org.openqa.selenium.NoSuchElementException

Denne ofte sett unntaksklassen er en underklasse av NotFoundException klasse. Unntaket oppstår når WebDriver ikke kan finne og finne elementer.

Vanligvis skjer dette når tester skriver feil elementlokator i findElement (By, by) -metoden.

Tenk på at i eksemplet nedenfor var riktig id for tekstfeltet 'firstfield', men testeren nevnte det feilaktig som 'fistfield'. I dette tilfellet kan ikke WebDriver finne elementet og org.openqa.selenium.NoSuchElementException vil bli kastet

driver.findElement(By.id('submit')).click(); Exception Handling: try { driver.findElement(By.id('submit')).click(); } catch (NoSuchElementException e)

I dette tilfellet kastes unntaket selv om elementet ikke er lastet.

Unngå-og-håndtering : Prøv å gi en ventekommando.

Eksempel: Ventekommandoen nedenfor venter 10 sekunder på tilstedeværelsen av et webelement med id 'sende'. Så prøver den å klikke på den. Hvis elementet er tilgjengelig, men fortsatt klikk mislykkes, blir et unntak fanget.

Å bruke forsinket tid er en vanlig praksis i testautomatisering for å skape en pause mellom trinnene. Ved å legge til en prøve / fangst sørger vi for at programmet fortsetter selv om ventetiden ikke kunne hjelpe.

try { WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); wait.Until(ExpectedConditions.presenceOfElementLocated(By.id('submit'))); try { driver.findElement(By.id('submit')).click(); } catch (WebDriverException e) { System.out.println(“An exceptional case.”); } } catch (TimeOutException e) { System.out.println(“WebDriver couldn’t locate the element”); }

# 2) org.openqa.selenium.NoSuchWindowException

NoSuchWindowException kommer under NotFoundException klasse. Dette kastes når WebDriver prøver å bytte til et ugyldig vindu.

Koden nedenfor kan kaste org.openqa.selenium.NoSuchWindowException hvis vindushåndtaket ikke eksisterer eller ikke er tilgjengelig for å bytte.

driver.switchTo (). vindu (handle_1);

Unngå-og-håndtering : Vi bruker vinduhåndtak for å få settet med aktive vinduer og deretter utføre handlinger på det samme.

I eksemplet nedenfor utføres driverbytte til hvert vindushåndtak. Derfor reduseres sjansene for å sende et galt vinduparameter.

for (String handle : driver.getWindowHandles()) { try { driver.switchTo().window(handle); } catch (NoSuchWindowException e) { System.out.println(“An exceptional case”); } }

# 3) org.openqa.selenium.NoSuchFrameException

Når WebDriver prøver å bytte til en ugyldig ramme, kastes NoSuchFrameException under NotFoundException-klassen.

Koden nedenfor kan kaste org.openqa.selenium.NoSuchFrameException hvis rammen “frame_11” ikke eksisterer eller ikke er tilgjengelig.

driver.switchTo (). ramme (“frame_11”);

Avvikshåndtering:

try { driver.switchTo().frame('frame_11'); } catch (NoSuchFrameException e)

I dette tilfellet kastes unntaket selv om rammen ikke er lastet.

Unngå-og-håndtering : Prøv å gi en ventekommando.

I eksemplet nedenfor venter WebDriver i 10 sekunder på at rammen skal være tilgjengelig. Hvis rammen er tilgjengelig og det fortsatt er et unntak, blir den fanget.

try { WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); wait.Until(ExpectedConditions.frameToBeAvaliableAndSwitchToIt(frame_11)); try { driver.switchTo().frame('frame_11'); } catch (WebDriverException e) { System.out.println(“An exceptional case”); } } catch (TimeOutException e) { System.out.println(“WebDriver couldn’t locate the frame”); }

# 4) org.openqa.selenium.NoAlertPresentException

NoAlertPresentException under NotFoundException blir kastet når WebDriver prøver å bytte til et varsel, som ikke er tilgjengelig.

org.openqa.selenium.NoAlertPresentException vil bli kastet Hvis under automatiseringskode samtaler aksepterer () operasjon på Alert () klasse når et varsel ennå ikke er på skjermen.

driver.switchTo (). alarm (). godta ();

Avvikshåndtering:

try { driver.switchTo().alert().accept(); } catch (NoSuchAlertException e)

I dette tilfellet kastes unntaket selv om varselet ikke er lastet helt inn.

Unngå-og-håndtering : Bruk alltid eksplisitt eller flytende ventetid i en bestemt tid i alle tilfeller der det forventes et varsel. Hvis varselet er tilgjengelig og det fortsatt er et unntak, blir det fanget.

try { WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); wait.Until(ExpectedConditions.alertIsPresent()); try { driver.switchTo().alert().accept(); } catch (NoAlertPresentException e) { System.out.println(“An exceptional case”); } } catch (TimeOutException e) System.out.println(“WebDriver couldn’t locate the Alert”); }

# 5) org.openqa.selenium.InvalidSelectorException

Denne underklassen av NoSuchElementException klasse oppstår når en velger er feil eller syntaktisk ugyldig. Dette unntaket forekommer ofte når XPATH locator brukes.

Tenk på eksemplet nedenfor:

clickXPathButtonAndWait (“// knapp (@ type =’ knapp ’) (100)”);

Dette vil føre til et InvalidSelectorExeption fordi XPATH-syntaksen er feil.

Unngå og håndtere : For å unngå dette, bør vi sjekke locatoren som brukes fordi locatoren sannsynligvis er feil eller syntaksen er feil. Bruk av Firebug for å finne xpath kan redusere dette unntaket.

Koden nedenfor viser hvordan du håndterer det ved hjelp av Try / Catch

try { clickXPathButtonAndWait('//button(@type='button')'); } catch (InvalidSelectorException e) { }

# 6) org.openqa.selenium.ElementNotVisibleException

ElementNotVisibleException klasse er en underklasse av ElementNotInteractableException klasse. Dette unntaket blir kastet når WebDriver prøver å utføre en handling på et usynlig webelement, som ikke kan samhandles med. Det vil si at webelementet er i en skjult tilstand.

For eksempel, i koden nedenfor, hvis typen type knapp med id 'sende' er 'skjult' i HTML, org.openqa.selenium.ElementNotVisibleException vil bli kastet.

driver.findElement(By.id('submit')).click(); Exception Handling: try { driver.findElement(By.id('submit')).click(); } catch (ElementNotVisibleException e)

I dette tilfellet kastes unntaket selv om siden ikke er lastet helt inn.

Unngå-og-håndtering : Det er to måter å gjøre dette på. Vi kan enten vente på at elementet blir helt.

Koden nedenfor venter 10 sekunder på elementet. Hvis elementet er synlig og likevel kastes unntak, blir det fanget.

try { WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); wait.Until(ExpectedConditions.visibilityOfElementLocated(By.id(”submit”)); try { driver.findElement(By.id('submit')).click(); } catch (WebDriverException e) { System.out.println(“Exceptional case”); } } catch (TimeOutException e) System.out.println(“WebDriver couldn’t find this element visible”); }

# 7) org.openqa.selenium.ElementNotSelectableException

Dette unntaket kommer under InvalidElementStateException klasse . ElementNotSelectableException indikerer at webelementet er tilstede på websiden, men ikke kan velges.

For eksempel, koden nedenfor kan kaste et ElementNotSelectableException hvis id 'rask' er deaktivert.

Velg rullegardin = ny Velg (driver.findElement (By.id ('rask')));

Avvikshåndtering:

prøv {
Velg rullegardin = ny Velg (driver.findElement (By.id ('rask')));
} fangst (ElementNotSelectableException e)

I dette tilfellet kastes unntak selv om elementet blir aktivert etter en stund.

Unngå-og-håndtering : Vi kan legge til en ventekommando for å vente til elementet blir klikkbart. Hvis det fremdeles er et unntak, blir det fanget.

try { WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); wait.Until(ExpectedConditions. elementToBeClickable(By.id(”swift”)); try { Select dropdown = new Select(driver.findElement(By.id('swift'))); } catch (WebDriverException e) { System.out.println(“Exceptional case”); } } catch (TimeOutException e) System.out.println(“WebDriver found that this element was not selectable.”); }

# 8) org.openqa.selen .TimeoutException

Dette unntaket oppstår når en kommandofullføring tar mer enn ventetiden. Ventetider brukes hovedsakelig i WebDriver for å unngå unntaket ElementNotVisibleException.

Noen ganger kan det hende at testsiden ikke lastes helt inn før neste kommando i programmet. Hvis WebDriver prøver å finne et element på websiden før siden lastes helt inn, kastes unntaket ElementNotVisibleException. Ventekommandoer legges til for å unngå dette unntaket.

Imidlertid, hvis komponentene ikke lastes selv etter ventetiden, unntaket org.openqa.selen .TimeoutException vil bli kastet.

driver.manage (). timeouts (). implicitly Waait (10, TimeUnit.SECONDS);

driver.get (“https://www.softwaretestinghelp.com”);

I programmet ovenfor legges det til en implisitt ventetid på 10 sekunder. Hvis siden www.softwaretestinghelp.com lastes ikke på 10 sekunder, så blir TimeoutException kastet.

Unngå og håndtere : For å unngå dette kan vi manuelt sjekke gjennomsnittstiden for en side for å laste inn og justere ventetiden

Eller vi kan legge til eksplisitt ventetid ved å bruke JavaScript-utføreren til siden er lastet inn.

I eksemplet nedenfor brukes JavaScript-utføreren. Etter sidenavigasjon kaller vi JavaScript return document.readyState i 20 sekunder til “fullført” returneres.

WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(30)); wait.until(webDriver -> ((JavascriptExecutor)webDriver).executeScript('return document.readyState').equals('complete')); driver.get('https://www.softwaretestinghelp.com');

# 9) org.openqa.selenium.NoSuchSessionException

Dette unntaket blir kastet når en metode blir kalt etter å ha avsluttet nettleseren av WebDriver.quit (). Dette kan også skje på grunn av problemer i nettleseren som krasj, og WebDriver kan ikke utføre noen kommando ved hjelp av driverinstansen.

For å se dette unntaket kan koden nedenfor utføres.

driver.quit ()

Velg rullegardin = ny Velg (driver.findElement (By.id ('rask')));

Unngå og håndtere : Velg alltid den siste stabile versjonen av nettleseren for å kjøre Selenium Webdriver-testkasser.

Dette unntaket kan reduseres ved å bruke driver.quit () når alle testene er fullført. Ikke prøv å bruke dem etter hver testtilfelle. Dette kan føre til problemer når driverinstansen er null, og kommende testtilfeller prøver å bruke den uten å initialisere.

Koden nedenfor oppretter WebDriver-forekomst i @BeforeSuite TestiNG-merknaden og ødelegger den i @AfterSuite TestiNG-merknaden

@BeforeSuite public void setUp() throws MalformedURLException { WebDriver driver = new FirefoxDriver(); } @AfterSuite public void testDown() { driver.quit(); }

# 10) org.openqa.selenium.StaleElementReferenceException

Dette unntaket sier at et webelement ikke lenger er tilstede på websiden.

Denne feilen er ikke den samme som ElementNotVisibleException.

StaleElementReferenceException kastes når et objekt for et bestemt webelement ble opprettet i programmet uten problemer, og imidlertid; dette elementet er ikke lenger til stede i vinduet. Dette kan skje hvis det var en

java programmeringsintervju spørsmål for erfarne
  • Naviger til en annen side
  • DOM har oppdatert seg
  • En ramme- eller vindusbryter

WebElement firstName = driver.findElement (By.id (“firstname”));

driver.switchTo (). vindu (Child_Window);

element.sendKeys (“Aaron”);

I koden ovenfor ble objektet firstName opprettet, og deretter ble vinduet byttet. Deretter prøver WebDriver å skrive ‘Aaron’ i skjemafeltet. I dette tilfellet kastes StaleElementReferenceException.

Unngå og håndtere : Bekreft at vi prøver å utføre handlingen i riktig vindu. For å unngå problemer på grunn av DOM-oppdatering, kan vi bruke Dynamic Xpath

La oss diskutere et annet eksempel.

Si at 'id' i et brukernavnfelt er 'brukernavn_1', og XPath vil være det // * (@ id = ’fornavn_1?) . Når du åpner siden igjen, kan 'id' endre 'til' 'fornavn _11 ’. I dette tilfellet mislykkes testen fordi WebDriver ikke fant elementet. I dette tilfellet blir StaleElementReferenceException kastet.

I dette tilfellet kan vi bruke en dynamisk xpath som,

try { driver.findElement(By.xpath(“//*(contains(@id,firstname’))”)).sendKeys(“Aaron”); } catch (StaleElementReferenceException e)

I eksemplet ovenfor brukes dynamisk XPATH, og hvis unntaket fremdeles blir funnet, blir det fanget.

Konklusjon

Unntakshåndtering er den essensielle delen av hvert java-program samt selen-skript. Vi kan bygge robust og optimal kode ved å håndtere et unntak på smarte måter . Og det er også en god praksis å håndtere unntak i et skript som vil gi deg en bedre rapport når et program mislykkes på grunn av en eller annen grunn.

Her har vi prøvd å dekke prosessen og rammeverket for unntakshåndtering som kreves implementert i selen-skript.

Husk at det ikke er obligatorisk å alltid håndtere unntaket i a prøvefangst blokkere. Du kan også kaste et unntak avhengig av kravet i et skript.

Et unntak bør ikke ignoreres da de bryter programutførelsen. I denne opplæringen gikk vi gjennom forskjellige unntak og måter å redusere sjansene for å få dem gjennom manuelle kontroller og koder.

Å legge til ventetid kan kontrollere noen tilfeller som 'NoSuchElementException', 'ElementNotFoundException', 'ElementNotVisibleException'.

Neste opplæring nr. 20 : I den kommende opplæringen vil vi diskutere forskjellige typer testrammer tilgjengelig . Vi vil også studere fordeler og ulemper ved å bruke en avansert rammetilnærming i automatiseringstesting. Vi vil diskutere i detalj om det testdatadrevne rammeverket.

Vennligst legg inn spørsmålene dine, relatert til håndterings unntak, i Selenium WebDriver, hvis du har noen.

Anbefalt lesing

^