การประกันคุณภาพ (QA) การดีบักและการทดสอบอัตโนมัติ

กำไร:

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

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

ในหน่วยนี้คุณจะได้เรียนรู้วิธีใช้ AI ใน QA และการดีบัก คุณจะได้เรียนรู้การออกแบบสถานการณ์การทดสอบ การวิเคราะห์บันทึก การเขียนการทดสอบอัตโนมัติ และระเบียบวินัยในการรายงานข้อผิดพลาด

เลเยอร์ของ QA และตำแหน่งของ AI

QA มีหลายชั้น การทดสอบการทำงาน: คุณลักษณะนี้ทำงานหรือไม่ (ประตูเปิดอยู่ โหลดการบันทึกหรือไม่) การทดสอบการถดถอย: การเปลี่ยนแปลงใหม่ทำลายสิ่งที่เคยใช้อยู่ก่อนหน้านี้หรือไม่ การทดสอบกรณี Edge: อินพุตที่ผิดปกติ (รีเซ็ตสินค้าคงคลัง, สองคีย์พร้อมกัน, ค่าเส้นขอบ) การทดสอบประสิทธิภาพ/การชน: เกมมีความเสถียรหรือไม่ การทดสอบการเล่นเกม/ประสบการณ์: สนุก ใช้งานง่าย AI มีความแข็งแกร่งในสี่ส่วนแรก: การสร้างสถานการณ์ การแสดงรายการ Edge Case การเขียนโค้ดทดสอบ และการวิเคราะห์บันทึก สุดท้าย—ประสบการณ์—เป็นของมนุษย์

ขั้นตอน QA ทีละขั้นตอน:

1. สร้างกรณีทดสอบ (รายการกรณีการทำงานและกรณี Edge ด้วย AI)
2. เขียนการทดสอบอัตโนมัติ (โค้ดสำหรับการตรวจสอบซ้ำ)
3. เรียกใช้และรวบรวม (บันทึกข้อผิดพลาด บันทึก ข้อขัดข้อง)
4. วิเคราะห์ (ตรวจสอบบันทึกและรูปแบบข้อผิดพลาดด้วย AI)
5. รายงานและตรวจสอบ (รายงานข้อผิดพลาดที่ชัดเจนและทำซ้ำได้ ทดสอบการแก้ไข)

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

การทดสอบอัตโนมัติ: ปล่อยการทำซ้ำไว้ที่เครื่อง

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

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

การสืบพันธุ์: หัวใจของการดีบัก

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

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

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

กรณีที่ 1 — การค้นหากรณี Edge ในเกม RPG ทีมงานได้ทดสอบระบบสินค้าคงคลังในรูปแบบการเล่น "ปกติ" และคิดว่ามันแข็งแกร่ง พวกเขาให้ AI พูดว่า "พยายามถอดรหัสสินค้าคงคลังนี้" และสร้างสถานการณ์จำลอง 30 กรณี ข้อผิดพลาด 4 ข้อนี้เป็นข้อผิดพลาดที่แท้จริง (0 การแยกรายการน้ำหนัก ทิ้งพร้อมกัน) แก้ไขก่อนเผยแพร่

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

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

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

1) การสร้างสถานการณ์ Edge case/การแสวงหาผลประโยชน์:

บทบาทของคุณ: ผู้ทดสอบ QA ที่เป็นอันตราย ฉันอธิบายระบบต่อไปนี้: [ระบบ, กฎ] งาน: แสดงรายการสถานการณ์จำลอง Edge case 20 รายการที่จะพยายามเจาะ ใช้ประโยชน์ หรือทำให้ระบบนี้เข้าสู่สถานะที่ไม่คาดคิด สำหรับแต่ละข้อ: สิ่งที่ควรลอง ผลลัพธ์ที่คาดหวัง ข้อผิดพลาดที่อาจเกิดขึ้น

2) การเขียนทดสอบอัตโนมัติ:

เครื่องยนต์: [Unity 2022.3 / Unreal 5.3] กรอบงานการทดสอบ: [ระบุ] เขียนการทดสอบอัตโนมัติสำหรับฟังก์ชัน/ระบบต่อไปนี้: [คำอธิบาย/รหัส] รวมกรณีปกติ กรณีจำกัด และอินพุตที่ผิดพลาด ตรวจสอบให้แน่ใจว่าการทดสอบแต่ละครั้งจะตรวจสอบสิ่งที่มีความหมายอย่างแท้จริง การเขียนแบบทดสอบที่ว่างเปล่า/ไร้ความหมาย

