กำไร:
- ความสามารถในการอ่านหน่วยเมตริก เช่น เส้น สาขา และเงื่อนไขเป็นแผนที่ ไม่ใช่ความน่าเชื่อถือ และเข้าใจว่าความครอบคลุมสูงสามารถให้ความน่าเชื่อถือแบบหลอกได้
- ความสามารถในการวางขอบเขตความต้องการไว้ถัดจากขอบเขตโค้ด และทำให้มองเห็นช่องว่างในการตรวจสอบย้อนกลับได้ด้วยปัญญาประดิษฐ์
- ความสามารถในการให้คะแนนคุณลักษณะต่างๆ ด้วยสูตรความเสี่ยง = ความน่าจะเป็น × ผลกระทบ ความพยายามในการทดสอบที่จำกัดโดยตรงไปยังความเสี่ยงสูงสุด และจัดทำเอกสารที่จงใจอยู่นอกขอบเขต
คุณไม่สามารถทดสอบทุกซอฟต์แวร์ได้ตลอดไป เวลาและทรัพยากรมีจำกัด คำถามที่แท้จริงก็คือ: จะต้องพยายามทดสอบอย่างจำกัดที่ไหน? สองแนวคิดตอบคำถามนี้ ความครอบคลุมการทดสอบ—หน่วยวัดที่วัดว่าการทดสอบครอบคลุมโค้ดหรือข้อกำหนดมากน้อยเพียงใด—แสดงถึงสิ่งที่กำลังทดสอบ การทดสอบตามความเสี่ยง - วิธีการกำหนดลำดับความสำคัญของการทดสอบตามความน่าจะเป็นของการเสื่อมสภาพของพื้นที่และความเสียหายที่จะเกิดขึ้นเมื่อมันแย่ลง - กำหนดความพยายามไปสู่ความเสี่ยงมากที่สุด ปัญญาประดิษฐ์ (AI) เป็นพันธมิตรด้านการวิเคราะห์ที่ทรงพลังในด้านทั้งสอง: ช่วยให้มองเห็นช่องว่างความครอบคลุม และแนะนำพื้นที่เสี่ยง แต่ข้อแม้หลักยังคงอยู่: จำนวนขอบเขตที่ AI เห็นอาจทำให้เข้าใจผิดได้ แม้แต่การครอบคลุมแถว 100% ก็สามารถทำได้ด้วยการทดสอบที่ไม่ยืนยันอะไรเลย งานของคุณคือการอ่านขอบเขตเป็นแผนที่ ไม่ใช่ความน่าเชื่อถือ
การอ่านตัวชี้วัดความครอบคลุมอย่างถูกต้อง
ขอบเขตมีหลายประเภท และไม่ได้ทั้งหมดมีความหมายเท่ากัน:
- การครอบคลุมบรรทัด: จำนวนบรรทัดของโค้ดที่ถูกดำเนินการอย่างน้อยหนึ่งครั้ง เกณฑ์ที่พบบ่อยที่สุดแต่อ่อนแอที่สุด เพียงเพราะว่าบรรทัดใช้งานได้ไม่ได้พิสูจน์ว่าบรรทัดทำงานได้อย่างถูกต้อง
- ความครอบคลุมของสาขา: มีการทดสอบทุกสาขาหรือไม่ (ทั้งจริงและเท็จ) มีความหมายมากกว่าเส้น
- การครอบคลุมเงื่อนไข: การทดสอบแต่ละเงื่อนไขย่อยในเงื่อนไขที่ซับซ้อนแยกกัน
- การครอบคลุมเส้นทาง: การรวมกันของเส้นทางลอจิคัลภายในโค้ด เป็นสิ่งที่ครอบคลุมที่สุดแต่ยากที่จะเข้าถึงได้อย่างเต็มที่ในทางปฏิบัติ
ข้อควรระวัง: เปอร์เซ็นต์ความครอบคลุมไม่ใช่ "คะแนนคุณภาพ" ความครอบคลุมแถว 100% บอกคุณว่าแถวกำลังทำงานอยู่ ไม่ใช่ว่าจะให้ผลลัพธ์ที่ถูกต้อง (หลอกผ่านในหน่วยที่ 1) ใช้ขอบเขตเป็นคำตอบสำหรับคำถาม "ฉันไม่เคยดูที่ไหน" ไม่ใช่เป็นหลักประกันว่า "ทุกอย่างผ่านการทดสอบแล้ว"
ขอบเขตจุดบอด
ตัวชี้วัดความครอบคลุมจะวัดเฉพาะจำนวนโค้ดที่ถูกดำเนินการเท่านั้น ไม่สามารถมองเห็น: (1) ข้อกำหนดที่ยังไม่ผ่านการทดสอบ (มีรหัสอยู่แต่กฎเกณฑ์ทางธุรกิจไม่ถูกต้อง), (2) รหัสหายไป (ไม่มีขอบเขตสำหรับการควบคุมที่ไม่เคยเขียน), (3) การรวมข้อมูล/สถานะ (4) การใช้งาน ประสิทธิภาพ และความปลอดภัย ดังนั้น ความครอบคลุมข้อกำหนด (แต่ละเกณฑ์การยอมรับต้องเป็นไปตามการทดสอบอย่างน้อยหนึ่งครั้ง) ควรอยู่ถัดจากความครอบคลุมของโค้ด AI มีประโยชน์มากในการสร้างแผนที่การทดสอบความต้องการ (เมทริกซ์การตรวจสอบย้อนกลับ)
การทดสอบตามความเสี่ยง: เราทุ่มเทความพยายามไปที่ไหน?
ความเสี่ยง = ความน่าจะเป็น (โอกาสที่จะแตกหัก) × ผลกระทบ (อันตรายหากแตกหัก) ด้วย AI คุณสามารถให้คะแนนรายการคุณลักษณะบนสองแกนนี้ และสร้างแผนที่ความร้อนได้ ความน่าจะเป็นสูง × โดเมนสูง (การชำระเงิน การรับรองความถูกต้อง ความสมบูรณ์ของข้อมูล) สมควรได้รับการทดสอบที่เข้มข้นที่สุด พื้นที่ต่ำ × ต่ำ (หน้าจอกำหนดลักษณะที่ไม่ค่อยได้ใช้) การทดสอบแสงก็เพียงพอแล้ว
พื้นที่
ความน่าจะเป็น
ผลกระทบ
ความเสี่ยง
ทดสอบความหนาแน่น
กระแสการชำระเงิน
ปานกลาง
สูงมาก
สูง
ลึก + ระบบอัตโนมัติ
การรับรองความถูกต้อง
ปานกลาง
สูงมาก
สูง
ลึก + ความปลอดภัย
ค้นหาผลิตภัณฑ์
สูง
ปานกลาง
ปานกลาง-สูง
ระบบอัตโนมัติ + การค้นพบ
รูปโปรไฟล์
ต่ำ
ต่ำ
ต่ำ
การควบคุมแสง
หน้าช่วยเหลือ
ต่ำ
ต่ำเกินไป
ต่ำเกินไป
ทบทวน
กับดักแห่งขอบเขตการไล่ล่า
การกำหนดเปอร์เซ็นต์ความครอบคลุมเป็นเป้าหมาย (เช่น กฎ "ทีมต้องผ่านการครอบคลุม 90%) มีผลข้างเคียงที่เป็นอันตราย: นักพัฒนาและผู้ทดสอบมุ่งเน้นไปที่การเพิ่มเปอร์เซ็นต์แทนที่จะจัดการกับความเสี่ยงที่แท้จริง ผลลัพธ์มักมีขอบเขตป่องโดยไม่มีการยืนยันหรือการทดสอบเล็กๆ น้อยๆ ตัวเลขดูดีแต่ไม่มีการป้องกัน นี่คือปรากฏการณ์ของเกณฑ์ที่เสียหายเมื่อมันกลายเป็นเป้าหมาย: "เมื่อการวัดกลายเป็นเป้าหมาย มันก็จะเลิกเป็นการวัดที่ดี" ใช้ขอบเขตเป็นเครื่องมือวินิจฉัย ไม่ใช่การ์ดรายงานประสิทธิภาพ
แนวทางที่ดีกว่าคือการอ่านขอบเขตในทิศทาง: "เหตุใดความครอบคลุมของสาขาจึงติดอยู่ที่ 40% ในโมดูลการชำระเงินที่สำคัญ" คำถามคือ “ความคุ้มครองโดยรวม 90% หรือไม่?” มันมีค่ามากกว่าคำถามมาก ให้ AI แบ่งรายงานขอบเขตตามโมดูลและระดับความเสี่ยง เน้นพื้นที่เสี่ยงสูงที่มีความครอบคลุมต่ำ ดังนั้นขอบเขตจึงกลายเป็นเข็มทิศที่ชี้นำแรงงานแทนที่จะเป็นเปอร์เซ็นต์ที่มองไม่เห็น
ข้อควรระวัง สโลแกน "ครอบคลุม 100%" ถือเป็นกับดัก การทดสอบโค้ดบางส่วน (ตัวเข้าถึงแบบธรรมดา ชิ้นส่วนที่สร้างขึ้นอัตโนมัติ) มีค่าต่ำ ความพยายามที่ใช้ไปนั้นถูกขโมยไปจากกฎเกณฑ์ทางธุรกิจที่มีความเสี่ยงสูง เป้าหมายคือการทดสอบพฤติกรรมและความเสี่ยงที่สำคัญทั้งหมด ไม่ใช่ทุกบรรทัด
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
อ่อนแอ: “เพิ่มความครอบคลุมการทดสอบของฉัน”
แข็งแกร่ง: "เมื่อพิจารณาจากรายการเกณฑ์การยอมรับและกรณีทดสอบที่มีอยู่เหล่านี้ (1) ตารางซึ่งการทดสอบใดๆ ไม่ตรงตามเกณฑ์การยอมรับ (ช่องว่างความครอบคลุมข้อกำหนด) (2) ให้คะแนนแต่ละคุณลักษณะ 1-5 ตามแกนความน่าจะเป็นและแกนผลกระทบ จัดอันดับตามความเสี่ยง = ความน่าจะเป็น × ผลกระทบ (3) สำหรับช่วงเวลาที่จำกัดของฉัน ให้แนะนำว่าควรปิด 5 ช่องว่างใดก่อน โดยเริ่มจากความเสี่ยงสูงสุด อย่าใช้การครอบคลุมบรรทัดโค้ดเป็นเกณฑ์เพียงอย่างเดียว จัดลำดับความสำคัญของธุรกิจ เกณฑ์ความเสี่ยง: [...] การทดสอบ: [...]"
พรอมต์อันทรงพลัง; รวมขอบเขตเข้ากับความเสี่ยงทางธุรกิจและจัดลำดับความสำคัญของแรงงานที่มีจำกัด
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) ช่องว่างขอบเขตความต้องการ:
โดยพิจารณาจากเกณฑ์การยอมรับดังต่อไปนี้และกรณีทดสอบเหล่านี้ สร้างตารางการตรวจสอบย้อนกลับ: แต่ละเกณฑ์ -> การทดสอบที่ตรงตามนั้น เกณฑ์ที่ไม่มีการทดสอบใด ๆ เรียกว่า "COVERAGE GAP" และการทดสอบที่ไม่เชื่อมโยงกับเกณฑ์ใด ๆ เรียกว่า "จำเป็น" เครื่องหมาย: เกณฑ์: [...] / การทดสอบ: [...]
2) การให้คะแนนความเสี่ยง:
ให้คะแนนรายการคุณสมบัติ/โมดูล 1-5 นี้กับความน่าจะเป็น (โอกาสที่จะแตกหัก) และแกนกระแทก (ความเสียหายหากหัก) ความเสี่ยง = ความน่าจะเป็น × ผลกระทบ จัดเรียงในตารางและระบุประเภทการทดสอบที่แนะนำ (หน่วย/API/UI/การลาดตระเวน/ความปลอดภัย) สำหรับแต่ละพื้นที่ที่มีความเสี่ยงสูง รายการ: [...]
3) การตีความขอบเขต:
ได้รับรายงานความครอบคลุมต่อไปนี้ (บรรทัด %, สาขา %) บอกฉันสิ่งนี้:- ตัวเลขเหล่านี้ไม่ได้พิสูจน์อะไร - พื้นที่ใดบ้างที่อาจมีความเสี่ยงแม้จะมีการครอบคลุมแถวสูง - คุณจะแนะนำการทดสอบเพิ่มเติมอะไรบ้างสำหรับช่องว่างที่ความครอบคลุมไม่เห็น (ข้อกำหนด การรวมข้อมูล ความปลอดภัย) รายงาน: [วาง]
4) แผนเวลาจำกัด:
เหลืออีก [X ชั่วโมง] จนกว่าจะออกอากาศ มีการจัดอันดับความเสี่ยงและช่องว่างความครอบคลุมดังต่อไปนี้ ในช่วงเวลานี้ แผนการทดสอบที่จะลดความเสี่ยงสูงสุดจะถูกจัดเตรียมตามลำดับความสำคัญ ระบุอย่างชัดเจนถึงสิ่งที่ไม่ควรทดสอบอย่างมีสติและความเสี่ยงที่ยอมรับได้ในการทำเช่นนั้น ข้อมูล: [...]
มินิเคสสามอัน
กรณีที่ 1 — ความคุ้มครอง 100% ไม่มีความไว้วางใจ ทีมหนึ่งมีความครอบคลุมบรรทัดถึง 94% การวิเคราะห์ "การตีความขอบเขต" แสดงให้เห็นว่าการทดสอบส่วนใหญ่ไม่มีการยืนยัน ซึ่งหมายความว่าการทดสอบดำเนินไปแต่ไม่ได้ตรวจสอบอะไรเลย ความคุ้มครองที่แท้จริงต่ำกว่ามาก ทีมงานไม่ได้มุ่งเน้นไปที่ตัวเลข แต่เน้นที่การทดสอบการกลายพันธุ์ (หน่วยที่ 10) อัตราการตรวจจับข้อผิดพลาดจริงเพิ่มขึ้นสองเท่า
กรณีที่ 2 — แผนที่ความเสี่ยงมีลำดับความสำคัญที่ได้รับการแก้ไข ทีมหนึ่งใช้ความพยายามในการทดสอบ 40% บนหน้าจอการรายงานที่ไม่ค่อยได้ใช้ โดยข้ามขั้นตอนการชำระเงินเพราะมัน "ใช้งานได้" การให้คะแนนความเสี่ยงของ AI แสดงให้เห็นถึงความไม่สมดุลนี้ แรงงานถูกแจกจ่าย; สองสัปดาห์ต่อมา พบข้อบกพร่องที่มีผลกระทบสูงในขั้นตอนการชำระเงิน และถูกปิดก่อนใช้งานจริง
กรณีที่ 3 — มีสติอยู่นอกขอบเขต หลังจากเปิดตัวได้ 4 ชั่วโมง ทีมงานตัดสินใจว่าจะทดสอบอะไรและควรข้ามอะไรไปอย่างมีสติด้วยเทมเพลต "กำหนดเวลาที่จำกัด" มีการทดสอบลำธารที่มีความเสี่ยงสูงสองแห่งในเชิงลึก หน้าจอการตั้งค่าที่มีความเสี่ยงต่ำได้รับการบันทึกเป็น "ความเสี่ยงที่ยอมรับได้" และข้ามไป การตัดสินใจมีความโปร่งใสและมีเหตุผล เวอร์ชั่นออกมาอย่างปลอดภัย
ข้อผิดพลาดทั่วไป
- เปอร์เซ็นต์ความครอบคลุมที่ผิดพลาดในด้านคุณภาพ การอ่านความครอบคลุมของแถวสูงว่าเป็นการรับประกันที่ "ผ่านการทดสอบ"
- เพียงแค่ดูการครอบคลุมโค้ด การข้ามข้อกำหนดครอบคลุม (การทดสอบเกณฑ์การยอมรับแต่ละข้อ)
- การทดสอบอย่างเท่าเทียมกันโดยไม่คำนึงถึงความเสี่ยง การจัดสรรแรงงานไปยังพื้นที่ที่มีความเสี่ยงต่ำและละเลยกระแสวิกฤติ
- ซ่อนตัวอยู่นอกขอบเขต ไม่บันทึกสิ่งที่ไม่ได้ทดสอบเมื่อมีเวลาไม่เพียงพอ ความประหลาดใจหลังการเปิดตัว
- การยอมรับคะแนนความเสี่ยงของ AI โดยไม่มีคำถาม AI ไม่ทราบบริบทของผลิตภัณฑ์อย่างถ่องแท้ ปรับคะแนนด้วยสายตาผู้เชี่ยวชาญ
โดยสรุป
ความครอบคลุมของการทดสอบและการทดสอบตามความเสี่ยงเป็นสองเครื่องมือในการขับเคลื่อนความพยายามที่มีจำกัดไปยังสถานที่ที่เหมาะสม ตัวชี้วัดความครอบคลุม (เส้น สาขา สภาพ เส้นทาง) แสดงสิ่งที่ถูกสัมผัส แต่ไม่ได้พิสูจน์ว่ามีการทำงานอย่างถูกต้อง ขอบเขตคือแผนที่ ความไว้วางใจไม่ใช่ ใส่ความครอบคลุมของข้อกำหนดถัดจากความครอบคลุมของโค้ด ให้คะแนนคุณลักษณะต่างๆ ด้วยสูตรความเสี่ยง = ความน่าจะเป็น × ผลกระทบ และความพยายามโดยตรงไปยังความเสี่ยงมากที่สุด AI ทำให้มองเห็นช่องว่าง ให้คะแนนความเสี่ยง วางแผนในเวลาที่จำกัด แต่ลำดับความสำคัญสุดท้ายและการตัดสินใจ "ไม่เข้าร่วมอย่างมีสติ" อยู่ที่ผู้เชี่ยวชาญที่รู้บริบททางธุรกิจ
งานสมัคร
เลือกโมดูลจากโครงการของคุณเอง เรียกใช้เทมเพลต “ช่องว่างขอบเขตข้อกำหนด” ด้วย AI และค้นหาเกณฑ์การยอมรับที่ไม่ผ่านการทดสอบ จากนั้นจัดอันดับคุณลักษณะย่อยของโมดูลตามความน่าจะเป็น × แกนกระแทกด้วย "การให้คะแนนความเสี่ยง" แจกแจงเวลาทดสอบ (ตามสมมุติฐาน) 3 ชั่วโมงที่คุณมีโดย "กำหนดเวลาที่จำกัด" จดบันทึกสิ่งที่คุณตั้งใจจะไม่ทดสอบและความเสี่ยงที่ยอมรับ เพิ่มการทดสอบที่เป็นรูปธรรมที่จะปิดช่องว่างความครอบคลุมความเสี่ยงสูงสุดที่คุณพบ
รายการตรวจสอบ
- [ ] ฉันอ่านเปอร์เซ็นต์ความครอบคลุมเป็นแผนที่ ไม่ใช่คุณภาพ
- [ ] นอกจากการครอบคลุมโค้ดแล้ว ฉันยังลบการครอบคลุมข้อกำหนดออกด้วย
- [ ] ฉันให้คะแนนคุณลักษณะตามความน่าจะเป็น × ผลกระทบ และจัดอันดับตามความเสี่ยง
- [ ] ฉันเปลี่ยนเส้นทางความพยายามในการทดสอบไปยังความเสี่ยงสูงสุด
- [ ] ฉันได้บันทึกพื้นที่ที่ไม่ได้รับการทดสอบและยอมรับความเสี่ยงอย่างมีสติ
- [ ] ฉันตรวจสอบคะแนนความเสี่ยงของ AI ตามบริบทผลิตภัณฑ์ของฉัน