म्यूटेशन टेस्टिंग

From Vigyanwiki

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

म्यूटेशन टेस्टिंग (याम्यूटेशन विश्लेषण याप्रोग्राम म्यूटेशन) का उपयोग नए सॉफ्टवेयर परीक्षणों को डिजाइन करने और उपस्थित सॉफ्टवेयर परीक्षणों की गुणवत्ता का मूल्यांकन करने के लिए किया जाता है। म्यूटेशन परीक्षण में प्रोग्राम को छोटे तरीकों से संशोधित करना सम्मिलित है।[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’