परीक्षण विश्लेषण और परीक्षण का आधार
थॉमस हैमिल्टन
⚡ स्मार्ट सारांश
परीक्षण विश्लेषण, जिसे परीक्षण आधार भी कहा जाता है, आवश्यकताओं, डिज़ाइन दस्तावेज़ों और अन्य सामग्रियों की संरचित समीक्षा है जिसका उपयोग परीक्षण योग्य स्थितियों को निर्धारित करने के लिए किया जाता है। यह लेख परीक्षण विश्लेषण के स्रोतों, चरण-दर-चरण कार्यप्रवाह और वी-मॉडल में इसके स्थान की व्याख्या करता है।
टेस्ट एनालिसिस — जिसे टेस्ट बेसिस भी कहा जाता है — टेस्टिंग लाइफ साइकिल के बिल्कुल शुरुआती चरण में आता है। प्रत्येक टेस्ट कंडीशन और टेस्ट केस अंततः tracआइए इस पर वापस आते हैं। नीचे दिए गए अनुभाग इस शब्द को परिभाषित करते हैं, इसके स्रोतों की व्याख्या करते हैं, विश्लेषण कार्यप्रवाह को समझाते हैं और इसे वी-मॉडल में रखते हैं।
टेस्ट एनालिसिस क्या है?
परीक्षण विश्लेषण सॉफ्टवेयर टेस्टिंग में, परीक्षण स्थितियों और परीक्षण मामलों को प्राप्त करने के लिए उपयोग किए गए इनपुट की समीक्षा करने की प्रक्रिया को सॉफ्टवेयर टेस्टिंग कहा जाता है। इन इनपुट - विनिर्देश, आवश्यकताएं, डिज़ाइन दस्तावेज़, उपयोगकर्ता कहानियां और इसी तरह के अन्य डिलिवरेबल्स - को सामूहिक रूप से कहा जाता है। परीक्षण कलाकृतियाँपरीक्षण विश्लेषण का लक्ष्य यह पता लगाना है किtracपरीक्षण के उद्देश्य इतने स्पष्ट होने चाहिए कि प्रत्येक को एक स्पष्ट परीक्षण स्थिति में बदला जा सके। क्योंकि विश्लेषित सामग्री वह आधार है जिससे सभी परीक्षण प्राप्त होते हैं, इसलिए इसे परीक्षण सामग्री भी कहा जाता है। परीक्षण का आधार.
परीक्षकों द्वारा परीक्षण संबंधी जानकारी प्राप्त करने के लिए उपयोग किए जाने वाले सामान्य स्रोत निम्नलिखित हैं:
- एसआरएस — सॉफ्टवेयर आवश्यकता विनिर्देश
- बीआरएस — व्यावसायिक आवश्यकताओं का विनिर्देश
- कार्यात्मक डिज़ाइन दस्तावेज़
- उपयोगकर्ता कहानियां, स्वीकृति मानदंड और वायरफ्रेम
परीक्षक परीक्षण के तहत एप्लिकेशन का सीधे पता लगाकर या पिछले अनुभव के आधार पर भी परीक्षण की स्थितियाँ उत्पन्न कर सकते हैं, लेकिन अधिकांश परीक्षण के मामलों परीक्षण कलाकृतियों से प्राप्त किए जाते हैं ताकि उन्हें बनाए रखा जा सके tracक्षमता।
👉 निःशुल्क लाइव सॉफ्टवेयर परीक्षण परियोजना के लिए नामांकन करें
टेस्ट बेसिस क्यों महत्वपूर्ण है?
टेस्ट बेसिस ही सबसे बड़ा निर्धारक है कि कोई टेस्ट सूट वास्तविक दोषों को पकड़ता है या काल्पनिक दोषों का पीछा करता है। इसे वैकल्पिक मानना उत्पादन तक बग्स के पहुँचने का सबसे आम कारण है। ठोस टेस्ट विश्लेषण से चार महत्वपूर्ण लाभ मिलते हैं:
- Tracक्षमता: प्रत्येक टेस्ट केस को एक विशिष्ट आवश्यकता से जोड़ा जा सकता है, जिससे परिवर्तन-प्रभाव विश्लेषण तेज हो जाता है और ऑडिट समीक्षा आसान हो जाती है।
- कवरेज की स्पष्टता: Revआधारभूत सतहों का अवलोकन करने से उत्पादन संबंधी घटनाओं में तब्दील होने से पहले ही कमियों का पता चल जाता है — जैसे कि अनिर्दिष्ट त्रुटि स्थितियाँ, अनुपलब्ध सीमाएँ, अपरिभाषित गैर-कार्यात्मक सीमाएँ।
- हितधारक संरेखण: जब परीक्षण टीम उन्हीं दस्तावेजों से शर्तें प्राप्त करती है जिनके आधार पर विकास टीम निर्माण करती है, तो दोनों पक्षों के पास "पूर्ण" की एक साझा परिभाषा होती है।
- प्रारंभिक दोष पहचान: कई आवश्यकताओं से संबंधित दोष (अस्पष्टता, विरोधाभास, स्वीकृति मानदंडों की कमी) परीक्षण विश्लेषण के दौरान ही पकड़ में आ जाते हैं, कोड लिखे जाने से काफी पहले - और यही उन्हें ठीक करने का सबसे सस्ता तरीका है।
परीक्षण आधार के सामान्य स्रोत
विभिन्न दस्तावेज़ अलग-अलग परीक्षण स्तरों को प्रभावित करते हैं। टेस्ट केस लिखते समय किस दस्तावेज़ का उपयोग करना है, यह तय करने के लिए नीचे दी गई तालिका का त्वरित संदर्भ के रूप में उपयोग करें।
| स्रोत कलाकृति | के लिए सबसे अच्छा सूट | आप क्या पूर्वtract |
|---|---|---|
| व्यावसायिक आवश्यकताएँ विशिष्टता (बीआरएस) | स्वीकृति और सिस्टम परीक्षण | संपूर्ण व्यावसायिक नियम, नियामकीय बाधाएं, सफलता के मानदंड |
| सॉफ़्टवेयर आवश्यकताएँ विशिष्टता (SRS) | सिस्टम परीक्षण | मापने योग्य सीमा के साथ कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं |
| कार्यात्मक / तकनीकी डिजाइन दस्तावेज़ | एकीकरण जांच | मॉड्यूल इंटरफेस, डेटा प्रवाह, त्रुटि-प्रबंधन विनिर्देश |
| उपयोगकर्ता कहानियां और स्वीकृति मानदंड | एजाइल स्प्रिंट परीक्षण | “Given–when–then” प्रारूप में व्यवहार संबंधी अपेक्षाएँ |
| वायरफ्रेम और यूआई मॉकअप | यूआई / उपयोगिता परीक्षण | लेआउट, नेविगेशन, इनपुट सत्यापन नियम |
| परीक्षणधीन आवेदन (प्रारंभिक) | अन्वेषणात्मक और प्रतिगमन परीक्षण | अज्ञात व्यवहार, वास्तविक दुनिया के कार्यप्रवाह, अपवाद मामले |
चरण-दर-चरण परीक्षण विश्लेषण कैसे करें
प्रभावी परीक्षण विश्लेषण परियोजना के आकार या कार्यप्रणाली की परवाह किए बिना, एक दोहराने योग्य पांच-चरणीय कार्यप्रवाह का पालन करता है।
- परीक्षण के आधार को एकत्रित करें और उसकी सूची बनाएं। अपेक्षित व्यवहार का वर्णन करने वाले प्रत्येक दस्तावेज़ को एकत्रित करें — एसआरएस, बीआरएस, डिज़ाइन दस्तावेज़, उपयोगकर्ता कहानियां, मॉकअप। ध्यान दें कि प्रत्येक आवश्यकता किस दस्तावेज़ से संबंधित है। tracक्षमता बरकरार रहती है।
- Revपरीक्षण योग्यता के लिए समीक्षा करें। प्रत्येक दस्तावेज़ को पढ़ते समय तीन बातों का ध्यान रखें: क्या यह कथन मापने योग्य है? क्या यह स्पष्ट है? क्या यह पूर्ण है? यदि कोई आवश्यकता इनमें से किसी भी जाँच में विफल रहती है, तो उसे चिह्नित करें और उसके विरुद्ध परीक्षण लिखने से पहले उसे लेखक को सूचित करें।
- परीक्षण की स्थितियों की पहचान करें। प्रत्येक परीक्षण योग्य कथन के लिए, सत्यापन की आवश्यकता वाली शर्तों (सकारात्मक पथ, नकारात्मक पथ, सीमा मान, त्रुटि प्रबंधन, सुरक्षा, प्रदर्शन) को सूचीबद्ध करें। परीक्षण शर्त वह निरपेक्ष मान है।tracउदाहरण के लिए, "क्या" “सिस्टम शून्य मात्रा वाले ऑर्डर अस्वीकार करता है” — यह किसी परीक्षण मामले के ठोस "कैसे" से भिन्न है।
- स्थितियों को प्राथमिकता दें और समूहबद्ध करें। प्रत्येक स्थिति को जोखिम और उपयोग की आवृत्ति के आधार पर वर्गीकृत करें। उच्च जोखिम और उच्च आवृत्ति वाली स्थितियों का विस्तृत विश्लेषण किया जाता है; कम जोखिम वाली स्थितियों को संयोजित या नमूना के रूप में लिया जा सकता है। यहीं पर आप यह भी तय करते हैं कि किन स्थितियों को स्वचालित किया जा सकता है।
- शर्तों को टेस्ट केस में बदलें। प्रत्येक प्राथमिकता वाली स्थिति एक या अधिक बन जाती है परीक्षण के मामलों पूर्व शर्तों, चरणों, परीक्षण डेटा और अपेक्षित परिणामों के साथ आवश्यकताओं का रिकॉर्ड बनाए रखें। tracप्रत्येक टेस्ट केस को उसकी मूल आवश्यकता से जोड़ने वाला एक योग्यता मैट्रिक्स।
इस क्रम का पालन करने से परीक्षण विश्लेषण की सबसे आम गलतियों से बचा जा सकता है: स्पष्ट आधार के बिना परीक्षण मामले लिखना, नकारात्मक परिदृश्यों को अनदेखा करना और ऐसे परीक्षण तैयार करना जिन्हें दोष वर्गीकरण के दौरान किसी आवश्यकता से वापस नहीं जोड़ा जा सकता है।
वी-मॉडल में परीक्षण विश्लेषण
वी-मॉडल प्रत्येक विकास गतिविधि को एक संबंधित परीक्षण गतिविधि के साथ जोड़ता है। परीक्षण विश्लेषण प्रत्येक स्तर पर उस समय उपलब्ध दस्तावेज़ का उपयोग करके किया जाता है।
चित्र 1: परीक्षण के विभिन्न चरणों में विश्लेषण वि मॉडल.
केस स्टडी: ग्राहक की आवश्यकता से टेस्ट केस तैयार करना
एक ऐसे परिदृश्य पर विचार करें जिसमें ग्राहक निम्नलिखित एक पंक्ति की आवश्यकता भेजता है।
Client requirement: Add search functionality to an eCommerce Store
भले ही एप्लिकेशन अभी तक विकसित नहीं हुआ है, फिर भी एक परीक्षक आवश्यकता के निहितार्थों का विश्लेषण करके कई परीक्षण स्थितियों का पता लगा सकता है - जिसमें सामान्य व्यवहार और क्लाइंट द्वारा स्पष्ट रूप से उल्लिखित न किए गए विफलता मोड दोनों शामिल हैं। कुछ उदाहरणों में शामिल हैं:
- जब कोई कीवर्ड दर्ज न किया गया हो तो खोज परिणाम सत्यापित करें।
- यदि दर्ज किए गए कीवर्ड के लिए कोई मेल खाने वाला उत्पाद मौजूद नहीं है, तो खोज परिणाम को सत्यापित करें।
- यदि किसी कीवर्ड के लिए कई मिलते-जुलते उत्पाद मौजूद हों, तो खोज परिणाम की पुष्टि करें।
- विशेष वर्णों, आरंभिक/अनुगामी रिक्त स्थानों और बहुत लंबे इनपुट के साथ व्यवहार की जाँच करें।
- केस-सेंसिटिविटी और पार्शियल-मैच व्यवहार की पुष्टि करें।
- अपेक्षित उपयोगकर्ता भार के तहत खोज प्रतिक्रिया समय को सत्यापित करें।
परीक्षक ग्राहक की आवश्यकता (परीक्षण का आधार) लेता है, उसका विश्लेषण करता है और उसे परीक्षण स्थितियों में परिवर्तित करता है। यह प्रक्रिया वी-मॉडल के प्रत्येक चरण में दोहराई जाती है - परीक्षण योजनाएँ और परीक्षण मामले उस समय उपलब्ध दस्तावेज़ का उपयोग करके बनाए जाते हैं।
वीडियो: परीक्षण विश्लेषण की व्याख्या
यदि वीडियो लोड नहीं होता है, तो इसे सीधे यहां देखें YouTube.
