मेन्यू

टेस्ट केस कैसे लिखें: उदाहरणों के साथ अंतिम गाइड

how write test cases

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

इस गहराई से हाथ पर ट्यूटोरियल में कैसे लिखें टेस्ट मामलों के लिए, मैंने एक टेस्ट केस, इसकी मानक परिभाषा और टेस्ट केस डिज़ाइन तकनीकों का विवरण कवर किया है।

टेस्ट केस क्या है?

एक परीक्षण मामले में ऐसे घटक होते हैं जो इनपुट, कार्रवाई और एक अपेक्षित प्रतिक्रिया का वर्णन करते हैं, ताकि यह निर्धारित किया जा सके कि किसी एप्लिकेशन की एक विशेषता सही तरीके से काम कर रही है या नहीं।

एक परीक्षण मामला 'HOW' पर निर्देशों का एक सेट है जो किसी विशेष परीक्षण उद्देश्य / लक्ष्य को मान्य करने के लिए है, जिसका अनुसरण करने पर हमें पता चलेगा कि सिस्टम का अपेक्षित व्यवहार संतुष्ट है या नहीं।

टेस्ट केस कैसे लिखें

इस टेस्ट केस राइटिंग श्रृंखला में शामिल किए गए ट्यूटोरियल की सूची:

कैसे लिखना है:

ट्यूटोरियल # 1: एक टेस्ट केस क्या है और टेस्ट केस कैसे लिखें (यह ट्यूटोरियल)
ट्यूटोरियल # 2: उदाहरणों के साथ सैंपल टेस्ट केस टेम्प्लेट (डाउनलोड) (ज़रूर पढ़ें)
ट्यूटोरियल # 3: एसआरएस दस्तावेज़ से टेस्ट केस लिखना
ट्यूटोरियल # 4: एक दिए गए परिदृश्य के लिए टेस्ट केसेस कैसे लिखें
ट्यूटोरियल # 5: टेस्ट केस राइटिंग के लिए खुद को कैसे तैयार करें
ट्यूटोरियल # 6: नकारात्मक परीक्षण के मामले कैसे लिखें

उदाहरण:

ट्यूटोरियल # 7: वेब और डेस्कटॉप अनुप्रयोगों के लिए 180+ नमूना परीक्षण मामले
ट्यूटोरियल # 8: 100+ रेडी-टू-निष्पादित परीक्षा परिदृश्य (चेकलिस्ट)

लेखन तकनीक:

ट्यूटोरियल # 9: कारण और प्रभाव ग्राफ - डायनामिक टेस्ट केस राइटिंग तकनीक
ट्यूटोरियल # 10: राज्य संक्रमण परीक्षण तकनीक
ट्यूटोरियल # 11: ऑर्थोगोनल एरे टेस्टिंग टेक्नीक
ट्यूटोरियल # 12: त्रुटि अनुमान तकनीक
ट्यूटोरियल # 13: फील्ड वैलिडेशन टेबल (FVT) टेस्ट डिजाइन तकनीक

टेस्ट केस बनाम टेस्ट परिदृश्य:

ट्यूटोरियल # 14: टेस्ट केस बनाम टेस्ट परिदृश्य
ट्यूटोरियल # 15: टेस्ट प्लान, टेस्ट रणनीति और टेस्ट केस के बीच अंतर

स्वचालन:

ट्यूटोरियल # 16: स्वचालन परीक्षण के लिए सही टेस्ट मामलों का चयन कैसे करें
ट्यूटोरियल # 17: ऑटोमेशन लिपियों में मैनुअल टेस्ट के मामलों का अनुवाद कैसे करें

परीक्षण प्रबंधन उपकरण:

ट्यूटोरियल # 18: बेस्ट टेस्ट मैनेजमेंट टूल्स
ट्यूटोरियल # 19: टेस्ट केस मैनेजमेंट के लिए टेस्टलिंक
ट्यूटोरियल # 20: एचपी गुणवत्ता केंद्र का उपयोग करके टेस्ट केस बनाना और प्रबंधित करना
ट्यूटोरियल # 21: एएलएम / क्यूसी का उपयोग करके परीक्षण के मामलों को निष्पादित करना

डोमेन विशिष्ट मामले:

ट्यूटोरियल # 22: ईआरपी आवेदन के लिए परीक्षण के मामले
ट्यूटोरियल # 23: जावा आवेदन परीक्षण के मामले
ट्यूटोरियल # 24: सीमा मूल्य विश्लेषण और समानता विभाजन

इस श्रृंखला में पहले ट्यूटोरियल के साथ जारी रखें।

अनुशंसित उपकरण:

टेस्ट केस राइटिंग प्रक्रिया को जारी रखने से पहले, हम इस टेस्ट केस मैनेजमेंट टूल को डाउनलोड करने की सलाह देते हैं। इस ट्यूटोरियल में आपके टेस्ट केस लिखने की प्रक्रिया में आसानी होगी:

(1) TestRail

=> TestRail टेस्ट केस मैनेजमेंट टूल डाउनलोड करें

टेस्ट केस 728

# 2) TestMonitor

शीर्ष स्तर के ऑनलाइन टेस्ट प्रबंधन। क्रांतिकारी आसान।

TestMonitor हर संगठन के लिए एक एंड-टू-एंड टेस्ट मैनेजमेंट टूल है। परीक्षण के लिए एक सरल, सहज दृष्टिकोण। चाहे आप एंटरप्राइज़ सॉफ़्टवेयर लागू कर रहे हों, क्यूए की आवश्यकता हो, एक गुणवत्ता ऐप का निर्माण करना हो या बस अपने परीक्षण प्रोजेक्ट में मदद करने वाले हाथ की आवश्यकता हो, TestMonitor ने आपको कवर किया है।

परीक्षण करनेवाला

=> TestMonitor वेबसाइट पर जाएं

आप क्या सीखेंगे:

टेस्ट केस क्या है और टेस्ट केस कैसे लिखें?

प्रभावी मामलों को लिखना एक कौशल है। और आप इसे परीक्षण के तहत आवेदन के अनुभव और ज्ञान से सीख सकते हैं।

परीक्षण लिखने के बारे में बुनियादी निर्देशों के लिए, कृपया निम्नलिखित वीडियो देखें:

उपरोक्त संसाधनों से हमें परीक्षण लेखन प्रक्रिया की मूल बातें मिलनी चाहिए।

परीक्षण लेखन प्रक्रिया के स्तर:

  • स्तर 1: इस स्तर में, आप लिखेंगे उपलब्ध विनिर्देशन से मूल मामले और उपयोगकर्ता प्रलेखन।
  • लेवल 2: यह है व्यावहारिक चरण जिसमें लेखन मामले आवेदन के वास्तविक कार्यात्मक और सिस्टम प्रवाह पर निर्भर करते हैं।
  • स्तर 3: यह वह चरण है जिसमें आप कुछ मामलों को जोड़ेंगे और एक परीक्षण प्रक्रिया लिखें । परीक्षण प्रक्रिया कुछ भी नहीं है, लेकिन छोटे मामलों का एक समूह है, शायद अधिकतम 10।
  • स्तर 4: परियोजना का स्वचालन। यह सिस्टम के साथ मानव संपर्क को कम करेगा और इस प्रकार क्यूए प्रतिगमन परीक्षण के साथ व्यस्त रहने के बजाय परीक्षण करने के लिए वर्तमान में अद्यतन कार्यक्षमता पर ध्यान केंद्रित कर सकता है।

