การทดสอบแบบ End-to-End (E2E) คืออะไร? ตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบแบบครบวงจร (End-to-end testing) ตรวจสอบความถูกต้องของขั้นตอนการทำงานของซอฟต์แวร์ทั้งหมด ตั้งแต่ส่วนติดต่อผู้ใช้ ไปจนถึงระบบย่อยและฐานข้อมูลที่ผสานรวมเข้าด้วยกัน เพื่อให้มั่นใจว่าสถานการณ์จำลองที่เหมือนกับการใช้งานจริงทำงานได้อย่างถูกต้องก่อนที่จะปล่อยออกสู่ตลาด
สิ้นสุดการทดสอบ
การทดสอบแบบครบวงจร การทดสอบแบบ Dependency Testing (CPS) เป็นวิธีการทดสอบซอฟต์แวร์ที่ตรวจสอบความถูกต้องของแอปพลิเคชันทั้งหมดตั้งแต่ต้นจนจบ รวมถึงการบูรณาการกับอินเทอร์เฟซภายนอก จุดประสงค์คือเพื่อตรวจสอบซอฟต์แวร์ทั้งหมดในส่วนของความสัมพันธ์ระหว่างส่วนประกอบต่างๆ ความสมบูรณ์ของข้อมูล และการสื่อสารกับระบบ อินเทอร์เฟซ และฐานข้อมูลอื่นๆ โดยจำลองสถานการณ์การใช้งานจริงอย่างครบถ้วน
นอกจากนี้ยังช่วยตรวจสอบความถูกต้องของการประมวลผลแบบกลุ่มและข้อมูลจากระบบต้นน้ำและปลายน้ำ จึงเป็นที่มาของชื่อนี้ “ครบวงจร” โดยปกติแล้ว การทดสอบแบบ E2E จะดำเนินการหลังจากเสร็จสิ้นการทดสอบฟังก์ชันการทำงานและ การทดสอบระบบโดยใช้ข้อมูลที่คล้ายกับข้อมูลการผลิตเพื่อจำลองสถานการณ์แบบเรียลไทม์ เรียกอีกอย่างว่า การทดสอบโซ่.
ทำไมต้องจบการทดสอบ?
การทดสอบแบบครบวงจร ตรวจสอบการไหลของระบบทั้งหมดและเพิ่มความมั่นใจด้วยการตรวจจับปัญหาในระบบย่อยต่างๆ ซึ่งช่วยปรับปรุงประสิทธิภาพ ครอบคลุมการทดสอบระบบสมัยใหม่มีความเชื่อมโยงกันอย่างมาก และความล้มเหลวของระบบย่อยใดระบบหนึ่งอาจทำให้แพลตฟอร์มทั้งหมดล่มสลายได้ การทดสอบแบบครบวงจร (E2E testing) เป็นวิธีที่น่าเชื่อถือที่สุดในการลดความเสี่ยงดังกล่าว ก่อนที่จะปล่อยใช้งานจริง
สิ้นสุดกระบวนการทดสอบ
แผนภาพด้านล่างแสดงกระบวนการทดสอบแบบครบวงจร (End-to-End testing process)
.png)
กิจกรรมหลักในการทดสอบแบบครบวงจร (End-to-End Testing) ได้แก่:
- ศึกษาข้อกำหนดการทดสอบแบบครบวงจร
- การตั้งค่าสภาพแวดล้อมการทดสอบและข้อกำหนดด้านฮาร์ดแวร์/ซอฟต์แวร์
- อธิบายระบบทั้งหมดและกระบวนการย่อยของระบบเหล่านั้น
- กำหนดบทบาทและหน้าที่ความรับผิดชอบในระบบต่างๆ ให้ชัดเจน
- ตกลงกันเกี่ยวกับวิธีการและมาตรฐานการทดสอบ
- Track ข้อกำหนดแบบครบวงจรและกรณีทดสอบการออกแบบ
- กำหนดข้อมูลขาเข้าและขาออกสำหรับแต่ละระบบ
จะสร้างกรณีทดสอบแบบ End-to-End ได้อย่างไร
กรอบการออกแบบการทดสอบแบบครบวงจร (End-to-End Testing) ประกอบด้วยสามส่วน:
- สร้างฟังก์ชั่นผู้ใช้
- เงื่อนไขการก่อสร้าง
- สร้างกรณีทดสอบ
สร้างฟังก์ชั่นผู้ใช้
กิจกรรมต่อไปนี้ควรดำเนินการเป็นส่วนหนึ่งของการสร้างฟังก์ชันการใช้งานสำหรับผู้ใช้:
- ระบุคุณสมบัติของระบบและส่วนประกอบที่เชื่อมต่อกัน
- ระบุข้อมูลนำเข้า การกระทำ และข้อมูลส่งออกสำหรับแต่ละฟีเจอร์
- ระบุความสัมพันธ์ระหว่างฟังก์ชันต่างๆ
- พิจารณาว่าแต่ละฟังก์ชันสามารถนำกลับมาใช้ซ้ำได้หรือเป็นอิสระต่อกัน
ตัวอย่างเช่น ลองนึกถึงการเข้าสู่ระบบบัญชีธนาคารของคุณและโอนเงินไปยังธนาคารอื่น (ระบบย่อยของบุคคลที่สาม):
- เข้าสู่ระบบธนาคาร
- ตรวจสอบยอดเงินคงเหลือในบัญชี
- โอนเงินจากบัญชีของคุณไปยังบัญชีธนาคารอื่น
- ตรวจสอบยอดเงินคงเหลือล่าสุดในบัญชี
- ออกจากระบบแอปพลิเคชัน
สร้างเงื่อนไขตามฟังก์ชั่นผู้ใช้
กิจกรรมต่อไปนี้ดำเนินการเป็นส่วนหนึ่งของการตรวจสอบสภาพอาคาร:
- สร้างชุดเงื่อนไขสำหรับฟังก์ชันผู้ใช้แต่ละฟังก์ชันที่กำหนดไว้
- เงื่อนไขต่างๆ ได้แก่ เงื่อนไขลำดับ เวลา และข้อมูล
ตัวอย่างเช่น:
เข้าสู่ระบบหน้า
- ชื่อผู้ใช้และรหัสผ่านไม่ถูกต้อง
- ชื่อผู้ใช้และรหัสผ่านถูกต้อง
- การตรวจสอบความแข็งแกร่งของรหัสผ่าน
- การตรวจสอบข้อความแสดงข้อผิดพลาด
ยอดคงเหลือ
- ตรวจสอบยอดเงินคงเหลือหลังจาก 24 ชั่วโมง (เมื่อการโอนเงินไปยังธนาคารอื่น)
- ตรวจสอบข้อความแสดงข้อผิดพลาดหากจำนวนเงินที่โอนเกินยอดคงเหลือปัจจุบัน
สร้างสถานการณ์การทดสอบ
อาคาร สถานการณ์ทดสอบ สำหรับฟังก์ชันผู้ใช้ที่กำหนดไว้ ในกรณีนี้:
- เข้าสู่ระบบ
- ตรวจสอบยอดเงินในบัญชีธนาคาร
- โอนยอดเงินคงเหลือในบัญชีธนาคาร
สร้างกรณีทดสอบหลายกรณี
สร้างกรณีทดสอบอย่างน้อยหนึ่งกรณีสำหรับแต่ละสถานการณ์ที่กำหนดไว้ กรณีทดสอบแต่ละกรณีอาจพิจารณาแต่ละเงื่อนไขเป็นกรณีทดสอบเดียวก็ได้
ตัวชี้วัดสำหรับการทดสอบแบบครบวงจร
ตัวชี้วัดทั่วไปที่ใช้ในการทดสอบแบบครบวงจร ได้แก่:
- สถานะการเตรียมกรณีทดสอบ: Tracความคืบหน้าในการเตรียมงาน ks เทียบกับแผนงาน
- ความคืบหน้าการทดสอบประจำสัปดาห์: เปอร์เซ็นต์ความคืบหน้าประจำสัปดาห์ (ล้มเหลว ไม่ได้ดำเนินการ ดำเนินการแล้วเทียบกับแผน)
- สถานะและรายละเอียดของข้อบกพร่อง: จำนวนข้อบกพร่องที่เปิด/ปิดต่อสัปดาห์ และการกระจายตามระดับความรุนแรงและลำดับความสำคัญ
- ความพร้อมใช้งานของสภาพแวดล้อม: จำนวนชั่วโมงทั้งหมดที่ "ทำงาน" หารด้วยจำนวนชั่วโมงทั้งหมดที่กำหนดไว้ต่อวัน
เครื่องมือทดสอบ E2E ที่ทันสมัยในปี 2026
ปัจจุบันมีเฟรมเวิร์กหลัก 3 เฟรมเวิร์กที่ครองตลาดการทำงานอัตโนมัติแบบครบวงจร (E2E) บนเว็บ ได้แก่:
- Cypress: Javaเขียนสคริปต์ก่อน ทำงานภายในเบราว์เซอร์ พร้อมระบบดีบัgแบบย้อนเวลา เหมาะสำหรับส่วนหน้าของแอปพลิเคชันด้วย React, Vue และ Angular
- นักเขียนบทละคร: รองรับหลายเบราว์เซอร์ (Chromium, WebKit) Firefox) ด้วยการรออัตโนมัติ การประมวลผลแบบขนาน และ tracโปรแกรมดูอี.
- Selenium 4.x: ขณะนี้ได้เพิ่ม WebDriver BiDi, ตัวระบุตำแหน่งสัมพัทธ์ และความสามารถในการปรับขนาดกริดที่ดีขึ้นสำหรับชุดซอฟต์แวร์ระดับองค์กรแล้ว
สำหรับมือถือ Appium 2 และ Maestro นำ; Postman และ Karate จัดการโฟลว์ระดับ API
AI ในการสร้างการทดสอบแบบ End-to-End
ปัญญาประดิษฐ์เชิงสร้างสรรค์คือ reshaping การทดสอบแบบ End-to-End (E2E) แพลตฟอร์ม LLM อ่าน User Story และสร้างโค้ดโดยอัตโนมัติ Cypress หรือบทละครของนักเขียนบทละคร ในขณะที่ตัวระบุตำแหน่งที่แก้ไขตัวเองได้จะปรับตัวเมื่อ DOM เปลี่ยนแปลง ช่วยลดความยุ่งยากในการทดสอบที่ไม่เสถียร
เครื่องมือที่ชอบ TestimMabl, Functionize และ KaneAI วิเคราะห์ข้อมูลการใช้งานจริงเพื่อจัดลำดับความสำคัญของเส้นทางการใช้งานของผู้ใช้ที่มีความเสี่ยงสูงสุด
การทดสอบแบบครบวงจร (End-to-End) เทียบกับ การทดสอบแบบบูรณาการ (Integration) เทียบกับ การทดสอบระบบ (System)
| แง่มุม | จบสิ้น | บูรณาการ | System |
|---|---|---|---|
| ขอบเขต | แอปพลิเคชันเวอร์ชันเต็ม พร้อมอินเทอร์เฟซภายนอก | โมดูลแบบบูรณาการตั้งแต่สองโมดูลขึ้นไป | จัดทำซอฟต์แวร์ให้ครบถ้วนตามความต้องการ |
| สภาพสิ่งแวดล้อม | เหมือนงานผลิตจริงที่มีบุคคลที่สามเข้ามาเกี่ยวข้อง | ส่วนประกอบที่ไม่สมบูรณ์หรือการรวมเข้าบางส่วน | การจัดเวทีอย่างเป็นระบบ |
| ระยะ | หลังจากการทดสอบระบบเสร็จสิ้น | หลังจากทำการทดสอบหน่วยแล้ว | หลังจากการทดสอบการบูรณาการเสร็จสิ้น |
| อัตโนมัติ | ผสม; การทดสอบด้วยตนเอง ซึ่งมักจำเป็นสำหรับบุคคลที่สาม | ส่วนใหญ่ทำงานโดยอัตโนมัติ | ทั้งแบบใช้แรงงานคนและแบบอัตโนมัติ |
