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

يُستخدم اختبار الطفرات (أو تحليل الطفرات أو طفرة البرنامج ) لتصميم اختبارات برمجية جديدة وتقييم جودة الاختبارات البرمجية الحالية. يتضمن اختبار الطفرات إجراء تغييرات طفيفة على البرنامج قيد الاختبار. ^{[ 1 ]} يُطلق على كل نسخة مُعدّلة اسم " طفرة" . يكتشف الاختبار الطفرة، وبالتالي يرفضها عند فشل الاختبار - يشير الفشل إلى أن الاختبار قد نجح في تمييز أن سلوك الطفرة يختلف عن سلوك الكود الأصلي. يُطلق على الرفض اسم " إزالة الطفرة". تُقاس قيمة مجموعة الاختبارات بنسبة الطفرات التي تُزيلها. يمكن بعد ذلك تحسين مجموعة الاختبارات بإضافة اختبارات جديدة مُصممة لإزالة طفرات إضافية.

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

اختبار الطفرات هو شكل من أشكال اختبار الصندوق الأبيض . ^{[ 2 ] [ 3 ]} والغرض منه هو مساعدة المختبِر على تطوير اختبارات انحدار فعالة من خلال تحديد نقاط الضعف في بيانات الاختبار المستخدمة لاختبار البرنامج واكتشاف أجزاء من كود البرنامج المختبر التي نادرًا ما يتم الوصول إليها أو لا يتم الوصول إليها أبدًا أثناء التنفيذ .

يتناول معظم هذا المقال "تعديل البرامج"، حيث يتم تغيير البرنامج نفسه. ويُعرّف تحليل التعديلات بشكل أعم بأنه استخدام قواعد محددة بدقة، مبنية على البنى النحوية، لإجراء تغييرات منهجية على مكونات البرمجيات. ^{[ 4 ]} وقد طُبّق تحليل التعديلات على مشاكل أخرى، ولكنه يُستخدم عادةً في مجال الاختبار. لذا، يُعرّف اختبار التعديلات بأنه استخدام تحليل التعديلات لتصميم اختبارات برمجية جديدة أو لتقييم الاختبارات البرمجية الحالية. ^{[ 4 ]} وبالتالي، يمكن تطبيق تحليل التعديلات واختبارها على نماذج التصميم، والمواصفات، وقواعد البيانات، والاختبارات، وXML، وأنواع أخرى من مكونات البرمجيات، مع أن تعديل البرامج هو الأكثر شيوعًا. ^{[ 5 ]}

Tests can be created to verify the correctness of the implementation of a given software system, but the creation of tests still poses the question of whether the tests are correct and sufficiently cover the requirements associated with the implementation.^[6] (This technological problem is itself an instance of a deeper philosophical problem named "Quis custodiet ipsos custodes?" ["Who will guard the guards?"].)

The idea behind mutation testing is that the program being tested works as intended, so if a mutant is introduced and functionality changes this means a bug is introduced, which the tests should then find. In this way, the tests are tested. If a mutant is not detected by the test suite, this typically indicates that the test suite is unable to locate the faults represented by the mutant, but it can also indicate that the mutation introduces no faults. That is, the mutation is a valid change, one that either produces a desired result or one that does not affect functionality. One (common) way a mutant can be valid is that the code that has been changed is "dead code" that is never executed.

For mutation testing to function at scale, a large number of mutants are usually introduced, leading to the compilation and execution of an extremely large number of copies of the program. This problem of the expense of mutation testing had reduced its practical use as a method of software testing. However, the increased use of object-oriented programming languages and unit testing frameworks has led to the creation of mutation testing tools that test individual portions of an application.

The goals of mutation testing are multiple:

• identify weakly tested pieces of code (those for which mutants are not killed)^[1]
• identify weak tests (those that never kill mutants)^[7]
• compute the mutation score,^[4] the mutation score is the number of mutants killed / total number of mutants.
• learn about error propagation and state infection in the program

