TestNG ผู้ฟังใน Selenium

โดย: Krishna รุ่งทา Krishna รุ่งทา
Hours วันที่อัพเดท

⚡ สรุปอย่างชาญฉลาด

ผู้ฟังใน Selenium WebDriver คือ TestNG อินเทอร์เฟซที่ดักจับเหตุการณ์การทดสอบเพื่อปรับแต่งบันทึก รายงาน และการดำเนินการหลังความล้มเหลว บทความนี้อธิบายวิธีการของ ITestListener และแสดงตัวอย่างการทำงานที่สามารถรันได้ Java ตัวอย่างเช่น และอธิบายให้ชัดเจนว่าอย่างไร Selenium 4 แทนที่ WebDriverEventListener ที่เลิกใช้งานแล้ว

  • ❓ สิ่งที่ผู้ฟังทำ: พวกเขาสมัครสมาชิก TestNG เหตุการณ์ต่างๆ เช่น เริ่ม ผ่าน ล้มเหลว และข้าม จะกระตุ้นการบันทึกหรือการรายงานข้อมูล
  • 🧩 อินเทอร์เฟซสิบสองรายการ: TestNG มีอินเทอร์เฟซต่างๆ เช่น ITestListener, ISuiteListener, IReporter, IInvokedMethodListener และ IAnnotationTransformer สำหรับการควบคุมอย่างละเอียด
  • 🛠️ โหมดการเดินสายไฟสองแบบ: เพิ่ม Listener โดยใช้ Annotation @Listeners กับคลาสเดียว หรือลงทะเบียน Listener เพียงครั้งเดียวในไฟล์ testng.xml สำหรับแต่ละ Suite
  • 🚀 Selenium อัพเดต 4: EventFiringWebDriver นั้นเลิกใช้งานแล้ว ปัจจุบันอินเทอร์เฟซ WebDriverListener ที่ทันสมัยกว่า พร้อมด้วย EventFiringDecorator เป็นตัวขับเคลื่อนการทำงานของ event hook ในระดับ WebDriver แทน
  • 🤖 มุมมองของ AI: ระบบรับฟังที่ใช้ AI ช่วยสามารถจำแนกประเภทความล้มเหลวโดยอัตโนมัติ แนบภาพหน้าจออัจฉริยะ และส่งสัญญาณการทดสอบที่ไม่เสถียรกลับไปยังแดชบอร์ด CI ได้แบบเรียลไทม์
อ่านเพิ่มเติม

TestNG ผู้ฟังใน Selenium

Selenium สคริปต์ WebDriver มักจะต้องตอบสนองต่อเหตุการณ์การทดสอบ เช่น การยืนยันผ่าน การระบุตำแหน่งล้มเหลว หรือขั้นตอนที่ถูกข้ามไป Listener ช่วยให้สิ่งนี้เป็นไปได้ โดยทั่วไปแล้ว Selenium โครงการต่างๆ อาศัยกลุ่มผู้ฟังสองกลุ่มหลัก:

  1. ผู้ฟัง WebDriver
  2. TestNG ฟัง

ในบทเรียนนี้ เราจะเน้นไปที่... TestNG ผู้ฟัง พร้อมหมายเหตุเกี่ยวกับการเปลี่ยนแปลงของผู้ฟังระดับ WebDriver ใน Selenium 4.x

ผู้ฟังคืออะไรใน TestNG?

Listener คืออินเทอร์เฟซที่ปรับเปลี่ยนพฤติกรรมเริ่มต้นของ TestNGตามชื่อที่บ่งบอก ผู้ฟังจะ "ฟัง" เหตุการณ์ต่างๆ ที่ถูกกำหนดไว้ใน Selenium เขียนสคริปต์และตอบสนองตามนั้น คุณใช้งานโดยการใช้งานอินเทอร์เฟซ Listener ที่เกี่ยวข้องและลงทะเบียนในคลาสทดสอบหรือชุดทดสอบของคุณ Listener ช่วยให้คุณปรับแต่งได้ TestNG รายงานแนบภาพหน้าจอ และส่งบันทึกข้อมูลที่มีโครงสร้าง

ประเภทของผู้ฟังใน TestNG