हम टेस्ट क्यों लिखते हैं?

मामलों को लिखने का मूल उद्देश्य है एक आवेदन के परीक्षण कवरेज को मान्य करने के लिए।

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

टेस्ट केस कैसे लिखें?

खेत:

  • टेस्ट केस आई.डी.
  • परीक्षण करने के लिए यूनिट: क्या सत्यापित किया जाए?
  • मान्यताओं
  • परीक्षण डेटा: चर और उनके मूल्य
  • निष्पादित किए जाने वाले चरण
  • अपेक्षित परिणाम
  • वास्तविक परिणाम
  • सफल - असफल
  • टिप्पणियाँ

टेस्ट केस स्टेटमेंट का मूल प्रारूप

सत्यापित करें
का उपयोग करते हुए (उपकरण का नाम, टैग का नाम, संवाद, आदि)
साथ में (शर्तेँ)
सेवा (क्या दिखाया गया है, दिखाया गया है, दिखाया गया है)

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

किसी भी आवेदन के लिए, आपको सभी प्रकार के परीक्षणों को कवर करने की आवश्यकता है:

  • क्रियात्मक मामले
  • नकारात्मक मामलों
  • सीमा मूल्य मामले

ये सब लिखते हुए अपने टीसी को सरल और समझने में आसान होना चाहिए ।

***********************************

टेस्ट लिखने के लिए टिप्स

सॉफ़्टवेयर परीक्षक (SQA / SQC व्यक्ति) की सबसे लगातार और प्रमुख गतिविधियों में से एक है, टेस्ट परिदृश्यों और मामलों को लिखना।

कुछ महत्वपूर्ण और महत्वपूर्ण कारक हैं जो इस प्रमुख गतिविधि से संबंधित हैं। आइए पहले हम उन कारकों के बारे में एक विहंगम दृष्टि डालें।

महत्वपूर्ण कारक शामिल लेखन प्रक्रिया:

क) टीसीएस नियमित संशोधन और अद्यतन के लिए प्रवण हैं:

हम लगातार बदलती दुनिया में रहते हैं और सॉफ्टवेयर के लिए भी अच्छा है। सॉफ़्टवेयर आवश्यकताएँ मामलों को सीधे प्रभावित करती हैं। जब भी आवश्यकताओं में परिवर्तन किया जाता है, टीसी को अद्यतन करने की आवश्यकता होती है।

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

इसके अलावा, प्रतिगमन परीक्षण के दौरान, कई फिक्सेस और / या रिपल्स की मांग संशोधित या नए टीसीएस हैं।

बी) टीसी परीक्षकों के बीच वितरण के लिए प्रवण हैं जो इन पर अमल करेंगे:

बेशक, शायद ही ऐसी स्थिति होती है जिसमें एक एकल परीक्षक सभी टीसी को निष्पादित करता है। आम तौर पर, कई परीक्षक होते हैं जो एक ही आवेदन के विभिन्न मॉड्यूल का परीक्षण करते हैं। इसलिए परीक्षण के तहत आवेदन के स्वामित्व वाले क्षेत्रों के अनुसार टीसी को परीक्षकों के बीच विभाजित किया जाता है।

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

ग) टीसी के क्लस्टरिंग और बैचिंग के लिए प्रवण हैं:

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

इसी तरह, ऑटो के व्यावसायिक तर्क के अनुसार, एक एकल टीसी कई परीक्षण स्थितियों में योगदान दे सकता है और एक परीक्षण स्थिति में कई टीसी शामिल हो सकते हैं।

डी) टीसी में अंतर-निर्भरता की प्रवृत्ति होती है:

टेस्ट मामलों में अंतर-निर्भरता की प्रवृत्ति होती है

यह TCs का एक दिलचस्प और महत्वपूर्ण व्यवहार है, जिसमें कहा गया है कि वे एक-दूसरे पर निर्भर हो सकते हैं। जटिल व्यावसायिक तर्क के साथ मध्यम से बड़े अनुप्रयोगों में, यह प्रवृत्ति अधिक दिखाई देती है।

किसी भी आवेदन का स्पष्ट क्षेत्र जहां यह व्यवहार निश्चित रूप से देखा जा सकता है, एक ही या अलग-अलग अनुप्रयोगों के विभिन्न मॉड्यूलों के बीच अंतर है। सीधे शब्दों में, जहां भी एक मॉड्यूल या एक से अधिक एप्लिकेशन एक-दूसरे से जुड़े होते हैं, एक ही व्यवहार टीसीएस में भी परिलक्षित होता है।

ई) टीसी डेवलपर्स के बीच वितरण के लिए प्रवण हैं (विशेषकर टेस्ट-संचालित विकास वातावरण में):

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

परीक्षण के मामले लेखन युक्तियाँ

प्रभावी टेस्ट लिखने के लिए टिप्स:

उपरोक्त 5 कारकों को ध्यान में रखते हुए, प्रभावी टीसी लिखने के लिए यहां कुछ सुझाव दिए गए हैं।

चलो शुरू करते हैं!!!

# 1) इसे सरल रखें लेकिन बहुत सरल नहीं; इसे जटिल बनाएं लेकिन बहुत जटिल नहीं:

यह कथन एक विरोधाभास लगता है। लेकिन, मैं वादा करता हूं कि ऐसा नहीं है। टीसी के सभी चरणों को परमाणु और सटीक रखें। अपेक्षित परिणामों के लिए सही अनुक्रम और सही मैपिंग के साथ चरणों का उल्लेख करें। परीक्षण का मामला आत्म-व्याख्यात्मक और समझने में आसान होना चाहिए। इसका मतलब है कि मैं इसे सरल बनाने के लिए।

अब, इसे जटिल बनाने के लिए इसे टेस्ट प्लान और अन्य टीसी के साथ एकीकृत करने का मतलब है। अन्य टीसी, प्रासंगिक कलाकृतियों, जीयूआई आदि का संदर्भ लें जहां और जब आवश्यक हो। लेकिन, इसे संतुलित तरीके से करें। एक एकल परीक्षण परिदृश्य को पूरा करने के लिए दस्तावेजों के ढेर में स्थानांतरित करने के लिए एक परीक्षक न बनाएं।

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

# 2) टेस्ट मामलों के दस्तावेज के बाद, परीक्षक के रूप में एक बार समीक्षा करें:

परीक्षण के मामलों

कभी यह न सोचें कि परीक्षा परिदृश्य के अंतिम टीसी को लिखने के बाद नौकरी की जाती है। प्रारंभ पर जाएं और सभी टीसी की एक बार समीक्षा करें, लेकिन टीसी लेखक या परीक्षण नियोजक की मानसिकता के साथ नहीं। एक परीक्षक के दिमाग के साथ सभी टीसी की समीक्षा करें। तर्कसंगत रूप से सोचें और अपने टीसी को चलाने की कोशिश करें।

