A4Q Selenium Tester Probeprüfung #6 — 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.
Was ist der wesentliche Unterschied zwischen einem impliziten und einem expliziten Wait in Selenium WebDriver?
Ein impliziter Wait gilt global für alle Elementsuchen, ein expliziter Wait wartet auf eine bestimmte Bedingung an einem bestimmten Element.
Richtig: implizit wird einmal am Driver gesetzt und betrifft jedes findElement; explizit (WebDriverWait) wartet auf eine ExpectedCondition.
Ein impliziter Wait pausiert den Thread für eine feste Zeit, ein expliziter Wait pollt nie.
Falsch: das beschreibt Thread.sleep. Beide Wait-Arten pollen den DOM wiederholt bis zum Timeout.
Ein expliziter Wait ist global, ein impliziter Wait zielt auf ein einzelnes Element.
Falsch: das vertauscht beide — global ist der implizite Wait.
Es gibt keinen funktionalen Unterschied; die Begriffe sind Synonyme.
Falsch: sie verhalten sich unterschiedlich und sollten nicht gemischt werden.
Ein impliziter Wait ist ein globaler Polling-Timeout für jede Elementsuche; ein expliziter Wait zielt auf eine Bedingung an einem Element.
Ein Test sendet ein Suchformular ab. Die Ergebnisse werden per AJAX geladen und in einen Container eingefügt: nach der Antwort enthält der DOM ein div passend zum CSS-Selektor div.results li.item, davor ist der Container leer. Das Team erhält ständig eine NoSuchElementException, wenn es das erste Ergebnis direkt nach dem Klick auf Suchen prüft. Welcher Codeausschnitt lässt den Test am zuverlässigsten auf die Ergebnisse warten?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.visibilityOfElementLocated(By.cssSelector("div.results li.item")));
Richtig: pollt, bis das erste Ergebnis vorhanden und sichtbar ist — exakte Synchronisation mit dem AJAX-Rendern.
Thread.sleep(10000); danach driver.findElement(By.cssSelector("div.results li.item"));
Falsch: ein fester Sleep ist langsam und trotzdem flaky — er schlägt bei längerer Antwort fehl und verschwendet Zeit bei schneller.
driver.findElement(By.cssSelector("div.results li.item")); direkt nach dem Klick.
Falsch: genau das wirft die NoSuchElementException, weil das Element noch nicht existiert.
driver.manage().timeouts().pageLoadTimeout(Duration.ofSeconds(10));
Falsch: der pageLoadTimeout gilt für vollständige Navigationen, nicht für ein AJAX-Update im DOM.
Die richtige Lösung wartet mit einem expliziten WebDriverWait und ExpectedConditions darauf, dass das konkrete Ergebniselement sichtbar wird — kein fester Sleep, kein bloßes findElement.
Warum gilt die Verwendung von Thread.sleep() zur Synchronisation in Selenium-Tests als schlechte Praxis?
Es pausiert immer die volle feste Dauer — zu lang macht Tests langsam, zu kurz macht sie flaky.
Richtig: es passt sich nicht an die tatsächliche Ladezeit an, anders als ein pollender expliziter Wait.
Es ist veraltet und aus modernem Java entfernt.
Falsch: Thread.sleep ist eine gültige Java-Methode; das Problem ist das Verhalten, nicht eine Deprecation.
Es funktioniert nur in Firefox.
Falsch: es ist browserunabhängig — es pausiert nur den Test-Thread.
Es wirft per Design eine NoSuchElementException.
Falsch: sleep sucht keine Elemente und wirft daher keine solche Exception.
Thread.sleep wartet immer die volle feste Dauer, unabhängig von der Bereitschaft — Tests werden langsam und flaky.
Eine Checkout-Seite rendert den Bestellen-Button als <button id="placeOrder" disabled>Place order</button>. JavaScript entfernt das disabled-Attribut erst, nachdem alle Pflichtfelder validiert sind. Ein Test füllt die Felder und klickt dann, erhält aber sporadisch eine ElementClickInterceptedException / einen wirkungslosen Klick, weil der Button noch disabled ist. Welche explizite Wait-Bedingung synchronisiert den Klick am besten?
ExpectedConditions.elementToBeClickable(By.id("placeOrder"))
Richtig: wartet, bis der Button sichtbar und aktiviert (nicht disabled) ist, sodass der Klick greift.
ExpectedConditions.presenceOfElementLocated(By.id("placeOrder"))
Falsch: der Button ist von Anfang an im DOM, presence ist sofort erfüllt — auch wenn er noch disabled ist.
ExpectedConditions.visibilityOfElementLocated(By.id("placeOrder"))
Falsch: der disabled-Button ist bereits sichtbar; visibility prüft den enabled-Zustand nicht.
ExpectedConditions.titleContains("Checkout")
Falsch: der Seitentitel hat nichts mit dem Aktivieren des Buttons zu tun.
elementToBeClickable wartet, bis das Element sichtbar UND aktiviert ist — genau die hier fehlende Bedingung.
Warum warnt die Selenium-Dokumentation davor, implizite und explizite Waits im selben Test zu kombinieren?
Die beiden Timeouts können sich unvorhersehbar addieren und viel längere Waits als erwartet verursachen.
Richtig: das dokumentierte Risiko sind unvorhersehbare, aufaddierte Wartezeiten.
Explizite Waits funktionieren gar nicht mehr, sobald ein impliziter Wait gesetzt ist.
Falsch: explizite Waits funktionieren weiter; das Problem ist unvorhersehbares Timing, kein Totalausfall.
Implizite Waits werfen einen Kompilierfehler, wenn ein expliziter Wait existiert.
Falsch: es gibt keinen Kompilierkonflikt; beide sind gültige API-Aufrufe.
Die Kombination lässt den Browser automatisch headless laufen.
Falsch: Waits haben nichts mit dem Headless-Modus zu tun.
Die Kombination kann Timeouts unvorhersehbar addieren und schwer nachvollziehbare Wartezeiten erzeugen.
Ein Bestätigungs-Banner ist beim Laden bereits im DOM als <div id="banner" style="display:none">Saved</div> und wird erst nach dem Speichern angezeigt (display geändert). Ein Test muss prüfen, dass das Banner dem Nutzer tatsächlich erscheint. presenceOfElementLocated(By.id("banner")) ist schon vor dem Speichern erfüllt. Welche Bedingung wartet korrekt darauf, dass das Banner sichtbar wird?
ExpectedConditions.visibilityOfElementLocated(By.id("banner"))
Richtig: visibility verlangt, dass das Element angezeigt wird und eine Größe hat — passend zur Nutzer-sichtbaren Prüfung.
ExpectedConditions.presenceOfElementLocated(By.id("banner"))
Falsch: schon beim Laden erfüllt, da das versteckte div im DOM ist — wartet nicht auf die Anzeige.
ExpectedConditions.invisibilityOfElementLocated(By.id("banner"))
Falsch: das wartet auf das Verschwinden — das Gegenteil der Anforderung.
ExpectedConditions.numberOfElementsToBe(By.id("banner"), 1)
Falsch: die Anzahl ist bereits 1, während es noch versteckt ist — bestätigt keine Sichtbarkeit.
presence prüft nur, dass das Element im DOM ist; visibility verlangt zusätzlich, dass es angezeigt wird (kein display:none, Größe > 0).
Welche der folgenden sind echte ExpectedConditions von Selenium für explizite Waits? (Wählen Sie zwei.)
textToBePresentInElement
Richtig: eine echte Bedingung, die auf bestimmten Text in einem Element wartet.
alertIsPresent
Richtig: eine echte Bedingung, die wartet, bis ein JavaScript-Alert vorhanden ist.
elementToBeColored
Falsch: eine solche ExpectedCondition gibt es in Selenium nicht.
pageToBeFastEnough
Falsch: das ist keine echte ExpectedCondition.
textToBePresentInElement und alertIsPresent sind echte ExpectedConditions; die anderen beiden sind erfunden.
Ein FluentWait wird in Java als new FluentWait<>(driver).withTimeout(...).pollingEvery(...).ignoring(...) konfiguriert. Welche zwei Aussagen über FluentWait sind korrekt? (Wählen Sie zwei.)
Mit pollingEvery lässt sich festlegen, wie häufig die Bedingung geprüft wird.
Richtig: das Polling-Intervall ist in FluentWait explizit konfigurierbar.
Man kann Exception-Typen angeben, die beim Polling ignoriert werden, z. B. NoSuchElementException.
Richtig: ignoring() listet Exceptions, die den Wait nicht vorzeitig beenden sollen.
FluentWait garantiert, dass das Element immer innerhalb des Timeouts gefunden wird.
Falsch: wird die Bedingung nie wahr, wirft es eine TimeoutException.
FluentWait kann nur mit Firefox verwendet werden.
Falsch: es ist browserunabhängig wie alle WebDriver-Waits.
FluentWait erlaubt das Setzen des Polling-Intervalls und der während des Pollings zu ignorierenden Exception-Typen; es ist eine Verallgemeinerung von WebDriverWait.
Was beschreibt einen flaky Test in der Testautomatisierung am besten?
Ein Test, der bei gleichem Code und gleicher Umgebung ohne Änderungen mal besteht, mal fehlschlägt.
Richtig: nicht-deterministische Ergebnisse ohne Codeänderung sind die Definition von Flakiness.
Ein Test, der nach einer Codeänderung immer fehlschlägt.
Falsch: ein konstant fehlschlagender Test ist deterministisch, nicht flaky.
Ein Test, der länger als eine Minute läuft.
Falsch: Langsamkeit ist nicht dasselbe wie nicht-deterministische Ergebnisse.
Ein Test ohne Assertions.
Falsch: fehlende Assertions sind ein anderer Mangel, keine Flakiness.
Ein flaky Test liefert bei unverändertem Code unterschiedliche Ergebnisse (bestanden/fehlgeschlagen).
Ein Test iteriert über eine Liste von Zeilen, liest je Zeile eine Zelle, klickt einen Edit-Link, der die Tabelle per AJAX neu lädt, und setzt dann die Schleife fort. In der zweiten Iteration wirft er häufig eine StaleElementReferenceException. Was ist die Ursache und die richtige Lösung?
Die gespeicherten Referenzen werden nach dem AJAX-Reload abgelöst; die Elemente nach jedem Reload neu lokalisieren (z. B. findElements erneut ausführen) statt alte Referenzen wiederzuverwenden.
Richtig: stale Referenzen zeigen auf nicht mehr angehängte Knoten; erneutes Suchen löst es.
Der Locator ist falsch; jedes By.id in By.xpath ändern.
Falsch: der Locator funktioniert in der ersten Iteration — das Problem ist Staleness nach dem Reload, nicht die Locator-Strategie.
Einen großen impliziten Wait hinzufügen; das beseitigt die StaleElementReferenceException.
Falsch: ein impliziter Wait aktualisiert bereits erfasste Referenzen nicht — die Staleness bleibt.
Den Browser im Headless-Modus ausführen.
Falsch: der Headless-Modus ändert das Ablöseverhalten des DOM nicht.
Nach dem AJAX-Reload zeigen die zuvor gespeicherten WebElement-Referenzen auf abgelöste DOM-Knoten; sie müssen in der Schleife nach jedem Reload neu lokalisiert werden.
Welche Praxis verbessert die Stabilität einer Testsuite, die in einer CI-Pipeline wiederholt laufen muss, am meisten?
Jeden Test unabhängig und in sich geschlossen machen, mit eigenem Auf- und Abbau der Testdaten.
Richtig: Unabhängigkeit beseitigt Reihenfolge- und Shared-State-Fehler — der größte Stabilitätsgewinn in CI.
Jedes Thread.sleep auf mindestens 30 Sekunden erhöhen.
Falsch: längere feste Sleeps verlangsamen die Suite und beseitigen die zugrunde liegende Nicht-Determiniertheit nicht.
Alle Tests eine Browser-Session und einen Datensatz teilen lassen, um Zeit zu sparen.
Falsch: geteilter Zustand zwischen Tests ist eine Hauptursache reihenfolgeabhängiger Flakiness.
Jede Exception fangen und verschlucken, damit Tests nie Fehler melden.
Falsch: Fehler zu verbergen macht Tests nutzlos, nicht stabil.
Unabhängige, in sich geschlossene Tests, die ihre eigenen Daten auf- und abbauen, vermeiden Reihenfolge-Abhängigkeiten und Shared-State-Flakiness.
Ein Team bemerkt, dass einige wenige Tests nur fehlschlagen, wenn das CI-Grid stark ausgelastet ist und Agents langsam antworten, lokal aber immer bestehen. Was ist die wahrscheinlichste Ursache?
Timing-Annahmen, die lokal gelten, brechen, wenn das ausgelastete Grid Seiten langsamer rendert, als die Waits erlauben.
Richtig: umgebungsabhängiges Timing ist ein klassischer Flake; Abhilfe sind robuste explizite Waits, keine festen Verzögerungen.
Der Anwendungsquellcode ist auf dem Grid anders als lokal.
Falsch: normalerweise wird derselbe Build deployt; der Unterschied ist Timing/Last, nicht der Quellcode.
WebDriver kann auf ausgelasteten Maschinen überhaupt nicht laufen.
Falsch: WebDriver läuft unter Last; es legt nur fragile Timing-Annahmen offen.
Die Assertions sind zu streng und sollten entfernt werden.
Falsch: Assertions zu entfernen verbirgt das Problem; die Ursache ist Timing, nicht die Prüfungen.
Fest kodierte Timing-Annahmen (feste Sleeps oder zu kurze Waits) brechen in langsameren, ausgelasteten Umgebungen — ein klassischer umgebungsabhängiger Timing-Flake.
Welcher Locator-Ansatz verbessert die langfristige Stabilität von UI-Tests gegen ein sich häufig änderndes Frontend am meisten?
Stabile, dedizierte Attribute wie data-test oder eine feste id gegenüber absoluten XPath und Styling-Klassen bevorzugen.
Richtig: eigens angelegte Test-Hooks überstehen Layout- und Stylingänderungen und reduzieren Locator-Brüche.
Immer absolute XPath ab der html-Wurzel verwenden, z. B. /html/body/div[3]/div[2]/table/tr[4]/td[2].
Falsch: absolute XPath ist extrem brüchig — jede Strukturänderung bricht es.
Elemente über ihre generierte Framework-Klasse wie css-1a2b3c ansprechen.
Falsch: gehashte Framework-Klassen ändern sich bei jedem Build und sind instabile Locators.
Jedes Element über seine exakten Pixelkoordinaten ansprechen.
Falsch: Koordinaten sind keine WebDriver-Locator-Strategie und brechen bei jeder Layoutänderung.
Stabile, aussagekräftige Hooks wie dedizierte data-test-Attribute sind weit weniger brüchig als absolute XPath oder generierte CSS-Klassen.
Welche zwei der folgenden sind häufige Ursachen flaky Selenium-Tests? (Wählen Sie zwei.)
Race Conditions durch Interaktion mit Elementen, bevor sie bereit sind (fehlende explizite Waits).
Richtig: Handeln vor UI-Bereitschaft ist eine Hauptquelle von Flakiness.
Tests, die von geteilten oder übrig gebliebenen Daten früherer Tests abhängen.
Richtig: geteilter/übrig gebliebener Zustand erzeugt reihenfolgeabhängige, nicht-deterministische Ergebnisse.
Verwendung eines Page Object Model zur Strukturierung der Tests.
Falsch: POM verbessert die Wartbarkeit und reduziert Flakiness eher, statt sie zu verursachen.
Hinzufügen aussagekräftiger Assertion-Meldungen.
Falsch: Assertion-Meldungen helfen beim Debuggen und beeinflussen die Determiniertheit nicht.
Race Conditions durch fehlende Synchronisation und Abhängigkeit von geteiltem oder übrig gebliebenem Zustand sind zwei klassische Flakiness-Ursachen.
Ein Team will Flakiness reduzieren, ohne echte Defekte zu verbergen. Welche zwei Maßnahmen sind geeignet? (Wählen Sie zwei.)
Feste Thread.sleep-Aufrufe durch explizite WebDriverWait-Bedingungen ersetzen.
Richtig: Synchronisation auf echte Bedingungen beseitigt Race-Condition-Flakiness, ohne Defekte zu verdecken.
Als flaky erkannte Tests isolieren und ihre Ursache untersuchen, bevor sie wieder aktiviert werden.
Richtig: flaky Tests zu isolieren und zu diagnostizieren hält das Signal vertrauenswürdig, während die Ursache behoben wird.
Jeden fehlschlagenden Test automatisch bis zu 10-mal wiederholen und als bestanden melden, wenn ein Versuch besteht.
Falsch: blinde Retries verbergen echte sporadische Defekte und lassen reale Bugs durch.
Die Assertions aus flaky Tests entfernen, damit sie nicht mehr fehlschlagen können.
Falsch: Assertions zu entfernen macht den Test wertlos und verbirgt Defekte vollständig.
Feste Sleeps durch explizite Waits ersetzen und flaky Tests isolieren/untersuchen ist sinnvoll; pauschales Retry-bis-grün und Assertions löschen verbergen Defekte.
Welche WebDriver-Methode lädt die aktuelle Seite neu, entsprechend dem Aktualisieren-Button des Browsers?
driver.navigate().refresh()
Richtig: refresh() lädt die aktuelle Seite neu.
driver.navigate().back()
Falsch: back() geht zum vorherigen Eintrag in der Historie, kein Reload.
driver.get("about:blank")
Falsch: das navigiert zu einer leeren Seite, kein Neuladen der aktuellen.
driver.close()
Falsch: close() schließt das aktuelle Fenster/Tab; kein Refresh.
driver.navigate().refresh() lädt die aktuelle URL neu; die anderen navigate-Methoden bewegen sich in der Historie oder zu einer neuen URL.
Eine Seite bettet ein Zahlungsformular in <iframe id="payframe" src="..."> ein. Ein Test macht driver.switchTo().frame("payframe"), gibt die Kartennummer ein und sendet ab. Danach muss er einen Continue-Button auf der Hauptseite (außerhalb des iframe) klicken, aber findElement wirft eine NoSuchElementException. Was muss der Test zuerst tun?
driver.switchTo().defaultContent() aufrufen, um den Fokus zum Hauptdokument zurückzugeben, bevor der Continue-Button lokalisiert wird.
Richtig: nach der Arbeit im iframe muss man zum obersten Dokument zurückwechseln, um Hauptseiten-Elemente zu erreichen.
driver.switchTo().frame("payframe") ein zweites Mal aufrufen.
Falsch: erneutes Wechseln in denselben Frame behält den Fokus im iframe, nicht auf der Hauptseite.
driver.manage().window().maximize() hinzufügen.
Falsch: die Fenstergröße hat nichts mit dem Frame-Kontext zu tun.
Den impliziten Wait auf 30 Sekunden erhöhen.
Falsch: das Element ist wegen des Frame-Kontexts unerreichbar, nicht wegen Timing — längeres Warten schlägt weiter fehl.
WebDriver bleibt auf den iframe fokussiert, bis man mit switchTo().defaultContent() zum obersten Dokument zurückwechselt.
Ein Klick auf einen Löschen-Button öffnet einen nativen JavaScript-Bestätigungsdialog (window.confirm) mit "Delete this item?". Der Test muss ihn bestätigen, um fortzufahren. Welche Sequenz ist korrekt?
driver.switchTo().alert().accept();
Richtig: zum Alert wechseln und accept() aufrufen bestätigt den nativen Dialog.
driver.findElement(By.xpath("//button[text()='OK']")).click();
Falsch: ein nativer confirm-Dialog gehört nicht zum DOM und kann nicht per findElement lokalisiert werden.
driver.switchTo().alert().dismiss();
Falsch: dismiss() bricht den Dialog ab (Cancel) und führt die Löschung nicht aus.
driver.navigate().refresh();
Falsch: das Neuladen der Seite verwirft den Dialog und die Löschaktion.
Man muss zum Alert wechseln und accept() aufrufen; ein normales findElement kann native Browserdialoge nicht bedienen.
Eine Produktseite hat ein Dropdown <select id="qty"><option value="1">1</option><option value="2">2</option><option value="3">3</option></select>. Der Test soll die Option mit dem sichtbaren Text "2" wählen. Welcher Selenium-Code wählt sie korrekt aus?
new Select(driver.findElement(By.id("qty"))).selectByVisibleText("2");
Richtig: Select.selectByVisibleText ist die vorgesehene API für Standard-select-Dropdowns.
driver.findElement(By.id("qty")).sendKeys("2");
Falsch: sendKeys auf ein select ist unzuverlässig und nicht der Standardweg, eine Option per Text zu wählen.
driver.findElement(By.id("qty")).click();
Falsch: ein einzelner Klick öffnet nur das Dropdown; er wählt die Option "2" nicht aus.
new Select(driver.findElement(By.id("qty"))).deselectAll();
Falsch: deselectAll hebt Auswahlen auf und funktioniert nur bei Mehrfachauswahl; es wählt "2" nicht.
Die Support-Klasse Select bietet selectByVisibleText für Standard-HTML-select-Elemente.
Was ist der Unterschied zwischen driver.close() und driver.quit() in Selenium WebDriver?
close() schließt nur das aktuelle Fenster, quit() schließt alle Fenster und beendet die Session.
Richtig: das ist die dokumentierte Unterscheidung.
close() beendet die Session, quit() schließt nur das aktuelle Fenster.
Falsch: das vertauscht die beiden Methoden.
Sie sind identisch und austauschbar.
Falsch: sie unterscheiden sich im Umfang — ein Fenster gegenüber der ganzen Session.
close() löscht Cookies, quit() lädt die Seite neu.
Falsch: keine der Methoden betrifft Cookies oder Neuladen.
close() schließt nur das aktuelle Fenster/Tab; quit() schließt alle Fenster und beendet die WebDriver-Session.
Ein Test bewegt den Zeiger über ein Products-Menü, um ein Untermenü einzublenden, und klickt dann den Laptops-Link, der nur beim Hover erscheint. Ein einfacher Klick auf den versteckten Link schlägt fehl. Welcher Selenium-Ansatz führt Hover-dann-Klick korrekt aus?
new Actions(driver).moveToElement(productsMenu).click(laptopsLink).perform();
Richtig: Actions.moveToElement hovert und blendet das Untermenü ein, dann klickt click den nun sichtbaren Link; perform() führt aus.
laptopsLink.click(); direkt ohne jeden Hover aufgerufen.
Falsch: der Link ist erst nach dem Hover bedienbar, daher schlägt der direkte Klick fehl.
driver.navigate().to(productsMenu.getText());
Falsch: das missbraucht navigate mit Menütext als URL und führt weder Hover noch Klick aus.
new Select(productsMenu).selectByVisibleText("Laptops");
Falsch: Select funktioniert nur bei <select>-Elementen, nicht bei einem Hover-Navigationsmenü.
Die Actions-Klasse verkettet moveToElement (Hover) und click, um Hover-Menüs zu bedienen.
Ein Klick auf einen Report-Link öffnet einen neuen Browser-Tab. Der Test muss einen Wert im neuen Tab lesen und dann zum ursprünglichen Tab zurückkehren. Welche zwei Schritte sind erforderlich? (Wählen Sie zwei.)
driver.getWindowHandles() erfassen und mit driver.switchTo().window(newHandle) zum neuen Handle wechseln.
Richtig: Handles aufzählen und per Handle wechseln ist der Standardweg, im neuen Tab zu arbeiten.
Das ursprüngliche Handle vorher speichern und mit driver.switchTo().window(originalHandle) zurückwechseln.
Richtig: das ursprüngliche Handle zu behalten erlaubt die Rückkehr zum ersten Tab nach dem Lesen des neuen.
driver.switchTo().frame(1) aufrufen, um den neuen Tab zu erreichen.
Falsch: frame() wechselt zwischen iframes innerhalb eines Dokuments, nicht zwischen Browser-Tabs.
driver.navigate().forward() verwenden, um in den neuen Tab zu wechseln.
Falsch: forward() bewegt sich in der Historie des aktuellen Tabs; es wechselt keine Tabs.
Man erfasst die Window-Handles und nutzt switchTo().window(handle), um zwischen Tabs zu wechseln; getWindowHandles liefert alle offenen Handles.
Was ist der Hauptzweck des Page Object Model (POM) in der Selenium-Testautomatisierung?
Locators und Interaktionen einer Seite in einer eigenen Klasse zu kapseln, was Wartbarkeit und Wiederverwendung verbessert.
Richtig: das Zentralisieren von Locators/Aktionen pro Seite ist der Kernvorteil von POM.
Den Browser durch Caching von Seiten schneller zu machen.
Falsch: POM ist ein Strukturmuster, kein Performance-/Caching-Mechanismus.
Die Notwendigkeit jeglicher Locators zu ersetzen.
Falsch: POM verwendet weiterhin Locators — es organisiert sie nur in Seitenklassen.
Testdaten automatisch zu generieren.
Falsch: die Generierung von Testdaten hat nichts mit POM zu tun.
POM kapselt Locators und Interaktionen einer Seite in einer Klasse, sodass Tests lesbar sind und Locatoränderungen an einer Stelle erfolgen.
In einem Page Object ist eine login-Methode so geschrieben: public DashboardPage login(String user, String pass) { type(userField, user); type(passField, pass); click(submitBtn); return new DashboardPage(driver); }. Warum gibt die Methode ein neues DashboardPage zurück statt void?
Weil ein erfolgreicher Login auf dem Dashboard landet; die Rückgabe dieses Page Objects modelliert die Navigation und erlaubt das Verketten der nächsten Aktionen.
Richtig: das resultierende Page Object zurückzugeben ist der idiomatische POM-Weg, Seitenübergänge darzustellen.
Weil eine Methode in Java immer ein Objekt zurückgeben muss.
Falsch: Java-Methoden können void zurückgeben; der Rückgabetyp hier ist eine bewusste Design-Entscheidung.
Weil die Rückgabe von DashboardPage den Login schneller macht.
Falsch: der Rückgabetyp beeinflusst die Ausführungsgeschwindigkeit nicht.
Weil es Locators auf dem Dashboard überflüssig macht.
Falsch: das DashboardPage definiert weiterhin eigene Locators; die Rückgabe entfernt sie nicht.
Die Rückgabe des nächsten Page Objects modelliert das Navigationsergebnis und ermöglicht lesbare, verkettbare Testabläufe über Seiten hinweg.
Welche Aussage spiegelt eine gute Trennung der Zuständigkeiten bei Verwendung des Page Object Model am besten wider?
Page Objects bieten Aktionen und Seitenzustand, während Assertions in den Testmethoden liegen.
Richtig: Assertions in Tests und Verhalten in Page Objects zu halten ist die empfohlene Trennung.
Jede Assertion sollte in die Page-Object-Methoden gelegt werden.
Falsch: Assertions in Page Objects koppeln sie an bestimmte Tests und mindern die Wiederverwendung.
Die WebDriver-Instanz sollte in jeder Page-Object-Methode erzeugt werden.
Falsch: der Driver wird typischerweise geteilt/injiziert, nicht pro Methode neu erzeugt.
Locators sollten direkt in jeder Testmethode fest kodiert werden, nicht im Page Object.
Falsch: das untergräbt POM — Locators gehören zentral ins Page Object.
Assertions gehören in die Tests; Page Objects bieten Aktionen und Zustand, sollten aber die Assertions des Tests nicht enthalten.
Ein UI-Redesign ändert die id des Login-Buttons von loginBtn zu signInBtn. Wie viele Stellen müssen in einer gut strukturierten POM-Suite mit 30 Tests, die sich anmelden, aktualisiert werden?
Eine — die einzelne Locator-Definition in der LoginPage-Klasse.
Richtig: zentralisierte Locators bedeuten, dass eine Änderung alle 30 Tests abdeckt.
Dreißig — eine pro Test, der sich anmeldet.
Falsch: genau das vermeidet POM; duplizierte Locators wären das Anti-Muster.
Keine — Selenium aktualisiert Locators automatisch.
Falsch: Selenium heilt Locators nicht automatisch; die Definition muss manuell geändert werden.
Zwei — der Locator plus die Browser-Driver-Konfiguration.
Falsch: die Driver-Konfiguration hat nichts mit einer Locator-id-Änderung zu tun.
Mit POM ist der Locator einmal in der LoginPage-Klasse definiert, sodass nur diese eine Definition geändert wird.
Welche Beziehung zwischen Testdaten und Page Objects wird in einem wartbaren Selenium-Framework empfohlen?
Page-Object-Methoden nehmen Daten als Parameter von den Tests entgegen, wodurch die Page Objects wiederverwendbar bleiben.
Richtig: Daten zu übergeben hält Page Objects generisch und szenarioübergreifend wiederverwendbar.
Jedes Page Object sollte einen bestimmten Benutzernamen und ein Passwort fest kodieren.
Falsch: fest kodierte Daten binden das Page Object an ein Szenario und schaden der Wiederverwendung.
Testdaten müssen in der WebDriver-Instanz gespeichert werden.
Falsch: die WebDriver-Instanz ist kein Datenspeicher für Testwerte.
Page Objects sollten Zufallsdaten erzeugen und nie Parameter annehmen.
Falsch: erzwungene Zufallsdaten nehmen die Kontrolle über Testbedingungen und Reproduzierbarkeit.
Page Objects sollten mit von Tests übergebenen Daten parametrisiert werden, damit sie wiederverwendbar bleiben und nicht an feste Werte gebunden sind.
Welche zwei sind echte Vorteile der Anwendung des Page Object Model? (Wählen Sie zwei.)
Weniger Code-Duplizierung, da Locators und Aktionen einmal pro Seite definiert sind.
Richtig: Zentralisierung reduziert Duplizierung über Tests hinweg.
Bessere Wartbarkeit, da UI-Änderungen in einer Seitenklasse behandelt werden.
Richtig: Aktualisierungen an einer Stelle für Locators sind ein zentraler Wartbarkeitsvorteil.
Es macht jegliche expliziten Waits überflüssig.
Falsch: Synchronisation ist weiterhin nötig; POM ersetzt keine Waits.
Es garantiert, dass die Tests nie flaky sein können.
Falsch: POM verbessert die Struktur, beseitigt aber keine Timing- oder Umgebungs-Flakiness.
POM reduziert Code-Duplizierung und verbessert die Wartbarkeit durch zentrale Locators; es beseitigt keine Waits und garantiert keine Flakiness-Freiheit.
Gegeben das Markup <input type="email" name="email" data-test="signup-email" class="form-control ng-untouched">: Welcher Locator ist die robusteste Wahl für einen Test, der Styling- und Framework-Zustandsänderungen überstehen muss?
By.cssSelector("[data-test='signup-email']")
Richtig: ein eigens angelegtes data-test-Attribut ist stabil gegen Styling- und Framework-Zustandsänderungen.
By.cssSelector(".form-control.ng-untouched")
Falsch: ng-untouched ist eine flüchtige Framework-Zustandsklasse, die sich bei Interaktion ändert und den Locator bricht.
By.xpath("/html/body/div[2]/form/div[1]/input")
Falsch: ein absoluter XPath ist extrem brüchig und bricht bei jeder Strukturänderung.
By.className("form-control")
Falsch: form-control ist eine generische, geteilte Klasse, die wahrscheinlich viele Inputs trifft — nicht eindeutig.
Das dedizierte data-test-Attribut ist stabil; class-Werte enthalten Framework-/Zustandsrauschen (ng-untouched), das sich zur Laufzeit ändert.
Eine Tabellenzeile ist <tr><td>SKU-9921</td><td>In stock</td><td><button>Reorder</button></td></tr> unter vielen Zeilen. Der Test muss den Reorder-Button in der Zeile klicken, deren erste Zelle den Text SKU-9921 hat. Welcher XPath wählt diesen Button korrekt?
//td[text()='SKU-9921']/ancestor::tr//button
Richtig: es verankert auf der SKU-Zelle, steigt zur Zeile auf und wählt den button in derselben Zeile.
//button[text()='Reorder']
Falsch: das trifft jeden Reorder-Button der Tabelle, nicht den zu SKU-9921 gehörenden.
//td[text()='SKU-9921']/button
Falsch: der button ist kein direktes Kind der SKU-Zelle; er steht in einer Geschwisterzelle derselben Zeile.
//tr[1]//button
Falsch: das zielt per Position auf die erste Zeile, die nicht die SKU-9921-Zeile sein muss.
Man lokalisiert das td über seinen exakten Text, geht zum ancestor tr hinauf und findet dann den button in dieser Zeile.
Der DOM enthält <a href="/logout" class="nav-link"> Log out </a> mit führenden und nachfolgenden Leerzeichen um den Text. Welcher XPath trifft den Link trotz der umgebenden Leerzeichen zuverlässig über seinen sichtbaren Text?
//a[normalize-space()='Log out']
Richtig: normalize-space() entfernt die umgebenden Leerzeichen, sodass der Text sauber passt.
//a[text()='Log out']
Falsch: der exakte Textknoten enthält die führenden/nachfolgenden Leerzeichen, ein striktes Match schlägt fehl.
//a[@class='nav-link'][1]
Falsch: das stützt sich auf Klasse und Position statt auf den sichtbaren Text und könnte einen anderen Nav-Link treffen.
//a[contains(@href,'Log out')]
Falsch: es durchsucht das href-Attribut (/logout) nach 'Log out', das dort nicht vorkommt.
normalize-space() kürzt und komprimiert Whitespace, sodass 'Log out' auch mit umgebenden Leerzeichen passt; ein striktes text()='Log out' würde fehlschlagen.
Welcher CSS-Selektor trifft ein input, dessen id-Attributwert mit dem Suffix _email endet, z. B. user_email oder admin_email?
input[id$='_email']
Richtig: $= ist der 'endet-mit'-Attributoperator in CSS.
input[id^='_email']
Falsch: ^= bedeutet 'beginnt mit' und träfe ids, die mit _email anfangen.
input[id*='_email']
Falsch: *= bedeutet 'enthält' und ist breiter als das geforderte endet-mit.
input[id='_email']
Falsch: das verlangt, dass die id exakt _email ist, und trifft weder user_email noch admin_email.
Der CSS-Attributselektor [id$='_email'] trifft Werte, die auf den angegebenen Teilstring enden.
Warum sind id und name allgemein bevorzugte Locator-Strategien gegenüber XPath, wenn eine stabile id verfügbar ist?
Eine stabile id/name ist einfach, eindeutig und weniger brüchig als ein komplexer XPath-Ausdruck.
Richtig: eine gute id ist der direkteste und robusteste Locator, wenn vorhanden.
XPath kann Elemente gar nicht über die id finden.
Falsch: XPath kann auf @id matchen; es geht um Einfachheit und Robustheit, nicht um Fähigkeit.
id-Locators warten automatisch auf das Laden des Elements.
Falsch: keine Locator-Strategie fügt von sich aus Warten hinzu; Synchronisation ist getrennt.
name-Locators funktionieren nur im Headless-Modus.
Falsch: Locator-Strategien sind unabhängig vom Headless-Modus.
id/name-Suchen sind einfach, schnell und weniger brüchig; komplexe XPath sind fragiler und können langsamer sein.
Gegeben <button data-test="save" class="btn primary" type="submit">Save</button>: Welche zwei Locators würden diesen Button korrekt treffen? (Wählen Sie zwei.)
By.cssSelector("button[data-test='save']")
Richtig: das data-test-Attribut ist vorhanden und identifiziert den Button eindeutig.
By.cssSelector("button.btn.primary")
Richtig: der zusammengesetzte Klassenselektor trifft ein Element mit den Klassen btn und primary.
By.id("save")
Falsch: der Button hat kein id-Attribut, nur data-test='save', daher trifft By.id nicht.
By.name("save")
Falsch: das Element hat kein name-Attribut, daher schlägt By.name fehl.
Der data-test-Attributselektor und der zusammengesetzte Klassenselektor treffen beide; die id- und name-Selektoren nicht, da das Element weder id noch name hat.
Was macht die Methode driver.get(String url) in Selenium WebDriver?
Es lädt die angegebene URL im aktuellen Browserfenster und wartet auf das Laden der Seite.
Richtig: get() öffnet die URL und blockiert, bis das Laden abgeschlossen ist.
Es gibt den HTTP-Antwortkörper als String zurück.
Falsch: get() gibt void zurück und steuert den Browser; es liefert nicht den Antwortkörper.
Es liest den Wert eines Formularfelds aus.
Falsch: einen Feldwert liest man mit getAttribute oder getText, nicht mit driver.get.
Es schließt die aktuelle Browser-Session.
Falsch: die Session schließt quit(); get() öffnet eine URL.
get() navigiert den Browser zur angegebenen URL und wartet, bis der Seitenladevorgang abgeschlossen ist.
Ein Element ist <input id="promo" value="WELCOME10">. Während des Tests tippt ein Nutzer SUMMER darüber, aber das sichtbare DOM-Attribut zeigt im Seitenquelltext weiterhin value="WELCOME10". Der Test braucht den aktuellen Text, den der Nutzer im Feld sieht. Welcher Aufruf liefert SUMMER?
element.getAttribute("value")
Richtig: getAttribute("value") spiegelt die aktuelle value-Property und gibt das getippte SUMMER zurück.
element.getText()
Falsch: getText() liefert den sichtbaren Innentext, der bei einem <input> leer ist.
element.getTagName()
Falsch: getTagName() gibt 'input' zurück, nicht den Feldwert.
element.getCssValue("value")
Falsch: getCssValue liest CSS-Eigenschaften, nicht den value des Inputs.
getAttribute("value") liefert die aktuelle value-Property (SUMMER), während das statische HTML-Attribut noch WELCOME10 sein kann; getText() gibt bei Inputs Leerstring zurück.
Warum ist es in JUnit-basierten Selenium-Tests gute Praxis, den WebDriver in einer @BeforeEach-Methode zu instanziieren und driver.quit() in einer @AfterEach-Methode aufzurufen?
Es gibt jedem Test eine saubere, isolierte Browser-Session und gibt den Driver danach zuverlässig frei.
Richtig: frisches Setup und garantiertes Teardown pro Test maximieren Isolation und Stabilität.
Es lässt die Tests automatisch parallel laufen.
Falsch: Parallelität wird vom Test-Runner konfiguriert, nicht allein durch Setup/Teardown pro Test.
Es macht jegliche Locators überflüssig.
Falsch: Lifecycle-Methoden ändern nichts daran, wie Elemente lokalisiert werden.
Es garantiert, dass die Anwendung keine Defekte hat.
Falsch: Setup/Teardown organisiert Tests; es kann keine defektfreie Anwendung garantieren.
Setup/Teardown pro Test gibt jedem Test eine saubere, isolierte Browser-Session und gibt den Driver frei — das verbessert Unabhängigkeit und Stabilität.
Welche Exception wirft Selenium, wenn findElement kein Element findet, das dem angegebenen Locator entspricht?
NoSuchElementException
Richtig: das ist die von findElement geworfene Exception, wenn nichts passt.
TimeoutException
Falsch: TimeoutException wirft ein Wait, dessen Bedingung nie wahr wird, nicht ein einfaches findElement.
StaleElementReferenceException
Falsch: die tritt auf, wenn ein zuvor gefundenes Element nicht mehr am DOM hängt, nicht wenn nichts gefunden wird.
ElementClickInterceptedException
Falsch: die wird geworfen, wenn ein anderes Element einen Klick abfängt, nicht bei fehlgeschlagener Suche.
findElement wirft eine NoSuchElementException, wenn kein passendes Element gefunden wird.
Was ist der Unterschied zwischen findElement und findElements in Selenium WebDriver?
findElement gibt das erste passende Element zurück oder wirft, wenn keines existiert; findElements gibt eine Liste zurück, leer bei keinem Treffer.
Richtig: das ist der dokumentierte Verhaltensunterschied.
Beide werfen NoSuchElementException, wenn nichts passt.
Falsch: findElements gibt eine leere Liste zurück, statt zu werfen.
findElements gibt nur das letzte passende Element zurück.
Falsch: findElements gibt alle Treffer als Liste zurück, nicht nur den letzten.
findElement funktioniert nur mit XPath, findElements nur mit CSS.
Falsch: beide akzeptieren jede By-Locator-Strategie.
findElement gibt den ersten Treffer zurück oder wirft NoSuchElementException; findElements gibt eine Liste zurück, die bei keinem Treffer leer ist.
Welche zwei Aussagen über Selenium WebDriver sind korrekt? (Wählen Sie zwei.)
Es automatisiert echte Browser über deren native Automatisierungsunterstützung.
Richtig: WebDriver steuert echte Browser über ihre Automatisierungsschnittstellen.
Es bietet offizielle Sprach-Bindings wie Java, Python, C# und JavaScript.
Richtig: WebDriver bietet mehrere offizielle Bindings und ist damit sprachunabhängig.
Es ist selbst ein Unit-Test-Framework, das JUnit oder TestNG ersetzt.
Falsch: WebDriver steuert den Browser; man braucht weiterhin einen Test-Runner wie JUnit oder TestNG.
Es erfordert einen gesetzten impliziten Wait, sonst findet es kein Element.
Falsch: WebDriver findet Elemente auch ohne impliziten Wait; der Wait fügt nur Polling-Toleranz hinzu.
WebDriver steuert echte Browser über deren Automatisierungsschnittstellen und ist über offizielle Bindings sprachunabhängig; es ist kein Test-Runner und benötigt keinen impliziten Wait, um zu funktionieren.