मॉडल-आधारित परीक्षण: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
[[File:Mbt-overview.png|frame|सामान्य मॉडल-आधारित परीक्षण सेटिंग]]मॉडल-आधारित परीक्षण सॉफ्टवेयर परीक्षण या [[सिस्टम परीक्षण]] करने के लिए कलाकृतियों को डिजाइन करने और वैकल्पिक रूप से निष्पादित करने के लिए [[मॉडल-आधारित डिज़ाइन]] का अनुप्रयोग है। मॉडल का उपयोग परीक्षण (एसयूटी) के | [[File:Mbt-overview.png|frame|सामान्य मॉडल-आधारित परीक्षण सेटिंग]]'''मॉडल-आधारित परीक्षण''' सॉफ्टवेयर परीक्षण या [[सिस्टम परीक्षण]] करने के लिए कलाकृतियों को डिजाइन करने और वैकल्पिक रूप से निष्पादित करने के लिए [[मॉडल-आधारित डिज़ाइन]] का एक अनुप्रयोग है। मॉडल का उपयोग परीक्षण (एसयूटी) के अनुसार सिस्टम के वांछित व्यवहार का प्रतिनिधित्व करने के लिए, या परीक्षण रणनीतियों और परीक्षण वातावरण का प्रतिनिधित्व करने के लिए किया जा सकता है। दाईं ओर का चित्र पूर्व दृष्टिकोण को दर्शाता है। | ||
एसयूटी का वर्णन करने वाला मॉडल सामान्यतः एसयूटी के वांछित व्यवहार की अमूर्त, आंशिक प्रस्तुति है। | |||
ऐसे मॉडल से प्राप्त परीक्षण स्थितियां मॉडल के समान अमूर्त स्तर पर कार्यात्मक परीक्षण होते हैं। | |||
इन परीक्षण स्थितियों को सामूहिक रूप से अमूर्त परीक्षण सूट के रूप में जाना जाता है। | |||
अमूर्त परीक्षण सूट को सीधे एसयूटी के विरुद्ध निष्पादित नहीं किया जा सकता क्योंकि सूट अमूर्तता के गलत स्तर पर है। | |||
[[निष्पादन योग्य परीक्षण सूट]] को संबंधित सार परीक्षण सूट से प्राप्त करने की आवश्यकता है। | [[निष्पादन योग्य परीक्षण सूट]] को संबंधित सार परीक्षण सूट से प्राप्त करने की आवश्यकता है। | ||
निष्पादन योग्य परीक्षण सूट परीक्षण के | |||
यह अमूर्त परीक्षण | निष्पादन योग्य परीक्षण सूट परीक्षण के अनुसार सिस्टम के साथ सीधे संचार कर सकता है। | ||
यह निष्पादन के लिए उपयुक्त अमूर्त परीक्षण स्थितियों को ठोस परीक्षण स्थितियों में मैप करके प्राप्त किया जाता है। | |||
कुछ मॉडल-आधारित परीक्षण परिवेशों में, मॉडल में सीधे निष्पादन योग्य परीक्षण सूट उत्पन्न करने के लिए पर्याप्त जानकारी होती है। | |||
दूसरों में, ठोस परीक्षण सूट बनाने के लिए अमूर्त परीक्षण सूट के तत्वों को [[सॉफ़्टवेयर परीक्षण]] विशिष्ट कथनों या विधि कॉलों पर मैप किया जाना चाहिए। इसे मैपिंग समस्या का समाधान कहा जाता है।<ref name="Jeff Offutt 2016">Paul Ammann and Jeff Offutt. Introduction to Software Testing, 2nd edition. Cambridge University Press, 2016.</ref> | दूसरों में, ठोस परीक्षण सूट बनाने के लिए अमूर्त परीक्षण सूट के तत्वों को [[सॉफ़्टवेयर परीक्षण]] विशिष्ट कथनों या विधि कॉलों पर मैप किया जाना चाहिए। इसे मैपिंग समस्या का समाधान कहा जाता है।<ref name="Jeff Offutt 2016">Paul Ammann and Jeff Offutt. Introduction to Software Testing, 2nd edition. Cambridge University Press, 2016.</ref> | ||
परीक्षण विभिन्न | ऑनलाइन परीक्षण (नीचे देखें) के स्थितियां में, अमूर्त परीक्षण सूट केवल वैचारिक रूप से उपस्थित हैं, किन्तु स्पष्ट कलाकृतियों के रूप में नहीं हैं। | ||
परीक्षण व्युत्पत्ति के लिए कोई सर्वोत्तम | |||
सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को में समेकित करना | परीक्षण विभिन्न प्रणालियों से मॉडल से प्राप्त किए जा सकते हैं। क्योंकि परीक्षण सामान्यतः प्रायोगिक होता है और अनुमान पर आधारित होता है, इसलिए परीक्षण व्युत्पत्ति के लिए कोई एक सर्वोत्तम प्रणाली ज्ञात नहीं है। | ||
सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को एक पैकेज में समेकित करना सामान्य बात है जिसे अधिकांश "परीक्षण आवश्यकताएं", "परीक्षण उद्देश्य" या यहां तक कि "उपयोग स्थितियां" के रूप में जाना जाता है। | |||
इस पैकेज में मॉडल के उन हिस्सों के बारे में जानकारी हो सकती है जिन पर ध्यान केंद्रित किया जाना चाहिए, या परीक्षण समाप्त करने की शर्तों (परीक्षण रोकने के मानदंड) के बारे में जानकारी हो सकती है। | इस पैकेज में मॉडल के उन हिस्सों के बारे में जानकारी हो सकती है जिन पर ध्यान केंद्रित किया जाना चाहिए, या परीक्षण समाप्त करने की शर्तों (परीक्षण रोकने के मानदंड) के बारे में जानकारी हो सकती है। | ||
क्योंकि परीक्षण सूट मॉडल से प्राप्त होते हैं न कि स्रोत कोड से, मॉडल-आधारित परीक्षण को | क्योंकि परीक्षण सूट मॉडल से प्राप्त होते हैं न कि स्रोत कोड से, मॉडल-आधारित परीक्षण को सामान्यतः [[ब्लैक-बॉक्स परीक्षण]] के रूप के रूप में देखा जाता है। | ||
जटिल सॉफ्टवेयर सिस्टम के लिए मॉडल-आधारित परीक्षण अभी भी विकसित क्षेत्र है। | जटिल सॉफ्टवेयर सिस्टम के लिए मॉडल-आधारित परीक्षण अभी भी विकसित क्षेत्र है। | ||
| Line 26: | Line 35: | ||
==मॉडल-आधारित परीक्षण तैनात करना== | ==मॉडल-आधारित परीक्षण तैनात करना== | ||
[[File:Mbt-process-example.png|right|frame|मॉडल-आधारित परीक्षण वर्कफ़्लो (ऑफ़लाइन परीक्षण केस पीढ़ी) का उदाहरण। IXIT अतिरिक्त जानकारी के कार्यान्वयन को संदर्भित करता है और अमूर्त परीक्षण सूट को निष्पादन योग्य में बदलने के लिए आवश्यक जानकारी को संदर्भित करता है। | [[File:Mbt-process-example.png|right|frame|मॉडल-आधारित परीक्षण वर्कफ़्लो (ऑफ़लाइन परीक्षण केस पीढ़ी) का उदाहरण। IXIT अतिरिक्त जानकारी के कार्यान्वयन को संदर्भित करता है और अमूर्त परीक्षण सूट को निष्पादन योग्य में बदलने के लिए आवश्यक जानकारी को संदर्भित करता है। सामान्यतः, IXIT में परीक्षण हार्नेस, डेटा मैपिंग और एसयूटी कॉन्फ़िगरेशन की जानकारी होती है।]]मॉडल-आधारित परीक्षण को तैनात करने के विभिन्न ज्ञात तरीके हैं, जिनमें ऑनलाइन परीक्षण, निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी और मैन्युअल रूप से तैनाती योग्य परीक्षणों की ऑफ़लाइन पीढ़ी शामिल है।<ref name="pmbt">[http://www.cs.waikato.ac.nz/research/mbt/ ''Practical Model-Based Testing: A Tools Approach''] {{webarchive|url=https://web.archive.org/web/20120825215944/http://www.cs.waikato.ac.nz/research/mbt/ |date=2012-08-25 }}, Mark Utting and Bruno Legeard, {{ISBN|978-0-12-372501-1}}, Morgan-Kaufmann 2007</ref> | ||
ऑनलाइन परीक्षण का मतलब है कि मॉडल-आधारित परीक्षण उपकरण सीधे एसयूटी से जुड़ता है और इसे गतिशील रूप से परीक्षण करता है। | ऑनलाइन परीक्षण का मतलब है कि मॉडल-आधारित परीक्षण उपकरण सीधे एसयूटी से जुड़ता है और इसे गतिशील रूप से परीक्षण करता है। | ||
निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण | निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण स्थितियों को कंप्यूटर-पठनीय संपत्तियों के रूप में उत्पन्न करता है जिन्हें बाद में स्वचालित रूप से चलाया जा सकता है; उदाहरण के लिए, [[पायथन (प्रोग्रामिंग भाषा)]] कक्षाओं का संग्रह जो उत्पन्न परीक्षण तर्क का प्रतीक है। | ||
मैन्युअल रूप से परिनियोजन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण | मैन्युअल रूप से परिनियोजन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण स्थितियों को मानव-पठनीय संपत्तियों के रूप में उत्पन्न करता है जो बाद में मैन्युअल परीक्षण में सहायता कर सकते हैं; उदाहरण के लिए, मानव भाषा में पीडीएफ दस्तावेज़ जो उत्पन्न परीक्षण चरणों का वर्णन करता है। | ||
==एल्गोरिदम के अनुसार परीक्षण प्राप्त करना== | ==एल्गोरिदम के अनुसार परीक्षण प्राप्त करना== | ||
मॉडल-आधारित परीक्षण की प्रभावशीलता मुख्य रूप से इसके द्वारा प्रदान की जाने वाली स्वचालन की क्षमता के कारण है। यदि कोई मॉडल मशीन-पठनीय है और इस हद तक औपचारिक है कि इसमें अच्छी तरह से परिभाषित व्यवहारिक व्याख्या है, तो परीक्षण | मॉडल-आधारित परीक्षण की प्रभावशीलता मुख्य रूप से इसके द्वारा प्रदान की जाने वाली स्वचालन की क्षमता के कारण है। यदि कोई मॉडल मशीन-पठनीय है और इस हद तक औपचारिक है कि इसमें अच्छी तरह से परिभाषित व्यवहारिक व्याख्या है, तो परीक्षण स्थितियों को सिद्धांत रूप से यांत्रिक रूप से प्राप्त किया जा सकता है। | ||
===परिमित अवस्था मशीनों से=== | ===परिमित अवस्था मशीनों से=== | ||
अधिकांश मॉडल को परिमित राज्य ऑटोमेटन या [[राज्य संक्रमण प्रणाली]] के रूप में अनुवादित या व्याख्या किया जाता है। यह ऑटोमेटन परीक्षण के अनुसार सिस्टम के संभावित कॉन्फ़िगरेशन का प्रतिनिधित्व करता है। परीक्षण स्थितियों को खोजने के लिए, निष्पादन योग्य पथों के लिए ऑटोमेटन की खोज की जाती है। संभावित निष्पादन पथ परीक्षण स्थितियां के रूप में काम कर सकता है। यह विधि तब काम करती है जब मॉडल [[नियतात्मक प्रणाली (गणित)]] है या इसे नियतात्मक प्रणाली में बदला जा सकता है। इन मॉडलों में अनिर्दिष्ट बदलावों का लाभ उठाकर मूल्यवान ऑफ-नोमिनल परीक्षण स्थितियां प्राप्त किए जा सकते हैं। | |||
परीक्षण के | परीक्षण के अनुसार सिस्टम की जटिलता और संबंधित मॉडल के आधार पर पथों की संख्या बहुत बड़ी हो सकती है, क्योंकि सिस्टम के संभावित कॉन्फ़िगरेशन की बड़ी मात्रा होती है। ऐसे परीक्षण स्थितियों को खोजने के लिए जो उचित, किन्तु सीमित, पथों की संख्या को कवर कर सकते हैं, चयन को निर्देशित करने के लिए परीक्षण मानदंड की आवश्यकता होती है। इस तकनीक को सबसे पहले ऑफ़ुट और अब्दुरज़िक द्वारा उस पेपर में प्रस्तावित किया गया था जिसने मॉडल-आधारित परीक्षण शुरू किया था।<ref>Jeff Offutt and Aynur Abdurazik. Generating Tests from UML Specifications. Second International Conference on the Unified Modeling Language (UML ’99), pages 416-429, Fort Collins, CO, October 1999.</ref> टेस्ट केस जेनरेशन के लिए कई तकनीकें विकसित की गई हैं और रशबी द्वारा उनका सर्वेक्षण किया गया है।<ref>John Rushby. Automated Test Generation and Verified Software. Verified Software: Theories, Tools, Experiments: First IFIP TC 2/WG 2.3 Conference, VSTTE 2005, Zurich, Switzerland, October 10–13. pp. 161-172, Springer-Verlag</ref> परीक्षण मानदंड को परीक्षण पाठ्यपुस्तक में सामान्य ग्राफ़ के संदर्भ में वर्णित किया गया है।<ref name="Jeff Offutt 2016"/> | ||
===[[प्रमेय सिद्ध करना]]=== | ===[[प्रमेय सिद्ध करना]]=== | ||
प्रमेय सिद्ध करना मूल रूप से तार्किक सूत्रों को स्वचालित रूप से सिद्ध करने के लिए उपयोग किया गया था। मॉडल-आधारित परीक्षण दृष्टिकोण के लिए, सिस्टम को सिस्टम के व्यवहार को निर्दिष्ट करते हुए, [[विधेय (तर्क)]]तर्क) के सेट द्वारा मॉडल किया जाता है।<ref name="otbt">{{Cite journal|first1=Achim D.|last1=Brucker|first2=Burkhart|last2=Wolff|title=प्रमेय नीति-आधारित परीक्षण पर|journal=Formal Aspects of Computing|volume=25|issue=5|pages=683–721|year=2012|doi=10.1007/s00165-012-0222-y|url=http://www.brucker.ch/bibliography/abstract/brucker.ea-theorem-prover-2012.en.html|citeseerx=10.1.1.208.3135|s2cid=5774837}}</ref> परीक्षण | प्रमेय सिद्ध करना मूल रूप से तार्किक सूत्रों को स्वचालित रूप से सिद्ध करने के लिए उपयोग किया गया था। मॉडल-आधारित परीक्षण दृष्टिकोण के लिए, सिस्टम को सिस्टम के व्यवहार को निर्दिष्ट करते हुए, [[विधेय (तर्क)]]तर्क) के सेट द्वारा मॉडल किया जाता है।<ref name="otbt">{{Cite journal|first1=Achim D.|last1=Brucker|first2=Burkhart|last2=Wolff|title=प्रमेय नीति-आधारित परीक्षण पर|journal=Formal Aspects of Computing|volume=25|issue=5|pages=683–721|year=2012|doi=10.1007/s00165-012-0222-y|url=http://www.brucker.ch/bibliography/abstract/brucker.ea-theorem-prover-2012.en.html|citeseerx=10.1.1.208.3135|s2cid=5774837}}</ref> परीक्षण स्थितियों को प्राप्त करने के लिए, मॉडल को परीक्षण के अनुसार प्रणाली का वर्णन करने वाले विधेय के सेट की वैध व्याख्या पर [[समतुल्य वर्ग]]ों में विभाजित किया गया है। प्रत्येक वर्ग निश्चित सिस्टम व्यवहार का वर्णन करता है, और इसलिए, परीक्षण स्थितियां के रूप में काम कर सकता है। सबसे सरल विभाजन विघटनकारी सामान्य रूप दृष्टिकोण के साथ है जिसमें सिस्टम के व्यवहार का वर्णन करने वाली तार्किक अभिव्यक्तियाँ विघटनकारी सामान्य रूप में बदल जाती हैं। | ||
===बाधा तर्क प्रोग्रामिंग और प्रतीकात्मक निष्पादन=== | ===बाधा तर्क प्रोग्रामिंग और प्रतीकात्मक निष्पादन=== | ||
[[बाधा प्रोग्रामिंग]] का उपयोग चर के सेट पर बाधाओं के सेट को हल करके विशिष्ट बाधाओं को संतुष्ट करने वाले परीक्षण | [[बाधा प्रोग्रामिंग]] का उपयोग चर के सेट पर बाधाओं के सेट को हल करके विशिष्ट बाधाओं को संतुष्ट करने वाले परीक्षण स्थितियों का चयन करने के लिए किया जा सकता है। सिस्टम का वर्णन बाधाओं के माध्यम से किया गया है।<ref>Jefferson Offutt. Constraint-Based Automatic Test Data Generation. IEEE Transactions on Software Engineering, 17:900-910, 1991</ref> बाधाओं के सेट को हल करना बूलियन सॉल्वरों (उदाहरण के लिए [[बूलियन संतुष्टि समस्या]] पर आधारित एसएटी-सॉल्वर्स) या गॉसियन उन्मूलन जैसे [[संख्यात्मक विश्लेषण]] द्वारा किया जा सकता है। बाधाओं के सूत्रों के सेट को हल करके पाया गया समाधान संबंधित प्रणाली के लिए परीक्षण स्थितियों के रूप में काम कर सकता है। | ||
बाधा प्रोग्रामिंग को प्रतीकात्मक निष्पादन के साथ जोड़ा जा सकता है। इस दृष्टिकोण में सिस्टम मॉडल को प्रतीकात्मक रूप से निष्पादित किया जाता है, यानी विभिन्न नियंत्रण पथों पर डेटा बाधाओं को एकत्रित करना, और फिर बाधाओं को हल करने और परीक्षण | बाधा प्रोग्रामिंग को प्रतीकात्मक निष्पादन के साथ जोड़ा जा सकता है। इस दृष्टिकोण में सिस्टम मॉडल को प्रतीकात्मक रूप से निष्पादित किया जाता है, यानी विभिन्न नियंत्रण पथों पर डेटा बाधाओं को एकत्रित करना, और फिर बाधाओं को हल करने और परीक्षण स्थितियों का उत्पादन करने के लिए बाधा प्रोग्रामिंग विधि का उपयोग करना।<ref>Antti Huima. Implementing Conformiq Qtronic. | ||
Testing of Software and Communicating Systems, | Testing of Software and Communicating Systems, | ||
Lecture Notes in Computer Science, 2007, Volume 4581/2007, 1-12, DOI: 10.1007/978-3-540-73066-8_1 | Lecture Notes in Computer Science, 2007, Volume 4581/2007, 1-12, DOI: 10.1007/978-3-540-73066-8_1 | ||
| Line 55: | Line 64: | ||
===मॉडल जाँच=== | ===मॉडल जाँच=== | ||
[[ मॉडल जांच ]] का उपयोग टेस्ट केस जेनरेशन के लिए भी किया जा सकता है।<ref>Gordon Fraser, Franz Wotawa, and Paul E. Ammann. Testing with model checkers: a survey. Software Testing, Verification and Reliability, 19(3):215–261, 2009. URL: [https://archive.today/20130105114035/http://www3.interscience.wiley.com/journal/121560421/abstract]</ref> मूल रूप से मॉडल चेकिंग को यह जांचने की तकनीक के रूप में विकसित किया गया था कि किसी मॉडल में किसी विनिर्देश की संपत्ति मान्य है या नहीं। जब परीक्षण के लिए उपयोग किया जाता है, तो परीक्षण के | [[ मॉडल जांच ]] का उपयोग टेस्ट केस जेनरेशन के लिए भी किया जा सकता है।<ref>Gordon Fraser, Franz Wotawa, and Paul E. Ammann. Testing with model checkers: a survey. Software Testing, Verification and Reliability, 19(3):215–261, 2009. URL: [https://archive.today/20130105114035/http://www3.interscience.wiley.com/journal/121560421/abstract]</ref> मूल रूप से मॉडल चेकिंग को यह जांचने की तकनीक के रूप में विकसित किया गया था कि किसी मॉडल में किसी विनिर्देश की संपत्ति मान्य है या नहीं। जब परीक्षण के लिए उपयोग किया जाता है, तो परीक्षण के अनुसार सिस्टम का मॉडल और परीक्षण के लिए संपत्ति मॉडल चेकर को प्रदान की जाती है। प्रूफिंग की प्रक्रिया के भीतर, यदि यह संपत्ति मॉडल में मान्य है, तो मॉडल चेकर गवाहों और प्रति-उदाहरणों का पता लगाता है। गवाह ऐसा मार्ग है जहां संपत्ति संतुष्ट होती है, जबकि प्रति-उदाहरण मॉडल के निष्पादन में पथ है जहां संपत्ति का उल्लंघन होता है। इन पथों को फिर से परीक्षण स्थितियों के रूप में उपयोग किया जा सकता है। | ||
===मार्कोव श्रृंखला परीक्षण मॉडल का उपयोग करके केस निर्माण का परीक्षण करें=== | ===मार्कोव श्रृंखला परीक्षण मॉडल का उपयोग करके केस निर्माण का परीक्षण करें=== | ||
मार्कोव श्रृंखला मॉडल-आधारित परीक्षण को संभालने का कुशल तरीका है। मार्कोव श्रृंखलाओं के साथ साकार किए गए परीक्षण मॉडल को उपयोग मॉडल के रूप में समझा जा सकता है: इसे उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण के रूप में जाना जाता है। उपयोग मॉडल, इसलिए मार्कोव श्रृंखलाएं, मुख्य रूप से 2 कलाकृतियों से निर्मित होती हैं: परिमित राज्य मशीन (एफएसएम) जो परीक्षण किए गए सिस्टम के सभी संभावित उपयोग परिदृश्यों का प्रतिनिधित्व करती है और ऑपरेशनल प्रोफाइल (ओपी) जो एफएसएम को यह दर्शाने के लिए योग्य बनाती है कि सिस्टम कैसा है या होगा सांख्यिकीय रूप से उपयोग किया जाए। पहला (एफएसएम) यह जानने में मदद करता है कि क्या परीक्षण किया जा सकता है या किया गया है और दूसरा (ओपी) परिचालन परीक्षण | मार्कोव श्रृंखला मॉडल-आधारित परीक्षण को संभालने का कुशल तरीका है। मार्कोव श्रृंखलाओं के साथ साकार किए गए परीक्षण मॉडल को उपयोग मॉडल के रूप में समझा जा सकता है: इसे उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण के रूप में जाना जाता है। उपयोग मॉडल, इसलिए मार्कोव श्रृंखलाएं, मुख्य रूप से 2 कलाकृतियों से निर्मित होती हैं: परिमित राज्य मशीन (एफएसएम) जो परीक्षण किए गए सिस्टम के सभी संभावित उपयोग परिदृश्यों का प्रतिनिधित्व करती है और ऑपरेशनल प्रोफाइल (ओपी) जो एफएसएम को यह दर्शाने के लिए योग्य बनाती है कि सिस्टम कैसा है या होगा सांख्यिकीय रूप से उपयोग किया जाए। पहला (एफएसएम) यह जानने में मदद करता है कि क्या परीक्षण किया जा सकता है या किया गया है और दूसरा (ओपी) परिचालन परीक्षण स्थितियों को प्राप्त करने में मदद करता है। | ||
उपयोग/सांख्यिकीय मॉडल-आधारित परीक्षण उन तथ्यों से शुरू होता है जो किसी सिस्टम का संपूर्ण परीक्षण करना संभव नहीं है और विफलता बहुत कम दर के साथ सामने आ सकती है।<ref>Helene Le Guen. Validation d'un logiciel par le test statistique d'usage : de la modelisation de la decision à la livraison, 2005. URL:ftp://ftp.irisa.fr/techreports/theses/2005/leguen.pdf</ref> यह दृष्टिकोण सांख्यिकीय रूप से परीक्षण | उपयोग/सांख्यिकीय मॉडल-आधारित परीक्षण उन तथ्यों से शुरू होता है जो किसी सिस्टम का संपूर्ण परीक्षण करना संभव नहीं है और विफलता बहुत कम दर के साथ सामने आ सकती है।<ref>Helene Le Guen. Validation d'un logiciel par le test statistique d'usage : de la modelisation de la decision à la livraison, 2005. URL:ftp://ftp.irisa.fr/techreports/theses/2005/leguen.pdf</ref> यह दृष्टिकोण सांख्यिकीय रूप से परीक्षण स्थितियों को प्राप्त करने का व्यावहारिक तरीका प्रदान करता है जो परीक्षण के अनुसार सिस्टम की विश्वसनीयता में सुधार करने पर केंद्रित है। उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण को हाल ही में एम्बेडेड सॉफ़्टवेयर सिस्टम पर लागू करने के लिए विस्तारित किया गया था।<ref>{{Cite book | doi=10.1109/ICSTW.2011.11| chapter=Model Based Statistical Testing of Embedded Systems| title=2011 IEEE Fourth International Conference on Software Testing, Verification and Validation Workshops| pages=18–25| year=2011| last1=Böhr| first1=Frank| isbn=978-1-4577-0019-4| s2cid=9582606}}</ref><ref>{{cite book |isbn=978-3843903486|title=Model-Based Statistical Testing of Embedded Real-Time Software with Continuous and Discrete Signals in a Concurrent Environment: The Usage Net Approach |last1=Böhr |first1=Frank |year=2012 }}</ref> | ||
Revision as of 08:39, 18 July 2023
मॉडल-आधारित परीक्षण सॉफ्टवेयर परीक्षण या सिस्टम परीक्षण करने के लिए कलाकृतियों को डिजाइन करने और वैकल्पिक रूप से निष्पादित करने के लिए मॉडल-आधारित डिज़ाइन का एक अनुप्रयोग है। मॉडल का उपयोग परीक्षण (एसयूटी) के अनुसार सिस्टम के वांछित व्यवहार का प्रतिनिधित्व करने के लिए, या परीक्षण रणनीतियों और परीक्षण वातावरण का प्रतिनिधित्व करने के लिए किया जा सकता है। दाईं ओर का चित्र पूर्व दृष्टिकोण को दर्शाता है।
एसयूटी का वर्णन करने वाला मॉडल सामान्यतः एसयूटी के वांछित व्यवहार की अमूर्त, आंशिक प्रस्तुति है।
ऐसे मॉडल से प्राप्त परीक्षण स्थितियां मॉडल के समान अमूर्त स्तर पर कार्यात्मक परीक्षण होते हैं।
इन परीक्षण स्थितियों को सामूहिक रूप से अमूर्त परीक्षण सूट के रूप में जाना जाता है।
अमूर्त परीक्षण सूट को सीधे एसयूटी के विरुद्ध निष्पादित नहीं किया जा सकता क्योंकि सूट अमूर्तता के गलत स्तर पर है।
निष्पादन योग्य परीक्षण सूट को संबंधित सार परीक्षण सूट से प्राप्त करने की आवश्यकता है।
निष्पादन योग्य परीक्षण सूट परीक्षण के अनुसार सिस्टम के साथ सीधे संचार कर सकता है।
यह निष्पादन के लिए उपयुक्त अमूर्त परीक्षण स्थितियों को ठोस परीक्षण स्थितियों में मैप करके प्राप्त किया जाता है।
कुछ मॉडल-आधारित परीक्षण परिवेशों में, मॉडल में सीधे निष्पादन योग्य परीक्षण सूट उत्पन्न करने के लिए पर्याप्त जानकारी होती है।
दूसरों में, ठोस परीक्षण सूट बनाने के लिए अमूर्त परीक्षण सूट के तत्वों को सॉफ़्टवेयर परीक्षण विशिष्ट कथनों या विधि कॉलों पर मैप किया जाना चाहिए। इसे मैपिंग समस्या का समाधान कहा जाता है।[1]
ऑनलाइन परीक्षण (नीचे देखें) के स्थितियां में, अमूर्त परीक्षण सूट केवल वैचारिक रूप से उपस्थित हैं, किन्तु स्पष्ट कलाकृतियों के रूप में नहीं हैं।
परीक्षण विभिन्न प्रणालियों से मॉडल से प्राप्त किए जा सकते हैं। क्योंकि परीक्षण सामान्यतः प्रायोगिक होता है और अनुमान पर आधारित होता है, इसलिए परीक्षण व्युत्पत्ति के लिए कोई एक सर्वोत्तम प्रणाली ज्ञात नहीं है।
सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को एक पैकेज में समेकित करना सामान्य बात है जिसे अधिकांश "परीक्षण आवश्यकताएं", "परीक्षण उद्देश्य" या यहां तक कि "उपयोग स्थितियां" के रूप में जाना जाता है।
इस पैकेज में मॉडल के उन हिस्सों के बारे में जानकारी हो सकती है जिन पर ध्यान केंद्रित किया जाना चाहिए, या परीक्षण समाप्त करने की शर्तों (परीक्षण रोकने के मानदंड) के बारे में जानकारी हो सकती है।
क्योंकि परीक्षण सूट मॉडल से प्राप्त होते हैं न कि स्रोत कोड से, मॉडल-आधारित परीक्षण को सामान्यतः ब्लैक-बॉक्स परीक्षण के रूप के रूप में देखा जाता है।
जटिल सॉफ्टवेयर सिस्टम के लिए मॉडल-आधारित परीक्षण अभी भी विकसित क्षेत्र है।
मॉडल
विशेष रूप से मॉडल संचालित इंजीनियरिंग में या लक्ष्य प्रबंधन समूह (ऑब्जेक्ट मैनेजमेंट ग्रुप) के मॉडल-संचालित वास्तुकला में, मॉडल संबंधित SysML से पहले या समानांतर में बनाए जाते हैं। मॉडल का निर्माण पूर्ण सिस्टम से भी किया जा सकता है। परीक्षण पीढ़ी के लिए विशिष्ट मॉडलिंग भाषाओं में एकीकृत मॉडलिंग भाषा, एसआईएसएमएल, मुख्यधारा प्रोग्रामिंग भाषाएं, परिमित मशीन नोटेशन और गणितीय औपचारिकताएं जैसे Z अंकन, बी-विधि (बी-मेथड | इवेंट-बी), मिश्र धातु (विनिर्देश भाषा) या कॉक शामिल हैं।
मॉडल-आधारित परीक्षण तैनात करना
मॉडल-आधारित परीक्षण को तैनात करने के विभिन्न ज्ञात तरीके हैं, जिनमें ऑनलाइन परीक्षण, निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी और मैन्युअल रूप से तैनाती योग्य परीक्षणों की ऑफ़लाइन पीढ़ी शामिल है।[2]
ऑनलाइन परीक्षण का मतलब है कि मॉडल-आधारित परीक्षण उपकरण सीधे एसयूटी से जुड़ता है और इसे गतिशील रूप से परीक्षण करता है।
निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण स्थितियों को कंप्यूटर-पठनीय संपत्तियों के रूप में उत्पन्न करता है जिन्हें बाद में स्वचालित रूप से चलाया जा सकता है; उदाहरण के लिए, पायथन (प्रोग्रामिंग भाषा) कक्षाओं का संग्रह जो उत्पन्न परीक्षण तर्क का प्रतीक है।
मैन्युअल रूप से परिनियोजन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी का मतलब है कि मॉडल-आधारित परीक्षण उपकरण परीक्षण स्थितियों को मानव-पठनीय संपत्तियों के रूप में उत्पन्न करता है जो बाद में मैन्युअल परीक्षण में सहायता कर सकते हैं; उदाहरण के लिए, मानव भाषा में पीडीएफ दस्तावेज़ जो उत्पन्न परीक्षण चरणों का वर्णन करता है।
एल्गोरिदम के अनुसार परीक्षण प्राप्त करना
मॉडल-आधारित परीक्षण की प्रभावशीलता मुख्य रूप से इसके द्वारा प्रदान की जाने वाली स्वचालन की क्षमता के कारण है। यदि कोई मॉडल मशीन-पठनीय है और इस हद तक औपचारिक है कि इसमें अच्छी तरह से परिभाषित व्यवहारिक व्याख्या है, तो परीक्षण स्थितियों को सिद्धांत रूप से यांत्रिक रूप से प्राप्त किया जा सकता है।
परिमित अवस्था मशीनों से
अधिकांश मॉडल को परिमित राज्य ऑटोमेटन या राज्य संक्रमण प्रणाली के रूप में अनुवादित या व्याख्या किया जाता है। यह ऑटोमेटन परीक्षण के अनुसार सिस्टम के संभावित कॉन्फ़िगरेशन का प्रतिनिधित्व करता है। परीक्षण स्थितियों को खोजने के लिए, निष्पादन योग्य पथों के लिए ऑटोमेटन की खोज की जाती है। संभावित निष्पादन पथ परीक्षण स्थितियां के रूप में काम कर सकता है। यह विधि तब काम करती है जब मॉडल नियतात्मक प्रणाली (गणित) है या इसे नियतात्मक प्रणाली में बदला जा सकता है। इन मॉडलों में अनिर्दिष्ट बदलावों का लाभ उठाकर मूल्यवान ऑफ-नोमिनल परीक्षण स्थितियां प्राप्त किए जा सकते हैं।
परीक्षण के अनुसार सिस्टम की जटिलता और संबंधित मॉडल के आधार पर पथों की संख्या बहुत बड़ी हो सकती है, क्योंकि सिस्टम के संभावित कॉन्फ़िगरेशन की बड़ी मात्रा होती है। ऐसे परीक्षण स्थितियों को खोजने के लिए जो उचित, किन्तु सीमित, पथों की संख्या को कवर कर सकते हैं, चयन को निर्देशित करने के लिए परीक्षण मानदंड की आवश्यकता होती है। इस तकनीक को सबसे पहले ऑफ़ुट और अब्दुरज़िक द्वारा उस पेपर में प्रस्तावित किया गया था जिसने मॉडल-आधारित परीक्षण शुरू किया था।[3] टेस्ट केस जेनरेशन के लिए कई तकनीकें विकसित की गई हैं और रशबी द्वारा उनका सर्वेक्षण किया गया है।[4] परीक्षण मानदंड को परीक्षण पाठ्यपुस्तक में सामान्य ग्राफ़ के संदर्भ में वर्णित किया गया है।[1]
प्रमेय सिद्ध करना
प्रमेय सिद्ध करना मूल रूप से तार्किक सूत्रों को स्वचालित रूप से सिद्ध करने के लिए उपयोग किया गया था। मॉडल-आधारित परीक्षण दृष्टिकोण के लिए, सिस्टम को सिस्टम के व्यवहार को निर्दिष्ट करते हुए, विधेय (तर्क)तर्क) के सेट द्वारा मॉडल किया जाता है।[5] परीक्षण स्थितियों को प्राप्त करने के लिए, मॉडल को परीक्षण के अनुसार प्रणाली का वर्णन करने वाले विधेय के सेट की वैध व्याख्या पर समतुल्य वर्गों में विभाजित किया गया है। प्रत्येक वर्ग निश्चित सिस्टम व्यवहार का वर्णन करता है, और इसलिए, परीक्षण स्थितियां के रूप में काम कर सकता है। सबसे सरल विभाजन विघटनकारी सामान्य रूप दृष्टिकोण के साथ है जिसमें सिस्टम के व्यवहार का वर्णन करने वाली तार्किक अभिव्यक्तियाँ विघटनकारी सामान्य रूप में बदल जाती हैं।
बाधा तर्क प्रोग्रामिंग और प्रतीकात्मक निष्पादन
बाधा प्रोग्रामिंग का उपयोग चर के सेट पर बाधाओं के सेट को हल करके विशिष्ट बाधाओं को संतुष्ट करने वाले परीक्षण स्थितियों का चयन करने के लिए किया जा सकता है। सिस्टम का वर्णन बाधाओं के माध्यम से किया गया है।[6] बाधाओं के सेट को हल करना बूलियन सॉल्वरों (उदाहरण के लिए बूलियन संतुष्टि समस्या पर आधारित एसएटी-सॉल्वर्स) या गॉसियन उन्मूलन जैसे संख्यात्मक विश्लेषण द्वारा किया जा सकता है। बाधाओं के सूत्रों के सेट को हल करके पाया गया समाधान संबंधित प्रणाली के लिए परीक्षण स्थितियों के रूप में काम कर सकता है।
बाधा प्रोग्रामिंग को प्रतीकात्मक निष्पादन के साथ जोड़ा जा सकता है। इस दृष्टिकोण में सिस्टम मॉडल को प्रतीकात्मक रूप से निष्पादित किया जाता है, यानी विभिन्न नियंत्रण पथों पर डेटा बाधाओं को एकत्रित करना, और फिर बाधाओं को हल करने और परीक्षण स्थितियों का उत्पादन करने के लिए बाधा प्रोग्रामिंग विधि का उपयोग करना।[7]
मॉडल जाँच
मॉडल जांच का उपयोग टेस्ट केस जेनरेशन के लिए भी किया जा सकता है।[8] मूल रूप से मॉडल चेकिंग को यह जांचने की तकनीक के रूप में विकसित किया गया था कि किसी मॉडल में किसी विनिर्देश की संपत्ति मान्य है या नहीं। जब परीक्षण के लिए उपयोग किया जाता है, तो परीक्षण के अनुसार सिस्टम का मॉडल और परीक्षण के लिए संपत्ति मॉडल चेकर को प्रदान की जाती है। प्रूफिंग की प्रक्रिया के भीतर, यदि यह संपत्ति मॉडल में मान्य है, तो मॉडल चेकर गवाहों और प्रति-उदाहरणों का पता लगाता है। गवाह ऐसा मार्ग है जहां संपत्ति संतुष्ट होती है, जबकि प्रति-उदाहरण मॉडल के निष्पादन में पथ है जहां संपत्ति का उल्लंघन होता है। इन पथों को फिर से परीक्षण स्थितियों के रूप में उपयोग किया जा सकता है।
मार्कोव श्रृंखला परीक्षण मॉडल का उपयोग करके केस निर्माण का परीक्षण करें
मार्कोव श्रृंखला मॉडल-आधारित परीक्षण को संभालने का कुशल तरीका है। मार्कोव श्रृंखलाओं के साथ साकार किए गए परीक्षण मॉडल को उपयोग मॉडल के रूप में समझा जा सकता है: इसे उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण के रूप में जाना जाता है। उपयोग मॉडल, इसलिए मार्कोव श्रृंखलाएं, मुख्य रूप से 2 कलाकृतियों से निर्मित होती हैं: परिमित राज्य मशीन (एफएसएम) जो परीक्षण किए गए सिस्टम के सभी संभावित उपयोग परिदृश्यों का प्रतिनिधित्व करती है और ऑपरेशनल प्रोफाइल (ओपी) जो एफएसएम को यह दर्शाने के लिए योग्य बनाती है कि सिस्टम कैसा है या होगा सांख्यिकीय रूप से उपयोग किया जाए। पहला (एफएसएम) यह जानने में मदद करता है कि क्या परीक्षण किया जा सकता है या किया गया है और दूसरा (ओपी) परिचालन परीक्षण स्थितियों को प्राप्त करने में मदद करता है। उपयोग/सांख्यिकीय मॉडल-आधारित परीक्षण उन तथ्यों से शुरू होता है जो किसी सिस्टम का संपूर्ण परीक्षण करना संभव नहीं है और विफलता बहुत कम दर के साथ सामने आ सकती है।[9] यह दृष्टिकोण सांख्यिकीय रूप से परीक्षण स्थितियों को प्राप्त करने का व्यावहारिक तरीका प्रदान करता है जो परीक्षण के अनुसार सिस्टम की विश्वसनीयता में सुधार करने पर केंद्रित है। उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण को हाल ही में एम्बेडेड सॉफ़्टवेयर सिस्टम पर लागू करने के लिए विस्तारित किया गया था।[10][11]
यह भी देखें
- डोमेन-विशिष्ट भाषा (डीएसएल)
- डोमेन-विशिष्ट मॉडलिंग (डीएसएम)
- मॉडल-संचालित वास्तुकला (एमडीए)
- मॉडल-संचालित इंजीनियरिंग (एमडीई)
- वस्तु-उन्मुख विश्लेषण और डिजाइन (ओओएडी)
- समय विभाजन परीक्षण (टीपीटी)
संदर्भ
- ↑ 1.0 1.1 Paul Ammann and Jeff Offutt. Introduction to Software Testing, 2nd edition. Cambridge University Press, 2016.
- ↑ Practical Model-Based Testing: A Tools Approach Archived 2012-08-25 at the Wayback Machine, Mark Utting and Bruno Legeard, ISBN 978-0-12-372501-1, Morgan-Kaufmann 2007
- ↑ Jeff Offutt and Aynur Abdurazik. Generating Tests from UML Specifications. Second International Conference on the Unified Modeling Language (UML ’99), pages 416-429, Fort Collins, CO, October 1999.
- ↑ John Rushby. Automated Test Generation and Verified Software. Verified Software: Theories, Tools, Experiments: First IFIP TC 2/WG 2.3 Conference, VSTTE 2005, Zurich, Switzerland, October 10–13. pp. 161-172, Springer-Verlag
- ↑ Brucker, Achim D.; Wolff, Burkhart (2012). "प्रमेय नीति-आधारित परीक्षण पर". Formal Aspects of Computing. 25 (5): 683–721. CiteSeerX 10.1.1.208.3135. doi:10.1007/s00165-012-0222-y. S2CID 5774837.
- ↑ Jefferson Offutt. Constraint-Based Automatic Test Data Generation. IEEE Transactions on Software Engineering, 17:900-910, 1991
- ↑ Antti Huima. Implementing Conformiq Qtronic. Testing of Software and Communicating Systems, Lecture Notes in Computer Science, 2007, Volume 4581/2007, 1-12, DOI: 10.1007/978-3-540-73066-8_1
- ↑ Gordon Fraser, Franz Wotawa, and Paul E. Ammann. Testing with model checkers: a survey. Software Testing, Verification and Reliability, 19(3):215–261, 2009. URL: [1]
- ↑ Helene Le Guen. Validation d'un logiciel par le test statistique d'usage : de la modelisation de la decision à la livraison, 2005. URL:ftp://ftp.irisa.fr/techreports/theses/2005/leguen.pdf
- ↑ Böhr, Frank (2011). "Model Based Statistical Testing of Embedded Systems". 2011 IEEE Fourth International Conference on Software Testing, Verification and Validation Workshops. pp. 18–25. doi:10.1109/ICSTW.2011.11. ISBN 978-1-4577-0019-4. S2CID 9582606.
- ↑ Böhr, Frank (2012). Model-Based Statistical Testing of Embedded Real-Time Software with Continuous and Discrete Signals in a Concurrent Environment: The Usage Net Approach. ISBN 978-3843903486.
अग्रिम पठन
- OMG UML 2 Testing Profile; [2]
- Bringmann, E.; Krämer, A. (2008). "2008 International Conference on Software Testing, Verification, and Validation". 2008 International Conference on Software Testing, Verification, and Validation. International Conference on Software Testing, Verification, and Validation (ICST). pp. 485–493. doi:10.1109/ICST.2008.45. ISBN 978-0-7695-3127-4.
- 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.
- Hong Zhu; et al. (2008). AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test. ACM Press. ISBN 978-1-60558-030-2.
- Santos-Neto, P.; Resende, R.; Pádua, C. (2007). "Proceedings of the 2007 ACM symposium on Applied computing - SAC '07". Proceedings of the 2007 ACM symposium on Applied computing - SAC '07. Symposium on Applied Computing. pp. 1409–1415. doi:10.1145/1244002.1244306. ISBN 978-1-59593-480-2.
- Roodenrijs, E. (Spring 2010). "Model-Based Testing Adds Value". Methods & Tools. 18 (1): 33–39. ISSN 1661-402X.
- A Systematic Review of Model Based Testing Tool Support, Muhammad Shafique, Yvan Labiche, Carleton University, Technical Report, May 2010.
- Zander, Justyna; Schieferdecker, Ina; Mosterman, Pieter J., eds. (2011). Model-Based Testing for Embedded Systems. Computational Analysis, Synthesis, and Design of Dynamic Systems. Vol. 13. Boca Raton: CRC Press. ISBN 978-1-4398-1845-9.
- 2011/2012 Model-based Testing User Survey: Results and Analysis. Robert V. Binder. System Verification Associates, February 2012
