मॉडल-आधारित परीक्षण

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

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

परीक्षण विभिन्न तरीकों से मॉडल से प्राप्त किए जा सकते हैं। क्योंकि परीक्षण आमतौर पर प्रायोगिक होता है और अनुमान पर आधारित होता है, परीक्षण व्युत्पत्ति के लिए कोई सर्वोत्तम तरीका ज्ञात नहीं है। सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को में समेकित करना आम बात है पैकेज जिसे अक्सर परीक्षण आवश्यकताओं, परीक्षण उद्देश्य या यहां तक ​​कि उपयोग के मामलों के रूप में जाना जाता है। इस पैकेज में मॉडल के उन हिस्सों के बारे में जानकारी हो सकती है जिन पर ध्यान केंद्रित किया जाना चाहिए, या परीक्षण समाप्त करने की शर्तों (परीक्षण रोकने के मानदंड) के बारे में जानकारी हो सकती है।

क्योंकि परीक्षण सूट मॉडल से प्राप्त होते हैं न कि स्रोत कोड से, मॉडल-आधारित परीक्षण को आमतौर पर ब्लैक-बॉक्स परीक्षण के रूप के रूप में देखा जाता है।

जटिल सॉफ्टवेयर सिस्टम के लिए मॉडल-आधारित परीक्षण अभी भी विकसित क्षेत्र है।

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

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

निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण मामलों को कंप्यूटर-पठनीय संपत्तियों के रूप में उत्पन्न करता है जिन्हें बाद में स्वचालित रूप से चलाया जा सकता है; उदाहरण के लिए, पायथन (प्रोग्रामिंग भाषा) कक्षाओं का संग्रह जो उत्पन्न परीक्षण तर्क का प्रतीक है।

मैन्युअल रूप से परिनियोजन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण मामलों को मानव-पठनीय संपत्तियों के रूप में उत्पन्न करता है जो बाद में मैन्युअल परीक्षण में सहायता कर सकते हैं; उदाहरण के लिए, मानव भाषा में पीडीएफ दस्तावेज़ जो उत्पन्न परीक्षण चरणों का वर्णन करता है।

एल्गोरिदम के अनुसार परीक्षण प्राप्त करना
मॉडल-आधारित परीक्षण की प्रभावशीलता मुख्य रूप से इसके द्वारा प्रदान की जाने वाली स्वचालन की क्षमता के कारण है। यदि कोई मॉडल मशीन-पठनीय है और इस हद तक औपचारिक है कि इसमें अच्छी तरह से परिभाषित व्यवहारिक व्याख्या है, तो परीक्षण मामलों को सिद्धांत रूप से यांत्रिक रूप से प्राप्त किया जा सकता है।

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

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

प्रमेय सिद्ध करना
प्रमेय सिद्ध करना मूल रूप से तार्किक सूत्रों को स्वचालित रूप से सिद्ध करने के लिए उपयोग किया गया था। मॉडल-आधारित परीक्षण दृष्टिकोण के लिए, सिस्टम को सिस्टम के व्यवहार को निर्दिष्ट करते हुए, विधेय (तर्क)तर्क) के सेट द्वारा मॉडल किया जाता है। परीक्षण मामलों को प्राप्त करने के लिए, मॉडल को परीक्षण के तहत प्रणाली का वर्णन करने वाले विधेय के सेट की वैध व्याख्या पर समतुल्य वर्गों में विभाजित किया गया है। प्रत्येक वर्ग निश्चित सिस्टम व्यवहार का वर्णन करता है, और इसलिए, परीक्षण मामले के रूप में काम कर सकता है। सबसे सरल विभाजन विघटनकारी सामान्य रूप दृष्टिकोण के साथ है जिसमें सिस्टम के व्यवहार का वर्णन करने वाली तार्किक अभिव्यक्तियाँ विघटनकारी सामान्य रूप में बदल जाती हैं।

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

बाधा प्रोग्रामिंग को प्रतीकात्मक निष्पादन के साथ जोड़ा जा सकता है। इस दृष्टिकोण में सिस्टम मॉडल को प्रतीकात्मक रूप से निष्पादित किया जाता है, यानी विभिन्न नियंत्रण पथों पर डेटा बाधाओं को एकत्रित करना, और फिर बाधाओं को हल करने और परीक्षण मामलों का उत्पादन करने के लिए बाधा प्रोग्रामिंग विधि का उपयोग करना।

मॉडल जाँच
मॉडल जांच का उपयोग टेस्ट केस जेनरेशन के लिए भी किया जा सकता है। मूल रूप से मॉडल चेकिंग को यह जांचने की तकनीक के रूप में विकसित किया गया था कि किसी मॉडल में किसी विनिर्देश की संपत्ति मान्य है या नहीं। जब परीक्षण के लिए उपयोग किया जाता है, तो परीक्षण के तहत सिस्टम का मॉडल और परीक्षण के लिए संपत्ति मॉडल चेकर को प्रदान की जाती है। प्रूफिंग की प्रक्रिया के भीतर, यदि यह संपत्ति मॉडल में मान्य है, तो मॉडल चेकर गवाहों और प्रति-उदाहरणों का पता लगाता है। गवाह ऐसा मार्ग है जहां संपत्ति संतुष्ट होती है, जबकि प्रति-उदाहरण मॉडल के निष्पादन में पथ है जहां संपत्ति का उल्लंघन होता है। इन पथों को फिर से परीक्षण मामलों के रूप में उपयोग किया जा सकता है।

मार्कोव श्रृंखला परीक्षण मॉडल का उपयोग करके केस निर्माण का परीक्षण करें
मार्कोव श्रृंखला मॉडल-आधारित परीक्षण को संभालने का कुशल तरीका है। मार्कोव श्रृंखलाओं के साथ साकार किए गए परीक्षण मॉडल को उपयोग मॉडल के रूप में समझा जा सकता है: इसे उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण के रूप में जाना जाता है। उपयोग मॉडल, इसलिए मार्कोव श्रृंखलाएं, मुख्य रूप से 2 कलाकृतियों से निर्मित होती हैं: परिमित राज्य मशीन (एफएसएम) जो परीक्षण किए गए सिस्टम के सभी संभावित उपयोग परिदृश्यों का प्रतिनिधित्व करती है और ऑपरेशनल प्रोफाइल (ओपी) जो एफएसएम को यह दर्शाने के लिए योग्य बनाती है कि सिस्टम कैसा है या होगा सांख्यिकीय रूप से उपयोग किया जाए। पहला (एफएसएम) यह जानने में मदद करता है कि क्या परीक्षण किया जा सकता है या किया गया है और दूसरा (ओपी) परिचालन परीक्षण मामलों को प्राप्त करने में मदद करता है। उपयोग/सांख्यिकीय मॉडल-आधारित परीक्षण उन तथ्यों से शुरू होता है जो किसी सिस्टम का संपूर्ण परीक्षण करना संभव नहीं है और विफलता बहुत कम दर के साथ सामने आ सकती है। यह दृष्टिकोण सांख्यिकीय रूप से परीक्षण मामलों को प्राप्त करने का व्यावहारिक तरीका प्रदान करता है जो परीक्षण के तहत सिस्टम की विश्वसनीयता में सुधार करने पर केंद्रित है। उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण को हाल ही में एम्बेडेड सॉफ़्टवेयर सिस्टम पर लागू करने के लिए विस्तारित किया गया था।

यह भी देखें

 * डोमेन-विशिष्ट भाषा (डीएसएल)
 * डोमेन-विशिष्ट मॉडलिंग (डीएसएम)
 * मॉडल-संचालित वास्तुकला (एमडीए)
 * मॉडल-संचालित इंजीनियरिंग (एमडीई)
 * वस्तु-उन्मुख विश्लेषण और डिजाइन (ओओएडी)
 * समय विभाजन परीक्षण (टीपीटी)

अग्रिम पठन

 * OMG UML 2 Testing Profile;
 * Practical Model-Based Testing: A Tools Approach, Mark Utting and Bruno Legeard, ISBN 978-0-12-372501-1, Morgan-Kaufmann 2007.
 * Model-Based Software Testing and Analysis with C#, Jonathan Jacky, Margus Veanes, Colin Campbell, and Wolfram Schulte, ISBN 978-0-521-68761-4, Cambridge University Press 2008.
 * Model-Based Testing of Reactive Systems Advanced Lecture Series, LNCS 3472, Springer-Verlag, 2005. ISBN 978-3-540-26278-7.
 * A Systematic Review of Model Based Testing Tool Support, Muhammad Shafique, Yvan Labiche, Carleton University, Technical Report, May 2010.
 * 2011/2012 Model-based Testing User Survey: Results and Analysis. Robert V. Binder. System Verification Associates, February 2012
 * A Systematic Review of Model Based Testing Tool Support, Muhammad Shafique, Yvan Labiche, Carleton University, Technical Report, May 2010.
 * 2011/2012 Model-based Testing User Survey: Results and Analysis. Robert V. Binder. System Verification Associates, February 2012
 * A Systematic Review of Model Based Testing Tool Support, Muhammad Shafique, Yvan Labiche, Carleton University, Technical Report, May 2010.
 * 2011/2012 Model-based Testing User Survey: Results and Analysis. Robert V. Binder. System Verification Associates, February 2012
 * 2011/2012 Model-based Testing User Survey: Results and Analysis. Robert V. Binder. System Verification Associates, February 2012