ความหนาแน่นของข้อบกพร่องคืออะไร? สูตรคำนวณด้วยตัวอย่าง

ความหนาแน่นของข้อบกพร่องคืออะไร?

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

ความหนาแน่นของข้อบกพร่องจะนับต่อจำนวนบรรทัดโค้ดพันบรรทัด หรือที่เรียกว่า KLOC เนื่องจากการนับจะถูกปรับให้เป็นมาตรฐานตามขนาด ทำให้สามารถเปรียบเทียบโมดูลขนาดใหญ่ที่มีข้อบกพร่องจำนวนมากและโมดูลขนาดเล็กที่มีข้อบกพร่องน้อยได้ในระดับเดียวกัน ซึ่งการนับข้อบกพร่องแบบดิบๆ ไม่สามารถทำได้

โดยปกติแล้วจะมีการรายงานค่าตัวชี้วัดนี้เมื่อสิ้นสุดรอบการทดสอบ tracมีการปล่อยเวอร์ชันใหม่ออกมาเรื่อยๆ จึงทำให้มันอยู่เคียงข้างกับเวอร์ชันอื่นๆ กระบวนการจัดการข้อบกพร่อง ที่ วงจรชีวิตการทดสอบซอฟต์แวร์.

วิธีคำนวณความหนาแน่นของข้อบกพร่อง

สูตรในการวัดความหนาแน่นของข้อบกพร่อง:

Defect Density = Defect count/size of the release

ขนาดของเวอร์ชันที่ปล่อยออกมาสามารถวัดได้ในแง่ของจำนวนบรรทัดโค้ด (LOC)

มีรายละเอียดสามอย่างที่จะตัดสินว่าตัวเลขที่ได้นั้นมีความหมายหรือไม่:

• หน่วยวัดขนาด LOC และ KLOC เป็นหน่วยที่ใช้กันทั่วไปมากที่สุด ส่วนฟังก์ชันพอยต์นั้นใช้ในกรณีที่ทีมต้องการหน่วยวัดขนาดที่ไม่เปลี่ยนแปลงไปตามภาษาโปรแกรม และบางทีมอาจปรับมาตรฐานตามโมดูลหรือตามคอมโพเนนต์แทน
• อะไรคือสิ่งที่ถือว่าเป็นข้อบกพร่อง? เฉพาะข้อบกพร่องที่ได้รับการยืนยันแล้วเท่านั้นที่จะนับรวมในตัวเศษ รายการที่ซ้ำกัน รายงานที่ถูกปฏิเสธ และคำขอปรับปรุงจะต้องถูกตัดออก มิเช่นนั้นตัวเลขจะสูงขึ้นโดยที่คุณภาพของโค้ดไม่เปลี่ยนแปลง
• หน้าต่างการวัด ข้อบกพร่องที่พบระหว่างการทดสอบระบบ การทดสอบการถดถอยและหลังจากเผยแพร่แล้วจะอธิบายสิ่งต่างๆ ที่แตกต่างกัน ดังนั้นจึงต้องระบุช่วงเวลาพร้อมกับตัวเลขด้วย

ตัวอย่างความหนาแน่นของข้อบกพร่อง

สมมติว่าคุณมีโมดูล 3 โมดูลที่รวมอยู่ในผลิตภัณฑ์ซอฟต์แวร์ของคุณ แต่ละโมดูลมีจำนวนข้อบกพร่องที่ตรวจพบดังต่อไปนี้:

• โมดูล 1 = 10 ข้อบกพร่อง
• โมดูล 2 = 20 ข้อบกพร่อง
• โมดูล 3 = 10 ข้อบกพร่อง

จำนวนบั๊กทั้งหมด = 10+20+10 = 40

จำนวนบรรทัดโค้ดทั้งหมดสำหรับแต่ละโมดูลมีดังนี้:

• โมดูล 1 = 1000 ล็อค
• โมดูล 2 = 1500 ล็อค
• โมดูล 3 = 500 ล็อค

เส้นรวมของ Code = 1000+1500+500 = 3000

ความหนาแน่นของข้อบกพร่องคำนวณได้ดังนี้:

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

การคำนวณแบบเดียวกันที่ใช้กับแต่ละโมดูลนั้นมีประโยชน์มากกว่าตัวเลขรวม ดังที่แผนภูมิด้านล่างแสดงให้เห็น: โมดูล 2 มีข้อบกพร่อง 20 รายการในโค้ด 1500 บรรทัด และโมดูล 3 มีข้อบกพร่อง 10 รายการในโค้ดเพียง 500 บรรทัด ดังนั้นโมดูล 3 จึงมีความหนาแน่นและมีความเสี่ยงมากกว่า แม้ว่าจะรายงานข้อบกพร่องน้อยกว่าก็ตาม

มาตรฐานสำหรับความหนาแน่นของข้อบกพร่อง

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

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

ปัจจัยที่มีผลต่อความหนาแน่นของข้อบกพร่อง

โค้ดชุดเดียวกันอาจให้ค่าความหนาแน่นของข้อบกพร่องที่แตกต่างกันอย่างมาก ขึ้นอยู่กับปัจจัยต่อไปนี้:

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

ความหนาแน่นของข้อบกพร่องเทียบกับตัวชี้วัดข้อบกพร่องอื่นๆ

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

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

ข้อดีของความหนาแน่นของข้อบกพร่อง

ต่อไปนี้คือข้อดีของความหนาแน่นของข้อบกพร่อง:

• ช่วยในการวัดประสิทธิภาพของการทดสอบ
• วิธีนี้ช่วยในการแยกแยะความเข้มข้นของข้อบกพร่องระหว่างส่วนประกอบและโมดูลซอฟต์แวร์ได้
• เป็นประโยชน์ในการระบุส่วนที่ต้องแก้ไขหรือปรับปรุง
• เป็นประโยชน์ในการชี้ให้เห็นถึงส่วนประกอบที่มีความเสี่ยงสูง ซึ่งส่งผลโดยตรงต่อ... การทดสอบตามความเสี่ยง.
• ช่วยในการระบุความต้องการด้านการฝึกอบรมของบุคลากรกลุ่มต่างๆ
• สิ่งนี้อาจเป็นประโยชน์ในการประเมินความพยายามในการทดสอบและแก้ไขงานที่เกิดจากข้อบกพร่อง
• สามารถประเมินข้อบกพร่องที่เหลืออยู่ในซอฟต์แวร์ได้
• ก่อนการเปิดตัว จะช่วยตรวจสอบว่าการทดสอบที่ทำมานั้นเพียงพอหรือไม่
• เป็นการสร้างฐานข้อมูลทางประวัติศาสตร์ที่สามารถใช้เป็นเกณฑ์วัดสำหรับเวอร์ชันต่อๆ ไปได้

ข้อจำกัดของความหนาแน่นของข้อบกพร่อง

ตัวชี้วัดนี้คำนวณได้ง่าย แต่ก็ตีความผิดได้ง่ายเช่นกัน ข้อจำกัดต่อไปนี้จะเป็นตัวกำหนดว่าควรให้ความสำคัญกับตัวชี้วัดนี้มากน้อยเพียงใดในการตัดสินใจเกี่ยวกับการปล่อยเวอร์ชันใหม่:

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

ทั้งหมดนี้ไม่ได้ทำให้ความหนาแน่นของข้อบกพร่องไร้ประโยชน์ แต่เป็นเพียงตัวบ่งชี้แนวโน้มสำหรับผลิตภัณฑ์หนึ่งๆ ที่วัดผลอย่างสม่ำเสมอ มากกว่าจะเป็นคะแนนสำหรับเปรียบเทียบทีมต่างๆ

วิธีลดความหนาแน่นของข้อบกพร่อง

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

• ย้ายการทดสอบให้เร็วขึ้น การนำผู้ทดสอบเข้ามามีส่วนร่วมในขั้นตอนการกำหนดความต้องการและการออกแบบ จะช่วยตรวจจับความคลุมเครือได้ก่อนที่จะกลายเป็นโค้ด ซึ่งเป็นจุดที่การแก้ไขข้อบกพร่องมีต้นทุนต่ำที่สุด
• Revตรวจสอบโค้ดก่อนที่จะรวมเข้าด้วยกัน การตรวจสอบโดยเพื่อนร่วมงานช่วยตรวจจับข้อผิดพลาดทางตรรกะ การตีความข้อกำหนดผิดพลาด และข้อบกพร่องในการออกแบบที่ไม่มีใครสังเกตเห็น การทดสอบหน่วย ถูกเขียนขึ้นเพื่อค้นหา
• ทำการทดสอบการถดถอยแบบอัตโนมัติ ทำการตรวจสอบทุกครั้งที่มีการคอมมิตผ่าน บูรณาการอย่างต่อเนื่อง ช่วยป้องกันไม่ให้ข้อบกพร่องเก่ากลับมาเกิดขึ้นอีกในขณะที่กำลังเขียนโค้ดใหม่
• เขียนชุดทดสอบก่อน การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ บังคับให้ต้องระบุพฤติกรรมแต่ละอย่างก่อนที่จะนำไปใช้งาน และ การทดสอบการกลายพันธุ์ จากนั้นจึงสามารถยืนยันได้ว่าผลการทดสอบที่ได้นั้นยืนยันบางสิ่งบางอย่างอย่างแท้จริง
• ใช้การวิเคราะห์แบบสถิต ระบบสแกนโค้ดอัตโนมัติจะตรวจจับการเข้าถึงค่าว่าง การรั่วไหลของทรัพยากร และจุดที่ซับซ้อนก่อนที่จะเริ่มการทดสอบใดๆ
• ปรับโครงสร้างโมดูลที่มีความหนาแน่นสูงใหม่ เมื่อ Defect Density ระบุส่วนประกอบที่แย่ที่สุดแล้ว การแยกและลดความซับซ้อนของส่วนประกอบเหล่านั้นมักจะช่วยลดทั้งความซับซ้อนและจำนวนข้อบกพร่องลงได้
• นำข้อบกพร่องกลับเข้าสู่กระบวนการอีกครั้ง การวิเคราะห์สาเหตุที่แท้จริงในการประชุมทบทวนผลการปฏิบัติงานจะเปลี่ยนข้อบกพร่องแต่ละรายการให้เป็นการแก้ไขกระบวนการทำงาน แทนที่จะเป็นการแก้ไขแบบเฉพาะหน้า

Tracการปล่อย ked เหนือการปล่อยควบคู่กันไป เทคนิคการทดสอบซอฟต์แวร์ และด้วยข้อมูลความครอบคลุม ความหนาแน่นของข้อบกพร่องจึงกลายเป็นระบบเตือนภัยล่วงหน้ามากกว่าจะเป็นเพียงรายงานผลการประเมิน

คำถามที่พบบ่อย