परीक्षण स्थिति: Difference between revisions
No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
{{about|सॉफ्टवेयर इंजीनियरिंग के शब्द में|वैधानिक शब्द|परीक्षण स्थिति (नियम)|अन्य उपयोग|परीक्षण स्थिति (बहुविकल्पीय)}} | {{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 web|url=https://www.stickyminds.com/article/writing-test-rules-verify-stakeholder-requirements|title=हितधारक आवश्यकताओं को सत्यापित करने के लिए परीक्षण नियम लिखना|website=StickyMinds}}</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> ज्ञात इनपुट को पूर्व नियम का परीक्षण करना चाहिए और अपेक्षित आउटपुट को [[शर्त लगाना|पोस्टकंडिशन]] का परीक्षण करना चाहिए। | |||
== अनौपचारिक परीक्षण स्थिति == | == अनौपचारिक परीक्षण स्थिति == | ||
Line 17: | Line 15: | ||
औपचारिक आवश्यकताओं के बिना अनुप्रयोगों या प्रणालियों के लिए, समान वर्ग के कार्यक्रमों के स्वीकृत सामान्य संचालन के आधार पर परीक्षण स्थितियों को लिखा जा सकता है। परीक्षण के कुछ विद्यालयों में, परीक्षण स्थितियों को बिल्कुल नहीं लिखा जाता है, लेकिन परीक्षण चलाए जाने के बाद गतिविधियों और परिणामों की सूचना दी जाती है। | औपचारिक आवश्यकताओं के बिना अनुप्रयोगों या प्रणालियों के लिए, समान वर्ग के कार्यक्रमों के स्वीकृत सामान्य संचालन के आधार पर परीक्षण स्थितियों को लिखा जा सकता है। परीक्षण के कुछ विद्यालयों में, परीक्षण स्थितियों को बिल्कुल नहीं लिखा जाता है, लेकिन परीक्षण चलाए जाने के बाद गतिविधियों और परिणामों की सूचना दी जाती है। | ||
[[परिदृश्य परीक्षण]] में, | [[परिदृश्य परीक्षण]] में, जटिल समस्या या प्रणाली के माध्यम से परीक्षक को सोचने में सहायता करने के लिए काल्पनिक कहानियों का उपयोग किया जाता है। इन परिदृश्यों को सामान्यतः किसी भी विवरण में नहीं लिखा जाता है। वे परीक्षण वातावरण के लिए आरेख के रूप में सरल हो सकते हैं या वे गद्य में लिखे गए विवरण हो सकते हैं। आदर्श परिदृश्य परीक्षण ऐसी कहानी है जो प्रेरक, विश्वसनीय, जटिल और मूल्यांकन करने में सरल है। वे सामान्यतः परीक्षण स्थितियों से भिन्न होते हैं, परीक्षण स्थिति एकल चरण होते हैं जबकि परिदृश्य कुंजी के कई चरणों को कवर करते हैं।<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 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 40: | Line 35: | ||
बड़े परीक्षण स्थितियों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं।<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> | ||
Line 52: | Line 47: | ||
परीक्षण की जाने वाली कार्यक्षमता के विवरण के अतिरिक्त, और यह सुनिश्चित करने के लिए तैयारी की आवश्यकता है कि परीक्षण आयोजित किया जा सकता है, परीक्षण स्थिति में सबसे अधिक समय लेने वाला हिस्सा परीक्षण बना रहा है और प्रणाली में परिवर्तन होने पर उन्हें संशोधित कर रहा है। | परीक्षण की जाने वाली कार्यक्षमता के विवरण के अतिरिक्त, और यह सुनिश्चित करने के लिए तैयारी की आवश्यकता है कि परीक्षण आयोजित किया जा सकता है, परीक्षण स्थिति में सबसे अधिक समय लेने वाला हिस्सा परीक्षण बना रहा है और प्रणाली में परिवर्तन होने पर उन्हें संशोधित कर रहा है। | ||
विशेष परिस्थितियों में, परीक्षण चलाने, परिणाम उत्पन्न करने की आवश्यकता हो सकती है, और फिर विशेषज्ञों की | विशेष परिस्थितियों में, परीक्षण चलाने, परिणाम उत्पन्न करने की आवश्यकता हो सकती है, और फिर विशेषज्ञों की टीम मूल्यांकन करेगी कि क्या परिणामों को पास माना जा सकता है। यह अधिकांशतः नए उत्पादों के प्रदर्शन संख्या निर्धारण पर होता है। पहले परीक्षण को बाद के परीक्षण और उत्पाद रिलीज़ चक्रों के लिए आधार रेखा के रूप में लिया जाता है। | ||
स्वीकृति परीक्षण, जो | स्वीकृति परीक्षण, जो लिखित परीक्षण स्थिति की भिन्नता का उपयोग करते हैं, सामान्यतः [[अंतिम उपयोगकर्ता|अंतिम उपयोगकर्ताओं]] या प्रणाली के ग्राहकों के समूह द्वारा यह सुनिश्चित करने के लिए किया जाता है कि विकसित प्रणाली निर्दिष्ट आवश्यकताओं या अनुबंध को पूरा करती है।<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 01:59, 8 March 2023
सॉफ्टवेयर इंजीनियरिंग में, परीक्षण स्थिति इनपुट, निष्पादन की स्थिति, परीक्षण प्रक्रिया और अपेक्षित परिणाम का विनिर्देश है जो विशेष सॉफ्टवेयर परीक्षण उद्देश्य को प्राप्त करने के लिए निष्पादित किए जाने वाले एकल परीक्षण को परिभाषित करता है, जैसे किसी विशेष प्रोग्राम पथ का प्रयोग करना या सत्यापित करना तथा विशिष्ट आवश्यकता का अनुपालन करना इत्यादि।[1] परीक्षण की स्थिति परीक्षण के अंतर्गत आती हैं, जो बेतरतीब होने के अतिरिक्त व्यवस्थित है। परीक्षण किए जा रहे सॉफ़्टवेयर के वांछित कवरेज का उत्पादन करने के लिए परीक्षण स्थितियों की बैटरी बनाई जा सकती है। औपचारिक रूप से परिभाषित परीक्षण स्थिति एक ही परीक्षण को सॉफ्टवेयर के क्रमिक संस्करणों के विरुद्ध समान परीक्षणों को बार-बार चलाने की अनुमति देते हैं, जिससे प्रभावी और सुसंगत प्रतिगमन परीक्षण की अनुमति मिलती है।[2]
औपचारिक परीक्षण स्थिति
पूरी तरह से परीक्षण करने के लिए कि अनुप्रयोग की सभी आवश्यकताओं को पूरा किया गया है, प्रत्येक आवश्यकता के लिए कम से कम दो परीक्षण सकारात्मक परीक्षण और नकारात्मक परीक्षण स्थिति होनी चाहिए।[3] यदि किसी आवश्यकता की उप-आवश्यकताएँ हैं, तो प्रत्येक उप-आवश्यकता में कम से कम दो परीक्षण स्थिति होनी चाहिए। आवश्यकता और परीक्षण के बीच की कड़ी का ट्रैक रखना अधिकांशतः ट्रेसबिलिटी आव्यूह का उपयोग करके किया जाता है। लिखित परीक्षा की स्थितियों में परीक्षण की जाने वाली कार्यक्षमता का विवरण, और यह सुनिश्चित करने के लिए आवश्यक तैयारी सम्मिलित होनी चाहिए कि परीक्षण आयोजित किया जा सकता है।
औपचारिक लिखित परीक्षा स्थिति को ज्ञात इनपुट और अपेक्षित आउटपुट द्वारा चित्रित किया जाता है, जिसे परीक्षण के निष्पादन से पहले काम किया जाता है।[4] ज्ञात इनपुट को पूर्व नियम का परीक्षण करना चाहिए और अपेक्षित आउटपुट को पोस्टकंडिशन का परीक्षण करना चाहिए।
अनौपचारिक परीक्षण स्थिति
औपचारिक आवश्यकताओं के बिना अनुप्रयोगों या प्रणालियों के लिए, समान वर्ग के कार्यक्रमों के स्वीकृत सामान्य संचालन के आधार पर परीक्षण स्थितियों को लिखा जा सकता है। परीक्षण के कुछ विद्यालयों में, परीक्षण स्थितियों को बिल्कुल नहीं लिखा जाता है, लेकिन परीक्षण चलाए जाने के बाद गतिविधियों और परिणामों की सूचना दी जाती है।
परिदृश्य परीक्षण में, जटिल समस्या या प्रणाली के माध्यम से परीक्षक को सोचने में सहायता करने के लिए काल्पनिक कहानियों का उपयोग किया जाता है। इन परिदृश्यों को सामान्यतः किसी भी विवरण में नहीं लिखा जाता है। वे परीक्षण वातावरण के लिए आरेख के रूप में सरल हो सकते हैं या वे गद्य में लिखे गए विवरण हो सकते हैं। आदर्श परिदृश्य परीक्षण ऐसी कहानी है जो प्रेरक, विश्वसनीय, जटिल और मूल्यांकन करने में सरल है। वे सामान्यतः परीक्षण स्थितियों से भिन्न होते हैं, परीक्षण स्थिति एकल चरण होते हैं जबकि परिदृश्य कुंजी के कई चरणों को कवर करते हैं।[5][6]
विशिष्ट लिखित परीक्षा केस प्रारूप
किसी अनुप्रयोग के सही व्यवहार/कार्यक्षमता, विशेषताओं का परीक्षण करने के लिए परीक्षण स्थिति सामान्यतः एक चरण या कभी-कभी चरणों का क्रम होता है। अपेक्षित परिणाम या अपेक्षित परिणाम सामान्यतः दिया जाता है।[7]
अतिरिक्त जानकारी जो सम्मिलित हो सकती है:[8]
- परीक्षण स्थिति आईडी - यह क्षेत्र विशिष्ट रूप से परीक्षण स्थिति की पहचान करता है।
- परीक्षण स्थिति का विवरण/सारांश - यह क्षेत्र परीक्षण स्थिति के उद्देश्य का वर्णन करता है।
- परीक्षण स्टेप्स - इस क्षेत्र में, परीक्षण स्थिति को करने के लिए स्पष्ट स्टेप्स का उल्लेख किया गया है।
- पूर्वापेक्षाएँ - यह फ़ील्ड उन नियमों या चरणों को निर्दिष्ट करती है जिनका परीक्षण चरणों के निष्पादन से पहले पालन किया जाना चाहिए।
- परीक्षण श्रेणी
- लेखक- परीक्षक का नाम।
- स्वचालन - यह परीक्षण स्थिति स्वचालित है या नहीं।
- उतीर्ण अनुतीर्ण
- टिप्पणियां
बड़े परीक्षण स्थितियों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं।[8]
लिखित परीक्षा स्थिति में वास्तविक परिणाम के लिए भी स्थान होना चाहिए।
इन चरणों को वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है।
डेटाबेस प्रणाली में, आप पिछले परीक्षण परिणामों को देखने में सक्षम हो सकते हैं और उन परिणामों को उत्पन्न करने के लिए उपयोग किए जाने वाले प्रणाली कॉन्फ़िगरेशन और परिणाम उत्पन्न करने वाले कौन हैं। ये पिछले परिणाम सामान्यतः अलग तालिका में संग्रहीत किए जाते हैं।
परीक्षण सूट में अधिकांशतः भी होता है:[9]
- परीक्षण सारांश
- विन्यास
परीक्षण की जाने वाली कार्यक्षमता के विवरण के अतिरिक्त, और यह सुनिश्चित करने के लिए तैयारी की आवश्यकता है कि परीक्षण आयोजित किया जा सकता है, परीक्षण स्थिति में सबसे अधिक समय लेने वाला हिस्सा परीक्षण बना रहा है और प्रणाली में परिवर्तन होने पर उन्हें संशोधित कर रहा है।
विशेष परिस्थितियों में, परीक्षण चलाने, परिणाम उत्पन्न करने की आवश्यकता हो सकती है, और फिर विशेषज्ञों की टीम मूल्यांकन करेगी कि क्या परिणामों को पास माना जा सकता है। यह अधिकांशतः नए उत्पादों के प्रदर्शन संख्या निर्धारण पर होता है। पहले परीक्षण को बाद के परीक्षण और उत्पाद रिलीज़ चक्रों के लिए आधार रेखा के रूप में लिया जाता है।
स्वीकृति परीक्षण, जो लिखित परीक्षण स्थिति की भिन्नता का उपयोग करते हैं, सामान्यतः अंतिम उपयोगकर्ताओं या प्रणाली के ग्राहकों के समूह द्वारा यह सुनिश्चित करने के लिए किया जाता है कि विकसित प्रणाली निर्दिष्ट आवश्यकताओं या अनुबंध को पूरा करती है।[10][11] नकारात्मक परीक्षण स्थितियों के लगभग पूर्ण बहिष्करण के लिए उपयोगकर्ता स्वीकृति परीक्षणों को शुभ पथ या सकारात्मक परीक्षण स्थितियों को सम्मिलित करने से अलग किया जाता है।[12]
यह भी देखें
संदर्भ
- ↑ 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) - ↑ Kaner, Cem (May 2003). "What Is a Good Test Case?" (PDF). STAR East: 2.
- ↑ "हितधारक आवश्यकताओं को सत्यापित करने के लिए परीक्षण नियम लिखना". StickyMinds.
- ↑ Beizer, Boris (May 22, 1995). ब्लैक बॉक्स परीक्षण. New York: Wiley. p. 3. ISBN 9780471120940.
- ↑ "परिदृश्य परीक्षण का एक परिचय" (PDF). Cem Kaner. Retrieved 2009-05-07.
- ↑ 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.
- ↑ https://www.softwaretestingstandard.org/part3.php ISO/IEC/IEEE 29119-4:2019, "Part 4: Test techniques"
- ↑ 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.
- ↑ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). कंप्यूटर सॉफ्टवेयर का परीक्षण (2nd ed.). Boston: Thomson Computer Press. p. 123–4. ISBN 1-85032-847-1.
- ↑ 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) - ↑ 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.
- ↑ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing. Pearson Education. pp. Chapter 2. ISBN 9780132702621.
बाहरी संबंध
- Writing Software Security Test Cases - Putting security test cases into your test plan by Robert Auger
- Software Test Case Engineering By Ajay Bhagwat