ما هي الكثافة المعيبة؟ صيغة لحساب مع المثال

ما هي الكثافة المعيبة؟

كثافة الخلل هو عدد العيوب المؤكدة في برنامج أو وحدة برمجية خلال فترة تشغيل أو تطوير محددة، مقسومًا على حجم ذلك البرنامج أو الوحدة. يُمكّن هذا المقياس الفريق من تحديد ما إذا كان البرنامج جاهزًا للإصدار أم لا.

يُحسب معدل كثافة العيوب لكل ألف سطر من التعليمات البرمجية، ويُعرف أيضًا باسم 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 LOC
• الوحدة 2 = 1500 LOC
• الوحدة 3 = 500 LOC

إجمالي عدد Code = 1000 + 1500 + 500 = 3000

يتم حساب كثافة العيب على النحو التالي:

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

إن تطبيق نفس الحساب على كل وحدة على حدة أكثر فائدة من الرقم الإجمالي، كما يوضح الرسم البياني أدناه: تحتوي الوحدة 2 على 20 عيبًا في 1500 سطر من التعليمات البرمجية، بينما تحتوي الوحدة 3 على 10 عيوب في 500 سطر فقط من التعليمات البرمجية، لذا فإن الوحدة 3 هي الأكثر كثافة والأكثر خطورة من بين الوحدتين على الرغم من أنها أبلغت عن عدد أقل من الأخطاء.

معيار لكثافة العيوب

لا يوجد معيار ثابت لكثافة العيوب. تشير الدراسات إلى أن أحد خلل يعتبر معدل كتابة الألف سطر من التعليمات البرمجية بشكل عام علامة على جودة المشروع الجيدة، وهذا الرقم هو القاعدة العامة الأكثر شيوعًا في هذا المجال.

تتغير التوقعات بتغير المجال. فالبرمجيات الحساسة للسلامة والخاضعة للتنظيم، مثل إلكترونيات الطيران والأجهزة الطبية، تخضع لهدف أقل بكثير من عيب واحد لكل ألف سطر برمجي، بينما تتجاوز تطبيقات الأعمال العادية هذا الهدف بشكل روتيني. ولأن قواعد العد ووحدات الحجم وعمق الاختبار تختلف بين المؤسسات، فإن المعيار المأخوذ من دراسة منشورة لا يُقارن إلا بمشروع يُقاس بنفس الطريقة. لذا، فإن الاستخدام العملي لهذا المقياس داخلي: قارن إصدارًا بالإصدار السابق من نفس المنتج، بعد قياسه بنفس الطريقة.

العوامل التي تؤثر على كثافة العيوب

يمكن أن ينتج عن نفس قاعدة التعليمات البرمجية أرقام مختلفة تمامًا لكثافة العيوب اعتمادًا على العوامل التالية:

• Code تعقيد. منطق متداخل بعمق ومستوى عالٍ التعقيد السيكلوماتي ينتج عنه عيوب أكثر لكل سطر مقارنةً بالبرمجة المباشرة.
• نوع العيوب التي تم أخذها في الاعتبار. سواء اقتصر الأمر على العيوب الوظيفية فقط، أو شمل سهولة الاستخدام والتوثيق، و غير وظيفية النتائج، تغير البسط بشكل كبير.
• المدة الزمنية المأخوذة في الاعتبار. لا يمكن مقارنة الرقم الذي تم قياسه خلال دورة اختبار مدتها أسبوعان بالرقم الذي تم قياسه على مدار ستة أشهر من الاستخدام الإنتاجي.
• مهارات المطور والمختبر. يقوم المطورون ذوو الخبرة بإدخال عيوب أقل، ويكتشف المختبرون ذوو الخبرة المزيد من العيوب الموجودة، لذا فإن التأثيرين يسحبان المقياس في اتجاهين متعاكسين.
• تغطية الاختبار. العيوب التي لم يتم البحث عنها لا يتم احتسابها أبدًا، لذلك تغطية الاختبار يحدد بصمت الحد الأقصى لكثافة القياس.

كثافة العيوب مقابل مقاييس العيوب الأخرى

يجيب مؤشر كثافة العيوب على سؤال واحد: ما مدى تركيز العيوب المعروفة؟ بينما تجيب ثلاثة مؤشرات أخرى مصاحبة على الأسئلة التي لا يستطيع هذا المؤشر الإجابة عليها، وتقوم معظم الفرق بالإبلاغ عنها معًا.

عند قراءة هذه النقاط الأربع معًا، فإنها تعطي صورة أكثر اكتمالًا: انخفاض كثافة العيوب مع ارتفاع تسرب العيوب يشير إلى اختبار سطحي بدلاً من التعليمات البرمجية النظيفة، وهو بالضبط سوء الفهم الذي يحذر منه القسم التالي.

مزايا كثافة العيوب

فيما يلي مزايا كثافة العيوب:

