การทดสอบการทำงานเว็บของ AI Agent: การตรวจสอบ 4 ระดับและตัวชี้วัด

การทำงานสำเร็จหนึ่งครั้งใน demo environment ไม่ได้หมายความว่าเส้นทางเดียวกันจะใช้งานได้อย่างเชื่อถือได้ทุกวัน

หากต้องการประเมินให้ชัด ควรแยกการทดสอบ: ตรวจ environment ในชั้นของ environment ตรวจ Agent ในชั้นของ Agent และสุดท้ายดูว่าทั้งสองส่วนยังคงเสถียรเมื่อเชื่อมต่อกันหรือไม่

Single-step smoke test: ทดสอบ 4 การกระทำแยกกัน

Smoke test ทำเพียง 4 อย่างและทดสอบทีละอย่างโดยไม่ต่อเป็นชุด: เปิด page ที่กำหนด; หา element บน page; click element; ดึง text ของ element นั้นกลับมา หากทั้ง 4 อย่างผ่าน แสดงว่าพื้นฐานด้าน connection, session และ element access ใช้งานได้

การแยกทดสอบเพียง 4 อย่างช่วยให้ขอบเขตของ failure แคบลง หากเปิด page ไม่ได้ ปัญหามักอยู่ที่ network egress หรือสิทธิ์การเข้าถึง หากเปิดได้แต่หา element ไม่เจอ อาจเกิดจาก page ยัง load ไม่เสร็จ หรือ locator พึ่งพา layout ปัจจุบันมากเกินไป หากหาเจอแต่ click ไม่ได้ ให้ตรวจว่า element ถูกบังหรืออยู่ใน iframe หรือไม่ หาก text ที่ได้กลับมาว่าง ให้ยืนยันก่อนว่ากำลังอ่าน rendered content ไม่ใช่ HTML เริ่มต้น

ให้ดู 3 ตัวเลข: single-step success rate, เวลาของแต่ละ step และการกระจายประเภท error ตัวเลขเหล่านี้ควรเสถียรตั้งแต่ smoke stage หาก single-step success rate แกว่งอยู่เพียงประมาณ 80–90% การทดสอบขั้นต่อไปก็แทบไม่มีความหมาย

งานหลายขั้นตอน: branch สำคัญกว่าจำนวน step

นำ 4 การกระทำข้างต้นมาต่อเป็นงานจริง เช่น กรอก form, เปิดหลาย pages, filter ตามเงื่อนไข และเขียนผลลัพธ์กลับไปยัง local การเพิ่มจำนวน step เป็นเพียงการเพิ่มปริมาณ ความยากจริงอยู่ที่ branch: มี prompt โผล่ขึ้นมา, target element หายไป, page redirect เอง หรือเจอขั้นตอน verification ที่ต้องให้คนยืนยัน

ที่นี่ควรดู task completion rate ไม่ใช่ step success rate หลังเกิด failure ความสามารถของ Agent ในการปรับเส้นทาง และรู้ว่าเมื่อใดควรหยุดพร้อม report ปัญหาให้ชัดเจน สำคัญกว่าการวิ่งให้จบทุกครั้ง

อีกตัวเลขที่มักถูกมองข้ามคือจำนวน human intervention หากรันงานเดิม 20 ครั้ง จำนวนครั้งที่ต้องมีการแทรกแซงและจุดที่ติดในแต่ละครั้ง สามารถบอก maturity ของเส้นทางได้ดีกว่า overall completion rate

Concurrency และ fault injection

เมื่อเส้นทางเดียวเสถียรแล้ว จึงเพิ่ม concurrency เปิดหลาย environments พร้อมกันเพื่อรันงานประเภทเดียวกัน แล้วดูว่า environments รบกวนกันหรือไม่ และ failure rate แย่ลงเมื่อ concurrency สูงขึ้นหรือไม่ Failure ในช่วงนี้มักไม่ได้เกิดจาก Agent logic ผิด แต่เกิดจาก resource หรือ session ถูกกดดัน

Fault injection เป็นการทดสอบที่ถูกข้ามได้ง่ายที่สุด แต่จำเป็นมาก ควรสร้าง timeout, element หายระหว่างทาง, session หมดอายุ และ CAPTCHA แบบตั้งใจ แล้วดูการตอบสนอง: หลัง timeout retry สำเร็จหรือ process ค้าง; หลัง session หมดอายุมี error ชัดเจนหรือยังเดินหน้าด้วย credential ที่ใช้ไม่ได้

บันทึก 3 metrics: เส้นโค้ง failure rate ภายใต้ concurrency, recovery success rate หลังเกิด fault และเวลาที่เพิ่มขึ้นจาก fault หนึ่งครั้ง หาก recovery success rate ต่ำ แสดงว่าเส้นทางนี้ทำงานได้ดีเฉพาะตอนที่เงื่อนไขเป็นใจ

ตรวจ environment layer แยกต่างหาก

การทดสอบก่อนหน้านี้ทำใน environment เดียว แต่เมื่อใช้หลาย environments พร้อมกัน ต้องตรวจอีกหนึ่งชั้นแยกต่างหาก: แต่ละ environment ต้อง start ได้อย่างอิสระ เก็บ session และ cache ของตัวเอง และผูกกับ egress IP ของตัวเอง

ทีมที่ดูแลหลาย accounts มักแยก environment ตาม account เครื่องมืออย่าง PurpleMark ให้ environment isolation เพื่อให้แต่ละ account มี runtime space แยกจากกัน ในการทดสอบ ให้ start หลาย environments พร้อมกันและยืนยันว่า Cookies, cache และ egress ไม่ปะปนกัน

สำหรับชั้นนี้ ให้ดู 3 ตัวเลข: environment startup success rate, data cross-talk ระหว่าง environments (ปกติควรเป็นศูนย์) และ session ยังต่อเนื่องได้หรือไม่หลัง rebuild environment

วิธีระบุสาเหตุหลังเกิด failure

เมื่อเส้นทางมีปัญหา ความผิดพลาดที่พบบ่อยคือรีบแก้ Agent script ทันที ลำดับที่เหมาะกว่าคือ ตรวจว่า environment start ได้หรือไม่และ session หมดอายุหรือยัง จากนั้นดู network egress และ nodes แล้วจึงค่อยสงสัย element location กับ task planning ของ Agent หากสลับลำดับ จะเกิดการแก้ซ้ำในจุดที่ไม่ใช่สาเหตุ

4 การกระทำใน single-step smoke test ยังใช้เป็นเครื่องมือหาสาเหตุได้ด้วย หลัง failure ใดๆ ให้กลับมารัน 4 อย่างนี้แยกกัน แล้วดูว่าจุดใดขาดก่อน ส่วนใหญ่จะพบคำตอบได้ในขั้นตอนนี้