TestNG บริษัทนี้จัดส่งชุดอินเทอร์เฟซสำหรับผู้ฟัง (listener interface) หลายแบบ โดยแต่ละแบบมีเป้าหมายที่แตกต่างกันในแต่ละขั้นตอนของวงจรชีวิตการทดสอบ

ด้านล่างนี้คือสิ่งที่ใช้กันทั่วไป TestNG ผู้ฟัง:

  1. Iคำอธิบายประกอบ Transformer
  2. Iคำอธิบายประกอบ Transformer2
  3. กำหนดค่าได้
  4. IConfigurationListener
  5. IExecutionListener
  6. ฉันติดได้
  7. ฉันเรียกใช้MethodListener
  8. ฉันเรียกใช้MethodListener2
  9. IMethodInterceptor
  10. ไอรีพอร์ตเตอร์
  11. ISuiteListener
  12. ITestListener

อินเทอร์เฟซเหล่านี้ใช้ใน Selenium เพื่อสร้างบันทึกหรือปรับแต่ง TestNG ในบทเรียนนี้ เราจะนำรายงานมาใช้งาน ITestListener.

ITestListener เปิดเผยวิธีการต่อไปนี้:

  • onStart – ฟังก์ชันนี้จะถูกเรียกใช้เมื่อเริ่มการทดสอบใดๆ
  • onTestSuccess – เรียกใช้เมื่อการทดสอบผ่าน
  • เมื่อการทดสอบล้มเหลว – เรียกใช้เมื่อการทดสอบล้มเหลว
  • onTestSkipped – ฟังก์ชันนี้จะถูกเรียกเมื่อมีการข้ามการทดสอบ
  • onTestFailedButWithinSuccessPercentage – เรียกใช้เมื่อการทดสอบล้มเหลว แต่ยังอยู่ในช่วงเปอร์เซ็นต์ความสำเร็จที่กำหนดไว้
  • onFinish – ฟังก์ชันนี้จะถูกเรียกหลังจากที่การทดสอบทั้งหมดในคลาสเสร็จสิ้นแล้ว
อย่าพลาด:

สถานการณ์ทดสอบ

ในสถานการณ์ทดสอบนี้ เราจะทำการทำให้กระบวนการล็อกอินเป็นแบบอัตโนมัติและนำไปใช้งาน ITestListener กับมัน

  1. ยิง Firefox และเปิดเว็บไซต์ https://demo.guru99.com/V4/

การเข้าสู่ระบบสถานการณ์ทดสอบ URL

  1. เข้าสู่ระบบแอปพลิเคชัน

แบบฟอร์มเข้าสู่ระบบสถานการณ์ทดสอบ

ขั้นตอนในการสร้าง TestNG ผู้ฟัง

สำหรับสถานการณ์ทดสอบข้างต้น เราจะทำการใช้งาน Listener ทีละขั้นตอน

ขั้นตอน 1) สร้างคลาสชื่อ... การทดสอบผู้ฟัง ที่ดำเนินการ ITestListenerเลื่อนเมาส์ไปที่เส้นใต้สีแดงแล้ว... Eclipse จะแนะนำวิธีแก้ไขปัญหาอย่างรวดเร็วสองวิธี ดังแสดงด้านล่าง:

Eclipse การแก้ไขด่วนเพื่อเพิ่มเมธอดที่ยังไม่ได้ใช้งาน

คลิก “เพิ่มเมธอดที่ยังไม่ได้ใช้งาน” ระบบจะเพิ่มเมธอดจำลองหลายรายการ (ที่ไม่มีเนื้อหา) ลงในโค้ดของคุณ ในลักษณะนี้:

แพ็คเกจ Listener_Demo;

นำเข้า org.testng.ITestContext;
นำเข้า org.testng.ITestListener;
นำเข้า org.testng.ITestResult;

