- क्या है सॉफ्टवेयर परीक्षण मेट्रिक्स?
- सॉफ़्टवेयर परीक्षण मापन क्या है?
- मेट्रिक्स का परीक्षण क्यों करें?
- मेट्रिक्स लाइफ साइकिल
- मैनुअल टेस्ट मेट्रिक्स के प्रकार
- सॉफ्टवेयर के उदाहरणटेस्टिंग मेट्रिक्स
- निष्कर्ष
- अनुशंसित पढ़ना
सॉफ्टवेयर परियोजनाओं में, परियोजना और प्रक्रियाओं की गुणवत्ता, लागत और प्रभावशीलता को मापना सबसे महत्वपूर्ण है। इन्हें मापे बिना, कोई प्रोजेक्ट सफलतापूर्वक पूरा नहीं किया जा सकता है।
आज के लेख में, हम उदाहरणों और ग्राफ़ के साथ - सॉफ़्टवेयर टेस्ट मेट्रिक्स और माप 5 सीखेंगे> और सॉफ़्टवेयर परीक्षण प्रक्रिया में इनका उपयोग कैसे करें।
एक प्रसिद्ध कथन है: “हम उन चीज़ों को नियंत्रित नहीं कर सकते जिन्हें हम माप नहीं सकते”।3
यहां परियोजनाओं को नियंत्रित करने का मतलब है, कैसे एक परियोजना प्रबंधक/लीड परीक्षण योजना से विचलन की पहचान कर सकता है ताकि सही समय पर प्रतिक्रिया करने के लिए प्रतिक्रिया कर सके। परीक्षण किए जा रहे सॉफ़्टवेयर की गुणवत्ता प्राप्त करने के लिए प्रोजेक्ट की ज़रूरतों के आधार पर टेस्ट मेट्रिक्स तैयार करना बहुत महत्वपूर्ण है।
क्या है सॉफ्टवेयर परीक्षण मेट्रिक्स?
एक मेट्रिक उस डिग्री का एक मात्रात्मक माप है जिसके लिए एक सिस्टम, सिस्टम घटक, या प्रक्रिया में दी गई विशेषता होती है।
मेट्रिक्स को “मानकों के के रूप में परिभाषित किया जा सकता है माप "।
प्रोजेक्ट की गुणवत्ता को मापने के लिए सॉफ्टवेयर मेट्रिक्स का उपयोग किया जाता है . सीधे शब्दों में, एक मीट्रिक एक विशेषता का वर्णन करने के लिए उपयोग की जाने वाली इकाई है। मीट्रिक माप के लिए एक पैमाना है।
मान लीजिए, सामान्य तौर पर, "किलोग्राम" विशेषता "वजन" को मापने के लिए एक मीट्रिक है। इसी तरह, सॉफ्टवेयर में, “कितने इश्यू में पाए जाते हैंकोड की एक हजार पंक्तियाँ?”, h ere नहीं। मुद्दों की एक माप है और; कोड की पंक्तियों की संख्या एक अन्य माप है। मीट्रिक को इन दो मापों से परिभाषित किया गया है ।
परीक्षण मीट्रिक उदाहरण:
- कितने दोष मौजूद हैं मॉड्यूल?
- प्रति व्यक्ति कितने परीक्षण मामले निष्पादित किए जाते हैं?
- परीक्षण कवरेज % क्या है?
सॉफ़्टवेयर परीक्षण मापन क्या है?
माप किसी उत्पाद या प्रक्रिया की कुछ विशेषताओं की सीमा, मात्रा, आयाम, क्षमता या आकार का मात्रात्मक संकेत है।
परीक्षण मापन का उदाहरण: दोषों की कुल संख्या।
माप और मापन के बीच अंतर की स्पष्ट समझ के लिए कृपया नीचे आरेख देखें। मेट्रिक्स.
मेट्रिक्स का परीक्षण क्यों करें?
सॉफ्टवेयर टेस्ट मेट्रिक्स का निर्माण सॉफ्टवेयर टेस्ट लीड/मैनेजर की सबसे महत्वपूर्ण जिम्मेदारी है।
टेस्ट मेट्रिक्स का उपयोग
- 13 के लिए किया जाता है> गतिविधियों के अगले चरण के लिए निर्णय लें जैसे, लागत का अनुमान लगाएं और; भविष्य की परियोजनाओं की अनुसूची।
- परियोजना की सफलता के लिए आवश्यक सुधार को समझें
- प्रक्रिया या प्रौद्योगिकी को संशोधित करने के बारे में निर्णय लें।
सॉफ्टवेयर टेस्टिंग मेट्रिक्स का महत्व:
जैसा कि ऊपर बताया गया है, टेस्ट मेट्रिक्स सॉफ्टवेयर की गुणवत्ता को मापने के लिए सबसे महत्वपूर्ण हैं।
अब, हम कैसे माप सकते हैं की गुणवत्तामेट्रिक्स का उपयोग करके सॉफ्टवेयर?
मान लीजिए, अगर किसी प्रोजेक्ट में कोई मेट्रिक्स नहीं है, तो टेस्ट एनालिस्ट द्वारा किए गए काम की गुणवत्ता कैसे मापी जाएगी?
उदाहरण के लिए, एक परीक्षण विश्लेषक को,
- 5 आवश्यकताओं के लिए परीक्षण मामलों को डिज़ाइन करना होता है
- डिज़ाइन किए गए परीक्षण मामलों को निष्पादित करें
- दोषों को लॉग करें और; संबंधित परीक्षण मामलों को विफल करने की आवश्यकता
- दोष का समाधान होने के बाद, हमें दोष का पुन: परीक्षण करने की आवश्यकता है और; संबंधित विफल परीक्षण मामले को फिर से निष्पादित करें।
उपरोक्त परिदृश्य में, यदि मेट्रिक्स का पालन नहीं किया जाता है, तो परीक्षण विश्लेषक द्वारा पूरा किया गया कार्य व्यक्तिपरक होगा अर्थात परीक्षण रिपोर्ट में उचित जानकारी नहीं होगी उसके कार्य/परियोजना की स्थिति जानने के लिए।
यदि परियोजना में मेट्रिक्स शामिल हैं, तो उचित संख्या/डेटा के साथ उसके कार्य की सटीक स्थिति प्रकाशित की जा सकती है।
यानी टेस्ट रिपोर्ट में, हम प्रकाशित कर सकते हैं:
- आवश्यकता के अनुसार कितने टेस्ट केस डिजाइन किए गए हैं?
- कितने टेस्ट केस डिजाइन किए जाने बाकी हैं?
- कितने परीक्षण मामले निष्पादित किए गए हैं?
- कितने परीक्षण मामले पारित/विफल/अवरुद्ध हुए हैं?
- कितने परीक्षण मामले अभी तक निष्पादित नहीं हुए हैं?
- कितने दोष हैं पहचाने जाते हैं & amp; उन दोषों की गंभीरता क्या है?
- एक विशेष दोष के कारण कितने परीक्षण मामले विफल हो जाते हैं? आदि
परियोजना की जरूरतों के आधार पर हमारे पास उपरोक्त सूची की तुलना में अधिक मेट्रिक्स हो सकते हैं, यह जानने के लिएपरियोजना की स्थिति विस्तार से।
उपर्युक्त मेट्रिक्स के आधार पर, टेस्ट लीड/मैनेजर नीचे उल्लिखित मुख्य बिंदुओं की समझ प्राप्त करेंगे।
- %ge पूरा काम
- %ge अभी पूरा होना बाकी है
- शेष काम पूरा करने का समय
- क्या प्रोजेक्ट शेड्यूल के मुताबिक चल रहा है या लेट हो रहा है? आदि
मैट्रिक्स के आधार पर, यदि परियोजना निर्धारित समय के अनुसार पूरी नहीं हो रही है, तो प्रबंधक क्लाइंट और अन्य हितधारकों को कारण बताते हुए अलार्म उठाएगा अंतिम समय के आश्चर्य से बचने के लिए पिछड़ना।
मेट्रिक्स लाइफ साइकिल
मैनुअल टेस्ट मेट्रिक्स के प्रकार
टेस्टिंग मेट्रिक्स को मुख्य रूप से 2 श्रेणियों में विभाजित किया गया है। मेट्रिक्स वे मेट्रिक्स हैं जो परीक्षण मामले के विकास और निष्पादन के दौरान परीक्षण विश्लेषक द्वारा एकत्र किए गए डेटा से प्राप्त होते हैं।
यह डेटा पूरे परीक्षण जीवनचक्र में ट्रैक किया जाएगा। अर्थात। कुल संख्या जैसे डेटा एकत्र करना। एक परियोजना (या) संख्या के लिए विकसित परीक्षण मामलों की संख्या। परीक्षण मामलों को निष्पादित करने की आवश्यकता है (या) नहीं। उत्तीर्ण/असफल/अवरुद्ध आदि परीक्षण मामलों की संख्या।
परिकलित मेट्रिक्स: परिकलित मेट्रिक्स बेस मेट्रिक्स में एकत्र किए गए डेटा से प्राप्त किए जाते हैं। टेस्ट रिपोर्टिंग उद्देश्यों के लिए इन मेट्रिक्स को आमतौर पर टेस्ट लीड/मैनेजर द्वारा ट्रैक किया जाता है।
सॉफ्टवेयर के उदाहरणटेस्टिंग मेट्रिक्स
आइए सॉफ्टवेयर परीक्षण रिपोर्ट में उपयोग किए जाने वाले विभिन्न टेस्ट मेट्रिक्स की गणना करने के लिए एक उदाहरण लेते हैं:
टेस्ट एनालिस्ट से प्राप्त डेटा के लिए तालिका प्रारूप नीचे दिया गया है जो वास्तव में इसमें शामिल है टेस्टिंग:
मैट्रिक्स की गणना के लिए परिभाषाएं और सूत्र:
#1) %ge टेस्ट केस निष्पादित : इस मीट्रिक का उपयोग %ge के संदर्भ में परीक्षण मामलों की निष्पादन स्थिति प्राप्त करने के लिए किया जाता है।
%ge निष्पादित परीक्षण मामले = ( निष्पादित परीक्षण मामलों की संख्या / कुल लिखित मामलों की संख्या) * 100.
इसलिए, उपरोक्त डेटा से,
%ge परीक्षण मामले निष्पादित = (65/100) * 100 = 65%
#2) %ge परीक्षण मामलों को निष्पादित नहीं किया गया : इस मीट्रिक का उपयोग %ge के संदर्भ में परीक्षण मामलों की लंबित निष्पादन स्थिति प्राप्त करने के लिए किया जाता है।
%ge परीक्षण मामले निष्पादित नहीं = ( निष्पादित नहीं किए गए परीक्षण मामलों की संख्या / लिखित परीक्षण मामलों की कुल संख्या) * 100.
इसलिए, उपरोक्त डेटा से,
%ge परीक्षण मामले अवरोधित = (35/100) * 100 = 35%
#3) %ge टेस्ट केस पास हुए : इस मीट्रिक का उपयोग निष्पादित परीक्षण मामलों का पास% जीई प्राप्त करने के लिए किया जाता है।
% जीई टेस्ट केस पास = ( नहीं। परीक्षण मामलों की संख्या उत्तीर्ण / कुल संख्या। निष्पादित मामलों की संख्या) * 100।
इसलिए, उपरोक्त डेटा से,
%ge परीक्षण मामले उत्तीर्ण = (30/65) * 100 = 46%
#4) %ge परीक्षण मामले विफल : इस मीट्रिक का उपयोग निष्पादित परीक्षण मामलों के विफल %ge को प्राप्त करने के लिए किया जाता है।
%ge परीक्षण मामलेविफल = ( विफल हुए परीक्षण मामलों की संख्या / निष्पादित मामलों की कुल संख्या) * 100.
इसलिए, उपरोक्त डेटा से,
%ge परीक्षण मामले उत्तीर्ण = (26 / 65) * 100 = 40%
#5)% जीई परीक्षण मामले अवरुद्ध : इस मीट्रिक का उपयोग निष्पादित परीक्षण मामलों के अवरुद्ध% जी को प्राप्त करने के लिए किया जाता है। परीक्षण मामलों को अवरुद्ध करने के वास्तविक कारण को निर्दिष्ट करके एक विस्तृत रिपोर्ट प्रस्तुत की जा सकती है।
%ge परीक्षण मामले अवरुद्ध = ( अवरुद्ध परीक्षण मामलों की संख्या / परीक्षण मामलों की कुल संख्या निष्पादित ) * 100.
तो, उपरोक्त डेटा से,
%ge टेस्ट केस ब्लॉक किए गए = (9 / 65) * 100 = 14%
1
#6) दोष घनत्व = नहीं। दोषों की पहचान / आकार
( यहां "आकार" को एक आवश्यकता माना जाता है। इसलिए यहां दोष घनत्व की गणना प्रति आवश्यकता पहचानी गई दोषों की संख्या के रूप में की जाती है। इसी प्रकार, दोष घनत्व की गणना की जा सकती है कोड की प्रति 100 पंक्तियों में पहचाने गए दोषों की संख्या के रूप में [या] प्रति मॉड्यूल की पहचान की गई दोषों की संख्या, आदि। )
तो, उपरोक्त डेटा से,
दोष घनत्व = (30 / 5) = 6
#7) दोष हटाने की क्षमता (DRE) = ( QA परीक्षण के दौरान पाए गए दोषों की संख्या / (QA के दौरान पाए गए दोषों की संख्या) परीक्षण + एंड-यूज़र द्वारा पाए गए दोषों की संख्या)) * 100
DRE का उपयोग सिस्टम की परीक्षण प्रभावशीलता की पहचान करने के लिए किया जाता है।
मान लीजिए, विकास के दौरान और; क्यूए परीक्षण, हमने 100 दोषों की पहचान की है।
क्यूए परीक्षण के बाद, अल्फा और amp के दौरान; बीटा परीक्षण,एंड-यूज़र / क्लाइंट ने 40 दोषों की पहचान की, जिन्हें क्यूए परीक्षण चरण के दौरान पहचाना जा सकता था।
अब, DRE की गणना इस प्रकार की जाएगी,
DRE = [100 / (100 + 40)] * 100 = [100 /140] * 100 = 71%
#8) दोष रिसाव: दोष रिसाव वह मीट्रिक है जिसका उपयोग QA परीक्षण की दक्षता की पहचान करने के लिए किया जाता है यानी, QA परीक्षण के दौरान कितने दोष छूटे/छिप गए।
त्रुटि रिसाव = ( UAT में पाए गए दोषों की संख्या / QA परीक्षण में पाए गए दोषों की संख्या।) * 100
मान लीजिए, विकास के दौरान & क्यूए परीक्षण, हमने 100 दोषों की पहचान की है।
क्यूए परीक्षण के बाद, अल्फा और amp के दौरान; बीटा परीक्षण, एंड-यूज़र / क्लाइंट ने 40 दोषों की पहचान की, जिन्हें क्यूए परीक्षण चरण के दौरान पहचाना जा सकता था।
दोष रिसाव = (40 /100) * 100 = 40%
#9) प्राथमिकता के आधार पर दोष : इस मीट्रिक का उपयोग संख्या की पहचान करने के लिए किया जाता है। सॉफ्टवेयर की गुणवत्ता तय करने के लिए उपयोग किए जाने वाले दोष की गंभीरता / प्राथमिकता के आधार पर पहचाने गए दोषों की संख्या।
%ge गंभीर दोष = पहचाने गए महत्वपूर्ण दोषों की संख्या / कुल संख्या। पहचाने गए दोषों की संख्या * 100
उपर्युक्त तालिका में उपलब्ध डेटा से,
%ge गंभीर दोष = 6/30 * 100 = 20%
%ge उच्च दोष = पहचाने गए उच्च दोषों की संख्या / कुल संख्या पहचाने गए दोषों की संख्या * 100
उपरोक्त तालिका में उपलब्ध डेटा से,
%ge उच्च दोष = 10/30 * 100 = 33.33%
%ge मध्यम दोष = नहीं।मध्यम दोषों की पहचान / कुल संख्या। पहचाने गए दोषों की संख्या * 100
उपर्युक्त तालिका में उपलब्ध डेटा से,
%ge मध्यम दोष = 6/30 * 100 = 20%
%ge कम दोष = पहचाने गए कम दोषों की संख्या / कुल संख्या पहचाने गए दोषों की संख्या * 100
उपर्युक्त तालिका में उपलब्ध डेटा से,
%ge कम दोष = 8/30 * 100 = 27%
0
निष्कर्ष
इस लेख में दिए गए मेट्रिक्स का उपयोग परीक्षण मामले के विकास/निष्पादन चरण के दौरान सटीक डेटा के साथ दैनिक/साप्ताहिक स्थिति रिपोर्ट बनाने के लिए प्रमुख रूप से किया जाता है। यह परियोजना की स्थिति पर नज़र रखने के लिए भी उपयोगी है और; सॉफ्टवेयर की गुणवत्ता।
लेखक के बारे में : यह अनुराधा के द्वारा एक अतिथि पोस्ट है। उनके पास सॉफ्टवेयर परीक्षण का 7+ वर्ष का अनुभव है और वर्तमान में वे एक सलाहकार के रूप में काम कर रही हैं। एक एमएनसी। उसे मोबाइल ऑटोमेशन परीक्षण का भी अच्छा ज्ञान है।
आप अपने प्रोजेक्ट में कौन से अन्य परीक्षण मेट्रिक्स का उपयोग करते हैं? हमेशा की तरह, अपने विचार/प्रश्न हमें नीचे कमेंट में बताएं।