मूल्यांकन करें कि सभी चरण और देखें कि क्या आपने एक स्पष्ट तरीके से इनका उल्लेख किया है और अपेक्षित परिणाम उन चरणों के अनुरूप हैं।

यह सुनिश्चित करें कि परीक्षण डेटा टीसी में निर्दिष्ट न केवल वास्तविक परीक्षकों के लिए संभव है, बल्कि वास्तविक समय के वातावरण के अनुसार भी है। सुनिश्चित करें कि टीसी के बीच कोई निर्भरता संघर्ष नहीं है और सत्यापित करें कि अन्य टीसीएस / कलाकृतियों / जीयूआई के सभी संदर्भ सटीक हैं। अन्यथा, परीक्षक बहुत परेशानी में पड़ सकते हैं।

# 3) साथ ही साथ परीक्षकों को आसानी से बांधे:

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

क्योंकि, जानबूझकर या अनजाने में, वे बार-बार एक ही परीक्षण डेटा का उपयोग कर सकते हैं और टीसीएस के निष्पादन के दौरान कुछ महत्वपूर्ण परीक्षण डेटा को अनदेखा किया जा सकता है।

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

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

# 4) एक योगदानकर्ता बनें:

एक योगदानकर्ता बनें

एफएस या डिज़ाइन दस्तावेज़ को कभी स्वीकार न करें जैसा कि यह है। आपका काम केवल एफएस के माध्यम से जाना और टेस्ट परिदृश्यों की पहचान करना नहीं है। क्यूए संसाधन होने के नाते, व्यवसाय में योगदान देने में कभी भी संकोच न करें और सुझाव दें यदि आपको लगता है कि आवेदन में कुछ सुधार किया जा सकता है।

डेवलपर्स को भी सुझाव दें, खासकर टीसी-संचालित विकास के माहौल में। ड्रॉप-डाउन सूची, कैलेंडर नियंत्रण, चयन-सूची, समूह रेडियो बटन, अधिक सार्थक संदेश, सावधानी, संकेत, उपयोगिता से संबंधित सुधार आदि का सुझाव दें।

क्यूए होने के नाते, बस परीक्षण न करें, लेकिन फर्क करें!

# 5) कभी भी अंतिम उपयोगकर्ता को न भूलें:

एंड यूज़र को कभी न भूलें

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

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

***********************************

टेस्ट केस डॉक्यूमेंटेशन में उत्कृष्टता कैसे प्राप्त करें

एक सॉफ्टवेयर टेस्टर होने के नाते, आप निश्चित रूप से मेरे साथ सहमत होंगे कि एक परिपूर्ण टेस्ट डॉक्यूमेंट के साथ आना वास्तव में एक चुनौतीपूर्ण कार्य है।

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

एक परीक्षक के रूप में, जब भी आपको परीक्षण प्रलेखन लिखने के लिए कहा जाता है, तो केवल एक तदर्थ तरीके से दूर शुरू न करें। दस्तावेज़ीकरण प्रक्रिया पर काम करने से पहले परीक्षण मामलों को लिखने के उद्देश्य को समझना बहुत महत्वपूर्ण है।

टेस्ट केस डॉक्यूमेंटेशन में उत्कृष्टता हासिल करें

परीक्षण हमेशा स्पष्ट और स्पष्ट होना चाहिए। उन्हें इस तरह से लिखा जाना चाहिए कि परीक्षक को प्रत्येक परीक्षण में परिभाषित चरणों का पालन करके पूर्ण परीक्षण करने में आसानी होती है।

इसके अलावा, परीक्षण केस दस्तावेज में संपूर्ण प्रदान करने के लिए आवश्यक के रूप में कई मामले होने चाहिए परीक्षण कवरेज । उदाहरण के लिए , आपको उन सभी संभावित परिदृश्यों के लिए परीक्षण को कवर करने का प्रयास करना चाहिए जो आपके सॉफ़्टवेयर एप्लिकेशन के भीतर हो सकते हैं।

उपरोक्त बिंदुओं को ध्यान में रखते हुए, अब मैं आपको एक दौरे के माध्यम से बताता हूं कि टेस्ट डॉक्यूमेंटेशन में उत्कृष्टता कैसे प्राप्त करें।

बूटस्ट्रैप अनुभवी के लिए साक्षात्कार प्रश्न और उत्तर

उपयोगी टिप्स और ट्रिक्स

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

# 1) क्या आपका टेस्ट डॉक्यूमेंट गुड शेप में है?

अपने परीक्षण दस्तावेज़ को व्यवस्थित करने का सबसे अच्छा और सरल तरीका यह है कि इसे कई एकल उपयोगी वर्गों में विभाजित किया जाए। संपूर्ण परीक्षण को कई परीक्षण परिदृश्यों में विभाजित करें। फिर प्रत्येक परिदृश्य को कई परीक्षणों में विभाजित करें। अंत में, प्रत्येक मामले को कई परीक्षण चरणों में विभाजित करें।

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

# 2) नकारात्मक मामलों को कवर करने के लिए मत भूलना

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

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

# 3) परमाणु परीक्षण कदम है

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

# 4) टेस्ट को प्राथमिकता दें

हम अक्सर एक आवेदन के लिए परीक्षण खत्म करने के लिए कड़े समय है। इस मामले में, हम सॉफ़्टवेयर की कुछ महत्वपूर्ण कार्यक्षमता और पहलुओं का परीक्षण करने से चूक सकते हैं। इससे बचने के लिए, आपको इसे प्रलेखित करते समय प्रत्येक परीक्षण के साथ प्राथमिकता को टैग करना चाहिए।

परीक्षण की प्राथमिकता को परिभाषित करने के लिए आप किसी भी एन्कोडिंग का उपयोग कर सकते हैं। आमतौर पर 3 स्तरों में से किसी का उपयोग करना बेहतर होता है, उच्च, मध्यम और निम्न , या 1, 50 और 100. इसलिए, जब आपके पास एक सख्त समयरेखा होती है, तो आपको पहले सभी उच्च प्राथमिकता वाले परीक्षणों को पूरा करना चाहिए और फिर मध्यम और निम्न प्राथमिकता वाले परीक्षणों में जाना चाहिए।

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

# 5) अनुक्रम मामले

पुष्टि करें कि क्या परीक्षण में चरणों का क्रम बिल्कुल सही है। कदमों का गलत क्रम भ्रम पैदा कर सकता है। अधिमानतः, चरणों को ऐप को किसी विशेष परिदृश्य के लिए ऐप से बाहर निकलने तक पूरे अनुक्रम को भी परिभाषित करना चाहिए जिसे परीक्षण किया जा रहा है।

# 6) टिप्पणी में टाइमस्टैम्प और परीक्षक नाम जोड़ें

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

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

# 7) ब्राउज़र विवरण शामिल करें

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

# 8) दस्तावेज़ में दो अलग-अलग शीट - 'बग' और 'सारांश' रखें

