A4Q Selenium Tester Probeprüfung #2 — 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 Rolle spielt die WebDriver-Schnittstelle in Selenium 4 in erster Linie?
Sie definiert eine gemeinsame, browserunabhängige API, die konkrete Treiber (ChromeDriver, FirefoxDriver) implementieren, um einen echten Browser zu steuern.
Richtig — WebDriver ist die Schnittstelle; jeder Browsertreiber implementiert sie, sodass derselbe Testcode jeden unterstützten Browser steuert.
Sie rendert die Webseite selbst und ersetzt die Browser-Engine.
Falsch — WebDriver rendert keine Seiten; das macht die Browser-Engine. WebDriver sendet nur Befehle an den Browser.
Sie ist ein Test-Runner, der Testfälle findet und ausführt.
Falsch — das Ausführen und Berichten von Tests übernimmt ein Framework wie JUnit, TestNG oder pytest, nicht WebDriver.
Sie ist eine Assertion-Bibliothek zur Prüfung erwarteter Ergebnisse.
Falsch — Assertions stammen aus dem Test-Framework oder einer Assertion-Bibliothek; WebDriver bietet nur Browser-Automatisierungsbefehle.
WebDriver definiert eine browserunabhängige API; eine browserspezifische Treiberklasse implementiert sie und steuert einen echten Browser.
Welches Kommunikationsprotokoll verwendet Selenium 4 standardmäßig zwischen den Client-Bindings und dem Browsertreiber?
Das W3C-WebDriver-Protokoll.
Richtig — Selenium 4 nutzt ausschließlich den W3C-WebDriver-Standard, was die Browserstabilität verbessert.
Das alte JSON Wire Protocol.
Falsch — das JSON Wire Protocol wurde in Selenium 3 und früher genutzt und ist in Selenium 4 entfernt.
FTP.
Falsch — FTP ist ein Dateiübertragungsprotokoll und hat nichts mit Browser-Automatisierung zu tun.
SMTP.
Falsch — SMTP ist ein E-Mail-Protokoll und spielt beim Steuern eines Browsers keine Rolle.
Selenium 4 ist vollständig auf das W3C-WebDriver-Protokoll standardisiert; das alte JSON Wire Protocol wurde entfernt.
Was ist der Unterschied zwischen driver.quit() und driver.close()?
close() schließt nur das aktuelle Browserfenster bzw. den Tab, während quit() die gesamte WebDriver-Session beendet und alle Fenster schließt.
Richtig — das ist der entscheidende Unterschied; nutzen Sie quit() im Teardown, um den Treiberprozess freizugeben.
Sie sind identisch; beide beenden die Session.
Falsch — nur quit() beendet die Session. close() lässt die Session mit verbleibenden Fenstern bestehen.
quit() schließt nur den aktuellen Tab; close() beendet die gesamte Session.
Falsch — das vertauscht die beiden Methoden.
close() löscht Cookies; quit() lädt die Seite neu.
Falsch — keine der Methoden betrifft Cookies oder Neuladen; beide schließen Fenster/Sessions.
close() schließt das aktuelle Fenster; quit() beendet die gesamte Session und verwirft den Treiber.
Welche der folgenden sind gültige Navigationsbefehle der WebDriver.Navigation-Schnittstelle? Wählen Sie ZWEI.
navigate().refresh()
Richtig — refresh() lädt die aktuelle Seite neu und gehört zur Navigation-Schnittstelle.
navigate().back()
Richtig — back() geht einen Schritt im Browserverlauf zurück und gehört zur Navigation-Schnittstelle.
navigate().scroll()
Falsch — es gibt kein scroll() in der Navigation-Schnittstelle; Scrollen erfolgt über Actions oder JavaScript.
navigate().click()
Falsch — click() ist eine WebElement-Methode, kein Navigationsbefehl.
navigate().back(), forward(), refresh() und to(url) gehören zur Navigation-Schnittstelle.
Ein Test öffnet einen Link, der ein zweites Browserfenster erzeugt. Welches Methodenpaar erlaubt es, offene Fenster aufzulisten und den Fokus auf das neue zu wechseln?
getWindowHandles() und switchTo().window(handle)
Richtig — getWindowHandles() liefert die Menge der Handles und switchTo().window() setzt den Fokus des Treibers auf das gewählte Fenster.
getWindowHandle() und switchTo().frame(index)
Falsch — getWindowHandle() (Singular) liefert nur das aktuelle Handle, und frame() wechselt in iframes, nicht in Fenster.
findElements() und click()
Falsch — diese finden und klicken Elemente; sie verwalten keinen Fensterfokus.
navigate().to() und get()
Falsch — diese laden eine URL im aktuellen Fenster und wechseln nicht zwischen bestehenden Fenstern.
getWindowHandles() liefert alle Handles; switchTo().window(handle) wechselt den Fokus.
Ein Tester führt folgenden Java-Code gegen eine Seite aus, die das Suchfeld erst etwa 3 Sekunden nach dem 'load'-Ereignis rendert:
WebDriver driver = new ChromeDriver();
driver.get("https://shop.example.com");
driver.findElement(By.id("search")).sendKeys("laptop");
Es ist kein impliziter oder expliziter Wait konfiguriert. Was ist das WAHRSCHEINLICHSTE Ergebnis?
Eine NoSuchElementException wird geworfen, weil findElement läuft, bevor das Suchfeld gerendert ist.
Richtig — get() kehrt beim load-Ereignis zurück; das Element erscheint ~3 s später, ohne Wait schlägt die Suche sofort fehl.
Selenium wartet automatisch, bis das Element erscheint, und gibt dann den Text ein.
Falsch — WebDriver wartet nicht automatisch; ohne konfigurierten Wait wird nicht nach dem Element gepollt.
Der Text wird erfolgreich eingegeben, weil get() blockiert, bis alle asynchronen Inhalte geladen sind.
Falsch — get() blockiert nur bis zum load-Ereignis, nicht bis asynchrones Rendering abgeschlossen ist.
Nach dem Standard-Timeout von 30 Sekunden wird eine TimeoutException geworfen.
Falsch — es ist kein Wait konfiguriert, also gibt es kein Polling-Timeout; der Fehler ist eine sofortige NoSuchElementException.
driver.get() blockiert nur bis zum load-Ereignis, nicht bis asynchrone Inhalte erscheinen. Ohne Wait läuft findElement sofort, das Element ist noch nicht vorhanden, daher wird eine NoSuchElementException geworfen.
Wie sollte in Selenium 4 browserspezifische Konfiguration wie der Headless-Modus oder ein eigenes Download-Verzeichnis beim Erzeugen eines Treibers übergeben werden?
Durch Erstellen eines Options-Objekts (z. B. ChromeOptions) und Übergabe an den Treiber-Konstruktor.
Richtig — Options-Klassen sind der Selenium-4-Mechanismus für Capabilities und Browser-Flags.
Durch Instanziieren der veralteten DesiredCapabilities-Klasse und direkte Übergabe.
Falsch — DesiredCapabilities wurde als Konstruktorargument in Selenium 4 entfernt; Options ersetzt es.
Durch Bearbeiten der Einstellungsdatei des Browsers auf der Festplatte vor dem Lauf.
Falsch — das ist fragil und nicht der von WebDriver unterstützte Weg; Options bietet eine programmatische, portable API.
Die Konfiguration kann nicht geändert werden; der Treiber nutzt immer die Browser-Standards.
Falsch — Konfiguration wird über Options voll unterstützt; der Treiber erzwingt keine Standards.
Selenium 4 hat DesiredCapabilities entfernt; die Options-Klassen (ChromeOptions, FirefoxOptions) sind der unterstützte Weg, eine Session zu konfigurieren.
Welche Aussagen über Selenium WebDriver sind korrekt? Wählen Sie ZWEI.
Es steuert einen echten Browser über ein browserspezifisches Treiber-Executable (z. B. chromedriver).
Richtig — jeder Browser hat ein Treiber-Executable, an das WebDriver-Befehle gesendet werden.
Es kann den Browser im Headless-Modus für CI-Umgebungen ausführen.
Richtig — der Headless-Modus (über Options) wird häufig auf Servern ohne Display genutzt.
Es ist ein Record-and-Playback-Werkzeug, das keine Programmierung erfordert.
Falsch — das beschreibt Selenium IDE; WebDriver ist eine Programmier-API.
Es kann native Desktop-Anwendungen ohne Browser testen.
Falsch — WebDriver automatisiert Browser; native Desktop-Apps brauchen Tools wie WinAppDriver oder Appium.
WebDriver steuert einen echten Browser über dessen eigenes Treiber-Executable und funktioniert headless; es ist keine Record-and-Playback-IDE.
Welcher Locator wählt anhand des folgenden HTML eindeutig das E-Mail-Eingabefeld aus?
<form id="signup"><input name="email" type="email" class="field"><input name="phone" type="tel" class="field"></form>
By.cssSelector("input[name='email']")
Richtig — das name-Attribut ist für das E-Mail-Feld eindeutig, dieser CSS-Selektor trifft genau ein Element.
By.className("field")
Falsch — beide Inputs haben die Klasse 'field', also trifft dies zwei Elemente und findElement liefert das erste (das falsche).
By.id("email")
Falsch — es gibt kein Element mit der id 'email'; das E-Mail-Feld hat nur ein name-Attribut.
By.tagName("input")
Falsch — es gibt zwei input-Elemente, also ist dies mehrdeutig und liefert den ersten Treffer.
Beide Inputs teilen die Klasse 'field', daher ist By.className mehrdeutig. Das name-Attribut 'email' ist eindeutig.
Warum ist gemäß Selenium-Best-Practice By.id() meist einem absoluten XPath wie /html/body/div[2]/form/input[1] vorzuziehen?
Eine stabile id ist eindeutig und robust gegenüber Layoutänderungen, während ein absoluter XPath bei Änderungen der DOM-Struktur bricht.
Richtig — absolute Pfade sind fragil; eine stabile id findet das Element auch nach Umsortierung des Markups.
Absoluter XPath kann in Selenium 4 überhaupt nicht verwendet werden.
Falsch — absoluter XPath funktioniert weiterhin; er wird nur wegen seiner Fragilität abgeraten.
IDs sind immer langsamer auszuwerten als XPath.
Falsch — in der Regel gilt das Gegenteil; id-Suchen sind meist die schnellste Locator-Strategie.
Absoluter XPath garantiert einen eindeutigen Treffer und ist daher die zuverlässigste Option.
Falsch — er kann momentan eindeutig sein, ist aber sehr empfindlich gegenüber Strukturänderungen und daher langfristig unzuverlässig.
IDs (sofern vorhanden und stabil) sind schnell und robust; absoluter XPath bricht, sobald sich die DOM-Struktur ändert.
Welcher XPath wählt den Button, dessen sichtbarer Text genau 'Add to cart' lautet?
<button class="btn primary">Add to cart</button>
//button[normalize-space(text())='Add to cart']
Richtig — dies trifft den Button anhand seines getrimmten sichtbaren Textes und ist robust gegen führende/abschließende Leerzeichen.
//button[@text='Add to cart']
Falsch — der Button hat kein 'text'-Attribut; sichtbarer Text ist in HTML kein Attribut.
//button[@class='Add to cart']
Falsch — dies trifft auf das class-Attribut, dessen Wert 'btn primary' ist, nicht auf den Button-Text.
//button#Add to cart
Falsch — '#' ist CSS-id-Syntax und in einem XPath-Ausdruck ungültig.
XPath text() mit normalize-space trifft auf den sichtbaren Textinhalt des Elements.
Welcher CSS-Selektor trifft einen Link, dessen href-Attribut mit '.pdf' ENDET?
<a href="/files/report.pdf">Download report</a>
a[href$='.pdf']
Richtig — der Operator $= trifft Attributwerte, die mit der angegebenen Zeichenkette enden.
a[href^='.pdf']
Falsch — ^= trifft Werte, die mit der Zeichenkette BEGINNEN; der href beginnt mit '/files', nicht mit '.pdf'.
a[href='.pdf']
Falsch — = verlangt, dass der gesamte Attributwert gleich '.pdf' ist, was nicht zutrifft.
a[href~='.pdf']
Falsch — ~= trifft ein durch Leerzeichen getrenntes Wort im Wert, was auf ein URL-Ende nicht zutrifft.
Der CSS-Attributselektor [attr$='value'] trifft, wenn der Attributwert mit der angegebenen Zeichenkette endet.
Was ist der praktische Unterschied zwischen driver.findElement() und driver.findElements()?
findElement liefert den ersten Treffer und wirft NoSuchElementException, wenn keiner gefunden wird; findElements liefert eine (möglicherweise leere) Liste ohne Exception.
Richtig — findElements ist die sichere Wahl, wenn ein Element fehlen kann, da es eine leere Liste liefert.
Beide werfen NoSuchElementException, wenn kein Element passt.
Falsch — findElements wirft nicht; es liefert eine leere Liste.
findElements liefert nur das erste passende Element.
Falsch — findElements liefert alle passenden Elemente als Liste; findElement liefert nur das erste.
findElement kann nur mit By.id verwendet werden.
Falsch — findElement funktioniert mit jeder By-Locator-Strategie.
findElement wirft NoSuchElementException, wenn nichts passt; findElements liefert eine leere Liste.
Welche der folgenden Punkte sind Vorteile von CSS-Selektoren gegenüber XPath in Selenium? Wählen Sie ZWEI.
CSS-Selektoren sind in den meisten Browser-Engines meist schneller auszuwerten.
Richtig — die native CSS-Engine ist in den meisten Browsern typischerweise schneller als XPath.
Die CSS-Syntax ist für id-, Klassen- und Attribut-Matching oft knapper.
Richtig — für gängige Suchen ist CSS meist kürzer und lesbarer als das XPath-Äquivalent.
CSS-Selektoren können zu einem Eltern- oder Vorfahrenelement navigieren.
Falsch — CSS kann keine Vorfahren auswählen; nur XPath unterstützt Eltern-/Vorfahrenachsen.
CSS-Selektoren können ein Element anhand seines sichtbaren Textes finden.
Falsch — CSS kann nicht auf Textinhalt matchen; XPath kann es mit text()/normalize-space().
CSS-Selektoren sind in den meisten Browser-Engines meist schneller und für häufige Fälle knapper; CSS kann jedoch nicht zu Eltern-/Vorfahrenknoten navigieren und nicht auf sichtbaren Text matchen.
Eine Zeile in einer Datentabelle soll anhand des Textes in ihrer zweiten Zelle gefunden werden. Welcher XPath findet das <tr>, das ein <td> mit dem Text 'Invoice #4521' enthält?
<tr><td>2026-07-01</td><td>Invoice #4521</td></tr>
//tr[td[normalize-space()='Invoice #4521']]
Richtig — dies wählt das tr, das ein td-Kind mit dem angegebenen Text hat, und liefert die ganze Zeile.
//td[text()='Invoice #4521']
Falsch — dies liefert die Zelle selbst, nicht die gewünschte Elternzeile.
//tr/td::parent[text()='Invoice #4521']
Falsch — 'td::parent' ist keine gültige XPath-Achsensyntax; die parent-Achse schreibt man als parent::tr.
tr:has(td:contains('Invoice #4521'))
Falsch — :contains() ist kein von Selenium unterstützter Standard-CSS-Selektor und vermischt CSS mit der XPath-Anforderung.
XPath kann eine Vorfahrenzeile aus einer Nachfahrenzelle wählen, mit dem Muster //td[...]/parent::tr oder //tr[td[...]].
Ein Team verwendet Locators, die an automatisch generierte Klassennamen wie 'css-1x9k2f' gebunden sind. Warum ist das eine schlechte Locator-Strategie?
Automatisch generierte Klassennamen ändern sich zwischen Builds, sodass die Locators unvorhersehbar ungültig werden.
Richtig — gehashte Klassennamen sind flüchtig; ein stabiles data-testid oder id ist weit zuverlässiger.
Selenium kann Klassennamen überhaupt nicht als Locators nutzen.
Falsch — Selenium unterstützt klassenbasierte Locators voll; das Problem ist die Instabilität dieser konkreten Namen.
Klassennamen-Locators sind immer langsamer als id-Locators und verursachen Timeouts.
Falsch — das Kernproblem ist Instabilität, nicht Geschwindigkeit; Performance ist nicht der Grund für das Versagen.
Klassennamen dürfen keine Ziffern enthalten, daher ist 'css-1x9k2f' ungültiges HTML.
Falsch — Klassennamen dürfen Ziffern enthalten; solche Namen sind gültiges HTML, nur instabil.
Automatisch generierte Klassennamen (aus CSS-in-JS-Build-Tools) ändern sich bei Rebuilds, sodass daran gebundene Locators unvorhersehbar brechen.
Was ist die Kernidee des Page Object Model (POM)?
Jede Seite (oder Komponente) wird durch eine Klasse repräsentiert, die ihre Locators und Interaktionen kapselt und Tests von rohen Locators freihält.
Richtig — diese Trennung der Zuständigkeiten ist der Kern von POM und verbessert die Wartbarkeit.
Es speichert alle Testdaten in einer einzigen JSON-Datei pro Seite.
Falsch — das beschreibt datengetriebenes Testen, nicht das Page Object Model.
Es ersetzt WebDriver durch eine Screenshot-Vergleichs-Engine.
Falsch — POM ist ein Entwurfsmuster zur Codeorganisation, keine visuelle Testtechnik.
Es verlangt, dass jeder Test in Gherkin-Syntax geschrieben wird.
Falsch — Gherkin ist eine BDD-Notation und unabhängig von POM.
POM kapselt die Locators und Interaktionen einer Seite in einer Klasse und trennt sie von der Testlogik.
Wo sollten in einem gut entworfenen Page Object Assertions (Prüfung erwarteter Ergebnisse) normalerweise stehen?
In den Testmethoden; das Page Object bietet Aktionen und Getter, überlässt die Prüfung aber den Tests.
Richtig — Assertions aus Page Objects herauszuhalten macht sie über viele Tests mit unterschiedlichen Erwartungen wiederverwendbar.
In jeder Page-Object-Methode, damit sich jede Aktion selbst prüft.
Falsch — eingebettete Assertions koppeln Page Objects an bestimmte Erwartungen und schaden der Wiederverwendung.
In der WebDriver-Treiberklasse.
Falsch — der Treiber ist ein Low-Level-Browsercontroller und nicht der Ort für Testverifikation.
Assertions werden bei Verwendung von POM nie benötigt.
Falsch — Tests brauchen weiterhin Assertions; POM ändert nur, wo die Locators liegen, nicht ob geprüft wird.
Page Objects modellieren Seitenverhalten und liefern Zustände; Assertions gehören in die Testmethoden, damit Page Objects wiederverwendbar bleiben.
Wenn eine Page-Object-Methode eine Aktion ausführt, die den Benutzer auf eine andere Seite führt, was ist ein empfohlener Rückgabewert?
Eine Instanz des Page Objects, das die Zielseite repräsentiert.
Richtig — die Rückgabe des nächsten Page Objects unterstützt eine fluente API und dokumentiert die Navigation im Code.
Der rohe HTML-Quelltext der neuen Seite als String.
Falsch — rohes HTML zurückzugeben untergräbt die Abstraktion von POM und ist schwer nutzbar.
Die WebDriver-Instanz selbst.
Falsch — den Treiber offenzulegen lässt Low-Level-Details in Tests einfließen und untergräbt die Seitenabstraktion.
Immer void; Seitenmethoden sollten nie etwas zurückgeben.
Falsch — manche Aktionen sind void, doch Navigationsmethoden profitieren von der Rückgabe des Ziel-Page-Objects.
Die Rückgabe des nächsten Page Objects ermöglicht fluentes Verketten und modelliert den Navigationsfluss explizit.
Welche der folgenden Punkte sind Vorteile des Page Object Model? Wählen Sie ZWEI.
Wenn sich ein Locator ändert, wird er an einer Stelle statt in vielen Tests aktualisiert.
Richtig — die Zentralisierung von Locators ist ein Hauptvorteil von POM für die Wartbarkeit.
Tests lesen sich als fachliche Aktionen (z. B. loginPage.loginAs(user)) statt als Low-Level-Locator-Aufrufe.
Richtig — lesbarer Testcode auf höherer Ebene ist ein zentraler Vorteil der Seitenkapselung.
Es macht Waits oder Synchronisation überflüssig.
Falsch — POM adressiert kein Timing; Waits bleiben für dynamische Inhalte nötig.
Es lässt Tests automatisch parallel laufen.
Falsch — Parallelausführung wird vom Test-Framework/Runner konfiguriert, nicht von POM bereitgestellt.
POM zentralisiert Locators (eine Stelle zum Ändern bei UI-Änderungen) und verbessert Lesbarkeit/Wiederverwendung des Testcodes.
Worauf bezieht sich der Begriff 'Page Factory' im Kontext von Selenium Page Objects (Java)?
Eine Selenium-Support-Klasse, die mit @FindBy annotierte WebElement-Felder in einem Page Object initialisiert.
Richtig — PageFactory.initElements() verdrahtet @FindBy-Felder lazy, ein klassischer POM-Helfer in den Java-Bindings.
Ein Entwurfsmuster zum Erzeugen von Browser-Treiberinstanzen.
Falsch — das beschreibt eine Treiber-Factory; Page Factory initialisiert Elementfelder von Page Objects.
Ein Werkzeug, das HTML-Seiten zum Testen generiert.
Falsch — PageFactory generiert keine Seiten; es verdrahtet Locators mit Feldern.
Eine Reporting-Bibliothek für Testergebnisse.
Falsch — Reporting hat nichts mit PageFactory zu tun, das die Elementinitialisierung betrifft.
PageFactory ist eine Selenium-Support-Klasse, die @FindBy-annotierte Felder über PageFactory.initElements() initialisiert.
Eine Testsuite hat ein einziges riesiges Page Object mit 200 Elementen und 80 Methoden für die gesamte Anwendung. Was ist aus Designsicht das Hauptproblem?
Es verletzt das Single-Responsibility-Prinzip; jede Seite oder Komponente sollte ein eigenes, fokussiertes Page Object haben.
Richtig — ein God-Object ist schwer wartbar; POM funktioniert am besten, wenn Klassen einzelnen Seiten/Komponenten entsprechen.
Nichts; ein großes Page Object ist der empfohlene POM-Ansatz.
Falsch — POM empfiehlt eine Klasse pro Seite/Komponente, keinen einzelnen Monolithen.
WebDriver kann nicht mehr als 100 Elemente in einer Klasse verarbeiten.
Falsch — ein solches technisches Limit gibt es nicht; das Problem ist Design/Wartbarkeit, keine WebDriver-Grenze.
Page Objects dürfen nie mehr als eine Methode enthalten.
Falsch — Page Objects dürfen viele Methoden haben; das Problem ist der Umfang, nicht die Methodenzahl an sich.
Ein einzelnes monolithisches Page Object verletzt das Modell; jede Seite/Komponente sollte eine eigene Klasse sein, um kohärent und wartbar zu bleiben.
Was ist der wesentliche Unterschied zwischen einem impliziten und einem expliziten Wait in Selenium WebDriver?
Ein impliziter Wait gilt global für jede Elementsuche, während ein expliziter Wait auf eine bestimmte Bedingung eines bestimmten Elements wartet.
Richtig — explizite Waits sind bedingungsbasiert und gezielt; implizite Waits setzen ein pauschales Polling-Timeout für alle findElement-Aufrufe.
Ein impliziter Wait pausiert die Ausführung jedes Mal für eine feste Anzahl Sekunden, wie Thread.sleep.
Falsch — das beschreibt einen harten Sleep; ein impliziter Wait wartet nur bis zum Timeout und kehrt zurück, sobald das Element gefunden ist.
Ein expliziter Wait gilt für alle Elemente und kann keine Bedingung anvisieren.
Falsch — das vertauscht die Konzepte; explizite Waits dienen genau dem Anvisieren einer bestimmten Bedingung.
Es gibt keinen Unterschied; die beiden Begriffe sind Synonyme.
Falsch — es sind unterschiedliche Mechanismen mit unterschiedlichem Geltungsbereich und Verhalten.
Der implizite Wait gilt global für alle Elementsuchen; der explizite Wait zielt auf eine bestimmte Bedingung eines bestimmten Elements.
Ein Tester möchte warten, bis ein Spinner verschwindet und die Ergebnisse klickbar werden. Welches Java-Snippet ist der korrekte explizite Wait-Ansatz in Selenium 4?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(By.id("result")))
Richtig — Selenium 4 nimmt eine Duration und pollt, bis die ExpectedCondition erfüllt ist oder das Timeout abläuft.
Thread.sleep(10000); driver.findElement(By.id("result")).click();
Falsch — ein fester Sleep ist kein expliziter Wait; er verschwendet Zeit, wenn es schnell geht, und scheitert dennoch, wenn es langsam ist.
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); driver.findElement(By.id("result")).click();
Falsch — ein impliziter Wait wartet auf Vorhandensein, nicht auf Klickbarkeit, und kann so ein vorhandenes, aber noch nicht interagierbares Element anklicken.
driver.wait(10).click(By.id("result"));
Falsch — eine solche driver.wait(...).click()-API gibt es in Selenium nicht; das ist ungültig.
WebDriverWait mit Duration und einer ExpectedConditions-Methode (z. B. elementToBeClickable) ist der idiomatische explizite Wait in Selenium 4.
Warum wird das Mischen von impliziten und expliziten Waits im selben Test abgeraten?
Die beiden Mechanismen können sich addieren und zu unvorhersehbaren, unerwartet langen Wartezeiten führen.
Richtig — die Interaktion zwischen implizitem und explizitem Polling ist undefiniert und kann sich summieren, daher wird vom Mischen abgeraten.
Selenium wirft einen Kompilierfehler, wenn beide konfiguriert sind.
Falsch — es gibt keinen Kompilierfehler; der Code läuft, aber das Timing wird unzuverlässig.
Explizite Waits funktionieren gar nicht mehr, sobald ein impliziter Wait gesetzt ist.
Falsch — explizite Waits funktionieren weiter; das Problem ist unvorhersehbares kombiniertes Timing, kein Totalausfall.
Weil implizite Waits in Selenium 4 nicht unterstützt werden.
Falsch — implizite Waits werden weiterhin unterstützt; sie werden nur nicht zusammen mit expliziten Waits empfohlen.
Die Kombination kann zu unvorhersehbaren, länger als erwarteten Wartezeiten führen, weil die beiden Mechanismen interagieren.
Was ist ein FluentWait und wie erweitert er den einfachen expliziten Wait?
Ein Wait, mit dem man Timeout, Polling-Intervall und die während des Wartens zu ignorierenden Exceptions festlegen kann.
Richtig — FluentWait bietet withTimeout, pollingEvery und ignoring und gibt feingranulare Kontrolle über das Warten.
Ein Wait, der nie ein Timeout hat und den Test ewig blockiert.
Falsch — FluentWait hat immer ein konfiguriertes Timeout; er blockiert nicht unbegrenzt.
Ein Wait, der ohne Code automatisch auf alle Elemente angewendet wird.
Falsch — das beschreibt einen impliziten Wait; FluentWait muss explizit erstellt und genutzt werden.
Ein Wait, der nur mit By.id-Locators funktioniert.
Falsch — FluentWait funktioniert mit jeder Bedingung/Funktion, nicht nur mit id-Locators.
FluentWait erlaubt es, Timeout, Polling-Intervall und ignorierte Exceptions explizit zu konfigurieren.
Welche der folgenden sind gültige, häufig mit WebDriverWait genutzte ExpectedConditions? Wählen Sie ZWEI.
ExpectedConditions.visibilityOfElementLocated(By)
Richtig — wartet, bis das Element im DOM vorhanden und sichtbar ist.
ExpectedConditions.elementToBeClickable(By)
Richtig — wartet, bis das Element sichtbar und aktiviert ist, sodass es geklickt werden kann.
ExpectedConditions.pageToBeBeautiful()
Falsch — eine solche Bedingung existiert nicht; sie ist nicht Teil der Selenium-API.
ExpectedConditions.networkIdleForever()
Falsch — das ist keine echte ExpectedCondition in Selenium.
visibilityOfElementLocated und elementToBeClickable sind Standard-ExpectedConditions; die anderen sind erfunden.
Warum gilt die Verwendung von Thread.sleep() zur Synchronisation in Selenium-Tests als Anti-Pattern?
Er wartet immer die volle feste Zeit, selbst wenn das Element früher bereit ist, und kann bei einem langsamen Lauf dennoch zu kurz sein — langsam und instabil.
Richtig — ein harter Sleep kann sich nicht an das tatsächliche Timing anpassen, verschwendet Zeit und scheitert dennoch sporadisch; bedingte Waits sind besser.
Thread.sleep() ist in Java nicht verfügbar, daher kompiliert der Code nicht.
Falsch — Thread.sleep() ist Standard-Java; der Einwand ist verhaltensbezogen, kein Kompilierfehler.
Es schließt die Browser-Session unerwartet.
Falsch — ein Sleep schließt die Session nicht; er pausiert nur den Thread.
Es lässt den Browser im Headless-Modus laufen.
Falsch — Thread.sleep hat nichts mit dem Headless-Modus zu tun.
Ein fester Sleep wartet immer die volle Dauer, unabhängig von der Bereitschaft, was Tests langsam und instabil macht.
Eine Seite zeigt Inhalt in einem <iframe>. Ein Test schlägt mit NoSuchElementException fehl, wenn ein klar sichtbares Element im Frame gesucht wird. Was ist die wahrscheinlichste Ursache?
Der Treiber ist nicht in den iframe gewechselt, daher liegt das Element außerhalb seines aktuellen Suchkontexts.
Richtig — man muss driver.switchTo().frame(...) aufrufen, bevor man Elemente im iframe sucht.
Selenium kann überhaupt nicht mit Elementen in iframes interagieren.
Falsch — Selenium unterstützt iframe-Inhalte voll, nachdem in den Frame gewechselt wurde.
Das Element darf innerhalb eines iframe nur mit By.id gesucht werden.
Falsch — jeder Locator funktioniert im Frame, sobald man gewechselt hat; die Strategie ist nicht das Problem.
iframes schließen automatisch die WebDriver-Session.
Falsch — iframes schließen keine Sessions; der Fehler ist ein Suchkontext-Problem.
Elemente in einem iframe sind erst erreichbar, wenn der Treiber mit switchTo().frame() in diesen Frame wechselt.
Welche Selenium-4-API ist für komplexe Interaktionen wie Drag-and-Drop, Hover und Tastenkombinationen gedacht?
Die Actions-Klasse (Actions-API).
Richtig — Actions bildet Ketten wie moveToElement, clickAndHold, dragAndDrop und keyDown/keyUp.
Die By-Klasse.
Falsch — By definiert Locator-Strategien, keine Interaktionssequenzen.
Die ExpectedConditions-Klasse.
Falsch — ExpectedConditions liefert Wartebedingungen, keine Benutzereingabe-Aktionen.
Die Select-Klasse.
Falsch — Select behandelt nur <select>-Dropdowns, kein Drag-and-Drop oder Hover.
Die Actions-Klasse erstellt Low-Level-Eingabesequenzen (Maus, Tastatur) für fortgeschrittene Interaktionen.
Ein Dropdown ist mit einem Standard-HTML-<select>-Element aufgebaut:
<select id="country"><option value="us">USA</option><option value="de">Germany</option></select>
Was ist der korrekte Selenium-Weg (Java), um 'Germany' auszuwählen?
new Select(driver.findElement(By.id("country"))).selectByVisibleText("Germany");
Richtig — die Select-Klasse ist die passende API für Standard-<select>-Elemente; selectByVisibleText wählt die Option per Text.
driver.findElement(By.id("country")).sendKeys("Germany");
Falsch — Tasten an das Select zu senden ist unzuverlässig; die Select-Klasse ist der korrekte, portable Weg.
driver.findElement(By.id("country")).selectOption("Germany");
Falsch — WebElement hat in Seleniums Java-Bindings keine selectOption()-Methode.
new Actions(driver).selectByVisibleText("Germany").perform();
Falsch — selectByVisibleText ist eine Select-Methode, keine Actions-Methode.
Für ein echtes <select> nutzt man die Select-Support-Klasse; selectByVisibleText('Germany') oder selectByValue('de') ist idiomatisch.
Während eines Tests erscheint ein JavaScript-alert(). Wie interagiert WebDriver damit?
Durch Wechsel mit driver.switchTo().alert() und Aufruf von accept() oder dismiss().
Richtig — Alerts sind ein eigener Kontext, erreichbar über switchTo().alert(); danach bestätigt, verwirft oder tippt man.
Durch Suchen mit By.id("alert") und Klicken der OK-Schaltfläche.
Falsch — native JS-Alerts sind nicht Teil des DOM und können nicht mit By-Strategien gefunden werden.
WebDriver kann keine JavaScript-Alerts behandeln.
Falsch — WebDriver behandelt Alerts über die Alert-Schnittstelle.
Durch Neuladen der Seite, damit der Alert verschwindet.
Falsch — Neuladen behandelt den Alert nicht korrekt und kann den Browser blockiert zurücklassen.
JavaScript-Alerts werden über driver.switchTo().alert() behandelt, dann accept()/dismiss()/sendKeys().
Was liefert driver.getWindowHandle() (Singular)?
Ein String, der das aktuell fokussierte Fenster identifiziert.
Richtig — die Singular-Methode liefert das Handle des aktuellen Fensters als String.
Eine Liste aller offenen Fenster-Handles.
Falsch — das ist getWindowHandles() (Plural); der Singular liefert ein Handle.
Die Pixelabmessungen des Fensters.
Falsch — Abmessungen liefert manage().window().getSize(), nicht getWindowHandle().
Der Seitentitel des aktuellen Fensters.
Falsch — den Titel liefert driver.getTitle(), nicht getWindowHandle().
getWindowHandle() liefert das String-Handle des aktuell fokussierten Fensters; getWindowHandles() (Plural) liefert alle.
Welche Aussagen zum Umgang mit mehreren Browser-Tabs/Fenstern in Selenium 4 sind korrekt? Wählen Sie ZWEI.
Selenium 4 kann mit driver.switchTo().newWindow(WindowType.TAB) direkt einen neuen Tab öffnen.
Richtig — newWindow ist eine Selenium-4-Ergänzung, die einen neuen Tab oder ein neues Fenster öffnet und dorthin wechselt.
Man identifiziert Fenster und wechselt zwischen ihnen über ihre Window-Handles.
Richtig — Handles sind die stabilen Bezeichner, um den Fokus zwischen offenen Fenstern/Tabs zu wechseln.
WebDriver wechselt den Fokus automatisch zu einem neu geöffneten Tab.
Falsch — das Öffnen eines Links in einem neuen Tab verschiebt den Fokus nicht; man muss explizit per Handle wechseln.
Window-Handles sind fortlaufende Ganzzahlen ab 0.
Falsch — Handles sind undurchsichtige, vom Browser vergebene Strings, keine geordneten Ganzzahlen.
Selenium 4 fügt driver.switchTo().newWindow(WindowType.TAB) hinzu, um einen neuen Tab zu öffnen; Fenster verfolgt man weiter über Handles.
Was ist ein 'flaky' (instabiler) automatisierter Test?
Ein Test, der beim gleichen Code sporadisch besteht und scheitert, ohne klaren Grund.
Richtig — Flakiness bedeutet nicht-deterministische Ergebnisse, oft durch Timing, Reihenfolge oder Umgebung.
Ein Test, der bei jedem Lauf immer scheitert.
Falsch — ein konstant scheiternder Test ist deterministisch, nicht flaky.
Ein Test ohne Assertions.
Falsch — fehlende Assertions sind ein anderes Qualitätsproblem, keine Flakiness.
Ein Test, der nur im Headless-Modus läuft.
Falsch — Headless-Ausführung hat nichts mit der Definition von Flakiness zu tun.
Ein flaky Test besteht und scheitert sporadisch, ohne dass sich der zu testende Code ändert.
Ein Test scheitert sporadisch beim Klick auf einen Button, der zwar im DOM ist, sich aber manchmal noch in Position animiert. Welche Behebung adressiert die Ursache am besten?
Einen expliziten Wait auf ExpectedConditions.elementToBeClickable vor dem Klick verwenden.
Richtig — dies wartet, bis das Element sichtbar und aktiviert ist, und trifft die echte Vorbedingung für einen zuverlässigen Klick.
Vor jedem Klick Thread.sleep(500) einfügen.
Falsch — ein fester Sleep ist ein fragiles Pflaster; er verschwendet Zeit und kann unter Last dennoch zu kurz sein.
Den gesamten Test dreimal wiederholen und den ersten Erfolg akzeptieren.
Falsch — blindes Wiederholen verdeckt den Timing-Defekt, statt die Synchronisation zu beheben.
Den Locator von CSS auf XPath umstellen.
Falsch — die Locator-Strategie ist nicht das Problem; das Element wird gefunden, ist aber noch nicht interagierbar.
Das Warten auf elementToBeClickable (sichtbar UND aktiviert) synchronisiert auf Interagierbarkeit, anders als bloßes Vorhandensein.
Welche Praktiken machen Selenium-Tests stabiler und weniger flaky? Wählen Sie ZWEI.
Jeden Test unabhängig machen, mit eigenem Setup und Aufräumen der Daten.
Richtig — Testisolation verhindert Fehler durch übrig gebliebenen Zustand oder Ausführungsreihenfolge.
Auf Zustand mit bedingungsbasierten expliziten Waits synchronisieren statt mit festen Sleeps.
Richtig — auf die tatsächliche Bedingung zu warten passt sich dem echten Timing an und vermeidet verschwendete Zeit und verfrühte Aktionen.
Eine Browser-Session und akkumulierten Zustand über alle Tests teilen.
Falsch — geteilter veränderlicher Zustand koppelt Tests und ist eine häufige Quelle von Flakiness.
Längere Thread.sleep()-Aufrufe überall dort einfügen, wo ein Test gelegentlich scheitert.
Falsch — feste Sleeps passen sich dem Timing nicht an und verdecken das eigentliche Synchronisationsproblem, statt es zu beheben.
Unabhängige Tests mit eigenen Daten und bedingungsbasierte explizite Waits reduzieren Flakiness; geteilter Zustand und feste Sleeps erhöhen sie.
Eine CI-Pipeline führt eine Selenium-Suite parallel über viele Threads aus. Mehrere Tests scheitern sporadisch, weil sie sich als derselbe gemeinsame Benutzer anmelden und sich gegenseitig die Daten stören. Welche Änderung beseitigt diese Flakiness am direktesten?
Jedem parallelen Test einen eigenen isolierten Testbenutzer und Datensatz geben.
Richtig — das Entfernen des geteilten veränderlichen Zustands zwischen parallelen Tests beseitigt die Wechselwirkung an der Wurzel.
Den impliziten Wait auf 60 Sekunden erhöhen.
Falsch — die Fehler entstehen durch Datenkollisionen, nicht durch Timing; ein längerer Wait verhindert keine gemeinsame Daten-Störung.
Die Suite im Headless-Modus ausführen.
Falsch — der Headless-Modus ändert das Rendering, nicht die Datenisolation; die Kollision bleibt.
Alle Locators auf absoluten XPath umstellen.
Falsch — die Locator-Strategie ist hier irrelevant; das Problem sind gemeinsame Daten zwischen gleichzeitigen Tests.
Ursache sind gemeinsame Testdaten über parallele Threads; jedem Test einen eigenen isolierten Benutzer/Daten zu geben beseitigt die Störung.
Warum ist das Erstellen eines Screenshots bei Testfehlern eine empfohlene Stabilitäts-/Diagnosepraxis?
Er hält den UI-Zustand im Moment des Fehlers fest und erleichtert die Diagnose sporadischer Probleme erheblich.
Richtig — ein Screenshot (oft samt Seitenquelle/Logs) zum Fehlerzeitpunkt ist für das Debuggen flaky oder umgebungsspezifischer Fehler von unschätzbarem Wert.
Es verhindert, dass der Test je wieder scheitert.
Falsch — ein Screenshot ist ein Diagnoseartefakt; er ändert keine Testergebnisse.
Es lässt den Browser schneller laufen.
Falsch — einen Screenshot zu machen verbessert die Ausführungsgeschwindigkeit nicht.
Es repariert automatisch defekte Locators.
Falsch — ein Screenshot hält nur den Zustand fest; er kann keine Locators reparieren.
Ein Fehler-Screenshot hält den UI-Zustand im Moment des Fehlers fest und beschleunigt die Ursachenanalyse erheblich.
Ein Team möchte dieselbe Selenium-Suite über Chrome, Firefox und Edge auf einer gemeinsamen Infrastruktur ausführen. Welche Selenium-Komponente ist für diese verteilte, browserübergreifende Ausführung gedacht?
Selenium Grid.
Richtig — Grid leitet Tests an Nodes mit verschiedenen Browsern/OS und ermöglicht verteilte, parallele browserübergreifende Läufe.
Selenium IDE.
Falsch — Selenium IDE ist eine Record-and-Playback-Erweiterung im Browser, kein verteiltes Ausführungs-Grid.
Die Actions-Klasse.
Falsch — Actions behandelt komplexe Eingabegesten, keine verteilte Testausführung.
Die PageFactory-Klasse.
Falsch — PageFactory initialisiert Page-Object-Felder; sie hat nichts mit verteilter Ausführung zu tun.
Selenium Grid verteilt Tests auf mehrere Maschinen/Browser und ermöglicht parallele browserübergreifende Ausführung.