TestNG Zuhörer rein Selenium
Krishna Runta
⚡ Intelligente Zusammenfassung
Zuhörer rein Selenium WebDriver sind TestNG Schnittstellen, die Testereignisse abfangen, um Protokolle, Berichte und Aktionen nach einem Fehler anzupassen. Dieser Artikel erläutert die Methoden von ITestListener und führt durch ein ausführbares Beispiel. Java Beispiel und verdeutlicht, wie Selenium 4 ersetzte den veralteten WebDriverEventListener.
Selenium WebDriver-Skripte müssen häufig auf Testereignisse wie eine erfolgreiche Assertion, einen fehlgeschlagenen Locator oder einen übersprungenen Schritt reagieren. Listener ermöglichen dies. Im Allgemeinen gilt: Selenium Die Projekte basieren auf zwei Zuhörergruppen:
- WebDriver-Listener
- TestNG Zuhörer
In diesem Tutorial konzentrieren wir uns auf TestNG Listener, mit einem Hinweis darauf, wie sich die Listener auf WebDriver-Ebene geändert haben in Selenium 4.x.
Was ist ein Zuhörer in TestNG?
Ein Listener ist eine Schnittstelle, die das Standardverhalten von TestNGWie der Name schon sagt, „hören“ Listener Ereignisse ab, die in einem definierten Selenium Skripten Sie und reagieren Sie entsprechend. Sie verwenden Listener, indem Sie die entsprechende Listener-Schnittstelle implementieren und diese in Ihrer Testklasse oder -suite registrieren. Listener ermöglichen Ihnen die Anpassung Ihres Skripts. TestNG Berichte erstellen, Screenshots anhängen und strukturierte Protokolle ausgeben.
Arten von Zuhörern in TestNG
TestNG Es wird eine Reihe von Listener-Schnittstellen angeboten, von denen jede auf eine andere Phase des Testlebenszyklus abzielt.
Nachfolgend sind die gebräuchlichsten aufgeführt. TestNG Zuhörer:
- IAnnotationTransformer
- IAnnotationTransformer2
- IKonfigurierbar
- IConfigurationListener
- IExecutionListener
- IchHookable
- InvokedMethodListener
- IInvokedMethodListener2
- IMethodInterceptor
- Reporter
- ISuiteListener
- ITestListener
Diese Schnittstellen werden verwendet in Selenium um Protokolle zu generieren oder anzupassen TestNG Berichte. In diesem Tutorial werden wir implementieren ITestListener.
ITestListener stellt die folgenden Methoden bereit:
- onStart – Wird aufgerufen, sobald ein Test beginnt.
- onTestSuccess – wird aufgerufen, wenn ein Test bestanden wurde.
- onTestFailure – Wird aufgerufen, wenn ein Test fehlschlägt.
- onTestSkipped – Wird aufgerufen, wenn ein Test übersprungen wird.
- onTestFailedButWithinSuccessPercentage – Wird aufgerufen, wenn ein Test fehlschlägt, aber innerhalb der Erfolgsquote liegt.
- onFinish – wird aufgerufen, nachdem alle Tests in der Klasse ausgeführt wurden.
Testszenario
In diesem Testszenario werden wir den Anmeldeprozess automatisieren und implementieren ITestListener dagegen.
- Start Firefox und öffnen Sie die Seite https://demo.guru99.com/V4/
- Melden Sie sich bei der Anwendung an.
Schritte zum Erstellen eines TestNG Hörer
Für das oben beschriebene Testszenario werden wir den Listener schrittweise implementieren.
Schritt 1) Erstelle eine Klasse namens ListenerTest das implementiert ITestListenerBewegen Sie den Mauszeiger über die rote Unterstreichung und Eclipse wird zwei schnelle Lösungen vorschlagen, wie unten dargestellt:
Klicken Sie auf „Nicht implementierte Methoden hinzufügen“. Ihrem Code werden mehrere Stub-Methoden (ohne Rumpf) hinzugefügt, ähnlich wie folgt:
importieren org.testng.ITestContext;
importieren org.testng.ITestListener;
importieren org.testng.ITestResult;
Öffentliche Klasse ListenerTest implementiert ITestListener {
@Überschreiben
öffentliche Leere onFinish(ITestContext arg0) {
// TODO Automatisch generierter Methoden-Stub
}
@Überschreiben
öffentliche Leere onStart(ITestContext arg0) {
// TODO Automatisch generierter Methoden-Stub
}
@Überschreiben
öffentliche Leere onTestFailedButWithinSuccessPercentage(ITestResult arg0) {
// TODO Automatisch generierter Methoden-Stub
}
@Überschreiben
öffentliche Leere onTestFailure(ITestResult arg0) {
// TODO Automatisch generierter Methoden-Stub
}
@Überschreiben
öffentliche Leere onTestSkipped(ITestResult arg0) {
// TODO Automatisch generierter Methoden-Stub
}
@Überschreiben
öffentliche Leere onTestStart(ITestResult arg0) {
// TODO Automatisch generierter Methoden-Stub
}
@Überschreiben
öffentliche Leere onTestSuccess(ITestResult arg0) {
// TODO Automatisch generierter Methoden-Stub
}
}
Nun modifizieren wir die ListenerTest Klasse. Insbesondere werden wir die folgenden Methoden implementieren: onTestFailure, onTestÜbersprungen, onTestStart und onTestSuccess.
Die Änderung ist einfach: Jede Methode gibt den Namen des Tests aus, sodass die Konsole den Status „bestanden“, „fehlgeschlagen“ und „übersprungen“ deutlich anzeigt.
Nach der Änderung sieht der Code folgendermaßen aus:
importieren org.testng.ITestContext;
importieren org.testng.ITestListener;
importieren org.testng.ITestResult;
Öffentliche Klasse ListenerTest implementiert ITestListener {
@Überschreiben
öffentliche Leere onFinish(ITestContext Ergebnis) {
}
@Überschreiben
öffentliche Leere onStart(ITestContext Ergebnis) {
}
@Überschreiben
öffentliche Leere onTestFailedButWithinSuccessPercentage(ITestResult Ergebnis) {
}
// Wenn ein Testfall fehlschlägt, wird diese Methode aufgerufen.
@Überschreiben
öffentliche Leere onTestFailure(ITestResult Ergebnis) {
System.out.println(„Der Name des fehlgeschlagenen Testfalls lautet:“ + Result.getName());
}
// Wenn ein Testfall übersprungen wird, wird diese Methode aufgerufen.
@Überschreiben
öffentliche Leere onTestSkipped(ITestResult Ergebnis) {
System.out.println(„Der Name des übersprungenen Testfalls lautet:“ + Result.getName());
}
// Diese Methode wird beim Start eines Testfalls aufgerufen.
@Überschreiben
öffentliche Leere onTestStart(ITestResult Ergebnis) {
System.out.println(Result.getName() + „Testfall gestartet“);
}
// Wenn ein Testfall erfolgreich ist, wird diese Methode aufgerufen.
@Überschreiben
öffentliche Leere onTestSuccess(ITestResult Ergebnis) {
System.out.println(„Der Name des bestandenen Testfalls lautet:“ + Result.getName());
}
}
Schritt 2) Erstelle eine weitere Klasse namens Testfälle für die Anmeldeautomatisierung. Selenium Diese Klasse wird ausgeführt, um sich auf der Demoseite anzumelden.
importieren org.openqa.selenium.By;
importieren org.openqa.selenium.WebDriver;
importieren org.openqa.selenium.firefox.FirefoxTreiber;
importieren org.testng.Assert;
importieren org.testng.annotations.Listeners;
importieren org.testng.Anmerkungen.Test;
Öffentliche Klasse Testfälle {
WebTreiber Fahrer = neu FirefoxLED Treiber();
// Test, der so konzipiert ist, dass er erfolgreich ist, um den Erfolgs-Listener zu überprüfen.
@Prüfung
öffentliche Leere Login() {
Treiber.get(„https://demo.guru99.com/V4/“);
driver.findElement(By.name(„uid“)).sendKeys(„mngr34926“);
driver.findElement(By.name("Passwort")).sendKeys(“amUpenu”);
driver.findElement(By.name(„btnLogin“)).klicken();
}
// Test wurde zwangsweise fehlgeschlagen, um den Fehler-Listener zu überprüfen.
@Prüfung
öffentliche Leere TestToFail() {
System.out.println(„Diese Methode zum Testen schlägt fehl.“);
Assert.assertTrue(falsch);
}
}
Schritt 3) Als Nächstes fügen wir diesen Listener unserer Testklasse hinzu. TestfälleEs gibt zwei Möglichkeiten, eine Klasse mit einer Listener-Schnittstelle zu verbinden.
Die erste Möglichkeit besteht in der Verwendung von @Zuhörer Anmerkung, wie unten dargestellt:
Wir fügen diese Anmerkung oberhalb der Testfälle Klasse. Die Klasse sieht dann folgendermaßen aus:
importieren org.openqa.selenium.By;
importieren org.openqa.selenium.WebDriver;
importieren org.openqa.selenium.firefox.FirefoxTreiber;
importieren org.testng.Assert;
importieren org.testng.annotations.Listeners;
importieren org.testng.Anmerkungen.Test;
@Listeners(Listener_Demo.ListenerTest.class)
Öffentliche Klasse Testfälle {
WebTreiber Fahrer = neu FirefoxLED Treiber();
// Test, der erfolgreich sein muss, um den Erfolgs-Listener zu überprüfen.
@Prüfung
öffentliche Leere Login() {
Treiber.get(„https://demo.guru99.com/V4/“);
driver.findElement(By.name(„uid“)).sendKeys(„mngr34926“);
driver.findElement(By.name("Passwort")).sendKeys(“amUpenu”);
driver.findElement(By.name(„btnLogin“)).klicken();
}
// Test wurde zwangsweise fehlgeschlagen, um den Fehler-Listener zu überprüfen.
@Prüfung
öffentliche Leere TestToFail() {
System.out.println(„Diese Methode zum Testen schlägt fehl.“);
Assert.assertTrue(falsch);
}
}
Die Projektstruktur sieht folgendermaßen aus:
Schritt 4) Führen Sie die aus Testfälle Klasse. Methoden innerhalb ListenerTest werden automatisch aufgerufen, basierend auf dem Verhalten von Methoden, die mit annotiert sind @Prüfung.
Schritt 5) Überprüfen Sie die in der Konsole angezeigte Ausgabe.
Die Ausgabe von Testfälle sieht aus wie:
C:\Users\gauravn\AppData\Local\Temp\testng-eclipse–1058076918\testng-customsuite.xml
Login-Testfall gestartet
Der Name des bestandenen Testfalls lautet: Login
TestToFail-Testfall gestartet
Diese Methode zum Testen schlägt fehl
Der Name des fehlgeschlagenen Testfalls lautet: TestToFail
ERFOLGREICH: Anmeldung
FEHLGESCHLAGEN: TestToFail
java.lang.AssertionError: erwartet wurde [true], aber gefunden wurde [false].
Verwendung eines Listeners für mehrere Klassen
Wenn ein Projekt viele Testklassen hat, wird das Hinzufügen der @Zuhörer Die Kommentierung jedes einzelnen Eintrags wird dadurch umständlich und fehleranfällig.
Erstellen Sie in diesem Fall ein testng.xml Datei und registrieren Sie den Listener dort einmalig.
Dieser Listener wird dann für die gesamte Testsuite angewendet, unabhängig von der Anzahl der Klassen. Beim Ausführen der XML-Datei wird der Listener für jede in der Suite deklarierte Klasse ausgelöst, und Sie können beliebig viele Listener-Klassen innerhalb desselben Tags verketten.
WebDriverListener in Selenium 4 im Vergleich zum veralteten EventFiringWebDriver
Während TestNG Listener reagieren auf Ereignisse im Testlebenszyklus, WebDriver-Listener reagieren auf Browser-Treiber-Aktionen wie Klicks, Navigationen oder den Aufruf von findElement. Selenium 3. Der typische Ansatz war der WebDriverEventListener Schnittstelle verdrahtet durch EventFiringWebDriverBeide sind veraltet in Selenium 4.x.
Der moderne Ersatz ist der WebDriverListener Schnittstelle kombiniert mit EventFiringDecorator:
importieren org.openqa.selenium.chrome.ChromeDriver;
importieren org.openqa.selenium.support.events.EventFiringDecorator;
importieren org.openqa.selenium.support.events.WebDriverListener;
Öffentliche Klasse LoggingListener implementiert WebDriverListener {
@Überschreiben
öffentliche Leere beforeGet(WebTreiber driver, String url) {
System.out.println(„Navigieren zu“ + URL);
}
}
WebTreiber Rohdaten = neu Chrome-Treiber();
WebTreiber Fahrer = neu EventFiringDecorator<>(neu LoggingListener()).decorate(raw);
Der Dekorator kann beliebige WebDriver-, WebElement- oder Alert-Elemente umschließen und ist damit flexibler als der alte, ereignisauslösende Wrapper. WebDriverListener für die Beobachtbarkeit auf Browserseite und TestNG ITestListener für Berichte auf Suite-Ebene.
KI-gestützte Zuhörer: Intelligentere Protokolle und Fehleranalyse
Modernes Selenium Teams integrieren zunehmend KI-Dienste in ihre Listener, um CI-Signale besser umsetzbar zu machen. onTestFailureEin KI-gestützter Listener kann einen DOM-Snapshot und einen Screenshot erfassen, diese an ein Modell senden, das einen wahrscheinlichen Ursachencluster zurückgibt, und ein Tag zurückschreiben. TestNG einen Bericht oder ein Tool wie ReportPortal.
Gängige KI-gesteuerte Muster sind:
- Flaky-Test-Erkennung: Die Zuhörer leiten erfolgreiche/nicht erfolgreiche Zeitachsen an ein Modell weiter, das einen Fehler als unzuverlässig, umweltbedingt oder als echte Regression klassifiziert.
- Intelligente Screenshots: Computer-Vision-Modelle schneiden, annotieren und vergleichen UI-Screenshots, sodass Prüfer nur den geänderten Bereich sehen und nicht die gesamte Seite.
- Selbstheilende Ortungsgeräte: A WebDriverListener Haken vor dem Finden von Elementen und bittet einen KI-Helfer, einen alternativen Ortungspunkt vorzuschlagen, wenn der primäre Ortungspunkt ausfällt. NoSuchElementException.
- Zusammenfassungen in natürlicher Sprache: An Reporter Die Implementierung speist die Ergebnisse der Testsuite in ein LLM ein, das eine einzeilige Stand-up-Zusammenfassung erzeugt.
Die Listener-Schicht ist der sauberste Ort, um diese Hooks einzufügen, da sie außerhalb der Testlogik bleibt und einheitlich auf die gesamte Testsuite angewendet wird.
Zusammenfassung
Listener sind erforderlich, um Protokolle zu generieren oder anzupassen TestNG Berichte in Selenium WebDriver.
- TestNG bietet viele Zuhörerschnittstellen; wählen Sie diejenige aus, die zu dem Ereignis passt, das Sie interessiert.
- Listener sind Schnittstellen, die verwendet werden in Selenium WebDriver-Skripte zur Reaktion auf Ereignisse im Testlebenszyklus.
- Das Tutorial demonstrierte ITestListener mit einem bestandenen und einem nicht bestandenen Test.
- Sie können einen Listener anhängen mit @Zuhörer oder registrieren Sie es einmal in testng.xml für die gesamte Suite.
- Selenium 4.x ersetzt EventFiringWebDriver und WebDriverListener + EventFiringDecorator für WebDriver-Ereignisse.