यदि आप एक एक्सेल में दस्तावेज कर रहे हैं, तो वर्कबुक की पहली दो शीट सारांश और बग होनी चाहिए। सारांश शीट को परीक्षा परिदृश्य को सारांशित करना चाहिए और बग शीट को परीक्षण के दौरान सामने आने वाले सभी मुद्दों को सूचीबद्ध करना चाहिए। इन दो शीटों को जोड़ने का महत्व यह है कि यह दस्तावेज़ के पाठक / उपयोगकर्ता को परीक्षण की स्पष्ट समझ देगा।

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

परीक्षण दस्तावेज़ को सर्वोत्तम संभव परीक्षण कवरेज, उत्कृष्ट पठनीयता प्रदान करनी चाहिए और पूरे एक मानक प्रारूप का पालन करना चाहिए।

हम टेस्ट केस डॉक्यूमेंट के संगठन के रूप में सिर्फ कुछ आवश्यक टिप्स को ध्यान में रखते हुए, टीसीएस को प्राथमिकता देते हुए, टीसी को प्राथमिकता देने के लिए, सभी आवश्यक विवरणों को शामिल करते हुए, टीसी को निष्पादित करने के लिए और स्पष्ट और स्पष्ट परीक्षण चरणों को प्रदान करके, उत्कृष्टता प्राप्त कर सकते हैं। आदि के रूप में ऊपर चर्चा की।

सॉफ्टवेयर परीक्षण में स्वचालन सर्वोत्तम प्रथाओं

***********************************

टेस्ट लिखने के लिए कैसे नहीं

हम अपना अधिकांश समय लेखन, समीक्षा, निष्पादन या इन्हें बनाए रखने में बिताते हैं। यह काफी दुर्भाग्यपूर्ण है कि परीक्षण भी सबसे अधिक त्रुटि वाले हैं। समझ में अंतर, संगठन परीक्षण अभ्यास, समय की कमी आदि कुछ ऐसे कारण हैं जिनसे हम अक्सर ऐसे परीक्षण देखते हैं जो वांछित होने के लिए बहुत कुछ छोड़ देते हैं।

इस विषय पर हमारी साइट पर बहुत सारे लेख हैं, लेकिन यहां देखेंगे परीक्षण मामलों को लिखने के लिए कैसे नहीं - विशिष्ट, गुणवत्ता और प्रभावी परीक्षण बनाने में कुछ सुझाव जो महत्वपूर्ण होंगे।

आइए पढ़ते हैं और कृपया ध्यान दें कि ये युक्तियां नए और अनुभवी परीक्षक दोनों के लिए हैं।

परीक्षण के मामले कैसे नहीं लिखें

3 टेस्ट मामलों में सबसे आम समस्याएं

  1. समग्र कदम
  2. आवेदन व्यवहार अपेक्षित व्यवहार के रूप में लिया जाता है
  3. एक मामले में कई स्थितियां

इन तीनों को परीक्षण लेखन प्रक्रिया में सामान्य समस्याओं की मेरी शीर्ष 3 सूची में होना चाहिए।

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

आइए इसे प्राप्त करें और हर एक पर विस्तार से चर्चा करें:

(१) कम्पोजिट स्टेप्स

सबसे पहले, एक समग्र कदम क्या है?

उदाहरण के लिए, आप बिंदु A से बिंदु B तक दिशा-निर्देश दे रहे हैं: यदि आप कहते हैं कि 'XYZ स्थान पर जाएं और फिर ABC में जाएं' तो यह बहुत मायने नहीं रखता है, क्योंकि यहां हम खुद को सोच पाते हैं - 'मैं कैसे करूं पहले स्थान पर XYZ में पहुंचें ”- इसके बजाय“ यहां से बाएं मुड़ें और 1 मील जाएं, फिर शुरू करें, फिर Rd पर दाएं मुड़ें। कोई 11 XYZ पर आने के लिए “बेहतर परिणाम प्राप्त कर सकता है।

ठीक वही नियम परीक्षण और उसके चरणों पर भी लागू होते हैं।

उदाहरण के लिए मैं Amazon.com के लिए एक परीक्षण लिख रहा हूं - किसी भी उत्पाद के लिए एक आदेश दें।

निम्नलिखित मेरे परीक्षण चरण हैं (नोट: मैं केवल चरण लिख रहा हूं और परीक्षण के अन्य सभी भागों जैसे अपेक्षित परिणाम नहीं है)

सेवा मेरे । Amazon.com लॉन्च करें
ख । स्क्रीन के शीर्ष पर 'खोज' फ़ील्ड में उत्पाद कीवर्ड / नाम दर्ज करके एक उत्पाद खोजें।
सी । प्रदर्शित खोज परिणामों से, पहले वाले को चुनें।
घ । उत्पाद विवरण पृष्ठ पर Add to Cart पर क्लिक करें।
है । चेकआउट और भुगतान।
च । आदेश की पुष्टि पृष्ठ की जाँच करें।

अब, क्या आप पहचान सकते हैं कि इनमें से कौन सा एक संयुक्त कदम है? राइट- स्टेप (e)

याद रखें, परीक्षण हमेशा 'कैसे' के बारे में होते हैं इसलिए परीक्षण करना ज़रूरी है कि आपके परीक्षण में 'चेक आउट और भुगतान कैसे करें' के सटीक चरणों को लिखना महत्वपूर्ण है।

इसलिए, उपरोक्त मामला नीचे लिखे जाने पर अधिक प्रभावी है:

सेवा मेरे । Amazon.com लॉन्च करें
ख । स्क्रीन के शीर्ष पर 'खोज' फ़ील्ड में उत्पाद कीवर्ड / नाम दर्ज करके एक उत्पाद खोजें।
सी । प्रदर्शित खोज परिणामों से, पहले वाले को चुनें।
घ । उत्पाद विवरण पृष्ठ पर Add to Cart पर क्लिक करें।
है । शॉपिंग कार्ट पेज में Checkout पर क्लिक करें।
च । CC जानकारी, शिपिंग और बिलिंग जानकारी दर्ज करें।
जी । Checkout पर क्लिक करें।
एच । आदेश की पुष्टि पृष्ठ की जाँच करें।

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

# 2) आवेदन व्यवहार अपेक्षित व्यवहार के रूप में लिया जाता है

अधिक से अधिक परियोजनाओं को इन दिनों इस स्थिति से निपटना है।

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

यह तब तक हानिरहित है जब तक आप एक खुले दिमाग रखते हैं और इस उम्मीद को बनाए रखते हैं कि - 'ऑटो त्रुटिपूर्ण हो सकता है'। यह केवल तभी है जब आप यह नहीं सोचते कि यह है, चीजें बुरी तरह से काम करती हैं। हमेशा की तरह, हम उदाहरणों को बात करने देंगे।

यदि निम्नलिखित पृष्ठ आप के लिए परीक्षण चरणों को लिख / डिजाइन कर रहे हैं:

परीक्षण मामलों के लिए युक्तियाँ

मामला एक:

