การทดสอบแบบเอเจนติก - บทบาทของเอเจนต์ในสแตกการทดสอบ E2E

 (slack.engineering)
6 คะแนน โดย GN⁺ 3 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • ทีมวิศวกรรมของ Slack รันการทดลองด้วย เวิร์กโฟลว์แบบเอเจนติกกว่า 200 รายการ เพื่อตรวจสอบว่า การทดสอบ E2E (End-to-End) แบบอิงเอเจนต์จะมาแทนการทดสอบแบบกำหนดแน่นอน (deterministic) เดิมได้หรือไม่
  • ขณะที่การทดสอบ E2E แบบดั้งเดิมบังคับให้เดินตามเส้นทาง UI ที่กำหนดไว้ เอเจนต์จะตรวจสอบว่า บรรลุเป้าหมาย (goal) ได้หรือไม่ และอาจไปถึงผลลัพธ์เดียวกันผ่านเส้นทางที่ต่างกัน
  • การรันเอเจนต์ใช้เวลา ครั้งละ $15–30 และมากกว่า 10 นาที แต่ก็มีกรณีใช้งานที่ชัดเจนในด้านความน่าเชื่อถือ
  • แนวทาง Playwright MCP มีอัตราความล้มเหลวต่ำกว่าและใช้โทเคนน้อยกว่าวิธี CLI และวิธีสร้างโค้ด โดยเสถียรภาพของสภาพแวดล้อมรันมีผลชี้ขาดต่อผลลัพธ์
  • การทดสอบแบบเอเจนติกไม่ได้มาแทนที่การทดสอบเดิม แต่ถูกเพิ่มเข้าไปเป็นชั้นสำหรับการสำรวจ การดีบัก และการตรวจสอบพฤติกรรมซับซ้อนที่ ยอดบนสุดของ test pyramid

จากเส้นทางสู่เป้าหมาย (From Journeys to Goals)

  • การทดสอบ E2E แบบดั้งเดิมตรวจสอบ journey ที่เฉพาะเจาะจงโดยเดินตาม UI → คลิก → คลิก → ป้อนข้อมูล → assert
  • การทดสอบแบบอิงเอเจนต์ตรวจสอบว่า สามารถบรรลุเป้าหมาย ที่อธิบายด้วยคำสั่งอย่าง "ส่งข้อความในเธรด" ได้หรือไม่ → เป้าหมาย → เอเจนต์ปรับตัว → ตรวจสอบผลลัพธ์
    • ความต่างหลักคือ: "การทดสอบบังคับเส้นทาง แต่เอเจนต์ตรวจสอบเป้าหมาย"
  • เวิร์กโฟลว์ทั้งหมด (ล็อกอิน → ค้นหา → ผลลัพธ์ → รีเซ็ต) คงเดิม แต่ลำดับพฤติกรรมจริงเปลี่ยนไปทุกครั้ง
    • วิธีป้อนข้อมูลที่ต่างกัน (คลิกคำแนะนำการค้นหา vs กด Enter)
    • รูปแบบการนำทางที่ต่างกัน (ค้นหาใหม่ vs ใช้สถานะเดิมต่อ)
    • ขั้นตอนที่ถูกเพิ่มหรือละไว้ (คลิกเพิ่ม, snapshot, การกระทำระหว่างทาง)
  • ความยืดหยุ่นนี้มาพร้อม trade-off ด้าน ความน่าเชื่อถือ ต้นทุน และเวลาในการรัน

  • การตั้งคำถาม

    • คำถามหลักคือ วิธีที่ใช้เวลา ครั้งละ $15–30 และมากกว่า 10 นาที จะเข้ากับเวิร์กโฟลว์การทดสอบสมัยใหม่ได้หรือไม่
    • จากการรันกว่า 200 ครั้ง พบว่ามันแตกต่างจากการทดสอบแบบดั้งเดิมโดยพื้นฐาน แต่ยังให้ความน่าเชื่อถือสูงและมีกรณีใช้งานที่ชัดเจน
    • ความก้าวหน้าของ โมเดลภาษาขนาดใหญ่ (LLM) ที่ทำให้เขียนโค้ด ดีบักความล้มเหลว และควบคุม UI โดยตรงได้ เปิดทางให้โมเดลการรันแบบใหม่เกิดขึ้น

