unit testing - यूनिट परीक्षणों(और क्यों) के लिए उचित कोड कवरेज% क्या है?




unit-testing code-coverage (20)

अल्बर्टो सवोइया द्वारा यह गद्य ठीक उसी प्रश्न का उत्तर देता है (उस पर एक मनोरंजक तरीके से!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

टेस्ट कवरेज पर टेस्टिवस

शुरुआती एक सुबह, एक प्रोग्रामर ने महान गुरु से पूछा:

"मैं कुछ यूनिट परीक्षण लिखने के लिए तैयार हूं। मुझे किस कोड कवरेज का लक्ष्य रखना चाहिए? "

महान मास्टर ने जवाब दिया:

"कवरेज के बारे में चिंता न करें, बस कुछ अच्छे परीक्षण लिखें।"

प्रोग्रामर मुस्कुराया, झुका, और छोड़ दिया।

...

उस दिन बाद में, एक दूसरे प्रोग्रामर ने एक ही सवाल पूछा।

महान गुरु उबलते पानी के एक बर्तन पर इंगित किया और कहा:

"उस बर्तन में चावल के कितने अनाज लगाए जाएंगे?"

प्रोग्रामर, परेशान लग रहा है, जवाब दिया:

"मैं आपको कैसे बता सकता हूं? यह इस बात पर निर्भर करता है कि आपको कितने लोगों को खिलाने की ज़रूरत है, वे कितने भूखे हैं, आप कौन सी अन्य भोजन कर रहे हैं, कितना चावल उपलब्ध है, और इसी तरह। "

महान मास्टर ने कहा, "बिल्कुल,"।

दूसरा प्रोग्रामर मुस्कुराया, झुका, और छोड़ दिया।

...

दिन के अंत में, एक तीसरा प्रोग्रामर आया और कोड कवरेज के बारे में एक ही सवाल पूछा।

"80 प्रतिशत और कम नहीं!" मास्टर ने एक कठोर आवाज़ में जवाब दिया, मेज पर अपनी मुट्ठी तेज़ कर दिया।

तीसरा प्रोग्रामर मुस्कुराया, झुका, और छोड़ दिया।

...

इस आखिरी उत्तर के बाद, एक युवा प्रशिक्षु ने महान गुरु से संपर्क किया:

"महान गुरु, आज मैंने आपको तीन अलग-अलग उत्तरों के साथ कोड कवरेज के बारे में एक ही सवाल का जवाब दिया। क्यूं कर?"

महान गुरु अपनी कुर्सी से खड़ा था:

"आओ मेरे साथ कुछ ताजा चाय लें और चलिए इसके बारे में बात करें।"

गर्म हरी चाय धूम्रपान करने के साथ अपने कप भरने के बाद, महान गुरु ने जवाब देना शुरू किया:

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

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

युवा प्रशिक्षु ने कहा, "मैं देखता हूं," लेकिन यदि कोई आसान जवाब नहीं है, तो आपने तीसरे प्रोग्रामर 'अष्ट प्रतिशत और कम नहीं' का जवाब क्यों दिया? "

महान गुरु इतने कठोर और जोर से हँसे कि उसके पेट, साक्ष्य कि वह सिर्फ हरी चाय से ज्यादा पीता है, ऊपर और नीचे flopped।

"तीसरा प्रोग्रामर केवल साधारण उत्तर चाहता है - यहां तक ​​कि जब कोई आसान जवाब नहीं है ... और तब भी उनका पालन नहीं करता है।"

युवा प्रशिक्षु और ग्रिज्ड महान गुरु ने चिंतनशील चुप्पी में अपनी चाय पीना समाप्त कर दिया।

यदि आप यूनिट परीक्षणों के लिए न्यूनतम प्रतिशत कोड-कवरेज जरूरी थे, तो शायद एक भंडार करने की आवश्यकता के रूप में भी, यह क्या होगा?

कृपया बताएं कि आप अपने उत्तर पर कैसे पहुंचे (क्योंकि यदि आपने जो कुछ किया वह एक नंबर ले गया था, तो मैं इसे सब कुछ कर सकता था;)


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

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


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

इस प्रश्न को कुछ इस तरह से खारिज करना आसान है:

  • कवर लाइनें परीक्षण तर्क के बराबर नहीं होती हैं और किसी को प्रतिशत में बहुत ज्यादा नहीं पढ़ना चाहिए।

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

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

कोड कवरेज मीट्रिक का उपयोग करते समय आपको केवल एक निश्चित (मनमानी) प्रतिशत नहीं होना चाहिए जो पूरा होना चाहिए। ऐसा करने से आपको मेरी राय में कोड कवरेज विश्लेषण का वास्तविक लाभ नहीं मिलता है। इसके बजाय, निम्नलिखित मेट्रिक्स को परिभाषित करें:

  • कम जल चिह्न (एलडब्ल्यूएम), परीक्षण के तहत सिस्टम में कभी भी अनदेखी लाइनों की सबसे कम संख्या
  • हाई वाटर मार्क (एचडब्लूएम), परीक्षण के तहत सिस्टम के लिए कभी भी उच्चतम कोड कवरेज प्रतिशत देखा जाता है

नया कोड केवल तभी जोड़ा जा सकता है जब हम एलडब्ल्यूएम से ऊपर नहीं जाते हैं और हम एचडब्लूएम के नीचे नहीं जाते हैं। दूसरे शब्दों में, कोड कवरेज को कम करने की अनुमति नहीं है , और नया कोड कवर किया जाना चाहिए। ध्यान दें कि मैं कैसे कहूं और नहीं करना चाहिए (नीचे समझाया गया है)।

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

  • टेस्टेबल कोड को बढ़ावा दिया जाता है। नया कोड जोड़ते समय आपको कोड को टेस्ट करने योग्य बनाने का प्रयास करना पड़ता है, क्योंकि आपको अपने परीक्षण मामलों के साथ इसे सभी को आज़माकर कवर करना होगा। टेस्टेबल कोड आमतौर पर एक अच्छी बात है।

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

और फिर, यदि फीडबैक लूप बहुत लंबा है तो यह एकीकरण प्रक्रिया में ऐसा कुछ स्थापित करने के लिए पूरी तरह से अप्रत्याशित हो सकता है।

मैं कोड कवरेज मीट्रिक के दो और सामान्य लाभों का भी उल्लेख करना चाहूंगा।

  • कोड कवरेज विश्लेषण गतिशील कोड विश्लेषण का हिस्सा है (स्थिर स्थिर, यानी लिंट के विपरीत)। गतिशील कोड विश्लेषण के दौरान पाए गए समस्याएं (शुद्ध परिवार जैसे उपकरण, http://www-03.ibm.com/software/products/en/rational-purify-family ) अनियमित स्मृति रीड (यूएमआर) जैसी चीजें हैं, मेमोरी लीक इत्यादि। ये समस्याएं केवल तभी मिल सकती हैं जब कोड निष्पादित परीक्षण केस द्वारा कवर किया जाता है । एक परीक्षण मामले में कवर करने वाला सबसे कठिन कोड आमतौर पर सिस्टम में असामान्य मामलों में होता है, लेकिन यदि आप चाहते हैं कि सिस्टम गहराई से विफल हो (यानी क्रैश के बजाय त्रुटि ट्रेस) तो आप असामान्य मामलों को कवर करने में कुछ प्रयास करना चाहेंगे गतिशील कोड विश्लेषण में भी। थोड़ी सी बुरी किस्मत के साथ, एक यूएमआर एक सीगफॉल्ट या बदतर हो सकता है।

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

और पूर्ण, पूर्णता के लिए।

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

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

नेट दुनिया में लोग अक्सर तर्कसंगत के रूप में 80% उद्धृत करते हैं। लेकिन वे इसे समाधान स्तर पर कहते हैं। मैं प्रोजेक्ट लेवल पर मापना पसंद करता हूं: यूआई प्रोजेक्ट के लिए 30% ठीक हो सकता है यदि आपके पास सेलेनियम, आदि या मैन्युअल परीक्षण हैं, तो डेटा लेयर प्रोजेक्ट के लिए 20% ठीक हो सकता है, लेकिन 95% + व्यवसाय के लिए काफी हद तक उपलब्ध हो सकता है नियम परत, अगर पूरी तरह से जरूरी नहीं है। तो कुल कवरेज 60% कह सकता है, लेकिन महत्वपूर्ण व्यावसायिक तर्क बहुत अधिक हो सकता है।

मैंने यह भी सुना है: 100% की इच्छा है और आप 80% हिट करेंगे; लेकिन 80% की इच्छा है और आप 40% हिट करेंगे।

निचली पंक्ति: 80:20 नियम लागू करें, और अपने ऐप की बग गिनती आपको मार्गदर्शन दें।


कोड कवरेज एक भ्रामक मीट्रिक है यदि 100% कवरेज आपका लक्ष्य है (सभी सुविधाओं के 100% परीक्षण के बजाय)।

  • आप एक बार सभी लाइनों को मारकर 100% प्राप्त कर सकते हैं। हालांकि आप अभी भी एक विशेष अनुक्रम (तार्किक पथ) का परीक्षण करना याद कर सकते हैं जिसमें उन पंक्तियों को हिट किया जाता है।
  • आपको 100% प्राप्त नहीं हो सका लेकिन अभी भी आपके सभी 80% / freq प्रयुक्त कोड-पथ का परीक्षण किया है। परीक्षणों का परीक्षण करने वाले प्रत्येक 'फेंक अपवाद टाइपपेक्स' या आपके द्वारा डाले गए समान रक्षात्मक प्रोग्रामिंग गार्ड का परीक्षण करना 'अच्छा होना' है, 'होना चाहिए'

तो अपने आप को या अपने डेवलपर्स पर भरोसा रखें और उनके कोड के माध्यम से हर पथ को कवर करें। व्यावहारिक बनें और जादुई 100% कवरेज का पीछा न करें। यदि आप अपना कोड टीडीडी करते हैं तो आपको बोनस के रूप में 90% + कवरेज प्राप्त करना चाहिए। आपके द्वारा छोड़े गए कोड के हिस्सों को हाइलाइट करने के लिए कोड-कवरेज का उपयोग करें (यदि आप टीडीडी हालांकि नहीं होते हैं तो ऐसा नहीं होना चाहिए .. चूंकि आप केवल परीक्षा पास करने के लिए कोड लिखते हैं। इसके सहयोगी परीक्षण के बिना कोई कोड मौजूद नहीं हो सकता है।)


कोड कवरेज बहुत अच्छा है, लेकिन कार्यक्षमता कवरेज भी बेहतर है। मैं लिखने वाली प्रत्येक पंक्ति को कवर करने में विश्वास नहीं करता हूं। लेकिन मैं उन सभी कार्यक्षमताओं का 100% परीक्षण कवरेज लिखने में विश्वास करता हूं जो मैं प्रदान करना चाहता हूं (यहां तक ​​कि मेरे साथ आने वाली अतिरिक्त शानदार सुविधाओं के लिए और जिनसे मीटिंग के दौरान चर्चा नहीं हुई थी)।

मुझे कोई परवाह नहीं है कि मेरे पास कोड होगा जो परीक्षणों में शामिल नहीं है, लेकिन मुझे परवाह होगा कि क्या मैं अपना कोड दोबारा कर दूंगा और एक अलग व्यवहार करूँगा। इसलिए, 100% कार्यक्षमता कवरेज मेरा एकमात्र लक्ष्य है।


कोड कवरेज सिर्फ एक और मीट्रिक है। अपने और अपने आप में, यह बहुत भ्रामक हो सकता है ( www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated देखें)। इसलिए आपका लक्ष्य 100% कोड कवरेज प्राप्त नहीं करना चाहिए बल्कि यह सुनिश्चित करने के लिए कि आप अपने आवेदन के सभी प्रासंगिक परिदृश्यों का परीक्षण करें।


कोड की गंभीरता के आधार पर, 75% -85% से कहीं भी अंगूठे का एक अच्छा नियम है। शिपिंग कोड निश्चित रूप से घरेलू उपयोगिताओं आदि की तुलना में अधिक अच्छी तरह से परीक्षण किया जाना चाहिए।


जब मुझे लगता है कि मेरा कोड इकाई का परीक्षण नहीं किया गया है, और मुझे यकीन नहीं है कि आगे क्या परीक्षण करना है, तो मैं यह तय करने में सहायता के लिए कवरेज का उपयोग करता हूं कि आगे क्या परीक्षण करना है।

अगर मैं यूनिट टेस्ट में कवरेज बढ़ाता हूं - मुझे इस यूनिट टेस्ट के बारे में कुछ पता है।

यह कोड के लिए जाता है जो कवर नहीं है, 50% कवर या 97% कवर किया गया है।


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


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


मुझे लगता है कि सही कोड कवरेज का सबसे अच्छा लक्षण यह है कि ठोस समस्याओं की इकाई परीक्षण परीक्षणों को ठीक करने में मदद करता है जो आपके द्वारा बनाए गए यूनिट परीक्षण कोड के आकार के अनुरूप है।


मेरी राय में, जवाब है "यह इस बात पर निर्भर करता है कि आपके पास कितना समय है"। मैं 100% हासिल करने की कोशिश करता हूं लेकिन अगर मुझे यह समय नहीं मिलता है तो मैं झगड़ा नहीं करता हूं।

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

मैं आमतौर पर निम्नलिखित मानदंडों या नियमों का पालन करता हूं:

  1. यूनिट टेस्ट दस्तावेजों का एक रूप होना चाहिए जो मेरे कोड के अपेक्षित व्यवहार है, यानी। अपेक्षित आउटपुट को एक निश्चित इनपुट दिया गया है और अपवाद यह फेंक सकता है कि ग्राहक पकड़ना चाहते हैं (मेरे कोड के उपयोगकर्ताओं को क्या पता होना चाहिए?)

  2. यूनिट टेस्ट को मुझे यह जानने में मदद करनी चाहिए कि क्या शर्तों को मैंने अभी तक नहीं सोचा है। (मेरा कोड स्थिर और मजबूत कैसे बनाएं?)

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


मेरे पास टेस्ट कवरेज पर एक और एक्टोड होगा जो मैं साझा करना चाहता हूं।

हमारे पास एक बड़ी परियोजना है जिसमें ट्विटर पर, मैंने नोट किया कि, 700 यूनिट परीक्षणों के साथ, हमारे पास केवल 20% कोड कवरेज है

स्कॉट हंसेलमैन ने ज्ञान के शब्दों के साथ जवाब दिया:

क्या यह सही 20% है? क्या यह 20% है जो आपके उपयोगकर्ताओं द्वारा सबसे ज्यादा प्रभावित कोड का प्रतिनिधित्व करता है? आप 50 और परीक्षण जोड़ सकते हैं और केवल 2% जोड़ सकते हैं।

फिर, यह कोड कवरेज उत्तर पर मेरे टेस्टिवस पर वापस चला जाता है। आप बर्तन में कितना चावल डाल देना चाहिए? निर्भर करता है।


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

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

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


यदि आप एक सभ्य समय के लिए यूनिट परीक्षण कर रहे हैं, तो मुझे इसके लिए कोई कारण नहीं दिखता कि 95% + न हो। हालांकि, कम से कम, मैंने परीक्षण करने के लिए नए होने पर भी 80% के साथ काम किया है।

इस संख्या में केवल प्रोजेक्ट में लिखे गए कोड शामिल हैं (ढांचे, प्लगइन्स इत्यादि को छोड़कर) और यहां तक ​​कि बाहरी कोड पर कॉल के लिखे गए कोड से पूरी तरह से तैयार कुछ वर्गों को भी बाहर रखा जाना चाहिए। इस प्रकार की कॉल को मॉक / स्टब्ड किया जाना चाहिए।


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


यह आपके आवेदन विकास जीवन चक्र के चरण में निर्भर होना चाहिए।

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

आपके डोमेन के आधार पर 95% के लिए शूट करने के लिए अनुचित नहीं है, लेकिन मुझे औसतन 85% से 90% के औसत मामले को देखने के लिए कहना होगा।


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

मैं ऐसा करने पर एक शॉट ले जाऊंगा। मैं टेस्ट इंजीनियरिंग में विशेषज्ञ नहीं हूं और एक और सूचित उत्तर देखने में प्रसन्नता होगी।

कोड कवरेज आवश्यकताओं को कब सेट करें

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

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

कुछ विशिष्ट मामलों जहां एक अनुभवजन्य मानक होने से मूल्य जोड़ सकता है:

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

उपयोग करने के लिए कौन सा मीट्रिक

कोड कवरेज एक मीट्रिक नहीं है; कवरेज को मापने के कई अलग-अलग तरीके हैं। आप जिस पर मानक निर्धारित कर सकते हैं उस पर निर्भर करता है कि आप उस मानक का उपयोग करने के लिए उस मानक का उपयोग कर रहे हैं।

मैं दो सामान्य मीट्रिक का उपयोग उदाहरण के रूप में कर सकता हूं जब आप मानकों को सेट करने के लिए उनका उपयोग कर सकते हैं:

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

कई अन्य मीट्रिक हैं (लाइन कवरेज कथन कवरेज के समान है, लेकिन उदाहरण के लिए मल्टी-लाइन स्टेटमेंट के लिए अलग-अलग संख्यात्मक परिणाम प्राप्त करता है; सशर्त कवरेज और पथ कवरेज शाखा कवरेज के समान है, लेकिन संभावित क्रमिकताओं के बारे में अधिक विस्तृत दृश्य दर्शाता है कार्यक्रम निष्पादन आप सामना कर सकते हैं।)

आवश्यकता के लिए प्रतिशत क्या है

अंत में, मूल प्रश्न पर वापस जाएं: यदि आप कोड कवरेज मानकों को सेट करते हैं, तो यह संख्या क्या होनी चाहिए?

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

कुछ संख्याएं जो कोई चुन सकती हैं:

  • 100% आप इसे चुन सकते हैं क्योंकि आप यह सुनिश्चित करना चाहते हैं कि सब कुछ परीक्षण किया गया हो। यह आपको परीक्षण की गुणवत्ता में कोई अंतर्दृष्टि नहीं देता है, लेकिन आपको बताता है कि कुछ गुणवत्ता के कुछ परीक्षण ने प्रत्येक कथन (या शाखा इत्यादि) को फिर से छुआ है, यह आत्मविश्वास की डिग्री पर वापस आ गया है: यदि आपका कवरेज 100% से नीचे है , आप जानते हैं कि आपके कोड का कुछ सबसेट अनचाहे है।
    • कुछ लोग तर्क दे सकते हैं कि यह मूर्खतापूर्ण है, और आपको केवल अपने कोड के उन हिस्सों का परीक्षण करना चाहिए जो वास्तव में महत्वपूर्ण हैं। मैं तर्क दूंगा कि आपको केवल अपने कोड के उन हिस्सों को बनाए रखना चाहिए जो वास्तव में महत्वपूर्ण हैं। अवांछित कोड को हटाकर भी कोड कवरेज में सुधार किया जा सकता है।
  • 99% (या 9 5%, उच्च नब्बे के दशक में अन्य नंबर।) उन मामलों में उपयुक्त जहां आप आत्मविश्वास का स्तर 100% के समान व्यक्त करना चाहते हैं, लेकिन कभी-कभार हार्ड-टू-टेस्ट कोने के बारे में चिंता न करने के लिए खुद को कुछ मार्जिन छोड़ दें कोड।
  • 80% मैंने इस नंबर को कुछ बार उपयोग में देखा है, और पूरी तरह से यह नहीं पता कि यह कहां से उत्पन्न होता है। मुझे लगता है कि यह 80-20 नियम का अजीब दुरूपयोग हो सकता है; आम तौर पर, यह इरादा यह दिखाने के लिए है कि आपके अधिकांश कोड का परीक्षण किया जाता है। (हां, 51% भी "सबसे अधिक" होगा, लेकिन 80% अधिकतर लोगों द्वारा अधिकतर लोगों के लिए अधिक प्रतिबिंबित होता है।) यह मध्य-भूमि के मामलों के लिए उपयुक्त है जहां "अच्छी तरह से परीक्षण" उच्च प्राथमिकता नहीं है (आप डॉन ' टी कम मूल्य परीक्षणों पर प्रयास बर्बाद करना चाहते हैं), लेकिन यह एक प्राथमिकता है कि आप अभी भी कुछ मानक रखना चाहते हैं।

मैंने प्रैक्टिस में 80% से नीचे की संख्या नहीं देखी है, और एक ऐसे मामले की कल्पना करने में कठिन समय है जहां कोई उन्हें सेट करेगा। इन मानकों की भूमिका शुद्धता में विश्वास बढ़ाने के लिए है, और 80% से नीचे की संख्या विशेष रूप से आत्मविश्वास-प्रेरणादायक नहीं है। (हां, यह व्यक्तिपरक है, लेकिन फिर, विचार यह है कि जब आप मानक निर्धारित करते हैं तो एक बार व्यक्तिपरक विकल्प बनाना है, और फिर आगे बढ़ने के उद्देश्य से उपयोग करें।)

अन्य नोट

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


हम कुछ दिनों पहले> 80% लक्ष्यीकरण कर रहे थे, लेकिन जब हमने बहुत से जेनरेटेड कोड का उपयोग किया, तो हमें% उम्र की परवाह नहीं है, बल्कि समीक्षाकर्ता को आवश्यक कवरेज पर कॉल करने के लिए तैयार करें।





code-metrics