ทดสอบการผลิตและการประกันคุณภาพ

กำไร:

• ความสามารถในการสร้างการทดสอบหน่วย กรณี Edge และการวิเคราะห์ช่องว่างความครอบคลุมด้วย AI
• ความสามารถในการพิมพ์ความคาดหวังของการทดสอบตามข้อกำหนด ไม่ใช่พฤติกรรมปัจจุบันของโค้ด
• ความสามารถในการทดสอบว่าการทดสอบป้องกันโดยการฉีดข้อผิดพลาดจริงหรือไม่

การทดสอบการเขียนเป็นหนึ่งในงานที่สร้างมูลค่ามากที่สุดที่นักพัฒนาส่วนใหญ่เลื่อนออกไป ชุดทดสอบที่ดีเป็นการพิสูจน์ว่าโค้ดทำงานได้ตามที่คาดหวังและเป็นเส้นชีวิตสำหรับการเปลี่ยนแปลงในอนาคต ปัญหาคือการทดสอบการเขียนนั้นซ้ำซากและใช้เวลานาน ซึ่งเป็นงานที่ AI โดดเด่นอย่างแน่นอน แต่มีข้อเสียคือ AI มักจะทดสอบพฤติกรรมที่มีอยู่ของโค้ด ไม่ใช่พฤติกรรมที่ควรจะเป็น การจัดการความแตกต่างนี้คือสาระสำคัญของหน่วยนี้

ในหน่วยการเรียนรู้นี้ คุณจะได้เรียนรู้การทดสอบหน่วย (การทดสอบที่ทดสอบฟังก์ชันเพียงอย่างเดียว แบบแยกส่วน) การทดสอบ Edge Case และการสร้างข้อมูลการทดสอบด้วย AI ปิดช่องว่างในความครอบคลุมของการทดสอบ และเหตุใดการเชื่อถือการทดสอบ AI แบบสุ่มสี่สุ่มห้าจึงเป็นอันตราย

การทดสอบสองด้าน: พฤติกรรมการแก้ไขกับการตรวจสอบ

การทดสอบสามารถตอบสนองวัตถุประสงค์ที่แตกต่างกันสองประการ สิ่งแรกคือการตรวจสอบ: จะทดสอบว่ารหัสถูกต้องและเป็นไปตามข้อกำหนด ประการที่สองคือการป้องกันการถดถอย: มันจะหยุดพฤติกรรมของโค้ดในวันนี้ ดังนั้นหากมีใครเปลี่ยนมันโดยไม่ตั้งใจในวันพรุ่งนี้ การทดสอบจะเสียหายและแจ้งให้ทราบ

AI ดีมากในช่วงหลัง มันจะดูโค้ดและสร้างเคสที่ทดสอบ "สิ่งที่กำลังทำอยู่ตอนนี้" แต่หากรหัสผิดตั้งแต่เริ่มต้น AI ก็สามารถปักหมุดพฤติกรรมที่ไม่ถูกต้องนั้นว่า “ถูกต้อง” ได้ ดังนั้นคุณต้องตรวจสอบการยืนยันการทดสอบแต่ละครั้งที่ AI สร้างขึ้น: "โค้ดส่งคืน 42 และการทดสอบคาดหวัง 42" ไม่ได้หมายความว่า 42 เป็นคำตอบที่ถูกต้อง

ข้อควรระวัง: หาก AI ผ่านการทดสอบ ไม่ได้หมายความว่าโค้ด "ใช้งานได้" มันแค่หมายความว่า "มันทำงานตามที่ AI คาดหวัง" คุณตัดสินใจว่าความคาดหวังนั้นถูกต้องหรือไม่โดยดูที่ข้อกำหนด

ทีละขั้นตอน: การเขียนการทดสอบที่แข็งแกร่งด้วย AI