ชั้นสาธารณะ การทดสอบผู้ฟัง การดำเนินการ ITestListener {

@แทนที่
โมฆะสาธารณะ เมื่อเสร็จสิ้น(ITestContext arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}

@แทนที่
โมฆะสาธารณะ เมื่อเริ่มต้น(ITestContext arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}

@แทนที่
โมฆะสาธารณะ onTestFailedButWithinSuccessPercentage(ผลการทดสอบไอที arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}

@แทนที่
โมฆะสาธารณะ เมื่อการทดสอบล้มเหลว(ผลการทดสอบไอที arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}

@แทนที่
โมฆะสาธารณะ onTestSkipped(ผลการทดสอบไอที arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}

@แทนที่
โมฆะสาธารณะ onTestStart(ผลการทดสอบไอที arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}

@แทนที่
โมฆะสาธารณะ onTestSuccess(ผลการทดสอบไอที arg0) {
// TODO สร้างโครงร่างเมธอดโดยอัตโนมัติ
}
}

ตอนนี้เรามาแก้ไขกันเถอะ การทดสอบผู้ฟัง ในคลาสนี้ เราจะเติมข้อมูลลงในเมธอดต่อไปนี้โดยเฉพาะ: เมื่อการทดสอบล้มเหลว, การทดสอบข้ามไป, onTestStartและ onTestSuccess.

การเปลี่ยนแปลงนั้นง่ายมาก: แต่ละวิธีจะพิมพ์ชื่อของการทดสอบออกมา เพื่อให้คอนโซลแสดงสถานะผ่าน ไม่ผ่าน และข้ามได้อย่างชัดเจน

หลังจากแก้ไขแล้ว โค้ดจะมีลักษณะดังนี้:

แพ็คเกจ Listener_Demo;

นำเข้า org.testng.ITestContext;
นำเข้า org.testng.ITestListener;
นำเข้า org.testng.ITestResult;

ชั้นสาธารณะ การทดสอบผู้ฟัง การดำเนินการ ITestListener {

@แทนที่
โมฆะสาธารณะ เมื่อเสร็จสิ้น(ITestContext ผลลัพธ์) {
}

@แทนที่
โมฆะสาธารณะ เมื่อเริ่มต้น(ITestContext ผลลัพธ์) {
}

@แทนที่
โมฆะสาธารณะ onTestFailedButWithinSuccessPercentage(ผลการทดสอบไอที ผลลัพธ์) {
}

// เมื่อการทดสอบล้มเหลว เมธอดนี้จะถูกเรียกใช้
@แทนที่
โมฆะสาธารณะ เมื่อการทดสอบล้มเหลว(ผลการทดสอบไอที ผลลัพธ์) {
System.out.println(“ชื่อของกรณีทดสอบที่ล้มเหลวคือ : “ + Result.getName());
}

// เมื่อมีการข้ามกรณีทดสอบ เมธอดนี้จะถูกเรียกใช้
@แทนที่
โมฆะสาธารณะ onTestSkipped(ผลการทดสอบไอที ผลลัพธ์) {
System.out.println(“ชื่อของกรณีทดสอบที่ถูกข้ามคือ : “ + Result.getName());
}

// เมธอดนี้จะถูกเรียกใช้เมื่อเริ่มการทดสอบ
@แทนที่
โมฆะสาธารณะ onTestStart(ผลการทดสอบไอที ผลลัพธ์) {
System.out.println(Result.getName() + “เริ่มการทดสอบแล้ว”);
}

// เมื่อการทดสอบผ่าน เมธอดนี้จะถูกเรียกใช้
@แทนที่
โมฆะสาธารณะ onTestSuccess(ผลการทดสอบไอที ผลลัพธ์) {
System.out.println(“ชื่อของกรณีทดสอบที่ผ่านคือ : “ + Result.getName());
}
}

ขั้นตอน 2) สร้างคลาสอีกคลาสหนึ่งชื่อว่า กรณีทดสอบ สำหรับระบบล็อกอินอัตโนมัติ Selenium จะเรียกใช้คลาสนี้เพื่อล็อกอินเข้าสู่เว็บไซต์สาธิต

แพ็คเกจ Listener_Demo;

นำเข้า org.openqa.selenium.By;
นำเข้า org.openqa.selenium.WebDriver;
นำเข้า org.openqa.selenium.firefox.Firefoxคนขับรถ;
นำเข้า org.testng.Assert;
นำเข้า org.testng.annotations.Listeners;
นำเข้า org.testng.annotations.Test;

