الرئيسيةعريقبحث

تغطية الكود

☰ جدول المحتويات

تغطية الكود هي مقياس يستخدم في فحص البرمجيات ويقوم بوصف المرحلة التي وصل إليها فحص الكود المصدري للبرنامج. وهي إحدى صور الفحص التي يتم فيها فحص الكود بشكل مباشر وبذلك تكون إحدى صور فحص الصندوق الأبيض.[1]. بمرور الوقت، توسع استخدام تغطية الكود ليشمل مجال الالكترونيات الرقمية، والتي تعتمد منهجية تصميمها المعاصر على لغات وصف الإلكترونيات

كانت تغطية الكود من بين أولى الطرق التي تم اختراعها من أجل الفحص المنهجي للبرمجيات. قام ميلر وماوني بنشر أول مرجع في اتصالات رابطة مكائن الحوسبة عام 1963.[2]

تغطية الكود هي إحدى الاعتبارات في شهادة أمان معدات إلكترونيات الطيران. تم توثيق المعيار الذي تم من خلاله اعتماد معدات إلكترونيات الطيران بواسطة وكالة الطيران الفدرالية في DO-178B 2[3]

معايير التغطية

يتم استخدام واحد أو أكثر من معايير التغطية لقياس مدى استخدام البرنامج بواسطة حزمة فحص

معايير التغطية الأساسية

هناك العديد من معايير التغطية، المعايير الرئيسية هي:[4]

  • تغطية الدالة – هل تم استدعاء كل دالة (أو إجراء) في البرنامج ؟
  • تغطية الجملة – هل تم تنفيذ كل عقدة في البرنامج؟
  • تغطية التقرير (تختلف عن تغطية الفرع..[5])هل تم تنفيذ كل حافة في البرنامج؟ على سبيل المثال، هل تم أم لم يتم استيفاء متطلبات كل فرع من كل بنية توجيهية (كما في جمل IF وCASE)
  • تغطية الشرط(أو تغطية التوقع)- هل تم تقييم كل تعبير فرعي بولياني من حيث true أو false؟ وهذا لايعني بالضرورة تغطية التقرير.
  • تغطية الشرط/التقرير – يتعين استيفاء كل من تغطية التقرير والشرط.

على سبيل المثال، نفترض دالة سي++ التالية:

int foo(int x, int y) { int z = 0; if ((x>0) && (y>0)) { z = x; } return z; }

بافتراض أن هذه الدالة جزء من برنامج أكبر وأن هذا البرنامج يتم تشغيله بواسطة حزمة فحص ما.

  • في حالة استدعاء الدالة ‘foo’ مرة واحدة على الأقل أثناء التنفيذ، تكون تغطية الدالة لهذه الدالة قد تم استيفاءها.
  • تغطية الجملة لهذه الدالة يتم استيفاءها عند استدعاءها على سبيل المثال foo(1,1) كما في هذه الحالة، يتم تنفيذ كل سطر في الدالة بما فيه z=x.
  • تستوفي فحوصات استدعاء foo(1,1) و foo (0,1) تغطية التقرير كما في الحالة الأولى عند استيفاء شرطية if وشرطية التقييم بالقصر وتنفيذ z=x; وفي الحالة الثانية لم يتم استيفاء أي من الجملتين الشرطيتين ولم يتم إقران x ب z.
  • يمكن استيفاء تغطية الشرط من خلال فحوصات تستدعي foo(1,1) و foo (1,0) و foo (0,0). وتعتبر ضرورية حيث تُفيّم (x>0) في أول حالتين true بينما تُفيّم false في الحالة الثالثة. وفي نفس الوقت تجعل الحالة الأولى (y>0) true بينما تجعلها الحالتين الثانية والثالثة false

في اللغات، كلغة باسكال حيث لايتم تقييم العمليات البوليانية القياسية بالقصر، ليس من الضروري أن تعني تغطية الشرط تغطية التقرير. على سبيل المثال، نفترض القطعة التالية من الكود:

if a and b then

يمكن استيفاء تغطية الشرط من خلال فحصين:

  • a=true, b=false
  • a=false, b=true

ومع ذلك، فإن مجموعة الفحوصات تلك لاتستوفي تغطية التقرير حيث لن يتم استيفاء شرط if في أي من الحالات

قد يكون إدخال العيوب ضروريا من أجل ضمان تغطية كافية لشروط وفروع كود إدارة الاستثناء أثناء الفحص

تغطية شرط/تقرير المعدلة

في تطبيقات السلامة الحرجة (على سبيل المثال. برمجيات إلكترونيات الطيران) غالبا ماتكون هناك حاجة إلى استيفاء تغطية شرط/تقرير معدلة C/DCهذه المعايير هي امتداد لمعايير شرط/تقرير مع تطلب قيام كل شرط بالتأثير على ناتج التقرير بشكل مستقل. على سبيل المثال، نفترض الكود التالي:

if (a or b) and c then

يتم استيفاء معايير شرط/تقرير من خلال مجموعة الفحوصات التالية:

  • a=true, b=true, c=true
  • a=false, b=false, c=false

ومع ذلك، لن تستوفي مجموعة الفحوصات الموجودة بالأعلى تغطية شرط/تقرير المعدّلة، حيث لن تؤثر القيمة"b" في الفحص الأول والقيمة "c" في الفحص الثاني على الناتج. وبذلك نحتاج إلى مجموعة الفحص التالية لاستيفاء MC/DC

  • a=false, b=false, c=true
  • a=true, b=false, c=true
  • a=false, b=true, c=true
  • a=true, b=true, c=false

تؤثر القيم بالخط البارز على الناتج، ينبغي أن يتواجد كل متغير كقيمة مؤثرة مرة واحدة على الأقل مع false ومرة مع true

تغطية الشرط المتعدد

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

  • a=false, b=false, c=false
  • a=false, b=false, c=true
  • a=false, b=true, c=false
  • a=false, b=true, c=true
  • a=true, b=false, c=false
  • a=true, b=false, c=true
  • a=true, b=true, c=false
  • a=true, b=true, c=true

باقي معايير التغطية

هناك معايير تغطية أخرى تُستخدم بشكل أقل:

  • تغطية تتابع وانتقال الكود الخطي (LCSAJ) – هل تم تنفيذ كل LCSAJ؟
  • تغطية مسار JJ- هل تم تنفيذ انتقال كل المنتقلات إلى مسارات الانتقال[6] (تعرف أيضا باسم LCSAJs)
  • تغطية المسار – هل تم تنفيذ كل مسار ممكن عبر جزء مُعطى من الكود؟
  • تغطية دخول/خروج - هل تم تنفيذ كل استدعاء ورجوع ممكن للدالة؟
  • تغطية الحلقات – هل تم تنفيذ كل حلقة ممكنة عدد مرات صفر وواحد وأكثر من واحد؟

تحتاج تطبيقات السلامة الحرجة غالبا إلى برهنة أن الفحص يحقق 100% من بعض صور تغطية الكود.

تتصل بعض معايير التغطية بالأعلى. على سبيل المثال، تعني تغطية المسار تغطية التقرير والجملة ودخول/خروج. تعني تغطية التقرير تغطية الجملة لأن كل جملة جزء من فرع ما.

تغطية المسار الكامل، النوع المذكور بالأعلى يكون عادة غير عملي أو غير ممكن.أي وحدة تحتوي على تتابع ن تقرير داخلها يمكن أن يكون ضمنها عدد مسارات حتى 2n ؛ يمكن أن ينتج عن تركيبات الحلقات عدد لانهائي من المسارات. قد يكون العديد من المسارات أيضا غير قابل للتطبيق، والتي لايكون فيها دخل للبرنامج ضمن الفحص الذي يمكن أن يتسبب في تنفيذ هذا المسار المحدد. ومع ذلك تم برهنة إمكانية ايجاد خوارزمية غرض عام للتعرف على المسارات غير القابلة للتطبيق (يمكن استخدام مثل هذه الخوارزمية لحل مشكلة التوقف.[7] تحاول طرق تغطية المسار العملية بدلا من ذلك التعرف على درجات مسارات الكود التي تختلف فقط في عدد تنفيذات الكود لتحقيق تغطية "المسار الأساسي". ينبغي على المختبر تغطية كل درجات المسار.

في الممارسة

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

عند تنفيذ سياسات تغطية الكود ضمن بيئة تطوير برمجية ما، يجب مراعاة الآتي:

  • ماهي متطلبات التغطية من أجل الحصول على اعتماد المنتج النهائي، وإذا كان الأمر كذلك فماهو مستوى تغطية الكود المطلوب؟ المستوى النموذجي لتقدم الدقة هو كالتالي: الجملة، الفرع/التقرير، تغطية شرط/تقرير معدّلة (MC/DC)،LCSAJ تتابع وانتقال الكود الخطي
  • هل سيتم قياس تغطية الكود مقابل الفحوصات التي تتحقق من المتطلبات المفروضة على المنظومة التي يتم فحصها (DO-178B)
  • هل يمكن إرجاع الكود المستهدف بشكل مباشر إلى جمل كود المصدر؟ تحتاج شهادات محدده (DO-178B مستوىA على سبيل المثال) إلى تغطية على مستوى التجميع وإذا لم يكن الحال كذلك: "يتعين القيام بتحقق إضافي من الكود المستهدف من أجل إنشاء تصحيح لتتابعات الأكواد المتولدة تلك" (DO-178B) para-6.4.4.2.[3]

يمكن لمهندسي الفحص أن يقوموا بإلقاء نظرة على نتائج فحص تغطية الكود بحيث تساعدهم على استنباط حالات الفحص والدخل أو مجموعات التكوين والتي ستقوم بزيادة تغطية الكود على الدوال الحيوية. هناك صورتان شائعتان لتغطية الكود يتم استخدامهما من قِبل المُختبرين وهما تغطية الجملة (أو الخط) وتغطية المسار (أو الحافة). تقوم تغطية الخط بالتبليغ على بصمة تنفيذ الفحص من حيث أي من خطوط الكود تم تنفيذها لاكمال الفحص.تقوم تغطية الحافة بالتبليغ عن أي من الفروع أونقاط تقرير الكود تم تنفيذها لاكمال الفحص. تقوم كلتا التغطيتين بالتبليغ عن ميزان التغطية والذي يقاس كنسبة مئوية. معني ذلك يعتمد على أي من صور تغطية الكود تم استخدامها حيث أن تغطية مسار 67% أكثر شمولا من تغطية جملة 67% وبشكل عام، تتطلب أدوات تغطية الكود ومكتباتها البرمجية تكلفة آداء و/أو ذاكرة أو موارد أخرى غير مقبولة لعمليات البرمجيات المعتادة. ولذلك، يتم استخدامها فقط في المختبر. وكما يجب أن يتوقع المرء، فإن هناك درجات من البرمجيات لا يمكن اخضاعها عمليا لفحوصات التغطية تلك، ومع ذلك يمكن الوصول إلى تقريب لتعيين درجة التغطية عبر التحليل أكثر من الفحص المباشر.

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

الأدوات البرمجية

أدوات C/C++

أدوات C#.NET

أدوات كوبول

  • تغطية فحص تصميمات سيمانتك ل COBOL

أدوات جاوة (جزيرة)

  • Clover
  • Cobertura
  • Structure 101
  • EMMA
  • Jtest
  • Serenity
  • Testwell CTC++ (with Java and C# add on)
  • تغطية فحص تصميمات سيمانتك ل Java

أدوات بيرل

  • Devel::Cover حزمة كاملة لتوليد بلاغات تغطية الكود بصيغة HTML وصيغ أخرى.

أدوات بي إتش بي

  • PHPUnit أيضا تحتاج إلى Xdebug لعمل بلاغات تغطية
  • تغطية فحص تصميمات سيمانتك ل PHP

أدوات PLSQL

  • تغطية فحص تصميمات سيمانتك ل PLSQL

أدوات بايثون

أدوات الأجهزة الإلكترونية

مقالات ذات صلة

المراجع

  1. Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. صفحة 254.  . مؤرشف من الأصل في 09 ديسمبر 2017.
  2. Joan C. Miller, Clifford J. Maloney (1963). "Systematic mistake analysis of digital computer programs". Communications of the ACM. New York, NY, USA: ACM. 6 (2): 58–63. doi:10.1145/366246.366248. ISSN 0001-0782. مؤرشف من الأصل في 6 مايو 2020.
  3. RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, December 1, 1992.
  4. Glenford J. Myers (2004). The Art of Software Testing, 2nd edition. Wiley. .
  5. Position Paper CAST-10 (June 2002). What is a “Decision” in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)? نسخة محفوظة 14 مايو 2017 على موقع واي باك مشين.
  6. M. R. Woodward, M. A. Hennell, "On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC", Information and Software Technology 48 (2006) pp. 433-440
  7. Dorf,Richard C.: Computers, Software Engineering, and Digital Devices, Chapter 12, pg. 15. CRC Press, 2006. , 9780849373404; via Google Book Search - تصفح: "infeasible+path"+"halting+problem"&source=web&ots=WUWz3qMPRv&sig=dSAjrLHBSZJcKWZfGa_IxYlfSNA&hl=en&sa=X&oi=book_result&resnum=1&ct=result نسخة محفوظة 6 مايو 2020 على موقع واي باك مشين.

وصلات خارجية

موسوعات ذات صلة :