1. ระบุข้อกำหนด ไม่ใช่แค่โค้ด หากคุณเพิ่มข้อมูล "ฟังก์ชันนี้ควรทำ" AI จะสามารถเขียนความคาดหวังที่ถูกต้องได้ มันจะทดสอบพฤติกรรมปัจจุบันหากคุณเพียงแค่ระบุรหัส
2. ขอเคสขอบ. ว่างเปล่า, เป็นโมฆะ, เป็นศูนย์, ลบ, ใหญ่เกินไป, รูปแบบไม่ดี, เกิดขึ้นพร้อมกัน — อ้างสิทธิ์ในเส้นทางแห่งความสุขอย่างชัดเจน
3. ระบุกรอบการทดสอบและรูปแบบ "use pytest", "Arrange-Act-Assert pattern", "ให้แต่ละการทดสอบทดสอบสิ่งเดียว" ฯลฯ
4. ตรวจสอบความคาดหวัง (การยืนยัน) เปรียบเทียบกับข้อกำหนดที่แต่ละ assert ตรวจสอบค่าที่ถูกต้อง
5. ปิดช่องว่างในขอบเขต ทำการทดสอบที่มีอยู่แล้วถามว่า "สาขาและกรณีใดบ้างที่ยังไม่ได้รับการทดสอบ" ทำให้คุณถาม; จากนั้นตรวจสอบการทดสอบเพิ่มเติมที่เกิดขึ้น

มินิเคสสามอัน

กรณีที่ 1 — ความคุ้มครองตั้งแต่ 52% ถึง 85% ความครอบคลุมการทดสอบของโมดูลบริการหนึ่งโมดูลคือ 52% ทีมงานป้อนการทดสอบที่มีอยู่ให้กับ AI จัดทำรายการสาขาที่ยังไม่ทดสอบ และสร้างการทดสอบสำหรับพวกเขา ด้วยการตรวจสอบโดยเจ้าหน้าที่ ความครอบคลุมเพิ่มขึ้นเป็น 85%; ในกระบวนการนี้ AI ได้ค้นพบจุดบกพร่องที่เกิดขึ้นจริง (เส้นทางที่ส่งคืนรหัสข้อผิดพลาดที่ไม่ถูกต้อง) ในสาขาจุดบกพร่องที่ไม่เคยมีการทดสอบมาก่อน

กรณีที่ 2 — กับดักการตรึงความคาดหวังที่ผิดพลาด จริงๆ แล้วฟังก์ชันการปัดเศษเงินนั้นผิด แทนที่จะปัดเศษ 2.675 เป็น 2.67 กลับปัดเศษ 2.67 แทนที่จะเป็น 2.68 AI ดูโค้ดแล้วเขียน assert round_money(2.675) == 2.67 — หยุดข้อผิดพลาดเป็น “จริง” เมื่อนักพัฒนาอ่านข้อกำหนด เขาก็แก้ไขความคาดหวังและพบจุดบกพร่องที่แท้จริง การทดสอบกฎ ไม่ใช่โค้ด ทำให้เกิดความแตกต่าง

กรณีที่ 3 — การระเบิดของสถานะ Edge เมื่อถาม AI เฉพาะ “กรณีขอบ” สำหรับฟังก์ชันช่วงวันที่ โดยสร้างกรณี 8 กรณี เช่น start=end, Reverse Interval, ปีอธิกสุรทินวันที่ 29 กุมภาพันธ์, โซนเวลาที่ต่างกัน และช่วงเวลาว่าง สองสิ่งนี้ (การเว้นวรรคย้อนกลับและปีอธิกสุรทิน) เป็นสาเหตุให้เกิดข้อผิดพลาดจริงๆ การพิจารณากรณีเหล่านี้ด้วยตนเองมักถูกข้ามไป AI กลายเป็นพันธมิตร "การระดมความคิดแบบ edge-case" ที่นี่

เทมเพลตที่คัดลอกได้สี่แบบ

การสร้างการทดสอบตามข้อกำหนด:

บทบาท: นักพัฒนาที่เขียนการทดสอบ กรอบงาน: {{pytest/JUnit/Jest...}} สิ่งที่ฟังก์ชันควรทำ (ข้อกำหนด): {{rule}}เขียนการทดสอบสำหรับฟังก์ชันต่อไปนี้ เขียนความคาดหวังตามข้อกำหนด ไม่ใช่ผลลัพธ์ปัจจุบันของโค้ด เส้นทางแห่งความสุข + เพิ่มเคสขอบอย่างน้อย 4 อัน ให้แต่ละการทดสอบทดสอบสิ่งหนึ่ง ใช้ชื่อที่สื่อความหมาย {{ฟังก์ชั่น}}

