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

اختبار الطفرة

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

يستخدم اختبار الطفرات (أو تحليل الطفرة ) لتصميم الاختبارات للبرامج الجديدة وتقييم جودة اختبارات البرامج الموجودة. ينطوي اختبار الطفرة على تعديل برنامج في الطرق الصغيرة، ويسمى ”1“ كل إصدار تحور الطفرة واختبارات كشف ورفض الطفرة من خلال التسبب في سلوك الإصدار الأصلي للتختلف عن الطفرة.

التعريف

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

الهدف منه

يمكن إنشاء اختبارات للتحقق من صحة تنفيذ نظام لبرنامج معين، ولكن انشاء الاختبارات لا تزال تطرح مسألة ما إذا كانت الاختبارات صحيحة وتغطي بما فيه الكفاية المتطلبات التي تكون قد نشأت في التنفيذ. (هذه مشكلة التكنولوجية هي نفسها مثيل لمشكلة أعمق فلسفيا التي تسمى [Quis custodiet ipsos custodes?"]

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

لمحه تاريخيه

اقترح اختبار طفرة في الأصل من قبل Richard Lipton كطالب في عام 1971، وضعت لأول مرة والتي نشرتها [DeMillo LiptonوSayward ] وكان تنفيذهالأول أداة اختبار للطفرات التي كتبها  Timothy Budd كجزء من عمل على درجة الدكتوراه (بعنوان تحليل الطفرة) في عام 1980 من جامعة ييل.

في الآونة الأخيرة، مع توافر القدرة الحاسوبية الهائلة، كان هناك انبعاث للتحليل الطفرة داخل مجتمع علوم الكمبيوتر، وأنجز العمل على تحديد أساليب تطبيق الاختبار لطفرة في الاعتراض للغات البرمجة الموجهة واللغات غير الإجرائية مثل XML، SMV، وأجهزة الدولة محدودة.

في عام 2004 شركة تدعى شركة Certess (وهي الآن جزء من سينوبسيس) بمد العديد من المبادئ في مجال التحقق من الأجهزة. في حين أن تحليل الطفرة يتوقع فقط لاكتشاف الفرق في الكمية المنتجة، Certess يمتد هذا عن طريق التحقق من أن المدقق في testbench سيتم الكشف عن الفرق الواقع. هذا التمديد يعني أن جميع المراحل الثلاث من التحقق، وهي: تفعيل، ونشر وكشف وتقييمها. دعوه هذا التأهيل الوظيفي.

ويمكن اعتبار التضبيب أن تكون حالة خاصة من اختبار الطفرات. في التضبيب، الرسائل أو البيانات المتبادلة داخل واجهات الاتصال (سواء داخل أو بين مثيلات البرامج) والطفرة للحاق بالفشل أو الاختلافات في معالجة البيانات. [5](Codenomicon 2001) و (Mu Dynamics 2005) تطورت مفاهيم التضبيب إلى اتمام منصة اختبار الطفرة، الكاملة مع المراقبين لممارسة بدقة تطبيقات البروتوكول.

نظره عامه

ويستند اختبار الطفرة على فرضيتين.

الأول هو فرضية المبرمج المختصة: وتنص هذه الفرضية أن معظم أخطاء البرامج المقدمة من قبل المبرمجين ذوي الخبرة هي نتيجة لأخطاء النحوية الصغيرة، [1]

الفرضية الثانية وتسمى تأثير الاقتران: ويؤكد تأثير الاقتران أن أخطاء بسيطة يمكن التتابع أو الزوجين لتشكيل الأخطاء الناشئة الأخرى. [6] [7]

وكشفت أخطاء خفية ومهمة أيضا الطفرة العليا، الأمر الذي يزيد من دعم تأثير الاقتران. [8] [9] [10] [11] [12] يتم تمكين النظام العالي لطفرات من خلال انشاء الطفرة مع أكثر من واحدة.

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

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

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

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

على سبيل المثال، والنظر في C ++ جزء التعليمات البرمجية التالية:

}(if (a && b { ;c = 1 } else {;c = 0

ان المشغل حالة تحور محل && مع || وتنتج الطفرة التالية:

}(if (a || b { ;c = 1 } else {;c = 0

الآن، للاختبار لقتل هذا المسخ، يجب أن تتحقق الشروط الثلاثة التالية:

وهناك اختبار يجب أن تصل البيان للطفرة. يجب لبيانات الاختبار المدخلة ان تصيب دوال البرنامج من خلال التسبب في الدوال المختلفة لبرنامج الطفرة والبرنامج الأصلي. على سبيل المثال، فإن الاختبار مع A= 1 و B= 0 للقيام بذلك. دوال البرنامج الغير صحيح (قيمة ‘c') يجب نشرها إلى البرنامج ويتم فحصها من قبل الاختبار. تسمى هذه الظروف مجتمعة نموذج [RIP [3 .

مشغلو الطفرة

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

1- بيان الحذف

2- بيان النسخ أو الإدراج، على سبيل المثال انتقل إلى الفشل.

3- استبدال subexpressions منطقية مع الصواب والخطأ

4- استبدال بعض العمليات الحسابية مع الآخرين، على سبيل المثال + مع *، - مع /

5- استبدال بعض العلاقات المنطقية مع الآخرين، على سبيل المثال > مع>=، == و <=

6- استبدال المتغيرات مع الآخرين من نفس النطاق (يجب أن تكون أنواع متغير متوافقة)

7- النتيجة لطفرة = عدد من الطفرات المقتولة / العدد الكلي للطفرات

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

[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16]

Mutation Operators for Concurrent Java (J2SE 5.0) by Jeremy S. Bradbury, James R. Cordy, Juergen Dingel.

[17][18]

المراجع

  1. 1.^ Jump up to:a b c Richard A. DeMillo, Richard J. Lipton, and Fred G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34-41. April 1978.
  2. 2.^ Jump up to:a b Paul Ammann and Jeff Offutt. Introduction to Software Testing. Cambridge University Press, 2008.
  3. 3.^ Jump up to:a b Mutation 2000: Uniting the Orthogonal by A. Jefferson Offutt and Roland H. Untch.
  4. 4.Jump up^ Tim A. Budd, Mutation Analysis of Program Test Data. PhD thesis, Yale University New Haven CT, 1980.
  5. 5.Jump up^ Kaksonen, Rauli. A Functional Method for Assessing Protocol Implementation Security (Licentiate thesis). Espoo. 2001.
  6. 6.Jump up^ A. Jefferson Offutt. 1992. Investigations of the software testing coupling effect. ACM Trans. Softw. Eng. Methodol. 1, 1 (January 1992), 5-20.
  7. 7.Jump up^ A. T. Acree, T. A. Budd, R. A. DeMillo, R. J. Lipton, and F. G. Sayward, "Mutation Analysis," Georgia Institute of Technology, Atlanta, Georgia, Technique Report GIT-ICS-79/08, 1979.
  8. Yue Jia; Harman, M., "Constructing Subtle Faults Using Higher Order Mutation Testing," Source Code Analysis and Manipulation, 2008 Eighth IEEE International Working Conference on , vol., no., pp.249,258, 28-29 Sept. 2008
  9. Maryam Umar, "An Evaluation of Mutation Operators For Equivalent Mutants," MS Thesis, 2006
  10. Smith B., "On Guiding Augmentation of an Automated Test Suite via Mutation Analysis," 2008
  11. Polo M. and Piattini M., "Mutation Testing: practical aspects and cost analysis," University of Castilla-La Mancha (Spain), Presentation, 2009
  12. Anderson S., "Mutation Testing", the University of Edinburgh, School of Informatics, Presentation, 2011
  13. P. G. Frankl, S. N. Weiss, and C. Hu. All-uses versus mutation testing: An experimental comparison of effectiveness. Journal of Systems and Software, 38:235–253, 1997.
  14. Overcoming the Equivalent Mutant Problem: A Systematic Literature Review and a Comparative Experiment of Second Order Mutation by L. Madeyski, W. Orzeszyna, R. Torkar, M. Józala. IEEE Transactions on Software Engineering
  15. Apple's SSL/TLS bug by Adam Langley.
  16. MuJava: An Automated Class Mutation System by Yu-Seung Ma, Jeff Offutt and Yong Rae Kwo.
  17. Mutation of Java Objects by Roger T. Alexander, James M. Bieman, Sudipto Ghosh, Bixia Ji.
  18. Mutation-based Testing of Buffer Overflows, SQL Injections, and Format String Bugs by H. Shahriar and M. Zulkernine.

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