test coverage software testing
सॉफ्टवेयर टेस्टिंग टेस्ट कवरेज पूरी गाइड: कैसे और अधिक परीक्षण, समय बचाने के लिए, और बेहतर परीक्षण के परिणाम प्राप्त करने के लिए:
सॉफ्टवेयर विकास और रखरखाव जीवन चक्र में सॉफ्टवेयर परीक्षण एक आवश्यक गतिविधि है। यह सॉफ्टवेयर की गुणवत्ता को तय करने और सुधारने के लिए अक्सर प्रयोग किया जाता है।
विकास आजकल अधिक व्यवस्थित है और संगठन परीक्षण पूर्णता दिखाने के लिए परीक्षण पूर्णता और प्रभावशीलता के उपायों की तलाश करते हैं। उन सभी में से, कवरेज को विशेष रूप से मूल्यवान माना जाता है।
आप क्या सीखेंगे:
- टेस्ट कवरेज क्या है?
- टेस्ट कवरेज और कोड कवरेज
- मेरा अनुभव
- टेस्ट कवरेज अर्थ
- एक उचित टेस्ट कवरेज विधि कैसे अपनाएं?
- कैसे सुनिश्चित करें कि सब कुछ परीक्षण किया गया है?
- प्रभावी परीक्षण के लिए महत्वपूर्ण क्षेत्र और तरीके
- एक परीक्षक के लिए कवरेज जागरूकता के परीक्षण के लाभ:
- निष्कर्ष
- अनुशंसित पाठ
टेस्ट कवरेज क्या है?
सीधे शब्दों में कहें, तो कवरेज 'हम क्या परीक्षण कर रहे हैं और हम कितना परीक्षण कर रहे हैं?'
टेस्ट कवरेज, परीक्षण की गुणवत्ता की निगरानी करने में मदद करता है, और परीक्षणकर्ताओं को ऐसे परीक्षण बनाने में सहायता करता है जो ऐसे क्षेत्रों को कवर करते हैं जो गायब हैं या मान्य नहीं हैं।
अधिकांश टीमें अकेले कार्यात्मक आवश्यकताओं पर अपने कवरेज की गणना को आधार बनाती हैं। यह उचित भी है क्योंकि पहले और सबसे पहले एक आवेदन को वही करना चाहिए जो वह करने वाला है। यदि नहीं, तो इसकी गति या सुरक्षा या उपयोग में आसानी - इससे कोई फर्क नहीं पड़ता।
हालांकि, अगर समर्पित और स्वतंत्र गैर-कार्यात्मक परीक्षण टीमें प्रदर्शन, सुरक्षा, प्रयोज्य परीक्षण आदि पर काम कर रही हैं, फिर उन्हें परीक्षण कवरेज एनालिटिक्स के माध्यम से निष्पादन के लिए अपनी आवश्यकताओं को ट्रैक करना होगा।
टेस्ट कवरेज और कोड कवरेज
टेस्ट कवरेज अक्सर कोड कवरेज के साथ भ्रमित होता है। भले ही अंतर्निहित सिद्धांत समान हैं, वे दो अलग-अलग चीजें हैं।
कोड कवरेज़ यूनिट परीक्षण प्रथाओं के बारे में वास्तव में बात करता है जिन्हें कम से कम एक बार कोड के सभी क्षेत्रों को लक्षित करना पड़ता है और डेवलपर्स द्वारा किया जाता है।
दूसरी ओर, टेस्ट कवरेज, है हर आवश्यकता का परीक्षण कम से कम एक बार और स्पष्ट रूप से एक क्यूए टीम गतिविधि है।
वास्तव में एक कवर की जाने वाली आवश्यकता क्या है यह प्रत्येक टीम की व्याख्या पर निर्भर करता है।
उदाहरण के लिए , कुछ टीमें कवर की गई आवश्यकता को बुलाती हैं यदि इसके खिलाफ कम से कम एक परीक्षण मामला हो। कभी-कभी, यह कवर किया जाता है यदि कम से कम एक टीम के सदस्य को इसे सौंपा जाता है। या, यदि इसके साथ जुड़े सभी परीक्षण मामलों को निष्पादित किया जाता है।
- यदि 10 आवश्यकताएं और 100 परीक्षण बनाए गए हैं - जब ये 100 परीक्षण सभी 10 आवश्यकताओं को लक्षित करते हैं और किसी को भी नहीं छोड़ते हैं - तो हम डिजाइन स्तर पर इस पर्याप्त परीक्षण कवरेज को कहते हैं।
- जब बनाए गए परीक्षणों में से केवल 80 को निष्पादित किया जाता है और केवल 6 आवश्यकताओं को लक्षित करता है। हम कहते हैं कि 4 आवश्यकताओं को कवर नहीं किया गया है, हालांकि 80% परीक्षण किया जाता है। यह एक निष्पादन स्तर पर कवरेज आँकड़े हैं।
- जब 8 आवश्यकताओं से संबंधित केवल 90 परीक्षणों ने परीक्षकों को सौंपा है और उनमें से बाकी नहीं हैं, तो हम कहते हैं कि परीक्षण असाइनमेंट कवरेज 80% (10 आवश्यकताओं में से 8) है।
यह भी महत्वपूर्ण है कि कब कवरेज की गणना की जाए।
यदि आप इस प्रक्रिया को बहुत जल्दी करते हैं, तो आपको बहुत सारे अंतराल दिखाई देंगे क्योंकि चीजें अभी भी अधूरी हैं। तो यह आमतौर पर सलाह दी जाती है अंतिम निर्माण तक प्रतीक्षा करें यानी फाइनल रिग्रेशन बिल्ड। यह दी गई आवश्यकताओं के लिए किए गए टेस्ट का सही कवरेज देगा।
यह भी पढ़े => रिलीज और तैनाती प्रबंधन प्रक्रिया
मेरा अनुभव
दृश्य 8 साल पहले: जब मुझे सॉफ्टवेयर टेस्टिंग इंडस्ट्री में 2 साल का अनुभव हो रहा था, तो मैं सोच रहा था कि यह ठीक है अगर मुझे सॉफ्टवेयर टेस्टिंग के बारे में कुछ बुनियादी बातों के बारे में पता नहीं है क्योंकि कोई अनुभव के साथ कुछ सीख सकता है और मैं भी करूंगा।
मैं सही था - और गलत भी।
क्योंकि अनुभव के साथ, आप एक बड़ी तस्वीर देखना सीखते हैं, आप 'महत्वपूर्ण स्थिति' का वास्तविक अर्थ समझते हैं और आप अंतिम उपयोगकर्ता को अधिक समझते हैं।
गलत है क्योंकि उल्लेखित चीजों में से किसी को भी अनुभव की आवश्यकता नहीं है, लेकिन प्रारंभिक शिक्षा, जिसे मैंने बहुत देर से समझा। यह पोस्ट लिखने के लिए उत्साहजनक कारक है।
यहाँ उस समय के एक साक्षात्कार से मेरा अनुभव है:
आप कैसे सुनिश्चित करते हैं कि परीक्षण कवरेज पूर्ण या अधिकतम है? मुझसे पूछा गया।
उम्म्म्म …… मुझे यकीन है कि मैं हर कार्यक्षमता का परीक्षण करता हूं , मैंने कहा था।
रों ओ कह रहे हैं कि एक बार जब आप सभी कार्यात्मकताओं का परीक्षण करते हैं, तो आपको लगता है कि आपने परीक्षण के संदर्भ में अधिकतम आवेदन / उत्पाद को कवर किया है साक्षात्कारकर्ता ने बैकफायर किया।
उम्म… अच्छा… .मम्मी… .हाँ, क्योंकि जब आप सभी कार्यक्षमताओं का परीक्षण करते हैं, तो आप अनुप्रयोग / उत्पाद और व्यवहार के बारे में आश्वस्त होते हैं, मैंने अपने उत्तर का समर्थन किया ।
मैं सहमत हूं, लेकिन मेरा प्रश्न है - क्या यह आपको विश्वास दिलाएगा कि आपका परीक्षण कवरेज अधिकतम या पूर्ण है? साक्षात्कारकर्ता मुझे जाने देने के मूड में नहीं था।
अब, मैं अधीर हो रहा था, इस तथ्य के बारे में अज्ञात था कि मैं सॉफ्टवेयर परीक्षण के बारे में सबसे महत्वपूर्ण विषयों में से एक सीखने जा रहा था - ' टेस्ट कवरेज ” ।
साक्षात्कार के अंश को पुन: प्रस्तुत करने के बजाय, मैं यहां संक्षेप में बता रहा हूं, मैंने उस दिन परीक्षण कवरेज के बारे में क्या सीखा। लेकिन इससे पहले कि एक बिंदु पर स्पष्ट होने दें - परीक्षण कवरेज का मतलब यह जानना कभी नहीं है कि आप पर्याप्त परीक्षण कर रहे हैं या नहीं, न तो इसका मतलब है कि आप पूरी तरह से परीक्षण कर रहे हैं या नहीं।
टेस्ट कवरेज अर्थ
विभिन्न संदर्भों में परीक्षण कवरेज का एक अलग अर्थ हो सकता है। आइए उन संदर्भों को एक-एक करके देखें:
उत्पाद कवरेज - आपने किस उत्पाद को देखा है?
हां, जब परीक्षण कवरेज को उत्पाद के संदर्भ में मापा जा रहा है, तो ध्यान केंद्रित करने के लिए मुख्य क्षेत्र है - आपके द्वारा परीक्षण किए गए उत्पाद के कौन से क्षेत्र और कौन से अप्रयुक्त हैं?
उदाहरण 1:
यदि 'चाकू' एक उत्पाद है, तो आप परीक्षण कर रहे हैं; बस यह जाँचने पर ध्यान न दें कि क्या यह सब्जियों / फलों को ठीक से काटता है। ऐसे देखने के अन्य पहलू हैं - उपयोगकर्ता को इसे आराम से संभालने में सक्षम होना चाहिए।
उदाहरण # 2:
यदि 'नोटपैड' एक एप्लिकेशन है, तो आप परीक्षण कर रहे हैं, प्रासंगिक सुविधाओं की जांच करना एक जरूरी बात है।
लेकिन ध्यान रखे जाने वाले अन्य पहलू हैं - एक साथ अन्य एप्लिकेशन का उपयोग करते समय एप्लिकेशन ठीक से प्रतिक्रिया करता है, एप्लिकेशन क्रैश नहीं होता है जब उपयोगकर्ता कुछ असामान्य करने की कोशिश करता है , उपयोगकर्ता को उचित चेतावनी / त्रुटि संदेश प्रदान किया जाता है, उपयोगकर्ता आसानी से समझने और उपयोग करने में सक्षम होता है, आवश्यक होने पर सहायता सामग्री उपलब्ध होती है।
यदि आप उल्लिखित परिदृश्यों पर ध्यान नहीं देते हैं, तो आप यह दावा नहीं कर सकते कि आवेदन के लिए परीक्षण कवरेज पूरा हो गया है।
जोखिम कवरेज - आपने किन जोखिमों के लिए परीक्षण किया है?
जोखिम कवरेज पूर्ण परीक्षण कवरेज के लिए एक और पहलू है। जब तक आप संबंधित जोखिमों का परीक्षण नहीं करते हैं, तब तक आप उत्पाद या एप्लिकेशन को 'परीक्षण' के रूप में टैग नहीं कर सकते। समग्र परीक्षण कवरेज में संबद्ध जोखिमों का कवरेज एक महत्वपूर्ण कारक है।
उदाहरण 1:
हवाई जहाज का परीक्षण करते समय, अगर कोई परीक्षक आपको बताता है कि उसने हवाई जहाज की आंतरिक प्रणाली का पूरी तरह से परीक्षण किया है और यह ठीक काम कर रहा है, लेकिन परीक्षण के दौरान केवल हवाई जहाज की उड़ान क्षमता को कवर नहीं किया गया - आपकी प्रतिक्रिया क्या होगी?
खैर, यही जोखिम जोखिम का मतलब है। आवेदन / उत्पाद के अनुसार जोखिम की पहचान करना और इसे पूरी तरह से जांचना हमेशा एक अच्छा अभ्यास है।
उदाहरण # 2:
ई-कॉमर्स साइट का परीक्षण करते समय, परीक्षक ने प्रत्येक प्रभावी कारक पर विचार किया, लेकिन साथ ही साथ वेबसाइट पर पहुंचने वाले उपयोगकर्ताओं की संख्या और सुपर OFFER के दिन के जोखिम को नहीं माना, जोखिम नहीं माना एक बड़ी गलती साबित हुई।
अनुशंसित पाठ =>
आवश्यकताएँ कवरेज - आपने किन आवश्यकताओं के लिए परीक्षण किया है?
यदि कोई उत्पाद या एप्लिकेशन बहुत अच्छी तरह से विकसित किया गया है, लेकिन यदि वह ग्राहकों की आवश्यकताओं से मेल नहीं खा रहा है तो इसका कोई फायदा नहीं है। परीक्षण करते समय आवश्यकता कवरेज उत्पाद कवरेज के रूप में महत्वपूर्ण है।
उदाहरण 1:
पारिवारिक समारोह के लिए उत्साहित, आपने दर्जी को अपनी पोशाक सिलाई करने के लिए कहा और नेकलाइन पर उन मोर नीले शो बटन पर डाल दिया।
पोशाक को सिलाई करते समय, दर्जी ने सोचा कि उन बटन को नेकलाइन पर रखना अच्छा नहीं लगेगा, इसलिए उसने एक सुनहरे रंग की सीमा पर सिलाई की। परीक्षण के दिन, निश्चित रूप से, नाखुश ग्राहक आवश्यकताओं को पूरा न करने के लिए दर्जी पर चिल्लाया।
उदाहरण # 2:
एक चैट एप्लिकेशन का परीक्षण करते समय, परीक्षक ने सभी महत्वपूर्ण बिंदुओं का ध्यान रखा जैसे एक समूह में कई उपयोगकर्ता चैटिंग, दो उपयोगकर्ता स्वतंत्र रूप से चैटिंग, सभी प्रकार के इमोटिकॉन्स उपलब्ध, उपयोगकर्ता को तुरंत अपडेट आदि आदि लेकिन आवश्यकता दस्तावेज़ में देखना भूल गए, जो स्पष्ट रूप से उल्लेख किया है कि जब दो उपयोगकर्ता स्वतंत्र रूप से चैट करते हैं, तो वीडियो कॉल विकल्प सक्षम होना चाहिए।
क्लाइंट ने चैट एप्लिकेशन को यह दावा करते हुए विपणन किया कि यह कॉलिंग की अनुमति देगा, जबकि दो उपयोगकर्ता स्वतंत्र रूप से चैट करते हैं। आप सोच सकते हैं कि चैट एप्लिकेशन का क्या हुआ होगा।
भी पढ़ना => आवश्यकताएँ ट्रैसबिलिटी मैट्रिक्स कैसे बनाएँ
एक उचित टेस्ट कवरेज विधि कैसे अपनाएं?
जागरूकता ही सब कुछ है:
सबसे पहले, क्यूए टीम को पता होना चाहिए कि कितना काम शामिल है और डिजाइन कार्य कहाँ पर हैं। इस तरह, वे जागरूक होने जा रहे हैं यदि अधिक परीक्षण जोड़े जाने हैं। ऐसा करने के लिए, आप एक RTM का उपयोग कर सकते हैं जैसा कि विशिष्ट अभ्यास है।
=> इसके बारे में और जानने के लिए इस लेख को देखें और इसका उपयोग कैसे करें: आवश्यकताओं को कैसे बनाएं ट्रैसेबिलिटी मैट्रिक्स - नमूना टेम्पलेट के साथ सटीक प्रक्रिया
दूसरे, संसाधन असाइनमेंट की जाँच करें और परीक्षण निष्पादन प्रक्रिया यह देखने के लिए कि क्या सब कुछ अधिक प्रभावी तरीके से परीक्षण किया गया है।
नीचे दी गई तालिका उपयोगी हो सकती है:
टेस्ट का प्रकार | कुल मामले | निष्पादित मामले | स्थिति | टिप्पणियाँ |
---|---|---|---|---|
कार्यात्मक | 100 | .० | 50 पास, 30 फेल | |
अनुकूलता | 100 | पचास | 45 पास, 5 फेल | |
प्रयोज्यता | 100 | 100 | 98 पास, 2 फेल | |
अंतिम प्रतिगमन | 100 | 100 | 99 पास, 1 फेल |
कैसे सुनिश्चित करें कि सब कुछ परीक्षण किया गया है?
- प्रत्येक परीक्षक को आवश्यकताओं और परीक्षण विधियों के बारे में पता होना चाहिए
- अपनी आवश्यकताओं को प्राथमिकता दें और अपनी ऊर्जा पर ध्यान केंद्रित करें जहाँ इसकी सबसे अधिक आवश्यकता है
- इस बारे में सूचित किया जाए कि एक निश्चित रिलीज पिछले एक से कैसे अलग है ताकि आप महत्वपूर्ण आवश्यकताओं को अधिक सटीक रूप से पहचान सकें और अधिकतम सकारात्मक कवरेज पर ध्यान केंद्रित कर सकें
- एडाप्ट टेस्ट ऑटोमेशन
- परीक्षण प्रबंधन उपकरण का उपयोग करें हमेशा जानने के लिए
- स्मार्ट कार्य असाइनमेंट- महत्वपूर्ण कार्यों की दिशा में अपने सर्वोत्तम संसाधनों को चैनल दें और नए परीक्षकों को नए परिप्रेक्ष्य के लिए अधिक अन्वेषण करने दें
- एक बनाए रखना सभी कार्यों के लिए चेकलिस्ट और विविध गतिविधियाँ
- आवेदन व्यवहार में अंतर्दृष्टि प्राप्त करने के लिए अपने देव / स्क्रम / बीए टीमों के साथ अधिक बातचीत करें
- अपने सभी निर्माण चक्रों और सुधारों पर नज़र रखें
- आरंभिक बिल्ड्स में सबसे अधिक प्रभावित होने वाली समस्याओं को पहचानें (जब संभव हो) तो बाद में बेहतर स्थिरता के लिए काम कर सकते हैं और अपनी समस्याओं का उपयोग करके उन क्षेत्रों तक पहुंच सकते हैं
प्रभावी परीक्षण के लिए महत्वपूर्ण क्षेत्र और तरीके
# 1)संसाधन जंबलिंग: अपनी टीम के सदस्यों के बीच कार्यों का आदान-प्रदान करें। यह सगाई को बेहतर बनाने और ज्ञान की एकाग्रता को रोकने में मदद करता है।
#दो)संगतता कवरेज: सुनिश्चित करें कि आप जागरूक हैं और इसमें शामिल हैं विभिन्न ब्राउज़रों तथा प्लेटफार्मों अपने आवेदन का परीक्षण करने के लिए।
# 3)स्वामित्व: परीक्षकों को जवाबदेह बनाएं और उन्हें मॉड्यूल / कार्य के लिए नि: शुल्क लगाम (निगरानी और निश्चित रूप से समर्थन के साथ) दें, जिस पर वे काम कर रहे हैं। यह जिम्मेदारी का निर्माण करने में मदद करता है और उन्हें सड़क से नीचे पीटने के बजाय रचनात्मक तरीके से प्रयास करने देता है।
# 4)समय सीमा: परीक्षण चरण के शुरू होने से पहले रिलीज की समय सीमा जानने से प्रभावी योजना बनाने में मदद मिलती है
# 5)संचार : देव और अन्य टीमों के साथ संपर्क में रहें क्या हो रहा है, यह जानने के लिए रिलीज़ साइकिल के बीच में।
# 6)RTM बनाए रखें: के लिए एक अच्छा व्युत्पन्न के रूप में कार्य करता है हितधारक या ग्राहक , जिसके आधार पर रिलीज़ शेड्यूल की पुष्टि की जा सकती है
एक परीक्षक के लिए कवरेज जागरूकता के परीक्षण के लाभ:
- यह प्राथमिक रूप से परीक्षण कार्य को प्राथमिकता देने में मदद करता है
- यह 100% आवश्यकता कवरेज या दूसरे शब्दों में प्राप्त करने में मदद करता है, यह आवश्यकता रिसाव को रोकता है
- प्रभाव विश्लेषण आसान हो जाता है
- के निर्धारण में उपयोगी है EXIT मानदंड
- एक स्पष्ट तैयार करने के लिए एक परीक्षण का नेतृत्व सक्षम करता है परीक्षण बंद करने की रिपोर्ट
निष्कर्ष
उल्लिखित संदर्भों के साथ टेस्ट कवरेज समाप्त नहीं होता है। कई अन्य बिंदु हैं जिन पर विचार किया जाना चाहिए जब परीक्षण कवरेज की बात आती है।
यह हमेशा सच नहीं है कि जब आप अधिक परीक्षण करते हैं, तो परिणाम बेहतर होते हैं। वास्तव में, जब आप कोई स्पष्ट रणनीति के साथ अधिक परीक्षण करते हैं, तो आप संभवतः बहुत समय का निवेश करेंगे।
अधिक संरचित दृष्टिकोण के साथ, 100% आवश्यकता कवरेज और प्रभावी परीक्षण विधियों के उद्देश्य से, आप गुणवत्ता से समझौता नहीं करेंगे।
c ++ रेगेक्स मैच उदाहरण
हमें उम्मीद है कि इस लेख में उल्लिखित तकनीकें आपको कुछ संकेत देंगी।
पोस्ट के बारे में अपनी टिप्पणी और विचारों में डालें। हमेशा की तरह, हम आपसे सुनना पसंद करते हैं।
अनुशंसित पाठ
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 [क्यूए टेस्ट स्वचालन उपकरण]
- सॉफ्टवेयर परीक्षण क्यूए सहायक नौकरी
- सॉफ्टवेयर टेस्टिंग कोर्स: मुझे किस सॉफ्टवेयर टेस्टिंग इंस्टीट्यूट में शामिल होना चाहिए?
- अपने कैरियर के रूप में सॉफ्टवेयर परीक्षण चुनना
- सॉफ्टवेयर टेस्टिंग टेक्निकल कंटेंट राइटर फ्रीलांसर जॉब
- क्या सॉफ्टवेयर टेस्टिंग एक इमोशनल टास्क है?
- कुछ दिलचस्प सॉफ्टवेयर परीक्षण साक्षात्कार प्रश्न
- सॉफ्टवेयर परीक्षण पाठ्यक्रम प्रतिक्रिया और समीक्षा