म्यूटेशन टेस्टिंग: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(24 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{redirect|Mutation analysis|the biological term|Gene mutation analysis}}
'''"म्यूटेशन विश्लेषण" यहाँ पुननिर्देशित करें। जैविक भाषा के लिए,जीन म्यूटेशन विश्लेषण देखें।'''
म्यूटेशन टेस्टिंग (या ''म्यूटेशन एनालिसिस'' या ''प्रोग्राम म्यूटेशन'') का उपयोग नए सॉफ्टवेयर परीक्षणों को डिजाइन करने और उपस्थित सॉफ्टवेयर परीक्षणों की गुणवत्ता का मूल्यांकन करने के लिए किया जाता है। म्यूटेशन परीक्षण में प्रोग्राम को छोटे तरीकों से संशोधित करना सम्मिलित है।<ref name=DLS1978 />प्रत्येक उत्परिवर्तित संस्करण को  उत्परिवर्ती कहा जाता है और मूल संस्करण के व्यवहार को उत्परिवर्ती से अलग करने के कारण परीक्षण म्यूटेंट (उत्परिवर्ती) का पता लगाते हैं और अस्वीकार करते हैं। इसे म्यूटेंट को मारना कहा जाता है। टेस्ट  समूह  को उनके द्वारा मारे गए म्यूटेंट के प्रतिशत से मापा जाता है। अतिरिक्त म्यूटेंट को मारने के लिए नए परीक्षण तैयार किए जा सकते हैं। म्यूटेंट अच्छी तरह से परिभाषित म्यूटेशन ऑपरेटरों पर आधारित होते हैं जो या तो विशिष्ट प्रोग्रामिंग त्रुटियों की नकल करते हैं (जैसे गलत ऑपरेटर या चर नाम का उपयोग करना) या मूल्यवान परीक्षणों के निर्माण के लिए मजबूर करना  है  (जैसे प्रत्येक अभिव्यक्ति को शून्य से विभाजित करना)। इसका उद्देश्य परीक्षक को प्रभावी परीक्षण विकसित करने में मदद करना है या प्रोग्राम के लिए उपयोग किए गए परीक्षण डेटा या कोड के उन हिस्सों में कमजोरियों का पता लगाना है जो [[निष्पादन (कंप्यूटर)]] के दौरान  संभवतः  ही कभी या कभी एक्सेस नहीं किए जाते हैं। म्यूटेशन परीक्षण [[व्हाइट-बॉक्स परीक्षण]] का  प्रकार  है।<ref>{{Citation|last=Ostrand|first=Thomas|title=White-Box Testing|date=2002|url=https://onlinelibrary.wiley.com/doi/abs/10.1002/0471028959.sof378|encyclopedia=Encyclopedia of Software Engineering|publisher=American Cancer Society|language=en|doi=10.1002/0471028959.sof378|isbn=978-0-471-02895-6|access-date=2021-03-16}}</ref><ref>{{Cite journal|last=Misra|first=S.|date=2003|title=Evaluating four white-box test coverage methodologies|url=https://ieeexplore.ieee.org/document/1226246|journal=CCECE 2003 - Canadian Conference on Electrical and Computer Engineering. Toward a Caring and Humane Technology (Cat. No.03CH37436)|location=Montreal, Que., Canada|publisher=IEEE|volume=3|pages=1739–1742|doi=10.1109/CCECE.2003.1226246|isbn=978-0-7803-7781-3|s2cid=62549502 }}</ref>
 


'''म्यूटेशन टेस्टिंग''' (या''म्यूटेशन विश्लेषण'' या''प्रोग्राम म्यूटेशन'') का उपयोग नए सॉफ्टवेयर परीक्षणों को डिजाइन करने और उपस्थित सॉफ्टवेयर परीक्षणों की गुणवत्ता का मूल्यांकन करने के लिए किया जाता है। म्यूटेशन परीक्षण में प्रोग्राम को छोटे तरीकों से संशोधित करना सम्मिलित है।<ref name="DLS1978" />प्रत्येक उत्परिवर्तित संस्करण को उत्परिवर्ती कहा जाता है और मूल संस्करण के व्यवहार को उत्परिवर्ती से अलग करने के कारण परीक्षण उत्परिवर्ती (उत्परिवर्ती) का पता लगाते हैं और अस्वीकार करते हैं। इसे उत्परिवर्ती को मारना (किलिंग) कहा जाता है। टेस्ट समूह को उनके द्वारा मारे गए उत्परिवर्ती के प्रतिशत से मापा जाता है। अतिरिक्त उत्परिवर्ती को मारने के लिए नए परीक्षण तैयार किए जा सकते हैं। उत्परिवर्ती सही प्रकार से परिभाषित म्यूटेशन ऑपरेटरों पर आधारित होते हैं जो या तो विशिष्ट प्रोग्रामिंग त्रुटियों की नकल करते हैं (जैसे गलत ऑपरेटर या अस्थायी नाम का उपयोग करना) या मूल्यवान परीक्षणों के निर्माण के लिए विविश करना है (जैसे प्रत्येक अभिव्यक्ति को शून्य से विभाजित करना)। इसका उद्देश्य परीक्षक को प्रभावी परीक्षण विकसित करने में मदद करना है या प्रोग्राम के लिए उपयोग किए गए परीक्षण डेटा या कोड के उन हिस्सों में कमजोरियों का पता लगाना है जो [[निष्पादन (कंप्यूटर)]] के दौरान संभवतः ही कभी या कभी एक्सेस नहीं किए जाते हैं। म्यूटेशन परीक्षण [[व्हाइट-बॉक्स परीक्षण|व्हाइट-बॉक्स टेक्सटिंग]] का प्रकार है।<ref>{{Citation|last=Ostrand|first=Thomas|title=White-Box Testing|date=2002|url=https://onlinelibrary.wiley.com/doi/abs/10.1002/0471028959.sof378|encyclopedia=Encyclopedia of Software Engineering|publisher=American Cancer Society|language=en|doi=10.1002/0471028959.sof378|isbn=978-0-471-02895-6|access-date=2021-03-16}}</ref><ref>{{Cite journal|last=Misra|first=S.|date=2003|title=Evaluating four white-box test coverage methodologies|url=https://ieeexplore.ieee.org/document/1226246|journal=CCECE 2003 - Canadian Conference on Electrical and Computer Engineering. Toward a Caring and Humane Technology (Cat. No.03CH37436)|location=Montreal, Que., Canada|publisher=IEEE|volume=3|pages=1739–1742|doi=10.1109/CCECE.2003.1226246|isbn=978-0-7803-7781-3|s2cid=62549502 }}</ref>
== परिचय ==
== परिचय ==
इस लेख का अधिकांश भाग प्रोग्राम म्यूटेशन के बारे में है, जिसमें प्रोग्राम को संशोधित किया जाता है। म्यूटेशन विश्लेषण की अत्यधिक सामान्य परिभाषा सॉफ्टवेयर कलाकृतियों में व्यवस्थित परिवर्तन करने के लिए वाक्यात्मक संरचनाओं पर परिभाषित अच्छी तरह से परिभाषित नियमों का उपयोग कर रही है।<ref name="AmmannOffutt2008">Paul Ammann and Jeff Offutt. Introduction to Software Testing. Cambridge University Press, 2008.</ref> उत्परिवर्तन विश्लेषण अन्य समस्याओं पर लागू किया गया है, लेकिन आमतौर पर परीक्षण के लिए लागू किया जाता है। इसलिए म्यूटेशन परीक्षण को नए सॉफ़्टवेयर परीक्षणों को डिज़ाइन करने या मौजूदा सॉफ़्टवेयर परीक्षणों का मूल्यांकन करने के लिए म्यूटेशन विश्लेषण का उपयोग करने के रूप में परिभाषित किया गया है।<ref name="AmmannOffutt2008"/>इस प्रकार, उत्परिवर्तन विश्लेषण और परीक्षण डिजाइन मॉडल, विनिर्देशों, डेटाबेस, परीक्षण, एक्सएमएल और अन्य प्रकार के सॉफ़्टवेयर कलाकृतियों पर लागू किया जा सकता है, हालांकि प्रोग्राम म्यूटेशन सबसे आम है।<ref>{{cite journal| journal = CREST Centre, King's College London, Technical Report TR-09-06 | title = An Analysis and Survey of the Development of Mutation Testing | first1=Yue | last1=Jia | first2=Mark | last2=Harman | authorlink2=Mark Harman (computer scientist) | date=September 2009 | volume = 37 | issue = 5 | pages = 649–678 | doi = 10.1109/TSE.2010.62 | s2cid = 6853229 | url = https://pdfs.semanticscholar.org/3277/8a2eb4c74cd437e922ac1eb6a1477dfcb925.pdf | archive-url = https://web.archive.org/web/20171204061252/https://pdfs.semanticscholar.org/3277/8a2eb4c74cd437e922ac1eb6a1477dfcb925.pdf | url-status = dead | archive-date = 2017-12-04 }}</ref>
इस लेख का अधिकांश भाग प्रोग्राम म्यूटेशन के बारे में है, जिसमें प्रोग्राम को संशोधित किया जाता है। म्यूटेशन विश्लेषण की अत्यधिक सामान्य परिभाषा सॉफ्टवेयर कलाकृतियों में व्यवस्थित परिवर्तन करने के लिए वाक्यात्मक संरचनाओं पर सही प्रकार से परिभाषित नियमों का उपयोग कर रही है।<ref name="AmmannOffutt2008">Paul Ammann and Jeff Offutt. Introduction to Software Testing. Cambridge University Press, 2008.</ref> म्यूटेशन विश्लेषण अन्य समस्याओं पर क्रियान्वित किया गया है, परन्तु सामान्य तौर पर परीक्षण के लिए क्रियान्वित किया जाता है। इसलिए म्यूटेशन परीक्षण को नए सॉफ़्टवेयर परीक्षणों को डिज़ाइन करने या वर्तमान समय में उपस्थित सॉफ़्टवेयर परीक्षणों का मूल्यांकन करने के लिए म्यूटेशन विश्लेषण का उपयोग करने के रूप में परिभाषित किया गया है।<ref name="AmmannOffutt2008"/>इस प्रकार, म्यूटेशन विश्लेषण और परीक्षण डिजाइन मॉडल, विनिर्देशों, डेटाबेस, परीक्षण, एक्सएमएल (XML) और अन्य प्रकार के सॉफ़्टवेयर कलाकृतियों पर क्रियान्वित किया जा सकता है, चूंकि म्यूटेशन प्रोग्राम सबसे सरल है।<ref>{{cite journal| journal = CREST Centre, King's College London, Technical Report TR-09-06 | title = An Analysis and Survey of the Development of Mutation Testing | first1=Yue | last1=Jia | first2=Mark | last2=Harman | authorlink2=Mark Harman (computer scientist) | date=September 2009 | volume = 37 | issue = 5 | pages = 649–678 | doi = 10.1109/TSE.2010.62 | s2cid = 6853229 | url = https://pdfs.semanticscholar.org/3277/8a2eb4c74cd437e922ac1eb6a1477dfcb925.pdf | archive-url = https://web.archive.org/web/20171204061252/https://pdfs.semanticscholar.org/3277/8a2eb4c74cd437e922ac1eb6a1477dfcb925.pdf | url-status = dead | archive-date = 2017-12-04 }}</ref>
== अवलोकन ==
किसी दिए गए सॉफ़्टवेयर सिस्टम के कार्यान्वयन की शुद्धता को सत्यापित करने के लिए टेस्ट बनाए जा सकते हैं, परन्तु परीक्षणों का निर्माण अभी भी यह सवाल खड़ा करता है कि क्या परीक्षण सही हैं और पर्याप्त प्रकार से उन आवश्यकताओं को पूरा करते हैं जो कार्यान्वयन से उत्पन्न हुई हैं।<ref>{{cite book | first1=Aristides | last1=Dasso | first2=Ana | last2=Funes | title=Verification, Validation and Testing in Software Engineering |publisher=Idea Group Inc | year=2007| isbn=978-1591408512}}</ref> (यह तकनीकी समस्या अपने आप में "क्विस कस्टोडाइट इप्सॉस कस्टोड्स" नाम की गंभीर दार्शनिक समस्या का उदाहरण है? [गार्ड की रखवाली कौन करेगा? ]।) म्यूटेशन परीक्षण के पीछे विचार यह है कि यदि उत्परिवर्ती प्रस्तुत किया जाता है, तो यह सामान्य प्रकार से प्रोग्राम के बग का कारण बनता है जिसे परिक्षण को खोजना चाहिए। इस प्रकार, परीक्षणों का परीक्षण किया जाता है। यदि परीक्षण सूट द्वारा उत्परिवर्ती का पता नहीं लगाया जाता है, तो यह सामान्यतौर पर इंगित करता है कि परीक्षण सूट उत्परिवर्ती द्वारा दर्शाए गए दोषों का पता लगाने में असमर्थ है, परन्तु यह भी संकेत कर सकता है कि म्यूटेशन में कोई दोष नहीं है, अर्थात म्यूटेशन वैध परिवर्तन है जिससे कार्यक्षमता प्रभावित न हो। एक (सामान्य) तरीका उत्परिवर्ती मान्य हो सकता है कि जो कोड बदल दिया गया है वह मृत कोड है जिसे कभी निष्पादित नहीं किया जाता है।


 
उच्च स्तर पर कार्य करने के लिए म्यूटेशन परीक्षण के लिए, बड़ी संख्या में उत्परिवर्ती सामान्यतौर पर प्रस्तुत किए जाते हैं, जिससे प्रोग्राम की बहुत बड़ी संख्या में प्रतियों का संकलन और निष्पादन होता है। म्यूटेशन परीक्षण के खर्च की इस समस्या ने सॉफ्टवेयर परीक्षण की विधि के रूप में इसका वास्तविक उपयोग कम कर दिया था। चूंकि, [[वस्तु उन्मुख प्रोग्रामिंग भाषा|ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेजेज]] और [[इकाई का परीक्षण]] फ्रेमवर्क के बढ़ते उपयोग के कारण म्यूटेशन टेस्टिंग औजार का निर्माण हुआ है, जो किसी एप्लिकेशन के अलग-अलग हिस्सों का परीक्षण करते हैं।
== सिंहावलोकन ==
किसी दिए गए सॉफ़्टवेयर सिस्टम के कार्यान्वयन की शुद्धता को सत्यापित करने के लिए टेस्ट बनाए जा सकते हैं, लेकिन परीक्षणों का निर्माण अभी भी यह सवाल खड़ा करता है कि क्या परीक्षण सही हैं और पर्याप्त रूप से उन आवश्यकताओं को पूरा करते हैं जो कार्यान्वयन से उत्पन्न हुई हैं।<ref>{{cite book | first1=Aristides | last1=Dasso | first2=Ana | last2=Funes | title=Verification, Validation and Testing in Software Engineering |publisher=Idea Group Inc | year=2007| isbn=978-1591408512}}</ref> (यह तकनीकी समस्या अपने आप में Quis custodiet ipsos custodes नाम की एक गहरी दार्शनिक समस्या का एक उदाहरण है? [गार्ड की रखवाली कौन करेगा? ]।) उत्परिवर्तन परीक्षण के पीछे विचार यह है कि यदि एक म्यूटेंट पेश किया जाता है, तो यह सामान्य रूप से प्रोग्राम के बग का कारण बनता है। कार्यक्षमता जो परीक्षणों को मिलनी चाहिए। इस प्रकार, परीक्षणों का परीक्षण किया जाता है। यदि परीक्षण सूट द्वारा एक उत्परिवर्ती का पता नहीं लगाया जाता है, तो यह आमतौर पर इंगित करता है कि परीक्षण सूट उत्परिवर्ती द्वारा दर्शाए गए दोषों का पता लगाने में असमर्थ है, लेकिन यह भी संकेत कर सकता है कि उत्परिवर्तन में कोई दोष नहीं है, अर्थात उत्परिवर्तन एक वैध परिवर्तन है जिससे कार्यक्षमता प्रभावित न हो। एक (सामान्य) तरीका एक उत्परिवर्ती मान्य हो सकता है कि जो कोड बदल दिया गया है वह मृत कोड है जिसे कभी निष्पादित नहीं किया जाता है।
 
बड़े पैमाने पर कार्य करने के लिए म्यूटेशन परीक्षण के लिए, बड़ी संख्या में म्यूटेंट आमतौर पर पेश किए जाते हैं, जिससे प्रोग्राम की बहुत बड़ी संख्या में प्रतियों का संकलन और निष्पादन होता है। उत्परिवर्तन परीक्षण के खर्च की इस समस्या ने सॉफ्टवेयर परीक्षण की एक विधि के रूप में इसका व्यावहारिक उपयोग कम कर दिया था। हालाँकि, [[वस्तु उन्मुख प्रोग्रामिंग भाषा]] और [[इकाई का परीक्षण]] फ्रेमवर्क के बढ़ते उपयोग के कारण म्यूटेशन टेस्टिंग टूल्स का निर्माण हुआ है, जो किसी एप्लिकेशन के अलग-अलग हिस्सों का परीक्षण करते हैं।


== लक्ष्य ==
== लक्ष्य ==


उत्परिवर्तन परीक्षण के लक्ष्य एकाधिक हैं:
म्यूटेशन परीक्षण के लक्ष्य एकाधिक हैं:
* कोड के कमजोर परीक्षण वाले टुकड़ों की पहचान करें (जिनके लिए म्यूटेंट नहीं मारे गए हैं)<ref name=DLS1978 />* कमजोर परीक्षणों की पहचान करें (जो म्यूटेंट को कभी नहीं मारते)<ref name="Smith2008"/>* म्यूटेशन स्कोर की गणना करें,<ref name="AmmannOffutt2008"/>म्यूटेशन स्कोर मारे गए म्यूटेंट की संख्या / म्यूटेंट की कुल संख्या है।
* कोड के कमजोर परीक्षण वाले टुकड़ों की पहचान करें (जिनके लिए उत्परिवर्ती नहीं मारे (किल्ड ) गए हैं)<ref name=DLS1978 />
* कार्यक्रम में त्रुटि प्रसार और राज्य संक्रमण के बारे में जानें
*कमजोर परीक्षणों की पहचान करें (जो उत्परिवर्ती को कभी नहीं मारते)<ref name="Smith2008" />
*म्यूटेशन स्कोर की गणना करें,<ref name="AmmannOffutt2008" /> म्यूटेशन स्कोर मारे गए उत्परिवर्ती की संख्या/उत्परिवर्ती की कुल संख्या है।
* कार्यक्रम में त्रुटि प्रसार और प्रसारित होने अवस्था के बारे में जानें।


== इतिहास ==
== इतिहास ==
म्यूटेशन परीक्षण मूल रूप से 1971 में एक छात्र के रूप में रिचर्ड लिप्टन द्वारा प्रस्तावित किया गया था,<ref name="mutation2000">[http://cs.gmu.edu/~offutt/rsrch/papers/mut00.pdf Mutation 2000: Uniting the Orthogonal] by [[Jeff Offutt|A. Jefferson Offutt]] and Roland H. Untch.</ref> और सबसे पहले डेमिलो, लिप्टन और सैवर्ड द्वारा विकसित और प्रकाशित किया गया।<ref name="DLS1978">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.</ref> म्यूटेशन टेस्टिंग टूल का पहला कार्यान्वयन 1980 में [[येल विश्वविद्यालय]] से टिमोथी बड ने अपने [[पीएचडी]] कार्य (म्यूटेशन एनालिसिस शीर्षक) के हिस्से के रूप में किया था।<ref name="Budd1980">Tim A. Budd, Mutation Analysis of Program Test Data. PhD thesis, Yale University New Haven CT, 1980.</ref>
म्यूटेशन परीक्षण मुख्य प्रकार से 1971 में छात्र के रूप में रिचर्ड लिप्टन द्वारा प्रस्तावित किया गया था,<ref name="mutation2000">[http://cs.gmu.edu/~offutt/rsrch/papers/mut00.pdf Mutation 2000: Uniting the Orthogonal] by [[Jeff Offutt|A. Jefferson Offutt]] and Roland H. Untch.</ref> और सबसे पहले डेमिलो, लिप्टन और सैवर्ड द्वारा विकसित और प्रकाशित किया गया था।<ref name="DLS1978">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.</ref> म्यूटेशन टेस्टिंग औजार का पहला कार्यान्वयन 1980 में [[येल विश्वविद्यालय]] से टिमोथी बड ने अपने [[पीएचडी]] कार्य (म्यूटेशन   विश्लेषण शीर्षक) के पक्ष के रूप में किया था।<ref name="Budd1980">Tim A. Budd, Mutation Analysis of Program Test Data. PhD thesis, Yale University New Haven CT, 1980.</ref>कुछ समय पहले ही, उच्च स्तर पर कंप्यूटिंग शक्ति की उपलब्धता के साथ, कंप्यूटर विज्ञान समुदाय के भीतर   म्यूटेशन विश्लेषण का पुनरुत्थान हुआ है, और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग (एक कंप्यूटर प्रोग्रामिंग मॉडल है) भाषाओं और [[गैर-प्रक्रियात्मक भाषा]]ओं जैसे [[एक्सएमएल]], एसएमवी परिमित अवस्था की मशीनों में म्यूटेशन टेस्टिंग को क्रियान्वित करने के तरीकों को परिभाषित करने के लिए कार्य किया गया है।
हाल ही में, बड़े पैमाने पर कंप्यूटिंग शक्ति की उपलब्धता के साथ, कंप्यूटर विज्ञान समुदाय के भीतर म्यूटेशन विश्लेषण का पुनरुत्थान हुआ है, और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग भाषाओं और [[गैर-प्रक्रियात्मक भाषा]]ओं जैसे [[एक्सएमएल]], म्यूटेशन टेस्टिंग को लागू करने के तरीकों को परिभाषित करने के लिए काम किया गया है। [[प्रतीकात्मक मॉडल सत्यापन]], और [[परिमित राज्य मशीनें]]।


2004 में Certess Inc. (अब [[Synopsys]] का हिस्सा) नामक एक कंपनी ने कई सिद्धांतों को हार्डवेयर सत्यापन डोमेन में विस्तारित किया। जबकि म्यूटेशन विश्लेषण केवल उत्पादित आउटपुट में अंतर का पता लगाने की अपेक्षा करता है, Certess यह सत्यापित करके इसे बढ़ाता है कि टेस्टबेंच में एक चेकर वास्तव में अंतर का पता लगाएगा। इस विस्तार का अर्थ है कि सत्यापन के सभी तीन चरणों, अर्थात्: सक्रियण, प्रसार और पहचान का मूल्यांकन किया जाता है। उन्होंने इसे कार्यात्मक योग्यता कहा।
2004 में सरटेस इंक. (सिनोप्सिस का हिस्सा) नामक एक कंपनी ने कई सिद्धांतों को हार्डवेयर सत्यापन डोमेन में विस्तारित किया है। यद्यपि म्यूटेशन विश्लेषण केवल उत्पादित आउटपुट में अंतर का पता लगाने की अपेक्षा करता है, सरटेस यह सत्यापित करके इसे बढ़ाता है कि टेस्टबेंच में चेकर वास्तव में अंतर का पता लगाएगा। इस विस्तार का अर्थ है कि सत्यापन के सभी तीन चरणों, अर्थात्: सक्रियण, प्रसार और पहचान का मूल्यांकन किया जाता है। उन्होंने इसे कार्यात्मक योग्यता कहा है।


[[फज़िंग]] को उत्परिवर्तन परीक्षण का एक विशेष मामला माना जा सकता है। फ़ज़िंग में, संचार इंटरफेस (सॉफ्टवेयर इंस्टेंसेस के अंदर और बीच दोनों) में आदान-प्रदान किए गए संदेशों या डेटा को डेटा को संसाधित करने में विफलताओं या अंतरों को पकड़ने के लिए उत्परिवर्तित किया जाता है। [[कोडनोमिकॉन]]<ref>[http://www.codenomicon.com/resources/publications.shtml Kaksonen, Rauli. A Functional Method for Assessing Protocol Implementation Security (Licentiate thesis). Espoo. 2001.]</ref> (2001) और [[गतिकी में]] (2005) ने पूरी तरह से स्टेटफुल म्यूटेशन टेस्टिंग प्लेटफॉर्म के लिए [[फ़ज़ परीक्षण]] कॉन्सेप्ट विकसित किया, जो पूरी तरह से प्रोटोकॉल कार्यान्वयन के लिए मॉनिटर के साथ पूरा हुआ।
[[फज़िंग]] को म्यूटेशन परीक्षण का विशेष कथन माना जा सकता है। फ़ज़िंग में, संचार इंटरफेस (सॉफ्टवेयर इंस्टेंसेस के अंदर और बीच दोनों) में आदान-प्रदान किए गए संदेशों या डेटा को संसाधित करने में विफलताओं या अंतरों को पकड़ने के लिए उत्परिवर्तित किया जाता है। [[कोडनोमिकॉन]]<ref>[http://www.codenomicon.com/resources/publications.shtml Kaksonen, Rauli. A Functional Method for Assessing Protocol Implementation Security (Licentiate thesis). Espoo. 2001.]</ref> (2001) और [[गतिकी में]] (2005) ने पूर्ण तरह की अवस्था म्यूटेशन टेस्टिंग प्लेटफॉर्म के लिए [[फ़ज़ परीक्षण]] अवधारणा विकसित किया, जो पूरी तरह से प्रोटोकॉल कार्यान्वयन के लिए मॉनिटर के साथ पूर्ण हुआ है।


== उत्परिवर्तन परीक्षण सिंहावलोकन ==
== म्यूटेशन परीक्षण अवलोकन ==
उत्परिवर्तन परीक्षण दो परिकल्पनाओं पर आधारित है। पहला सक्षम प्रोग्रामर परिकल्पना है। यह परिकल्पना बताती है कि सक्षम प्रोग्रामर ऐसे प्रोग्राम लिखते हैं जो सही होने के करीब हैं।<ref name=DLS1978 />क्लोज का उद्देश्य व्यवहार पर आधारित होना है, सिंटैक्स पर नहीं। दूसरी परिकल्पना को युग्मन प्रभाव कहा जाता है। युग्मन प्रभाव का दावा है कि सरल दोष कैस्केड कर सकते हैं या जोड़े अन्य आकस्मिक दोष बना सकते हैं।<ref name="Offut1992">A. Jefferson Offutt. 1992. Investigations of the software testing coupling effect. ACM Trans. Softw. Eng. Methodol. 1, 1 (January 1992), 5-20.</ref><ref name="ABDLS1979">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.</ref>
म्यूटेशन परीक्षण दो परिकल्पनाओं पर आधारित है। पहला सक्षम प्रोग्रामर परिकल्पना है। यह परिकल्पना बताती है कि सक्षम प्रोग्रामर ऐसे प्रोग्राम लिखते हैं जो सही होने के निकट हैं।<ref name=DLS1978 />क्लोज का उद्देश्य व्यवहार पर आधारित होना है, सिंटैक्स पर नहीं। दूसरी परिकल्पना को युग्मन प्रभाव कहा जाता है। युग्मन प्रभाव का कथन है कि सरल दोष कैस्केड कर सकते हैं या जोड़े अन्य अप्रत्याशित दोष बना सकते हैं।<ref name="Offut1992">A. Jefferson Offutt. 1992. Investigations of the software testing coupling effect. ACM Trans. Softw. Eng. Methodol. 1, 1 (January 1992), 5-20.</ref><ref name="ABDLS1979">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.</ref> उच्च-क्रम के उत्परिवर्ती द्वारा सूक्ष्म और महत्वपूर्ण दोष भी प्रकट होते हैं, जो आगे युग्मन प्रभाव का समर्थन करते हैं।<ref name="JH2008">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</ref><ref name="Umar2008">Maryam Umar, "An Evaluation of Mutation Operators For Equivalent Mutants," MS Thesis, 2006</ref><ref name="Smith2008">Smith B., "On Guiding Augmentation of an Automated Test Suite via Mutation Analysis," 2008</ref><ref name="PP2009">Polo M. and Piattini M., "Mutation Testing: practical aspects and cost analysis," University of Castilla-La Mancha (Spain), Presentation, 2009</ref><ref name="Anderson2011">Anderson S., "Mutation Testing", the  University of Edinburgh, School of Informatics, Presentation, 2011</ref> एक से अत्यधिक म्यूटेशन वाले उत्परिवर्ती बनाकर उच्च-क्रम उत्परिवर्ती को कार्य करने योग्य  किया जाता है।
उच्च-क्रम के म्यूटेंट द्वारा सूक्ष्म और महत्वपूर्ण दोष भी प्रकट होते हैं, जो आगे युग्मन प्रभाव का समर्थन करते हैं।<ref name="JH2008">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</ref><ref name="Umar2008">Maryam Umar, "An Evaluation of Mutation Operators For Equivalent Mutants," MS Thesis, 2006</ref><ref name="Smith2008">Smith B., "On Guiding Augmentation of an Automated Test Suite via Mutation Analysis," 2008</ref><ref name="PP2009">Polo M. and Piattini M., "Mutation Testing: practical aspects and cost analysis," University of Castilla-La Mancha (Spain), Presentation, 2009</ref><ref name="Anderson2011">Anderson S., "Mutation Testing", the  University of Edinburgh, School of Informatics, Presentation, 2011</ref> एक से अधिक म्यूटेशन वाले म्यूटेंट बनाकर उच्च-क्रम म्यूटेंट को सक्षम किया जाता है।


म्यूटेशन ऑपरेटरों के एक सेट का चयन करके उत्परिवर्तन परीक्षण किया जाता है और फिर उन्हें स्रोत कोड के प्रत्येक लागू टुकड़े के लिए एक बार में स्रोत प्रोग्राम में लागू किया जाता है। प्रोग्राम में एक म्यूटेशन ऑपरेटर लगाने के परिणाम को म्यूटेंट कहा जाता है। यदि परीक्षण सूट परिवर्तन का पता लगाने में सक्षम है (अर्थात परीक्षणों में से एक विफल हो जाता है), तो उत्परिवर्ती को मार दिया जाना कहा जाता है।
म्यूटेशन ऑपरेटरों के समूह का चयन करके म्यूटेशन परीक्षण किया जाता है और फिर उन्हें स्रोत कोड के प्रत्येक क्रियान्वित टुकड़े के लिए एक बार में स्रोत प्रोग्राम में क्रियान्वित किया जाता है। प्रोग्राम में म्यूटेशन ऑपरेटर लगाने के परिणाम को उत्परिवर्ती कहा जाता है। यदि परीक्षण सूट परिवर्तन का पता लगाने में सक्षम है (अर्थात परीक्षणों में से विफल हो जाता है), तो उत्परिवर्ती को मार दिया जाना कहा जाता है।


उदाहरण के लिए, निम्नलिखित सी ++ कोड खंड पर विचार करें:
उदाहरण के लिए, निम्नलिखित C++ कोड खंड पर विचार करें:  
<वाक्यविन्यास लैंग = सीपीपी>
<syntaxhighlight lang="cpp">
अगर (ए && बी) {
if (a && b) {
     सी = 1;
     c = 1;
} अन्य {
} else {
     सी = 0;
     c = 0;
}
}
</वाक्यविन्यास हाइलाइट>
</syntaxhighlight>


हालत म्यूटेशन ऑपरेटर बदलेगा <code>&&</code> साथ <code>||</code> और निम्नलिखित उत्परिवर्त उत्पन्न करें:
The condition mutation operator would replace <code>&&</code> with <code>||</code> and produce the following mutant:
<वाक्यविन्यास लैंग = सीपीपी>
<syntaxhighlight lang="cpp">
अगर (ए || बी) {
if (a || b) {
     सी = 1;
     c = 1;
} अन्य {
} else {
     सी = 0;
     c = 0;
}
}
</वाक्यविन्यास हाइलाइट>
</syntaxhighlight>


अब, इस उत्परिवर्ती को मारने के परीक्षण के लिए, निम्नलिखित तीन शर्तें पूरी की जानी चाहिए:
अब, इस उत्परिवर्ती को मारने के परीक्षण के लिए, निम्नलिखित तीन शर्तें पूरी की जानी चाहिए:
# एक परीक्षण उत्परिवर्तित कथन तक पहुंचना चाहिए।
# टेस्ट इनपुट डेटा को म्यूटेंट और मूल प्रोग्राम के लिए अलग-अलग प्रोग्राम स्टेट्स बनाकर प्रोग्राम स्टेट को संक्रमित करना चाहिए। उदाहरण के लिए, के साथ एक परीक्षण <code>a = 1</code> और <code>b = 0</code> यह करेंगे।
# गलत कार्यक्रम स्थिति ('सी' का मान) कार्यक्रम के आउटपुट के लिए प्रचारित होना चाहिए और परीक्षण द्वारा जांच की जानी चाहिए।


इन स्थितियों को सामूहिक रूप से RIP मॉडल कहा जाता है।<ref name="mutation2000" />
1. परीक्षण उत्परिवर्तित कथन तक पहुंचना चाहिए।


कमजोर म्यूटेशन परीक्षण (या कमजोर म्यूटेशन कवरेज) के लिए आवश्यक है कि केवल पहली और दूसरी शर्तें पूरी हों। मजबूत उत्परिवर्तन परीक्षण के लिए आवश्यक है कि तीनों शर्तें पूरी हों। मजबूत उत्परिवर्तन अधिक शक्तिशाली है, क्योंकि यह सुनिश्चित करता है कि परीक्षण सूट वास्तव में समस्याओं को पकड़ सकता है। कमजोर म्यूटेशन [[कोड कवरेज़]] विधियों से निकटता से संबंधित है। यह सुनिश्चित करने के लिए बहुत कम कंप्यूटिंग शक्ति की आवश्यकता होती है कि टेस्ट सूट मजबूत म्यूटेशन परीक्षण की तुलना में कमजोर म्यूटेशन परीक्षण को संतुष्ट करता है।
2. वास्तविकता में टेस्ट इनपुट डेटा को उत्परिवर्ती और मूल प्रोग्राम के लिए अलग-अलग प्रोग्राम स्टेट्स बनाकर प्रोग्राम स्टेट को बढ़ाना करना चाहिए। उदाहरण के लिए,<code>a=1</code>और<code>b=0</code>वाला परिक्षण ऐसा करेगा।


हालांकि, ऐसे मामले हैं जहां एक परीक्षण मामला खोजना संभव नहीं है जो इस उत्परिवर्ती को मार सके। परिणामी कार्यक्रम व्यावहारिक रूप से मूल के बराबर है। ऐसे म्यूटेंट को समतुल्य म्यूटेंट कहा जाता है।
3. गलत प्रोग्राम स्टेट ('सी' का मान) प्रोग्राम के आउटपुट के लिए प्रचारित होना चाहिए और परीक्षण द्वारा जांच की जानी चाहिए।


उत्परिवर्तन परीक्षण के व्यावहारिक उपयोग के लिए समतुल्य म्यूटेंट का पता लगाना सबसे बड़ी बाधाओं में से एक है। म्यूटेंट समकक्ष हैं या नहीं, यह जांचने के लिए आवश्यक प्रयास छोटे कार्यक्रमों के लिए भी बहुत अधिक हो सकते हैं।<ref>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.</ref> समतुल्य उत्परिवर्ती समस्या को दूर करने के लिए दृष्टिकोणों की एक विस्तृत श्रृंखला की एक व्यवस्थित साहित्य समीक्षा<ref>[http://madeyski.e-informatyka.pl/download/Madeyski13TSE.pdf 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''</ref> 17 प्रासंगिक तकनीकों (22 लेखों में) और तकनीकों की तीन श्रेणियों की पहचान की: पता लगाना (डीईएम); सुझाव (SEM); और समतुल्य उत्परिवर्ती पीढ़ी (AEMG) से बचना। प्रयोग ने संकेत दिया कि सामान्य रूप से हायर ऑर्डर म्यूटेशन और विशेष रूप से जूडीडिफऑप रणनीति समतुल्य उत्परिवर्ती समस्या के लिए एक आशाजनक दृष्टिकोण प्रदान करती है।
इन स्थितियों को सामूहिक रूप से आरआइपी मॉडल कहा जाता है।<ref name="mutation2000" />


समतुल्य म्यूटेंट के अलावा, ऐसे म्यूटेंट म्यूटेंट हैं जो म्यूटेंट हैं जो एक ही स्रोत कोड स्थान में एक अन्य म्यूटेंट के रूप में मौजूद हैं, और कहा जाता है कि अन्य म्यूटेंट द्वारा सब्सक्राइब किया गया है। सम्मिलित म्यूटेंट एक उत्परिवर्तन परीक्षण उपकरण के लिए दृश्यमान नहीं हैं, और कवरेज मेट्रिक्स में योगदान नहीं करते हैं। उदाहरण के लिए, मान लें कि आपके पास दो म्यूटेंट, ए और बी हैं, जो दोनों एक ही तरह से कोड की एक पंक्ति बदलते हैं। म्यूटेंट ए का पहले परीक्षण किया जाता है, और इसका परिणाम यह होता है कि कोड ठीक से काम नहीं कर रहा है। तब उत्परिवर्ती बी का परीक्षण किया जाता है, और परिणाम उत्परिवर्ती ए के समान होता है। इस मामले में, उत्परिवर्ती बी को म्यूटेंट ए द्वारा निर्वाह माना जाता है, क्योंकि म्यूटेंट बी के परीक्षण का परिणाम म्यूटेंट ए के परीक्षण के परिणाम के समान है। इसलिए, उत्परिवर्ती बी को परीक्षण करने की आवश्यकता नहीं है, क्योंकि परिणाम उत्परिवर्ती ए के समान ही होगा।
कमजोर म्यूटेशन परीक्षण (या कमजोर म्यूटेशन कवरेज) के लिए आवश्यक है कि केवल पहली और दूसरी अवस्था पूर्ण हों। मजबूत म्यूटेशन परीक्षण के लिए आवश्यक है कि तीनों अवस्था पूर्ण हों। मजबूत म्यूटेशन अत्यधिक शक्तिशाली है, क्योंकि यह सुनिश्चित करता है कि परीक्षण सूट वास्तव में समस्याओं को पकड़ सकता है। कमजोर म्यूटेशन [[कोड कवरेज़]] विधियों से निकटता से संबंधित है। यह सुनिश्चित करने के लिए बहुत कम कंप्यूटिंग शक्ति की आवश्यकता होती है कि टेस्ट सूट मजबूत म्यूटेशन परीक्षण की तुलना में कमजोर म्यूटेशन परीक्षण को संतुष्ट करता है।


== म्यूटेशन ऑपरेटर्स ==
चूँकि, ऐसे कारण हैं जहां परीक्षण के स्थिति को ढूंढ़ना संभव नहीं है जो इस उत्परिवर्ती को मार सकते हैं। परिणामी प्रोग्राम व्यावहारिक प्रकार से मूल के बराबर है। ऐसे उत्परिवर्ती को समतुल्य उत्परिवर्ती कहा जाता है।
शोधकर्ताओं द्वारा कई म्यूटेशन ऑपरेटरों का पता लगाया गया है। यहाँ अनिवार्य भाषाओं के लिए उत्परिवर्तन संचालकों के कुछ उदाहरण दिए गए हैं:
 
म्यूटेशन परीक्षण के व्यावहारिक उपयोग के लिए समतुल्य उत्परिवर्ती का पता लगाना सबसे बड़ी बाधाओं में से एक है। उत्परिवर्ती समकक्ष हैं या नहीं, यह जांचने के लिए आवश्यक प्रयास छोटे प्रोग्राम्स के लिए भी बहुत अत्यधिक हो सकते हैं।<ref>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.</ref> समतुल्य उत्परिवर्ती समस्या को दूर करने के लिए दृष्टिकोणों की एक विस्तृत श्रृंखला की व्यवस्थित साहित्य समीक्षा है <ref>[http://madeyski.e-informatyka.pl/download/Madeyski13TSE.pdf 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''</ref> 17 प्रासंगिक तकनीकों (22 लेखों में) और तकनीकों की तीन श्रेणियों की पहचान की: पता लगाना (डीईएम); सुझाव (एसइएम); और समतुल्य उत्परिवर्ती पीढ़ी (एइएमजी) से बचना है। प्रयोग ने संकेत दिया कि सामान्य प्रकार से उच्च क्रम म्यूटेशन और विशेष प्रकार से जूडीडिफऑप रणनीति समतुल्य उत्परिवर्ती समस्या के लिए आशाजनक दृष्टिकोण प्रदान करती है।
 
समतुल्य उत्परिवर्ती के अतिरिक्त, ऐसे उत्परिवर्ती म्यूटेंट हैं जो स्रोत कोड स्थान में अन्य उत्परिवर्ती के रूप में उपस्थित हैं, और कहा जाता है कि अन्य उत्परिवर्ती द्वारा सब्सक्राइब किया गया है। सम्मिलित उत्परिवर्ती म्यूटेशन परीक्षण उपकरण के लिए दृश्यमान नहीं हैं, और कवरेज मेट्रिक्स में योगदान नहीं करते हैं। उदाहरण के लिए, मान लें कि आपके पास दो म्यूटेंट, ए और बी हैं, जो दोनों एक ही तरह से कोड की पंक्ति बदलते हैं। उत्परिवर्ती ए का पहले परीक्षण किया जाता है, और इसका परिणाम यह होता है कि कोड सही प्रकार से कार्य नहीं कर रहा है। तब उत्परिवर्ती बी का परीक्षण किया जाता है, और परिणाम उत्परिवर्ती ए के समान होता है। इस कथन में, उत्परिवर्ती बी को उत्परिवर्ती ए द्वारा निर्वाह माना जाता है, क्योंकि उत्परिवर्ती बी के परीक्षण का परिणाम उत्परिवर्ती ए के परीक्षण के परिणाम के समान है। इसलिए, उत्परिवर्ती बी को परीक्षण करने की आवश्यकता नहीं है, क्योंकि परिणाम उत्परिवर्ती ए के समान ही होगा।
 
 
 
 
 
 
 
== म्यूटेशन ऑपरेटर्स ==
शोधकर्ताओं द्वारा कई म्यूटेशन ऑपरेटरों का पता लगाया गया है। यहाँ अनिवार्य भाषाओं के लिए म्यूटेशन संचालकों के कुछ उदाहरण दिए गए हैं:


* कथन विलोपन
* कथन विलोपन
* कथन दोहराव या प्रविष्टि, उदा. <code>goto fail;</code><ref>[https://www.imperialviolet.org/2014/02/22/applebug.html Apple's SSL/TLS bug] by Adam Langley.</ref>
* कथन दोहराव या प्रविष्टि, उदा. गोटो फेल ;<ref>[https://www.imperialviolet.org/2014/02/22/applebug.html Apple's SSL/TLS bug] by Adam Langley.</ref>
* बूलियन उप-अभिव्यक्तियों को सही और गलत के साथ बदलना
* बूलियन उप-अभिव्यक्तियों को सही और गलत के साथ बदलना
* कुछ अंकगणितीय संक्रियाओं को अन्य संक्रियाओं से बदलना, उदा. <code>+</code> साथ <code>*</code>, <code>-</code> साथ <code>/</code>
* कुछ अंकगणितीय संक्रियाओं को अन्य संक्रियाओं से बदलना, उदा.<code>+</code>साथ<code>*</code>,<code>-</code>साथ<code>/</code>
* कुछ बूलियन संबंधों को अन्य के साथ बदलना, उदा. <code>></code> साथ <code>>=</code>, <code>==</code> और <code><=</code>
* कुछ बूलियन संबंधों को अन्य के साथ बदलना, उदा.<code>></code>साथ<code>>=,</code><code>==</code>और<code><=</code>
* एक ही दायरे से दूसरों के साथ चर का प्रतिस्थापन (चर प्रकार संगत होना चाहिए)
* एक ही दायरे से दूसरों के साथ चर का प्रतिस्थापन (चर प्रकार संगत होना चाहिए)
* विधि निकाय निकालें।<ref>{{Cite journal|last1=Niedermayr|first1=Rainer|last2=Juergens|first2=Elmar|last3=Wagner|first3=Stefan|date=2016-05-14|title=Will my tests tell me if I break this code?|url=https://doi.org/10.1145/2896941.2896944|journal=Proceedings of the International Workshop on Continuous Software Evolution and Delivery|series=CSED '16|location=Austin, Texas|publisher=Association for Computing Machinery|pages=23–29|doi=10.1145/2896941.2896944|isbn=978-1-4503-4157-8|arxiv=1611.07163|s2cid=9213147 }}</ref>
* विधि निकाय निकालें।<ref>{{Cite journal|last1=Niedermayr|first1=Rainer|last2=Juergens|first2=Elmar|last3=Wagner|first3=Stefan|date=2016-05-14|title=Will my tests tell me if I break this code?|url=https://doi.org/10.1145/2896941.2896944|journal=Proceedings of the International Workshop on Continuous Software Evolution and Delivery|series=CSED '16|location=Austin, Texas|publisher=Association for Computing Machinery|pages=23–29|doi=10.1145/2896941.2896944|isbn=978-1-4503-4157-8|arxiv=1611.07163|s2cid=9213147 }}</ref>
इन म्यूटेशन ऑपरेटरों को पारंपरिक म्यूटेशन ऑपरेटर्स भी कहा जाता है।
इन म्यूटेशन ऑपरेटरों को पारंपरिक म्यूटेशन ऑपरेटर्स भी कहा जाता है। ऑब्जेक्ट-ओरिएंटेड भाषाओं के लिए म्यूटेशन ऑपरेटर भी हैं,<ref>[http://www.cs.gmu.edu/~offutt/rsrch/papers/mujava.pdf MuJava: An Automated Class Mutation System] by Yu-Seung Ma, [[Jeff Offutt]] and Yong Rae Kwo.</ref> समवर्ती निर्माण के लिए,<ref>[http://www.irisa.fr/manifestations/2006/Mutation2006/papers/14_Final_version.pdf Mutation Operators for Concurrent Java (J2SE 5.0)] by Jeremy S. Bradbury, James R. Cordy, Juergen Dingel.</ref> जटिल वस्तुएं जैसे कंटेनर,<ref>[http://www.cs.colostate.edu/~bieman/Pubs/AlexanderBiemanGhoshJiISSRE02.pdf Mutation of Java Objects] by Roger T. Alexander, James M. Bieman, Sudipto Ghosh, Bixia Ji.</ref> इत्यादि के लिए है। कंटेनरों के लिए ऑपरेटरों को क्लास-लेवल म्यूटेशन ऑपरेटर्स कहा जाता है। उदाहरण के लिए, मुजावा टूल विभिन्न क्लास-लेवल म्यूटेशन ऑपरेटर प्रदान करता है जैसे एक्सेस मॉडिफायर चेंज, टाइप कास्ट ऑपरेटर इंसर्शन, और टाइप कास्ट ऑपरेटर विलोपन इत्यादि है। प्रोग्राम्स की सुरक्षा भेद्यता परीक्षण करने के लिए म्यूटेशन ऑपरेटरों को विकसित किया गया है।<ref>[http://qspace.library.queensu.ca/handle/1974/1359 Mutation-based Testing of Buffer Overflows, SQL Injections, and Format String Bugs] by H. Shahriar and M. Zulkernine.</ref>
ऑब्जेक्ट-ओरिएंटेड भाषाओं के लिए म्यूटेशन ऑपरेटर भी हैं,<ref>[http://www.cs.gmu.edu/~offutt/rsrch/papers/mujava.pdf MuJava: An Automated Class Mutation System] by Yu-Seung Ma, [[Jeff Offutt]] and Yong Rae Kwo.</ref> समवर्ती निर्माण के लिए,<ref>[http://www.irisa.fr/manifestations/2006/Mutation2006/papers/14_Final_version.pdf Mutation Operators for Concurrent Java (J2SE 5.0)] by Jeremy S. Bradbury, James R. Cordy, Juergen Dingel.</ref> जटिल वस्तुएं जैसे कंटेनर,<ref>[http://www.cs.colostate.edu/~bieman/Pubs/AlexanderBiemanGhoshJiISSRE02.pdf Mutation of Java Objects] by Roger T. Alexander, James M. Bieman, Sudipto Ghosh, Bixia Ji.</ref> आदि। कंटेनरों के लिए ऑपरेटरों को क्लास-लेवल म्यूटेशन ऑपरेटर्स कहा जाता है। उदाहरण के लिए, muJava टूल विभिन्न क्लास-लेवल म्यूटेशन ऑपरेटर प्रदान करता है जैसे एक्सेस मॉडिफायर चेंज, टाइप कास्ट ऑपरेटर इंसर्शन, और टाइप कास्ट ऑपरेटर डिलीशन। कार्यक्रमों की सुरक्षा भेद्यता परीक्षण करने के लिए म्यूटेशन ऑपरेटरों को भी विकसित किया गया है।<ref>[http://qspace.library.queensu.ca/handle/1974/1359 Mutation-based Testing of Buffer Overflows, SQL Injections, and Format String Bugs] by H. Shahriar and M. Zulkernine.</ref>
 
 
== यह भी देखें ==
== यह भी देखें ==


* [[Bebugging]] (या फॉल्ट सीडिंग)
* बेबगिंग (या फॉल्ट सीडिंग)
* [[विवेक परीक्षण]]
* [[विवेक परीक्षण]]
* [[दोष इंजेक्शन]]
* [[दोष इंजेक्शन]]
Line 88: Line 91:
{{reflist}}
{{reflist}}


{{Software testing}}
[[Category:CS1 English-language sources (en)]]
[[Category: सॉफ़्टवेयर परीक्षण]]
 
 
 
[[Category: Machine Translated Page]]
[[Category:Created On 19/02/2023]]
[[Category:Created On 19/02/2023]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:सॉफ़्टवेयर परीक्षण]]

Latest revision as of 17:03, 29 August 2023

"म्यूटेशन विश्लेषण" यहाँ पुननिर्देशित करें। जैविक भाषा के लिए,जीन म्यूटेशन विश्लेषण देखें।

म्यूटेशन टेस्टिंग (याम्यूटेशन विश्लेषण याप्रोग्राम म्यूटेशन) का उपयोग नए सॉफ्टवेयर परीक्षणों को डिजाइन करने और उपस्थित सॉफ्टवेयर परीक्षणों की गुणवत्ता का मूल्यांकन करने के लिए किया जाता है। म्यूटेशन परीक्षण में प्रोग्राम को छोटे तरीकों से संशोधित करना सम्मिलित है।[1]प्रत्येक उत्परिवर्तित संस्करण को उत्परिवर्ती कहा जाता है और मूल संस्करण के व्यवहार को उत्परिवर्ती से अलग करने के कारण परीक्षण उत्परिवर्ती (उत्परिवर्ती) का पता लगाते हैं और अस्वीकार करते हैं। इसे उत्परिवर्ती को मारना (किलिंग) कहा जाता है। टेस्ट समूह को उनके द्वारा मारे गए उत्परिवर्ती के प्रतिशत से मापा जाता है। अतिरिक्त उत्परिवर्ती को मारने के लिए नए परीक्षण तैयार किए जा सकते हैं। उत्परिवर्ती सही प्रकार से परिभाषित म्यूटेशन ऑपरेटरों पर आधारित होते हैं जो या तो विशिष्ट प्रोग्रामिंग त्रुटियों की नकल करते हैं (जैसे गलत ऑपरेटर या अस्थायी नाम का उपयोग करना) या मूल्यवान परीक्षणों के निर्माण के लिए विविश करना है (जैसे प्रत्येक अभिव्यक्ति को शून्य से विभाजित करना)। इसका उद्देश्य परीक्षक को प्रभावी परीक्षण विकसित करने में मदद करना है या प्रोग्राम के लिए उपयोग किए गए परीक्षण डेटा या कोड के उन हिस्सों में कमजोरियों का पता लगाना है जो निष्पादन (कंप्यूटर) के दौरान संभवतः ही कभी या कभी एक्सेस नहीं किए जाते हैं। म्यूटेशन परीक्षण व्हाइट-बॉक्स टेक्सटिंग का प्रकार है।[2][3]

परिचय

इस लेख का अधिकांश भाग प्रोग्राम म्यूटेशन के बारे में है, जिसमें प्रोग्राम को संशोधित किया जाता है। म्यूटेशन विश्लेषण की अत्यधिक सामान्य परिभाषा सॉफ्टवेयर कलाकृतियों में व्यवस्थित परिवर्तन करने के लिए वाक्यात्मक संरचनाओं पर सही प्रकार से परिभाषित नियमों का उपयोग कर रही है।[4] म्यूटेशन विश्लेषण अन्य समस्याओं पर क्रियान्वित किया गया है, परन्तु सामान्य तौर पर परीक्षण के लिए क्रियान्वित किया जाता है। इसलिए म्यूटेशन परीक्षण को नए सॉफ़्टवेयर परीक्षणों को डिज़ाइन करने या वर्तमान समय में उपस्थित सॉफ़्टवेयर परीक्षणों का मूल्यांकन करने के लिए म्यूटेशन विश्लेषण का उपयोग करने के रूप में परिभाषित किया गया है।[4]इस प्रकार, म्यूटेशन विश्लेषण और परीक्षण डिजाइन मॉडल, विनिर्देशों, डेटाबेस, परीक्षण, एक्सएमएल (XML) और अन्य प्रकार के सॉफ़्टवेयर कलाकृतियों पर क्रियान्वित किया जा सकता है, चूंकि म्यूटेशन प्रोग्राम सबसे सरल है।[5]

अवलोकन

किसी दिए गए सॉफ़्टवेयर सिस्टम के कार्यान्वयन की शुद्धता को सत्यापित करने के लिए टेस्ट बनाए जा सकते हैं, परन्तु परीक्षणों का निर्माण अभी भी यह सवाल खड़ा करता है कि क्या परीक्षण सही हैं और पर्याप्त प्रकार से उन आवश्यकताओं को पूरा करते हैं जो कार्यान्वयन से उत्पन्न हुई हैं।[6] (यह तकनीकी समस्या अपने आप में "क्विस कस्टोडाइट इप्सॉस कस्टोड्स" नाम की गंभीर दार्शनिक समस्या का उदाहरण है? [गार्ड की रखवाली कौन करेगा? ]।) म्यूटेशन परीक्षण के पीछे विचार यह है कि यदि उत्परिवर्ती प्रस्तुत किया जाता है, तो यह सामान्य प्रकार से प्रोग्राम के बग का कारण बनता है जिसे परिक्षण को खोजना चाहिए। इस प्रकार, परीक्षणों का परीक्षण किया जाता है। यदि परीक्षण सूट द्वारा उत्परिवर्ती का पता नहीं लगाया जाता है, तो यह सामान्यतौर पर इंगित करता है कि परीक्षण सूट उत्परिवर्ती द्वारा दर्शाए गए दोषों का पता लगाने में असमर्थ है, परन्तु यह भी संकेत कर सकता है कि म्यूटेशन में कोई दोष नहीं है, अर्थात म्यूटेशन वैध परिवर्तन है जिससे कार्यक्षमता प्रभावित न हो। एक (सामान्य) तरीका उत्परिवर्ती मान्य हो सकता है कि जो कोड बदल दिया गया है वह मृत कोड है जिसे कभी निष्पादित नहीं किया जाता है।

उच्च स्तर पर कार्य करने के लिए म्यूटेशन परीक्षण के लिए, बड़ी संख्या में उत्परिवर्ती सामान्यतौर पर प्रस्तुत किए जाते हैं, जिससे प्रोग्राम की बहुत बड़ी संख्या में प्रतियों का संकलन और निष्पादन होता है। म्यूटेशन परीक्षण के खर्च की इस समस्या ने सॉफ्टवेयर परीक्षण की विधि के रूप में इसका वास्तविक उपयोग कम कर दिया था। चूंकि, ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेजेज और इकाई का परीक्षण फ्रेमवर्क के बढ़ते उपयोग के कारण म्यूटेशन टेस्टिंग औजार का निर्माण हुआ है, जो किसी एप्लिकेशन के अलग-अलग हिस्सों का परीक्षण करते हैं।

लक्ष्य

म्यूटेशन परीक्षण के लक्ष्य एकाधिक हैं:

  • कोड के कमजोर परीक्षण वाले टुकड़ों की पहचान करें (जिनके लिए उत्परिवर्ती नहीं मारे (किल्ड ) गए हैं)[1]
  • कमजोर परीक्षणों की पहचान करें (जो उत्परिवर्ती को कभी नहीं मारते)[7]
  • म्यूटेशन स्कोर की गणना करें,[4] म्यूटेशन स्कोर मारे गए उत्परिवर्ती की संख्या/उत्परिवर्ती की कुल संख्या है।
  • कार्यक्रम में त्रुटि प्रसार और प्रसारित होने अवस्था के बारे में जानें।

इतिहास

म्यूटेशन परीक्षण मुख्य प्रकार से 1971 में छात्र के रूप में रिचर्ड लिप्टन द्वारा प्रस्तावित किया गया था,[8] और सबसे पहले डेमिलो, लिप्टन और सैवर्ड द्वारा विकसित और प्रकाशित किया गया था।[1] म्यूटेशन टेस्टिंग औजार का पहला कार्यान्वयन 1980 में येल विश्वविद्यालय से टिमोथी बड ने अपने पीएचडी कार्य (म्यूटेशन विश्लेषण शीर्षक) के पक्ष के रूप में किया था।[9]कुछ समय पहले ही, उच्च स्तर पर कंप्यूटिंग शक्ति की उपलब्धता के साथ, कंप्यूटर विज्ञान समुदाय के भीतर म्यूटेशन विश्लेषण का पुनरुत्थान हुआ है, और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग (एक कंप्यूटर प्रोग्रामिंग मॉडल है) भाषाओं और गैर-प्रक्रियात्मक भाषाओं जैसे एक्सएमएल, एसएमवी परिमित अवस्था की मशीनों में म्यूटेशन टेस्टिंग को क्रियान्वित करने के तरीकों को परिभाषित करने के लिए कार्य किया गया है।

2004 में सरटेस इंक. (सिनोप्सिस का हिस्सा) नामक एक कंपनी ने कई सिद्धांतों को हार्डवेयर सत्यापन डोमेन में विस्तारित किया है। यद्यपि म्यूटेशन विश्लेषण केवल उत्पादित आउटपुट में अंतर का पता लगाने की अपेक्षा करता है, सरटेस यह सत्यापित करके इसे बढ़ाता है कि टेस्टबेंच में चेकर वास्तव में अंतर का पता लगाएगा। इस विस्तार का अर्थ है कि सत्यापन के सभी तीन चरणों, अर्थात्: सक्रियण, प्रसार और पहचान का मूल्यांकन किया जाता है। उन्होंने इसे कार्यात्मक योग्यता कहा है।

फज़िंग को म्यूटेशन परीक्षण का विशेष कथन माना जा सकता है। फ़ज़िंग में, संचार इंटरफेस (सॉफ्टवेयर इंस्टेंसेस के अंदर और बीच दोनों) में आदान-प्रदान किए गए संदेशों या डेटा को संसाधित करने में विफलताओं या अंतरों को पकड़ने के लिए उत्परिवर्तित किया जाता है। कोडनोमिकॉन[10] (2001) और गतिकी में (2005) ने पूर्ण तरह की अवस्था म्यूटेशन टेस्टिंग प्लेटफॉर्म के लिए फ़ज़ परीक्षण अवधारणा विकसित किया, जो पूरी तरह से प्रोटोकॉल कार्यान्वयन के लिए मॉनिटर के साथ पूर्ण हुआ है।

म्यूटेशन परीक्षण अवलोकन

म्यूटेशन परीक्षण दो परिकल्पनाओं पर आधारित है। पहला सक्षम प्रोग्रामर परिकल्पना है। यह परिकल्पना बताती है कि सक्षम प्रोग्रामर ऐसे प्रोग्राम लिखते हैं जो सही होने के निकट हैं।[1]क्लोज का उद्देश्य व्यवहार पर आधारित होना है, सिंटैक्स पर नहीं। दूसरी परिकल्पना को युग्मन प्रभाव कहा जाता है। युग्मन प्रभाव का कथन है कि सरल दोष कैस्केड कर सकते हैं या जोड़े अन्य अप्रत्याशित दोष बना सकते हैं।[11][12] उच्च-क्रम के उत्परिवर्ती द्वारा सूक्ष्म और महत्वपूर्ण दोष भी प्रकट होते हैं, जो आगे युग्मन प्रभाव का समर्थन करते हैं।[13][14][7][15][16] एक से अत्यधिक म्यूटेशन वाले उत्परिवर्ती बनाकर उच्च-क्रम उत्परिवर्ती को कार्य करने योग्य किया जाता है।

म्यूटेशन ऑपरेटरों के समूह का चयन करके म्यूटेशन परीक्षण किया जाता है और फिर उन्हें स्रोत कोड के प्रत्येक क्रियान्वित टुकड़े के लिए एक बार में स्रोत प्रोग्राम में क्रियान्वित किया जाता है। प्रोग्राम में म्यूटेशन ऑपरेटर लगाने के परिणाम को उत्परिवर्ती कहा जाता है। यदि परीक्षण सूट परिवर्तन का पता लगाने में सक्षम है (अर्थात परीक्षणों में से विफल हो जाता है), तो उत्परिवर्ती को मार दिया जाना कहा जाता है।

उदाहरण के लिए, निम्नलिखित C++ कोड खंड पर विचार करें: 

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

The condition mutation operator would replace && with || and produce the following mutant: 

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

अब, इस उत्परिवर्ती को मारने के परीक्षण के लिए, निम्नलिखित तीन शर्तें पूरी की जानी चाहिए:

1. परीक्षण उत्परिवर्तित कथन तक पहुंचना चाहिए।

2. वास्तविकता में टेस्ट इनपुट डेटा को उत्परिवर्ती और मूल प्रोग्राम के लिए अलग-अलग प्रोग्राम स्टेट्स बनाकर प्रोग्राम स्टेट को बढ़ाना करना चाहिए। उदाहरण के लिए,a=1औरb=0वाला परिक्षण ऐसा करेगा।

3. गलत प्रोग्राम स्टेट ('सी' का मान) प्रोग्राम के आउटपुट के लिए प्रचारित होना चाहिए और परीक्षण द्वारा जांच की जानी चाहिए।

इन स्थितियों को सामूहिक रूप से आरआइपी मॉडल कहा जाता है।[8]

कमजोर म्यूटेशन परीक्षण (या कमजोर म्यूटेशन कवरेज) के लिए आवश्यक है कि केवल पहली और दूसरी अवस्था पूर्ण हों। मजबूत म्यूटेशन परीक्षण के लिए आवश्यक है कि तीनों अवस्था पूर्ण हों। मजबूत म्यूटेशन अत्यधिक शक्तिशाली है, क्योंकि यह सुनिश्चित करता है कि परीक्षण सूट वास्तव में समस्याओं को पकड़ सकता है। कमजोर म्यूटेशन कोड कवरेज़ विधियों से निकटता से संबंधित है। यह सुनिश्चित करने के लिए बहुत कम कंप्यूटिंग शक्ति की आवश्यकता होती है कि टेस्ट सूट मजबूत म्यूटेशन परीक्षण की तुलना में कमजोर म्यूटेशन परीक्षण को संतुष्ट करता है।

चूँकि, ऐसे कारण हैं जहां परीक्षण के स्थिति को ढूंढ़ना संभव नहीं है जो इस उत्परिवर्ती को मार सकते हैं। परिणामी प्रोग्राम व्यावहारिक प्रकार से मूल के बराबर है। ऐसे उत्परिवर्ती को समतुल्य उत्परिवर्ती कहा जाता है।

म्यूटेशन परीक्षण के व्यावहारिक उपयोग के लिए समतुल्य उत्परिवर्ती का पता लगाना सबसे बड़ी बाधाओं में से एक है। उत्परिवर्ती समकक्ष हैं या नहीं, यह जांचने के लिए आवश्यक प्रयास छोटे प्रोग्राम्स के लिए भी बहुत अत्यधिक हो सकते हैं।[17] समतुल्य उत्परिवर्ती समस्या को दूर करने के लिए दृष्टिकोणों की एक विस्तृत श्रृंखला की व्यवस्थित साहित्य समीक्षा है [18] 17 प्रासंगिक तकनीकों (22 लेखों में) और तकनीकों की तीन श्रेणियों की पहचान की: पता लगाना (डीईएम); सुझाव (एसइएम); और समतुल्य उत्परिवर्ती पीढ़ी (एइएमजी) से बचना है। प्रयोग ने संकेत दिया कि सामान्य प्रकार से उच्च क्रम म्यूटेशन और विशेष प्रकार से जूडीडिफऑप रणनीति समतुल्य उत्परिवर्ती समस्या के लिए आशाजनक दृष्टिकोण प्रदान करती है।

समतुल्य उत्परिवर्ती के अतिरिक्त, ऐसे उत्परिवर्ती म्यूटेंट हैं जो स्रोत कोड स्थान में अन्य उत्परिवर्ती के रूप में उपस्थित हैं, और कहा जाता है कि अन्य उत्परिवर्ती द्वारा सब्सक्राइब किया गया है। सम्मिलित उत्परिवर्ती म्यूटेशन परीक्षण उपकरण के लिए दृश्यमान नहीं हैं, और कवरेज मेट्रिक्स में योगदान नहीं करते हैं। उदाहरण के लिए, मान लें कि आपके पास दो म्यूटेंट, ए और बी हैं, जो दोनों एक ही तरह से कोड की पंक्ति बदलते हैं। उत्परिवर्ती ए का पहले परीक्षण किया जाता है, और इसका परिणाम यह होता है कि कोड सही प्रकार से कार्य नहीं कर रहा है। तब उत्परिवर्ती बी का परीक्षण किया जाता है, और परिणाम उत्परिवर्ती ए के समान होता है। इस कथन में, उत्परिवर्ती बी को उत्परिवर्ती ए द्वारा निर्वाह माना जाता है, क्योंकि उत्परिवर्ती बी के परीक्षण का परिणाम उत्परिवर्ती ए के परीक्षण के परिणाम के समान है। इसलिए, उत्परिवर्ती बी को परीक्षण करने की आवश्यकता नहीं है, क्योंकि परिणाम उत्परिवर्ती ए के समान ही होगा।




म्यूटेशन ऑपरेटर्स

शोधकर्ताओं द्वारा कई म्यूटेशन ऑपरेटरों का पता लगाया गया है। यहाँ अनिवार्य भाषाओं के लिए म्यूटेशन संचालकों के कुछ उदाहरण दिए गए हैं:

  • कथन विलोपन
  • कथन दोहराव या प्रविष्टि, उदा. गोटो फेल ;[19]
  • बूलियन उप-अभिव्यक्तियों को सही और गलत के साथ बदलना
  • कुछ अंकगणितीय संक्रियाओं को अन्य संक्रियाओं से बदलना, उदा.+साथ*,-साथ/
  • कुछ बूलियन संबंधों को अन्य के साथ बदलना, उदा.>साथ>=,==और<=
  • एक ही दायरे से दूसरों के साथ चर का प्रतिस्थापन (चर प्रकार संगत होना चाहिए)
  • विधि निकाय निकालें।[20]

इन म्यूटेशन ऑपरेटरों को पारंपरिक म्यूटेशन ऑपरेटर्स भी कहा जाता है। ऑब्जेक्ट-ओरिएंटेड भाषाओं के लिए म्यूटेशन ऑपरेटर भी हैं,[21] समवर्ती निर्माण के लिए,[22] जटिल वस्तुएं जैसे कंटेनर,[23] इत्यादि के लिए है। कंटेनरों के लिए ऑपरेटरों को क्लास-लेवल म्यूटेशन ऑपरेटर्स कहा जाता है। उदाहरण के लिए, मुजावा टूल विभिन्न क्लास-लेवल म्यूटेशन ऑपरेटर प्रदान करता है जैसे एक्सेस मॉडिफायर चेंज, टाइप कास्ट ऑपरेटर इंसर्शन, और टाइप कास्ट ऑपरेटर विलोपन इत्यादि है। प्रोग्राम्स की सुरक्षा भेद्यता परीक्षण करने के लिए म्यूटेशन ऑपरेटरों को विकसित किया गया है।[24]

यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 1.2 1.3 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. ↑ Ostrand, Thomas (2002), "White-Box Testing", Encyclopedia of Software Engineering (in English), American Cancer Society, doi:10.1002/0471028959.sof378, ISBN 978-0-471-02895-6, retrieved 2021-03-16
  3. ↑ Misra, S. (2003). "Evaluating four white-box test coverage methodologies". CCECE 2003 - Canadian Conference on Electrical and Computer Engineering. Toward a Caring and Humane Technology (Cat. No.03CH37436). Montreal, Que., Canada: IEEE. 3: 1739–1742. doi:10.1109/CCECE.2003.1226246. ISBN 978-0-7803-7781-3. S2CID 62549502.
  4. ↑ 4.0 4.1 4.2 Paul Ammann and Jeff Offutt. Introduction to Software Testing. Cambridge University Press, 2008.
  5. ↑ Jia, Yue; Harman, Mark (September 2009). "An Analysis and Survey of the Development of Mutation Testing" (PDF). CREST Centre, King's College London, Technical Report TR-09-06. 37 (5): 649–678. doi:10.1109/TSE.2010.62. S2CID 6853229. Archived from the original (PDF) on 2017-12-04.
  6. ↑ Dasso, Aristides; Funes, Ana (2007). Verification, Validation and Testing in Software Engineering. Idea Group Inc. ISBN 978-1591408512.
  7. ↑ 7.0 7.1 Smith B., "On Guiding Augmentation of an Automated Test Suite via Mutation Analysis," 2008
  8. ↑ 8.0 8.1 Mutation 2000: Uniting the Orthogonal by A. Jefferson Offutt and Roland H. Untch.
  9. ↑ Tim A. Budd, Mutation Analysis of Program Test Data. PhD thesis, Yale University New Haven CT, 1980.
  10. ↑ Kaksonen, Rauli. A Functional Method for Assessing Protocol Implementation Security (Licentiate thesis). Espoo. 2001.
  11. ↑ A. Jefferson Offutt. 1992. Investigations of the software testing coupling effect. ACM Trans. Softw. Eng. Methodol. 1, 1 (January 1992), 5-20.
  12. ↑ 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.
  13. ↑ 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
  14. ↑ Maryam Umar, "An Evaluation of Mutation Operators For Equivalent Mutants," MS Thesis, 2006
  15. ↑ Polo M. and Piattini M., "Mutation Testing: practical aspects and cost analysis," University of Castilla-La Mancha (Spain), Presentation, 2009
  16. ↑ Anderson S., "Mutation Testing", the University of Edinburgh, School of Informatics, Presentation, 2011
  17. ↑ 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.
  18. ↑ 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
  19. ↑ Apple's SSL/TLS bug by Adam Langley.
  20. ↑ Niedermayr, Rainer; Juergens, Elmar; Wagner, Stefan (2016-05-14). "Will my tests tell me if I break this code?". Proceedings of the International Workshop on Continuous Software Evolution and Delivery. CSED '16. Austin, Texas: Association for Computing Machinery: 23–29. arXiv:1611.07163. doi:10.1145/2896941.2896944. ISBN 978-1-4503-4157-8. S2CID 9213147.
  21. ↑ MuJava: An Automated Class Mutation System by Yu-Seung Ma, Jeff Offutt and Yong Rae Kwo.
  22. ↑ Mutation Operators for Concurrent Java (J2SE 5.0) by Jeremy S. Bradbury, James R. Cordy, Juergen Dingel.
  23. ↑ Mutation of Java Objects by Roger T. Alexander, James M. Bieman, Sudipto Ghosh, Bixia Ji.
  24. ↑ Mutation-based Testing of Buffer Overflows, SQL Injections, and Format String Bugs by H. Shahriar and M. Zulkernine.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=म्यूटेशन_टेस्टिंग&oldid=254513’