اختبار الطفرة
يستخدم اختبار الطفرات (أو تحليل الطفرة ) لتصميم الاختبارات للبرامج الجديدة وتقييم جودة اختبارات البرامج الموجودة. اختبار الطفرة ينطوي على تعديل برنامج في الطرق الصغيرة، ويسمى ”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 ++ جزء التعليمات البرمجية التالية:
ان المشغل حالة تحور محل && مع || وتنتج الطفرة التالية:
الآن، للاختبار لقتل هذا المسخ، يجب أن تتحقق الشروط الثلاثة التالية:
وهناك اختبار يجب أن تصل البيان للطفرة.
يجب لبيانات الاختبار المدخلة ان تصيب دوال البرنامج من خلال التسبب في الدوال المختلفة لبرنامج الطفرة والبرنامج الأصلي. 
على سبيل المثال، فإن الاختبار مع A= 1 و B= 0 للقيام بذلك.
دوال البرنامج الغير صحيح (قيمة ‘c') يجب نشرها إلى البرنامج ويتم فحصها من قبل الاختبار.
تسمى هذه الظروف مجتمعة نموذج [RIP [3 .
تم استكشاف العديد من المشغلين لطفرة من قبل الباحثين. وهنا بعض الأمثلة من مشغلين الطفرة للغات حتمية :
1- بيان الحذف
2- بيان النسخ أو الإدراج، على سبيل المثال انتقل إلى الفشل.
3- استبدال subexpressions منطقية مع الصواب والخطأ
4- استبدال بعض العمليات الحسابية مع الآخرين، على سبيل المثال + مع *، - مع /
5- استبدال بعض العلاقات المنطقية مع الآخرين، على سبيل المثال > مع>=، == و <=
6- استبدال المتغيرات مع الآخرين من نفس النطاق (يجب أن تكون أنواع متغير متوافقة)
7- النتيجة لطفرة = عدد من الطفرات المقتولة / العدد الكلي للطفرات
ويطلق على هؤلاء المشغلين لطفرة أيضا المشغلين لطفرة التقليدية. وهناك أيضا شركات طفرة للغات وجوه المنحى، لهياكل المتزامنة،كائنات معقدة مثل حاويات، ويطلق على مشغلي للحاويات مشغلي طفرة على مستوى الصف. على سبيل المثال أداة muJava تقدم مختلف المشغلين طفرة على مستوى الطبقة مثل وصول معدل التغيير، نوع المصبوب مشغل الإدراج، ونوع المصبوب مشغل الحذف. كما تم تطوير المشغلين طفرة لأداء الاختبار الأمني ضعف برامج