การระดมความคิดกรณี Edge:

แสดงรายการกรณี Edge/ความล้มเหลวที่ควรลองใช้ในการทดสอบฟังก์ชันนี้ (ค่าว่าง ค่าว่าง จุดพัก รูปแบบที่ไม่ถูกต้อง การเกิดขึ้นพร้อมกัน ข้อผิดพลาดภายนอก) สำหรับแต่ละกรณี: อินพุต ลักษณะการทำงานที่คาดไว้ อย่าเพิ่งเขียนโค้ด แค่เขียนรายการเท่านั้น{{function}}

การวิเคราะห์ช่องว่างความครอบคลุม:

ด้านล่างนี้คือฟังก์ชันและการทดสอบที่ใช้ได้ สาขา เงื่อนไข และกรณีใดบ้างที่ยังไม่ได้รับการทดสอบ? แสดงรายการข้อบกพร่องและเขียนการทดสอบใหม่เฉพาะข้อบกพร่องเท่านั้น อย่าทำซ้ำสิ่งที่มีอยู่ ฟังก์ชัน:{{function}}การทดสอบ:{{existing_tests}}

ข้อมูลทดสอบ / การสร้างวัตถุจำลอง:

สร้างข้อมูลการทดสอบที่สมจริงสำหรับการทดสอบ {{function/service}}: ตัวอย่างที่ถูกต้อง ตัวอย่างขอบ และตัวอย่างที่ไม่ถูกต้องแยกกัน แนะนำพฤติกรรมจำลองง่ายๆ สำหรับการพึ่งพาภายนอก {{X}} การใช้ข้อมูลที่เป็นความลับ/PII ที่แท้จริง สร้างข้อมูลปลอม

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

จุดอ่อน: "เขียนแบบทดสอบสำหรับฟังก์ชันนี้"

Strong: "ด้วย pytest ฟังก์ชั่น Apply_discount(total, เปอร์เซ็นต์) — กฎ: ส่วนลดต้องเป็น 0%–30% นอกขอบเขตควรโยน ValueError ผลลัพธ์ควรปัดเศษเป็นทศนิยม 2 ตำแหน่ง เขียนความคาดหวังตามกฎนี้ (ไม่ใช่ด้วยโค้ด) เส้นทางที่มีความสุข + กรณีขอบเหล่านี้: 0%, 30%, 31% (ข้อผิดพลาด), ลบ, รวม = 0. [รหัส]"

เขาให้กฎการเผยแพร่ที่เข้มงวดและพูดว่า "เขียนความคาดหวังตามกฎ ไม่ใช่โค้ด"; ประโยคเดียวนี้ปิดกับดักของ AI ที่แก้ไขพฤติกรรมที่ไม่เหมาะสม

ประเภทการทดสอบ

การมีส่วนร่วมของ AI

การควบคุมของมนุษย์

การทดสอบหน่วยถนนแห่งความสุข

โครงกระดูกที่รวดเร็ว

ความคาดหวังถูกต้องหรือไม่?

เคสขอบ

การระดมความคิดอย่างกว้างขวาง

กำจัดสิ่งที่ไม่เกี่ยวข้องออกไป

การเติมช่องว่างขอบเขต

ค้นหาสาขาที่ถูกข้าม

ยืนยันความสำคัญ

ทดสอบข้อมูล/จำลอง

สร้างตัวอย่างที่เหมือนจริง

ไม่มี PII การควบคุมความสมจริง

การทดสอบจัดการคุณภาพ ไม่ใช่การรับประกัน

