अब मुझे पता है कि लोग इस प्रश्न पर डुप्लिकेट या कई बार पूछ सकते हैं, जिस स्थिति में मैं अपने प्रश्न के उत्तर के साथ प्रासंगिक प्रश्नों के लिंक की सराहना करूंगा।
मैं हाल ही में कोड कवरेज के बारे में कुछ लोगों से असहमत रहा हूं। मेरे पास ऐसे लोगों का एक समूह है जो चाहते हैं कि हमारी टीम कोड कवरेज को पूरी तरह से इस तर्क के आधार पर देखना छोड़ दे कि 100% कवरेज का मतलब अच्छी गुणवत्ता परीक्षण और इस प्रकार अच्छी गुणवत्ता कोड नहीं है।
मैं इस तर्क को बेचकर पीछे धकेलने में सफल रहा कि कोड कवरेज मुझे बताता है कि क्या सुनिश्चित करने के लिए परीक्षण नहीं किया गया है और हमें उन क्षेत्रों पर ध्यान केंद्रित करने में मदद करता है।
(ऊपर इस तरह से अन्य एसओ सवालों में इसी तरह से चर्चा की गई है - /programming/695811/pitfall-of-code-coverage )
इन लोगों का तर्क है - तब टीम कम गुणवत्ता परीक्षण जल्दी से बनाकर प्रतिक्रिया करेगी और इस तरह समय बर्बाद नहीं करेगी, जबकि कोई महत्वपूर्ण गुणवत्ता नहीं होगी।
जबकि मैं उनकी बात को समझता हूं, मैं अधिक मजबूत उपकरण / रूपरेखा पेश करके कोड कवरेज के लिए अधिक मजबूत मामला बनाने का तरीका खोज रहा हूं जो अधिक कवरेज मानदंडों का ख्याल रखता है(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) ।
जो मैं देख रहा हूं वह ऐसे कोड कवरेज टूल और प्रथाओं / प्रक्रियाओं के संयोजन के लिए सुझाव है जो उनके साथ जाने के लिए है जो मेरी सिफारिश के बारे में सहज महसूस करते हुए मुझे इस तरह के तर्कों का मुकाबला करने में मदद कर सकते हैं।
मैं इस तरह के एक तर्क का मुकाबला करने के तरीके के बारे में आपके अनुभव / ज्ञान के आधार पर किसी भी साथ आने वाली टिप्पणियों / सुझावों का भी स्वागत करूंगा, क्योंकि व्यक्तिपरक होने पर, कोड कवरेज ने मेरी टीम को कोड की गुणवत्ता और परीक्षण के मूल्य के प्रति अधिक सचेत होने में मदद की है।
संपादित करें: ठेठ कोड कवरेज की कमजोरी के बारे में मेरी समझ के बारे में किसी भी भ्रम को कम करने के लिए, मैं इंगित करना चाहता हूं कि मैंStatement Coverage (या निष्पादित कोड की पंक्तियों) टूल का उल्लेख नहीं कर रहा हूं (बहुत सारे हैं)। वास्तव में यहां हर चीज पर एक अच्छा लेख है जो इसके साथ गलत है: http://www.bullseye.com/statementCoverage.html
मैं सिर्फ बयान या लाइन कवरेज से अधिक के लिए देख रहा था, कई कवरेज मानदंडों और स्तरों में अधिक जा रहा था।
देखें: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria
विचार यह है कि यदि कोई टूल हमें कई मानदंडों के आधार पर हमारी कवरेज बता सकता है तो यह परीक्षण गुणवत्ता का एक उचित स्वचालित मूल्यांकन बन जाता है। मैं किसी भी तरह से यह कहने की कोशिश नहीं कर रहा हूं कि लाइन कवरेज एक अच्छा मूल्यांकन है। वास्तव में यही मेरे प्रश्न का आधार है।
संपादित करें:
ठीक है, शायद मैंने इसे थोड़ा नाटकीय रूप से पेश किया, लेकिन आपको यह बात मिल गई। समस्या एक सजातीय / सुसंगत फैशन में सभी टीमों में सामान्य रूप से प्रक्रियाओं / नीतियों को स्थापित करने के बारे में है। और यह आशंका सामान्य है कि आप परीक्षणों की गुणवत्ता कैसे सुनिश्चित करते हैं, आप बिना किसी उपाय के कैसे गारंटी समय आवंटित करते हैं। इस प्रकार मैं एक औसत दर्जे की सुविधा है कि जब उचित प्रक्रियाओं के साथ बैकअप और सही उपकरण हमें कोड गुणवत्ता में सुधार करने की अनुमति देगा, जबकि यह जानते हुए भी कि समय बर्बादी प्रक्रियाओं में खर्च नहीं किया जा रहा है।
संपादित करें: अब तक मेरे पास जवाबों से क्या है:
- परीक्षणों की गुणवत्ता सुनिश्चित करने के लिए कोड समीक्षाओं को परीक्षणों को कवर करना चाहिए
- टेस्ट फर्स्ट स्ट्रैटिजी उन परीक्षणों से बचने में मदद करती है जो केवल कवरेज% बढ़ाने के लिए तथ्य के बाद लिखे जाते हैं
- वैकल्पिक उपकरणों की खोज करना जो केवल कथन / रेखा के अलावा परीक्षण मानदंडों को कवर करते हैं
- कवर किए गए कोड / बगों की संख्या का विश्लेषण कवरेज के महत्व की सराहना करने और एक बेहतर मामला बनाने में मदद करेगा
- सबसे महत्वपूर्ण बात यह है कि टीम के इनपुट को सही काम करने के लिए और अपने विश्वासों के लिए लड़ने के लिए विश्वास करें
- ब्लॉक किए गए / # परीक्षण के - बहस योग्य लेकिन कुछ मूल्य रखता है
अब तक के शानदार जवाब के लिए धन्यवाद। मैं वास्तव में उनकी सराहना करता हूं। यह धागा उन शक्तियों के साथ विचार-मंथन के घंटों से बेहतर है।