यदि मेरे परीक्षण मामले के चरण नीचे दिए गए हैं:

  1. शॉपिंग साइट लॉन्च करें।
  2. शिपिंग और रिटर्न पर क्लिक करें- अपेक्षित परिणाम: शिपिंग और रिटर्न पेज को 'अपनी जानकारी यहां डालें' और 'जारी रखें' बटन के साथ प्रदर्शित किया जाता है।

फिर, यह गलत है।

केस 2:

  1. शॉपिंग साइट लॉन्च करें।
  2. शिपिंग पर क्लिक करें और वापस लौटें।
  3. Enter इस स्क्रीन में मौजूद ऑर्डर नंबर 'टेक्स्ट बॉक्स दर्ज करें, क्रम संख्या दर्ज करें।
  4. जारी रखें पर क्लिक करें- अपेक्षित परिणाम: शिपिंग और रिटर्न से संबंधित आदेश का विवरण प्रदर्शित किया जाता है।

केस 2 एक बेहतर परीक्षण मामला है क्योंकि भले ही संदर्भ एप्लिकेशन गलत तरीके से व्यवहार करता है, हम इसे केवल एक दिशानिर्देश के रूप में लेते हैं, आगे अनुसंधान करते हैं और प्रत्याशित सही कार्यक्षमता के अनुसार अपेक्षित व्यवहार लिखते हैं।

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

# 3) एक मामले में कई शर्तें

परीक्षण मेम

एक बार फिर से आइए जानें उदाहरण ।

नीचे दिए गए परीक्षण चरणों पर एक नज़र डालें: निम्नलिखित एक लॉगिन फ़ंक्शन के लिए एक परीक्षण के भीतर परीक्षण चरण हैं।

ए। मान्य विवरण दर्ज करें और सबमिट पर क्लिक करें।
बी। उपयोगकर्ता नाम फ़ील्ड को खाली छोड़ दें। सबमिट पर क्लिक करें।
सी। पासवर्ड फ़ील्ड खाली छोड़ दें और सबमिट करें पर क्लिक करें।
डी पहले से ही लॉग इन यूजरनेम / पासवर्ड चुनें और सबमिट पर क्लिक करें।

4 अलग-अलग मामलों में जो होना था वह एक में संयुक्त है। आप सोच रहे होंगे- इसमें गलत क्या है? यह बहुत सारे प्रलेखन को बचा रहा है और मैं 4 में क्या कर सकता हूं, मैं 1-1 में कर रहा हूं क्या यह महान नहीं है? खैर, काफी नहीं। कारण?

पढ़ते रहिये:

  • क्या होगा अगर कोई एक स्थिति विफल हो जाती है - हमें पूरे परीक्षण को 'असफल' के रूप में चिह्नित करना होगा। यदि हम पूरे मामले को 'विफल' मान लेते हैं, तो इसका मतलब है कि सभी 4 स्थितियाँ काम नहीं कर रही हैं, जो वास्तव में सही नहीं है।
  • टेस्ट के लिए एक प्रवाह होना चाहिए। पूर्वगामी से चरण 1 तक और चरणों के माध्यम से सभी। यदि मैं इस मामले का अनुसरण करता हूं, तो चरण (ए) में, यदि यह सफल होता है, तो मुझे पृष्ठ पर लॉग इन किया जाएगा, जहां 'लॉगिन' विकल्प अब उपलब्ध नहीं है। इसलिए जब मुझे स्टेप मिलता है (बी) - परीक्षक उपयोगकर्ता नाम दर्ज करने के लिए कहां जा रहा है? तुम देखते हो, प्रवाह टूट गया है।

इसलिये, मॉड्यूलर परीक्षण लिखें । यह बहुत काम की बात लगती है लेकिन आपके लिए यह सब कुछ अलग करना है और हमारे साथ काम करने के लिए हमारे सबसे अच्छे दोस्त Ctrl + C और Ctrl + V का उपयोग करना है। :)

***********************************

टेस्ट केस एफिशिएंसी कैसे सुधारें

सॉफ़्टवेयर परीक्षणकर्ताओं को सॉफ़्टवेयर विकास चरण के पहले चरण से अपने परीक्षण लिखने चाहिए, जो सॉफ़्टवेयर आवश्यकताओं के चरण के दौरान सबसे अच्छे हों।

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

परीक्षण मामले की दक्षता

टेस्ट लेखन के लिए दस्तावेज़ संग्रह

# 1) उपयोगकर्ता आवश्यकताएँ दस्तावेज़

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

# 2) बिजनेस यूसेज केस डॉक्यूमेंट

इस दस्तावेज़ का विवरण उदाहरण व्यावसायिक दृष्टिकोण से कार्यात्मक आवश्यकताओं का परिदृश्य। यह दस्तावेज़ व्यावसायिक अभिनेताओं (या सिस्टम), लक्ष्यों, पूर्व-स्थितियों, पोस्ट-शर्तों, बुनियादी प्रवाह, वैकल्पिक प्रवाह, विकल्प, आवश्यकताओं के तहत प्रत्येक और प्रत्येक व्यवसाय प्रवाह के अपवादों को शामिल करता है।

# 3) कार्यात्मक आवश्यकताएँ दस्तावेज़

यह दस्तावेज़ आवश्यकताओं के तहत सिस्टम के लिए प्रत्येक सुविधा की कार्यात्मक आवश्यकताओं का विवरण देता है।

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

# 4) सॉफ्टवेयर परियोजना योजना (वैकल्पिक)

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

# 5) क्यूए / टेस्ट प्लान

इस दस्तावेज़ में गुणवत्ता प्रबंधन प्रणाली, प्रलेखन मानकों, परिवर्तन नियंत्रण तंत्र, महत्वपूर्ण मॉड्यूल, और कार्यक्षमता, कॉन्फ़िगरेशन प्रबंधन प्रणाली, परीक्षण योजना, दोष ट्रैकिंग, स्वीकृति मानदंड आदि का विवरण है।

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

वास्तविक उदाहरण

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

टेस्ट केस दक्षता २

# 1) किसी भी परीक्षण के मामले की प्रक्रिया के लिए पहला दृष्टिकोण एक स्क्रीन प्रोटोटाइप (या तार-फ्रेम) प्राप्त करना होगा जैसा कि ऊपर उपलब्ध है, यदि उपलब्ध हो। यह कुछ कार्यात्मकताओं के लिए उपलब्ध नहीं हो सकता है और विकास के पहले चरणों में एक प्रोटोटाइप को डिजाइन करने की महत्वपूर्णता पर निर्भर करता है।

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

#दो) इसके बाद द कार्यात्मक आवश्यकताओं विनिर्देशों । यह संगठन की प्रक्रिया पर निर्भर करता है, यह कई दस्तावेजों के एक सूट में उपलब्ध होगा।

इसलिए, मामलों को लिखने के लिए सबसे अच्छा दस्तावेज तय करें, या तो यह एक उपयोगकर्ता की आवश्यकता का दस्तावेज हो सकता है या एक कार्यात्मक आवश्यकताओं के विनिर्देशों (या यहां तक ​​कि एसआरएस दस्तावेज़ भी हो सकता है अगर यह परीक्षण टीम द्वारा आराम से समझा जा सकता है) जो चयनित का पूर्ण कार्यात्मक प्रवाह देगा परीक्षण किया जाना है।

