กำไร:
- ความสามารถในการสร้างการทดสอบหน่วย การบูรณาการ และกรณี Edge ด้วยการยืนยันที่มีความหมายด้วย AI
- ความสามารถในการแยกความครอบคลุมของการทดสอบอย่างเป็นระบบ จำกัดค่า และสถานการณ์เชิงลบด้วยการสนับสนุน AI
- ความสามารถในการตรวจสอบว่าการทดสอบที่ผลิตโดย AI ตรวจสอบพฤติกรรมได้จริง และไม่ใช่แค่การทำซ้ำโค้ดที่มีอยู่
การทดสอบเป็นกลไกที่พิสูจน์ว่าซอฟต์แวร์ทำงานตามที่สัญญาไว้จริง ๆ ชุดทดสอบที่ดีจะบอกคุณภายในไม่กี่วินาทีว่าการเปลี่ยนแปลงส่งผลต่อบางสิ่งบางอย่างและทำให้วิศวกรมีอิสระในการดำเนินการด้วยความมั่นใจหรือไม่ AI เร่งความเร็วส่วนที่น่าเบื่อที่สุดและข้ามไปมากที่สุดของการเขียนทดสอบ: การสร้างสถานการณ์ จุดพัก และกรณีเชิงลบที่หลากหลาย แต่มีกับดักซ่อนเร้นอยู่ที่นี่: AI อาจเขียนการทดสอบเพื่อตรวจสอบพฤติกรรมปัจจุบันของโค้ด (อาจเป็นข้อผิดพลาด) ไม่ใช่พฤติกรรมที่ควรจะเป็น หรือสามารถสร้างการทดสอบเปล่าๆ ที่ผ่านเสมอ โดยไม่ได้ตรวจสอบอะไรเลย คุณค่าของการทดสอบไม่ได้อยู่ที่ว่าผ่านการทดสอบหรือไม่ แต่อยู่ที่การตรวจสอบสิ่งที่ถูกต้องและเปลี่ยนเป็นสีแดงเมื่อมันผิดหรือไม่
ในหน่วยนี้ คุณจะได้เรียนรู้วิธีสร้างการทดสอบหน่วย การบูรณาการ และกรณี Edge ด้วยการยืนยันที่มีความหมาย วิธีแยกความครอบคลุมของการทดสอบ จุดพัก และสถานการณ์ด้านลบอย่างเป็นระบบ และมาดูกันว่าคุณจะตรวจสอบได้อย่างไรว่าการทดสอบที่ AI สร้างพฤติกรรมการตรวจสอบได้จริง
แนวคิด: การทดสอบหน่วย: ทดสอบฟังก์ชัน/คลาสเดี่ยวแบบแยกกัน การทดสอบการรวม: ทดสอบว่าหลายส่วนทำงานร่วมกันได้อย่างถูกต้อง ยืนยัน: ข้อความที่ตรวจสอบว่าผลลัพธ์เท่ากับสิ่งที่คาดหวัง นี่คือหัวใจของการทดสอบ ความครอบคลุม: การทดสอบเรียกใช้โค้ดจำนวนเท่าใด ความครอบคลุมสูงไม่ได้รับประกันคุณภาพ
การสร้างแบบทดสอบที่มีความหมาย
การทดสอบที่ดีจะทำสามสิ่งอย่างชัดเจน: สร้างสถานะ ดำเนินการ และยืนยันผลลัพธ์ เมื่อพิมพ์การทดสอบไปยัง AI ให้ระบุลักษณะการทำงานที่คุณต้องการตรวจสอบ และสถานการณ์ที่ควรครอบคลุม มิฉะนั้นจะทำให้เกิดการทดสอบผิวเผินที่ผ่านไปเสมอ
- กำหนดพฤติกรรมที่จะทดสอบ “อะไรนับว่าถูกต้อง” ตอบคำถามให้ชัดเจน.
- สอบถามประเภทสถานการณ์ ปกติ ขีดจำกัด ลบ เงื่อนไขข้อผิดพลาด
- นำเข้าการยืนยันที่มีความหมาย มันไม่เพียงแค่ "ทำให้เกิดข้อผิดพลาด" แต่ยัง "ส่งคืนค่าที่ถูกต้อง"
- ตรวจสอบความถูกต้องของการทดสอบ การทดสอบเปลี่ยนเป็นสีแดงเมื่อคุณทำลายโค้ดอย่างมีสติหรือไม่?
พร้อมท์การสร้างการทดสอบที่ครอบคลุม: "เขียนหน่วยการทดสอบสำหรับฟังก์ชัน 'ใช้ส่วนลด (จำนวน คูปอง)' ต่อไปนี้ มีอย่างน้อยหนึ่งสถานการณ์ในหมวดหมู่ต่อไปนี้: (1) คูปองที่ถูกต้องปกติ (2) จุดพัก (จำนวน 0 ส่วนลด 100%) (3) ค่าลบ (คูปองไม่ถูกต้อง จำนวนค่าลบ) (4) กรณีข้อผิดพลาด (คูปองค่าว่าง) ยืนยันค่าที่คาดหวังของ CONCRETE ในการทดสอบแต่ละครั้ง (ไม่ใช่แค่ 'ทำงานแล้ว') ตั้งชื่อการทดสอบที่สามารถอ่านได้ รหัส: [รหัส]"
พร้อมท์การแยกค่าขอบเขต: "ทำการวิเคราะห์ค่าขอบเขตสำหรับอินพุตของฟังก์ชันนี้ สำหรับแต่ละพารามิเตอร์ ให้แยกค่า 'ที่ขอบเขต', 'ใต้ขอบเขต', 'เหนือขอบเขต' มาเป็นตาราง จากนั้นแสดงรายการสถานการณ์การทดสอบที่ครอบคลุมขอบเขตเหล่านี้ อย่าเพิ่งเขียนโค้ด เพียงวิเคราะห์และรายการสถานการณ์ ฟังก์ชัน: [ลายเซ็น]"
ข้อควรระวัง: ความครอบคลุมการทดสอบสูง (เช่น 90%) ไม่ได้พิสูจน์ว่ารหัสนั้นถูกต้อง ความครอบคลุมจะวัดจำนวนแถวที่ถูกดำเนินการ ไม่ใช่ว่าเส้นเหล่านั้นให้ผลลัพธ์ที่ถูกต้อง การทดสอบที่ไม่มีการยืนยันที่มีความหมายจะเพิ่มความครอบคลุมแต่ไม่ได้รับประกันอะไรเลย เนื้อหาของการยืนยันจะกำหนดคุณภาพ ไม่ใช่จำนวนการยืนยัน
การทดสอบการทดสอบตัวเอง: ตรรกะของการกลายพันธุ์
วิธีที่เป็นประโยชน์มากที่สุดในการทำความเข้าใจว่าการทดสอบที่สร้างโดย AI ใช้งานได้จริงหรือไม่คือจงใจทำลายโค้ด (ตรรกะการทดสอบการกลายพันธุ์) กลับเงื่อนไข ให้เครื่องหมาย + -; หากไม่มีการทดสอบใดเปลี่ยนเป็นสีแดง แสดงว่าการทดสอบของคุณไม่ได้รักษาพฤติกรรมนั้นไว้
พร้อมท์การทดสอบช่องโหว่: "บอกฉันว่าการทดสอบต่อไปนี้อาจตรวจไม่พบจุดบกพร่องที่อาจเกิดขึ้นในโค้ดนี้ แนะนำการเปลี่ยนแปลงเล็กๆ น้อยๆ 5 แบบที่สามารถทำได้กับโค้ด (เช่น >= แทน >, - แทน +) และระบุว่าการทดสอบที่มีอยู่จะตรวจจับได้หรือไม่ สำหรับผู้ที่ตรวจไม่พบ แนะนำการทดสอบที่ควรเพิ่ม รหัส: [รหัส] การทดสอบ: [ทดสอบ]"
พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง
อ่อนแอ: "เขียนการทดสอบฟังก์ชันนี้" (ผลลัพธ์: มักจะเป็นสถานการณ์ที่มีความสุข การยืนยันที่ไม่รัดกุม พลาดข้อผิดพลาด) แข็งแกร่ง: "เขียนการทดสอบไปยังฟังก์ชัน 'passwordStrong' นี้ กฎ: อย่างน้อย 8 ตัวอักษร ตัวพิมพ์ใหญ่ 1 ตัว ต้องมี 1 หลัก ครอบคลุมสถานการณ์ต่อไปนี้เป็นการทดสอบแยก: 8 ตัวอักษรพอดี (จำกัด), 7 ตัวอักษร (ต่ำกว่าขีดจำกัด), ไม่มีตัวอักษรตัวพิมพ์ใหญ่, ไม่มีตัวเลข, สตริงว่าง, ช่องว่างเท่านั้น, ยาวเกินไป (1,000 ตัวอักษร) ยืนยันอย่างชัดเจน ค่าจริง/เท็จที่คาดหวังในการทดสอบแต่ละครั้ง และตั้งชื่อการทดสอบตามสิ่งที่ตรวจสอบ"
พร้อมท์ที่มีประสิทธิภาพให้กฎและสถานการณ์ขอบเขตเต็ม คู่ขอบเขต เช่น "อักขระ 8/7 พอดี" เป็นจุดที่มักเกิดข้อผิดพลาด (สับสน > กับ >=) พร้อมท์ที่อ่อนแอจะข้ามขอบเขตเหล่านี้ และนำข้อผิดพลาดไปสู่การใช้งานจริง
ประเภทการทดสอบและสถานที่ที่จะใช้
ประเภทการทดสอบ
มันยืนยันอะไร?
การมีส่วนร่วมของ AI
ความสนใจ
หน่วย
ฟังก์ชั่นเดียว/คลาส
สร้างหลายสถานการณ์อย่างรวดเร็ว
จำเป็นต้องมีการยืนยันที่มีความหมาย
บูรณาการ
ชิ้นส่วนที่ทำงานร่วมกัน
สถานการณ์จำลองและร่างข้อมูลจำลอง
พฤติกรรมเสพติดที่แท้จริง
สิ้นสุด/ยอมรับ
โฟลว์ผู้ใช้ทั้งหมด
รายการขั้นตอนและความคาดหวัง
มีแนวโน้มที่จะเปราะบาง
การถดถอย
ข้อผิดพลาดเก่าไม่ส่งคืน
การทดสอบเฉพาะข้อผิดพลาด
ควรเพิ่มการแก้ไขทุกครั้ง
เคสมินิ
กรณีที่ 1 — การทดสอบที่ผ่านเสมอ AI เขียนการทดสอบ 12 รายการไปยังฟังก์ชันหนึ่งๆ และการทดสอบทั้งหมดก็ผ่าน วิศวกรเกิดความสงสัยและจงใจบิดเบือนค่าที่ส่งคืนของฟังก์ชัน การทดสอบเพียง 3 รายการเท่านั้นที่เปลี่ยนเป็นสีแดง การทดสอบอีก 9 รายการไม่มีการยืนยันที่มีความหมาย การทดสอบมีความเข้มแข็งขึ้นโดยการตามล่าการกลายพันธุ์ ความคุ้มครองที่แท้จริงได้รับใน 9 สถานการณ์
กรณีที่ 2 — ข้อผิดพลาดขอบเขต ฟังก์ชันการตรวจสอบอายุควรระบุว่า "18 ปีขึ้นไปถูกต้อง" แต่เขียนว่า >18 ซึ่งหมายความว่าอายุ 18 ปีจะถูกปฏิเสธ ข้อผิดพลาดปรากฏขึ้นทันทีในการทดสอบ เนื่องจาก AI สร้างสถานการณ์ "18 พอดี" ผ่านการวิเคราะห์เบรกพอยต์ การทดสอบขีดจำกัดเพียงครั้งเดียวจะป้องกันการร้องเรียนจากผู้ใช้จริง
กรณีที่ 3 — แก้ไขพฤติกรรมปัจจุบัน เมื่อ AI ได้รับคำสั่งให้ "เขียนการทดสอบโดยใช้โค้ดนี้" จะสร้างการทดสอบที่ยอมรับว่า "ถูกต้อง" ข้อผิดพลาดในการปัดเศษที่มีอยู่ในโค้ดแล้ว เมื่อวิศวกรพิมพ์การทดสอบตามความต้องการ (ค่าที่คาดไว้ถูกต้อง) ไม่ใช่รหัส การทดสอบจะเปลี่ยนเป็นสีแดงและเกิดข้อผิดพลาดจริง การทดสอบควรมาจากความคาดหวัง ไม่ใช่จากโค้ด
ข้อผิดพลาดทั่วไป
- ยืนยันอย่างไม่มีจุดหมาย "ไม่ได้โยนข้อผิดพลาด" ยังไม่เพียงพอ ต้องตรวจสอบค่าที่ถูกต้อง
- ขอบเขตที่สับสนกับคุณภาพ การครอบคลุมที่สูงไม่ได้รับประกันผลลัพธ์ที่แม่นยำ
- การพิมพ์การทดสอบด้วยรหัส แก้ไขข้อผิดพลาดปัจจุบันเป็น "จริง"; การทดสอบควรมาจากความคาดหวัง
- ข้ามค่าขีดจำกัด การสับสน > ด้วย >= เป็นข้อผิดพลาดที่พบบ่อยที่สุด จะต้องทดสอบคู่ขอบเขต
- ไม่ได้ตรวจสอบการทดสอบเอง การทดสอบที่ไม่เปลี่ยนเป็นสีแดงเมื่อคุณทำลายโค้ดไม่ได้ให้การป้องกัน
โดยสรุป
ชุดการทดสอบที่ดีคือกุญแจสำคัญในการเปลี่ยนแปลงอย่างมั่นใจ AI สร้างสถานการณ์ ขอบเขต และสถานการณ์เชิงลบมากมายอย่างรวดเร็ว แต่หากได้รับการทดสอบจากโค้ดแทนที่จะเป็นข้อกำหนด ก็สามารถแก้ไขข้อบกพร่องที่มีอยู่หรือเขียนการทดสอบที่ไม่มีความหมายซึ่งผ่านเสมอได้ ยืนยันค่าคาดหวังที่เป็นรูปธรรมในการทดสอบแต่ละครั้ง รวมคู่ที่ถูกผูกไว้ และตรวจสอบว่าการทดสอบของคุณป้องกันได้จริงโดยจงใจทำลายโค้ด เนื้อหาของการยืนยัน ไม่ใช่จำนวนขอบเขต เป็นตัวกำหนดคุณภาพ
งานสมัคร
เลือกฟังก์ชันและให้สร้างการทดสอบในสี่หมวดหมู่ (ปกติ, ขีดจำกัด, ลบ, ข้อผิดพลาด) พร้อมพร้อมท์การสร้างการทดสอบที่ครอบคลุม ยืนยันค่าคาดหวังที่เป็นรูปธรรมในการทดสอบแต่ละครั้ง จากนั้นเรียกใช้พรอมต์การค้นหาช่องโหว่การทดสอบ แนะนำการเปลี่ยนแปลงเล็กๆ น้อยๆ 5 รายการในโค้ด และเรียกใช้การทดสอบเพื่อตรวจสอบว่าการเปลี่ยนแปลงใดที่จับได้ เพิ่มการทดสอบใหม่สำหรับการกลายพันธุ์อย่างน้อยหนึ่งรายการที่ตรวจไม่พบ และแสดงว่าขณะนี้เปลี่ยนเป็นสีแดง
รายการตรวจสอบ
- [ ] ฉันพิมพ์การทดสอบตามพฤติกรรมที่คาดหวัง/ถูกต้อง ไม่ใช่โค้ด
- [ ] ฉันครอบคลุมสถานการณ์ปกติ ขีดจำกัด เชิงลบ และข้อผิดพลาด
- [ ] ฉันยืนยันค่าคาดหวังที่เป็นรูปธรรมในการทดสอบแต่ละครั้ง
- [ ] ฉันทดสอบคู่เส้นขอบ (เหนือ-ล่าง / เหนือ-ล่าง)
- [ ] โดยเจตนาทำลายรหัส ฉันยืนยันว่าการทดสอบกลายเป็นสีแดง
- [ ] ฉันได้เพิ่มการทดสอบใหม่สำหรับการกลายพันธุ์ที่ตรวจไม่พบ