ชั้นสาธารณะ กรณีทดสอบ {
ไดรเวอร์เว็บ คนขับ = ใหม่ Firefoxคนขับรถ();

// การทดสอบนี้ออกแบบมาเพื่อให้ผ่าน เพื่อตรวจสอบความสำเร็จของตัวรับฟังเหตุการณ์
@ทดสอบ
โมฆะสาธารณะ เข้าสู่ระบบ() {
ไดรเวอร์.รับ(“https://demo.guru99.com/V4/”);
ไดรเวอร์.ค้นหาองค์ประกอบ(โดย.ชื่อ(“uid”)).ส่งคีย์(“mngr34926”);
ไดรเวอร์.ค้นหาองค์ประกอบ(โดย.ชื่อ("รหัสผ่าน")).ส่งคีย์(“amUpenu”);
ไดรเวอร์.ค้นหาองค์ประกอบ(โดย.ชื่อ(“btnLogin”)).คลิก();
}

// บังคับให้การทดสอบล้มเหลว เพื่อตรวจสอบตัวรับฟังความล้มเหลว
@ทดสอบ
โมฆะสาธารณะ TestToFail() {
System.out.println(“วิธีการทดสอบนี้ล้มเหลว”);
ยืนยัน.ยืนยันจริง(เท็จ);
}
}

ขั้นตอน 3) ถัดไป ให้แนบ Listener นี้เข้ากับคลาสทดสอบของเรา กรณีทดสอบมีสองวิธีในการเชื่อมต่อคลาสกับอินเทอร์เฟซผู้ฟัง

วิธีแรกคือการใช้ @ผู้ฟัง คำอธิบายประกอบ ดังแสดงด้านล่าง:

@Listeners(Listener_Demo.ListenerTest.class)

เราเพิ่มคำอธิบายประกอบนี้ไว้ด้านบน กรณีทดสอบ คลาส โครงสร้างของคลาสจะเป็นดังนี้:

แพ็คเกจ Listener_Demo;

นำเข้า org.openqa.selenium.By;
นำเข้า org.openqa.selenium.WebDriver;
นำเข้า org.openqa.selenium.firefox.Firefoxคนขับรถ;
นำเข้า org.testng.Assert;
นำเข้า org.testng.annotations.Listeners;
นำเข้า org.testng.annotations.Test;

@Listeners(Listener_Demo.ListenerTest.class)
ชั้นสาธารณะ กรณีทดสอบ {
ไดรเวอร์เว็บ คนขับ = ใหม่ Firefoxคนขับรถ();

// ทดสอบให้ผ่าน เพื่อยืนยันตัวรับฟังความสำเร็จ
@ทดสอบ
โมฆะสาธารณะ เข้าสู่ระบบ() {
ไดรเวอร์.รับ(“https://demo.guru99.com/V4/”);
ไดรเวอร์.ค้นหาองค์ประกอบ(โดย.ชื่อ(“uid”)).ส่งคีย์(“mngr34926”);
ไดรเวอร์.ค้นหาองค์ประกอบ(โดย.ชื่อ("รหัสผ่าน")).ส่งคีย์(“amUpenu”);
ไดรเวอร์.ค้นหาองค์ประกอบ(โดย.ชื่อ(“btnLogin”)).คลิก();
}

// บังคับให้การทดสอบล้มเหลว เพื่อตรวจสอบตัวรับฟังความล้มเหลว
@ทดสอบ
โมฆะสาธารณะ TestToFail() {
System.out.println(“วิธีการทดสอบนี้ล้มเหลว”);
ยืนยัน.ยืนยันจริง(เท็จ);
}
}

โครงสร้างโครงการมีลักษณะดังนี้:

TestNG โครงสร้างโครงการผู้ฟัง

ขั้นตอน 4) ดำเนินการ กรณีทดสอบ เมธอดภายในคลาส การทดสอบผู้ฟัง จะถูกเรียกใช้งานโดยอัตโนมัติตามพฤติกรรมของเมธอดที่ติดคำอธิบายประกอบด้วย @ทดสอบ.

ขั้นตอน 5) ตรวจสอบผลลัพธ์ที่แสดงในคอนโซล

ผลลัพธ์ของ กรณีทดสอบ ดูเหมือนกับ:

TestNG เอาต์พุตคอนโซลผู้ฟัง

[TestNG] วิ่ง:
C:\Users\gauravn\AppData\Local\Temp\testng-eclipse–1058076918\testng-customsuite.xml

เริ่มการทดสอบการเข้าสู่ระบบแล้ว
ชื่อของกรณีทดสอบที่ผ่านคือ: เข้าสู่ระบบ
เริ่มการทดสอบ TestToFail แล้ว
วิธีการทดสอบนี้ล้มเหลว
ชื่อของกรณีทดสอบที่ล้มเหลวคือ: TestToFail
ผ่านแล้ว: เข้าสู่ระบบ
ล้มเหลว: TestToFail
java.lang.AssertionError: คาดหวัง [true] แต่พบ [false]

การใช้ Listener สำหรับหลายคลาส

หากโปรเจ็กต์มีคลาสทดสอบจำนวนมาก การเพิ่มคลาสทดสอบเข้าไปจะทำให้เกิดปัญหาได้ @ผู้ฟัง การใส่คำอธิบายประกอบลงในแต่ละภาพกลายเป็นเรื่องยุ่งยากและมีโอกาสเกิดข้อผิดพลาดสูง

ในกรณีนั้น ให้สร้าง การทดสอบ ng.xml ดาวน์โหลดไฟล์และลงทะเบียนผู้ฟังที่นั่นเพียงครั้งเดียว

แท็ก listeners ในไฟล์ testng.xml สำหรับคลาสหลายคลาส

จากนั้นตัวรับฟังนี้จะถูกนำไปใช้กับชุดทดสอบทั้งหมดโดยไม่คำนึงถึงจำนวนคลาส เมื่อคุณเรียกใช้ไฟล์ XML ตัวรับฟังจะทำงานสำหรับทุกคลาสที่ประกาศไว้ในชุดทดสอบ และคุณสามารถเชื่อมโยงคลาสตัวรับฟังจำนวนเท่าใดก็ได้ภายในแท็กเดียวกัน

WebDriverListener ใน Selenium 4 เทียบกับ EventFiringWebDriver ที่เลิกใช้งานแล้ว

ในขณะที่ TestNG ตัวรับฟังจะตอบสนองต่อเหตุการณ์ในวงจรชีวิตของการทดสอบ ในขณะที่ตัวรับฟังของ WebDriver จะตอบสนองต่อการกระทำของเบราว์เซอร์ เช่น การคลิก การนำทาง หรือการเรียกใช้ findElement Selenium 3. แนวทางทั่วไปคือ WebDriverEventListener อินเทอร์เฟซที่เชื่อมต่อผ่าน EventFiringWebDriverทั้งสองแบบถูกยกเลิกการใช้งานแล้วใน Selenium 4.x

สิ่งทดแทนที่ทันสมัยคือ เว็บไดรเวอร์ลิสต์เนอร์ อินเทอร์เฟซที่รวมเข้ากับ EventFiringDecorator:

นำเข้า org.openqa.selenium.WebDriver;
นำเข้า org.openqa.selenium.chrome.ChromeDriver;
นำเข้า org.openqa.selenium.support.events.EventFiringDecorator;
นำเข้า org.openqa.selenium.support.events.WebDriverListener;

ชั้นสาธารณะ ผู้ฟังการบันทึก การดำเนินการ เว็บไดรเวอร์ลิสต์เนอร์ {
@แทนที่
โมฆะสาธารณะ ก่อนรับ(ไดรเวอร์เว็บ ไดรเวอร์, สตริง URL) {
System.out.println(“การนำทางไปยัง “ + url);
}
}

ไดรเวอร์เว็บ ดิบ = ใหม่ ไดรเวอร์ Chrome();
ไดรเวอร์เว็บ คนขับ = ใหม่ EventFiringDecorator<>(ใหม่ LoggingListener()).decorate(raw);

ตัวตกแต่งนี้สามารถห่อหุ้ม WebDriver, WebElement หรือ Alert ใดๆ ก็ได้ ซึ่งมีความยืดหยุ่นมากกว่าตัวห่อหุ้มแบบเดิมที่ใช้การเรียกใช้งานเหตุการณ์ ใช้งาน เว็บไดรเวอร์ลิสต์เนอร์ สำหรับการตรวจสอบฝั่งเบราว์เซอร์และ TestNG ITestListener สำหรับการรายงานระดับชุดโปรแกรม

