परीक्षण स्थिति: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Specification of a software test, its objective and its procedure}} {{about|the term in software engineering|the legal term|Test case (law)|other uses|Test...")
 
No edit summary
Line 1: Line 1:
{{Short description|Specification of a software test, its objective and its procedure}}
{{Short description|Specification of a software test, its objective and its procedure}}
{{about|the term in software engineering|the legal term|Test case (law)|other uses|Test case (disambiguation)}}
{{about|सॉफ्टवेयर इंजीनियरिंग के शब्द में|वैधानिक शब्द|परीक्षण स्थिति (नियम)|अन्य उपयोग|परीक्षण स्थिति (बहुविकल्पीय)}}


सॉफ्टवेयर इंजीनियरिंग में, एक परीक्षण मामला इनपुट, निष्पादन की स्थिति, परीक्षण प्रक्रिया और अपेक्षित परिणाम का एक विनिर्देश है जो एक विशेष सॉफ्टवेयर परीक्षण उद्देश्य को प्राप्त करने के लिए निष्पादित किए जाने वाले एकल परीक्षण को परिभाषित करता है, जैसे किसी विशेष प्रोग्राम पथ का प्रयोग करना या सत्यापित करना एक विशिष्ट आवश्यकता का अनुपालन।<ref>{{Cite book|date=2010-12-01|title=Systems and software engineering – Vocabulary|journal= Iso/Iec/IEEE 24765:2010(E)|pages=1–418|doi=10.1109/IEEESTD.2010.5733835|isbn=978-0-7381-6205-8}}</ref> परीक्षण के मामले परीक्षण के अंतर्गत आते हैं जो बेतरतीब होने के बजाय व्यवस्थित है। परीक्षण किए जा रहे सॉफ़्टवेयर के वांछित कवरेज का उत्पादन करने के लिए परीक्षण मामलों की एक बैटरी बनाई जा सकती है। औपचारिक रूप से परिभाषित परीक्षण मामले एक ही परीक्षण को सॉफ्टवेयर के क्रमिक संस्करणों के खिलाफ बार-बार चलाने की अनुमति देते हैं, जिससे प्रभावी और सुसंगत [[प्रतिगमन परीक्षण]] की अनुमति मिलती है।<ref>{{Cite journal|last=Kaner|first=Cem|date=May 2003|title=What Is a Good Test Case?|url=http://www.kaner.com/pdfs/GoodTest.pdf|journal=STAR East|pages=2}}</ref>
सॉफ्टवेयर इंजीनियरिंग में, एक परीक्षण स्थिति इनपुट, निष्पादन की स्थिति, परीक्षण प्रक्रिया और अपेक्षित परिणाम का एक विनिर्देश है जो एक विशेष सॉफ्टवेयर परीक्षण उद्देश्य को प्राप्त करने के लिए निष्पादित किए जाने वाले एकल परीक्षण को परिभाषित करता है, जैसे किसी विशेष प्रोग्राम पथ का प्रयोग करना या सत्यापित करना एक विशिष्ट आवश्यकता का अनुपालन करना इत्यादि।<ref>{{Cite book|date=2010-12-01|title=Systems and software engineering – Vocabulary|journal= Iso/Iec/IEEE 24765:2010(E)|pages=1–418|doi=10.1109/IEEESTD.2010.5733835|isbn=978-0-7381-6205-8}}</ref> परीक्षण की स्थिति परीक्षण के अंतर्गत आती हैं, जो बेतरतीब होने के अतिरिक्त व्यवस्थित है। परीक्षण किए जा रहे सॉफ़्टवेयर के वांछित कवरेज का उत्पादन करने के लिए परीक्षण स्थितियों की एक बैटरी बनाई जा सकती है। औपचारिक रूप से परिभाषित परीक्षण स्थिति एक ही परीक्षण को सॉफ्टवेयर के क्रमिक संस्करणों के विरुद्ध समान परीक्षणों को बार-बार चलाने की अनुमति देते हैं, जिससे प्रभावी और सुसंगत प्रतिगमन परीक्षण की अनुमति मिलती है।<ref>{{Cite journal|last=Kaner|first=Cem|date=May 2003|title=What Is a Good Test Case?|url=http://www.kaner.com/pdfs/GoodTest.pdf|journal=STAR East|pages=2}}</ref>




== औपचारिक परीक्षण मामले ==
== औपचारिक परीक्षण स्थिति ==


पूरी तरह से परीक्षण करने के लिए कि एक आवेदन की सभी आवश्यकताओं को पूरा किया गया है, प्रत्येक आवश्यकता के लिए कम से कम दो परीक्षण मामले होने चाहिए: एक सकारात्मक परीक्षण और एक नकारात्मक परीक्षण।<ref>{{Cite web|url=https://www.stickyminds.com/article/writing-test-rules-verify-stakeholder-requirements|title=हितधारक आवश्यकताओं को सत्यापित करने के लिए परीक्षण नियम लिखना|website=StickyMinds}}</ref> यदि किसी आवश्यकता की उप-आवश्यकताएँ हैं, तो प्रत्येक उप-आवश्यकता में कम से कम दो परीक्षण मामले होने चाहिए। आवश्यकता और परीक्षण के बीच की कड़ी का ट्रैक रखना अक्सर [[पता लगाने की क्षमता का मापदंड]] का उपयोग करके किया जाता है। लिखित परीक्षा के मामलों में परीक्षण की जाने वाली कार्यक्षमता का विवरण, और यह सुनिश्चित करने के लिए आवश्यक तैयारी शामिल होनी चाहिए कि परीक्षण आयोजित किया जा सकता है।
पूरी तरह से परीक्षण करने के लिए कि एक अनुप्रयोग की सभी आवश्यकताओं को पूरा किया गया है, प्रत्येक आवश्यकता के लिए कम से कम दो परीक्षण सकारात्मक परीक्षण और एक नकारात्मक परीक्षण स्थिति होनी चाहिए''': एक''' '''सकारात्मक परीक्षण और एक नकारात्मक परीक्षण'''।<ref>{{Cite web|url=https://www.stickyminds.com/article/writing-test-rules-verify-stakeholder-requirements|title=हितधारक आवश्यकताओं को सत्यापित करने के लिए परीक्षण नियम लिखना|website=StickyMinds}}</ref> यदि किसी आवश्यकता की उप-आवश्यकताएँ हैं, तो प्रत्येक उप-आवश्यकता में कम से कम दो परीक्षण स्थिति होनी चाहिए। आवश्यकता और परीक्षण के बीच की कड़ी का ट्रैक रखना अधिकांशतः [[पता लगाने की क्षमता का मापदंड|ट्रेसबिलिटी मैट्रिक्स]] का उपयोग करके किया जाता है। लिखित परीक्षा की स्थितियों में परीक्षण की जाने वाली कार्यक्षमता का विवरण, और यह सुनिश्चित करने के लिए आवश्यक तैयारी सम्मिलित होनी चाहिए कि परीक्षण आयोजित किया जा सकता है।


एक औपचारिक लिखित परीक्षा मामले को एक ज्ञात इनपुट और एक अपेक्षित आउटपुट द्वारा चित्रित किया जाता है, जिसे परीक्षण निष्पादित करने से पहले काम किया जाता है।<ref>{{cite book |last=Beizer |first=Boris |date=May 22, 1995 |title=ब्लैक बॉक्स परीक्षण|url=https://archive.org/details/blackboxtestingt00beiz_0 |url-access=registration |location=New York |publisher=Wiley |page=[https://archive.org/details/blackboxtestingt00beiz_0/page/3 3] |isbn= 9780471120940}}</ref> ज्ञात इनपुट को पूर्व शर्त का परीक्षण करना चाहिए और अपेक्षित आउटपुट को [[[[शर्त लगाना]]]] का परीक्षण करना चाहिए।
एक औपचारिक लिखित परीक्षा स्थिति को एक ज्ञात इनपुट और एक अपेक्षित आउटपुट द्वारा चित्रित किया जाता है, जिसे परीक्षण के निष्पादन से पहले काम किया जाता है।<ref name=":0">{{cite book |last=Beizer |first=Boris |date=May 22, 1995 |title=ब्लैक बॉक्स परीक्षण|url=https://archive.org/details/blackboxtestingt00beiz_0 |url-access=registration |location=New York |publisher=Wiley |page=[https://archive.org/details/blackboxtestingt00beiz_0/page/3 3] |isbn= 9780471120940}}</ref> ज्ञात इनपुट को पूर्व नियम का परीक्षण करना चाहिए और अपेक्षित आउटपुट को [[शर्त लगाना|पोस्टकंडिशन]] का परीक्षण करना चाहिए।


== अनौपचारिक परीक्षण मामले ==
'''एक औपचारिक लिखित परीक्षा स्थिति को एक ज्ञात इनपुट और एक अपेक्षित आउटपुट द्वारा चित्रित किया जाता है, जिसे परीक्षण निष्पादित करने से पहले काम किया जाता है।<ref name=":0" /> ज्ञात इनपुट को पूर्व नियम का परीक्षण करना चाहिए और अपेक्षित आउटपुट को [[[[शर्त लगाना|नियम लगाना]]]] का परीक्षण करना चाहिए।'''


औपचारिक आवश्यकताओं के बिना अनुप्रयोगों या प्रणालियों के लिए, समान वर्ग के कार्यक्रमों के स्वीकृत सामान्य संचालन के आधार पर परीक्षण मामलों को लिखा जा सकता है। परीक्षण के कुछ विद्यालयों में, परीक्षण मामलों को बिल्कुल नहीं लिखा जाता है, लेकिन परीक्षण चलाए जाने के बाद गतिविधियों और परिणामों की सूचना दी जाती है।
== अनौपचारिक परीक्षण स्थिति ==
 
औपचारिक आवश्यकताओं के बिना अनुप्रयोगों या प्रणालियों के लिए, समान वर्ग के कार्यक्रमों के स्वीकृत सामान्य संचालन के आधार पर परीक्षण स्थितियों को लिखा जा सकता है। परीक्षण के कुछ विद्यालयों में, परीक्षण स्थितियों को बिल्कुल नहीं लिखा जाता है, लेकिन परीक्षण चलाए जाने के बाद गतिविधियों और परिणामों की सूचना दी जाती है।
 
[[परिदृश्य परीक्षण]] में, एक जटिल समस्या या प्रणाली के माध्यम से परीक्षक को सोचने में सहायता करने के लिए काल्पनिक कहानियों का उपयोग किया जाता है। इन परिदृश्यों को सामान्यतः किसी भी विवरण में नहीं लिखा जाता है। वे एक परीक्षण वातावरण के लिए आरेख के रूप में सरल हो सकते हैं या वे गद्य में लिखे गए विवरण हो सकते हैं। आदर्श परिदृश्य परीक्षण एक ऐसी कहानी है जो प्रेरक, विश्वसनीय, जटिल और मूल्यांकन करने में सरल है। वे सामान्यतः परीक्षण स्थितियों से भिन्न होते हैं, परीक्षण स्थिति एकल चरण होते हैं जबकि परिदृश्य कुंजी के कई चरणों को कवर करते हैं।<ref name="Kaner-Intro">{{cite web | title = परिदृश्य परीक्षण का एक परिचय| url = http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf | access-date = 2009-05-07 | publisher = Cem Kaner }}</ref><ref name="Crispin-Agile">{{cite book |last= Crispin |first= Lisa |author2=Gregory, Janet  |title= Agile Testing: A Practical Guide for Testers and Agile Teams |url= https://archive.org/details/agiletestingprac00cris |url-access= limited |publisher= [[Addison-Wesley]] |year= 2009 |isbn= 978-81-317-3068-3 |pages=[https://archive.org/details/agiletestingprac00cris/page/n231 192]–5}}</ref>


[[परिदृश्य परीक्षण]] में, एक जटिल समस्या या प्रणाली के माध्यम से परीक्षक को सोचने में मदद करने के लिए काल्पनिक कहानियों का उपयोग किया जाता है। इन परिदृश्यों को आमतौर पर किसी भी विवरण में नहीं लिखा जाता है। वे एक परीक्षण वातावरण के लिए आरेख के रूप में सरल हो सकते हैं या वे गद्य में लिखे गए विवरण हो सकते हैं। आदर्श परिदृश्य परीक्षण एक ऐसी कहानी है जो प्रेरक, विश्वसनीय, जटिल और मूल्यांकन करने में आसान है। वे आमतौर पर परीक्षण मामलों से भिन्न होते हैं, परीक्षण मामले एकल चरण होते हैं जबकि परिदृश्य कुंजी के कई चरणों को कवर करते हैं।<ref name="Kaner-Intro">{{cite web | title = परिदृश्य परीक्षण का एक परिचय| url = http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf | access-date = 2009-05-07 | publisher = Cem Kaner }}</ref><ref name="Crispin-Agile">{{cite book |last= Crispin |first= Lisa |author2=Gregory, Janet  |title= Agile Testing: A Practical Guide for Testers and Agile Teams |url= https://archive.org/details/agiletestingprac00cris |url-access= limited |publisher= [[Addison-Wesley]] |year= 2009 |isbn= 978-81-317-3068-3 |pages=[https://archive.org/details/agiletestingprac00cris/page/n231 192]–5}}</ref>




== विशिष्ट लिखित परीक्षा केस प्रारूप ==
== विशिष्ट लिखित परीक्षा केस प्रारूप ==


किसी एप्लिकेशन के सही व्यवहार/कार्यक्षमता, विशेषताओं का परीक्षण करने के लिए एक परीक्षण मामला आमतौर पर एक चरण या कभी-कभी चरणों का एक क्रम होता है। एक अपेक्षित परिणाम या अपेक्षित परिणाम आमतौर पर दिया जाता है।<ref>https://www.softwaretestingstandard.org/part3.php ''ISO/IEC/IEEE 29119-4:2019'', "Part 4: Test techniques"</ref>
किसी एप्लिकेशन के सही व्यवहार/कार्यक्षमता, विशेषताओं का परीक्षण करने के लिए एक परीक्षण स्थिति सामान्यतः एक चरण या कभी-कभी चरणों का एक क्रम होता है। एक अपेक्षित परिणाम या अपेक्षित परिणाम सामान्यतः दिया जाता है।<ref>https://www.softwaretestingstandard.org/part3.php ''ISO/IEC/IEEE 29119-4:2019'', "Part 4: Test techniques"</ref>
अतिरिक्त जानकारी जो शामिल हो सकती है:<ref name="Liu">{{cite journal |last=Liu |first=Juan |year=2014 |title=जीयूआई पर आधारित सॉफ्टवेयर परीक्षण प्रक्रियाओं का अध्ययन|url=https://books.google.com/books?id=xK0tAwAAQBAJ&pg=PA116 |journal=2014 International Conference on Computer, Network |pages=113–121 |access-date=2019-10-22|isbn=9781605951676 |doi=10.1109/CSCI.2014.104 |s2cid=15204091 }}</ref>
 
अतिरिक्त जानकारी जो सम्मिलित हो सकती है:<ref name="Liu">{{cite journal |last=Liu |first=Juan |year=2014 |title=जीयूआई पर आधारित सॉफ्टवेयर परीक्षण प्रक्रियाओं का अध्ययन|url=https://books.google.com/books?id=xK0tAwAAQBAJ&pg=PA116 |journal=2014 International Conference on Computer, Network |pages=113–121 |access-date=2019-10-22|isbn=9781605951676 |doi=10.1109/CSCI.2014.104 |s2cid=15204091 }}</ref>
*टेस्ट केस आईडी - यह फील्ड विशिष्ट रूप से एक टेस्ट केस की पहचान करता है।
*टेस्ट केस आईडी - यह फील्ड विशिष्ट रूप से एक टेस्ट केस की पहचान करता है।
*टेस्ट केस का विवरण/सारांश - यह फील्ड टेस्ट केस के उद्देश्य का वर्णन करता है।
*टेस्ट केस का विवरण/सारांश - यह फील्ड टेस्ट केस के उद्देश्य का वर्णन करता है।
*टेस्ट स्टेप्स - इस फील्ड में, टेस्ट केस को करने के लिए सटीक स्टेप्स का उल्लेख किया गया है।
*टेस्ट स्टेप्स - इस फील्ड में, टेस्ट केस को करने के लिए सटीक स्टेप्स का उल्लेख किया गया है।
* पूर्वापेक्षाएँ - यह फ़ील्ड उन शर्तों या चरणों को निर्दिष्ट करती है जिनका परीक्षण चरणों के निष्पादन से पहले पालन किया जाना चाहिए।
* पूर्वापेक्षाएँ - यह फ़ील्ड उन नियमों या चरणों को निर्दिष्ट करती है जिनका परीक्षण चरणों के निष्पादन से पहले पालन किया जाना चाहिए।
* टेस्ट श्रेणी
* टेस्ट श्रेणी
*लेखक- परीक्षक का नाम।
*लेखक- परीक्षक का नाम।
Line 32: Line 36:
*टिप्पणियां
*टिप्पणियां


बड़े परीक्षण मामलों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं।<ref name="Liu" />
बड़े परीक्षण स्थितियों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं।<ref name="Liu" />


एक लिखित परीक्षा मामले में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए।
एक लिखित परीक्षा स्थिति में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए।


इन चरणों को वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है।
इन चरणों को वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है।


एक डेटाबेस सिस्टम में, आप पिछले परीक्षण परिणामों को देखने में सक्षम हो सकते हैं और उन परिणामों को उत्पन्न करने के लिए उपयोग किए जाने वाले सिस्टम कॉन्फ़िगरेशन और परिणाम उत्पन्न करने वाले कौन हैं। ये पिछले परिणाम आमतौर पर एक अलग तालिका में संग्रहीत किए जाते हैं।
एक डेटाबेस प्रणाली में, आप पिछले परीक्षण परिणामों को देखने में सक्षम हो सकते हैं और उन परिणामों को उत्पन्न करने के लिए उपयोग किए जाने वाले प्रणाली कॉन्फ़िगरेशन और परिणाम उत्पन्न करने वाले कौन हैं। ये पिछले परिणाम सामान्यतः एक अलग तालिका में संग्रहीत किए जाते हैं।


[[परीक्षण सूट]] में भी अक्सर होता है<ref name="tcs">{{cite book |last1=Kaner |first1=Cem |last2=Falk |first2=Jack |last3=Nguyen |first3=Hung Q. |year=1993 |title=कंप्यूटर सॉफ्टवेयर का परीक्षण|url=https://archive.org/details/testingcomputers00kanerich |url-access=registration |edition=2nd |location=Boston |publisher=Thomson Computer Press |page=[https://archive.org/details/testingcomputers00kanerich/page/123 123–4] |isbn=1-85032-847-1}}</ref>
[[परीक्षण सूट]] में भी अधिकांशतः होता है<ref name="tcs">{{cite book |last1=Kaner |first1=Cem |last2=Falk |first2=Jack |last3=Nguyen |first3=Hung Q. |year=1993 |title=कंप्यूटर सॉफ्टवेयर का परीक्षण|url=https://archive.org/details/testingcomputers00kanerich |url-access=registration |edition=2nd |location=Boston |publisher=Thomson Computer Press |page=[https://archive.org/details/testingcomputers00kanerich/page/123 123–4] |isbn=1-85032-847-1}}</ref>
* टेस्ट सारांश
* टेस्ट सारांश
* विन्यास
* विन्यास


परीक्षण की जाने वाली कार्यक्षमता के विवरण के अलावा, और यह सुनिश्चित करने के लिए आवश्यक तैयारी कि परीक्षण आयोजित किया जा सकता है, परीक्षण मामले में सबसे अधिक समय लेने वाला हिस्सा परीक्षण बना रहा है और सिस्टम में बदलाव होने पर उन्हें संशोधित कर रहा है।
परीक्षण की जाने वाली कार्यक्षमता के विवरण के अतिरिक्त, और यह सुनिश्चित करने के लिए आवश्यक तैयारी कि परीक्षण आयोजित किया जा सकता है, परीक्षण स्थिति में सबसे अधिक समय लेने वाला हिस्सा परीक्षण बना रहा है और प्रणाली में बदलाव होने पर उन्हें संशोधित कर रहा है।


विशेष परिस्थितियों में, परीक्षण चलाने, परिणाम उत्पन्न करने की आवश्यकता हो सकती है, और फिर विशेषज्ञों की एक टीम मूल्यांकन करेगी कि क्या परिणामों को पास माना जा सकता है। यह अक्सर नए उत्पादों के प्रदर्शन संख्या निर्धारण पर होता है। पहले परीक्षण को बाद के परीक्षण और उत्पाद रिलीज़ चक्रों के लिए आधार रेखा के रूप में लिया जाता है।
विशेष परिस्थितियों में, परीक्षण चलाने, परिणाम उत्पन्न करने की आवश्यकता हो सकती है, और फिर विशेषज्ञों की एक टीम मूल्यांकन करेगी कि क्या परिणामों को पास माना जा सकता है। यह अधिकांशतः नए उत्पादों के प्रदर्शन संख्या निर्धारण पर होता है। पहले परीक्षण को बाद के परीक्षण और उत्पाद रिलीज़ चक्रों के लिए आधार रेखा के रूप में लिया जाता है।


स्वीकृति परीक्षण, जो एक लिखित परीक्षण मामले की भिन्नता का उपयोग करते हैं, आमतौर पर [[अंतिम उपयोगकर्ता]]ओं या सिस्टम के ग्राहकों के समूह द्वारा यह सुनिश्चित करने के लिए किया जाता है कि विकसित प्रणाली निर्दिष्ट आवश्यकताओं या अनुबंध को पूरा करती है।<ref>{{cite book|last= Goethem|first= Brian Hambling, Pauline van|title= User acceptance testing : a step-by-step guide|year= 2013|publisher= BCS Learning & Development Limited|isbn= 9781780171678}}</ref><ref>{{cite book| last=Black | first=Rex | date=August 2009 | title= Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing | url=https://archive.org/details/managingtestingp00rexb | url-access=registration | publisher=Hoboken, NJ: Wiley | isbn=978-0-470-40415-7}}</ref> नकारात्मक परीक्षण मामलों के लगभग पूर्ण बहिष्करण के लिए उपयोगकर्ता स्वीकृति परीक्षणों को खुश पथ या सकारात्मक परीक्षण मामलों को शामिल करने से अलग किया जाता है।<ref>{{cite book|last= Cimperman|first= Rob|title= UAT Defined: A Guide to Practical User Acceptance Testing|year= 2006|publisher= Pearson Education|isbn= 9780132702621|pages=Chapter 2}}</ref>
स्वीकृति परीक्षण, जो एक लिखित परीक्षण स्थिति की भिन्नता का उपयोग करते हैं, सामान्यतः [[अंतिम उपयोगकर्ता]]ओं या प्रणाली के ग्राहकों के समूह द्वारा यह सुनिश्चित करने के लिए किया जाता है कि विकसित प्रणाली निर्दिष्ट आवश्यकताओं या अनुबंध को पूरा करती है।<ref>{{cite book|last= Goethem|first= Brian Hambling, Pauline van|title= User acceptance testing : a step-by-step guide|year= 2013|publisher= BCS Learning & Development Limited|isbn= 9781780171678}}</ref><ref>{{cite book| last=Black | first=Rex | date=August 2009 | title= Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing | url=https://archive.org/details/managingtestingp00rexb | url-access=registration | publisher=Hoboken, NJ: Wiley | isbn=978-0-470-40415-7}}</ref> नकारात्मक परीक्षण स्थितियों के लगभग पूर्ण बहिष्करण के लिए उपयोगकर्ता स्वीकृति परीक्षणों को खुश पथ या सकारात्मक परीक्षण स्थितियों को सम्मिलित करने से अलग किया जाता है।<ref>{{cite book|last= Cimperman|first= Rob|title= UAT Defined: A Guide to Practical User Acceptance Testing|year= 2006|publisher= Pearson Education|isbn= 9780132702621|pages=Chapter 2}}</ref>




Revision as of 23:51, 7 March 2023

This article is about सॉफ्टवेयर इंजीनियरिंग के शब्द में. For वैधानिक शब्द, see परीक्षण स्थिति (नियम). For अन्य उपयोग, see परीक्षण स्थिति (बहुविकल्पीय).

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


औपचारिक परीक्षण स्थिति

पूरी तरह से परीक्षण करने के लिए कि एक अनुप्रयोग की सभी आवश्यकताओं को पूरा किया गया है, प्रत्येक आवश्यकता के लिए कम से कम दो परीक्षण सकारात्मक परीक्षण और एक नकारात्मक परीक्षण स्थिति होनी चाहिए: एक सकारात्मक परीक्षण और एक नकारात्मक परीक्षण।[3] यदि किसी आवश्यकता की उप-आवश्यकताएँ हैं, तो प्रत्येक उप-आवश्यकता में कम से कम दो परीक्षण स्थिति होनी चाहिए। आवश्यकता और परीक्षण के बीच की कड़ी का ट्रैक रखना अधिकांशतः ट्रेसबिलिटी मैट्रिक्स का उपयोग करके किया जाता है। लिखित परीक्षा की स्थितियों में परीक्षण की जाने वाली कार्यक्षमता का विवरण, और यह सुनिश्चित करने के लिए आवश्यक तैयारी सम्मिलित होनी चाहिए कि परीक्षण आयोजित किया जा सकता है।

एक औपचारिक लिखित परीक्षा स्थिति को एक ज्ञात इनपुट और एक अपेक्षित आउटपुट द्वारा चित्रित किया जाता है, जिसे परीक्षण के निष्पादन से पहले काम किया जाता है।[4] ज्ञात इनपुट को पूर्व नियम का परीक्षण करना चाहिए और अपेक्षित आउटपुट को पोस्टकंडिशन का परीक्षण करना चाहिए।

एक औपचारिक लिखित परीक्षा स्थिति को एक ज्ञात इनपुट और एक अपेक्षित आउटपुट द्वारा चित्रित किया जाता है, जिसे परीक्षण निष्पादित करने से पहले काम किया जाता है।[4] ज्ञात इनपुट को पूर्व नियम का परीक्षण करना चाहिए और अपेक्षित आउटपुट को [[नियम लगाना]] का परीक्षण करना चाहिए।

अनौपचारिक परीक्षण स्थिति

औपचारिक आवश्यकताओं के बिना अनुप्रयोगों या प्रणालियों के लिए, समान वर्ग के कार्यक्रमों के स्वीकृत सामान्य संचालन के आधार पर परीक्षण स्थितियों को लिखा जा सकता है। परीक्षण के कुछ विद्यालयों में, परीक्षण स्थितियों को बिल्कुल नहीं लिखा जाता है, लेकिन परीक्षण चलाए जाने के बाद गतिविधियों और परिणामों की सूचना दी जाती है।

परिदृश्य परीक्षण में, एक जटिल समस्या या प्रणाली के माध्यम से परीक्षक को सोचने में सहायता करने के लिए काल्पनिक कहानियों का उपयोग किया जाता है। इन परिदृश्यों को सामान्यतः किसी भी विवरण में नहीं लिखा जाता है। वे एक परीक्षण वातावरण के लिए आरेख के रूप में सरल हो सकते हैं या वे गद्य में लिखे गए विवरण हो सकते हैं। आदर्श परिदृश्य परीक्षण एक ऐसी कहानी है जो प्रेरक, विश्वसनीय, जटिल और मूल्यांकन करने में सरल है। वे सामान्यतः परीक्षण स्थितियों से भिन्न होते हैं, परीक्षण स्थिति एकल चरण होते हैं जबकि परिदृश्य कुंजी के कई चरणों को कवर करते हैं।[5][6]


विशिष्ट लिखित परीक्षा केस प्रारूप

किसी एप्लिकेशन के सही व्यवहार/कार्यक्षमता, विशेषताओं का परीक्षण करने के लिए एक परीक्षण स्थिति सामान्यतः एक चरण या कभी-कभी चरणों का एक क्रम होता है। एक अपेक्षित परिणाम या अपेक्षित परिणाम सामान्यतः दिया जाता है।[7]

अतिरिक्त जानकारी जो सम्मिलित हो सकती है:[8]

  • टेस्ट केस आईडी - यह फील्ड विशिष्ट रूप से एक टेस्ट केस की पहचान करता है।
  • टेस्ट केस का विवरण/सारांश - यह फील्ड टेस्ट केस के उद्देश्य का वर्णन करता है।
  • टेस्ट स्टेप्स - इस फील्ड में, टेस्ट केस को करने के लिए सटीक स्टेप्स का उल्लेख किया गया है।
  • पूर्वापेक्षाएँ - यह फ़ील्ड उन नियमों या चरणों को निर्दिष्ट करती है जिनका परीक्षण चरणों के निष्पादन से पहले पालन किया जाना चाहिए।
  • टेस्ट श्रेणी
  • लेखक- परीक्षक का नाम।
  • ऑटोमेशन - यह टेस्ट केस ऑटोमेटेड है या नहीं।
  • उतीर्ण अनुतीर्ण
  • टिप्पणियां

बड़े परीक्षण स्थितियों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं।[8]

एक लिखित परीक्षा स्थिति में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए।

इन चरणों को वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है।

एक डेटाबेस प्रणाली में, आप पिछले परीक्षण परिणामों को देखने में सक्षम हो सकते हैं और उन परिणामों को उत्पन्न करने के लिए उपयोग किए जाने वाले प्रणाली कॉन्फ़िगरेशन और परिणाम उत्पन्न करने वाले कौन हैं। ये पिछले परिणाम सामान्यतः एक अलग तालिका में संग्रहीत किए जाते हैं।

परीक्षण सूट में भी अधिकांशतः होता है[9]

  • टेस्ट सारांश
  • विन्यास

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

विशेष परिस्थितियों में, परीक्षण चलाने, परिणाम उत्पन्न करने की आवश्यकता हो सकती है, और फिर विशेषज्ञों की एक टीम मूल्यांकन करेगी कि क्या परिणामों को पास माना जा सकता है। यह अधिकांशतः नए उत्पादों के प्रदर्शन संख्या निर्धारण पर होता है। पहले परीक्षण को बाद के परीक्षण और उत्पाद रिलीज़ चक्रों के लिए आधार रेखा के रूप में लिया जाता है।

स्वीकृति परीक्षण, जो एक लिखित परीक्षण स्थिति की भिन्नता का उपयोग करते हैं, सामान्यतः अंतिम उपयोगकर्ताओं या प्रणाली के ग्राहकों के समूह द्वारा यह सुनिश्चित करने के लिए किया जाता है कि विकसित प्रणाली निर्दिष्ट आवश्यकताओं या अनुबंध को पूरा करती है।[10][11] नकारात्मक परीक्षण स्थितियों के लगभग पूर्ण बहिष्करण के लिए उपयोगकर्ता स्वीकृति परीक्षणों को खुश पथ या सकारात्मक परीक्षण स्थितियों को सम्मिलित करने से अलग किया जाता है।[12]


यह भी देखें

संदर्भ

  1. ↑ Systems and software engineering – Vocabulary. 2010-12-01. pp. 1–418. doi:10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8. {{cite book}}: |journal= ignored (help)
  2. ↑ Kaner, Cem (May 2003). "What Is a Good Test Case?" (PDF). STAR East: 2.
  3. ↑ "हितधारक आवश्यकताओं को सत्यापित करने के लिए परीक्षण नियम लिखना". StickyMinds.
  4. ↑ 4.0 4.1 Beizer, Boris (May 22, 1995). ब्लैक बॉक्स परीक्षण. New York: Wiley. p. 3. ISBN 9780471120940.
  5. ↑ "परिदृश्य परीक्षण का एक परिचय" (PDF). Cem Kaner. Retrieved 2009-05-07.
  6. ↑ Crispin, Lisa; Gregory, Janet (2009). Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley. pp. 192–5. ISBN 978-81-317-3068-3.
  7. ↑ https://www.softwaretestingstandard.org/part3.php ISO/IEC/IEEE 29119-4:2019, "Part 4: Test techniques"
  8. ↑ 8.0 8.1 Liu, Juan (2014). "जीयूआई पर आधारित सॉफ्टवेयर परीक्षण प्रक्रियाओं का अध्ययन". 2014 International Conference on Computer, Network: 113–121. doi:10.1109/CSCI.2014.104. ISBN 9781605951676. S2CID 15204091. Retrieved 2019-10-22.
  9. ↑ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). कंप्यूटर सॉफ्टवेयर का परीक्षण (2nd ed.). Boston: Thomson Computer Press. p. 123–4. ISBN 1-85032-847-1.
  10. ↑ Goethem, Brian Hambling, Pauline van (2013). User acceptance testing : a step-by-step guide. BCS Learning & Development Limited. ISBN 9781780171678.{{cite book}}: CS1 maint: multiple names: authors list (link)
  11. ↑ Black, Rex (August 2009). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. Hoboken, NJ: Wiley. ISBN 978-0-470-40415-7.
  12. ↑ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing. Pearson Education. pp. Chapter 2. ISBN 9780132702621.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=परीक्षण_स्थिति&oldid=103579’