เปิดโฟลเดอร์โปรเจกต์
เริ่ม FlowLatch เลือกโฟลเดอร์ที่มีไฟล์ทดสอบของคุณเป็นโฟลเดอร์ทำงาน และเลือก Ask first เพื่อให้ทุกการกระทำที่เปลี่ยนแปลงข้อมูลจะรอการยืนยันจากคุณ เชื่อมต่อโมเดลหากคุณยังไม่ได้ทำ และใช้ปุ่ม Test เพื่อตรวจสอบ endpoint
เวิร์กโฟลว์
การทดสอบเว็บอัตโนมัติ: เปิด รัน อ่าน และแก้ไขตามลำดับ
03
ตรวจสอบขั้นตอนการชำระเงินในแอป staging ของคุณ
คุณมีสำเนา staging ของร้านค้า บัญชีทดสอบ และโฟลเดอร์ทดสอบ และต้องการทราบว่า การเข้าสู่ระบบ การเพิ่มสินค้าลงตะกร้า และการชำระเงินยังคงทำงานได้หรือไม่หลังจากการเปลี่ยนแปลงในวันนี้ นี่คือขั้นตอนการทดสอบเว็บแบบย่อ: โฟลเดอร์หนึ่ง คำสั่งทดสอบหนึ่ง และผลลัพธ์หนึ่งที่คุณสามารถอ่านได้ FlowLatch จะเปิดโฟลเดอร์ รันคำสั่งผ่าน Shell และแสดงค่า exit code จริงบนการ์ด หากขั้นตอนล้มเหลว มันจะชี้ไปที่บรรทัดและเสนอการแก้ไขในรูปแบบ diff และคุณจะเป็นผู้ตัดสินใจยอมรับหรือไม่ ขั้นตอนด้านล่างใช้เวลา 4 การกระทำ จากโฟลเดอร์สู่ผลลัพธ์ ทำงานเฉพาะกับแอปที่คุณสร้างหรือได้รับอนุญาตให้ทดสอบ ใช้บัญชีทดสอบและข้อมูลปลอม และใช้โหมดทดสอบของการตั้งค่าการชำระเงินของคุณเองสำหรับขั้นตอนการชำระเงิน อย่าใช้บัตรจริง การตรวจสอบอีเมลจะไปที่กล่องจดหมายทดสอบที่จัดตั้งขึ้นสำหรับการทดสอบ
แสดงรายการไฟล์ทดสอบ
ถามถึงโครงสร้างของเทสต์ โดย list_dir และ glob จะแสดงไฟล์ และ read_file จะเปิดหน้ากระบวนการชำระเงิน เพื่อให้คุณและเอเจนต์เริ่มทำงานจากข้อมูลเดียวกันก่อนการรันหรือเปลี่ยนแปลงใดๆ แต่ละการกระทำจะปรากฏในแชทเป็นการ์ดพร้อมผลลัพธ์
รันคำสั่งทดสอบของคุณ
บอกเอเจนต์ว่าโปรเจกต์ของคุณใช้คำสั่งทดสอบใด Shell จะรันคำสั่งบน Windows หรือใน WSL และการ์ดจะแสดงผลลัพธ์เต็มและค่า exit code จริง ไม่ใช่สรุป หากต้องการดูทุกบรรทัด ให้ขยายการ์ด และใช้ grep เพื่อค้นหาขั้นตอนที่ล้มเหลวในผลลัพธ์
อ่านผลลัพธ์และแก้ไข
เมื่อเกิดข้อผิดพลาด ให้ถามว่าผลลัพธ์บ่งชี้ถึงอะไร เอเจนต์จะเสนอการแก้ไขในรูปแบบ diff และจะไม่มีการเขียนข้อมูลจนกว่าคุณจะยอมรับ ปฏิเสธสิ่งที่ดูไม่ถูกต้อง จากนั้นรันคำสั่งอีกครั้งเพื่อดูค่า exit code ใหม่ ทำซ้ำจนกว่าขั้นตอนจะผ่านหรือคุณทราบสิ่งที่ต้องเปลี่ยนแปลงในแอป
โครงร่างการทดสอบที่คุณสามารถคัดลอกไปใช้ได้
รันขั้นตอนการชำระเงินในสำเนา staging ของฉันและบอกฉันว่าอะไรล้มเหลว
- list_dir
tests/แสดงรายการแล้ว - read_file
tests/checkout-flow-test.txtโหลดแล้ว - Shell
your test commandexit 0 - grep
FAIL reports/ไม่พบการจับคู่
รอการยืนยันจากคุณก่อนดำเนินการขั้นตอนถัดไปปฏิเสธยอมรับ
checkout-flow-test.txt
# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textโครงร่างนี้เป็นข้อความธรรมดาและอยู่ใน repository ข้างเคียงกับไฟล์ทดสอบของคุณ กรอบงานทดสอบของคุณจะเปลี่ยนแต่ละขั้นตอนเป็นโค้ด และ FlowLatch จะใช้ไฟล์นี้เป็นข้อกำหนดเมื่อเขียนโค้ดนั้น รันโค้ด และเปรียบเทียบผลลัพธ์กับบรรทัด expect สามบรรทัด เปลี่ยนชื่อผลิตภัณฑ์และหน้าเว็บให้ตรงกับแอป staging ของคุณ
คำแนะนำสำหรับการทดสอบเบราว์เซอร์อัตโนมัติ
ค้นหาและอ่านไฟล์ทดสอบที่มีอยู่
เริ่มต้นโดยถามว่าไฟล์ทดสอบอยู่ที่ไหน list_dir จะแสดงโฟลเดอร์ glob จะแสดงไฟล์ทั้งหมดที่ตรงกับรูปแบบ เช่น ไฟล์ทดสอบการชำระเงิน และ read_file จะเปิดไฟล์ที่คุณสนใจเพื่อดูว่าขั้นตอนถูกสร้างขึ้นอย่างไรในปัจจุบัน จากนั้น grep จะค้นหา selectors และ waits ที่ใช้ ทั้งหมดนี้เป็นการอ่านเท่านั้น ดังนั้นจึงเป็นขั้นตอนแรกที่เหมาะสมในโหมด Plan only ซึ่งจะเขียนแผนและไม่ได้รันอะไร แผนจะคงอยู่หลังจากการรีสตาร์ท ดังนั้นคุณสามารถกลับมาดูมันได้ในวันถัดไป เมื่อคุณพร้อมสำหรับการรันจริง ให้สลับเป็น Ask first และอ่านแผนอีกครั้ง จดบันทึกขั้นตอนที่ครอบคลุมอยู่แล้ว เพื่อให้คุณรู้ว่าขั้นตอนใดที่ยังขาดการทดสอบ
รันชุดทดสอบและอ่านค่า exit code
หลังจากการอัปเดต runtime ความล้มเหลวของชุดทดสอบ e2e มักมาจากสภาพแวดล้อมมากกว่าแอปของคุณ ดังนั้นให้อ่านข้อผิดพลาดแรกก่อนที่คุณจะแตะต้องไฟล์ทดสอบ Shell จะรันคำสั่งทดสอบของคุณ และการ์ดจะเก็บผลลัพธ์เต็มและค่า exit code จริง ซึ่งเป็นตัวชี้วัดการผ่านหรือล้มเหลวที่ตรงไปตรงมาที่สุด grep สามารถดึงขั้นตอนที่ล้มเหลวออกจากบันทึกที่ยาวได้ ขอคำอธิบายข้อผิดพลาดแบบเรียบง่ายในแชท เปรียบเทียบกับผลลัพธ์ แล้วจึงตัดสินใจว่าไฟล์ทดสอบจำเป็นต้องแก้ไขหรือไม่ หากข้อผิดพลาดระบุถึงแพ็กเกจที่ขาดหายไปหรือการตั้งค่าที่เปลี่ยนแปลง ให้แก้ไขสภาพแวดล้อมก่อนแล้วรันคำสั่งเดียวกันอีกครั้ง มักจะพบว่าชุดทดสอบผ่านโดยไม่ต้องแก้ไขเลย และค่า exit code บนการ์ดจะเป็นหลักฐานยืนยัน
แก้ไข selector และรันใหม่
การบำรุงรักษา selector ในการทดสอบ ui เป็นงานประจำที่พบบ่อยที่สุด เนื่องจากเลย์เอาต์ที่เปลี่ยนแปลงจะทำลาย selectors ที่ผูกติดกับมัน grep จะค้นหา selector เก่าในไฟล์ทั้งหมด read_file จะแสดงขั้นตอนที่เกี่ยวข้อง และ edit_file จะเสนอ label หรือ test id ที่เสถียรแทนที่ ในโหมด Ask first เอเจนต์จะหยุดชั่วคราวและแสดง diff ยอมรับบรรทัดที่ดูถูกต้อง จากนั้นให้ Shell รันคำสั่งอีกครั้ง ค่า exit code สีเขียวหลังการแก้ไขคือผลลัพธ์ที่คุณต้องการ และ diff จะคงอยู่ในประวัติ repository ของคุณสำหรับผู้ตรวจสอบรายถัดไป หากคำสั่งยังคงล้มเหลว ให้อ่านผลลัพธ์ใหม่ก่อนขอการเปลี่ยนแปลงเพิ่มเติม เพราะการแก้ไขครั้งที่สองบนการคาดเดาที่ผิดจะทำให้สาเหตุมองเห็นได้ยากขึ้น รักษาขนาด diff ให้เล็กพอที่จะอ่านได้ในครั้งเดียว
รันการทดสอบที่ล้มเหลวซ้ำเพื่อตรวจสอบความไม่เสถียร
เมื่อการทดสอบ ui e2e ล้มเหลว สาเหตุจริงมักจะเป็น wait แบบตายตัว ข้อมูลทดสอบที่ใช้ร่วมกัน หรือลำดับการทดสอบ ไม่ใช่แอป ถาม FlowLatch ให้รันการทดสอบที่ล้มเหลวหลายครั้งด้วยคำสั่งเดียวกันและรายงานค่า exit code แต่ละครั้ง ผลลัพธ์ที่ผสมกันหมายความว่าทดสอบไม่เสถียร หากกรอบงานของคุณบันทึกภาพหน้าจอ ocr จะอ่านข้อความในภาพ และข้อความจากหน้าเว็บในการรันที่ล้มเหลวจะเพิ่มเบาะแสที่สอง แก้ไข wait หรือข้อมูลในรูปแบบ diff ทบทวน แล้วรันการทดสอบอีกครั้ง ให้แต่ละการทดสอบมีข้อมูลของตัวเองและรีเซ็ตข้อมูล รอให้เงื่อนไขปรากฏแทนที่จะรอระยะเวลาตายตัว และทำให้การทดสอบเป็นอิสระจากลำดับของกันและกัน รันซ้ำอีกครั้งหลังการแก้ไข การผ่านเพียงครั้งเดียวพิสูจน์ได้น้อย