ระบบรับฟังอัจฉริยะที่ขับเคลื่อนด้วย AI: บันทึกข้อมูลและจัดการความล้มเหลวที่ชาญฉลาดกว่าเดิม

ทันสมัย Selenium ทีมต่างๆ เริ่มนำบริการ AI มาผสานรวมเข้ากับอุปกรณ์รับฟังมากขึ้น เพื่อให้สัญญาณ CI สามารถนำไปปฏิบัติได้จริงยิ่งขึ้น ภายใน เมื่อการทดสอบล้มเหลวระบบรับฟังที่ใช้ AI ช่วย สามารถบันทึกภาพรวมของ DOM และภาพหน้าจอ ส่งไปยังโมเดลที่ส่งคืนคลัสเตอร์สาเหตุหลักที่เป็นไปได้ และเขียนแท็กกลับเข้าไปในระบบ TestNG รายงานหรือเครื่องมืออย่าง ReportPortal

รูปแบบที่พบได้ทั่วไปซึ่งขับเคลื่อนด้วย AI ได้แก่:

  • การตรวจจับการทดสอบที่ไม่เสถียร: ผู้ฟังส่งไทม์ไลน์การผ่าน/ไม่ผ่านไปยังแบบจำลองที่จำแนกความล้มเหลวว่าเป็นผลมาจากปัจจัยชั่วคราว ปัจจัยด้านสิ่งแวดล้อม หรือความบกพร่องที่แท้จริง
  • การจับภาพหน้าจออัจฉริยะ: โมเดลคอมพิวเตอร์วิชั่นจะตัดส่วน ใส่คำอธิบายประกอบ และเปรียบเทียบภาพหน้าจอ UI เพื่อให้ผู้ตรวจสอบเห็นเฉพาะบริเวณที่เปลี่ยนแปลง แทนที่จะเห็นภาพหน้าจอทั้งหมด
  • อุปกรณ์ระบุตำแหน่งที่ซ่อมแซมตัวเองได้: A เว็บไดรเวอร์ลิสต์เนอร์ ตะขอ ก่อนค้นหาองค์ประกอบ และขอให้ผู้ช่วย AI แนะนำตัวระบุตำแหน่งสำรองเมื่อตัวระบุตำแหน่งหลักใช้งานไม่ได้ NoSuchElementException.
  • บทสรุปภาษาธรรมชาติ: An ไอรีพอร์ตเตอร์ การนำผลลัพธ์จากชุดโปรแกรมไปใช้จะถูกส่งไปยัง LLM ซึ่งจะสร้างบทสรุปแบบย่อหนึ่งย่อหน้า

เลเยอร์ตัวรับฟังเป็นจุดที่เหมาะสมที่สุดในการแทรกฮุกเหล่านี้ เนื่องจากมันไม่เกี่ยวข้องกับตรรกะการทดสอบและถูกนำไปใช้โดยสม่ำเสมอทั่วทั้งชุดการทดสอบ

สรุป

ผู้ฟังจะต้องสร้างบันทึกหรือปรับแต่ง TestNG รายงานใน Selenium เว็บไดร์เวอร์

  • TestNG มีอินเทอร์เฟซสำหรับผู้ฟังหลายแบบ เลือกใช้แบบที่ตรงกับกิจกรรมที่คุณสนใจ
  • Listener คืออินเทอร์เฟซที่ใช้ใน Selenium สคริปต์ WebDriver เพื่อตอบสนองต่อเหตุการณ์ในวงจรชีวิตของการทดสอบ
  • บทช่วยสอนได้แสดงให้เห็นแล้ว ITestListener โดยมีการสอบผ่านและสอบไม่ผ่าน
  • คุณสามารถแนบตัวรับฟังได้ด้วย @ผู้ฟัง หรือลงทะเบียนเพียงครั้งเดียว การทดสอบ ng.xml สำหรับห้องสวีททั้งหมด
  • Selenium 4.x แทนที่ EventFiringWebDriver สีสดสวย เว็บไดรเวอร์ลิสต์เนอร์ + EventFiringDecorator สำหรับเหตุการณ์ระดับ WebDriver