3) การวิเคราะห์บันทึก/ข้อขัดข้อง:

ด้านล่างนี้คือบันทึกข้อขัดข้อง/ข้อผิดพลาดของเกม: [บันทึก] งาน: ทำเครื่องหมายรูปแบบที่เกิดซ้ำ เงื่อนไขทั่วไป (ฉาก หน่วยความจำ เวลา) และสาเหตุที่เป็นไปได้ นำเสนอแต่ละสาเหตุเป็น "สมมติฐานที่ต้องพิสูจน์"; พูดอย่างชัดเจน บอกวิธียืนยันด้วย

4) ชี้แจงรายงานข้อผิดพลาด:

จัดทำรายงานข้อผิดพลาดที่คลุมเครือต่อไปนี้ให้ชัดเจนและทำซ้ำได้: [รายงานดิบ] ผลลัพธ์: ชื่อ, การสร้างซ้ำทีละขั้นตอน, ผลลัพธ์ที่คาดหวัง, ผลลัพธ์จริง, ความถี่, สภาพแวดล้อม หากมีข้อมูลขาดหายไป ให้ระบุข้อมูลที่จำเป็น

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

พรอมต์ที่อ่อนแอ:

มีข้อผิดพลาดในเกมของฉัน โปรดแก้ไข

ไม่มีบริบท ไม่มีบันทึก ไม่มีการทำซ้ำ AI เป็นการคาดการณ์และมีความเสี่ยงสูงที่จะเกิดอาการประสาทหลอน

พรอมต์อันทรงพลัง:

มีข้อบกพร่องในเกม Unity 2022.3 ของฉัน: บางครั้งพื้นที่โฆษณาจะเพิ่มขึ้นสองเท่าเมื่อผู้เล่นบันทึกการโหลดอย่างรวดเร็ว การทำสำเนา: [ขั้นตอน] รหัสที่เกี่ยวข้อง: [วาง] บันทึก: [วาง] งาน: แสดงรายการสาเหตุที่แท้จริงที่เป็นไปได้เป็นสมมติฐานที่ต้องการพิสูจน์ ให้วิธีการตรวจสอบและแก้ไขที่เป็นไปได้สำหรับแต่ละสาเหตุ สร้างสาเหตุที่ไม่มีอยู่จริง หากคุณไม่แน่ใจโปรดแจ้งให้เราทราบ

การทำซ้ำ รหัส บันทึก และคำขอ "นำเสนอตามสมมติฐาน" ทำให้การวินิจฉัยเชื่อถือได้

ตารางเลเยอร์ QA

ชั้น

มันทดสอบอะไร?

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

การแบ่งปันของมนุษย์

ใช้งานได้

คุณลักษณะนี้ใช้งานได้หรือไม่?

สคริปต์โค้ดทดสอบ

การตัดสินใจรับเข้าเรียน

การถดถอย

ของเก่าพังมั้ย?

การทดสอบอัตโนมัติ

การตัดสินใจขอบเขต

กรณีที่รุนแรง

อินพุตที่ผิดปกติ

การผลิตสคริปต์

ลำดับความสำคัญ

ความผิดพลาด/ประสิทธิภาพการทำงาน

ความมุ่งมั่น

การวิเคราะห์บันทึก

การยืนยันสาเหตุที่แท้จริง

ประสบการณ์

ความบันเทิงสัญชาตญาณ

จำกัด

มนุษย์โดยสมบูรณ์

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

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

โดยสรุป

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

งานสมัคร

เลือกระบบจากเกมของคุณ มี 20 สถานการณ์ที่สร้างขึ้นด้วยเทมเพลต “การสร้างสถานการณ์จำลองกรณี Edge/การแสวงหาประโยชน์” และทดสอบ 5 สถานการณ์ที่เสี่ยงที่สุด สร้างรายงานที่ทำซ้ำได้สำหรับข้อบกพร่องที่คุณพบด้วยเทมเพลต "การปรับแต่งรายงานข้อบกพร่อง"

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

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