• يساعد ذلك في قياس فعالية الاختبار.
• يساعد ذلك في التمييز بين تركيز العيوب بين المكونات ووحدات البرامج.
• وهو مفيد في تحديد المجالات التي تحتاج إلى تصحيح أو تحسين.
• وهو مفيد في تحديد المكونات عالية المخاطر، والتي تغذي مباشرة الاختبار القائم على المخاطر.
• يساعد ذلك في تحديد الاحتياجات التدريبية لمختلف الموارد.
• يمكن أن يكون ذلك مفيدًا في تقدير جهد الاختبار وإعادة العمل الناجم عن العيوب.
• يمكنه تقدير العيوب المتبقية في البرنامج.
• قبل الإصدار، يساعد ذلك في تحديد ما إذا كانت الاختبارات التي أجريت حتى الآن كافية.
• فهو يُرسي أساساً تاريخياً يمكن قياس الإصدارات اللاحقة بناءً عليه.

قيود كثافة العيوب

يسهل حساب هذا المقياس، كما يسهل إساءة فهمه. وتحدد القيود التالية مدى أهميته في قرار الإصدار:

• العيوب غير المكتشفة غير مرئية. لا يحتوي البسط إلا على العيوب التي تم اكتشافها بالفعل من خلال الاختبار، لذلك فإن الوحدة التي تم اختبارها بشكل ضعيف تُظهر رقماً مُرضياً.
• يتم تجاهل الخطورة. يُعتبر عيب واحد يؤدي إلى تلف عملية الدفع ومشكلة واحدة تتعلق بالمحاذاة التجميلية متساويين في الأهمية، ولهذا السبب هناك حاجة إلى عرض مرجح حسب درجة الخطورة إلى جانب ذلك.
• تختلف تعريفات العيوب. فريقان يقومان بالعد بطريقة مختلفة ينتجان أرقاماً لا يمكن مقارنتها، حتى داخل نفس المنظمة.
• عدد أسطر التعليمات البرمجية ليس مؤشراً دقيقاً لحجم الكود. يؤدي استخدام التعليمات البرمجية المطولة إلى تقليل الكثافة دون تحسين أي شيء، والوحدة غير قابلة للمقارنة بين لغات البرمجة المختلفة.
• يمكن التلاعب بهذا المقياس. إن رفض التقارير التي تقع على الحدود أو تضخيم عدد الأسطر كلاهما يحسن الرقم دون تحسين المنتج.

لا يجعل أي من هذا كثافة العيوب عديمة الفائدة. بل يجعلها مؤشراً للاتجاهات لمنتج واحد يتم قياسه باستمرار، بدلاً من كونها درجة لمقارنة الفرق ببعضها البعض.

كيفية تقليل كثافة العيوب

إن خفض كثافة العيوب فعلياً، وليس نظرياً فقط، يعني منع العيوب في وقت مبكر واكتشاف الباقي قبل الإصدار. الممارسات التالية هي تلك التي تتكرر في الإرشادات المنشورة:

• قم بإجراء الاختبارات في وقت مبكر. إن إشراك المختبرين في مرحلة المتطلبات والتصميم يكشف الغموض قبل أن يصبح رمزًا، وهو المكان الذي تكون فيه العيوب أرخص في إزالتها.
• Revراجع الكود قبل دمجه. تكشف مراجعة الأقران عن الأخطاء المنطقية، وسوء فهم المتطلبات، وعيوب التصميم التي لا يلاحظها أحد اختبار الوحدة كُتب للبحث عنه.
• أتمتة مجموعة اختبارات الانحدار. إجراء عمليات فحص على كل عملية إيداع من خلال التكامل المستمر يمنع هذا الإجراء عودة العيوب القديمة أثناء كتابة التعليمات البرمجية الجديدة.
• اكتب الاختبارات أولاً. اختبار يحركها التنمية يُجبر على تحديد كل سلوك قبل تنفيذه، و اختبار الطفرة ويمكن بعد ذلك التأكد من أن الاختبارات الناتجة تؤكد بالفعل شيئًا ما.
• استخدم التحليل الثابت. يقوم الفحص الآلي للتعليمات البرمجية بتحديد حالات إلغاء المراجع الفارغة، وتسريبات الموارد، ونقاط التعقيد قبل تشغيل أي اختبار.
• أعد هيكلة الوحدات النمطية الكثيفة. بمجرد أن تحدد كثافة العيوب أسوأ المكونات، فإن تقسيمها وتبسيطها عادة ما يقلل من التعقيد وعدد العيوب.
• أعد إدخال العيوب إلى العملية. يؤدي تحليل الأسباب الجذرية في جلسات التقييم إلى تحويل العيوب الفردية إلى إصلاحات في العمليات بدلاً من مجرد ترقيع لمرة واحدة.

Tracإصدار كيد على الإصدار جنبًا إلى جنب تقنيات اختبار البرمجيات وبفضل بيانات التغطية، يصبح مؤشر كثافة العيوب نظام إنذار مبكر بدلاً من كونه بطاقة تقييم.

الأسئلة الشائعة