# 3) एक बार जब स्क्रीन प्रोटोटाइप और कार्यात्मक विनिर्देश जगह में होते हैं, तो परीक्षक को निम्नलिखित दृष्टिकोण और मानदंडों के साथ मामलों को लिखना शुरू करना चाहिए।

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

4) अंत में, 'रखें' बीएओ मंत्र ', बोले तो i) मूल प्रवाह ii) वैकल्पिक प्रवाह iii) विकल्प और iv) अपवाद कार्यात्मक प्रवाह की पूरी कवरेज के लिए और परीक्षण किया जाने वाला फीचर। हर अवधारणा को सकारात्मक और नकारात्मक परीक्षणों पर लागू किया जाना चाहिए।

उदाहरण के लिए, हमें ऊपर नमूना लॉगिन स्क्रीन के लिए सरल BAOE दृष्टिकोण देखने दें।

  • मूल प्रवाह: किसी भी ब्राउज़र में लॉगिन का URL पथ दर्ज करें और आवश्यक जानकारी दर्ज करें और आवेदन में लॉगिन करें।
  • वैकल्पिक प्रवाह: मोबाइल डिवाइस पर एप्लिकेशन इंस्टॉल करें और आवश्यक जानकारी दर्ज करें और एप्लिकेशन में लॉगिन करें।
  • विकल्प: समान लॉगिन स्क्रीन पर आने के लिए क्या विकल्प उपलब्ध हैं? उदाहरण के लिए, एप्लिकेशन में लॉगिन करने के बाद, 'लॉगआउट' पर क्लिक करने से एक ही स्क्रीन आ सकती है या यदि सत्र समय समाप्त या सत्र समाप्त हो गया है, तो उपयोगकर्ता लॉगिन स्क्रीन पर आ सकता है।
  • अपवाद: यदि मेरे परीक्षण नकारात्मक हैं तो क्या अपवाद हैं? उदाहरण के लिए, यदि लॉगिन स्क्रीन में गलत क्रेडेंशियल दर्ज किए गए हैं, तो उपयोगकर्ता को एक त्रुटि संदेश मिलेगा या कोई कार्रवाई संबद्ध नहीं होगी।

हाथ में यह सब जानकारी के साथ, हम पूर्ण स्क्रीन के साथ एक प्रारूप में टीसीएस लिखना शुरू करते हैं, पूर्ण कवरेज और ट्रैसबिलिटी के साथ और विस्तृत जानकारी के साथ। तार्किक अनुक्रम और identify की पहचान करने की संख्या टेस्ट केस आईडी ' परीक्षण मामलों के त्वरित पहचान निष्पादन इतिहास के लिए बहुत उपयोगी होगा।

यह भी पढ़ें=> वेब और डेस्कटॉप अनुप्रयोगों के लिए परीक्षण मामलों का उपयोग करने के लिए तैयार 180+ नमूना।

टेस्ट केस डॉक्यूमेंट

टेस्ट केस दक्षता 1

परीक्षा निष्पादन इतिहास

परीक्षा निष्पादन इतिहास २

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

यह भी पढ़ें=> उदाहरण के साथ नमूना परीक्षण केस टेम्पलेट।

परीक्षण के मामलों

इस दस्तावेज़ की सादगी और पठनीयता में आसानी के लिए, हम नीचे विस्तार से लॉगिन स्क्रीन के लिए परीक्षणों के पुन: उत्पन्न, अपेक्षित और वास्तविक व्यवहार के बारे में लिखें।

ध्यान दें : इस टेम्पलेट के अंत में वास्तविक व्यवहार कॉलम जोड़ें।