ความครอบคลุมของการทดสอบในระดับสูงให้ความมั่นใจ แต่ก็อาจทำให้เข้าใจผิดได้เช่นกัน ความครอบคลุม 100 เปอร์เซ็นต์หมายความว่า "ทุกบรรทัดทำงาน" ไม่ใช่ "ทุกบรรทัดถูกต้อง" เพิ่มความครอบคลุมด้วย AI ได้อย่างง่ายดาย คุณค่าที่แท้จริงอยู่ที่การเขียนความคาดหวังที่มีความหมาย คุณค่าของการทดสอบคือความสามารถในการทำลายและแจ้งเตือนคุณเมื่อโค้ดเสียหาย นั่นเป็นเหตุผลว่าทำไมการทดสอบที่สร้างโดย AI จึงอิงตามคำถามที่ว่า "โค้ดจะพังจริง ๆ เมื่อมีการเปลี่ยนแปลงหรือไม่" ทดสอบด้วยคำถาม การจงใจทำลายเส้นและเห็นการแตกของการทดสอบ (แนวคิดในการเปลี่ยนแปลง) ถือเป็นข้อพิสูจน์ว่าการทดสอบได้ผล

เคล็ดลับ: หากต้องการดูว่าการทดสอบที่ AI เขียนใช้งานได้หรือไม่ ให้สร้างจุดบกพร่องเล็กๆ ในโค้ด (เช่น เปลี่ยน + เป็น -) และดูว่าการทดสอบขัดข้องหรือไม่ หากไม่พัง การทดสอบนั้นไม่ได้ปกป้องคุณ

ข้อผิดพลาดทั่วไป

• ขอทดสอบโดยไม่ให้กฎเกณฑ์ โมเดลหยุดพฤติกรรมปัจจุบัน แก้ไขข้อผิดพลาดเป็น "จริง"
• ยอมรับความคาดหวังโดยไม่ต้องอ่าน การทดสอบจะทำให้เข้าใจผิดหากคุณไม่ตรวจสอบว่าการยืนยันกำลังตรวจสอบค่าที่ถูกต้อง
• แค่ทดสอบเส้นทางแห่งความสุข ข้อผิดพลาดที่แท้จริงเกิดขึ้นที่ระยะขอบ ขอกรณีขอบอย่างชัดเจน
• ผิดขอบเขตตามวัตถุประสงค์ เปอร์เซ็นต์ที่สูงไม่ได้รับประกันถึงพฤติกรรมที่ถูกต้อง
• สร้างข้อมูลจริง/ที่ซ่อนอยู่เป็นข้อมูลทดสอบ ข้อมูลหรือความลับของลูกค้าไม่ควรเข้าสู่การทดสอบและการจัดเก็บ สร้างข้อมูลสังเคราะห์

โดยสรุป

AI รับภาระซ้ำซ้อนในการทดสอบการเขียน โดยจะสร้างโครงกระดูกที่รวดเร็ว รายการ Edge Case จำนวนมาก และการวิเคราะห์ช่องว่างความครอบคลุม แต่จุดสำคัญที่สุดคือความคาดหวัง AI มีแนวโน้มที่จะทดสอบพฤติกรรมปัจจุบันของโค้ด ในขณะที่การทดสอบควรเขียนตามข้อกำหนด กำหนดกฎ ตรวจสอบความคาดหวัง บังคับใช้กรณี Edge และทดสอบว่าการทดสอบป้องกันโดยการฉีดจุดบกพร่องจริงหรือไม่ ความครอบคลุมการทดสอบเป็นเครื่องมือ ไม่ใช่เป้าหมาย

งานสมัคร

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

รายการตรวจสอบ

• [ ] ฉันแยกแยะว่าการทดสอบมีไว้เพื่อแก้ไขหรือตรวจสอบพฤติกรรม
• [ ] เมื่อฉันขอการทดสอบ ฉันจะให้กฎ (ข้อกำหนด) ที่ควรมี ไม่ใช่โค้ด
• [ ] ฉันเปรียบเทียบการยืนยันที่สร้างขึ้นแต่ละรายการกับข้อกำหนด
• [ ] ฉันขอกรณี Edge และ Failure อย่างชัดเจน
• [ ] ฉันถือว่าเปอร์เซ็นต์ความครอบคลุมเป็นเครื่องมือ ไม่ใช่เป้าหมาย
• [ ] ฉันทดสอบว่าการทดสอบป้องกันโดยการฉีดข้อผิดพลาดจริงหรือไม่