Întrebări Interviu Selenium

Ați scris teste care trec local dar eșuează în pipeline, și bănuiți că răspunsul ține de wait fără să reușiți să îl formulați clar. Intervievatorii știu asta, de aceea wait deschide majoritatea rundelor de Selenium. Această secțiune arată cum sună un răspuns complet.

• Implicit versus explicit wait. Un implicit wait este o setare globală care verifică prezența elementului la fiecare căutare. Un explicit wait vizează un singur element și o singură condiție, precum clickable sau visible. Explicit este preferat pentru că precizează exact ce se așteaptă.
• De ce nu ar trebui combinate? Combinarea celor două poate acumula timeout-uri într-un mod greu de anticipat, de aceea majoritatea echipelor setează implicit wait la zero și folosesc explicit wait peste tot.
• Ce este un fluent wait? Un explicit wait cu un interval de polling configurabil și tipuri de exception ignorate.
• De ce este greșit Thread.sleep? Este necondiționat. Încetinește un test care ar fi trecut și tot lasă să eșueze unul lent.
• CSS selector sau XPath? Preferați un atribut identificator de test stabil, apoi CSS pentru lizibilitate. XPath își câștigă locul când trebuie să urcați spre un parent sau să potriviți după text.
• Ce face un locator fragil? Nume de clasă generate automat, XPath absolut și selecția bazată pe index. Spuneți ce ați cere unui developer să adauge în schimb.

Intervievatorii ascultă motivul din spatele fiecărei alegeri. A numi o preferință fără costul asociat sună ca un răspuns memorat.

Testele flaky sunt subiectul real al majorității interviurilor senior de automatizare, pentru că o suită în care nimeni nu are încredere este mai rea decât lipsa unei suite.

• Ce cauzează StaleElementReferenceException? Referința elementului indică spre un nod care nu mai este atașat, de obicei pentru că framework-ul a re-randat acea parte a paginii. Recăutați elementul în loc să refolosiți referința salvată.
• Dar ElementNotInteractableException? Elementul există dar nu poate fi acționat: ascuns, disabled, acoperit de un overlay, sau în afara ecranului.
• Cum gestionați NoSuchElementException? Distingeți o problemă de timing de un element cu adevărat absent și nu o mascați cu un sleep mai lung.
• De ce eșuează testele doar în pipeline? Dimensiune diferită a viewport-ului, mediu mai lent, date de test lipsă, animații care se termină mai târziu și teste paralele care se ciocnesc pe o stare partajată.
• Cum reparați un test flaky? Diagnosticați mai întâi categoria, apoi reparați cauza. Auto-retry ascunde eșecurile și este o soluție de ultimă instanță pe care ar trebui să o numiți ca atare.
• Cum gestionați frame-uri, ferestre noi și alerte? Schimbând contextul explicit și revenind la el ulterior.

Un inginer QA aflat la interviu pentru un rol de automatizare mid-level a fost întrebat de ce o suită eșua de două ori pe săptămână fără nicio schimbare de cod. Răspunsul câștigător nu a fost un detaliu de API Selenium, ci faptul că testele partajau un singur cont seeded și se blocau reciproc. Intervievatorii recompensează această ordine de diagnosticare: mai întâi mediul și datele, apoi API-ul.

Mai multe bănci de întrebări pe rol și unealtă se află sub interview questions by role.

Dincolo de API, panelul vrea să știe dacă puteți gestiona o suită. Aceste întrebări cântăresc cel mai mult pentru rolurile senior.

• Explicați Page Object Model. Clasele page expun acțiuni și ascund locatori, astfel încât o schimbare de UI atinge un singur fișier. Spuneți ce problemă rezolvă; a descrie doar structura de foldere ratează esența.
• Ce poate merge prost cu Page Object? Cresc până devin clase de mii de linii și încep să facă assert în interiorul metodelor de page. Assertion-urile aparțin testelor.
• Cum rulează framework-ul dumneavoastră testele în paralel? Gestionare thread-safe a driverului astfel încât instanțele nu sunt partajate între thread-uri, plus date de test independente pentru fiecare test.
• La ce servește Selenium Grid? Distribuirea testelor pe mai multe mașini și versiuni de browser, cu un hub și noduri, sau un furnizor cloud care joacă același rol.
• Ce s-a schimbat în Selenium 4? Protocolul W3C WebDriver a devenit standard și vechiul JSON wire protocol a fost eliminat, au apărut locatorii relative, iar accesul la Chrome DevTools Protocol a fost expus.
• Când nu ați folosi Selenium? Verificări la nivel de API, logică testabilă prin unit test și orice se află în afara browserului. Cunoașterea acestei granițe este un semnal de senior.
• Cum decideți ce automatizați? Trasee stabile, cu valoare mare, repetitive. Nu totul, și nu un ecran încă în curs de redesign.

Răspunsurile despre Selenium sunt neobișnuit de ușor de știut și greu de spus. Întrebarea despre wait în special are un răspuns în două părți, definiția și motivul, iar candidații care doar au citit-o oferă prima jumătate și se pierd.

Luați cele cinci întrebări de aici pe care cel mai puțin ați vrea să le primiți și răspundeți cu voce tare la fiecare în nouăzeci de secunde fără niciun editor deschis. Apoi rugați pe cineva să pună întrebarea de continuare, care este aproape mereu de ce. Rularea acelorași prompt-uri împotriva unui intervievator AI care insistă este mai aproape de o rundă reală decât recitirea unei liste, și exact pentru asta există modul mock interview.

Aaron Cao, fondatorul SubcueAI, a construit practica în jurul acestui decalaj de vorbire, nu în jurul furnizării mai multor întrebări. Într-un interviu live, aplicația desktop și Side Panel-ul extensiei de browser pot evidenția structura pe măsură ce intervievatorul vorbește, ceea ce ajută cel mai mult pe materialul deja exersat. Ce face produsul, și limitele pe care nu le depășește, sunt descrise pe pagina security.