ऐसा न करें।प्रजनन के चरणअपेक्षित व्यवहार
।।पंजीकरण लिंक पर क्लिक करेंलिंक पर क्लिक करके उपयोगकर्ता को संबंधित स्क्रीन पर ले जाना चाहिए।
१।एक ब्राउज़र खोलें और लॉगिन स्क्रीन के लिए URL दर्ज करें।लॉगिन स्क्रीन प्रदर्शित की जानी चाहिए।
दो।एंड्रॉइड फोन में ऐप इंस्टॉल करें और इसे खोलें।लॉगिन स्क्रीन प्रदर्शित की जानी चाहिए।
३।लॉगिन स्क्रीन खोलें और उपलब्ध ग्रंथों की सही तरीके से वर्तनी की जांच करें।संबंधित पाठ बॉक्स से पहले be उपयोगकर्ता का नाम ’और Name पासवर्ड’ पाठ प्रदर्शित किया जाना चाहिए। लॉगिन बटन पर कैप्शन ‘लॉगइन’ होना चाहिए। ‘पासवर्ड भूल गए?’ और Password पंजीकरण ’लिंक के रूप में उपलब्ध होना चाहिए।
चार।उपयोगकर्ता नाम बॉक्स में पाठ दर्ज करें।पाठ माउस क्लिक द्वारा दर्ज किया जा सकता है या टैब का उपयोग करके फ़ोकस किया जा सकता है।
५।पासवर्ड बॉक्स में पाठ दर्ज करें।पाठ माउस क्लिक द्वारा दर्ज किया जा सकता है या टैब का उपयोग करके फ़ोकस किया जा सकता है।
६।पासवर्ड भूल गए? संपर्क।लिंक पर क्लिक करके उपयोगकर्ता को संबंधित स्क्रीन पर ले जाना चाहिए।
।।उपयोगकर्ता नाम और पासवर्ड दर्ज करें और लॉगिन बटन पर क्लिक करें।लॉगिन बटन पर क्लिक करके संबंधित स्क्रीन या एप्लिकेशन पर ले जाना चाहिए।
९।डेटाबेस पर जाएं और इनपुट क्रेडेंशियल्स के खिलाफ सही टेबल नाम को सत्यापित किया गया है।तालिका नाम को मान्य किया जाना चाहिए और सफल या विफलता लॉगिन के लिए एक स्थिति ध्वज को अद्यतन किया जाना चाहिए।
१०।उपयोगकर्ता नाम और पासवर्ड बक्से में किसी भी पाठ को दर्ज किए बिना लॉगिन पर क्लिक करें।क्लिक करें लॉगिन बटन एक संदेश बॉक्स को सचेत करना चाहिए Login उपयोगकर्ता नाम और पासवर्ड अनिवार्य है ’।
ग्यारह।उपयोगकर्ता नाम बॉक्स में पाठ दर्ज किए बिना लॉगिन पर क्लिक करें, लेकिन पासवर्ड बॉक्स में पाठ दर्ज करें।एक संदेश बॉक्स alert पासवर्ड अनिवार्य है ’पर लॉग इन बटन पर क्लिक करना चाहिए।
१२।पासवर्ड बॉक्स में पाठ दर्ज किए बिना लॉगिन पर क्लिक करें, लेकिन उपयोगकर्ता नाम बॉक्स में पाठ दर्ज करें।क्लिक करें लॉगिन बटन एक संदेश बॉक्स को सचेत करना चाहिए Login उपयोगकर्ता नाम अनिवार्य है ’।
१३।उपयोगकर्ता नाम और पासवर्ड बॉक्स में अधिकतम अनुमत पाठ दर्ज करें।अधिकतम स्वीकृत 30 वर्णों को स्वीकार करना चाहिए।
१४।विशेष वर्णों से शुरू होने वाले उपयोगकर्ता नाम और पासवर्ड दर्ज करें।विशेष वर्णों से शुरू होने वाले पाठ को स्वीकार नहीं करना चाहिए, जिसे पंजीकरण में अनुमति नहीं है।
पंद्रह।रिक्त स्थानों से शुरू होने वाले उपयोगकर्ता नाम और पासवर्ड दर्ज करें।रिक्त स्थानों के साथ पाठ को स्वीकार नहीं करना चाहिए, जिसे पंजीकरण में अनुमति नहीं है।
१६।पासवर्ड फ़ील्ड में पाठ दर्ज करें।इसके बजाय वास्तविक पाठ प्रदर्शित नहीं करना चाहिए इसके बजाय तारांकन चिह्न * प्रदर्शित करना चाहिए।
१।।लॉगइन पेज को रिफ्रेश करें।पृष्ठ को उपयोगकर्ता नाम और पासवर्ड फ़ील्ड दोनों रिक्त के साथ ताज़ा किया जाना चाहिए।
१।।उपयोगकर्ता नाम दर्ज करें।ब्राउज़र ऑटो फिल सेटिंग्स पर निर्भर करता है, पहले दर्ज किए गए उपयोगकर्ता नाम ड्रॉपडाउन के रूप में प्रदर्शित होने चाहिए।
१ ९।पासवर्ड दर्ज करे।ब्राउज़र ऑटो भरण सेटिंग पर निर्भर करता है, पहले दर्ज किए गए पासवर्ड को एक ड्रॉपडाउन के रूप में प्रदर्शित नहीं किया जाना चाहिए।
बीस।टैब का उपयोग करके पासवर्ड भूल गए लिंक पर ध्यान केंद्रित करें।माउस क्लिक और एंटर कुंजी दोनों प्रयोग करने योग्य होनी चाहिए।
इक्कीस।टैब का उपयोग करके फ़ोकस को पंजीकरण लिंक पर ले जाएं।माउस क्लिक और एंटर कुंजी दोनों प्रयोग करने योग्य होनी चाहिए।
२२।लॉगइन पेज को रिफ्रेश करें और एंटर की दबाएं।लॉगिन बटन को फोकस किया जाना चाहिए और संबंधित कार्रवाई को निकाल दिया जाना चाहिए।
२। ३।लॉगइन पेज को रिफ्रेश करें और टैब की दबाएं।लॉगिन स्क्रीन में पहला फोकस उपयोगकर्ता नाम बॉक्स होना चाहिए।
२४।उपयोगकर्ता और पासवर्ड दर्ज करें और 10 मिनट के लिए लॉगिन पृष्ठ निष्क्रिय छोड़ दें।संदेश बॉक्स चेतावनी Exp सत्र समाप्त हो गया है, उपयोगकर्ता नाम और पासवर्ड फिर से दर्ज करें ’को उपयोगकर्ता नाम और पासवर्ड दोनों क्षेत्रों के साथ प्रदर्शित किया जाना चाहिए।
२५।Chrome, Firefox और Internet Explorer ब्राउज़र में लॉगिन URL दर्ज करें।समान लॉगिन स्क्रीन को लुक और फील पर बहुत अधिक विचलन के बिना प्रदर्शित किया जाना चाहिए और टेक्स्ट और फॉर्म नियंत्रण को संरेखित करना चाहिए।
२६।लॉगिन क्रेडेंशियल दर्ज करें और क्रोम, फ़ायरफ़ॉक्स और इंटरनेट एक्सप्लोरर ब्राउज़र में लॉगिन गतिविधि की जांच करें।लॉगिन बटन की कार्रवाई सभी ब्राउज़रों में एक और समान होनी चाहिए।
२।।भूल गए पासवर्ड की जाँच करें और क्रोम, फ़ायरफ़ॉक्स और इंटरनेट एक्सप्लोरर ब्राउज़रों में पंजीकरण लिंक नहीं टूटा है।दोनों लिंक को सभी ब्राउज़रों में रिश्तेदार स्क्रीन पर ले जाना चाहिए।
२।।एंड्रॉइड मोबाइल फोन में लॉगिन कार्यक्षमता ठीक से काम कर रही है।लॉगिन फीचर उसी तरह से काम करना चाहिए जिस तरह यह वेब संस्करण में उपलब्ध है।
२ ९।टैब और आईफ़ोन में लॉगिन कार्यक्षमता ठीक से काम कर रही है।लॉगिन फीचर उसी तरह से काम करना चाहिए जिस तरह यह वेब संस्करण में उपलब्ध है।
३०।लॉगिन स्क्रीन की जांच करें सिस्टम के समवर्ती उपयोगकर्ताओं को अनुमति देता है और सभी उपयोगकर्ता बिना विलंब के 5-10 सेकंड के भीतर लॉगिन स्क्रीन प्राप्त कर रहे हैं।यह ऑपरेटिंग सिस्टम और ब्राउज़रों के कई संयोजन का उपयोग करके भौतिक या वस्तुतः प्राप्त किया जाना चाहिए या कुछ प्रदर्शन / लोड परीक्षण उपकरण का उपयोग करके प्राप्त किया जा सकता है।

डेटा संग्रह का परीक्षण करें

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

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

ऊपर लिखे गए परीक्षणों के लिए एक नमूना परीक्षण डेटा दस्तावेज़ ढूंढें, जो बदले में इस बात पर मददगार होगा कि हम उस डेटा को कितनी प्रभावी रूप से एकत्र कर सकते हैं जो परीक्षण निष्पादन के समय हमारी नौकरी को कम कर देगा।

