कोड अखंडता: Difference between revisions
No edit summary |
No edit summary |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 7: | Line 7: | ||
== शिफ्ट-लेफ्ट टेस्टिंग और शिफ्ट-लेफ्ट कोड इंटीग्रिटी == | == शिफ्ट-लेफ्ट टेस्टिंग और शिफ्ट-लेफ्ट कोड इंटीग्रिटी == | ||
कोड अखंडता का अभ्यास करने वाली कंपनियां क्लासिक परिदृश्य से बचती हैं जहां विकास चरण में देरी हो रही है, क्यूए चरण में देरी हो रही है, रिलीज चरण में देरी हो रही है। कोड अखंडता को नहीं अपनाने वाली कंपनियों के उत्पाद अधिक बग (समय के दबाव के कारण) के साथ जारी किए जाते हैं, उपयोगकर्ता विकास टीम को टन बग वापस रिपोर्ट करते हैं, और संस्करण 1.0 जारी करने के तुरंत बाद वे संस्करण 1.1 पर काम करना प्रारंभ करते हैं, केवल बग को ठीक करने के लिए टाला जा सकता था। | कोड अखंडता का अभ्यास करने वाली कंपनियां क्लासिक परिदृश्य से बचती हैं जहां विकास चरण में देरी हो रही है, क्यूए चरण में देरी हो रही है, रिलीज चरण में देरी हो रही है। कोड अखंडता को नहीं अपनाने वाली कंपनियों के उत्पाद अधिक बग (समय के दबाव के कारण) के साथ जारी किए जाते हैं, उपयोगकर्ता विकास टीम को टन बग वापस रिपोर्ट करते हैं, और संस्करण 1.0 जारी करने के तुरंत बाद वे संस्करण 1.1 पर काम करना प्रारंभ करते हैं, केवल बग को ठीक करने के लिए टाला जा सकता था। | ||
शिफ्ट-लेफ्ट परीक्षण सॉफ्टवेयर विकास की प्रारंभिक प्रक्रियाओं के समय संबंधित परीक्षण करने की एक विधि है, क्योंकि क्यूए विभाग कोड की अखंडता को उनके सभी परीक्षणों के चलने के बाद भी माप नहीं सकता है। शिफ्ट-लेफ्ट टेस्टिंग और कोड इंटीग्रिटी कसकर जुड़े हुए हैं, किन्तु इंटीग्रिटी में न केवल जॉब का टेस्टिंग पार्ट होता है, जो शिफ्ट-लेफ्ट कोड इंटीग्रिटी की बड़ी प्रक्रिया का एक उप-कार्य है। यह प्रक्रिया न केवल उच्च कोड कवरेज के साथ अधिक ईकाई परीक्षण प्रयुक्त करती है, चूँकि प्रासंगिक डेटा के विरुद्ध विभिन्न अन्य शुद्धता-जांच प्रक्रियाओं को भी सम्मिलित करती है।<ref>{{cite web |title=High Level Test Driven Development – Shift Left |url=https://link.springer.com/chapter/10.1007/978-3-319-18612-2_23 |access-date=15 March 2023}}</ref> यहां कुछ उदाहरण दिए गए हैं: | शिफ्ट-लेफ्ट परीक्षण सॉफ्टवेयर विकास की प्रारंभिक प्रक्रियाओं के समय संबंधित परीक्षण करने की एक विधि है, क्योंकि क्यूए विभाग कोड की अखंडता को उनके सभी परीक्षणों के चलने के बाद भी माप नहीं सकता है। शिफ्ट-लेफ्ट टेस्टिंग और कोड इंटीग्रिटी कसकर जुड़े हुए हैं, किन्तु इंटीग्रिटी में न केवल जॉब का टेस्टिंग पार्ट होता है, जो शिफ्ट-लेफ्ट कोड इंटीग्रिटी की बड़ी प्रक्रिया का एक उप-कार्य है। यह प्रक्रिया न केवल उच्च कोड कवरेज के साथ अधिक ईकाई परीक्षण प्रयुक्त करती है, चूँकि प्रासंगिक डेटा के विरुद्ध विभिन्न अन्य शुद्धता-जांच प्रक्रियाओं को भी सम्मिलित करती है।<ref>{{cite web |title=High Level Test Driven Development – Shift Left |url=https://link.springer.com/chapter/10.1007/978-3-319-18612-2_23 |access-date=15 March 2023}}</ref> यहां कुछ उदाहरण दिए गए हैं: | ||
| Line 33: | Line 33: | ||
== शिफ्ट-बाएं कोड अखंडता सक्षमता == | == शिफ्ट-बाएं कोड अखंडता सक्षमता == | ||
यह अवधारणा इस तथ्य पर आधारित है कि डेवलपर्स तकनीकी लाभ का पूरा उपयोग करने में सक्षम होंगे यदि उनके पास प्रारंभ से ही प्रासंगिक परीक्षण उपकरण उपलब्ध हों। जैसे-जैसे नए सॉफ्टवेयर अधिक से अधिक जटिल होते जाते हैं और अधिक निर्भरताएं सम्मिलित होती हैं, डेवलपर्स की भूमिकाओं में [[बी मॉडल]] के दाहिने भाग सहित, उन्हें ईकाई परीक्षण और एकीकरण प्रक्रियाओं का नियंत्रण ग्रहण करने में सहायता मिलेगी।<ref name="wim">{{cite web |author1=Gadi Zimerman |title=Tests are not enough – Why code integrity matters? |url=https://www.codium.ai/blog/tests-are-not-enough-why-code-integrity-matters |access-date=16 March 2023 |date=11 November 2022}}</ref><ref>{{cite journal |author1=Rook, Paul, E. Rook |title=सॉफ्टवेयर परियोजनाओं को नियंत्रित करना|journal=IEEE Software Engineering Journal |date=1986 |volume=1 |issue=1 |page=7-16 |url=https://digital-library.theiet.org/content/journals/10.1049/sej.1986.0003 |access-date=15 March 2023}}</ref> परिणाम डेवलपर्स को कई सॉफ्टवेयर कंपनियों में पूर्ण वातावरण लाने की अनुमति देगा। यह प्रवृत्ति जारी रहने की उम्मीद है क्योंकि कई स्थितियों में पूरे प्रणाली के संदर्भ के बिना इकाई/एकीकरण परीक्षण करना असंभव है।<ref>{{cite web |title=डेवलपर और संचालन के बीच के अंतर को कम करने के लिए DevOps में निरंतर एकीकरण (CI) और सतत वितरण (CD) परिनियोजन का उपयोग करने का प्रभाव|url=https://ieeexplore.ieee.org/abstract/document/9994139 |access-date=15 March 2023}}</ref> | यह अवधारणा इस तथ्य पर आधारित है कि डेवलपर्स तकनीकी लाभ का पूरा उपयोग करने में सक्षम होंगे यदि उनके पास प्रारंभ से ही प्रासंगिक परीक्षण उपकरण उपलब्ध हों। जैसे-जैसे नए सॉफ्टवेयर अधिक से अधिक जटिल होते जाते हैं और अधिक निर्भरताएं सम्मिलित होती हैं, डेवलपर्स की भूमिकाओं में [[बी मॉडल]] के दाहिने भाग सहित, उन्हें ईकाई परीक्षण और एकीकरण प्रक्रियाओं का नियंत्रण ग्रहण करने में सहायता मिलेगी।<ref name="wim">{{cite web |author1=Gadi Zimerman |title=Tests are not enough – Why code integrity matters? |url=https://www.codium.ai/blog/tests-are-not-enough-why-code-integrity-matters |access-date=16 March 2023 |date=11 November 2022}}</ref><ref>{{cite journal |author1=Rook, Paul, E. Rook |title=सॉफ्टवेयर परियोजनाओं को नियंत्रित करना|journal=IEEE Software Engineering Journal |date=1986 |volume=1 |issue=1 |page=7-16 |url=https://digital-library.theiet.org/content/journals/10.1049/sej.1986.0003 |access-date=15 March 2023}}</ref> परिणाम डेवलपर्स को कई सॉफ्टवेयर कंपनियों में पूर्ण वातावरण लाने की अनुमति देगा। यह प्रवृत्ति जारी रहने की उम्मीद है क्योंकि कई स्थितियों में पूरे प्रणाली के संदर्भ के बिना इकाई/एकीकरण परीक्षण करना असंभव है।<ref>{{cite web |title=डेवलपर और संचालन के बीच के अंतर को कम करने के लिए DevOps में निरंतर एकीकरण (CI) और सतत वितरण (CD) परिनियोजन का उपयोग करने का प्रभाव|url=https://ieeexplore.ieee.org/abstract/document/9994139 |access-date=15 March 2023}}</ref> | ||
==संदर्भ == | ==संदर्भ == | ||
{{reflist}} | {{reflist}} | ||
{{Software-eng-stub}} | {{Software-eng-stub}} | ||
{{DEFAULTSORT:Code Integrity}} | {{DEFAULTSORT:Code Integrity}} | ||
[[Category: | [[Category:All stub articles|Code Integrity]] | ||
[[Category:Created On 15/05/2023]] | [[Category:CS1 maint]] | ||
[[Category:Created On 15/05/2023|Code Integrity]] | |||
[[Category:Machine Translated Page|Code Integrity]] | |||
[[Category:Pages with script errors|Code Integrity]] | |||
[[Category:Software engineering stubs|Code Integrity]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:सॉफ़्टवेयर परीक्षण|Code Integrity]] | |||
Latest revision as of 10:04, 12 June 2023
कोड अखंडता एक माप है जिसका उपयोग सॉफ़्टवेयर वितरण जीवनचक्र में किया जाता है। यह मापता है कि गुणवत्ता आश्वासन के लिए पारित होने पर स्रोत कोड की गुणवत्ता कितनी उच्च होती है, और शुद्धता-जांच प्रक्रियाओं (चाहे मैन्युअल या स्वचालित) द्वारा कोड को कितनी अच्छी तरह से संसाधित किया गया था, इससे प्रभावित होता है। ऐसी शुद्धता-जांच प्रक्रियाओं के उदाहरण इकाई परीक्षण और एकीकरण परीक्षण, कोड समीक्षा, परीक्षण स्वचालन, एआई-आधारित कोड विश्लेषण इत्यादि हो सकते हैं।[1] कोड अखंडता मेट्रिक्स के साथ कोड शुद्धता प्रक्रियाओं (सॉफ्टवेयर गुणवत्ता) को प्रयुक्त करने का संयोजन है जो इन शुद्धता-जांच प्रक्रियाओं की पूर्णता को मापता है, जैसे, उदाहरण के लिए, कोड कवरेज जबकि कोड अखंडता सामान्यतः उच्च कोड कवरेज तक पहुंचने के लिए स्रोत कोड का परीक्षण करके प्राप्त की जाती है, यह निश्चित रूप से कोड अखंडता प्राप्त करने का एकमात्र विधि या सबसे अच्छा विधि नहीं है। वास्तव में, कोड कवरेज, ईकाई परीक्षणों की पूर्णता को मापने के लिए एक लोकप्रिय मीट्रिक वास्तविक कोड अखंडता के माप के साथ सीमित सहसंबंध के लिए जाना जाता है।[2]
डेवलपर का विश्वास
कोड अखंडता केवल कोड की शुद्धता के बारे में नहीं है, चूँकि डेवलपर्स के अपने कोड की शुद्धता के बारे में विश्वास के बारे में भी है। कोड अखंडता के साथ, डेवलपर यह सुनिश्चित कर सकता है कि क्यूए को पास करते समय उसका कोड सही विधि से लिखा गया है। वास्तव में यह कोड का अपेक्षित गुणवत्ता स्तर है। कोड अखंडता डेवलपर्स और कंपनियों को कम समय में कम बग के साथ उत्तम उत्पाद जारी करने में सहायता करती है।[3]
शिफ्ट-लेफ्ट टेस्टिंग और शिफ्ट-लेफ्ट कोड इंटीग्रिटी
कोड अखंडता का अभ्यास करने वाली कंपनियां क्लासिक परिदृश्य से बचती हैं जहां विकास चरण में देरी हो रही है, क्यूए चरण में देरी हो रही है, रिलीज चरण में देरी हो रही है। कोड अखंडता को नहीं अपनाने वाली कंपनियों के उत्पाद अधिक बग (समय के दबाव के कारण) के साथ जारी किए जाते हैं, उपयोगकर्ता विकास टीम को टन बग वापस रिपोर्ट करते हैं, और संस्करण 1.0 जारी करने के तुरंत बाद वे संस्करण 1.1 पर काम करना प्रारंभ करते हैं, केवल बग को ठीक करने के लिए टाला जा सकता था।
शिफ्ट-लेफ्ट परीक्षण सॉफ्टवेयर विकास की प्रारंभिक प्रक्रियाओं के समय संबंधित परीक्षण करने की एक विधि है, क्योंकि क्यूए विभाग कोड की अखंडता को उनके सभी परीक्षणों के चलने के बाद भी माप नहीं सकता है। शिफ्ट-लेफ्ट टेस्टिंग और कोड इंटीग्रिटी कसकर जुड़े हुए हैं, किन्तु इंटीग्रिटी में न केवल जॉब का टेस्टिंग पार्ट होता है, जो शिफ्ट-लेफ्ट कोड इंटीग्रिटी की बड़ी प्रक्रिया का एक उप-कार्य है। यह प्रक्रिया न केवल उच्च कोड कवरेज के साथ अधिक ईकाई परीक्षण प्रयुक्त करती है, चूँकि प्रासंगिक डेटा के विरुद्ध विभिन्न अन्य शुद्धता-जांच प्रक्रियाओं को भी सम्मिलित करती है।[4] यहां कुछ उदाहरण दिए गए हैं:
- कोड का ईकाई परीक्षण
- एकीकरण जांच
- को़ड समीक्षा
- एआई-आधारित कोड विश्लेषण
- स्वचालित परीक्षण
- एक कोड अखंडता प्रबंधक असाइन करना
शुद्धता-जांच पूर्णता मेट्रिक्स के उदाहरण:
- शुद्ध कोड अखंडता मीट्रिक सूत्रीकरण है: 1 - (गैर-कवर किए गए बग) / (कुल बग), शब्दों में: सही कोड अखंडता माइनस बग की संख्या जो इकाई परीक्षण द्वारा कवर नहीं की गई थी, के समय पाए गए कुल बग से विभाजित विकास सहित संपूर्ण उत्पाद चक्र, कोड अखंडता में नहीं है।
- विभिन्न प्रकार के कोड कवरेज (लाइन-कवरेज, शाखा-कवरेज आदि)
- उत्परिवर्तन परीक्षण
शिफ्ट-लेफ्ट कोड इंटीग्रिटी के लाभ
- कम विकास समय - विकास के चरण के समय पाए जाने वाले बग को बाद के चरणों में पाए जाने वाले बग की तुलना में तेजी से और आसानी से ठीक किया जाता है।
- कम विकास लागत - बाद के चरणों की तुलना में विकास चरण के समय पाए जाने वाले बग को ठीक करना सस्ता है।
- अपने कोड की गुणवत्ता में विश्वास - उच्च कोड अखंडता वाले उत्पादों को जारी करने का अर्थ है आपके ग्राहकों से अधिक सकारात्मक प्रतिक्रिया है ।
- क्यूए के काम को और अधिक कुशल बनाता है - क्यूए बग के बारे में चिंता किए बिना प्रणाली के परीक्षण पर ध्यान केंद्रित करता है जो उचित इकाई परीक्षण के माध्यम से आसानी से पाया जा सकता था।
शिफ्ट-बाएं कोड अखंडता सक्षमता
यह अवधारणा इस तथ्य पर आधारित है कि डेवलपर्स तकनीकी लाभ का पूरा उपयोग करने में सक्षम होंगे यदि उनके पास प्रारंभ से ही प्रासंगिक परीक्षण उपकरण उपलब्ध हों। जैसे-जैसे नए सॉफ्टवेयर अधिक से अधिक जटिल होते जाते हैं और अधिक निर्भरताएं सम्मिलित होती हैं, डेवलपर्स की भूमिकाओं में बी मॉडल के दाहिने भाग सहित, उन्हें ईकाई परीक्षण और एकीकरण प्रक्रियाओं का नियंत्रण ग्रहण करने में सहायता मिलेगी।[3][5] परिणाम डेवलपर्स को कई सॉफ्टवेयर कंपनियों में पूर्ण वातावरण लाने की अनुमति देगा। यह प्रवृत्ति जारी रहने की उम्मीद है क्योंकि कई स्थितियों में पूरे प्रणाली के संदर्भ के बिना इकाई/एकीकरण परीक्षण करना असंभव है।[6]
संदर्भ
- ↑ "स्रोत कोड विश्लेषण के लिए मशीन लर्निंग तकनीक पर एक सर्वेक्षण". Retrieved 15 March 2023.
- ↑ "How Effective Are Code Coverage Criteria?". Retrieved 15 March 2023.
- ↑ 3.0 3.1 Gadi Zimerman (11 November 2022). "Tests are not enough – Why code integrity matters?". Retrieved 16 March 2023.
- ↑ "High Level Test Driven Development – Shift Left". Retrieved 15 March 2023.
- ↑ Rook, Paul, E. Rook (1986). "सॉफ्टवेयर परियोजनाओं को नियंत्रित करना". IEEE Software Engineering Journal. 1 (1): 7-16. Retrieved 15 March 2023.
{{cite journal}}: CS1 maint: multiple names: authors list (link) - ↑ "डेवलपर और संचालन के बीच के अंतर को कम करने के लिए DevOps में निरंतर एकीकरण (CI) और सतत वितरण (CD) परिनियोजन का उपयोग करने का प्रभाव". Retrieved 15 March 2023.
 | This software-engineering-related article is a stub. You can help Wikipedia by expanding it. |
