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

Latest revision as of 12:27, 28 July 2023

सामान्य मॉडल-आधारित परीक्षण सेटिंग

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

एसयूटी का वर्णन करने वाला मॉडल सामान्यतः एसयूटी के वांछित व्यवहार की अमूर्त, आंशिक प्रस्तुति है।

ऐसे मॉडल से प्राप्त परीक्षण स्थितियां मॉडल के समान अमूर्त स्तर पर कार्यात्मक परीक्षण होते हैं।

इन परीक्षण स्थितियों को सामूहिक रूप से अमूर्त परीक्षण सूट के रूप में जाना जाता है।

अमूर्त परीक्षण सूट को सीधे एसयूटी के विरुद्ध निष्पादित नहीं किया जा सकता क्योंकि सूट अमूर्तता के गलत स्तर पर है।

निष्पादन योग्य परीक्षण सूट को संबंधित सार परीक्षण सूट से प्राप्त करने की आवश्यकता है।

निष्पादन योग्य परीक्षण सूट परीक्षण के अनुसार सिस्टम के साथ सीधे संचार कर सकता है।

यह निष्पादन के लिए उपयुक्त अमूर्त परीक्षण स्थितियों को ठोस परीक्षण स्थितियों में मैप करके प्राप्त किया जाता है।

कुछ मॉडल-आधारित परीक्षण परिवेशों में, मॉडल में सीधे निष्पादन योग्य परीक्षण सूट उत्पन्न करने के लिए पर्याप्त जानकारी होती है।

दूसरों में, ठोस परीक्षण सूट बनाने के लिए अमूर्त परीक्षण सूट के तत्वों को सॉफ़्टवेयर परीक्षण विशिष्ट कथनों या विधि कॉलों पर मैप किया जाना चाहिए। इसे मैपिंग समस्या का समाधान कहा जाता है।^[1]

ऑनलाइन परीक्षण (नीचे देखें) के स्थितियां में, अमूर्त परीक्षण सूट केवल वैचारिक रूप से उपस्थित हैं, किन्तु स्पष्ट कलाकृतियों के रूप में नहीं हैं।

परीक्षण विभिन्न प्रणालियों से मॉडल से प्राप्त किए जा सकते हैं। क्योंकि परीक्षण सामान्यतः प्रायोगिक होता है और अनुमान पर आधारित होता है, इसलिए परीक्षण व्युत्पत्ति के लिए कोई एक सर्वोत्तम प्रणाली ज्ञात नहीं है।

सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को एक पैकेज में समेकित करना सामान्य बात है जिसे अधिकांश "परीक्षण आवश्यकताएं", "परीक्षण उद्देश्य" या यहां तक कि "उपयोग स्थितियां" के रूप में जाना जाता है।

इस पैकेज में मॉडल के उन हिस्सों के बारे में जानकारी हो सकती है जिन पर ध्यान केंद्रित किया जाना चाहिए, या परीक्षण समाप्त करने की शर्तों (परीक्षण रोकने के मानदंड) के बारे में जानकारी हो सकती है।

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

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

मॉडल

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

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

File:Mbt-process-example.png

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

मॉडल-आधारित परीक्षण को नियुक्त करने के विभिन्न ज्ञात विधियां हैं, जिनमें ऑनलाइन परीक्षण, निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी और मैन्युअल रूप से तैनाती योग्य परीक्षणों की ऑफ़लाइन पीढ़ी सम्मिलित है।^[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

[Jeff_Offutt_2016-1] 1.0 ^1.1 Paul Ammann and Jeff Offutt. Introduction to Software Testing, 2nd edition. Cambridge University Press, 2016.

[pmbt-2] 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

[3] 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.

[4] 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

[otbt-5] 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.

[6] Jefferson Offutt. Constraint-Based Automatic Test Data Generation. IEEE Transactions on Software Engineering, 17:900-910, 1991

[7] 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

[8] 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]

[9] 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

[10] 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.

[11] 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.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

@@ Line 1: / Line 1: @@
-[[File:Mbt-overview.png|frame|सामान्य मॉडल-आधारित परीक्षण सेटिंग]]मॉडल-आधारित परीक्षण सॉफ्टवेयर परीक्षण या [[सिस्टम परीक्षण]] करने के लिए कलाकृतियों को डिजाइन करने और वैकल्पिक रूप से निष्पादित करने के लिए [[मॉडल-आधारित डिज़ाइन]] का एक अनुप्रयोग है। मॉडल का उपयोग परीक्षण (एसयूटी) के तहत सिस्टम के वांछित व्यवहार का प्रतिनिधित्व करने के लिए, या परीक्षण रणनीतियों और परीक्षण वातावरण का प्रतिनिधित्व करने के लिए किया जा सकता है। दाईं ओर का चित्र पूर्व दृष्टिकोण को दर्शाता है।
+[[File:Mbt-overview.png|frame|सामान्य मॉडल-आधारित परीक्षण सेटिंग]]'''मॉडल-आधारित परीक्षण''' सॉफ्टवेयर परीक्षण या [[सिस्टम परीक्षण]] करने के लिए कलाकृतियों को डिजाइन करने और वैकल्पिक रूप से निष्पादित करने के लिए [[मॉडल-आधारित डिज़ाइन]] का एक अनुप्रयोग है। मॉडल का उपयोग परीक्षण (एसयूटी) के अनुसार सिस्टम के वांछित व्यवहार का प्रतिनिधित्व करने के लिए, या परीक्षण रणनीतियों और परीक्षण वातावरण का प्रतिनिधित्व करने के लिए किया जा सकता है। दाईं ओर का चित्र पूर्व दृष्टिकोण को दर्शाता है।
+एसयूटी का वर्णन करने वाला मॉडल सामान्यतः एसयूटी के वांछित व्यवहार की अमूर्त, आंशिक प्रस्तुति है।
+ऐसे मॉडल से प्राप्त परीक्षण स्थितियां मॉडल के समान अमूर्त स्तर पर कार्यात्मक परीक्षण होते हैं।
+इन परीक्षण स्थितियों को सामूहिक रूप से अमूर्त परीक्षण सूट के रूप में जाना जाता है।
+अमूर्त परीक्षण सूट को सीधे एसयूटी के विरुद्ध निष्पादित नहीं किया जा सकता क्योंकि सूट अमूर्तता के गलत स्तर पर है।
+[[निष्पादन योग्य परीक्षण सूट]] को संबंधित सार परीक्षण सूट से प्राप्त करने की आवश्यकता है।
+निष्पादन योग्य परीक्षण सूट परीक्षण के अनुसार सिस्टम के साथ सीधे संचार कर सकता है।
+यह निष्पादन के लिए उपयुक्त अमूर्त परीक्षण स्थितियों को ठोस परीक्षण स्थितियों में मैप करके प्राप्त किया जाता है।
+कुछ मॉडल-आधारित परीक्षण परिवेशों में, मॉडल में सीधे निष्पादन योग्य परीक्षण सूट उत्पन्न करने के लिए पर्याप्त जानकारी होती है।
-एसयूटी का वर्णन करने वाला एक मॉडल आमतौर पर एसयूटी के वांछित व्यवहार की एक अमूर्त, आंशिक प्रस्तुति है।
-ऐसे मॉडल से प्राप्त परीक्षण मामले मॉडल के समान अमूर्त स्तर पर कार्यात्मक परीक्षण होते हैं।
-इन परीक्षण मामलों को सामूहिक रूप से एक अमूर्त परीक्षण सूट के रूप में जाना जाता है।
-एक अमूर्त परीक्षण सूट को सीधे SUT के विरुद्ध निष्पादित नहीं किया जा सकता क्योंकि सूट अमूर्तता के गलत स्तर पर है।
-एक [[निष्पादन योग्य परीक्षण सूट]] को संबंधित सार परीक्षण सूट से प्राप्त करने की आवश्यकता है।
-निष्पादन योग्य परीक्षण सूट परीक्षण के तहत सिस्टम के साथ सीधे संचार कर सकता है।
-यह अमूर्त परीक्षण मामलों को मैप करके प्राप्त किया जाता है
-निष्पादन के लिए उपयुक्त ठोस परीक्षण मामले। कुछ मॉडल-आधारित परीक्षण परिवेशों में, मॉडल में सीधे निष्पादन योग्य परीक्षण सूट उत्पन्न करने के लिए पर्याप्त जानकारी होती है।
 दूसरों में, ठोस परीक्षण सूट बनाने के लिए अमूर्त परीक्षण सूट के तत्वों को [[सॉफ़्टवेयर परीक्षण]] विशिष्ट कथनों या विधि कॉलों पर मैप किया जाना चाहिए। इसे मैपिंग समस्या का समाधान कहा जाता है।<ref name="Jeff Offutt 2016">Paul Ammann and Jeff Offutt. Introduction to Software Testing, 2nd edition. Cambridge University Press, 2016.</ref>
-ऑनलाइन परीक्षण (नीचे देखें) के मामले में, अमूर्त परीक्षण सूट केवल वैचारिक रूप से मौजूद हैं, लेकिन स्पष्ट कलाकृतियों के रूप में नहीं।
-परीक्षण विभिन्न तरीकों से मॉडल से प्राप्त किए जा सकते हैं। क्योंकि परीक्षण आमतौर पर प्रायोगिक होता है और अनुमान पर आधारित होता है,
+ऑनलाइन परीक्षण (नीचे देखें) के स्थितियां में, अमूर्त परीक्षण सूट केवल वैचारिक रूप से उपस्थित हैं, किन्तु स्पष्ट कलाकृतियों के रूप में नहीं हैं।
-परीक्षण व्युत्पत्ति के लिए कोई एक सर्वोत्तम तरीका ज्ञात नहीं है।
-सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को एक में समेकित करना आम बात है
+परीक्षण विभिन्न प्रणालियों से मॉडल से प्राप्त किए जा सकते हैं। क्योंकि परीक्षण सामान्यतः प्रायोगिक होता है और अनुमान पर आधारित होता है, इसलिए परीक्षण व्युत्पत्ति के लिए कोई एक सर्वोत्तम प्रणाली ज्ञात नहीं है।
-पैकेज जिसे अक्सर परीक्षण आवश्यकताओं, परीक्षण उद्देश्य या यहां तक कि उपयोग के मामलों के रूप में जाना जाता है।
+सभी परीक्षण व्युत्पत्ति संबंधी मापदंडों को एक पैकेज में समेकित करना सामान्य बात है जिसे अधिकांश "परीक्षण आवश्यकताएं", "परीक्षण उद्देश्य" या यहां तक कि "उपयोग स्थितियां" के रूप में जाना जाता है।
 इस पैकेज में मॉडल के उन हिस्सों के बारे में जानकारी हो सकती है जिन पर ध्यान केंद्रित किया जाना चाहिए, या परीक्षण समाप्त करने की शर्तों (परीक्षण रोकने के मानदंड) के बारे में जानकारी हो सकती है।
-क्योंकि परीक्षण सूट मॉडल से प्राप्त होते हैं न कि स्रोत कोड से, मॉडल-आधारित परीक्षण को आमतौर पर [[ब्लैक-बॉक्स परीक्षण]] के एक रूप के रूप में देखा जाता है।
+क्योंकि परीक्षण सूट मॉडल से प्राप्त होते हैं न कि स्रोत कोड से, मॉडल-आधारित परीक्षण को सामान्यतः [[ब्लैक-बॉक्स परीक्षण]] के रूप के रूप में देखा जाता है।
-जटिल सॉफ्टवेयर सिस्टम के लिए मॉडल-आधारित परीक्षण अभी भी एक विकसित क्षेत्र है।
+जटिल सॉफ्टवेयर सिस्टम के लिए मॉडल-आधारित परीक्षण अभी भी विकसित क्षेत्र है।
 ==मॉडल==
-विशेष रूप से [[मॉडल संचालित इंजीनियरिंग]] में या [[ लक्ष्य प्रबंधन समूह ]] (ऑब्जेक्ट मैनेजमेंट ग्रुप) के [[मॉडल-संचालित वास्तुकला]] में, मॉडल संबंधित [[SysML]] से पहले या समानांतर में बनाए जाते हैं। मॉडल का निर्माण पूर्ण सिस्टम से भी किया जा सकता है। परीक्षण पीढ़ी के लिए विशिष्ट मॉडलिंग भाषाओं में [[एकीकृत मॉडलिंग भाषा]], एसआईएसएमएल, मुख्यधारा प्रोग्रामिंग भाषाएं, परिमित मशीन नोटेशन और गणितीय औपचारिकताएं जैसे [[Z अंकन]], [[ बी-विधि ]] (बी-मेथड | इवेंट-बी), [[मिश्र धातु (विनिर्देश भाषा)]] या [[कॉक]] शामिल हैं।
+विशेष रूप से [[मॉडल संचालित इंजीनियरिंग]] में या [[ लक्ष्य प्रबंधन समूह |ऑब्जेक्ट मैनेजमेंट ग्रुप]] (ओएमजी) के [[मॉडल-संचालित वास्तुकला]] में, मॉडल संबंधित [[SysML]] से पहले या समानांतर में बनाए जाते हैं। मॉडल का निर्माण पूर्ण सिस्टम से भी किया जा सकता है। परीक्षण पीढ़ी के लिए विशिष्ट मॉडलिंग भाषाओं में [[एकीकृत मॉडलिंग भाषा]], एसआईएसएमएल, मुख्यधारा प्रोग्रामिंग भाषाएं, परिमित मशीन नोटेशन और गणितीय औपचारिकताएं जैसे [[Z अंकन|जेड अंकन]], [[ बी-विधि |बी-विधि]] (इवेंट-बी), [[मिश्र धातु (विनिर्देश भाषा)]] या [[कॉक]] सम्मिलित हैं।
-==मॉडल-आधारित परीक्षण तैनात करना==
+==मॉडल-आधारित परीक्षण नियुक्त करना==
-[[File:Mbt-process-example.png|right|frame|मॉडल-आधारित परीक्षण वर्कफ़्लो (ऑफ़लाइन परीक्षण केस पीढ़ी) का एक उदाहरण। IXIT अतिरिक्त जानकारी के कार्यान्वयन को संदर्भित करता है और एक अमूर्त परीक्षण सूट को निष्पादन योग्य में बदलने के लिए आवश्यक जानकारी को संदर्भित करता है। आमतौर पर, IXIT में परीक्षण हार्नेस, डेटा मैपिंग और SUT कॉन्फ़िगरेशन की जानकारी होती है।]]मॉडल-आधारित परीक्षण को तैनात करने के विभिन्न ज्ञात तरीके हैं, जिनमें ऑनलाइन परीक्षण, निष्पादन योग्य परीक्षणों की ऑफ़लाइन पीढ़ी और मैन्युअल रूप से तैनाती योग्य परीक्षणों की ऑफ़लाइन पीढ़ी शामिल है।<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>
+[[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>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>Jefferson Offutt. Constraint-Based Automatic Test Data Generation. IEEE Transactions on Software Engineering, 17:900-910, 1991</ref> बाधाओं के सेट का समाधान करना बूलियन सॉल्वरों (उदाहरण के लिए [[बूलियन संतुष्टि समस्या]] पर आधारित एसएटी-सॉल्वर्स) या गॉसियन उन्मूलन जैसे [[संख्यात्मक विश्लेषण]] द्वारा किया जा सकता है। बाधाओं के सूत्रों के सेट का समाधान करके पाया गया समाधान संबंधित प्रणाली के लिए परीक्षण स्थितियों के रूप में काम कर सकता है।
-बाधा प्रोग्रामिंग को प्रतीकात्मक निष्पादन के साथ जोड़ा जा सकता है। इस दृष्टिकोण में एक सिस्टम मॉडल को प्रतीकात्मक रूप से निष्पादित किया जाता है, यानी विभिन्न नियंत्रण पथों पर डेटा बाधाओं को एकत्रित करना, और फिर बाधाओं को हल करने और परीक्षण मामलों का उत्पादन करने के लिए बाधा प्रोग्रामिंग विधि का उपयोग करना।<ref>Antti Huima. Implementing Conformiq Qtronic.
+बाधा प्रोग्रामिंग को प्रतीकात्मक निष्पादन के साथ जोड़ा जा सकता है। इस दृष्टिकोण में सिस्टम मॉडल को प्रतीकात्मक रूप से निष्पादित किया जाता है, अर्थात् विभिन्न नियंत्रण पथों पर डेटा बाधाओं को एकत्रित करना, और फिर बाधाओं का समाधान करने और परीक्षण स्थितियों का उत्पादन करने के लिए बाधा प्रोग्रामिंग विधि का उपयोग करना होता हैं।<ref>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
@@ 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 कलाकृतियों से निर्मित होती हैं: परिमित राज्य मशीन (एफएसएम) जो परीक्षण किए गए सिस्टम के सभी संभावित उपयोग परिदृश्यों का प्रतिनिधित्व करती है और ऑपरेशनल प्रोफाइल (ओपी) जो एफएसएम को यह दर्शाने के लिए योग्य बनाती है कि सिस्टम कैसा है या होगा सांख्यिकीय रूप से उपयोग किया जाए। पहला (एफएसएम) यह जानने में मदद करता है कि क्या परीक्षण किया जा सकता है या किया गया है और दूसरा (ओपी) परिचालन परीक्षण मामलों को प्राप्त करने में मदद करता है।
-उपयोग/सांख्यिकीय मॉडल-आधारित परीक्षण उन तथ्यों से शुरू होता है जो किसी सिस्टम का संपूर्ण परीक्षण करना संभव नहीं है और विफलता बहुत कम दर के साथ सामने आ सकती है।<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>
+मार्कोव श्रृंखला मॉडल-आधारित परीक्षण को संभालने का कुशल विधि है। मार्कोव श्रृंखलाओं के साथ साकार किए गए परीक्षण मॉडल को उपयोग मॉडल के रूप में समझा जा सकता है: इसे उपयोग/सांख्यिकीय मॉडल आधारित परीक्षण के रूप में जाना जाता है। उपयोग मॉडल, इसलिए मार्कोव श्रृंखलाएं, मुख्य रूप से 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>{{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>
@@ Line 100: / Line 113: @@
 {{Software testing}}
-{{DEFAULTSORT:Model-Based Testing}}[[Category: सॉफ़्टवेयर परीक्षण]]
+{{DEFAULTSORT:Model-Based Testing}}
-[[Category: Machine Translated Page]]
+[[Category:Collapse templates|Model-Based Testing]]
-[[Category:Created On 10/07/2023]]
+[[Category:Created On 10/07/2023|Model-Based Testing]]
+[[Category:Machine Translated Page|Model-Based Testing]]
+[[Category:Navigational boxes| ]]
+[[Category:Navigational boxes without horizontal lists|Model-Based Testing]]
+[[Category:Pages with broken file links|Model-Based Testing]]
+[[Category:Pages with script errors|Model-Based Testing]]
+[[Category:Sidebars with styles needing conversion|Model-Based Testing]]
+[[Category:Template documentation pages|Documentation/doc]]
+[[Category:Templates Vigyan Ready|Model-Based Testing]]
+[[Category:Templates generating microformats|Model-Based Testing]]
+[[Category:Templates that are not mobile friendly|Model-Based Testing]]
+[[Category:Templates using TemplateData|Model-Based Testing]]
+[[Category:Webarchive template wayback links]]
+[[Category:Wikipedia metatemplates|Model-Based Testing]]
+[[Category:सॉफ़्टवेयर परीक्षण|Model-Based Testing]]

v t e Software testing
The "box" approach	Black-box testing All-pairs testing Exploratory testing Fuzz testing Model-based testing Scenario testing Grey-box testing White-box testing API testing Mutation testing Static testing
Testing levels	Acceptance testing Integration testing System testing Unit testing
Testing types, techniques, and tactics	A/B testing Benchmark Compatibility testing Concolic testing Concurrent testing Conformance testing Continuous testing Destructive testing Development testing Dynamic program analysis Installation testing Regression testing Security testing Smoke testing (software) Software performance testing Symbolic execution Test automation Usability testing
See also	Graphical user interface testing Manual testing Orthogonal array testing Pair testing Soak testing Software reliability testing Stress testing Web testing

Anonymous

Search

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

Namespaces

More

Page actions

Latest revision as of 12:27, 28 July 2023

Contents

मॉडल

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

एल्गोरिदम के अनुसार परीक्षण प्राप्त करना

परिमित अवस्था मशीनों से

प्रमेय सिद्ध करना

बाधा तर्क प्रोग्रामिंग और प्रतीकात्मक निष्पादन

मॉडल जाँच

मार्कोव श्रृंखला परीक्षण मॉडल का उपयोग करके केस निर्माण का परीक्षण करें

यह भी देखें

संदर्भ

अग्रिम पठन

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

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

Latest revision as of 12:27, 28 July 2023

मॉडल

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

एल्गोरिदम के अनुसार परीक्षण प्राप्त करना

परिमित अवस्था मशीनों से

प्रमेय सिद्ध करना

बाधा तर्क प्रोग्रामिंग और प्रतीकात्मक निष्पादन

मॉडल जाँच

मार्कोव श्रृंखला परीक्षण मॉडल का उपयोग करके केस निर्माण का परीक्षण करें

यह भी देखें

संदर्भ

अग्रिम पठन

Navigation

Wiki tools

Page tools

Other projects

Categories