Mutation testing was originally proposed by Richard Lipton as a student in 1971,^[8] and first developed and published by DeMillo, Lipton and Sayward.^[1] The first implementation of a mutation testing tool was by Timothy Budd as part of his PhD work (titled Mutation Analysis) in 1980 from Yale University.^[9]

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

في عام ٢٠٠٤، قامت شركة سيرتيس (التي أصبحت الآن جزءًا من سينوبسيس ) بتوسيع نطاق العديد من المبادئ لتشمل مجال التحقق من الأجهزة. فبينما يقتصر تحليل الطفرات على اكتشاف اختلاف في المخرجات، تتجاوز سيرتيس ذلك بالتحقق من قدرة أداة الفحص في بيئة الاختبار على اكتشاف هذا الاختلاف فعليًا. ويعني هذا التوسع تقييم جميع مراحل التحقق الثلاث، وهي: التنشيط، والانتشار، والاكتشاف. وقد أطلقوا على هذه العملية اسم التأهيل الوظيفي.

يمكن اعتبار اختبار التشويش حالة خاصة من اختبار الطفرات. في اختبار التشويش، تُجرى تعديلات على الرسائل أو البيانات المتبادلة داخل واجهات الاتصال (سواء داخل البرنامج نفسه أو بين نسخ البرنامج المختلفة) لاكتشاف حالات الفشل أو الاختلافات في معالجة البيانات. وقد طوّرت شركتا Codenomicon ^{[ 10 ]} (2001) و Mu Dynamics (2005) مفاهيم اختبار التشويش إلى منصة اختبار طفرات متكاملة ذات حالة كاملة، مزودة بأجهزة مراقبة لاختبار تطبيقات البروتوكولات بدقة.

يعتمد اختبار الطفرات على فرضيتين. الأولى هي فرضية المبرمج الكفء ، التي تنص على أن المبرمجين الكفء يكتبون برامج قريبة من الصحة. ^{[ 1 ]} ويُقصد بكلمة "قريبة" هنا السلوك، وليس القواعد النحوية. أما الفرضية الثانية فتُسمى تأثير الاقتران، الذي يؤكد أن الأخطاء البسيطة قد تتسلسل أو تترابط لتُشكل أخطاءً ناشئة أخرى. ^{[ 11 ] [ 12 ]}

تكشف الطفرات من الرتبة الأعلى عن عيوب دقيقة وهامة، مما يدعم تأثير الاقتران. ^{[ 13 ] [ 14 ] [ 7 ] [ 15 ] [ 16 ]} وتُمكن الطفرات من الرتبة الأعلى من خلال إنشاء طفرات تحتوي على أكثر من طفرة واحدة.

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

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

إذا كان ( أ && ب ) { ج = 1 ؛ } وإلا { ج = 0 ؛ }

سيقوم عامل الطفرة الشرطية باستبدال &&و ||إنتاج الطفرة التالية:

إذا كان ( أ || ب ) { ج = 1 ؛ } وإلا { ج = 0 ؛ }

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

1. يجب أن يصل الاختبار إلى العبارة المعدلة.
2. ينبغي أن تؤثر بيانات الإدخال التجريبية على حالة البرنامج من خلال إحداث حالات مختلفة للبرنامج المُعدَّل والبرنامج الأصلي. على سبيل المثال، سيؤدي اختبار باستخدام ` a = 1and` b = 0إلى تحقيق ذلك.
3. يجب أن تنتقل حالة البرنامج غير الصحيحة (قيمة 'c') إلى مخرجات البرنامج وأن يتم التحقق منها بواسطة الاختبار.

تُسمى هذه الشروط مجتمعة بنموذج RIP . ^{[ 8 ]}

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

مع ذلك، توجد حالات لا يمكن فيها إيجاد حالة اختبار قادرة على القضاء على هذا البرنامج المُعدَّل. ويكون البرنامج الناتج مكافئًا سلوكيًا للبرنامج الأصلي. وتُسمى هذه البرامج المُعدَّلة بالبرامج المكافئة .