การออกแบบการทดลอง (Our Experiment)

  • มีการรันอัตโนมัติกว่า 200 ครั้ง ภายใต้หลายคอนฟิกเพื่อวัดความน่าเชื่อถือ ความเร็วในการรัน และต้นทุน

  • โมเดลการรัน (3 วิธี)

    • Agent + Playwright MCP: เอเจนต์โต้ตอบกับเบราว์เซอร์ผ่านการกระทำที่นิยามไว้ล่วงหน้า (คลิกองค์ประกอบ, ป้อนข้อมูล, อ่านสถานะ DOM ฯลฯ) พร้อมคง คอนเท็กซ์ต่อเนื่อง (DOM snapshot และ log)
    • Agent + Playwright CLI: รันคำสั่ง Playwright CLI ในเชลล์และจัดการทีละขั้น จากนั้นดูสถานะ UI ที่อัปเดตแล้วค่อยตัดสินใจการกระทำถัดไป
    • Generated Playwright Tests: AI agent สร้าง โค้ด Playwright แบบ deterministic จากคำอธิบายภาษาธรรมชาติ แล้วรันเป็นการทดสอบ E2E มาตรฐานพร้อมปรับปรุงซ้ำจนกว่าจะผ่าน

  • สภาพแวดล้อมการทดลอง

    • โมเดลเอเจนต์ MCP และ CLI: Claude Sonnet 4.5
    • โมเดลสำหรับสร้าง Playwright test: Claude Opus 4.6
    • การรัน: Claude Code แบบไม่โต้ตอบ (claude -p)
    • เครื่องมือเบราว์เซอร์: Playwright MCP, Playwright CLI
    • สภาพแวดล้อม: Slack Dev API MCP โดยการทดลองทั้งหมดทำใน test workspace ที่ใช้ข้อมูลแบบ non-production

  • test flow (2 ระดับความซับซ้อน)

    • Thread Reply (ง่าย): เวิร์กโฟลว์ราว 15–20 ขั้นตอน รวมการสร้างช่อง, ส่งข้อความ, ตอบในเธรด และตรวจสอบสถานะเธรด
    • Search Discovery (ซับซ้อนปานกลาง): เวิร์กโฟลว์ราว 25–30 ขั้นตอน รวมการป้อนคำค้นหา, สำรวจผลลัพธ์, ย้ายระหว่างมุมมอง (ค้นหา, ช่อง, เธรด) และตรวจสอบผลลัพธ์ที่คาดหวัง

  • รูปแบบอินพุต

    • ภาษาธรรมชาติ (NL): คำสั่งที่มนุษย์อ่านง่าย อธิบายเวิร์กโฟลว์และผลลัพธ์ที่คาดหวังเป็นรายการทีละขั้น
    • YAML แบบมีโครงสร้าง: รูปแบบเชิงโครงสร้างที่ระบุเวิร์กโฟลว์เดียวกันด้วยขั้นตอน, การกระทำ, เป้าหมาย และผลลัพธ์ที่คาดหวัง
      • ความต่างไม่ได้อยู่ที่ระดับความละเอียด แต่อยู่ที่วิธีการแสดงออก — ภาษาธรรมชาติต้องให้เอเจนต์ตีความและแมปเอง ขณะที่ YAML กำหนดการแมปไว้อย่างชัดเจนกว่า

  • เมทริกซ์การทดลอง

    • แต่ละคอนฟิกรัน 20 ครั้ง รวมทั้งหมด 5 การทดลอง (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, generated test-NL) กับทั้งสอง flow คือ Thread Reply และ Search Discovery

