A4Q Selenium Tester Probeprüfung #1 — 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.
Wie kommuniziert Selenium WebDriver mit einem echten Browser wie Chrome oder Firefox?
Über einen browserspezifischen Treiber mit dem W3C-WebDriver-Protokoll
Richtig — die Client-Bibliothek spricht über HTTP mit einem Treiber (chromedriver/geckodriver), der den Browser steuert.
Durch Einschleusen von JavaScript, was die einzige Steuerungsart ist
Falsch — WebDriver kann JavaScript ausführen, aber native Befehle laufen über den Treiber, nicht nur über eingeschleustes JS.
Durch direkte Änderung des Browser-Quellcodes zur Laufzeit
Falsch — WebDriver ändert keinen Browser-Quellcode; es automatisiert den Browser über dessen Treiber.
Durch Pixel-Screenscraping und Maussimulation auf OS-Ebene
Falsch — das beschreibt bildbasierte Werkzeuge; WebDriver nutzt die Automatisierungs-API des Browsers über den Treiber.
WebDriver sendet Befehle über das W3C-WebDriver-Protokoll (HTTP/JSON) an ein browserspezifisches Treiber-Programm (z. B. chromedriver, geckodriver), das den Browser steuert.
Was passiert, wenn driver.findElement(By.id("login")) aufgerufen wird und kein Element mit dieser id auf der Seite existiert?
Es wird eine NoSuchElementException geworfen
Richtig — findElement wirft NoSuchElementException, wenn nichts passt.
Es gibt null zurück
Falsch — findElement gibt nie null zurück, sondern wirft. findElements liefert stattdessen eine leere Liste.
Es gibt ein leeres WebElement zurück
Falsch — ein 'leeres WebElement' gibt es nicht; der Aufruf schlägt mit einer Exception fehl.
Es wartet unendlich, bis das Element erscheint
Falsch — findElement blockiert nicht unendlich; ohne Wait schlägt es sofort fehl.
findElement wirft sofort eine NoSuchElementException, wenn kein passendes Element gefunden wird.
Wie verhält sich driver.findElements(By.className("row")), wenn keine passenden Elemente vorhanden sind?
Es gibt eine leere Liste zurück
Richtig — findElements liefert eine Liste der Größe 0, wenn nichts passt.
Es wirft eine NoSuchElementException
Falsch — das ist das Verhalten von findElement; findElements wirft bei null Treffern nicht.
Es gibt null zurück
Falsch — es gibt eine leere Sammlung zurück, niemals null.
findElements gibt eine leere Liste (Größe 0) zurück und wirft keine Exception; das ist nützlich für Existenzprüfungen.
Worin besteht der Unterschied zwischen driver.close() und driver.quit()?
close() schließt das aktuelle Fenster; quit() schließt alle Fenster und beendet die Sitzung
Richtig — quit() beendet zudem den Treiberprozess und gibt Ressourcen frei.
Sie sind identische Aliase derselben Operation
Falsch — sie unterscheiden sich: close() betrifft ein Fenster, quit() die ganze Sitzung.
quit() schließt nur den aktiven Tab; close() beendet die Sitzung
Falsch — das vertauscht die beiden Methoden.
close() löscht Cookies; quit() lässt den Browser offen
Falsch — keine der Methoden betrifft Cookies, und quit() lässt den Browser nicht offen.
close() schließt das aktuelle Browserfenster/den Tab; quit() schließt alle vom Treiber geöffneten Fenster und beendet die WebDriver-Sitzung.
Welche der folgenden sind gültige eingebaute Locator-Strategien der By-Klasse in Selenium WebDriver? (Wähle zwei.)
By.cssSelector
Richtig — cssSelector ist eine zentrale By-Strategie.
By.xpath
Richtig — xpath ist eine zentrale By-Strategie.
By.value
Falsch — By.value gibt es nicht; einen Attributwert über CSS oder XPath ansprechen.
By.placeholder
Falsch — placeholder ist keine By-Strategie; per CSS-Attributselektor ansprechen.
Gültige By-Strategien sind u. a. id, name, className, tagName, linkText, partialLinkText, cssSelector und xpath. 'value' und 'placeholder' sind keine eigenen Strategien.
Sie möchten die sichtbare Beschriftung eines Buttons in einen String einlesen. Welche WebElement-Methode verwenden Sie?
getText()
Richtig — getText() gibt den gerenderten sichtbaren Text des Elements zurück.
getAttribute("text")
Falsch — ein Standardattribut 'text' gibt es nicht; für sichtbaren Inhalt getText() nutzen.
getTagName()
Falsch — getTagName() gibt das HTML-Tag zurück, nicht die Beschriftung.
getCssValue("label")
Falsch — getCssValue liest CSS-Eigenschaften, nicht den Text.
getText() liefert den sichtbaren, gerenderten Text eines Elements; getAttribute() liest den Wert eines bestimmten HTML-Attributs.
Ein <input>-Feld enthält bereits den Text "abc". Sie rufen element.sendKeys("123") auf. Welchen Wert hat das Feld danach (ohne weitere Aktion)?
abc123
Richtig — sendKeys hängt an, daher bleibt "abc" erhalten und "123" wird ergänzt.
123
Falsch — das erforderte zuerst clear(); sendKeys allein löscht nicht.
123abc
Falsch — die Eingaben werden an der Cursorposition (Ende) angehängt, nicht vorangestellt.
Ein leerer String
Falsch — sendKeys fügt Text hinzu, es leert das Feld nie.
sendKeys hängt an den vorhandenen Inhalt an; es leert das Feld nicht. Zum Ersetzen zuerst clear() aufrufen.
Welche Aussage beschreibt am besten die Beziehung zwischen dem WebDriver-Interface und einer Klasse wie ChromeDriver?
WebDriver ist ein Interface, das ChromeDriver implementiert
Richtig — gegen das WebDriver-Interface zu programmieren hält Tests browserunabhängig.
ChromeDriver ist ein Interface, das WebDriver implementiert
Falsch — das vertauscht die Beziehung; WebDriver ist das Interface.
Sie sind unverbundene Klassen ohne Vererbungsbeziehung
Falsch — ChromeDriver implementiert WebDriver, sie sind also verbunden.
WebDriver ist eine Unterklasse von ChromeDriver
Falsch — es ist umgekehrt; ChromeDriver implementiert das WebDriver-Interface.
WebDriver ist ein Interface; browserspezifische Klassen wie ChromeDriver, FirefoxDriver und EdgeDriver implementieren es, sodass Tests gegen das Interface geschrieben werden können.
Eine Seite enthält folgendes Element:
<input type="text" id="user-email" name="email" class="form-control required">
Welcher CSS-Selektor adressiert dieses eine Input am robustesten über seine id?
#user-email
Richtig — # selektiert über die id, die eindeutig ist, und liefert einen kurzen stabilen Locator.
.form-control.required
Falsch — Klassenselektoren treffen ggf. viele Elemente und Klassen ändern sich oft; weniger robust als die id.
input
Falsch — der Tag-Selektor trifft jedes input auf der Seite, ist also nicht eindeutig.
Falsch — die id ist user-email, nicht email; #email trifft hier nichts.
Eine id ist auf einer gültigen Seite eindeutig, daher ist der id-Selektor #user-email hier der robusteste CSS-Locator.
Worin unterscheidet sich in XPath ein Pfad, der mit // beginnt, von einem, der mit / beginnt?
// sucht Nachfahren überall; / selektiert ab der Dokumentwurzel
Richtig — // ist eine relative/Nachfahrensuche; ein einzelnes führendes / ist ein absoluter Pfad ab der Wurzel.
// ist für CSS und / für XPath
Falsch — beide sind XPath-Syntax; keines ist CSS.
// wählt nur den ersten Treffer; / wählt alle
Falsch — keiner der Operatoren beschränkt auf den ersten Treffer; das macht eine Indizierung wie [1].
Es gibt keinen Unterschied; sie sind austauschbar
Falsch — sie verhalten sich sehr unterschiedlich (Nachfahrensuche vs. absoluter Wurzelpfad).
Ein führendes / selektiert ab der Dokumentwurzel (absolut), während // passende Knoten an beliebiger Stelle im Dokument selektiert (Nachfahrensuche).
Die Seite hat zwei Buttons:
<button class="btn">Cancel</button> <button class="btn">Submit</button>
Welcher XPath wählt nur den Submit-Button über seinen sichtbaren Text?
//button[text()='Submit']
Richtig — es trifft den Button, dessen Textknoten 'Submit' ist.
//button[@class='btn']
Falsch — beide Buttons haben die Klasse btn, das trifft zwei Elemente.
//button
Falsch — das trifft jeden Button der Seite, nicht nur Submit.
//button[@text='Submit']
Falsch — es gibt kein text-Attribut; sichtbarer Text braucht die Funktion text(), nicht @text.
Beide Buttons teilen die Klasse btn, daher ist ein Klassen-Locator mehrdeutig. Der Abgleich des exakten Textes mit text()='Submit' wählt nur den Submit-Button.
Welches Präfix selektiert in einem CSS-Selektor ein Element über sein class-Attribut?
Ein Punkt, z. B. .btn
Richtig — das Punkt-Präfix selektiert in CSS über den Klassennamen.
Eine Raute, z. B. #btn
Falsch — die Raute selektiert über die id, nicht über die Klasse.
Ein At-Zeichen, z. B. @btn
Falsch — @ ist XPath-Attributsyntax, nicht CSS.
Ein Doppelpunkt, z. B. :btn
Falsch — ein Doppelpunkt leitet eine Pseudoklasse ein (z. B. :hover), keinen Klassentreffer.
In CSS selektiert . (Punkt) über die Klasse und # (Raute) über die id.
Welche der folgenden Locator-Praktiken führen im Allgemeinen zu STABILEREN, wartbareren Tests? (Wähle zwei.)
Eine eindeutige id oder ein eigenes data-testid-Attribut verwenden
Richtig — diese sind stabil und ändern sich selten durch Styling oder Layout.
Kurze, gezielte CSS-Selektoren auf Basis aussagekräftiger Attribute
Richtig — prägnantes attributbasiertes CSS ist lesbar und widerstandsfähig gegen Layoutänderungen.
Lange absolute XPaths wie /html/body/div[3]/div[2]/form/input[1]
Falsch — absolute Pfade brechen bei fast jeder DOM-Änderung; sie sind fragil.
Elemente über ihren numerischen Positionsindex auswählen
Falsch — Positionsindizes ändern sich bei jeder Änderung der Geschwisterreihenfolge und machen Tests instabil.
Stabile Locators bevorzugen eindeutige ids und eigens gesetzte Testattribute; lange absolute XPaths und Positionsindizes brechen leicht bei DOM-Änderungen.
Sie müssen dieses Feld über sein name-Attribut selektieren:
<input name="email" type="email">
Welcher CSS-Attributselektor ist korrekt?
input[name='email']
Richtig — die Attributsyntax mit eckigen Klammern trifft das name-Attribut exakt.
input(name='email')
Falsch — CSS nutzt keine runden Klammern für Attributselektion.
input@name='email'
Falsch — @ ist XPath-Attributsyntax, nicht CSS.
input.name.email
Falsch — Punkte selektieren Klassen namens 'name' und 'email', nicht das name-Attribut.
Ein CSS-Attributselektor nutzt eckige Klammern: input[name='email'] trifft ein input, dessen name-Attribut email ist.
Gegeben dieses Markup, benötigen Sie das <input>, das direkt auf das Label folgt:
<label for="q">Search</label><input id="q" type="text">
Welcher XPath nutzt eine Achse, um das input als following-sibling des Labels zu selektieren?
//label/following-sibling::input
Richtig — die Achse following-sibling selektiert das input, das auf gleicher Ebene auf das Label folgt.
//label/child::input
Falsch — das input ist ein Geschwister des Labels, kein Kind; child:: trifft nichts.
//label/parent::input
Falsch — die parent-Achse geht nach oben; ein input ist nicht der Elternknoten eines Labels.
//label/preceding-sibling::input
Falsch — preceding-sibling schaut zurück, aber das input kommt nach dem Label.
Die Achse following-sibling selektiert Geschwister nach dem Kontextknoten. //label/following-sibling::input wählt das input nach dem Label.
Ein Element hat eine dynamische Klasse, die immer das Wort 'alert' enthält, aber mit zusätzlichen Suffixen, z. B. class="alert alert-danger fade-in". Welcher XPath trifft zuverlässig jedes Element, dessen class 'alert' enthält?
//*[contains(@class,'alert')]
Richtig — contains() macht einen Teilstring-Abgleich des class-Attributs und toleriert zusätzliche Tokens.
//*[@class='alert']
Falsch — der exakte Abgleich scheitert, weil die volle Klasse 'alert alert-danger fade-in' ist.
//*[class='alert']
Falsch — Attribute brauchen in XPath das @-Präfix; class ohne @ meint einen Kindknoten namens class.
//*[starts-with(@id,'alert')]
Falsch — das prüft die id, nicht die Klasse, und nutzt Präfix- statt Teilstring-Abgleich.
Die Funktion contains() macht einen Teilstring-Abgleich, daher trifft contains(@class,'alert') unabhängig von den anderen Klassen-Tokens.
Was ist der Hauptzweck des Page-Object-Model-(POM-)Entwurfsmusters in der Selenium-Testautomatisierung?
Locators und Aktionen einer Seite in einer Klasse zu kapseln, was Lesbarkeit und Wartbarkeit verbessert
Richtig — dieses Kernziel reduziert Duplikate und isoliert UI-Änderungen in einer einzigen Klasse.
Tests parallel schneller laufen zu lassen
Falsch — POM dient der Wartbarkeit; parallele Geschwindigkeit kommt vom Runner/Grid, nicht vom Muster.
Die Notwendigkeit von Locators ganz zu ersetzen
Falsch — POM nutzt weiterhin Locators; es zentralisiert sie nur in Seitenklassen.
Testdaten automatisch zu erzeugen
Falsch — Testdatenerzeugung hat nichts mit POM zu tun, das Seiten modelliert.
POM kapselt die Locators und Interaktionen einer Seite in einer eigenen Klasse, sodass Testskripte lesbare Methoden aufrufen und Locator-Änderungen an einer Stelle erfolgen.
Wo sollten Test-Assertions gemäß gängiger Page-Object-Model-Empfehlung normalerweise stehen?
In den Testmethoden, nicht in den Page Objects
Richtig — Assertions in Tests halten Page Objects über verschiedene Prüfungen hinweg wiederverwendbar.
In jeder Page-Object-Methode
Falsch — überall eingebettete Assertions koppeln Seiten an konkrete Prüfungen und schaden der Wiederverwendung.
In der WebDriver-Konfiguration
Falsch — die Treiberkonfiguration betrifft das Setup, nicht die Prüfung erwarteter Ergebnisse.
Im HTML der zu testenden Seite
Falsch — Assertions sind Testcode; sie stehen nie im HTML der Anwendung.
Page Objects sollten Zustand/Verhalten bereitstellen und Daten oder andere Page Objects zurückgeben; Assertions gehören in die Testmethoden, damit Page Objects wiederverwendbar bleiben.
Eine LoginPage-Methode sendet das Formular ab und bringt den Nutzer aufs Dashboard:
public DashboardPage login(String u, String p) { ... }
Warum gilt die Rückgabe eines DashboardPage-Objekts (statt void) als gute Page-Object-Praxis?
Es modelliert den Seitenübergang und erlaubt typsicheres Verketten zur nächsten Seite
Richtig — die Rückgabe des Folge-Page-Objects drückt Navigation aus und ermöglicht flüssige, lesbare Ketten.
Es lässt den Login ohne Browser laufen
Falsch — der Rückgabetyp ändert nicht, ob ein Browser genutzt wird; WebDriver steuert weiterhin einen.
Es prüft automatisch, dass der Login erfolgreich war
Falsch — die Rückgabe eines Page Objects prüft nichts; Assertions bleiben im Test.
Es vermeidet die Instanziierung von WebDriver
Falsch — der Treiber wird weiterhin benötigt; der Rückgabetyp hat nichts mit der Treibererzeugung zu tun.
Die Rückgabe des nächsten Page Objects modelliert die Navigation und erlaubt flüssiges Verketten von Aufrufen, während der Seitenübergang explizit und typsicher bleibt.
Ein Locator für den Login-Button ändert sich in der UI der Anwendung. Wie viele Stellen müssen in einem gut strukturierten Page-Object-Model-Projekt typischerweise angepasst werden?
Eine — der im betreffenden Page Object definierte Locator
Richtig — zentrale Locators bedeuten, dass eine Änderung alle abhängigen Tests korrigiert.
Jeder Test, der den Button klickt
Falsch — genau das löst POM; ohne POM müsste man viele Tests ändern.
Keine — Locators aktualisieren sich selbst
Falsch — Locators sind statische Definitionen; sie aktualisieren sich nicht selbst.
Die WebDriver-Binärdatei muss neu installiert werden
Falsch — eine Locator-Änderung hat nichts mit der Treiber-Binärdatei zu tun.
Da jeder Locator einmal im Page Object definiert ist, wird eine UI-Änderung an einer einzigen Stelle behoben, egal wie viele Tests ihn nutzen.
Was gehört typischerweise IN eine Page-Object-Klasse? (Wähle zwei.)
Die Locators der Elemente dieser Seite
Richtig — Locators werden im Page Object gekapselt.
Methoden, die Benutzerinteraktionen auf dieser Seite ausführen
Richtig — Aktionsmethoden (z. B. login, search) gehören ins Page Object.
Die erwarteten Testdaten und Assertions
Falsch — diese gehören in den Test, nicht ins Page Object, damit es wiederverwendbar bleibt.
Die Test-Runner-Konfiguration (z. B. TestNG-Suite-XML)
Falsch — die Runner-Konfiguration ist Projekt-Setup, getrennt von Page Objects.
Ein Page Object enthält die Locators der Seite und Methoden, die Benutzerinteraktionen ausführen oder Informationen zurückgeben; Testdaten und Assertions stehen in den Tests.
Im Selenium-PageFactory-Ansatz (Java) wird ein Feld so deklariert:
@FindBy(id = "submit") private WebElement submitButton;
Was bewirkt die Annotation @FindBy zusammen mit PageFactory.initElements?
Es initialisiert das WebElement-Feld, sodass das Element beim ersten Zugriff verzögert lokalisiert wird
Richtig — PageFactory verdrahtet annotierte Felder und löst den Locator beim Zugriff auf.
Es cached das Element dauerhaft, sodass es nie veraltet
Falsch — gecachte PageFactory-Elemente können nach DOM-Änderungen weiterhin StaleElementReferenceException werfen.
Es fügt eine implizite Assertion hinzu, dass der Button existiert
Falsch — @FindBy lokalisiert; es prüft keine Existenz.
Es lädt den passenden Browser-Treiber automatisch herunter
Falsch — Treiberverwaltung hat nichts mit @FindBy zu tun.
PageFactory nutzt @FindBy, um das Element beim ersten Zugriff verzögert zu lokalisieren, und initialisiert die annotierten WebElement-Felder, sodass kein explizites findElement nötig ist.
Wie wirkt sich ein mit driver.manage().timeouts().implicitlyWait(...) konfigurierter impliziter Wait auf Elementsuchen aus?
Er gilt global und lässt jeden findElement bis zum Timeout pollen, bevor er fehlschlägt
Richtig — der implizite Wait wird einmal gesetzt und betrifft alle folgenden Elementsuchen.
Er wartet nur auf ein bestimmtes, jedes Mal benanntes Element
Falsch — das beschreibt einen expliziten Wait; der implizite Wait ist global.
Er pausiert den ganzen Test jedes Mal für die volle Dauer
Falsch — er wartet nur so lange wie nötig; erscheint das Element früher, kehrt der Aufruf sofort zurück.
Er betrifft nur die Navigation driver.get(), nicht findElement
Falsch — der implizite Wait betrifft die Elementsuche, nicht Navigations-Timeouts.
Ein impliziter Wait setzt ein globales Polling-Timeout: Jeder findElement-Aufruf pollt das DOM bis zu dieser Dauer, bevor er NoSuchElementException wirft.
Ein Test schlägt sporadisch fehl, weil ein Button im DOM ist, aber nach dem Laden kurz deaktiviert bleibt. Welche explizite Wartebedingung behebt das am besten?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.________)
elementToBeClickable(locator)
Richtig — es wartet, bis das Element sichtbar UND aktiviert ist.
presenceOfElementLocated(locator)
Falsch — presence prüft nur, dass das Element im DOM ist, nicht ob es aktiviert/klickbar ist.
titleContains("...")
Falsch — das prüft den Seitentitel, nicht den Aktivierungszustand des Buttons.
Thread.sleep(10000)
Falsch — das ist keine ExpectedCondition, und ein fester Sleep ist genau der fragile Ansatz, den man meidet.
elementToBeClickable wartet, bis das Element sichtbar und aktiviert ist — genau die Bedingung für einen vorhandenen, aber kurz deaktivierten Button.
Warum wird Thread.sleep() zur Synchronisation in Selenium-Tests im Allgemeinen abgeraten?
Es wartet immer die volle feste Zeit, was Tests langsam und dennoch instabil macht
Richtig — ein statischer Sleep passt sich nicht an reale Ladezeiten an, verschwendet Zeit oder schlägt fehl.
Es wird von Java nicht unterstützt
Falsch — Thread.sleep ist gültiges Java; das Problem ist die Eignung, nicht die Unterstützung.
Es schließt die Browser-Sitzung
Falsch — ein Sleep pausiert den Thread; es schließt den Browser nicht.
Es funktioniert nur im Headless-Modus
Falsch — Thread.sleep verhält sich im Headed- und Headless-Modus gleich.
Thread.sleep pausiert immer die feste Zeit, unabhängig von der Bereitschaft, was Tests langsamer macht und bei zu kurzer Wartezeit dennoch instabil bleibt.
Was ist der zentrale Verhaltensunterschied zwischen einem expliziten Wait (WebDriverWait + ExpectedConditions) und einem impliziten Wait?
Explizite Waits zielen auf eine bestimmte Bedingung; implizite sind ein globales Timeout für alle Suchen
Richtig — explizite Waits sind bedingungsbasiert und lokal; implizite gelten pauschal und global.
Explizite Waits sind global; implizite zielen auf eine Bedingung
Falsch — das vertauscht die beiden Wait-Typen.
Es gibt keinen Unterschied; die Begriffe sind Synonyme
Falsch — es sind unterschiedliche Mechanismen mit verschiedenem Geltungsbereich.
Explizite Waits funktionieren nur in Python; implizite nur in Java
Falsch — beide Wait-Typen gibt es in allen Selenium-Sprachbindings.
Ein expliziter Wait zielt auf eine bestimmte Bedingung für ein bestimmtes Element, während ein impliziter Wait ein einziges globales Timeout auf alle Elementsuchen anwendet.
Welche der folgenden sind empfohlene Synchronisationspraktiken für stabile Selenium-Tests? (Wähle zwei.)
Explizite Waits mit Bedingungen nutzen, die widerspiegeln, was der Test braucht (sichtbar, klickbar)
Richtig — bedingungsbasierte Waits kehren zurück, sobald die App bereit ist.
Einen FluentWait nutzen, um mit Timeout zu pollen und erwartete transiente Exceptions zu ignorieren
Richtig — FluentWait erlaubt Polling-Intervall und das Ignorieren von Exceptions wie NoSuchElement während des Wartens.
Implizite und explizite Waits in der Suite frei mischen
Falsch — das Mischen kann unvorhersehbare, additive Wartezeiten erzeugen und wird abgeraten.
Vor jeder Interaktion lange Thread.sleep-Aufrufe einfügen
Falsch — feste Sleeps machen Suiten langsam und garantieren keine Bereitschaft.
Gute Praxis bevorzugt explizite/fluent Waits auf sinnvolle Bedingungen und vermeidet das Mischen von impliziten und expliziten Waits sowie verstreute feste Sleeps.
Warum gilt das Mischen eines impliziten Waits und eines expliziten WebDriverWait in derselben Testsitzung als riskant?
Ihre Timeouts können sich unvorhersehbar kombinieren und zu längeren oder inkonsistenten Wartezeiten führen
Richtig — die offizielle Empfehlung warnt, dass beide interagieren und Wartezeiten aufblähen können.
Es verursacht einen Kompilierfehler
Falsch — der Code kompiliert; das Problem ist das Laufzeit-Timing, nicht die Kompilierung.
Explizite Waits werden deaktiviert, sobald ein impliziter Wait existiert
Falsch — beide bleiben aktiv; genau deshalb können sie sich stören.
Es beschädigt dauerhaft das Browser-Profil
Falsch — es gibt keine Profilbeschädigung; der einzige Effekt betrifft das Warte-Timing.
Sind beide gesetzt, können sich ihre Timeouts unvorhersehbar kombinieren (dokumentiert ist, dass sich Wartezeiten addieren können), was längere oder inkonsistente Wartezeiten erzeugt.
Welche Methode navigiert den Browser zur vorherigen Seite im Verlauf zurück?
driver.navigate().back()
Richtig — navigate().back() geht eine Seite im Verlauf zurück.
driver.get("back")
Falsch — get() lädt eine URL; 'back' ist keine URL.
driver.previous()
Falsch — eine Methode previous() gibt es bei WebDriver nicht.
driver.close()
Falsch — close() schließt das Fenster; es navigiert nicht zurück.
driver.navigate().back() geht einen Eintrag im Browserverlauf zurück, wie der Zurück-Button des Browsers.
Ein Klick auf einen Link öffnet einen zweiten Browser-Tab. Was müssen Sie tun, bevor WebDriver mit Elementen im neuen Tab interagieren kann?
Mit switchTo().window(handle) auf das neue Fenster-Handle wechseln
Richtig — WebDriver muss wissen, in welchem Fenster es agieren soll; der Fokuswechsel ist nötig.
Nichts — WebDriver fokussiert automatisch den neuesten Tab
Falsch — WebDriver wechselt nicht automatisch; der Fokus bleibt beim Ursprungsfenster.
driver.refresh() auf dem neuen Tab aufrufen
Falsch — ein Refresh verschiebt den Fokus nicht auf ein anderes Fenster.
Die WebDriver-Sitzung neu starten
Falsch — ein Neustart ist unnötig; man wechselt einfach das Fenster-Handle.
WebDriver bleibt auf dem ursprünglichen Fenster fokussiert, bis Sie wechseln. Mit getWindowHandles() das neue Handle finden und mit switchTo().window(handle) darauf fokussieren.
Ein Formular wird in einem iframe gerendert:
<iframe id="payment"><input id="card"></iframe>
driver.findElement(By.id("card")) wirft NoSuchElementException, obwohl das Feld sichtbar ist. Was ist die richtige Lösung?
driver.switchTo().frame("payment") vor dem Lokalisieren des Feldes aufrufen
Richtig — man muss in den iframe-Kontext wechseln, bevor dessen Elemente auffindbar sind.
Den impliziten Wait auf 60 Sekunden erhöhen
Falsch — längeres Warten hilft nicht; das Element ist in einem anderen Frame-Kontext.
driver.navigate().refresh() verwenden
Falsch — ein Refresh lädt die Seite neu, betritt aber nicht den iframe-Kontext.
By.id zu By.name ändern
Falsch — der Locator-Typ ist nicht das Problem; das Element ist in einem anderen Frame.
Elemente in einem iframe sind nicht im Hauptdokument-Kontext. Man muss zuerst switchTo().frame(...), interagieren und dann mit switchTo().defaultContent() zurückkehren.
Ein natives JavaScript-Alert erscheint. Wie bestätigen Sie es (OK) mit WebDriver?
driver.switchTo().alert().accept()
Richtig — zum Alert wechseln und accept() bestätigt es.
driver.findElement(By.id("ok")).click()
Falsch — native Alerts sind keine DOM-Elemente, findElement findet den OK-Button nicht.
driver.navigate().refresh()
Falsch — ein Refresh interagiert nicht mit dem Alert-Dialog.
driver.quit()
Falsch — quit beendet die Sitzung, statt das Alert zu bestätigen.
JavaScript-Alerts werden über das Alert-Interface behandelt: driver.switchTo().alert().accept() klickt OK; dismiss() klickt Abbrechen.
Wofür benötigt WebDriver einen switchTo()-Aufruf, bevor man interagieren kann? (Wähle zwei.)
Mit einem Element in einem iframe interagieren
Richtig — man muss switchTo().frame(...), um den iframe-Kontext zu betreten.
Ein JavaScript-Alert bestätigen oder abweisen
Richtig — Alerts werden über switchTo().alert() behandelt.
Einen Button auf der aktuellen Seite klicken
Falsch — Elemente im aktuellen Dokument werden direkt bedient, ohne Wechsel.
Den Text einer Überschrift auf der aktuellen Seite lesen
Falsch — getText() auf einem Element des aktuellen Dokuments braucht kein switchTo().
switchTo() ist nötig, um iframes zu betreten und JavaScript-Alerts zu behandeln (sowie für den Fensterfokus). Ein normaler Button-Klick oder das Lesen von Text im aktuellen Dokument nicht.
Welche Selenium-API ist für komplexe Benutzergesten wie das Überfahren eines Menüs oder Drag-and-drop gedacht?
Die Actions-Klasse
Richtig — Actions bietet erweiterte Maus-/Tastaturgesten, ausgeführt via perform().
Die Select-Klasse
Falsch — Select ist nur für <select>-Dropdowns, nicht für allgemeine Gesten.
Das Alert-Interface
Falsch — Alert behandelt JavaScript-Dialoge, keine Mausgesten.
Das TakesScreenshot-Interface
Falsch — TakesScreenshot erstellt Bilder; es führt keine Gesten aus.
Die Actions-Klasse baut Sequenzen niedriger Interaktionen (moveToElement, dragAndDrop, clickAndHold), die mit perform() ausgeführt werden.
Ein Test speichert eine WebElement-Referenz, dann aktualisiert die Seite einen Teil des DOM per AJAX. Die alte Referenz wirft nun StaleElementReferenceException. Wie geht man richtig damit um?
Das Element nach der DOM-Änderung neu lokalisieren, statt die alte Referenz wiederzuverwenden
Richtig — ein frisches findElement (oft in einem Wait) liefert eine gültige Referenz auf den neuen Knoten.
Die Exception fangen und ignorieren, damit der Test weiterläuft
Falsch — Ignorieren lässt die Aktion unausgeführt und verbirgt ein echtes Synchronisationsproblem.
Die Browserfenstergröße erhöhen
Falsch — die Fenstergröße hat nichts mit einer veralteten DOM-Referenz zu tun.
Von Chrome zu Firefox wechseln
Falsch — die Exception ist browserunabhängig; ein Browserwechsel behebt keine veraltete Referenz.
Die Referenz zeigt auf einen DOM-Knoten, der entfernt/ersetzt wurde. Die Lösung ist, das Element nach der DOM-Änderung erneut zu lokalisieren, idealerweise in einem expliziten Wait.
Was beschreibt in der Testautomatisierung einen 'flaky' (instabilen) Test am besten?
Ein Test, der ohne Codeänderungen mal besteht und mal fehlschlägt
Richtig — inkonsistente Ergebnisse bei identischen Läufen sind das Kennzeichen von Flakiness.
Ein Test, der immer fehlschlägt
Falsch — ein konsistent fehlschlagender Test ist zuverlässig defekt, nicht flaky.
Ein Test, der langsam läuft
Falsch — Langsamkeit ist ein Performance-Thema, nicht dasselbe wie inkonsistente Ergebnisse.
Ein Test ohne Assertions
Falsch — ein Test ohne Assertions ist schwach, aber das ist nicht die Bedeutung von 'flaky'.
Ein flaky Test liefert über Läufe hinweg unterschiedliche Ergebnisse (Pass/Fail) ohne Änderung an Code oder System, meist wegen Timing-, Reihenfolge- oder Umgebungsproblemen.
Warum sollten automatisierte UI-Tests im Allgemeinen voneinander unabhängig sein (keine gemeinsame Reihenfolge oder gemeinsamer Zustand)?
Damit sie in beliebiger Reihenfolge oder parallel laufen und ein Fehler nicht auf andere übergreift
Richtig — Unabhängigkeit ermöglicht Parallelität und isoliert Fehler auf ihre echte Ursache.
Damit Tests den Login-Zustand teilen, um schneller zu laufen
Falsch — geteilter Zustand schafft genau die Abhängigkeiten, die Suiten fragil und reihenfolgeabhängig machen.
Weil Selenium nicht mehr als einen Test ausführen kann
Falsch — Selenium führt viele Tests aus; Unabhängigkeit ist eine Designentscheidung, keine Werkzeuggrenze.
Um keine Assertions schreiben zu müssen
Falsch — Unabhängigkeit beseitigt nicht die Notwendigkeit von Assertions; Tests prüfen weiterhin Ergebnisse.
Unabhängige Tests können in beliebiger Reihenfolge oder parallel laufen, und ein Fehler in einem führt nicht zu Folgefehlern, was Ergebnisse zuverlässig und das Debugging einfacher macht.
Wo sollte ein Test, der Daten anlegt (z. B. einen neuen Nutzer), diese aufräumen, um die Suite wiederholbar zu halten?
In einem Teardown-Schritt nach dem Test, egal ob er bestanden oder fehlgeschlagen ist
Richtig — Teardown garantiert das Aufräumen, sodass spätere Läufe von einem bekannten Zustand starten.
Nirgends — übrig gebliebene Daten beeinflussen andere Tests nie
Falsch — übrig gebliebene Daten verursachen häufig Fehler wie Duplikat-Nutzer in späteren Läufen.
Nur manuell durch eine Person, nachdem die ganze Suite fertig ist
Falsch — manuelles Aufräumen ist unzuverlässig und untergräbt die Automatisierung; es gehört in den Teardown.
In den Locator-Definitionen des Page Objects
Falsch — Locators beschreiben Elemente; dort gehört das Daten-Aufräumen nicht hin.
Das Aufräumen gehört in einen Teardown-Schritt (z. B. @AfterMethod / Fixture-Teardown), damit jeder Test das System unabhängig von Pass oder Fail in einem bekannten Zustand hinterlässt.
Welche der folgenden Praktiken helfen, Flakiness in einer Selenium-Suite zu reduzieren? (Wähle zwei.)
Mit expliziten Waits auf sinnvolle Bedingungen synchronisieren
Richtig — auf die richtige Bedingung zu warten beseitigt die meiste timingbedingte Flakiness.
Stabile, eindeutige Locators verwenden (ids / Testattribute)
Richtig — robuste Locators vermeiden Brüche durch Layout- oder Klassenänderungen.
Tests von Daten abhängig machen, die vorherige Tests hinterlassen
Falsch — geteilte Restdaten erzeugen Reihenfolgeabhängigkeit und sporadische Fehler.
Feste Thread.sleep-Verzögerungen einbauen, 'um sicherzugehen'
Falsch — feste Sleeps verlangsamen die Suite und scheitern, wenn die App langsamer als geschätzt ist.
Explizite Waits auf echte Bedingungen und stabile, eindeutige Locators reduzieren Flakiness direkt; eine zufällige gemeinsame Reihenfolge oder feste Sleeps bewirken das Gegenteil.
Ein Klick schlägt mit ElementClickInterceptedException fehl, weil ein klebriges Cookie-Banner den Ziel-Button überlappt. Was ist die robusteste Lösung?
Das überlappende Banner schließen oder darüber hinausscrollen, dann warten, bis der Button klickbar ist
Richtig — das verdeckende Element zu behandeln adressiert die echte Ursache und hält den Klick realistisch.
Den Klick in eine Schleife packen, die tausendfach wiederholt
Falsch — blinde Wiederholungen verschwenden Zeit und entfernen das verdeckende Overlay nicht.
Die Assertion löschen, die das Ergebnis prüft
Falsch — das Entfernen der Assertion verbirgt den Fehler, statt den Klick gelingen zu lassen.
Den impliziten Wait auf null senken
Falsch — das Problem ist ein überlappendes Element, nicht die Wartezeit; ein kleinerer Wait hilft nicht.
Das Element wird von einem anderen verdeckt. Die robuste Lösung ist, das Overlay zu entfernen/behandeln (z. B. Banner schließen) oder zu scrollen/warten, bis das Ziel wirklich klickbar ist, statt den Klick blind zu erzwingen.