يُعدّ اكتشاف الطفرات المتكافئة أحد أكبر العقبات التي تحول دون الاستخدام العملي لاختبار الطفرات. وقد يكون الجهد المطلوب للتحقق من تكافؤ الطفرات كبيرًا جدًا، حتى بالنسبة للبرامج الصغيرة. ^{[ 17 ]} وقد حددت مراجعة منهجية للأدبيات نُشرت عام 2014، تناولت طيفًا واسعًا من المناهج المُستخدمة للتغلب على مشكلة الطفرات المتكافئة ^{[ 18 ]} ، 17 تقنية ذات صلة (في 22 مقالة) وثلاث فئات من التقنيات: الكشف (DEM)؛ والاقتراح (SEM)؛ وتجنب توليد الطفرات المتكافئة (AEMG). وأشارت التجربة إلى أن الطفرات من الرتبة العليا بشكل عام، واستراتيجية JudyDiffOp بشكل خاص، تُقدّمان منهجًا واعدًا لحل مشكلة الطفرات المتكافئة.

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

لإجراء تغييرات نحوية على برنامج ما، يُستخدم عامل الطفرة كدليل لاستبدال أجزاء من شفرة المصدر. ونظرًا لاعتماد الطفرات على هذه العوامل، فقد ابتكر الباحثون مجموعة من عوامل الطفرة لتناسب لغات البرمجة المختلفة، مثل جافا. وتلعب فعالية هذه العوامل دورًا محوريًا في اختبار الطفرات. ^{[ 19 ]}

استكشف الباحثون العديد من عوامل التغيير. فيما يلي بعض الأمثلة على عوامل التغيير للغات الإجرائية:

• حذف البيان
• تكرار أو إدراج العبارة، على سبيل المثال goto fail;^{[ 20 ]}
• استبدال التعبيرات المنطقية الفرعية بالقيمتين " صحيح" و "خطأ".
• استبدال بعض العمليات الحسابية بعمليات أخرى، على سبيل المثال، +باستخدام *، -باستخدام/
• استبدال بعض العلاقات المنطقية بعلاقات أخرى، على سبيل المثال >مع >=، ==و<=
• استبدال المتغيرات بمتغيرات أخرى من نفس النطاق (يجب أن تكون أنواع المتغيرات متوافقة)
• قم بإزالة جسم الدالة. ^{[ 21 ]}

تُسمى عوامل التغيير هذه أيضًا عوامل التغيير التقليدية. وهناك أيضًا عوامل تغيير خاصة بلغات البرمجة كائنية التوجه، ^{[ 22 ]} وللإنشاءات المتزامنة، ^{[ 23 ]} وللكائنات المعقدة مثل الحاويات، ^{[ 24 ]} إلخ.

هناك ثلاثة أنواع من اختبارات الطفرات؛

دالة التحقق من بيانات الاعتماد ( اسم المستخدم ، كلمة المرور ) { إذا كان ( اسم المستخدم === "admin" && كلمة المرور === "password" ) { إرجاع صحيح ؛ } }

// الكود الأصلي function multiplyByTwo ( value ) { return value * 2 ; }// تغيير القيمة: دالة multiplyByTwoMutation1 ( القيمة ) { return القيمة * 10 ; }// تغيير القيمة: تحويل القيمة الأكبر إلى قيمة أصغر. دالة multiplyByTwoMutation2 ( القيمة ) { return القيمة / 10 ; }

// الكود الأصلي function isPositive ( number ) { return number > 0 ; }// تغيير القرار: تغيير دالة عامل المقارنة isPositiveMutation1 ( number ) { return number >= 0 ; }// تغيير القرار: نفي نتيجة الدالة isPositiveMutation2 ( number ) { return ! ( number > 0 ); }

• تصحيح الأخطاء (أو إحداث الأعطال)
• اختبار السلامة
• حقن الأعطال