คำถามที่พบบ่อย

Listener คืออินเทอร์เฟซที่สมัครรับเหตุการณ์ที่เกิดขึ้นระหว่างการทำงาน Selenium ทดสอบการทำงาน TestNG ตัวรับฟังจะตอบสนองต่อเหตุการณ์ในวงจรชีวิตของการทดสอบ เช่น การเริ่มต้น การผ่าน การล้มเหลว และการข้าม ตัวรับฟังของ WebDriver จะตอบสนองต่อเหตุการณ์ของไดรเวอร์เบราว์เซอร์ เช่น การคลิก การนำทาง และการเรียกใช้ findElement

ITestListener จะทำงานสำหรับเมธอด @Test แต่ละรายการ และมีฟังก์ชัน onTestStart, onTestSuccess, onTestFailure, onTestSkipped และ onFinish ส่วน ISuiteListener จะทำงานเพียงสองครั้งต่อชุดทดสอบ คือ onStart และ onFinish ทำให้เหมาะสำหรับการตั้งค่าระดับชุดทดสอบ เช่น การเปิดไฟล์รายงาน

คุณสามารถลงทะเบียนได้ TestNG สามารถกำหนด Listener ได้สองวิธี: เพิ่มคำอธิบายประกอบ @Listeners(MyListener.class) ไว้เหนือคลาสทดสอบ หรือประกาศ Listener ก็ได้ ใส่แท็กภายในไฟล์ testng.xml วิธีการใช้ XML จะทำให้ตัวรับฟัง (listener) ครอบคลุมทุกคลาสในชุดทดสอบโดยไม่ต้องแก้ไขซอร์สโค้ด

EventFiringWebDriver และ WebDriverEventListener ถูกยกเลิกการใช้งานแล้วในเวอร์ชันนี้ Selenium 4.x. ตัวเลือกทดแทนที่แนะนำคืออินเทอร์เฟซ WebDriverListener ที่ทำงานร่วมกับ EventFiringDecorator ซึ่งสามารถห่อหุ้มอินสแตนซ์ WebDriver, WebElement หรือ Alert และมีจุดเชื่อมต่อที่สะอาดกว่า เช่น beforeGet และ afterClick

ใช้ IReporter เมื่อคุณต้องการสร้างรายงานแบบกำหนดเองหลังจากชุดทดสอบเสร็จสิ้น เช่น สรุปในรูปแบบ HTML หรือ JSON ใช้ IInvokedMethodListener เมื่อคุณต้องการ hook ก่อนและหลังเมธอดทดสอบทุกตัว รวมถึงเมธอดการกำหนดค่าต่างๆ เช่น @BeforeMethod และ @AfterMethod

โมเดล AI สามารถเพิ่มคุณค่าให้กับผลลัพธ์ของผู้ฟังได้โดยการติดแท็กให้กับแต่ละรายการบันทึกด้วยระดับความรุนแรง สร้างคำอธิบายขั้นตอนด้วยภาษาธรรมชาติ และจัดกลุ่มความล้มเหลวที่เกี่ยวข้อง ภายใน onTestFailure บริการ AI สามารถวิเคราะห์ภาพหน้าจอและสแต็กได้ tracจากนั้นให้ระบุสาเหตุหลักที่เป็นไปได้ลงไป TestNG แจ้ง

ใช่แล้ว ผู้ฟังสามารถสตรีมประวัติการผ่าน/ไม่ผ่านไปยังบริการ AI ซึ่งจะจำแนกความล้มเหลวว่าเป็นเพราะความผิดปกติชั่วคราว สภาพแวดล้อม หรือเป็นการถดถอยที่แท้จริง จากนั้นผลลัพธ์จะถูกเขียนกลับมาเป็น TestNG คุณสมบัติดังกล่าว ช่วยให้แดชบอร์ดสามารถแยกการทดสอบที่ไม่เสถียรได้โดยไม่ต้องให้มนุษย์ตรวจสอบทุกบิลด์ที่เป็นสีแดง

สรุปโพสต์นี้ด้วย: