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

From Vigyanwiki
Revision as of 11:29, 10 July 2023 by alpha>Indicwiki (Created page with "frame|सामान्य मॉडल-आधारित परीक्षण सेटिंगमॉडल-आधारित परीक्...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
सामान्य मॉडल-आधारित परीक्षण सेटिंग

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

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

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

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

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

मॉडल

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

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

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

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

ऑनलाइन परीक्षण का मतलब है कि एक मॉडल-आधारित परीक्षण उपकरण सीधे एक एसयूटी से जुड़ता है और इसे गतिशील रूप से परीक्षण करता है।

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

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

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

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

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

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

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


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

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

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

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

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


मॉडल जाँच

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

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

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


यह भी देखें

संदर्भ

  1. 1.0 1.1 Paul Ammann and Jeff Offutt. Introduction to Software Testing, 2nd edition. Cambridge University Press, 2016.
  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
  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.


अग्रिम पठन