A4Q Selenium Tester Probeprüfung #3 — Fragen & Antworten
Alle Fragen dieser Probeprüfung, mit markierter richtiger Antwort und einer schriftlichen Begründung zu jeder Option unten — zum Lesen und Wiederholen, kein zeitlich begrenzter Durchlauf.
Welche Aussage beschreibt die Beziehung zwischen dem WebDriver-Interface und der ChromeDriver-Klasse in den Selenium-Java-Bindings korrekt?
ChromeDriver implementiert das WebDriver-Interface, daher kann die Variable als WebDriver-Typ deklariert werden
Richtig — die Programmierung gegen das Interface hält den Test browserunabhängig.
WebDriver erweitert ChromeDriver, sodass ChromeDriver der Elterntyp ist
Vertauscht — das Interface ist die Abstraktion, die Klasse implementiert es.
Sie sind nicht verwandte Klassen und müssen zur Laufzeit gecastet werden
Falsch — sie sind über die implements-Beziehung verbunden, kein Cast nötig.
WebDriver ist ein Interface; ChromeDriver ist eine browserspezifische Implementierung davon, daher lautet die empfohlene Deklaration WebDriver driver = new ChromeDriver();
Während eines Testlaufs wurden mehrere Browserfenster geöffnet. Worin unterscheiden sich driver.close() und driver.quit()?
close() schließt nur das aktuelle Fenster; quit() schließt alle Fenster und beendet die Sitzung
Richtig — so ist das Verhalten der beiden Befehle definiert.
close() beendet die Sitzung; quit() schließt nur das aktuelle Fenster
Vertauscht — quit() beendet die gesamte Sitzung.
Sie sind Aliase und verhalten sich identisch
Falsch — sie unterscheiden sich, wenn mehr als ein Fenster offen ist.
close() löscht Cookies; quit() löscht den Browser-Cache
Falsch — keiner der Befehle löscht Cookies oder Cache.
close() schließt nur das aktuelle Fenster/den Tab; quit() schließt alle Fenster und beendet die WebDriver-Sitzung.
Wie unterscheiden sich findElement() und findElements(), wenn kein Element zum Locator passt?
findElement() wirft NoSuchElementException, während findElements() eine leere Liste zurückgibt
Richtig — findElements wirft bei keinem Treffer nichts, es gibt Größe 0 zurück.
Beide werfen NoSuchElementException
Falsch — findElements gibt eine leere Liste zurück, statt zu werfen.
Beide geben null zurück
Falsch — findElement wirft eine Exception und gibt nicht null zurück.
findElement() gibt eine leere Liste zurück; findElements() wirft
Vertauscht — es ist genau umgekehrt.
findElement() wirft eine NoSuchElementException; findElements() liefert eine leere Liste zurück.
Welche der folgenden sind legitime browserspezifische Implementierungen des WebDriver-Interfaces? (Wählen Sie zwei.)
ChromeDriver
Richtig — die Treiber-Implementierung für Google Chrome.
FirefoxDriver
Richtig — die Treiber-Implementierung für Mozilla Firefox (über GeckoDriver).
SeleniumIDEDriver
Falsch — eine solche Klasse gibt es nicht; Selenium IDE ist ein Record-and-Playback-Tool.
RemoteBrowserManager
Falsch — keine echte Selenium-Klasse; Remote-Läufe nutzen RemoteWebDriver.
ChromeDriver und FirefoxDriver sind echte WebDriver-Implementierungen. SeleniumIDEDriver und RemoteBrowserManager gibt es in den Bindings nicht.
Ein Tester schreibt folgenden Java-Code gegen ein Login-Formular: driver.get("https://shop.example/login"); WebElement user = driver.findElement(By.id("username")); user.sendKeys("alice"); WebElement pass = driver.findElement(By.id("password")); pass.sendKeys("secret"); driver.findElement(By.id("login-btn")).click(); Das Feld mit der id 'username' enthält bereits den Wert 'guest' aus einem vorherigen Schritt. Welchen Wert hat das Feld nach der Ausführung?
guestalice
Richtig — sendKeys hängt an; ohne clear() bleibt 'guest' und 'alice' wird angefügt.
alice
Falsch — dafür müsste vor sendKeys clear() aufgerufen werden, was hier fehlt.
guest
Falsch — sendKeys fügt 'alice' hinzu, der Wert ändert sich.
Es wird eine Exception geworfen, weil das Feld nicht leer ist
Falsch — sendKeys erfordert kein leeres Feld und wirft hier nichts.
sendKeys() hängt Text an den vorhandenen Inhalt an; es leert das Feld nicht. Also 'guest' + 'alice' = 'guestalice'. Zum Ersetzen zuerst user.clear() aufrufen.
Sie müssen den aktuell in einem <input>-Textfeld angezeigten Wert auslesen. Welcher Ansatz ist korrekt?
element.getAttribute("value")
Richtig — der Inhalt des Inputs wird über das value-Attribut/-Property bereitgestellt.
element.getText()
Falsch — getText() liefert den sichtbaren Innentext, der bei <input> meist leer ist.
element.getTagName()
Falsch — das gibt den Tag des Elements ('input') zurück, nicht den Wert.
element.getCssValue("value")
Falsch — getCssValue liest CSS-Eigenschaften, nicht den Feldwert.
Bei Formularelementen steckt der sichtbare Wert im 'value'-Attribut/-Property, daher getAttribute("value"). getText() liefert den sichtbaren Text von Nicht-Input-Elementen und ist bei Inputs meist leer.
Welche Selenium-API ist für komplexe Benutzergesten wie das Überfahren eines Menüs, Drag-and-Drop oder Tastenkombinationen gedacht?
Die Actions-Klasse
Richtig — sie modelliert zusammengesetzte Eingabegesten über einen Builder und perform().
Die Select-Klasse
Falsch — Select behandelt nur <select>-Dropdown-Optionen.
Das Alert-Interface
Falsch — Alert behandelt JavaScript-Dialoge (alert/confirm/prompt).
Das Navigation-Interface
Falsch — Navigation behandelt back/forward/refresh/to, keine Gesten.
Die Actions-Klasse baut Sequenzen von Low-Level-Interaktionen (moveToElement, dragAndDrop, keyDown usw.) und führt sie mit perform() aus.
Ein Dropdown <select id='country'> lässt den Nutzer ein Land wählen. Welcher Selenium-Helfer ist der sauberste Weg, die Option mit der Beschriftung 'Germany' zu wählen?
new Select(element).selectByVisibleText("Germany")
Richtig — die Select-Klasse ist die vorgesehene API für Dropdowns.
element.sendKeys("Germany")
Funktioniert in manchen Browsern teilweise, ist aber nicht der zuverlässige, vorgesehene Weg für <select>.
element.click() und dann den Text tippen
Falsch — ein natives <select> akzeptiert so keinen frei getippten Text.
new Dropdown(element).choose("Germany")
Falsch — es gibt keine Dropdown-Klasse in den Selenium-Bindings.
Das Element in die Select-Klasse einwickeln und selectByVisibleText("Germany") aufrufen. Select bietet zweckgebundene Methoden für <select>-Elemente.
Welche Locator-Strategie sollte laut Selenium-Best-Practice bevorzugt werden, wenn ein eindeutiges, stabiles id-Attribut am Zielelement verfügbar ist?
By.id
Richtig — die bevorzugte erste Wahl, wenn eine eindeutige, stabile id existiert.
Ein absoluter XPath ab der <html>-Wurzel
Falsch — absoluter XPath ist am fragilsten und bricht bei jeder Strukturänderung.
By.linkText auf einen benachbarten Link
Falsch — zielt auf ein anderes Element und hängt vom sichtbaren Text ab.
By.tagName
Falsch — der Tag-Name trifft meist viele Elemente und ist nicht eindeutig.
By.id ist der schnellste und robusteste Locator, da ids eindeutig sein sollen und von Layoutänderungen selten betroffen sind.
Betrachten Sie dieses HTML-Fragment: <div class="cart"> <ul> <li class="item" data-sku="A100">Keyboard</li> <li class="item" data-sku="B200">Mouse</li> <li class="item" data-sku="C300">Monitor</li> </ul> </div> Welcher einzelne Locator wählt genau das <li> für die Mouse und nichts anderes?
By.cssSelector("li.item[data-sku='B200']")
Richtig — der eindeutige data-sku-Wert isoliert genau die Mouse-Zeile.
By.className("item")
Falsch — trifft alle drei <li>-Elemente.
By.tagName("li")
Falsch — trifft ebenfalls alle drei Listeneinträge.
By.cssSelector(".cart ul li")
Falsch — wählt jedes <li>-Nachfahren-Element, nicht nur die Mouse.
Das data-sku-Attribut ist pro Item eindeutig, daher trifft der CSS-Selektor li.item[data-sku='B200'] genau die Mouse. Auswahl per Index oder nur über die Klasse trifft mehrere Items.
Sie müssen einen Submit-Button lokalisieren, der weder id noch stabile Klasse hat, aber immer den sichtbaren Text 'Place order' enthält. Welcher XPath trifft ihn zuverlässig, unabhängig vom umgebenden Markup?
//button[normalize-space()='Place order']
Richtig — trifft über getrimmten Text und toleriert umgebenden Whitespace.
/html/body/div[2]/form/div[3]/button
Falsch — ein absoluter Pfad bricht, sobald sich die umgebende Struktur ändert.
//button[1]
Falsch — indexbasiert und trifft irgendeinen ersten Button.
//button[@id='place-order']
Falsch — das Element hat keine id, daher trifft dies nichts.
//button[normalize-space()='Place order'] trifft über den getrimmten sichtbaren Text und ist gegen Whitespace und Position robust. Ein absoluter oder indexbasierter Pfad ist fragil.
Was ist der wesentliche Unterschied zwischen den CSS-Selektoren 'div p' (mit Leerzeichen) und 'div > p'?
Das Leerzeichen wählt jedes Nachfahren-<p>; '>' wählt nur ein direktes Kind-<p>
Richtig — Nachfahren- vs. Kind-Kombinator.
Sie sind gleichwertig; das '>' ist nur kosmetisch
Falsch — sie wählen unterschiedliche Elementmengen.
Das Leerzeichen wählt direkte Kinder; '>' wählt jeden Nachfahren
Vertauscht — es ist umgekehrt.
'>' funktioniert nur in XPath, nicht in CSS
Falsch — '>' ist ein gültiger CSS-Kind-Kombinator.
'div p' trifft jedes <p>, das Nachfahre eines <div> in beliebiger Tiefe ist; 'div > p' trifft nur <p>, das direktes Kind eines <div> ist.
Gegeben das Element <a href="/help" class="nav-link active">Help Center</a> — welche der folgenden Locators würden es erfolgreich treffen? (Wählen Sie zwei.)
By.linkText("Help Center")
Richtig — der exakte sichtbare Text des Ankers passt.
By.cssSelector("a.nav-link.active")
Richtig — das Verketten beider Klassennamen in CSS ist gültig und trifft diesen Anker.
By.className("nav-link active")
Falsch — By.className akzeptiert einen einzelnen Klassennamen, keine mit Leerzeichen getrennte Kombination.
By.linkText("Help")
Falsch — linkText erfordert den vollständigen Text; für eine Teilzeichenkette partialLinkText verwenden.
By.linkText("Help Center") trifft den vollständigen sichtbaren Linktext; By.cssSelector("a.nav-link.active") trifft beide Klassen. By.className kann nicht zwei Klassen als einen String nehmen, und der angegebene Teiltext passt nicht.
Welche Aussage über By.name und By.id ist korrekt?
id soll pro Seite eindeutig sein, während name von mehreren Elementen geteilt werden kann
Richtig — z.B. teilt sich eine Radiobutton-Gruppe einen name.
name muss immer eindeutig sein, id darf sich wiederholen
Vertauscht — es ist id, das eindeutig sein sollte.
Keiner kann mit findElement verwendet werden
Falsch — sowohl By.id als auch By.name funktionieren mit findElement.
By.name funktioniert nur bei <a>-Ankerelementen
Falsch — name gilt für Formularelemente und andere, nicht nur Anker.
Beide sind attributbasierte Locators, aber nur id soll pro Dokument eindeutig sein; name kann von mehreren Elementen geteilt werden (z.B. Radiobuttons einer Gruppe).
Eine Ergebnistabelle hat Zeilen wie: <tr><td class="name">Order 42</td><td class="status">Shipped</td></tr> Sie benötigen die Status-Zelle in derselben Zeile wie die Namenszelle mit 'Order 42'. Welcher XPath drückt diese Beziehung aus?
//td[@class='name'][normalize-space()='Order 42']/following-sibling::td[@class='status']
Richtig — verankert am bekannten Text und springt zur Geschwister-Statuszelle.
//td[@class='status']
Falsch — trifft jede Statuszelle der Tabelle, nicht die zu Order 42.
//td[@class='name']/td[@class='status']
Falsch — die Statuszelle ist ein Geschwister, kein Kind der Namenszelle.
//tr[normalize-space()='Order 42']
Falsch — wählt die Zeile, nicht die gefragte Statuszelle.
Von der Namenszelle über den Text ausgehen und zur Geschwister-Statuszelle wechseln: //td[@class='name'][normalize-space()='Order 42']/following-sibling::td[@class='status'].
Welcher CSS-Selektor trifft ein <input>, dessen id-Attribut mit dem Präfix 'user_' beginnt?
input[id^='user_']
Richtig — ^= bedeutet 'Attributwert beginnt mit'.
input[id$='user_']
Falsch — $= bedeutet 'endet mit', nicht 'beginnt mit'.
input[id*='user_']
Fast, aber *= bedeutet 'enthält irgendwo', nicht speziell ein Präfix.
input[id~='user_']
Falsch — ~= trifft ein durch Leerzeichen getrenntes Wort, für klassenähnliche Listen.
Der Operator für 'beginnt mit' ist ^=, also trifft input[id^='user_'] ids wie user_name, user_email usw.
Was ist der Hauptzweck des Page-Object-Model (POM)-Entwurfsmusters in der Selenium-Testautomatisierung?
Locators und Aktionen einer Seite in einer Klasse zu kapseln, was Wartbarkeit und Wiederverwendung verbessert
Richtig — genau das ist das Wartbarkeitsziel von POM.
Tests durch Caching von HTTP-Antworten schneller zu machen
Falsch — POM ist ein Strukturmuster, kein Performance-/Caching-Mechanismus.
Die Notwendigkeit einer WebDriver-Instanz zu ersetzen
Falsch — Page Objects nutzen intern weiterhin einen WebDriver.
Testdaten automatisch zu generieren
Falsch — POM befasst sich nicht mit Testdatengenerierung.
POM kapselt Locators und Interaktionen einer Seite in einer eigenen Klasse, sodass UI-Änderungen an einer Stelle behoben werden und Tests lesbar und wartbar bleiben.
Wo sollten in einem gut entworfenen Page Object Test-Assertions (z.B. Prüfen, dass eine Fehlermeldung einem erwarteten String entspricht) normalerweise liegen?
In den Testmethoden, nicht im Page Object
Richtig — hält Page Objects wiederverwendbar und frei von testspezifischer Logik.
In jeder Locator-Definition
Falsch — Locators identifizieren nur Elemente; sie enthalten keine Assertions.
Im WebDriver-Konstruktor
Falsch — das Driver-Setup hat nichts mit Assertions zu tun.
In der Entwicklerkonsole des Browsers
Falsch — das ist nicht Teil der automatisierten Teststruktur.
Assertions gehören in die Test-/Step-Methoden, nicht in das Page Object. Das Page Object stellt Zustand bereit (Getter, Aktionsmethoden); der Test entscheidet, was korrekt ist.
Ein Tester schreibt diese Page-Object-Methode für eine Login-Seite: public HomePage login(String u, String p) { driver.findElement(By.id("user")).sendKeys(u); driver.findElement(By.id("pass")).sendKeys(p); driver.findElement(By.id("submit")).click(); return new HomePage(driver); } Warum gilt die Rückgabe eines neuen HomePage-Objekts hier als gute POM-Praxis?
Sie modelliert die resultierende Seitennavigation und ermöglicht flüssiges Verketten zu HomePage-Aktionen
Richtig — die Rückgabe des Zielseiten-Objekts spiegelt den echten Navigationsfluss wider.
Weil sie bestätigt, dass der Login erfolgreich war
Falsch — die Methode enthält keine Assertion; die Prüfung bleibt im Test.
Weil sie die WebDriver-Sitzung beendet
Falsch — hier wird der Driver nicht beendet.
Weil sie den Einsatz von Locators vermeidet
Falsch — die Methode nutzt weiterhin By.id-Locators.
Ein erfolgreicher Login navigiert zur Startseite, daher erlaubt die Rückgabe des nächsten Page Objects flüssiges Verketten und modelliert den echten Seitenfluss. Sie führt selbst keine Assertion aus.
Welchen Vorteil bietet POM, wenn ein Entwickler die id des Login-Buttons von 'login' in 'signin' umbenennt?
Der Locator wird an einer Stelle korrigiert, sodass keine Testskripte bearbeitet werden müssen
Richtig — zentralisierte Locators sind der Kern-Wartbarkeitsvorteil von POM.
Selenium erkennt die Umbenennung automatisch
Falsch — Selenium kann eine umbenannte id nicht erraten; ein Mensch muss den Locator aktualisieren.
Die Testdaten werden neu generiert
Falsch — das Umbenennen eines Locators hat nichts mit Testdaten zu tun.
Der Browser braucht keinen Treiber mehr
Falsch — ohne Bezug; ein Treiber ist immer erforderlich.
Nur der eine Locator im Page Object muss geändert werden; alle Tests, die die Methode des Page Objects aufrufen, funktionieren unverändert weiter.
Welche der folgenden sind empfohlene Eigenschaften einer gut entworfenen Page-Object-Klasse? (Wählen Sie zwei.)
Es stellt lesbare Aktionsmethoden bereit (z.B. login, search) statt roher Locators
Richtig — Tests sollten in Fachaktionen sprechen, nicht in Element-Interna.
Es hält seine Locators privat/gekapselt in der Klasse
Richtig — Kapselung hält die Wartung lokal im Page Object.
Es enthält die Test-Assertions für jedes Szenario
Falsch — Assertions gehören in die Tests, damit Page Objects wiederverwendbar bleiben.
Es verwendet vor jeder Aktion Thread.sleep() für Stabilität
Falsch — fest codierte Sleeps sind ein Anti-Pattern; explizite Waits verwenden.
Ein Page Object sollte sinnvolle Aktions-/Getter-Methoden bereitstellen und Locators privat in der Klasse halten. Es sollte keine Assertions oder fest codierten Sleeps enthalten.
Wie unterstützt die PageFactory das Page-Object-Model in den Selenium-Java-Bindings?
Sie initialisiert mit @FindBy annotierte Felder, sodass Element-Lookups automatisch verdrahtet werden
Richtig — das ist die Rolle von PageFactory.initElements.
Sie startet den Browser automatisch
Falsch — der Treiber, nicht die PageFactory, startet den Browser.
Sie schreibt die Assertions für Sie
Falsch — PageFactory hat nichts mit Assertions zu tun.
Sie konvertiert XPath automatisch in CSS
Falsch — eine solche Konvertierung führt die PageFactory nicht durch.
PageFactory initialisiert mit @FindBy annotierte Felder über PageFactory.initElements(driver, this) und liefert verzögert lokalisierte WebElements, was Boilerplate reduziert.
Was ist der wesentliche Unterschied zwischen einem impliziten und einem expliziten Wait in Selenium WebDriver?
Der implizite Wait gilt global für alle Element-Lookups; der explizite Wait zielt auf eine bestimmte Bedingung
Richtig — das ist der entscheidende Unterschied.
Der implizite Wait gilt für ein bestimmtes Element; der explizite Wait ist global
Vertauscht — es ist umgekehrt.
Beide pausieren den Thread für eine feste Sekundenzahl unabhängig vom Zustand
Falsch — das beschreibt Thread.sleep, nicht die bedingten impliziten/expliziten Waits.
Es gibt keinen Unterschied; die Begriffe sind austauschbar
Falsch — sie verhalten sich deutlich unterschiedlich.
Ein impliziter Wait setzt ein globales Polling-Timeout für Element-Lookups; ein expliziter Wait (WebDriverWait + ExpectedConditions) wartet auf eine bestimmte Bedingung an einem bestimmten Element.
Warum wird die Verwendung von Thread.sleep(5000) zum Warten auf ein Element in Selenium-Tests generell abgeraten?
Es verschwendet Zeit, wenn das Element früh bereit ist, kann aber bei langsamem Laden zu kurz sein — also langsam und unzuverlässig
Richtig — feste Sleeps sind langsam und unzuverlässig.
Weil Thread.sleep in Java nicht unterstützt wird
Falsch — es ist gültiges Java; das Problem ist die schlechte Synchronisationsstrategie.
Weil es als Nebeneffekt Cookies löscht
Falsch — Sleep hat keine Auswirkung auf Cookies.
Weil es nur im Headless-Modus funktioniert
Falsch — Thread.sleep funktioniert unabhängig vom Headless-Modus.
Ein fester Sleep wartet immer die volle Zeit, auch wenn das Element früher erscheint (langsam), und kann bei langsamem Laden trotzdem zu kurz sein (flaky). Explizite Waits pollen und fahren fort, sobald die Bedingung erfüllt ist.
Ein Tester möchte einen Button erst klicken, sobald er klickbar ist, und dabei bis zu 10 Sekunden warten. Welches Snippet ist korrekt? A) new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(By.id("go"))).click(); B) driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); driver.findElement(By.id("go")).click(); Welches ist die passende Explicit-Wait-Lösung für die Klickbar-Bedingung?
Option A
Richtig — elementToBeClickable ist die Bedingung, die die Anforderung erfüllt.
Option B
Falsch — der implizite Wait sichert nur Vorhandensein, nicht Klickbarkeit.
Beide sind gleichermaßen korrekt
Falsch — nur A wartet auf Klickbarkeit; B nur auf Vorhandensein.
Keines lässt sich kompilieren
Falsch — beide sind gültiges Java; es geht darum, welches die Anforderung erfüllt.
Option A nutzt WebDriverWait mit der ExpectedCondition elementToBeClickable — genau der benötigte explizite Wait. Option B ist ein impliziter Wait, der nur auf Vorhandensein wartet, nicht auf Klickbarkeit.
Eine Testsuite setzt einen impliziten Wait von 10 Sekunden und verwendet in einem Test zusätzlich einen expliziten WebDriverWait von 15 Sekunden auf dasselbe Element. Das Team bemerkt unvorhersehbare, teils sehr lange Wartezeiten. Was ist die wahrscheinlichste Ursache?
Das Mischen von impliziten und expliziten Waits, deren Timeouts sich unvorhersehbar addieren können
Richtig — die offizielle Empfehlung ist, die beiden Wait-Mechanismen nicht zu kombinieren.
Der explizite Wait überschreibt immer den impliziten Wait, sodass es keinen Konflikt geben kann
Falsch — sie überschreiben sich nicht sauber; genau deshalb wird das Mischen abgeraten.
Implizite Waits werden ignoriert, sobald WebDriverWait importiert wird
Falsch — der Import einer Klasse deaktiviert die implizite Wait-Einstellung nicht.
Der Browser-Treiber ist zu alt
Falsch — das Symptom deutet auf Wait-Mischung, nicht auf die Treiberversion.
Das Mischen von impliziten und expliziten Waits kann dazu führen, dass sich ihre Timeouts unvorhersehbar addieren. Empfohlen wird, nur explizite Waits zu verwenden und keinen impliziten Wait zu setzen.
Welche ExpectedCondition sollten Sie verwenden, um zu warten, bis ein Element im DOM vorhanden und auf der Seite sichtbar ist, bevor Sie seinen Text lesen?
ExpectedConditions.visibilityOfElementLocated(locator)
Richtig — sichert sowohl Vorhandensein als auch Sichtbarkeit.
ExpectedConditions.invisibilityOfElementLocated(locator)
Falsch — das wartet auf das Verschwinden des Elements, das Gegenteil.
ExpectedConditions.numberOfWindowsToBe(1)
Falsch — das prüft die Fensteranzahl, ohne Bezug zur Element-Sichtbarkeit.
ExpectedConditions.titleIs("Home")
Falsch — das prüft den Seitentitel, nicht Vorhandensein/Sichtbarkeit des Elements.
visibilityOfElementLocated wartet darauf, dass das Element sowohl im DOM vorhanden als auch angezeigt (Größe > 0, sichtbar) ist — genau das ist vor dem Lesen des Textes nötig.
Was unterscheidet einen FluentWait von einem einfachen WebDriverWait?
FluentWait erlaubt eine eigene Polling-Frequenz und das Ignorieren bestimmter Ausnahmen
Richtig — das sind die zusätzlichen Stellschrauben von FluentWait.
FluentWait läuft ohne jede WebDriver-Instanz
Falsch — es arbeitet weiterhin mit einem Treiber/Element.
FluentWait kann nur auf Seitentitel warten
Falsch — es kann über eine Function/ExpectedCondition auf jede Bedingung warten.
FluentWait deaktiviert alle Timeouts
Falsch — es hat weiterhin ein Gesamt-Timeout; es ergänzt nur Polling-/Ignore-Kontrolle.
FluentWait erlaubt die Konfiguration des Polling-Intervalls und der zu ignorierenden Ausnahmetypen und bietet feinere Kontrolle als ein Standard-WebDriverWait (der selbst ein spezialisierter FluentWait ist).
Welches Befehlspaar lädt beide eine gegebene URL im aktuellen Browserfenster?
driver.get(url) und driver.navigate().to(url)
Richtig — beide laden die URL; get ist Kurzform für navigate().to.
driver.open(url) und driver.load(url)
Falsch — weder open() noch load() existieren in der WebDriver-API.
driver.goTo(url) und driver.browse(url)
Falsch — das sind keine echten WebDriver-Methoden.
driver.get(url) und driver.click(url)
Falsch — click() wirkt auf ein Element, es lädt keine URL.
driver.get(url) und driver.navigate().to(url) öffnen beide die angegebene URL; get() ist im Wesentlichen eine Kurzform von navigate().to().
Ein Tester führt diese Sequenz aus: driver.navigate().to("https://site/a"); driver.navigate().to("https://site/b"); driver.navigate().back(); driver.navigate().forward(); Welche Seite wird am Ende angezeigt?
https://site/b
Richtig — zurück zu /a, dann forward wieder zu /b.
https://site/a
Falsch — back() landet auf /a, aber forward() geht danach zu /b.
Eine leere Seite
Falsch — der Verlauf enthält weiterhin beide Seiten; nichts wird geleert.
Ein Fehler, weil forward() keinen Verlauf hat
Falsch — back() erzeugte Vorwärtsverlauf, daher gelingt forward().
Nach dem Laden von a und dann b kehrt back() zu a zurück und forward() geht wieder zu b. Die letzte Seite ist also /b.
Nachdem ein Link einen zweiten Browser-Tab geöffnet hat, warum müssen Sie driver.switchTo().window(handle) aufrufen, bevor Sie mit dem neuen Tab interagieren?
Der Fokus von WebDriver bleibt auf dem ursprünglichen Tab, bis Sie explizit zum neuen Window-Handle wechseln
Richtig — der Treiber folgt neu geöffneten Tabs nicht automatisch.
Weil der neue Tab eine andere WebDriver-Instanz hat
Falsch — alle Tabs einer Sitzung teilen denselben Treiber; nur der Fokus unterscheidet sich.
Weil Cookies nicht zwischen Tabs geteilt werden
Falsch — der Grund ist der Fokus, nicht Cookies.
Weil der implizite Wait im neuen Tab zurückgesetzt wird
Falsch — der Wechsel betrifft den Befehlsfokus, nicht den Wait-Zustand.
WebDriver behält seinen Befehlsfokus auf dem ursprünglichen Fenster, bis Sie explizit wechseln. Vor dem Wechsel gesendete Befehle zielen weiterhin auf den alten Tab.
Ein JavaScript-confirm()-Dialog erscheint mit der Frage 'Delete this item?'. Welche Selenium-API wird verwendet, um ihn zu bestätigen?
driver.switchTo().alert().accept()
Richtig — accept() des Alert-Interfaces bestätigt den Dialog.
driver.findElement(By.id("ok")).click()
Falsch — ein nativer Browserdialog ist nicht Teil des DOM und kann nicht als Element lokalisiert werden.
driver.navigate().refresh()
Falsch — ein Refresh bestätigt den Dialog nicht.
driver.quit()
Falsch — quit beendet die Sitzung, statt den Dialog zu behandeln.
Zum Alert wechseln und bestätigen: driver.switchTo().alert().accept(). Das Alert-Interface behandelt alert/confirm/prompt-Dialoge.
Welche der folgenden werden vom Interface driver.navigate() bereitgestellt? (Wählen Sie zwei.)
back()
Richtig — navigate().back() geht zum vorherigen Verlaufseintrag.
refresh()
Richtig — navigate().refresh() lädt die aktuelle Seite neu.
maximize()
Falsch — maximize() gehört zu driver.manage().window(), nicht zu navigate().
accept()
Falsch — accept() gehört zum Alert-Interface, nicht zu navigate().
navigate() bietet to(url), back(), forward() und refresh(). Es bietet kein maximize() (das ist bei Window) und keine alert()-Methode.
Um mit Elementen innerhalb eines <iframe> zu interagieren, was muss ein Test zuerst tun?
Mit driver.switchTo().frame(...) in den Frame wechseln
Richtig — iframe-Inhalte sind erst nach dem Wechsel in den Frame erreichbar.
Die Seite neu laden, um den iframe ins DOM zu integrieren
Falsch — ein Refresh integriert Frame-Kontexte nicht.
Einen impliziten Wait von mindestens 30 Sekunden setzen
Falsch — Warten ändert nichts an der Notwendigkeit, den Frame-Kontext zu wechseln.
Den iframe per JavaScript löschen
Falsch — das Entfernen des Frames zerstört genau die Elemente, die man nutzen will.
Man muss mit driver.switchTo().frame(...) in den Frame wechseln, bevor dessen Elemente erreichbar sind, und mit switchTo().defaultContent() zurückkehren.
Ein Test findet eine Liste von Zeilen, speichert das erste WebElement in einer Variablen und löst dann einen AJAX-Aufruf aus, der die gesamte Tabelle neu rendert. Beim späteren Aufruf von .click() auf dem gespeicherten Element wirft Selenium eine StaleElementReferenceException. Was ist die korrekte Erklärung und Lösung?
Die alte Referenz zeigt auf einen entfernten DOM-Knoten; das Element nach dem Neu-Rendern neu lokalisieren
Richtig — genau das bedeutet ein Stale-Element und so löst man es.
Das Element wurde nie gefunden; stattdessen NoSuchElementException abfangen
Falsch — das Element wurde ursprünglich gefunden; es wurde nach dem Neu-Rendern veraltet.
Vor dem Klick Thread.sleep(1000) hinzufügen und dieselbe Referenz wiederverwenden
Falsch — Sleep belebt eine veraltete Referenz nicht; der Knoten ist weg.
Vor dem Klick in den übergeordneten Frame wechseln
Falsch — hier ist kein Frame beteiligt; das Problem ist die veraltete Knotenreferenz.
Die gespeicherte Referenz zeigt auf einen DOM-Knoten, der durch das Neu-Rendern entfernt und neu erstellt wurde, also ist sie veraltet. Die Lösung ist, das Element nach der DOM-Änderung neu zu lokalisieren (idealerweise nach einem expliziten Wait), nicht die alte Referenz wiederzuverwenden.
Welche Praxis reduziert am direktesten flaky Selenium-Tests, die durch Timing-Probleme verursacht werden?
Feste Sleeps durch explizite Waits auf präzise Bedingungen ersetzen
Richtig — bedingungsbasiertes Warten ist das Standardmittel gegen Timing-Flakiness.
Jeden Thread.sleep auf 30 Sekunden erhöhen
Falsch — das macht Tests langsam und weiterhin fragil, nicht stabil.
Die gesamte Suite nur im Headless-Modus ausführen
Falsch — der Headless-Modus löst die Timing-Synchronisation nicht.
Alle Exceptions im Test abfangen und ignorieren
Falsch — das Verschlucken von Exceptions verbirgt Fehler, statt den Test zu stabilisieren.
Das Ersetzen fester Sleeps durch explizite Waits auf präzise Bedingungen synchronisiert den Test mit dem Anwendungszustand und verringert timingbedingte Flakiness.
Warum ist die Abhängigkeit von fest codierten, umgebungsspezifischen Testdaten (z.B. ein Benutzer, der nur auf einem Server existiert) eine Gefahr für die Teststabilität?
Der Test kann in anderen Umgebungen fehlschlagen, in denen diese Daten fehlen oder geändert sind — ohne echten Defekt
Richtig — umgebungsgebundene Daten machen Ergebnisse nicht portierbar und flaky.
Weil Selenium überhaupt keine Testdaten lesen kann
Falsch — Selenium-Tests nutzen durchaus Daten; das Problem ist die Bindung an eine Umgebung.
Weil fest codierte Daten die Tests zu sehr beschleunigen
Falsch — Geschwindigkeit ist hier nicht das Stabilitätsproblem.
Weil es die Verwendung von XPath-Locators erzwingt
Falsch — Testdaten haben keinen Einfluss auf die Locator-Strategie.
Fehlen die Daten in einer anderen Umgebung oder ändern sie sich, schlägt der Test aus Gründen fehl, die nichts mit dem getesteten Code zu tun haben. Stabile Tests richten ihre eigenen Daten ein oder isolieren sie.
Selenium meldet beim Klick auf einen Button eine ElementClickInterceptedException. Was bedeutet das typischerweise?
Ein anderes Element überdeckt das Ziel am Klickpunkt
Richtig — das ist die Bedeutung einer Click-Interception.
Das Element existiert nicht im DOM
Falsch — das wäre NoSuchElementException; hier existiert das Element, ist aber verdeckt.
Die Browser-Treiberversion ist inkompatibel
Falsch — eine Treiber-Inkompatibilität erzeugt andere Sitzungsfehler, keine Click-Interception.
Der Seitentitel ist falsch
Falsch — der Titel hat nichts mit der Click-Interception zu tun.
Ein anderes Element (ein Overlay, ein Sticky-Header, ein Cookie-Banner oder ein Spinner) verdeckt das Ziel am Klickpunkt, sodass der Klick auf dem verdeckenden Element landen würde. Auf das Verschwinden des Overlays warten oder das Ziel in einen freien Bereich scrollen.
Welche der folgenden Maßnahmen machen eine Selenium-Testsuite unabhängiger und stabiler? (Wählen Sie zwei.)
Jeder Test richtet seine eigenen Vorbedingungen ein und räumt sie auf
Richtig — in sich geschlossene Tests erben keinen kaputten Zustand von anderen.
Tests verlassen sich nicht darauf, in einer bestimmten Reihenfolge ausgeführt zu werden
Richtig — Reihenfolgeunabhängigkeit erlaubt sichere parallele und Teil-Läufe.
Alle Tests teilen sich eine einzige Browsersitzung, die nie zurückgesetzt wird
Falsch — geteilter, nicht zurückgesetzter Zustand leckt zwischen Tests und erzeugt Flakiness.
Spätere Tests hängen von Daten ab, die frühere Tests erzeugt haben
Falsch — verkettete Datenabhängigkeiten lassen einen Fehler in viele kaskadieren.
Dass jeder Test seinen eigenen Zustand aufbaut und aufräumt und dass Reihenfolgeabhängigkeiten vermieden werden, sind zentrale Stabilitätspraktiken. Eine gemeinsame Browsersitzung für alle Tests und das Verlassen auf die Ausführungsreihenfolge schaden der Unabhängigkeit.
Warum gilt ein absoluter XPath wie /html/body/div[3]/div[2]/form/button als Stabilitätsrisiko?
Jede Änderung der umgebenden DOM-Struktur bricht ihn, selbst wenn das Zielelement unverändert ist
Richtig — absolute Pfade sind gegen Layoutänderungen fragil.
Absoluter XPath wird von modernen Browsern nicht unterstützt
Falsch — er wird voll unterstützt; das Problem ist die Fragilität, nicht die Unterstützung.
Er trifft immer mehrere Elemente
Falsch — ein absoluter Pfad trifft meist einen Knoten; das Problem ist die Brüchigkeit.
Er kann nicht mit findElement verwendet werden
Falsch — By.xpath funktioniert mit findElement; das Anliegen ist die Wartbarkeit.
Absolute XPaths codieren den gesamten DOM-Pfad, sodass jede Strukturänderung (ein zusätzliches Wrapper-div, umsortierte Abschnitte) den Locator bricht, obwohl das Zielelement noch existiert. Besser sind stabile attributbasierte Locators.