A4Q Selenium Tester Probeprüfung #4 — 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 über die WebDriver-Methode driver.get(String url) ist korrekt?
Sie lädt die Seite und wartet standardmäßig, bis sie vollständig geladen ist.
get() kehrt erst zurück, wenn das Laden der Seite abgeschlossen ist.
Sie öffnet die URL in einem neuen Browser-Tab.
get() verwendet das aktuelle Fenster; es öffnet keinen neuen Tab.
Sie gibt den Seitentitel als String zurück.
get() gibt void zurück; getTitle() liefert den Titel.
Sie wartet nie und kehrt sofort nach dem Senden der Anfrage zurück.
get() ist standardmäßig blockierend.
get() navigiert zu einer URL und wartet standardmäßig, bis document.readyState 'complete' ist.
Was ist der Unterschied zwischen driver.getWindowHandle() und driver.getWindowHandles()?
getWindowHandle() liefert einen aktuellen Handle; getWindowHandles() liefert ein Set aller Handles.
Richtig: Singular gibt einen String, Plural ein Set<String> zurück.
Beide liefern eine nach Öffnungszeit sortierte Liste.
Keine liefert eine Liste; der Plural liefert ein ungeordnetes Set.
getWindowHandle() schließt das Fenster; getWindowHandles() listet sie auf.
getWindowHandle() schließt nichts.
Es gibt keinen Unterschied; sie sind Aliase.
Sie liefern unterschiedliche Typen und Bedeutungen.
getWindowHandle() liefert den Handle des aktuellen Fensters (String); getWindowHandles() liefert ein Set aller offenen Fenster/Tabs.
Ein Test klickt auf einen Link, der einen zweiten Browser-Tab mit einem Zahlungsformular öffnet. Vor dem Klick hat der Test den ursprünglichen Handle mit String main = driver.getWindowHandle(); gespeichert. Nach dem Klick muss der Test mit dem Formular im neuen Tab arbeiten, es ausfüllen, den Tab schließen und zur ursprünglichen Seite zurückkehren. Welche Abfolge von WebDriver-Aufrufen führt diesen Wechsel und die Bereinigung korrekt aus?
Über getWindowHandles() iterieren, switchTo().window(h) für den Handle != main, Formular ausfüllen, driver.close(), dann switchTo().window(main).
Richtig: zum neuen Tab wechseln, handeln, schließen und explizit zurückwechseln.
Einfach driver.switchTo().frame(1) aufrufen, ausfüllen, dann driver.quit().
frame() wechselt iframes, keine Tabs; quit() beendet die gesamte Session.
Formular direkt ausfüllen — WebDriver fokussiert automatisch den neuesten Tab.
WebDriver wechselt den Fokus NICHT automatisch; man muss explizit switchTo() aufrufen.
driver.navigate().forward() verwenden, um in den neuen Tab zu wechseln, und back() zurück.
navigate() steuert die Historie in einem Fenster, nicht den Tab-Wechsel.
Man iteriert das Handle-Set, wechselt zum Handle, der nicht der ursprüngliche ist, arbeitet, schließt den neuen Tab und wechselt zum gespeicherten main-Handle zurück.
Wenn kein passendes Element auf der Seite existiert, wie verhalten sich findElement() und findElements()?
findElement() wirft NoSuchElementException; findElements() liefert eine leere Liste.
Das ist der definierte Vertrag beider Methoden.
Beide liefern null.
findElement() wirft; findElements() liefert eine leere Liste.
Beide werfen NoSuchElementException.
findElements() wirft bei keinem Treffer nicht; es liefert eine leere Liste.
findElement() liefert eine leere Liste; findElements() wirft.
Das kehrt das tatsächliche Verhalten um.
findElement() wirft NoSuchElementException; findElements() liefert eine leere Liste.
Welche der folgenden sind legitime Aufgaben der Selenium WebDriver API? (Wählen Sie zwei.)
Einen echten Browser über dessen native Automatisierung steuern.
Kernzweck von WebDriver.
Elemente finden und Benutzerinteraktionen mit ihnen simulieren.
WebDriver findet Elemente und klickt/tippt.
Assertion-Methoden zur Überprüfung erwarteter Ergebnisse bereitstellen.
Assertions liefert das Test-Framework, nicht WebDriver.
Die Testsuite planen und parallel ausführen.
Ausführung/Planung übernehmen Test-Runner und Grid, nicht die WebDriver API.
WebDriver steuert einen echten Browser über dessen native Automatisierung und findet/bedient Elemente. Es ist kein Test-Runner und enthält keine Assertions.
Sie müssen über einen Menüpunkt fahren, um ein Untermenü einzublenden, und dann auf einen Link darin klicken, der nur beim Hover erscheint. Ein einfacher Klick schlägt fehl, weil der Link erst beim Hover sichtbar wird. Welcher Selenium-Ansatz führt Hover-und-Klick zuverlässig als eine Geste aus?
new Actions(driver).moveToElement(menu).click(submenuLink).perform();
Actions verkettet Mausbewegung und Klick zu einer von perform() ausgeführten Geste.
submenuLink.click(); zweimal hintereinander.
Ein wiederholter Klick erzeugt nicht den Hover-Zustand.
driver.navigate().refresh(); dann submenuLink.click();
Ein Refresh führt keinen Hover aus; der Link bleibt verborgen.
menu.sendKeys(Keys.ENTER); dann submenuLink.click();
ENTER ist kein Hover und öffnet das CSS-:hover-Untermenü evtl. nicht.
Die Actions-Klasse baut eine zusammengesetzte Geste: moveToElement(menu), dann click(submenuLink), abgeschlossen mit perform().
Was ist der Unterschied zwischen driver.close() und driver.quit()?
close() schließt das aktuelle Fenster; quit() schließt alle Fenster und beendet die Session.
Genau diese Unterscheidung gilt.
Sie sind identisch.
Sie unterscheiden sich im Umfang: ein Fenster vs. ganze Session.
close() beendet die ganze Session; quit() schließt ein Fenster.
Das kehrt das reale Verhalten um.
Beide lassen den Driver-Prozess zur Wiederverwendung laufen.
quit() beendet den Driver-Prozess.
close() schließt das aktuelle Fenster; quit() schließt alle Fenster und beendet die WebDriver-Session.
Welche WebElement-Methode sollte verwendet werden, um einen vorhandenen Wert aus einem Textfeld zu löschen, bevor ein neuer eingegeben wird?
clear()
clear() entfernt den aktuellen Inhalt eines editierbaren Feldes.
reset()
Es gibt kein reset() auf WebElement.
delete()
Es gibt keine delete()-Methode.
submit()
submit() sendet das Formular ab; es leert das Feld nicht.
clear() leert das Feld; danach tippt sendKeys() den neuen Wert.
Welche By-Strategie ist im Allgemeinen die schnellste und robusteste, wenn ein Element ein eindeutiges, stabiles id-Attribut trägt?
By.id
Eine id ist pro Seite eindeutig und wird schnell aufgelöst.
By.xpath mit absolutem Pfad
Absolutes XPath ist brüchig und langsam.
By.linkText
linkText funktioniert nur bei Ankertext.
By.tagName
tagName trifft viele Elemente und ist nicht eindeutig.
By.id spricht das id-Attribut direkt an und ist der bevorzugte Locator bei stabiler eindeutiger id.
Gegeben das Markup: <div class="card"><button class="btn btn-primary submit-order" data-test="place-order">Place order</button></div> — die Klassenwerte ändern sich zwischen Releases, aber das data-test-Attribut ist stabil. Welcher Locator trifft diesen Button am wartbarsten?
By.cssSelector("button[data-test='place-order']")
Zielt auf das stabile Attribut, unabhängig von Klassenänderungen.
By.className("btn btn-primary submit-order")
className akzeptiert nur einen Klassennamen, und diese ändern sich.
By.cssSelector(".btn-primary")
Hängt von einer flüchtigen Klasse ab und kann andere Buttons treffen.
By.xpath("/html/body/div[1]/div/button")
Absoluter Pfad bricht bei jeder Strukturänderung.
Ein CSS-Attributselektor auf dem stabilen data-test-Attribut ist knapp und robust gegen Klassenänderungen.
Sie benötigen ein XPath, das ein <a>-Element anhand seines exakten sichtbaren Textes 'Log out' auswählt. Welcher Ausdruck ist korrekt?
//a[text()='Log out']
Wählt den Anker mit exakt diesem Text.
//a[@text='Log out']
text ist kein Attribut, sondern ein Knoten; @text ist ungültig.
//a=='Log out'
Keine gültige XPath-Syntax.
//a(text='Log out')
Keine gültige XPath-Syntax.
//a[text()='Log out'] trifft Anker, deren Textknoten exakt 'Log out' entspricht.
Welcher CSS-Selektor trifft ein input-Element, dessen id genau 'email' ist?
input#email
# wählt in CSS nach id aus.
input.email
. wählt nach Klasse, nicht id.
input=email
Keine gültige CSS-Syntax.
input@email
Keine gültige CSS-Syntax.
In CSS steht # für eine id, also trifft input#email das Element mit id 'email'.
Welche zwei Locator-Strategien gelten als brüchig und sollten vermieden werden, wenn eine stabile id oder ein data-Attribut verfügbar ist? (Wählen Sie zwei.)
Absolutes XPath wie /html/body/div[2]/form/input[1]
Jede Strukturänderung bricht den Pfad.
Selektoren auf generierten Klassennamen wie css-1a2b3c
Framework-Hashes ändern sich beim Rebuild.
By.id auf einer stabilen eindeutigen id
Das ist die robusteste Strategie.
Ein CSS-Attributselektor auf stabilem data-test
data-test-Attribute sind für Automatisierung gedacht und stabil.
Absolutes XPath und Locators auf flüchtigen, generierten Klassennamen brechen bei UI-Änderungen leicht.
Welcher XPath-Achsenausdruck wählt ein <label>, das der direkte Elternknoten des Kontextknotens ist?
parent::label
Die parent-Achse mit Knotentest wählt das Eltern-label.
child::label
child wählt Kindknoten, nicht den Elternknoten.
following-sibling::label
Das wählt ein Geschwister, nicht den Elternknoten.
descendant::label
descendant sucht nach unten, nicht zum Elternknoten.
.. (oder parent::label) bewegt sich zum Elternknoten.
Eine Ergebnistabelle hat viele Zeilen. Sie müssen den 'Edit'-Button in der Zeile klicken, deren erste Zelle 'INV-1042' enthält. Die Zeilen haben die Struktur <tr><td>INV-1042</td>...<td><button>Edit</button></td></tr>. Welches XPath klickt zuverlässig den richtigen Edit-Button?
//td[text()='INV-1042']/ancestor::tr//button[text()='Edit']
Verankert am eindeutigen Zellentext und begrenzt den Button auf diese Zeile.
//button[text()='Edit']
Trifft jeden Edit-Button, nicht eine bestimmte Zeile.
//td[text()='INV-1042']/button
Der Button ist kein direktes Kind dieses td.
//tr[1]//button[text()='Edit']
Fest verdrahtet die erste Zeile, ohne die Rechnung zu prüfen.
Man verankert am td-Text und navigiert über die ancestor-tr zum Button derselben Zeile.
Welcher CSS-Selektor trifft ein Element, das BEIDE Klassen 'nav' und 'active' hat?
.nav.active
Kein Leerzeichen: beide Klassen am selben Element.
.nav .active
Ein Leerzeichen ist der Nachfahren-Kombinator.
.nav > .active
> ist der Kind-Kombinator, nicht 'beide Klassen'.
.nav,.active
Ein Komma ist eine Gruppierung (ODER).
Das Verketten der Klassenselektoren ohne Leerzeichen (.nav.active) verlangt beide Klassen am selben Element.
Was ist der Hauptzweck des Page-Object-Model-(POM-)Entwurfsmusters in der Selenium-Testautomatisierung?
Locators und Interaktionen einer Seite kapseln, damit Tests lesbar und die Wartung zentral ist.
Kernnutzen: Trennung von Seitenstruktur und Testlogik.
Den Bedarf an einem Test-Framework wie JUnit oder TestNG zu ersetzen.
POM ergänzt das Framework, ersetzt es nicht.
Den Browser durch Seiten-Caching schneller zu machen.
POM ist ein Entwurfsmuster ohne Einfluss auf die Browser-Leistung.
Testdaten für jede Seite automatisch zu generieren.
Testdatengenerierung hat nichts mit POM zu tun.
POM kapselt Locators und Interaktionen einer Seite in einer Klasse; Tests nutzen lesbare Methoden und Locator-Änderungen erfolgen an einer Stelle.
Das LoginPage-Objekt eines Teams bietet eine Methode, die Benutzername und Passwort eingibt, Submit klickt und dann ein DashboardPage-Objekt zurückgibt. Ein Reviewer nennt das gute POM-Praxis. Warum gilt das Zurückgeben des nächsten Page-Objekts aus einer Aktionsmethode als gutes Muster?
Es modelliert den Navigationsfluss und ermöglicht flüssige, typsichere Aufrufketten zur nächsten Seite.
Richtig: Die Aktion führt zu einer neuen Seite; die Rückgabe spiegelt die Nutzerreise.
Weil das Page-Objekt so die Test-Assertions enthalten kann.
Assertions gehören in Tests, nicht in Page-Objekte.
Weil es die WebDriver-Instanz global und statisch macht.
Globale statische Driver sind ein Anti-Muster.
Weil es Locators in der Page-Klasse überflüssig macht.
Page-Objekte enthalten weiterhin Locators.
Das Rückgeben des resultierenden Page-Objekts modelliert den Navigationsfluss und gibt Tests eine flüssige, typsichere Kette.
Welche zwei Praktiken passen zu einem gut entworfenen Page Object Model? (Wählen Sie zwei.)
Locators privat halten und Verhalten über aussagekräftige Methoden bereitstellen.
Kapselung ist zentral für POM.
Jede Seite (oder sinnvolle Komponente) hat ihre eigene Klasse.
Eine Klasse pro Seite/Komponente hält Verantwortlichkeiten klar.
Die Test-Assertions in die Page-Objekt-Methoden legen.
Assertions gehören in die Testebene.
In jeder Methode feste Thread.sleep()-Aufrufe für Stabilität.
Feste Sleeps sind ein Anti-Muster; explizite Waits sind besser.
Page-Objekte sollten Locators privat halten und aussagekräftige Methoden bereitstellen; sie sollten keine Test-Assertions enthalten.
Wo sollte in einem Page Object Model die WebDriver-Instanz einem Page-Objekt typischerweise bereitgestellt werden?
Über den Konstruktor des Page-Objekts injiziert.
Konstruktor-Injektion ist der Standardansatz.
In jeder Methode mit new neu erzeugt.
Ein neuer Driver pro Methode öffnet viele Browser und verliert den Zustand.
Aus einem fest verdrahteten globalen public static Feld gelesen.
Globaler statischer Zustand schadet Parallelität und Testbarkeit.
Bei jedem Aufruf von einem Remote-Server heruntergeladen.
Das ergibt keinen Sinn.
Der Driver wird meist über den Konstruktor injiziert, was das Objekt testbar und frei von globalem Zustand hält.
Ein Team stellt fest, dass die Locators einer gemeinsamen Header-Komponente auf zehn Seiten in zehn Page-Klassen kopiert sind. Welche POM-Verfeinerung entfernt diese Duplizierung?
Den Header in ein eigenes Komponenten-Page-Objekt extrahieren, das andere Seiten wiederverwenden.
Ein gemeinsames Komponentenobjekt zentralisiert Header-Locators und -Methoden.
Die Locators noch einmal in eine Basis-Testklasse kopieren.
Das fügt eine weitere Kopie hinzu.
Alle Header-Locators durch absolutes XPath ersetzen.
Ändert den Stil, behält aber die Duplizierung.
Die Header-Tests ganz löschen.
Abdeckung zu entfernen ist kein gültiges Refactoring.
Den Header in ein eigenes Komponenten-/Page-Objekt extrahieren, das andere Seiten nutzen — so leben die Locators an einer Stelle.
Welche Aussage beschreibt die Beziehung zwischen Page-Objekten und Testklassen am besten?
Tests rufen Page-Objekt-Methoden auf und prüfen die Ergebnisse selbst.
Saubere Trennung: Aktionen im Page-Objekt, Assertions im Test.
Page-Objekte rufen die Testklassen für Assertions auf.
Abhängigkeitsrichtung ist verkehrt.
Sie sind dieselbe Klasse mit zwei Namen.
Es sind getrennte Ebenen mit getrennten Aufgaben.
Es gibt keine Interaktion; sie laufen unabhängig.
Tests müssen Page-Objekte aufrufen.
Testklassen rufen Page-Objekt-Methoden auf und prüfen dann die Ergebnisse; das Page-Objekt verbirgt das Wie, der Test nennt das Was.
Wie unterscheidet sich ein impliziter Wait von einem expliziten Wait in Selenium WebDriver?
Implizit gilt global für Element-Suchen; explizit wartet auf eine definierte Bedingung für ein bestimmtes Element.
Das ist die entscheidende Unterscheidung.
Implizite Waits sind präziser als explizite Waits.
Explizite Waits sind die präzise, bedingungsbasierte Option.
Explizite Waits gelten automatisch für jeden Befehl.
Das beschreibt einen impliziten Wait.
Es gibt keinen Unterschied; beide sind Aliase.
Es sind wirklich unterschiedliche Mechanismen.
Ein impliziter Wait gilt global für alle findElement-Aufrufe; ein expliziter Wait (WebDriverWait) wartet auf eine bestimmte Bedingung für ein bestimmtes Element.
Eine Seite sendet ein Formular per AJAX. Nach Klick auf 'Save' erscheint ca. 1–3 Sekunden später ein Erfolgsbanner mit id 'toast-success'. Der Test schlägt sporadisch fehl, weil er das Banner sofort prüft. Welcher Aufruf mit explizitem Wait synchronisiert am besten mit dem Erscheinen des Banners?
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("toast-success")))
Wartet gezielt auf die Sichtbarkeit des Banners und beseitigt das Race.
Thread.sleep(3000) vor der Prüfung des Banners.
Ein fester Sleep ist fragil: zu kurz flakt er, zu lang verschwendet er Zeit.
Nur den impliziten Wait auf 30 Sekunden erhöhen.
Implizite Waits prüfen keine Sichtbarkeitsbedingungen; Mischen wird abgeraten.
driver.navigate().refresh() aufrufen und erneut prüfen.
Ein Refresh verwirft das AJAX-Ergebnis und das Banner.
WebDriverWait mit ExpectedConditions.visibilityOfElementLocated(By.id("toast-success")) pollt, bis das Banner sichtbar ist oder der Timeout erreicht wird.
Warum wird das Mischen von impliziten und expliziten Waits im selben Test allgemein abgeraten?
Es kann zu unvorhersehbaren, teils viel längeren Wartezeiten führen.
Das Zusammenspiel ist undefiniert und kann Verzögerungen verstärken.
Beide zu verwenden ist ein Compile-Fehler.
Es kompiliert; das Problem ist das Laufzeitverhalten.
Explizite Waits funktionieren gar nicht mehr, wenn ein impliziter Wait gesetzt ist.
Sie funktionieren noch, aber das Timing wird unvorhersehbar.
Es verdoppelt den Speicherverbrauch des Browsers.
Waits beeinflussen den Speicher nicht wesentlich.
Die Kombination kann zu unvorhersehbaren, längeren Wartezeiten führen, da die Mechanismen nicht additiv zusammenwirken.
Welche ExpectedCondition ist am geeignetsten, wenn ein Button nicht nur im DOM vorhanden, sondern auch klickbar sein muss?
ExpectedConditions.elementToBeClickable(locator)
Stellt sicher, dass das Element sichtbar und aktiviert ist.
ExpectedConditions.presenceOfElementLocated(locator)
Presence prüft nur das DOM; das Element kann verborgen/deaktiviert sein.
ExpectedConditions.titleIs("Home")
Das prüft den Seitentitel, nicht den Button.
ExpectedConditions.alertIsPresent()
Das wartet auf einen JavaScript-Alert.
elementToBeClickable wartet, bis das Element sichtbar und aktiviert ist — Voraussetzung für einen zuverlässigen Klick.
Was ist der Hauptvorteil eines FluentWait gegenüber einem einfachen WebDriverWait?
Man kann das Polling-Intervall setzen und gewählte Exception-Typen ignorieren.
FluentWait bietet pollingEvery und ignoring.
Es macht Locators überflüssig.
FluentWait braucht weiterhin eine Bedingung.
Es läuft ohne Timeout und wartet ewig.
FluentWait hat weiterhin ein Gesamt-Timeout.
Es wiederholt bei Fehlschlag automatisch den ganzen Test.
FluentWait pollt eine Bedingung; es wiederholt keine Tests.
FluentWait erlaubt das Konfigurieren des Polling-Intervalls und das Ignorieren bestimmter Exception-Typen während des Wartens.
Warum gelten fest verdrahtete Thread.sleep()-Aufrufe als schlechte Synchronisationsstrategie?
Es ignoriert den tatsächlichen App-Zustand — Zeitverschwendung oder weiter Flaky.
Feste Verzögerungen passen sich variablen Antwortzeiten nicht an.
Es funktioniert nur im Headless-Modus.
Thread.sleep() funktioniert unabhängig vom Headless-Modus.
Es wirft per Design NoSuchElementException.
sleep() pausiert nur den Thread.
Es wird von der Sprache Java nicht unterstützt.
Thread.sleep() ist Standard-Java.
Ein fester Sleep verschwendet Zeit, wenn die App schnell ist, oder flakt weiterhin, wenn sie langsam ist — er reagiert nicht auf den tatsächlichen Zustand.
Welche Methode lädt die aktuelle Seite in Selenium WebDriver neu?
driver.navigate().refresh()
Das ist die spezielle Reload-Methode.
driver.reload()
Es gibt keine reload()-Methode.
driver.get()
get() benötigt eine URL; refresh() lädt die aktuelle neu.
driver.switchTo().refresh()
switchTo() wechselt Kontext; es hat kein refresh().
driver.navigate().refresh() lädt die aktuelle Seite neu.
Um mit einem Element in einem <iframe> zu interagieren, was muss der Test zuerst tun?
Mit driver.switchTo().frame(...) in den Frame wechseln.
Elemente im iframe sind erst nach dem Wechsel erreichbar.
Nichts Besonderes; iframe-Elemente werden wie andere gefunden.
Ohne Wechsel sieht findElement die iframe-Elemente nicht.
driver.quit() aufrufen und eine neue Session starten.
Das verwirft die Session und hilft nicht.
Zuerst alle Cookies löschen.
Cookies haben nichts mit dem iframe-Kontext zu tun.
Man muss den Driver-Kontext in den Frame wechseln (switchTo().frame(...)), bevor man Elemente darin findet.
Ein Test gibt Daten in ein Feld innerhalb eines iframes (id 'editor') ein und muss dann einen 'Publish'-Button klicken, der auf der Hauptseite AUSSERHALB des iframes liegt. Was muss der Test nach dem Tippen im iframe vor dem Klick auf Publish tun — und warum?
driver.switchTo().defaultContent() aufrufen, um zum Hauptdokument zurückzukehren, da der Driver noch im iframe ist.
Der Kontext bleibt im iframe, bis man explizit zurückwechselt.
Nichts — der Klick funktioniert, da Publish auf derselben Seite ist.
Der Driver ist noch im iframe und sieht den äußeren Button nicht.
driver.switchTo().frame('editor') erneut aufrufen.
Das würde erneut in den iframe wechseln.
Den iframe per JavaScript löschen, bevor man klickt.
Den iframe zu zerstören ist destruktiv und unnötig.
Nach der Arbeit im Frame muss man mit switchTo().defaultContent() zum obersten Dokument zurückkehren, bevor man Elemente außerhalb des iframes findet.
Ein nativer JavaScript-Alert (window.alert) wird angezeigt. Welcher Selenium-Aufruf bestätigt (klickt OK) den Alert?
driver.switchTo().alert().accept()
Zum Alert wechseln, dann bestätigt accept() mit OK.
driver.findElement(By.id('ok')).click()
Ein nativer Alert ist nicht Teil des DOM.
driver.navigate().accept()
navigate() hat keine accept()-Methode.
driver.close()
close() schließt das Fenster, bestätigt nicht den Alert.
driver.switchTo().alert().accept() wechselt zum Alert und bestätigt ihn.
Um die Option mit dem sichtbaren Text 'Germany' aus einem Standard-HTML-<select> auszuwählen, welche Selenium-Hilfsklasse ist dafür vorgesehen?
Die Select-Klasse, z. B. new Select(element).selectByVisibleText("Germany").
Select ist der spezielle Helfer für <select>-Dropdowns.
Die Actions-Klasse mit doubleClick().
Actions ist für komplexe Gesten, nicht für <select>.
Die Alert-Klasse.
Alert behandelt JavaScript-Dialoge.
Die WebDriverWait-Klasse.
WebDriverWait ist für Synchronisation.
Die Select-Klasse bietet selectByVisibleText, selectByValue und selectByIndex für HTML-<select>-Elemente.
Welcher Navigationsaufruf bewegt den Browser zurück zur vorherigen Seite in der Historie?
driver.navigate().back()
Es geht einen Eintrag in der Historie zurück.
driver.back()
back() liegt am Navigation-Objekt via navigate().
driver.previous()
Es gibt kein previous().
driver.navigate().history(-1)
Navigation hat kein history().
driver.navigate().back() entspricht dem Zurück-Button des Browsers.
Eine CI-Pipeline führt 200 UI-Tests aus. Etwa 8 Tests bestehen lokal, fallen aber auf CI ca. jeden fünften Lauf durch — immer bei zeitkritischen Schritten rund um AJAX-Updates. Lokal laufen sie auf schnellen Rechnern; CI-Agenten sind langsamer und geteilt. Welche Ursache und Lösung erklären und beheben diese Flaky-Fehler am besten?
Unzureichende Synchronisation: Die Tests nehmen Timing an; feste Sleeps durch explizite Waits auf die AJAX-Abschlussbedingung ersetzen.
Explizite Waits passen sich langsameren CI-Agenten an.
Die Anwendung hat einen echten Bug; die 8 Tests dauerhaft deaktivieren.
Die Fehler sind timing- und umgebungsbedingt, kein reproduzierbarer Produktdefekt.
CI ist grundsätzlich unzuverlässig; die Suite bis zum Erfolg wiederholen.
Blindes Wiederholen verdeckt Flakiness und echte Regressionen.
Ein globales Thread.sleep(10000) zu jedem Test hinzufügen.
Riesige feste Sleeps verschwenden Zeit und garantieren nichts.
Das Symptom — sporadische Fehler auf langsameren geteilten CI-Agenten bei AJAX-Schritten — deutet auf unzureichende Synchronisation; feste Sleeps durch explizite Waits auf die erwartete Bedingung zu ersetzen ist die richtige Lösung.
Was ist ein 'flaky' Test?
Ein Test, der bei unverändertem Code mal besteht, mal fehlschlägt.
Nichtdeterministische Ergebnisse definieren Flakiness.
Ein Test, der immer fehlschlägt.
Ein stets fehlschlagender Test ist deterministisch.
Ein Test mit mehr als 100 Schritten.
Länge definiert keine Flakiness.
Ein in einer Skriptsprache geschriebener Test.
Die Sprache hat nichts mit Flakiness zu tun.
Ein flaky Test liefert bei unverändertem Code unterschiedliche Ergebnisse (pass/fail), meist wegen Timing-, Reihenfolge- oder Umgebungsproblemen.
Welche zwei Praktiken verbessern die Stabilität und Unabhängigkeit einer automatisierten UI-Testsuite? (Wählen Sie zwei.)
Jeden Test seine eigenen Daten auf- und abbauen lassen, damit Tests unabhängig sind.
Unabhängigkeit verhindert reihenfolgeabhängige Fehler.
Mit expliziten Waits auf sinnvolle Bedingungen synchronisieren statt fester Verzögerungen.
Bedingungsbasierte Waits passen sich Timing-Schwankungen an.
Tests Daten früherer Tests teilen und wiederverwenden lassen, um Zeit zu sparen.
Geteilter Zustand koppelt Tests und erzeugt Flakiness.
Überall großzügige feste Thread.sleep()-Aufrufe zur Sicherheit einfügen.
Feste Sleeps verlangsamen die Suite und garantieren nichts.
Unabhängige Tests, die ihre eigenen Daten auf- und abbauen, sowie robuste Waits reduzieren Flakiness. Geteilter Zustand und feste Sleeps schaden.
Eine StaleElementReferenceException wird geworfen. Was bedeutet das üblicherweise?
Die Element-Referenz ist nicht mehr am DOM angehängt (die Seite wurde neu gerendert).
Das Element nach der DOM-Änderung erneut suchen.
Dem Browser ist der Speicher ausgegangen.
Die Exception betrifft ein abgelöstes Element, nicht Speicher.
Die Locator-Syntax ist ungültig.
Ungültige Syntax wirft eine andere Exception.
Das Test-Framework ist falsch konfiguriert.
Es ist eine Laufzeit-DOM-Bedingung.
Eine zuvor gefundene WebElement-Referenz ist nicht mehr am DOM angehängt, meist weil die Seite oder ein Teil neu gerendert wurde.
Welcher Ansatz hält UI-Tests am besten unabhängig, sodass sie in beliebiger Reihenfolge oder parallel laufen können?
Jeder Test erzeugt seine eigenen Vorbedingungen und räumt seine Daten auf.
Eigenständige Tests laufen in beliebiger Reihenfolge und parallel.
Tests strikt in fester Reihenfolge ausführen und auf Daten früherer Tests bauen.
Reihenfolgeabhängigkeit verhindert Parallelität.
Geteilten Zustand in statischen Variablen über alle Tests speichern.
Geteilter statischer Zustand koppelt Tests.
Den Browser zwischen Tests nie zurücksetzen.
Zurückbleibender Browser-Zustand leckt zwischen Tests.
Jeder Test sollte den benötigten Zustand selbst erzeugen und danach aufräumen, damit kein Test von Seiteneffekten eines anderen abhängt.
Ein Test läuft gelegentlich direkt nach dem Neuladen des Ergebnis-Grids in eine StaleElementReferenceException. Was ist die robusteste Lösung?
Das Element nach dem Neuladen des Grids erneut suchen, abgesichert durch einen expliziten Wait.
Eine frische Suche nach der DOM-Änderung liefert eine gültige Referenz.
Die Exception fangen und still ignorieren.
Das Verschlucken verdeckt das Problem.
Die Browserfenstergröße erhöhen.
Die Fenstergröße hat nichts damit zu tun.
Die Element-Referenz in einem statischen Feld zwischenspeichern.
Zwischenspeichern über DOM-Änderungen erhöht die Staleness.
Das Element nach dem DOM-Update erneut suchen (idealerweise mit explizitem Wait abgesichert), um eine frische Referenz zu halten.