A4Q Selenium Tester Probeprüfung #5 — 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 Unterschied zwischen driver.close() und driver.quit() in Selenium WebDriver?
close() schließt das aktuelle Fenster; quit() beendet die Sitzung und schließt alle Fenster.
Richtig: quit() beendet zusätzlich den Treiberprozess, close() lässt die Sitzung bestehen, falls weitere Fenster offen sind.
Sie sind identisch; beide beenden die WebDriver-Sitzung.
Falsch: close() beendet die Sitzung nicht, wenn weitere Fenster offen sind.
close() beendet die Sitzung; quit() schließt ein Fenster.
Falsch: die Rollen sind vertauscht.
quit() löscht nur Cookies; close() leert den Cache.
Falsch: keine der Methoden betrifft Cookies oder Cache.
close() schließt nur das aktuelle Browserfenster/den aktuellen Tab; quit() beendet die gesamte WebDriver-Sitzung und schließt alle Fenster.
Was passiert, wenn findElement() kein passendes Element findet?
Es wird eine NoSuchElementException geworfen.
Richtig: definiertes Verhalten bei fehlgeschlagener Einzelsuche.
Es wird null zurückgegeben.
Falsch: WebDriver wirft eine Ausnahme, statt null zurückzugeben.
Es wird eine leere Liste zurückgegeben.
Falsch: das ist das Verhalten von findElements(), nicht findElement().
Es wartet unendlich, bis das Element erscheint.
Falsch: ohne expliziten/impliziten Wait schlägt es sofort fehl.
findElement() wirft sofort eine NoSuchElementException; findElements() gibt stattdessen eine leere Liste zurück.
Ein Preis-Label wird gerendert als: <span id="total" data-amount="49.90">€49.90</span>. Der Test muss den reinen Zahlenwert 49.90 lesen (nicht den formatierten Text). Welcher Aufruf liefert genau 49.90?
element.getAttribute("data-amount")
Richtig: liest das Attribut data-amount mit dem unformatierten Wert 49.90.
element.getText()
Falsch: liefert den sichtbaren Text '€49.90' inklusive Währungssymbol.
element.getAttribute("value")
Falsch: ein span hat kein value-Attribut, das ergibt null.
element.getTagName()
Falsch: liefert 'span', den Tag-Namen des Elements.
getText() liefert das sichtbare '€49.90'. Der reine Wert steht im Attribut data-amount, gelesen mit getAttribute("data-amount").
Über welches standardisierte Protokoll kommuniziert Selenium 4 mit Browsern?
Das W3C-WebDriver-Protokoll.
Richtig: Selenium 4 hat das JSON Wire Protocol zugunsten des W3C-Standards abgelöst.
Das alte JSON Wire Protocol.
Falsch: dieses Protokoll gehörte zu Selenium 3 und wurde in Selenium 4 entfernt.
FTP.
Falsch: FTP ist ein Dateiübertragungsprotokoll, ohne Bezug zur Browser-Automatisierung.
SMTP.
Falsch: SMTP ist ein E-Mail-Protokoll.
Selenium 4 ist vollständig W3C-WebDriver-konform; das alte JSON Wire Protocol wurde entfernt.
Eine Testklasse führt 12 Testmethoden aus. Jede Methode braucht eine frische, isolierte Browser-Sitzung, und nach dem Lauf darf kein Fenster offen bleiben, selbst wenn ein Test fehlschlägt. Wo instanziieren und wo verwerfen Sie den Treiber?
Treiber im @BeforeEach erzeugen und quit() im @AfterEach aufrufen.
Richtig: Setup pro Methode sichert Isolation; Teardown nach jedem Test garantiert Aufräumen auch bei Fehlern.
Einmal im @BeforeAll erzeugen und im @AfterAll beenden.
Falsch: eine geteilte Sitzung über 12 Tests bricht die Isolation (Zustand leckt zwischen Tests).
Im @BeforeEach erzeugen, aber quit() nur am Ende jedes Testkörpers aufrufen.
Falsch: schlägt ein Test vorher fehl, wird quit() nie erreicht und Fenster bleiben offen.
Sich darauf verlassen, dass die JVM den Browser beim Beenden schließt.
Falsch: der Browser-/Treiberprozess wird nicht automatisch aufgeräumt, es bleiben verwaiste Prozesse.
Isolation pro Test verlangt das Erzeugen im @BeforeEach und quit() im @AfterEach, das auch nach Fehlern ausgeführt wird.
Sie möchten zählen, wie viele <li>-Einträge eine Liste hat, wobei die Anzahl legitim null sein kann. Welche Methode nutzen Sie?
findElements(...).size()
Richtig: liefert 0 bei keinen Treffern statt einer Ausnahme, ideal zum Zählen.
findElement(...) in einer Schleife, bis es fehlschlägt.
Falsch: sich für einen normalen Nullwert auf eine Ausnahme zu verlassen ist fragil und langsam.
getPageSource().length()
Falsch: misst die HTML-Länge, nicht die Zahl der Listeneinträge.
getTitle().length()
Falsch: irrelevant — liefert die Länge des Seitentitels.
findElements() liefert eine Liste, die ohne Ausnahme leer (Größe 0) sein kann, sodass man Treffer inklusive null zählen kann.
Welche Aussage zu driver.getWindowHandle() und driver.getWindowHandles() ist korrekt?
getWindowHandle() liefert einen String; getWindowHandles() liefert ein Set von Strings.
Richtig: Singular gibt den aktuellen Handle, Plural alle Handles als Set.
Beide liefern eine Liste in garantierter Reihenfolge.
Falsch: getWindowHandles() liefert ein ungeordnetes Set, keine Liste.
getWindowHandle() öffnet ein neues Fenster.
Falsch: es liefert nur den aktuellen Handle und öffnet nichts.
getWindowHandles() wechselt den Fokus zum letzten Fenster.
Falsch: es liefert nur Handles; der Wechsel erfolgt über switchTo().window(handle).
getWindowHandle() (Singular) liefert den Handle des aktuellen Fensters als String; getWindowHandles() (Plural) liefert ein Set aller offenen Handles.
Welche ZWEI Fähigkeiten wurden in Selenium 4 eingeführt oder standardisiert? (Wählen Sie ZWEI)
Relative (friendly) Locators wie above(), below(), toLeftOf().
Richtig: relative Locators sind ein Selenium-4-Feature.
Nativer Zugriff auf das Chrome DevTools Protocol (CDP).
Richtig: Selenium 4 stellt CDP für Netzwerk, Geolocation und Konsole bereit.
Tests standardmäßig als Video aufzeichnen.
Falsch: WebDriver zeichnet kein Video auf; dafür braucht es externe Tools.
Automatische Erzeugung von Locators aus Screenshots.
Falsch: eine solche Funktion gibt es in Selenium 4 nicht.
Selenium 4 fügte relative (friendly) Locators und nativen Zugriff auf das Chrome DevTools Protocol hinzu und übernahm den W3C-Standard.
Welcher CSS-Selektor trifft ein Element mit id "submit-btn"?
#submit-btn
Richtig: '#' selektiert nach id.
.submit-btn
Falsch: '.' selektiert nach Klasse, nicht id.
submit-btn
Falsch: ein bloßes Token selektiert nach Tag-Name; ein <submit-btn>-Tag gibt es nicht.
*submit-btn
Falsch: keine gültige CSS-Syntax für eine id.
In CSS adressiert '#' eine id, also trifft #submit-btn id="submit-btn". '.' adressiert eine Klasse.
Gegeben: <input class="form-control" name="email" type="email"> und mehrere andere Inputs teilen class="form-control". Sie brauchen einen Locator, der eindeutig das E-Mail-Feld trifft. Welcher ist am besten?
css=input[name='email']
Richtig: das name-Attribut ist eindeutig und liefert einen stabilen Treffer.
css=.form-control
Falsch: diese Klasse ist geteilt und trifft mehrere Inputs, nicht nur E-Mail.
css=input
Falsch: trifft jedes Input der Seite.
css=input.email
Falsch: es gibt keine Klasse 'email'; 'email' ist der name-Wert, keine Klasse.
Die Klasse ist geteilt, also nicht eindeutig. Das name-Attribut 'email' ist eindeutig, daher trifft css=input[name='email'] zuverlässig.
Eine Seite hat einen Link <a href="/logout">Log out</a>. Es gibt mehrere Links, aber nur dieser hat exakt den Text 'Log out'. Welcher XPath wählt ihn über den sichtbaren Text?
//a[text()='Log out']
Richtig: trifft den Anker, dessen Text 'Log out' ist.
//a[@text='Log out']
Falsch: es gibt kein Attribut 'text'; der sichtbare Text ist ein Textknoten.
//a[@href='Log out']
Falsch: das prüft den href-Wert '/logout', nicht den Text.
//text()='Log out'
Falsch: kein gültiger XPath-Ausdruck, der ein Element selektiert.
//a[text()='Log out'] trifft ein <a>, dessen Textknoten exakt 'Log out' ist. normalize-space() wäre bei Leerraum nützlich.
Welcher CSS-Selektor trifft ein <a>, dessen href-Attribut mit '.pdf' endet?
a[href$='.pdf']
Richtig: '$=' bedeutet 'endet mit'.
a[href^='.pdf']
Falsch: '^=' bedeutet 'beginnt mit', nicht endet mit.
a[href*='.pdf']
'*=' bedeutet 'enthält' irgendwo, trifft also auch '.pdf.html' — nicht präzise 'endet mit'.
a[href='.pdf']
Falsch: verlangt, dass href exakt '.pdf' ist.
Der Operator '$=' in CSS trifft einen Attributwert, der mit dem Teilstring endet: a[href$='.pdf'].
Element: <button class="btn primary" data-test="save">Save</button>. Welche ZWEI Locators treffen diesen Button korrekt und eindeutig (data-test-Werte sind eindeutig)? (Wählen Sie ZWEI)
css=button[data-test='save']
Richtig: data-test ist eindeutig und stabil, ein idealer Locator.
//button[text()='Save']
Richtig: trifft den Button über den exakten Text 'Save'.
css=.btn
Falsch: 'btn' ist eine generische, geteilte Klasse und trifft wahrscheinlich viele Buttons.
css=#save
Falsch: der Button hat keine id, '#save' trifft nichts.
css=button[data-test='save'] nutzt das eindeutige data-test-Attribut; //button[text()='Save'] trifft den exakten Text. css=.btn ist geteilt; die id-Form ist ungültig, da keine id vorhanden ist.
In Selenium 4 möchten Sie das Input-Feld direkt über einem Label mit id 'password' finden. Welcher relative-locator-Ausdruck ist korrekt?
with(By.tagName("input")).above(By.id("password"))
Richtig: das ist die Selenium-4-API für relative Locators 'above'.
By.above("input", "password")
Falsch: By hat keine 'above'-Methode; relative Locators nutzen with().
By.cssSelector("input:above(#password)")
Falsch: ':above' ist keine gültige CSS-Pseudoklasse.
with(By.id("password")).below(By.tagName("input"))
Falsch: das kehrt die Beziehung um und verankert am falschen Element.
Relative Locators in Selenium 4 nutzen With.tagName(...).above(...). Also with(By.tagName("input")).above(By.id("password")).
Eine Tabellenzeile: <tr><td>ACME Ltd</td><td><button class="del">Delete</button></td></tr>. Sie müssen den Delete-Button in der Zeile klicken, deren erste Zelle 'ACME Ltd' ist. Welcher XPath ist korrekt?
//td[text()='ACME Ltd']/ancestor::tr//button[text()='Delete']
Richtig: verankert an der identifizierenden Zelle und findet den Delete-Button in derselben Zeile.
//button[text()='Delete']
Falsch: trifft jeden Delete-Button der Tabelle, nicht die bestimmte Zeile.
//td[text()='ACME Ltd']//button
Falsch: der Button ist kein Nachfahre der ersten Zelle, sondern in einer Nachbarzelle.
//tr[text()='ACME Ltd']//button
Falsch: der Text 'ACME Ltd' gehört zum <td>, nicht direkt zum <tr>.
Am eindeutigen Zellentext verankern, zur Zeile hoch und zum Button runter: //td[text()='ACME Ltd']/ancestor::tr//button[text()='Delete'].
Welche ZWEI Praktiken machen Locators robuster gegenüber UI-Änderungen? (Wählen Sie ZWEI)
Stabile, dedizierte Attribute wie id oder data-test bevorzugen.
Richtig: gezielte Test-Hooks ändern sich selten bei Styling/Layout.
Locators kurz und relativ zu einem stabilen Vorfahren halten.
Richtig: flache, relative Locators tolerieren DOM-Umbauten besser.
Vollständigen absoluten XPath ab /html/body verwenden.
Falsch: absolute Pfade brechen, sobald sich ein Zwischenelement ändert.
Sich auf Positionsindizes wie (//div)[7] verlassen.
Falsch: indexbasierte Locators brechen bei Hinzufügen/Umordnen von Elementen.
Stabile, gezielte Hooks (id, data-test) und kurze, flache Locators überstehen Änderungen. Lange absolute XPath und Index-Positionen sind fragil.
Was ist die Kernidee des Page Object Model (POM)?
Locators und Aktionen jeder Seite in einer eigenen Klasse kapseln.
Richtig: das zentralisiert Locators und stellt Verhalten als Methoden bereit — bessere Wartbarkeit.
Alle Testdaten in einem einzigen Objekt speichern.
Falsch: das beschreibt ein Daten-/Fixture-Muster, nicht POM.
Jeden Test in einer langen Methode schreiben.
Falsch: das Gegenteil der modularen Struktur, die POM fördert.
WebDriver in jedem Test durch einen Mock ersetzen.
Falsch: POM ist ein Entwurfsmuster, keine Mocking-Strategie.
POM kapselt Locators und Interaktionen einer Seite in einer eigenen Klasse, sodass Tests aussagekräftige Methoden aufrufen, statt Locator-Code zu duplizieren.
Wo sollten Test-Assertions nach guter POM-Praxis normalerweise liegen?
In den Testmethoden, nicht in den Page Objects.
Richtig: Assertions in Tests halten Page Objects wiederverwendbar und auf Interaktion fokussiert.
In jeder Methode des Page Objects.
Falsch: eingebettete Assertions koppeln Page Objects an konkrete Erwartungen und mindern Wiederverwendung.
Im WebDriver-Konstruktor.
Falsch: die Treiber-Initialisierung hat mit Assertions nichts zu tun.
Im HTML der zu testenden Seite.
Falsch: Assertions sind Testcode, kein Teil des Anwendungs-Markups.
Assertions gehören in die Testmethoden, nicht in Page Objects. Page Objects modellieren Struktur/Aktionen und liefern Daten/Zustände, die der Test prüft.
In einem gut entworfenen POM hat eine LoginPage eine Methode login(user, pass), die gültige Zugangsdaten absendet und auf dem Dashboard landet. Was sollte login() zurückgeben, damit der Test flüssig weiterarbeiten kann?
Ein DashboardPage-Objekt, das die Zielseite repräsentiert.
Richtig: die Rückgabe des nächsten Page Objects ermöglicht flüssiges, typsicheres Verketten.
Ein Boolean 'true', wenn irgendein Element vorhanden ist.
Falsch: ein bloßer Boolean verwirft den Navigationskontext und zwingt den Test, alles neu zu finden.
Die rohe WebDriver-Instanz.
Falsch: das Durchreichen des Treibers bricht die Kapselung, die POM bieten soll.
void (nichts).
Falsch: nichts zurückzugeben nach einem Seitenwechsel erzwingt manuelles Neu-Erzeugen der nächsten Seite.
Eine Navigationsaktion zu einer anderen Seite sollte das nächste Page Object (z. B. DashboardPage) zurückgeben, damit Tests verkettet und typsicher bleiben.
Was bewirkt die Annotation @FindBy in der PageFactory-Variante von POM?
Sie deklariert den Locator zur Auflösung eines WebElement-Felds.
Richtig: @FindBy verknüpft einen Locator mit einem Feld, das PageFactory lazy auflöst.
Sie führt eine Assertion auf dem Element aus.
Falsch: sie deklariert nur die Suche, keine Assertion.
Sie startet den Browser.
Falsch: sie hat mit dem Start einer Treibersitzung nichts zu tun.
Sie erstellt einen Screenshot des Elements.
Falsch: Screenshots haben mit @FindBy nichts zu tun.
@FindBy deklariert den Locator für ein WebElement-Feld; PageFactory.initElements(...) erzeugt Lazy-Proxies, die den Locator bei Nutzung auflösen.
Ein Locator für den 'Checkout'-Button wird in 15 Tests verwendet. Die id des Buttons ändert sich. Wie viele Stellen müssen Sie bei gut angewandtem Page Object Model ändern?
Eine — den Locator im Page Object.
Richtig: der zentrale Locator bedeutet, eine Änderung repariert alle 15 Tests.
Fünfzehn — einen pro Test.
Falsch: genau diese Duplizierung soll POM beseitigen.
Dreißig — der Locator plus seine Assertion je Test.
Falsch: Assertions sind getrennt und der Locator bleibt in POM zentral.
Keine — Selenium heilt Locators automatisch.
Falsch: Selenium hat kein eingebautes Self-Healing für Locators.
POM zentralisiert jeden Locator in einer Seitenklasse, sodass eine Änderung an genau einer Stelle erfolgt, egal wie viele Tests ihn nutzen.
Welche ZWEI Elemente gehören in eine Page-Object-Klasse? (Wählen Sie ZWEI)
Element-Locators dieser Seite.
Richtig: Locators sind der Hauptinhalt eines Page Objects.
Aktionsmethoden wie search() oder login().
Richtig: Verhaltensmethoden stellen die Interaktionen der Seite bereit.
Die Pass/Fail-Assertions einzelner Tests.
Falsch: Assertions gehören in die Tests, damit Page Objects wiederverwendbar bleiben.
Die Ablaufkonfiguration des Test-Runners.
Falsch: Runner-Konfiguration ist Infrastruktur, keine Seitenmodellierung.
Ein Page Object enthält die Element-Locators und Aktions-/Servicemethoden (z. B. login, search). Test-Assertions und die Ablaufsteuerung gehören nicht dorthin.
Was ist der zentrale Unterschied zwischen implizitem und explizitem Warten?
Impliziter Wait gilt global; expliziter Wait zielt auf eine bestimmte Bedingung.
Richtig: implizit gilt überall; explizit wartet auf eine definierte Bedingung.
Impliziter Wait pausiert jedes Mal eine feste Sekundenzahl, unabhängig vom Zustand.
Falsch: das beschreibt Thread.sleep; impliziter Wait pollt und kehrt zurück, sobald gefunden.
Expliziter Wait ist global; impliziter Wait zielt auf ein Element.
Falsch: die Rollen sind vertauscht.
Sie sind gleich und können problemlos gemischt werden.
Falsch: sie unterscheiden sich, und das Mischen kann zu unvorhersehbaren Timeouts führen.
Ein impliziter Wait ist ein globales Timeout für jede Elementsuche; ein expliziter Wait zielt auf eine bestimmte Bedingung an einem bestimmten Element.
Nach Klick auf 'Load more' werden Ergebnisse per AJAX eingefügt und ein Container mit id 'results' wird nach variabler Verzögerung sichtbar. Sie müssen warten, bis er sichtbar ist. Welcher explizite Wait (Selenium 4) ist korrekt?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.visibilityOfElementLocated(By.id("results")))
Richtig: wartet bis 10 s auf Vorhandensein und Sichtbarkeit, bevor es zurückgibt.
Thread.sleep(10000)
Falsch: fester Sleep ist langsam bzw. fragil und prüft die Bedingung nicht.
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)) und dann getText()
Falsch: impliziter Wait deckt Vorhandensein, aber nicht Sichtbarkeit ab; ein verborgener Container schlägt weiter fehl.
driver.findElement(By.id("results")).getText() sofort
Falsch: ohne Wait wirft das eine NoSuchElementException, während AJAX noch lädt.
WebDriverWait mit Duration und ExpectedConditions.visibilityOfElementLocated(By.id("results")) verwenden, um auf Vorhandensein und Sichtbarkeit zu warten.
Warum wird Thread.sleep() als Synchronisationsmechanismus in Selenium-Tests abgeraten?
Es wartet immer die volle feste Zeit, was Tests je nach Wert langsam oder fragil macht.
Richtig: es ignoriert den tatsächlichen Zustand und verschwendet Zeit oder schlägt sporadisch fehl.
Es wird von der Sprache Java nicht unterstützt.
Falsch: Thread.sleep ist Standard-Java; das Problem ist das Verhalten, nicht die Verfügbarkeit.
Es schließt die Browsersitzung.
Falsch: Schlafen beeinflusst die WebDriver-Sitzung nicht.
Es pollt das DOM alle 500 ms wie ein expliziter Wait.
Falsch: es pollt gar nicht, sondern blockiert nur für die feste Dauer.
Thread.sleep pausiert eine feste Dauer unabhängig von der Bereitschaft — langsam bei zu langer, fragil bei zu kurzer Wartezeit.
Ein 'Submit'-Button ist im DOM vorhanden, bleibt aber deaktiviert, bis das Formular gültig ist. Zu frühes Klicken bewirkt nichts. Auf welche ExpectedCondition sollten Sie vor click() warten?
ExpectedConditions.elementToBeClickable(...)
Richtig: verlangt sichtbar UND aktiviert, passend zum erst bei Gültigkeit aktivierten Button.
ExpectedConditions.presenceOfElementLocated(...)
Falsch: Presence prüft nur das Vorhandensein im DOM; der Button ist vorhanden, aber deaktiviert.
ExpectedConditions.titleContains(...)
Falsch: prüft den Seitentitel, ohne Bezug zum Buttonzustand.
ExpectedConditions.alertIsPresent()
Falsch: in diesem Szenario gibt es keinen Alert.
elementToBeClickable wartet, bis das Element sichtbar UND aktiviert ist — genau die Bedingung für einen erst bei Gültigkeit aktivierten Button.
Was lässt sich mit einem FluentWait konfigurieren, das ein einfacher WebDriverWait-Konstruktor nicht betont?
Das Polling-Intervall und welche Ausnahmen beim Pollen ignoriert werden.
Richtig: FluentWait bietet pollingEvery(...) und ignoring(...) neben dem Timeout.
Den User-Agent-String des Browsers.
Falsch: der User-Agent ist eine Browser-/Capability-Einstellung, kein Teil eines Waits.
Die Bildschirmauflösung des Testrechners.
Falsch: hat mit Warte-Logik nichts zu tun.
Die Anzahl paralleler Threads der Suite.
Falsch: Parallelität wird im Test-Runner konfiguriert, nicht in einem Wait.
FluentWait erlaubt das Setzen des Polling-Intervalls und das Ignorieren bestimmter Ausnahmetypen während des Pollings, zusätzlich zum Gesamttimeout.
Welche ZWEI sind gültige ExpectedConditions aus Seleniums Support-Bibliothek? (Wählen Sie ZWEI)
visibilityOfElementLocated(By)
Richtig: eine Standardbedingung, die auf Vorhandensein und Sichtbarkeit wartet.
textToBePresentInElement(element, text)
Richtig: eine Standardbedingung, die auf bestimmten Text im Element wartet.
elementHasNiceColor(By)
Falsch: eine solche Bedingung gibt es in Selenium nicht.
pageIsBeautiful()
Falsch: erfunden; nicht Teil der ExpectedConditions-API.
visibilityOfElementLocated und textToBePresentInElement sind Standard-ExpectedConditions. 'elementHasNiceColor' und 'pageIsBeautiful' sind erfunden.
Welches Paar von Aufrufen lädt jeweils eine URL im aktuellen Browserfenster?
driver.get(url) und driver.navigate().to(url)
Richtig: beide navigieren zur angegebenen URL im aktuellen Fenster.
driver.open(url) und driver.load(url)
Falsch: weder open() noch load() existieren auf WebDriver.
driver.goTo(url) und driver.visit(url)
Falsch: diese Methodennamen gehören nicht zur WebDriver-API.
driver.getUrl(url) und driver.setUrl(url)
Falsch: getCurrentUrl() liest die URL ohne Argument; setUrl() existiert nicht.
Sowohl driver.get(url) als auch driver.navigate().to(url) laden eine Seite; get() ist im Wesentlichen die Kurzform, navigate() ergänzt History (back()/forward()).
Welcher Aufruf kehrt zur vorherigen Seite in der Browser-History zurück?
driver.navigate().back()
Richtig: navigiert einen Eintrag in der History zurück.
driver.back()
Falsch: back() liegt am Navigation-Objekt, nicht direkt am driver.
driver.navigate().refresh()
Falsch: refresh() lädt die aktuelle Seite neu, geht nicht zurück.
driver.navigate().forward()
Falsch: forward() geht vorwärts, nicht zurück.
driver.navigate().back() geht einen Schritt in der History zurück, wie der Zurück-Button.
Ein Zahlungsformular liegt in einem <iframe id="pay">. Nach dem Ausfüllen und Absenden der Felder darin müssen Sie einen 'Continue'-Button klicken, der im HAUPTdokument außerhalb des iframes liegt. Was müssen Sie vor dem Lokalisieren von 'Continue' tun?
driver.switchTo().defaultContent() aufrufen, um zum Hauptdokument zurückzukehren.
Richtig: stellt den Fokus auf das oberste Dokument wieder her, sodass Hauptseiten-Elemente auffindbar sind.
Erneut driver.switchTo().frame("pay") aufrufen.
Falsch: das bleibt im iframe, wo 'Continue' nicht existiert.
Die Seite mit navigate().refresh() neu laden.
Falsch: ein Refresh verwirft den Formularzustand und löst das Frame-Kontextproblem nicht.
Nichts — Elemente im Hauptdokument sind aus einem iframe immer erreichbar.
Falsch: mit Fokus im iframe sind Elemente des Hauptdokuments nicht im Kontext.
Während der Fokus im iframe ist, ist das Hauptdokument außerhalb des Kontexts. Man muss mit driver.switchTo().defaultContent() zurückwechseln.
Ein JavaScript-confirm()-Dialog erscheint. Wie bestätigen Sie ihn (OK) in Selenium?
driver.switchTo().alert().accept()
Richtig: wechselt zum Alert und klickt OK.
driver.findElement(By.id("ok")).click()
Falsch: native Browser-Dialoge sind nicht Teil des DOM und nicht per By auffindbar.
driver.switchTo().alert().dismiss()
Falsch: dismiss() bricht ab (Abbrechen), bestätigt nicht.
driver.navigate().refresh()
Falsch: ein Refresh interagiert nicht mit dem Dialog.
Zum Alert wechseln und bestätigen: driver.switchTo().alert().accept(). dismiss() würde abbrechen.
Ein Klick auf 'View invoice' öffnet die Rechnung in einem NEUEN Tab. Sie müssen Text darauf lesen, den Tab schließen und zum ursprünglichen Tab zurückkehren. Welche Reihenfolge ist korrekt?
Aktuellen Handle merken, switchTo().window(newHandle), lesen, close(), dann switchTo().window(originalHandle).
Richtig: man muss explizit zum neuen Tab wechseln und nach dem Schließen zurück.
Einfach getText() aufrufen — WebDriver folgt dem neuen Tab automatisch.
Falsch: der Fokus bleibt auf dem ursprünglichen Tab bis zu switchTo().window(...).
driver.navigate().forward() aufrufen, um den neuen Tab zu erreichen.
Falsch: forward() bewegt sich in der History eines Tabs, nicht zwischen Tabs.
driver.quit() aufrufen und dann die Originalseite erneut öffnen.
Falsch: quit() beendet die gesamte Sitzung und verliert allen Zustand.
Ursprünglichen Handle merken, neuen Handle in getWindowHandles() finden, switchTo().window(newHandle), lesen/schließen, dann switchTo().window(originalHandle).
Ein Untermenü erscheint nur, wenn die Maus über einem Hauptmenüpunkt schwebt. Welche Selenium-API modelliert dieses Hover-dann-Klick?
Die Actions-Klasse, z. B. new Actions(driver).moveToElement(menu).click(submenu).perform()
Richtig: Actions modelliert erweiterte Zeigersequenzen wie Hover-dann-Klick.
driver.get() auf die Submenü-URL.
Falsch: das Untermenü ist keine eigene URL, es erscheint per Hover-Zustand.
driver.switchTo().frame(menu)
Falsch: Frame-Wechsel hat mit Hover über ein Menü nichts zu tun.
driver.manage().window().fullscreen()
Falsch: fullscreen ändert die Fenstergröße, nicht das Hover-Verhalten.
Die Actions-Klasse baut zusammengesetzte Eingabesequenzen; moveToElement(menu).click(submenu).perform() führt Hover und Klick aus.
Was ist ein 'flaky' (instabiler) automatisierter Test?
Ein Test, der ohne Code- oder Umgebungsänderung mal besteht und mal fehlschlägt.
Richtig: nicht-deterministische Ergebnisse ohne echte Änderung sind die Definition.
Ein Test, der immer fehlschlägt.
Falsch: ein konstant fehlschlagender Test ist deterministisch und zeigt einen echten Defekt.
Ein Test mit mehr als 100 Schritten.
Falsch: die Länge allein macht einen Test nicht flaky.
Ein Test in einer Skriptsprache.
Falsch: die Sprache hat mit Flakiness nichts zu tun.
Ein flaky Test liefert bei gleichem Code und gleicher Umgebung unterschiedliche Ergebnisse (Pass/Fail) ohne echte Änderung und untergräbt das Vertrauen.
Was ist die häufigste Ursache für instabile Selenium-UI-Tests?
Timing-/Synchronisationsprobleme — Handeln, bevor Elemente bereit sind.
Richtig: Race Conditions zwischen Test und Rendering sind die Hauptursache; explizite Waits helfen.
Zu wenige Kommentare im Code.
Falsch: Kommentare beeinflussen das Laufzeitverhalten nicht.
Testmethoden auf Englisch benennen.
Falsch: die Sprache der Methodennamen ist für Stabilität irrelevant.
Die Tests kompilieren statt interpretieren.
Falsch: Kompilieren vs. Interpretieren verursacht keine Flakiness.
Timing-/Synchronisationsprobleme — Interaktion mit noch nicht bereiten Elementen — sind die Hauptursache, am besten mit expliziten Waits behoben.
Ein Test speichert ein WebElement in einer Variablen, dann rendert die Seite eine Liste per AJAX neu, und die nächste Aktion auf dieser Variablen wirft StaleElementReferenceException. Was ist die richtige Lösung?
Das Element nach dem DOM-Update neu lokalisieren, statt die stale Referenz wiederzuverwenden.
Richtig: der alte Knoten wurde ersetzt; ein frisches findElement (nach Wait) löst den aktuellen Knoten auf.
Die Aktion in try/catch hüllen und die Ausnahme ignorieren.
Falsch: das Verschlucken verdeckt den Fehler, und die Aktion findet trotzdem nicht statt.
Den impliziten Wait auf 60 Sekunden erhöhen.
Falsch: ein längerer impliziter Wait aktualisiert eine bereits stale Referenz nicht.
Vor jeder Aktion den Browser neu starten.
Falsch: ein Neustart ist drastisch, langsam und unnötig; Neu-Lokalisieren genügt.
Eine stale Referenz zeigt auf einen ersetzten DOM-Knoten. Die Lösung ist, das Element nach der DOM-Änderung neu zu lokalisieren (idealerweise nach einem expliziten Wait).
Warum sollte jeder automatisierte Test unabhängig von den anderen sein?
Damit Tests in beliebiger Reihenfolge oder parallel laufen und ein Fehler nicht kaskadiert.
Richtig: Unabhängigkeit ermöglicht Parallelität und isoliert Fehler zur klaren Diagnose.
Damit die Suite langsamer läuft und leichter zu beobachten ist.
Falsch: Unabhängigkeit unterstützt Geschwindigkeit durch Parallelität.
Damit Tests immer eine Browsersitzung teilen müssen.
Falsch: Unabhängigkeit bedeutet meist das Gegenteil — isolierte Sitzungen/Zustände.
Damit man alle Assertions entfernen kann.
Falsch: Unabhängigkeit hat mit dem Entfernen von Assertions nichts zu tun.
Unabhängige Tests laufen in beliebiger Reihenfolge und parallel, und ein Fehler in einem kaskadiert nicht in andere — bessere Zuverlässigkeit und Diagnose.
Welche ZWEI Praktiken reduzieren Flakiness in einer Selenium-Suite auf einem CI-Server? (Wählen Sie ZWEI)
Explizite Waits auf die genaue Bedingung statt fester Sleeps verwenden.
Richtig: bedingungsbasierte Waits passen sich variabler CI-Zeit an und senken Timing-Flakiness.
Jeden Test eigene isolierte Daten anlegen und aufräumen lassen.
Richtig: eigenständige Daten verhindern Interferenzen zwischen Tests, gerade bei parallelen CI-Läufen.
Vor jeder Interaktion Thread.sleep(5000) einfügen.
Falsch: feste Sleeps sind langsam und bleiben flaky, wenn der Server langsamer ist.
Tests von den Daten des vorherigen Tests abhängig machen.
Falsch: Reihenfolgeabhängigkeit ist eine klassische Flakiness-Quelle, besonders parallel.
Explizite Waits für Bedingungen und eigene isolierte Testdaten reduzieren Flakiness. Feste Sleeps und Abhängigkeit von der Reihenfolge erhöhen sie.
Ein automatischer Screenshot beim Fehlschlagen eines Tests hilft vor allem wobei?
Die Fehlerursache zu diagnostizieren, indem der UI-Zustand in dem Moment gezeigt wird.
Richtig: der Screenshot ist ein Diagnose-Artefakt des Fehlerzustands, unschätzbar in CI.
Den Testlauf schneller zu machen.
Falsch: ein Screenshot kostet etwas Zeit und beschleunigt den Lauf nicht.
Das Fehlschlagen zu verhindern.
Falsch: ein Screenshot dokumentiert den Fehler, verhindert ihn nicht.
Den defekten Locator automatisch zu reparieren.
Falsch: Screenshots ändern oder reparieren keinen Testcode.
Ein Fehler-Screenshot hält den UI-Zustand im Moment des Fehlers fest und beschleunigt Debugging/Diagnose, besonders bei headless CI-Läufen.