กำไร:
- ความสามารถในการจดจำใบหน้าทั้งสามของความไว้วางใจหลอก (ไม่แสดงออก มั่นใจในตนเอง ยืนยันเล็กน้อย) และใช้ยาแก้พิษ
- ความสามารถในการใช้การทดสอบการกลายพันธุ์และคะแนนการกลายพันธุ์ในการวัดคุณภาพที่แม่นยำมากกว่าเปอร์เซ็นต์ความครอบคลุมด้วยเครื่องมือหรือมือ
- ความสามารถในการวางตำแหน่ง AI ให้เป็นทีมสีแดงที่ต่อต้านการทดสอบและตามล่าหาช่องโหว่ในการทดสอบโดยไม่ตกหลุมพราง
หัวใจของโมดูลนี้คือคำเตือนที่เกิดซ้ำ: แผงทดสอบที่เรืองแสงสีเขียวไม่ใช่หลักฐานยืนยันคุณภาพ หากการทดสอบของคุณทำให้คุณมั่นใจ คุณจำเป็นต้องรู้ว่าความมั่นใจนั้นเป็นเรื่องจริงหรือของปลอม ในยุคของปัญญาประดิษฐ์ (AI) คำถามนี้มีความสำคัญมากกว่าที่เคย เนื่องจาก AI เชี่ยวชาญในการสร้างการทดสอบที่ลื่นไหล ดูราบรื่น แต่กลวง ความมั่นใจที่ผิดพลาด — การเชื่อว่าซอฟต์แวร์นั้นถูกต้องเพราะการทดสอบเป็นสีเขียว แต่จริงๆ แล้วการทดสอบไม่ได้ตรวจสอบสิ่งใดเลย — เป็นสิ่งที่อันตรายที่สุดที่สามารถเกิดขึ้นได้กับทีม QA เพราะมันไม่ได้ซ่อนไว้ว่าไม่มีข้อผิดพลาด แต่คุณไม่สามารถมองเห็นข้อผิดพลาดได้ หน่วยนี้รวบรวมปรัชญาการตรวจสอบความถูกต้องของโมดูลทั้งหมดไว้ในระเบียบวินัยเดียว: การทดสอบการทดสอบของคุณ
มาตรฐานทองคำสำหรับการวัดคุณภาพการทดสอบ: การทดสอบการกลายพันธุ์
วิธีที่ทรงพลังที่สุดในการทำความเข้าใจว่าการทดสอบป้องกันได้จริงหรือไม่คือการทดสอบการกลายพันธุ์ (การทดสอบการกลายพันธุ์ - เทคนิคที่สร้างการบิดเบือน/การกลายพันธุ์เล็กน้อยโดยเจตนาในซอร์สโค้ด และวัดว่าการทดสอบตรวจจับการบิดเบือนเหล่านี้หรือไม่) ตรรกะนั้นง่ายมาก: หากคุณจงใจทำลายโค้ด (ทำให้ + เป็น -, a > เป็น >=, จริงเป็นเท็จ) ชุดทดสอบที่ดีควรตรวจจับความเสียหายนั้นและเปลี่ยนเป็นสีแดง หากไม่เป็นเช่นนั้น การหยุดชะงักนั้นจะเป็นการกลายพันธุ์ที่รอดชีวิต ดังนั้นการทดสอบของคุณจึงไม่รักษาพฤติกรรมนั้นไว้
คะแนนการกลายพันธุ์ = การกลายพันธุ์ที่ถูกฆ่า / การกลายพันธุ์ทั้งหมด แพ็คเกจที่มีความครอบคลุมของสาย 90% อาจมีคะแนนการกลายพันธุ์ที่ 40% สิ่งนี้บ่งชี้ว่าบรรทัดกำลังทำงานแต่พฤติกรรมยังไม่ได้รับการตรวจสอบ คะแนนการกลายพันธุ์เป็นตัววัดคุณภาพที่ตรงไปตรงมามากกว่าเปอร์เซ็นต์ความครอบคลุม
เคล็ดลับ: มีเครื่องมือการกลายพันธุ์อัตโนมัติ (PIT/Pitest สำหรับ Java, Stryker สำหรับ JavaScript/TypeScript, Stryker.NET สำหรับ .NET, mutmut สำหรับ Python) สิ่งเหล่านี้จะสร้างและทดสอบการกลายพันธุ์นับร้อยโดยอัตโนมัติ หากคุณไม่มีเครื่องมือ แม้แต่วิธี "break the code test" ด้วยตนเองก็มีประโยชน์อย่างมากสำหรับฟังก์ชันที่สำคัญ
ใบหน้าทั้งสามของความไว้วางใจหลอกและยาแก้พิษ
แบบฟอร์มหลอกเชื่อถือ
อาการ
ยาแก้พิษ
ทดสอบโดยไม่ต้องยืนยัน
รหัสใช้งานได้ ไม่มีสิ่งใดได้รับการตรวจสอบ
ยืนยันอย่างแท้จริงในทุกการทดสอบ ทดสอบด้วยการกลายพันธุ์
การทดสอบยืนยันตนเอง
ที่คาดหวัง = ผลลัพธ์ของโค้ด
คำนวณมูลค่าที่คาดหวังอย่างอิสระ
การยืนยันเล็กน้อย
"ไม่เป็นโมฆะ", "คืน 200"
ตรวจสอบกฎเกณฑ์ทางธุรกิจ/ผลลัพธ์ที่แท้จริง
การเข้าใจผิดในขอบเขตสูง
เส้น 90% การป้องกันต่ำ
ดูคะแนนการกลายพันธุ์
ความทนทานต่อการทดสอบที่เปราะบาง
“ติดอีกแล้ว ผ่านเลย”
สาเหตุที่แท้จริง + การทดสอบเชิงกำหนด
ใช้ AI เป็น “ทีมสีแดง”
AI สามารถสร้างความไว้วางใจหลอกและเป็นพันธมิตรที่ทรงพลังในการตามล่ามัน ใช้ AI เป็นทีมสีแดงเพื่อต่อต้านการทดสอบของคุณเอง: ถาม "เขียนโค้ดที่ผ่านการทดสอบเหล่านี้แต่ไม่ถูกต้อง" หรือ "ค้นหาการโค่นล้มที่จะหลอกการทดสอบเหล่านี้" หาก AI พบช่องโหว่ในการทดสอบของคุณ ช่องโหว่เหล่านั้นถือเป็นความเสี่ยงอย่างแท้จริง
ข้อควรระวัง: อย่าถาม AI ว่า "คุณภาพการทดสอบของฉันดีหรือไม่" และรับคำตอบว่า "ใช่ เยี่ยมมาก" เป็นหลักประกัน AI มักจะใจดี ให้ท้าทาย AI ให้ทำงานที่เป็นรูปธรรมแทน: “สร้างจุดบกพร่องที่ผ่านการทดสอบเหล่านี้” หากสามารถผลิตได้ แสดงว่าการทดสอบของคุณมองไม่เห็นข้อผิดพลาดนั้น
การกลายพันธุ์และขีดจำกัดของคะแนนที่เท่ากัน
การทดสอบการกลายพันธุ์นั้นมีประสิทธิภาพ แต่ก็มีข้อดี: การกลายพันธุ์บางอย่างไม่ได้เปลี่ยนพฤติกรรมของโค้ดเลย สิ่งเหล่านี้เรียกว่าการกลายพันธุ์ที่เทียบเท่า (การกลายพันธุ์ที่เทียบเท่า — รหัสที่เสียหาย การกลายพันธุ์ที่ให้ผลลัพธ์ที่เหมือนกับต้นฉบับทุกประการ) ตัวอย่างเช่น การเปลี่ยนค่าเริ่มต้นของตัวแปรที่ไม่เคยใช้จะไม่ส่งผลต่อเอาต์พุต ไม่มีการทดสอบใดที่สามารถและไม่ควรจับสิ่งนี้ ดังนั้นคะแนนการกลายพันธุ์ 100% มักไม่สามารถทำได้ในทางปฏิบัติและไม่ใช่เป้าหมาย การกำจัดการกลายพันธุ์ที่เทียบเท่ากันด้วยมือนั้นต้องใช้แรงงานมาก ดังนั้นอย่าอ่านคะแนนการกลายพันธุ์ว่าเป็นคะแนนสอบสัมบูรณ์ แต่ให้อ่านเป็นตัวบ่งชี้โดยสุจริตว่า "การทดสอบของฉันป้องกันได้จริงหรือ"
แนวทางการปฏิบัติคือ: แทนที่จะรันการทดสอบการกลายพันธุ์อย่างต่อเนื่องทั่วทั้งฐานโค้ดทั้งหมด ให้รันบนโมดูลที่มีความเสี่ยงสูงสุดและกฎเกณฑ์ทางธุรกิจที่ซับซ้อนที่สุด ตรวจสอบการกลายพันธุ์ที่ยังมีชีวิตรอดในโมดูลเหล่านี้ทีละตัว หากเป็นช่องว่างจริง ให้ทำการทดสอบเพิ่มเติม หากเป็นการกลายพันธุ์ที่เทียบเท่า ให้ทำเครื่องหมายด้วยการให้เหตุผลและผ่าน AI สามารถทำการตรวจคัดกรองเบื้องต้นเพื่อประเมินว่าการกลายพันธุ์ที่รอดชีวิตนั้นเทียบเท่ากันหรือไม่ แต่การตัดสินใจขั้นสุดท้ายนั้นทำโดยคุณที่รู้ว่าโค้ดทำอะไร
ข้อควรระวัง: การทดสอบการกลายพันธุ์มีราคาแพงในการคำนวณ (การทดสอบที่เกี่ยวข้องทั้งหมดจะดำเนินการซ้ำสำหรับการกลายพันธุ์แต่ละครั้ง) ดังนั้นกลยุทธ์ทั่วไปและสมเหตุสมผลคือกำหนดเวลาให้เป็นการตรวจสอบเชิงลึกรายสัปดาห์หรือก่อนเผยแพร่สำหรับโมดูลที่สำคัญ แทนที่จะรวมทุก ๆ ครั้ง
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
อ่อนแอ: "การทดสอบของฉันเพียงพอแล้วหรือยัง?"
Strong: "ทำหน้าที่เป็นทีมสีแดงสำหรับฟังก์ชันและชุดการทดสอบนี้ (1) สร้างการกลายพันธุ์ 8 ครั้งในโค้ดที่สามารถฆ่าได้ (การทดแทนตัวดำเนินการ, การเปลี่ยนขอบเขต, การผกผันเงื่อนไข, การทดแทนค่าส่งคืน) (2) สำหรับการกลายพันธุ์แต่ละครั้ง ให้ระบุว่าการทดสอบใดที่มีอยู่จะตรวจจับได้และการทดสอบใดจะไม่ (3) สำหรับการกลายพันธุ์แต่ละครั้งที่ยังมีชีวิตอยู่ ให้เขียนการทดสอบใหม่ที่จะฆ่ามัน (4) แสดงด้วยว่าคุณสามารถสร้างตัวอย่างโค้ดที่ผ่านการทดสอบทั้งหมดเหล่านี้แต่ละเมิดธุรกิจหรือไม่ กฎรหัส + การทดสอบ: [วาง]"
พรอมต์อันทรงพลัง; โดยวางตำแหน่ง AI ให้เป็นผู้ทดสอบที่ฝ่าฝืน ไม่ใช่เครื่องยกย่อง
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การควบคุมการกลายพันธุ์ด้วยตนเอง:
สร้างการกลายพันธุ์ที่มีนัยสำคัญ 8 แบบ (การหยุดชะงักโดยเจตนาเล็กน้อย) สำหรับโค้ดนี้: การแทนที่ตัวดำเนินการทางคณิตศาสตร์, ขีดจำกัดการเปรียบเทียบ (> vs >=), การผกผันเชิงตรรกะ, การทดแทนแบบส่งคืน/ค่าคงที่, การข้ามเงื่อนไข สำหรับการกลายพันธุ์แต่ละครั้ง ให้ทายว่าการทดสอบใดที่มีอยู่จะตรวจจับการกลายพันธุ์นั้นได้ รหัส + การทดสอบ: [วาง]
2) การฆ่าการกลายพันธุ์ที่ยังมีชีวิตอยู่:
รายงานการทดสอบการกลายพันธุ์ต่อไปนี้ประกอบด้วยการกลายพันธุ์ที่ยังมีชีวิตอยู่ (ไม่ได้ตรวจพบ): [รายการ/รายงาน] สำหรับแต่ละกรณี ให้เขียนการทดสอบขั้นต่ำที่จะฆ่าการกลายพันธุ์นั้น (โค้ดจะเปลี่ยนเป็นสีแดงเมื่อใช้งานไม่ได้ในลักษณะนั้น) แสดงความคิดเห็นเกี่ยวกับพฤติกรรมที่การทดสอบยืนยัน
3) ทีมสีแดง — การทดสอบเลือด:
คุณสามารถเขียนโค้ดที่ผ่านการทดสอบต่อไปนี้ทั้งหมด แต่ละเมิดกฎเกณฑ์ทางธุรกิจต่อไปนี้: [กฎเกณฑ์ทางธุรกิจ] หากเป็นเช่นนั้น ช่องโหว่อะไรในการทดสอบเหล่านี้ที่เอื้ออำนวยต่อสิ่งนี้ เพิ่มการทดสอบที่จะปิดช่องโหว่นั้น การทดสอบ: [วาง]
4) การตรวจสอบคุณภาพการทดสอบ:
ตรวจสอบคุณภาพชุดทดสอบนี้ ทำเครื่องหมายสำหรับการทดสอบแต่ละรายการ:- มีการยืนยันจริงหรือเป็นเพียงอุปกรณ์ประกอบฉาก?- ค่าที่คาดหวังเป็นอิสระจากโค้ดหรือไม่- มันตรวจสอบกฎเกณฑ์ทางธุรกิจหรืออะไรเล็กน้อยหรือไม่? สุดท้ายให้ประมาณ "คะแนนยืนยันจริง" และการทดสอบที่อ่อนแอที่สุด 3 รายการ การทดสอบ: [วาง]
มินิเคสสามอัน
กรณีที่ 1 — ครอบคลุม 92% คะแนนการกลายพันธุ์ 38% ทีมหนึ่งอาศัยความครอบคลุมสูง เมื่อทำการทดสอบการกลายพันธุ์ด้วยสไตรเกอร์ คะแนนคือ 38% การกลายพันธุ์ส่วนใหญ่ที่รอดชีวิตมาได้ นี่เป็นข้อพิสูจน์ว่าการทดสอบไม่ได้ดำเนินไปและตรวจสอบพฤติกรรม ทีมงานใช้เวลาสามสัปดาห์ในการทดสอบคุณภาพ คะแนนการกลายพันธุ์เพิ่มขึ้นเป็น 81% และข้อผิดพลาดในการคำนวณจริง 2 รายการถูกพบโดยการทดสอบที่ปรับปรุงเพิ่มเติมเหล่านี้ในรุ่นถัดไป
กรณีที่ 2 — AI หลอกการทดสอบ ด้วยเทมเพลต "ทีมสีแดง" ผู้เชี่ยวชาญขอรหัสที่ผ่านการทดสอบที่มีอยู่จาก AI แต่ละเมิดกฎส่วนลด AI เขียนโค้ดที่ส่งคืนส่วนลดเป็นศูนย์เสมอ และการทดสอบทั้งหมดยังคงเป็นสีเขียวเนื่องจากไม่มีการทดสอบใดที่ตรวจสอบมูลค่าส่วนลดจริงได้ เห็นช่องว่าง เพิ่มการยืนยันจริงแล้ว
กรณีที่ 3 — กับดักแห่งการสรรเสริญ ผู้ทดสอบรุ่นเยาว์ถาม AI ว่า "การทดสอบของฉันดีหรือไม่" และโล่งใจเมื่อได้ยินคำตอบว่า "ครอบคลุมมาก" เพื่อนร่วมงานอาวุโสของเขาได้รับการทดสอบแบบเดียวกันที่ได้รับการตรวจสอบโดยใช้เทมเพลต "การตรวจสอบคุณภาพการทดสอบ" ปรากฎว่าการทดสอบ 12 จาก 20 รายการเป็นการตกแต่ง (โดยไม่มีการยืนยันหรือขยะ) คำถามที่ถูกต้องนำมาซึ่งคำตอบที่ถูกต้อง
ข้อผิดพลาดทั่วไป
- ขอบเขตที่ผิดพลาดสำหรับคุณภาพ อาศัยการครอบคลุมแถวสูงและไม่ดูคะแนนการกลายพันธุ์เลย
- ไว้วางใจคำชมของ AI ถามว่า "การทดสอบของคุณดีไหม?" และพิจารณาคำตอบเชิงบวกเป็นหลักประกัน
- รับค่าที่คาดหวังจากโค้ด การทดสอบการตรวจสอบตัวเองที่ยืนยันรหัสที่ผิดพลาด
- จงพอใจกับคำกล่าวอ้างเล็กๆ น้อยๆ เช็คที่ไม่ตรวจสอบกฎจริง เช่น "ไม่เป็นโมฆะ" "ส่งคืน 200"
- ไม่สนใจการกลายพันธุ์ที่ยังมีชีวิตรอด เพิกเฉยต่อสิ่งที่ไม่พบในรายงานการกลายพันธุ์
- ไม่ได้พยายามแปลงรหัสสำคัญด้วยตนเองด้วยซ้ำ ข้ามขั้นตอน "ทำลายโค้ดและทดสอบ" หากไม่มีเครื่องมือ
โดยสรุป
Pseudo-trust เชื่อว่าซอฟต์แวร์ถูกต้องเนื่องจากการทดสอบเป็นสีเขียว ในขณะที่การทดสอบไม่อาจยืนยันอะไรได้ มาตรฐานทองคำสำหรับการวัดสิ่งนี้คือการทดสอบการกลายพันธุ์: จงใจทำลายโค้ดและวัดว่าการทดสอบจับได้หรือไม่ คะแนนการกลายพันธุ์เป็นตัววัดคุณภาพที่ตรงไปตรงมามากกว่าเปอร์เซ็นต์ความครอบคลุม AI ทั้งคู่สร้างความไว้วางใจหลอกและกลายเป็นทีมสีแดงที่ทรงพลังในการตามล่ามัน — ขอให้ “สร้างจุดบกพร่องที่ผ่านการทดสอบเหล่านี้” ทดสอบการทดสอบของคุณ: การยืนยันที่แท้จริง ค่าคาดหวังที่เป็นอิสระ การตรวจสอบกฎเกณฑ์ทางธุรกิจ และการกลายพันธุ์ที่ถูกฆ่า
งานสมัคร
นำเข้าฟังก์ชันที่มีกฎเกณฑ์ทางธุรกิจและการทดสอบจากโครงการของคุณเอง หากเป็นไปได้ ให้เรียกใช้เครื่องมือการกลายพันธุ์ (Stryker/Pitest/mutmut) และวัดคะแนนการกลายพันธุ์ หากไม่มีเครื่องมือ ให้สร้างการกลายพันธุ์อย่างน้อย 8 รายการด้วยเทมเพลต "การควบคุมการกลายพันธุ์แบบแมนนวล" แล้วลองด้วยตนเอง สำหรับการกลายพันธุ์ที่รอดตายแต่ละครั้ง ให้เขียนการทดสอบใหม่ด้วยเทมเพลต "การฆ่าการกลายพันธุ์ที่รอดชีวิต" สุดท้ายด้วยรูปแบบ “ทีมสีแดง” ดูว่า AI สามารถสร้างโค้ดที่หลอกการทดสอบของคุณได้หรือไม่ รายงานคะแนนการกลายพันธุ์เริ่มต้นและสิ้นสุดของคุณ (หรือที่จับได้/อัตราการกลายพันธุ์ทั้งหมด)
รายการตรวจสอบ
- [ ] ฉันประเมินคุณภาพการทดสอบด้วยคะแนนการกลายพันธุ์ ไม่ใช่ความครอบคลุม
- [ ] ฉันทำการทดสอบการกลายพันธุ์ (ไม่ว่าจะด้วยเครื่องมือหรือด้วยตนเอง) สำหรับโค้ดที่สำคัญ
- [ ] ฉันเขียนการทดสอบใหม่สำหรับการกลายพันธุ์ที่รอดมาแต่ละครั้ง
- [ ] ฉันใช้ AI เป็นทีมสีแดงและค้นหาช่องโหว่ในการทดสอบ
- [ ] ฉันไม่ได้ถือว่าคำชม "การทดสอบของคุณดี" ของ AI เป็นความมั่นใจ
- [ ] ฉันตรวจสอบว่าการทดสอบแต่ละครั้งยืนยันการยืนยันจริง ค่าคาดหวังที่เป็นอิสระ และกฎเกณฑ์ทางธุรกิจ