हाँ नहीटेस्ट डेटा का उद्देश्यवास्तविक परीक्षण डेटा
।।सभी छोटे पात्रों के साथ उपयोगकर्ता नाम और पासवर्ड का परीक्षण करेंव्यवस्थापक (व्यवस्थापन २०१५)
१।उचित उपयोगकर्ता नाम और पासवर्ड का परीक्षण करेंप्रशासक (एडमिन २०१५)
दो।उपयोगकर्ता नाम और पासवर्ड की अधिकतम लंबाई का परीक्षण करेंमुख्य प्रणाली के प्रशासक (admin2015admin2015admin2015admin)
३।उपयोगकर्ता नाम और पासवर्ड के लिए रिक्त स्थान का परीक्षण करेंउपयोगकर्ता नाम और पासवर्ड के लिए अंतरिक्ष कुंजी का उपयोग करके रिक्त स्थान दर्ज करें
चार।अनुचित उपयोगकर्ता नाम और पासवर्ड का परीक्षण करेंव्यवस्थापक (सक्रिय) (digx ## $ taxk209)
५।के बीच अनियंत्रित रिक्त स्थान के साथ उपयोगकर्ता नाम और पासवर्ड का परीक्षण करें।व्यवस्थापक ट्रेटर (व्यवस्थापक 2015)
६।विशेष वर्णों से शुरू होने वाले उपयोगकर्ता नाम और पासवर्ड का परीक्षण करें$% # @ # $ व्यवस्थापक (% # * # ** # व्यवस्थापक)
।।सभी पूंजी पात्रों के साथ उपयोगकर्ता नाम और पासवर्ड का परीक्षण करेंव्यवस्थापक (ADMIN2015)
९।एक ही समय में कई सिस्टम के साथ एक ही उपयोगकर्ता नाम और पासवर्ड के साथ लॉगिन का परीक्षण करें।व्यवस्थापक (admin2015) - एक ही मशीन में क्रोम के लिए और ऑपरेटिंग सिस्टम विंडोज एक्सपी, विंडोज 7, विंडोज 8 और विंडोज सर्वर के साथ अलग मशीन।

व्यवस्थापक (admin2015) - एक ही मशीन में फ़ायरफ़ॉक्स के लिए और ऑपरेटिंग सिस्टम के साथ अलग मशीन विंडोज एक्सपी, विंडोज 7, विंडोज 8 और विंडोज सर्वर।

प्रशासक (admin2015) - एक ही मशीन में इंटरनेट एक्सप्लोरर के लिए और ऑपरेटिंग सिस्टम विंडोज एक्सपी, विंडोज 7, विंडोज 8 और विंडोज सर्वर के साथ अलग मशीन।
१०।मोबाइल एप्लिकेशन में उपयोगकर्ता नाम और पासवर्ड के साथ लॉगिन का परीक्षण करें।प्रशासक (admin2015) - एंड्रॉइड मोबाइल्स, आईफ़ोन और टैबलेट में सफारी और ओपेरा के लिए।

***********************************

परीक्षण मामलों के मानकीकरण का महत्व

इस व्यस्त दुनिया में, कोई भी समान स्तर की रुचि और ऊर्जा के साथ दिन-प्रतिदिन दोहराता नहीं है। विशेष रूप से, मुझे एक ही कार्य को बार-बार करने का शौक नहीं है। मुझे चीजों को प्रबंधित करना और समय की बचत करना पसंद है। आईटी में कोई भी ऐसा होना चाहिए।

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

टेस्ट केस का फिर से इस्तेमाल

यह सवाल जो मुझे हमेशा परेशान करता है, वह यह है कि: 'यदि अधिकांश एप्लिकेशन समान हैं, उदाहरण के लिए: जैसे कि खुदरा साइटें, जिन्हें पहले एक हजार बार परीक्षण किया जा चुका है,' हमें स्क्रैच से किसी अन्य खुदरा साइट के लिए परीक्षण मामलों को लिखने की आवश्यकता क्यों है? ” क्या यह मौजूदा परीक्षण स्क्रिप्ट को बाहर निकालकर एक टन समय बचा सकता है जो कि पिछले रिटेल साइट का परीक्षण करने के लिए इस्तेमाल किया गया था?

निश्चित रूप से, कुछ छोटे मोड़ हो सकते हैं जो हमें करने पड़ सकते हैं, लेकिन कुल मिलाकर यह आसान, कुशल, समय और पैसा बचाने वाला भी है और इस तरह हमेशा परीक्षकों के ब्याज स्तर को ऊंचा रखने में मदद करता है। एक ही परीक्षण मामलों को बार-बार लिखना, समीक्षा करना और बनाए रखना किसे पसंद है, है ना? मौजूदा परीक्षणों का पुन: उपयोग करने से यह काफी हद तक हल हो सकता है और आपके क्लाइंट को यह स्मार्ट और तार्किक भी लगेगा।

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

टेस्ट मामलों का पुन: उपयोग करने के कारण

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

#दो) अधिकांश परियोजनाएं मौजूदा कार्यक्षमता में सिर्फ वृद्धि या परिवर्तन हैं।

# 3) सामग्री प्रबंधन प्रणाली जो स्थिर और गतिशील तरीकों से छवि अपलोड के लिए स्लॉट को परिभाषित करती है, सभी वेबसाइटों के लिए भी सामान्य है।

# 4) खुदरा वेबसाइटें हैं सीएसआर (ग्राहक सेवा) प्रणाली भी।

# 5) जेडीए का उपयोग कर बैकएंड सिस्टम और वेयरहाउस एप्लिकेशन का उपयोग सभी वेबसाइटों द्वारा भी किया जाता है।

# 6) कुकीज़, टाइमआउट और सुरक्षा की अवधारणा भी आम है।

# 7) वेब-आधारित परियोजनाओं में अक्सर आवश्यकता परिवर्तन की संभावना होती है।

# 8) परीक्षण के प्रकार जरूरत ब्राउज़र की तरह आम हैं अनुकूलता परीक्षण , प्रदर्शन का परीक्षण , सुरक्षा परीक्षण

तुम देखो, वहाँ बहुत कुछ है जो समान और समान है।

यह कहने के बाद कि पुन: प्रयोज्यता एक रास्ता है, कभी-कभी संशोधन स्वयं अधिक या कम समय ले सकते हैं या नहीं कर सकते हैं। कभी-कभी किसी को यह महसूस हो सकता है कि खरोंच से शुरू करना बेहतर है ताकि आप इसे संशोधित कर सकें।

यह प्रत्येक सामान्य कार्यक्षमता के लिए मानक परीक्षण मामलों का एक सेट बनाकर आसानी से नियंत्रित किया जा सकता है।

वेब परीक्षण में एक मानक परीक्षण क्या है?

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

उपरोक्त युक्तियों का उपयोग करके एक मानक स्क्रिप्ट का एक सेट बना सकता है और विभिन्न वेबसाइटों के लिए कम या आवश्यक संशोधनों के साथ उनका उपयोग कर सकता है।

इन मानक परीक्षण मामलों को भी स्वचालित किया जा सकता है, लेकिन एक बार फिर से पुन: प्रयोज्य पर ध्यान केंद्रित करना हमेशा एक प्लस होता है। इसके अलावा यदि स्वचालन एक जीयूआई पर आधारित है, कई यूआरएल या साइटों पर लिपियों का पुन: उपयोग करना कुछ ऐसा है जो मुझे व्यक्तिगत रूप से कभी प्रभावी नहीं मिला।

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

निष्कर्ष

टेस्ट केस दक्षता में सुधार केवल एक परिभाषित शब्द नहीं है, लेकिन यह एक अभ्यास है और इसे परिपक्व प्रक्रिया और नियमित अभ्यास के माध्यम से प्राप्त किया जा सकता है।

परीक्षण टीम को ऐसे कार्यों के सुधार में शामिल होने से नहीं थकना चाहिए क्योंकि यह गुणवत्ता की दुनिया में अधिक से अधिक उपलब्धियों के लिए सबसे अच्छा उपकरण है, यह मिशन-महत्वपूर्ण परियोजनाओं और जटिल अनुप्रयोगों पर दुनिया भर में कई परीक्षण संगठनों में साबित होता है।

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

अगला ट्यूटोरियल

अनुशंसित पाठ

^