تغطية الكود
المحتويات
- NCover
- في الممارسة
- أدوات بيرل
- معايير التغطية الأساسية
- معايير التغطية
- }
- باقي معايير التغطية
- تغطية الشرط المتعدد
- a=false, b=true
- أدوات بي إتش بي
- a=true, b=true, c=false
- a=false, b=false, c=false
- if a and b then
- Serenity
- تغطية شرط/تقرير المعدلة
- تغطية فحص تصميمات سيمانتك ل COBOL
- if (a or b) and c then
- Visual Studio 2010

بدايةً، تغطية الكود هي مقياس يستعمل في فحص البرمجيات ويقوم بوصف المرحلة التي وصل إليها فحص الكود المصدري للبرنامج. وهي إحدى صور الفحص التي يتم فيها فحص الكود بشكل مباشر وبذلك تكون إحدى صور فحص الصندوق الأبيض. بمرور الوقت، توسع استخدام تغطية الكود ليشمل مجال الالكترونيات الرقمية، والتي تعتمد منهجية تصميمها المعاصر على لغات وصف الإلكترونيات
وفي هذا السياق، كانت تغطية الكود من بين أولى الطرق التي تم اختراعها من أجل الفحص المنهجي للبرمجيات. قام ميلر وماوني بنشر أول مرجع في اتصالات رابطة مكائن الحوسبة عام 1963.
كذلك، تغطية الكود هي إحدى الاعتبارات في شهادة أمان معدات إلكترونيات الطيران. تم توثيق المعيار الذي تم من خلاله اعتماد معدات إلكترونيات الطيران بواسطة وكالة الطيران الفدرالية في DO-178B 2
NCover
- Testwell CTC++ (with Java and C# add on)
- تغطية فحص تصميمات سيمانتك ل# C
- JetBrains dotCover
- TestDriven.NET
في الممارسة
من جانب آخر، هل يمكن إرجاع الكود المستهدف بشكل مباشر إلى جمل كود المصدر؟ تحتاج شهادات محدده (DO-178B مستوىA مثلًا) إلى تغطية على مستوى التجميع وإذا لم يكن الحال كذلك: «يتعين القيام بتحقق إضافي من الكود المستهدف من أجل إنشاء تصحيح لتتابعات الأكواد المتولدة تلك» (DO-178B) para-6.4.4.2.
وفي هذا السياق، عند تنفيذ سياسات تغطية الكود ضمن بيئة تطوير برمجية ما، يجب مراعاة الآتي:
إضافةً إلى ذلك، هل سيتم قياس تغطية الكود مقابل الفحوصات التي تتحقق من المتطلبات المفروضة على المنظومة التي يتم فحصها (DO-178B)
ومن جهة أخرى، يتم بناء البرمجية المستهدفة بخيارات خاصة و/أو يتم تشغيلها من خلال بيئة خاصة بحيث يتم تعيين ممارسة (تنفيذ) كل دالة على نقاط الدالة في كود المصدر. تساعد هذه العملية المطورين وموظفي ضمان الجودة على البحث عن أجزاء المنظومة التي يتم الدخول إليها نادرا أو لم يتم الدخول إليها مطلقا في الحالات العادية (معالجة الخطأ وماشابه) وتساعد على طمأنة مهندسي الفحص على أن أغلب الشروط المهمة (نقاط الدالة) قد تم فحصها. يتم تحليل الخرج الناتج لمعرفة أي من أجزاء الكود لم يتم ممارسته ويتم تحديث الفحوصات بحيث تتضمن هذه الأجزاء كلما اقتضت الضرورة. وبالترافق مع باقي طرق تغطية الكود، يكون الهدف تطوير فحوصات تراجعية دقيقة لكن يمكن التحكم فيها.
- الأدوات البرمجية
- أدوات C/C++
- BullseyeCoverage
- Cantata++
- Insure++
- IBM Rational Pure Coverage
- Tessy
- Testwell CTC++
- Trucov
- CodeScroll
- TestCocoon
- تغطية فحص تصميمات سيمانتك ل C وسي++
- أدوات C.NET
في هذا الإطار، هناك كذلك بعض العيوب التي يتم التأثير عليها من خلال تلك الأدوات. وعلى وجه الخصوص قد لاتظهر بعض حالات التعرض أو العمليات الحساسة للوقت الحقيقي المشابهة عند تشغيلها في بيئات تغطية الكود؛ وعلى العكس قد يصبح اكتشاف بعض تلك العيوب أسهل كنتيجة للأحمال الإضافية على الكود الفحصي.
إضافةً إلى ذلك، يمكن لمهندسي الفحص أن يقوموا بإلقاء نظرة على نتائج فحص تغطية الكود بحيث تساعدهم على استنباط حالات الفحص والدخل أو مجموعات التكوين والتي ستقوم بزيادة تغطية الكود على الدوال الحيوية. هناك صورتان شائعتان لتغطية الكود يتم استخدامهما من قِبل المُختبرين وهما تغطية الجملة (أو الخط) وتغطية المسار (أو الحافة). تقوم تغطية الخط بالتبليغ على بصمة تنفيذ الفحص من حيث أي من خطوط الكود تم تنفيذها لاكمال الفحص.تقوم تغطية الحافة بالتبليغ عن أي من الفروع أونقاط تقرير الكود تم تنفيذها لاكمال الفحص. تقوم كلتا التغطيتين بالتبليغ عن ميزان التغطية والذي يقاس كنسبة مئوية. معني ذلك يعتمد على أي من صور تغطية الكود تم استخدامها حيث أن تغطية مسار 67% أكثر شمولا من تغطية جملة 67%
من جهة ثانية، ماهي متطلبات التغطية من أجل الحصول على اعتماد المنتج النهائي، وإذا كان الأمر كذلك فماهو مستوى تغطية الكود المطلوب؟ المستوى النموذجي لتقدم الدقة هو كالتالي: الجملة، الفرع/التقرير، تغطية شرط/تقرير معدّلة (MC/DC)،LCSAJ تتابع وانتقال الكود الخطي
من جهة ثانية، وبشكل عام، تتطلب أدوات تغطية الكود ومكتباتها البرمجية تكلفة آداء و/أو ذاكرة أو موارد أخرى غير مقبولة لعمليات البرمجيات المعتادة. ولذلك، يتم استخدامها فقط في المختبر. وكما يجب أن يتوقع المرء، فإن هناك درجات من البرمجيات لا يمكن اخضاعها عمليا لفحوصات التغطية تلك، ومع ذلك يمكن الوصول إلى تقريب لتعيين درجة التغطية عبر التحليل أكثر من الفحص المباشر.
أدوات بيرل
كذلك، Devel::Cover حزمة كاملة لتوليد بلاغات تغطية الكود بصيغة HTML وصيغ أخرى.
معايير التغطية الأساسية
وفي هذا السياق، تغطية الشرط (أو تغطية التوقع)- هل تم تقييم كل تعبير فرعي بولياني من حيث true أو false؟ وهذا لايعني بالضرورة تغطية التقرير.
- تغطية الشرط/التقرير – يتعين استيفاء كل من تغطية التقرير والشرط.
- مثلًا، نفترض دالة سي++ التالية:
- int foo(int x, int y)
- {
- int z = 0;
- if ((x>0) && (y>0)) {
- z = x;
- }
- return z;
وفي السياق ذاته، تغطية التقرير (تختلف عن تغطية الفرع.)هل تم تنفيذ كل حافة في البرنامج؟ مثلًا، هل تم أم لم يتم استيفاء متطلبات كل فرع من كل بنية توجيهية (كما في جمل IF وCASE)
- هناك الكثير من معايير التغطية، المعايير الرئيسية هي:
- تغطية الدالة – هل تم استدعاء كل دالة (أو إجراء) في البرنامج ؟
- تغطية الجملة – هل تم تنفيذ كل عقدة في البرنامج؟
معايير التغطية
إضافةً إلى ذلك، يتم استخدام واحد أو أكثر من معايير التغطية لقياس مدى استخدام البرنامج بواسطة حزمة فحص
}
من جهة ثانية، في اللغات، كلغة باسكال حيث لايتم تقييم العمليات البوليانية القياسية بالقصر، ليس من الضروري أن تعني تغطية الشرط تغطية التقرير. مثلًا، نفترض القطعة التالية من الكود:
علاوةً على ذلك، تغطية الجملة لهذه الدالة يتم استيفاءها عند استدعاءها مثلًا foo(1,1) كما في هذه الحالة، يتم تنفيذ كل سطر في الدالة بما فيه z=x.
وفي السياق ذاته، بافتراض أن هذه الدالة جزء من برنامج أكبر وأن هذا البرنامج يتم تشغيله بواسطة حزمة فحص ما.
وفي هذا الصدد، تستوفي فحوصات استدعاء foo(1,1) و foo (0,1) تغطية التقرير كما في الحالة الأولى عند استيفاء شرطية if وشرطية التقييم بالقصر وتنفيذ z=x; وفي الحالة الثانية لم يتم استيفاء أي من الجملتين الشرطيتين ولم يتم إقران x ب z.
وفي هذا السياق، في حالة استدعاء الدالة ‘foo’ مرة واحدة على الأقل أثناء التنفيذ، تكون تغطية الدالة لهذه الدالة قد تم استيفاءها.
وفي السياق ذاته، يمكن استيفاء تغطية الشرط من خلال فحوصات تستدعي foo(1,1) و foo (1,0) و foo (0,0). وتعتبر ضرورية حيث تُفيّم (x>0) في أول حالتين true بينما تُفيّم false في الحالة الثالثة. وفي نفس الوقت تجعل الحالة الأولى (y>0) true بينما تجعلها الحالتين الثانية والثالثة false
باقي معايير التغطية
ومن ناحية أخرى، تتصل بعض معايير التغطية بالأعلى. مثلًا، تعني تغطية المسار تغطية التقرير والجملة ودخول/خروج. تعني تغطية التقرير تغطية الجملة لأن كل جملة جزء من فرع ما.
وفي هذا الصدد، تحاول طرق تغطية المسار العملية بدلا من ذلك التعرف على درجات مسارات الكود التي تختلف فقط في عدد تنفيذات الكود لتحقيق تغطية «المسار الأساسي». ينبغي على المختبر تغطية كل درجات المسار.
ومن ناحية أخرى، تغطية تتابع وانتقال الكود الخطي (LCSAJ) – هل تم تنفيذ كل LCSAJ؟
من جهة ثانية، تحتاج تطبيقات السلامة الحرجة غالبا إلى برهنة أن الفحص يحقق 100% من بعض صور تغطية الكود.
وفي هذا الصدد، تغطية المسار الكامل، النوع المذكور بالأعلى يكون عادة غير عملي أو غير ممكن.أي وحدة تحتوي على تتابع ن تقرير داخلها يمكن أن يكون ضمنها عدد مسارات حتى 2n ؛ يمكن أن ينتج عن تركيبات الحلقات عدد لانهائي من المسارات. قد يكون الكثير من المسارات كذلك غير قابل للتطبيق، والتي لايكون فيها دخل للبرنامج ضمن الفحص الذي يمكن أن يتسبب في تنفيذ هذا المسار المحدد. ومع ذلك تم برهنة إمكانية ايجاد خوارزمية غرض عام للتعرف على المسارات غير القابلة للتطبيق (يمكن استخدام مثل هذه الخوارزمية لحل مشكلة التوقف.
هناك معايير تغطية أخرى تُستعمل بشكل أقل:
- تغطية المسار – هل تم تنفيذ كل مسار ممكن عبر جزء مُعطى من الكود؟
- تغطية دخول/خروج - هل تم تنفيذ كل استدعاء ورجوع ممكن للدالة؟
- تغطية الحلقات – هل تم تنفيذ كل حلقة ممكنة عدد مرات صفر وواحد وأكثر من واحد؟
وفي هذا السياق، تغطية مسار JJ- هل تم تنفيذ انتقال كل المنتقلات إلى مسارات الانتقال (تعرف كذلك باسم LCSAJs)
تغطية الشرط المتعدد
- 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
في هذا الإطار، تتطلب هذه المعايير فحص كل التركيبات الشرطية داخل كل تقرير. مثلًا، تحتاج قطعة الكود من القسم السابق إلى ثمانية فحوصات:
a=false, b=true
من جانب آخر، ومع ذلك، فإن مجموعة الفحوصات تلك لاتستوفي تغطية التقرير حيث لن يتم استيفاء شرط if في أي من الحالات
وفي هذا الصدد، قد يكون إدخال العيوب ضروريا من أجل ضمان تغطية كافية لشروط وفروع كود إدارة الاستثناء أثناء الفحص
أدوات بي إتش بي
- PHPUnit كذلك تحتاج إلى Xdebug لعمل بلاغات تغطية
- تغطية فحص تصميمات سيمانتك ل PHP
- أدوات PLSQL
- تغطية فحص تصميمات سيمانتك ل PLSQL
- أدوات بايثون
- Coverage.py
- أدوات الأجهزة الإلكترونية
- Aldec
- Atrenta
- كيدانس لأنظمة التصميم
- JEDA Technologies
- Mentor Graphics
- Nusym Technology
- Simucad Design Automation
- سينوبسيس
- انظر كذلك
- مقياس مكابي
- مقياس برمجي
- المراجع
a=true, b=true, c=false
في هذا الإطار، تؤثر القيم بالخط البارز على الناتج، ينبغي أن يتواجد كل متغير كقيمة مؤثرة مرة واحدة على الأقل مع false ومرة مع true
a=false, b=false, c=false
- a=false, b=false, c=true
- a=true, b=false, c=true
- a=false, b=true, c=true
من جهة ثانية، ومع ذلك، لن تستوفي مجموعة الفحوصات الموجودة بالأعلى تغطية شرط/تقرير المعدّلة، حيث لن تؤثر القيمة"b" في الفحص الأول والقيمة "c" في الفحص الثاني على الناتج. وبذلك نحتاج إلى مجموعة الفحص التالية لاستيفاء MC/DC
if a and b then
يمكن استيفاء تغطية الشرط من خلال فحصين:
a=true, b=false
Serenity
Testwell CTC++ (with Java and C# add on)
تغطية فحص تصميمات سيمانتك ل Java
تغطية شرط/تقرير المعدلة
وفي هذا الصدد، في تطبيقات السلامة الحرجة (مثلًا. برمجيات إلكترونيات الطيران) غالبا ماتكون هناك حاجة إلى استيفاء تغطية شرط/تقرير معدلة C/DCهذه المعايير هي امتداد لمعايير شرط/تقرير مع تطلب قيام كل شرط بالتأثير على ناتج التقرير بشكل مستقل. مثلًا، نفترض الكود التالي:
تغطية فحص تصميمات سيمانتك ل COBOL
- أدوات جاوة (جزيرة)
- Clover
- Cobertura
- Structure 101
- EMMA
- Jtest
if (a or b) and c then
a=true, b=true, c=true
ومن ناحية أخرى، يتم استيفاء معايير شرط/تقرير من خلال مجموعة الفحوصات التالية:
Visual Studio 2010
- PartCover (Open Source)
- OpenCover (Open Source)
- أدوات كوبول
📝 هل في هذه المقالة خطأ؟
إذا وجدت معلومة تحتاج تصحيحاً أو إضافة، أو أردت حذف المقالة، أرسل لنا طلباً وسنراجعه.
ما رأيك في هذه المقالة؟