कोड अखंडता

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

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

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

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


 * कोड का यूनिट परीक्षण
 * एकीकरण जांच
 * को़ड समीक्षा
 * एआई-आधारित कोड विश्लेषण
 * स्वचालित परीक्षण
 * एक कोड अखंडता प्रबंधक असाइन करना

शुद्धता-जांच पूर्णता मेट्रिक्स के उदाहरण:


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

शिफ्ट-लेफ्ट कोड इंटीग्रिटी के फायदे


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

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