สิ่งที่สังเกตพบ (What We Observed)

  • สรุปผลลัพธ์

    • Agent (Playwright MCP): อัตราล้มเหลว 0% (thread reply) / ประมาณ 12% (search discovery), เฉลี่ย 5–8 นาที
    • Agent (Playwright CLI): อัตราล้มเหลวประมาณ 12% / ประมาณ 20%, เฉลี่ย 9–11 นาที
    • Generated Playwright Tests: อัตราล้มเหลวประมาณ 8% / ประมาณ 48%, เฉลี่ย 3 นาที

  • ความน่าเชื่อถือ (Reliability)

    • เมื่อ flow ซับซ้อนขึ้น การเปลี่ยนแปลงของความน่าเชื่อถือจะเห็นได้ชัดที่สุด
    • Playwright MCP เสถียรที่สุด — ในสถานการณ์ง่ายมีอัตราล้มเหลวแทบ 0% และยังคงอยู่ที่ 0–12% แม้ใน flow ที่ซับซ้อน
    • Playwright CLI มีอัตราล้มเหลวสูงกว่า (ประมาณ 12–20%) โดยส่วนใหญ่เกิดจากปัญหาการรัน เช่น การจัดการการยืนยันตัวตน จังหวะของการนำทาง และความไม่เสถียรของเซสชัน มากกว่าปัญหาการให้เหตุผลของโมเดล
    • การทดสอบที่สร้างขึ้นทำได้ดีใน flow ง่าย (ประมาณ 8%) แต่แย่ลงมากในเวิร์กโฟลว์ซับซ้อน (ประมาณ 48%)
      • ไม่ได้ผิดทั้งหมด โดยทั่วไปยังไปได้ถึง 70–80% ของ flow ก่อนจะล้มเหลวที่ interaction หรือ assertion ช่วงท้าย
      • สาเหตุคือความแปรปรวนของสถานะ UI และความไม่ตรงกันของ abstraction — เนื่องจากถูกสร้างจาก flow ภาษาธรรมชาติที่สเปกไว้หลวม ๆ และนำ page object abstraction เดิมกลับมาใช้ จึงขัดขวางการเจาะจงองค์ประกอบได้แม่นยำ
    • ยิ่งความซับซ้อนสูง ช่องว่างด้านความน่าเชื่อถือยิ่งกว้างขึ้น และ โมเดลการรันที่ native กับเอเจนต์อย่าง MCP มีเสถียรภาพกว่า
      • MCP คงมุมมองของแอปที่สดใหม่และเสถียรแบบเรียลไทม์ ส่วน CLI ต้องประกอบสถานะขึ้นใหม่จาก snapshot ในแต่ละขั้น → ยิ่ง flow ยาว ความคลาดเคลื่อนยิ่งสะสม
      • MCP ดูเหมือนจะนำ interaction ที่สำเร็จในขั้นก่อนหน้าภายในเซสชันกลับมาใช้ได้ ขณะที่ CLI ให้ความรู้สึกเหมือนเริ่มใหม่ทุกขั้น (ไม่ได้วัดอย่างชัดเจน)

  • ความเร็ว (Speed)

    • generated test เร็วที่สุดอย่างสม่ำเสมอ (ประมาณ 3 นาที), MCP ประมาณ 5–8 นาที, CLI ประมาณ 9–11 นาที
    • ตัวเลขของ generated test รวมทั้งการสร้างและการรัน โดยค่าเฉลี่ยมาจากการสร้างหนึ่งครั้งแล้วรัน 5 ครั้ง
      • การรันจริงล้วน ๆ เร็วกว่ามาก — thread reply ประมาณ 32 วินาที, search discovery ประมาณ 45 วินาที
      • ในสภาพแวดล้อม CI ที่รันซ้ำ ต้นทุนการสร้างครั้งเดียวแทบไม่มีนัยสำคัญ ทำให้การทดสอบแบบ deterministic ขยายได้อย่างมีประสิทธิภาพ
    • เวิร์กโฟลว์แบบเอเจนต์ต้องจ่ายต้นทุนทุกครั้งที่รัน — แต่ละขั้นต้องสังเกตสถานะ UI, ให้เหตุผลหาการกระทำถัดไป, ลงมือทำ และตรวจสอบผลลัพธ์

  • ความสามารถในการปรับตัว (Adaptability)

    • มีเพียง ประมาณ 20% ของการรันเท่านั้นที่ทำตามลำดับการกระทำเดียวกัน ส่วนใหญ่ค้นพบเส้นทาง UI ที่ถูกต้องต่างกันแต่ไปถึงเป้าหมายเดียวกัน
      • เปิดเมนูในลำดับที่ต่างกัน
      • เลือกองค์ประกอบ UI ที่ต่างกันเล็กน้อย
      • ใช้ flow การนำทางทางเลือก
    • เพื่อการวัดผล มีการเปรียบเทียบ action signature ระหว่างแต่ละการรัน — รายการลำดับของ tool call และการกระทำบน UI ที่เอเจนต์ทำ
      • ก่อนเปรียบเทียบมีการ normalize โดยรวมพารามิเตอร์, การรอ/การทำ snapshot และรูปแบบเครื่องมือที่เทียบเท่ากัน (fill vs type) เพื่อคำนวณเฉพาะความต่างที่มีความหมาย
    • แม้ผลลัพธ์สุดท้ายจะถูกต้อง ลำดับการกระทำส่วนใหญ่ก็ยังต่างกัน — E2E แบบดั้งเดิมบังคับ deterministic journey เดียว ส่วนเอเจนต์สำรวจอินเทอร์เฟซแล้วตรวจสอบว่าบรรลุ state เป้าหมายหรือไม่

  • ต้นทุนและที่มาของต้นทุน (Cost and Where It Comes From)

    • การรันแบบเอเจนต์มักมีต้นทุน ครั้งละ $15–30 ซึ่งแพงกว่าการทดสอบแบบดั้งเดิมมาก
    • การวิเคราะห์การใช้โทเคนของ flow search discovery เดียวกัน
      • MCP (Opus 4.6) ประมาณ 3.8M, MCP (Sonnet 4.5) ประมาณ 3.5M, MCP (Haiku 4.5) ประมาณ 5.7M
      • CLI (Opus 4.6) ประมาณ 6M, Code Gen (Opus 4.6) ประมาณ 7M
    • วิธีรันสำคัญกว่าว่าใช้โมเดลไหน — แม้ Haiku จะใช้โทเคนมากกว่า แต่วิธี MCP ทั้งหมดก็ยังใช้โทเคนน้อยกว่า CLI และ Code Gen
    • การวิเคราะห์วิธีรันเซสชันของ Claude Code พบว่า API พื้นฐานเป็นแบบ stateless จึงต้องส่ง system prompt ทั้งหมดและประวัติการสนทนาทั้งหมดซ้ำในทุกเทิร์น
      • ต้นทุนไม่ได้ถูกกำหนดโดยเอาต์พุตของโมเดล แต่ขึ้นกับ ความเร็วในการสะสมคอนเท็กซ์และจำนวนเทิร์น
    • จำนวนเทิร์น: MCP (Opus/Sonnet) ประมาณ 40, MCP (Haiku) ประมาณ 60, CLI (Opus) ประมาณ 85, Code Gen (Opus) ประมาณ 70
      • CLI แยก interaction ของเบราว์เซอร์แต่ละครั้งออกเป็นหลายคำสั่ง เช่น กระทำ, รอ, snapshot, อ่านค่า, ค้นหาองค์ประกอบ ทำให้เฉลี่ย 85 เทิร์น
      • MCP รวม interaction และการคืนค่าสถานะไว้ในรอบโต้ตอบเดียว
      • ทุกเทิร์นที่เพิ่มขึ้นหมายถึงภาระการส่งต้นทุนของ system prompt ทั้งชุดและคอนเท็กซ์บทสนทนาก่อนหน้าอีกครั้ง
    • สิ่งที่เติมคอนเท็กซ์ให้เต็ม
      • MCP และ CLI: browser snapshot คือ payload หลัก — accessibility tree snapshot ที่ Playwright MCP ส่งกลับจะสะสมต่อไปในทุกเทิร์นถัดไป
      • Code Gen: ในทุกการ retry จะสะสมเอาต์พุตจาก test runner ทั้ง error trace, assertion failure และสถานะ DOM ทั้งชุด
    • ต้นทุนส่วนใหญ่เกิดจาก การส่งซ้ำสิ่งที่เคยเห็นแล้ว โดยข้อมูลใหม่ในแต่ละเทิร์นมีเพียงเล็กน้อยมาก
    • การใช้โทเคนยังอยู่ในขั้นที่ยังไม่ได้ optimize — แนวทางลดต้นทุนที่เสนอคือ prompt caching, context compaction และลดความถี่ของ snapshot
    • เพราะต้นทุน ปัจจุบันจึงเหมาะกับ การดีบักแบบเจาะจงและ exploratory testing มากกว่าการรัน CI ความถี่สูง แม้อนาคตอาจดีขึ้นด้วยโมเดลและเครื่องมือรุ่นใหม่

  • ความสำคัญของอินฟราสตรักเจอร์ (MCP vs CLI)

    • ไม่ใช่แค่ตัวโมเดล แต่สภาพแวดล้อมการรันส่งผลต่อความน่าเชื่อถืออย่างมาก — MCP ล้มเหลว 0–12%, CLI ล้มเหลว 12–20%
    • ความล้มเหลวของ CLI ส่วนใหญ่เกิดจากปัญหาการยืนยันตัวตนและการนำทาง (ล็อกอินผิดพลาด, timeout, เซสชันไม่เสถียร) ซึ่งเป็นปัญหาของ ชั้นการรัน ไม่ใช่การให้เหตุผลของเอเจนต์
    • Playwright MCP ให้ browser primitive แบบมีโครงสร้างและบูรณาการแน่นแฟ้นกับเวิร์กโฟลว์การเรียกใช้เครื่องมือของเอเจนต์ ขณะที่ CLI เพิ่มชั้นกลางระหว่างเอเจนต์กับเบราว์เซอร์
    • ความต่างด้านการทำงานขนาน: MCP ทำ parallel execution ได้ง่าย ส่วน CLI ทำได้ยาก จึงมักต้องรันแบบลำดับ
    • ความน่าเชื่อถือ ความเร็ว และต้นทุน ไม่ได้ขึ้นกับโมเดลอย่างเดียว แต่ขึ้นกับ เสถียรภาพและการออกแบบของสภาพแวดล้อมรัน ด้วย

  • ขอบเขตของความสามารถในการรัน (Execution Capability Boundaries)

    • การทดลองนี้โฟกัสที่ เวิร์กโฟลว์ UI ภายในเซสชันเดียว
    • flow ที่ข้ามหลาย workspace หรือเปิดหลายหน้าต่างเบราว์เซอร์ มีความท้าทายอีกแบบที่ทำให้การเลือกโมเดลการรันสำคัญพอ ๆ กับตัวเอเจนต์
      • MCP อาจเจอปัญหาต้นทุนเมื่อ observation loop ยาวขึ้นใน flow ที่ยืดเยื้อ
      • CLI อาจมีความซับซ้อนในการประสานงานและการใช้โทเคนสูงเมื่อจัดการหลาย browser session
    • ทั้งสองวิธีรองรับได้ แต่มี trade-off ต่างกัน — การทดลองนี้ยังไม่ได้สำรวจ และเป็นประเด็นสำคัญที่ทีมประเมินควรพิจารณา

ตำแหน่งของการทดสอบแบบเอเจนติกใน test pyramid

  • การทดสอบแบบเอเจนติกไม่ได้มาแทนวิธีเดิม แต่ เพิ่มความสามารถใหม่ ทับขึ้นไปด้านบน

  • การทดสอบ E2E แบบ deterministic

    • เหมาะที่สุดสำหรับ regression check ใน CI ที่ต้องเร็วและทำซ้ำได้
      • เขียนโดยคนหรือสร้างด้วย AI ก็ได้
      • เร็วและทำซ้ำได้, เป็นมิตรกับ CI
      • ต้นทุนการปฏิบัติการต่ำ
      • บังคับ UI journey ที่เฉพาะเจาะจง

  • การทดสอบแบบเอเจนติก

    • ไม่ได้เริ่มจากการรันสคริปต์ที่ตายตัว แต่ เริ่มจากเป้าหมาย — สังเกต UI, ให้เหตุผลจากสถานะปัจจุบัน, แล้วตัดสินใจว่าจะไปถึงผลลัพธ์ที่ต้องการอย่างไร
      • สำรวจพฤติกรรม UI ที่ซับซ้อน
      • ดีบักเวิร์กโฟลว์ที่ flaky
      • ทำซ้ำบั๊กใน production

  • test pyramid ที่มีชั้นเอเจนติก

    • มองในระดับระบบ การทดสอบแบบเอเจนติกตรวจสอบเวิร์กโฟลว์ผู้ใช้จริงผ่าน UI ในระดับเดียวกับ E2E ความต่างอยู่ที่ วิธีการรัน ของเวิร์กโฟลว์
    • กลยุทธ์การทดสอบที่มีประสิทธิภาพที่สุดในอนาคตน่าจะเป็นการผสานทั้งสองแบบ — deterministic tests เป็นฐานที่มั่นคงของ CI ส่วนการทดสอบแบบเอเจนติกทำหน้าที่สำรวจ ดีบัก และตรวจสอบพฤติกรรมซับซ้อนที่ยอดบนสุดของพีระมิด

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น