🕵🏼 🤟🏾 🙎🏼 पीवीएस-स्टूडियो स्थैतिक कोड विश्लेषक को विकास प्रक्रिया में पेश करने के कारण 🕹️ 💓 🐛

पीवीएस-स्टूडियो स्थैतिक कोडर को विकास प्रक्रिया में पेश करने के कारण

पीवीएस-स्टूडियो सी, सी ++, सी # या जावा में लिखे गए कार्यक्रमों के स्रोत कोड में त्रुटियों और संभावित कमजोरियों को खोजने के लिए एक उपकरण है। PVS-Studio स्थैतिक अनुप्रयोग सुरक्षा परीक्षण (स्थैतिक अनुप्रयोग सुरक्षा परीक्षण, SAST) के लिए उपकरणों के वर्ग से संबंधित है। विश्लेषक निरंतर एकीकरण (सीआई) के अभ्यास पर केंद्रित है और आपको लगभग सभी चरणों में त्रुटियों की पहचान करने की अनुमति देता है जब उन्हें ठीक करने में लगभग कुछ भी खर्च नहीं होता है।

स्थैतिक कोड विश्लेषण

उनके विकास की प्रक्रिया में सॉफ्टवेयर परियोजनाएं अधिक से अधिक बन रही हैं। उदाहरण:

लिनक्स कर्नेल 1.0.0: कोड की 176,000 लाइनें
लिनक्स कर्नेल 5.0: कोड की 26,000,000 लाइनें
फोटोशॉप 1.0: 128,000 कोड की लाइनें
Photoshop CS 6: कोड की 10,000,000 लाइनें

जैसे ही एक परियोजना आकार में बढ़ती है, इसकी जटिलता रैखिक रूप से तेजी से बढ़ती है। इस कारण से, जैसा कि कोड आधार का आकार बढ़ता है, इसलिए त्रुटियों का घनत्व होता है। बढ़ती जटिलता के लिए क्षतिपूर्ति करने का एक तरीका स्थिर कोड विश्लेषण टूल का उपयोग करना है।

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

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

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

स्थैतिक विश्लेषण उपकरणों का एक और लाभ त्रुटि पैटर्न के एक समृद्ध डेटाबेस की उपस्थिति है। वे उन समस्याओं का पता लगा सकते हैं जिनके बारे में प्रोग्रामर को भी जानकारी नहीं होगी। कुछ उदाहरण: V698 , V718 , V1023 ।

पी वी एस-स्टूडियो

हम पीवीएस-स्टूडियो स्थैतिक कोड विश्लेषक को लागू करने की सलाह देते हैं जिसे हमने विकास प्रक्रिया में विकसित किया है। उत्पाद विंडोज, लिनक्स, और मैकओएस पर 64-बिट सिस्टम पर चलता है और 32-बिट, 64-बिट और एम्बेडेड एआरएम प्लेटफार्मों के लिए कोड का विश्लेषण कर सकता है।

इस लेख के प्रकाशन के समय, विश्लेषक निम्नलिखित भाषाओं और संकलकों का समर्थन करता है:

विंडोज। विज़ुअल स्टूडियो 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
विंडोज। आईएआर एंबेडेड वर्कबेंच, एआर / सी के लिए सी / सी ++ कंपाइलर, सी ++
विंडोज। क्यूएनएक्स मोमेंटिक्स, क्यूसीसी सी, सी ++
विंडोज / लिनक्स केएल ilविज़न, डीएस-एमडीके, एआरएम कंपाइलर 5/6 सी, सी ++
विंडोज / लिनक्स टेक्सास इंस्ट्रूमेंट्स कोड कम्पोज़र स्टूडियो, एआरएम कोड जेनरेशन टूल्स सी, सी ++
विंडोज / लिनक्स / मैकओएस। जीएनयू आर्म एंबेडेड टूलचिन, आर्म एंबेडेड जीसीसी कंपाइलर, सी, सी ++
विंडोज / लिनक्स / मैकओएस। क्लेंग सी, सी ++
लिनक्स / macOS। जीसीसी सी, सी ++
विंडोज। MinGW C, C ++
विंडोज / लिनक्स / मैकओएस। जावा

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

PVS-Studio को SAST टूल के रूप में उपयोग करने वाले विशेषज्ञों की सुविधा के लिए, विश्लेषक सामान्य कमजोरता गणना, SEI CERT कोडिंग मानकों और MISRA मानक पर अपनी चेतावनी प्रदर्शित करता है। विभिन्न मानकों के लिए पीवीएस-स्टूडियो डायग्नोस्टिक्स की अनुपालन तालिकाएँ:

विश्लेषक स्वतंत्र रूप से और Visual Studio और IntelliJ IDEA दोनों के साथ उपयोग किया जा सकता है। इसके अलावा, हाल ही में हमारे कई ग्राहक सोनारक्यूब के हिस्से के रूप में पीवीएस-स्टूडियो का उपयोग कर रहे हैं। पीवीएस-स्टूडियो, सोनारक्यूब के प्लग- इन के रूप में जुड़ा हुआ है, नैदानिक संदेशों का एक अतिरिक्त स्रोत है।

CI में विभिन्न एकीकरण परिदृश्यों पर काम किया गया है। सभी परिदृश्यों पर विचार करना इस लेख के दायरे से परे है और प्रलेखन को संदर्भित करना बेहतर है। यहाँ कुछ लिंक दिए गए हैं ताकि पाठक एक सामान्य धारणा बना सके:

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

आपको पीवीएस-स्टूडियो का उपयोग क्यों करना चाहिए

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

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

पीवीएस-स्टूडियो टूल का उपयोग पांच या अधिक लोगों की टीमों में फायदेमंद है। आप " पीवीएस-स्टूडियो आरओआई " लेख में विश्लेषक उपयोग दक्षता की गणना करने की विधि से परिचित हो सकते हैं।

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

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

हमारे ग्राहक बनें। पीवीएस-स्टूडियो का उपयोग करके, आप विकास प्रक्रिया की परिपक्वता बढ़ाएंगे, कीड़े के खिलाफ लड़ाई में पैसे बचाएंगे और बेहतर सॉफ्टवेयर बनाएंगे।

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

आपत्ति उत्तर

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

"स्थैतिक विश्लेषण कार्य समय का हिस्सा होगा"

संदर्भ से अलग-थलग "स्टेटिक विश्लेषण कार्य समय का हिस्सा लेगा" यह सच है। नए या परिवर्तित कोड के लिए जारी किए गए स्थिर विश्लेषक चेतावनियों की नियमित रूप से समीक्षा करने में वास्तव में समय लगता है। हालाँकि, इस विचार को जारी रखा जाना चाहिए: लेकिन इस पर बिताया गया समय अन्य तरीकों से त्रुटियों की पहचान करने की लागत से बहुत कम है।

स्टैटिक कोड एनालाइजर से समय बिताने की जरूरत के बारे में राय कहां से आई है?

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

इस विषय पर लेख " आपत्तियों के साथ कार्य करना: स्थैतिक विश्लेषण कार्य समय का हिस्सा लेगा " में अधिक विस्तार से वर्णित किया गया है।

"स्टेटिक एनालाइज़र बहुत शोर है (यह बहुत सारी गलत सकारात्मकता पैदा करता है)"

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

एक और कारण जो विश्लेषक के विचार को विकृत करता है, उनके उद्देश्य को समझने के बिना, यथासंभव कई चेतावनियों को शामिल करने की इच्छा है। उदाहरण के लिए, यदि आप क्लासिक विंडोज एप्लिकेशन के लिए एम्बेडेड सिस्टम पर केंद्रित MISRA नियम को सक्षम करते हैं, तो विश्लेषक सैकड़ों हजारों चेतावनी देता है। उनमें कोई व्यावहारिक अर्थ नहीं होगा। विशेष रूप से अनावश्यक निदान उपकरण के साथ परिचित के चरण में हस्तक्षेप करते हैं और इसकी नैदानिक क्षमताओं के बारे में गलत धारणा बनाते हैं। " सी और सी ++ कोड के लिए पीवीएस-स्टूडियो विश्लेषक? " इस से बचने में मदद करता है कि लेख " कैसे जल्दी से दिलचस्प चेतावनियां देखें। "

"विकास प्रक्रिया में स्थैतिक विश्लेषण प्रस्तुत करना बहुत कठिन, लंबा और महंगा है"

बहुत अच्छी तरह से, इन चिंताओं को इस टिप्पणी में परिलक्षित किया जाता है:

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

यह इतना डरावना नहीं है। कम से कम तीन दृष्टिकोण हैं जो आपको बड़ी पुरानी परियोजनाओं में भी स्थैतिक विश्लेषण को श्रमसाध्य रूप से लागू करने की अनुमति देते हैं।

पहला तरीका। "रैटचैट विधि", जिसे इवान पोनोमारेव अपनी रिपोर्ट " कंटीन्यूअस स्टैटिक कोड एनालिसिस " में अच्छी तरह से बोलते हैं।

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

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

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

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

"हमने विश्लेषक का शुभारंभ किया और कुछ भी दिलचस्प नहीं मिला"

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

इस विषय पर लेख " फिलॉस्फी ऑफ स्टेटिक कोड एनालिसिस: हम 100 प्रोग्रामर हैं, में विश्लेषक ने कुछ त्रुटियां पाईं, क्या यह बेकार है? "

"एक स्टेटिक एनालाइज़र महंगा है, दूसरे प्रोग्रामर / टेस्टर को हायर करना बेहतर है"

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

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

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

"गतिशील विश्लेषण स्थैतिक की तुलना में अधिक कुशल है।"

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

उदाहरण के लिए, डायनामिक एनालाइज़र में कई टाइपो त्रुटियाँ नहीं मिल सकती हैं या अनुपलब्ध कोड का पता लगाया जा सकता है। " Validating Valgrind डायनामिक एनालाइज़र कोड का उपयोग स्टेटिक एनालाइज़र का उपयोग करते हुए " लेख में, आप इन त्रुटियों में से कुछ का सामना कर सकते हैं।

"इकाई परीक्षण स्थैतिक कोड विश्लेषण से अधिक कुशल हैं"

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

स्थैतिक विश्लेषण निम्नलिखित कारणों से इकाई परीक्षणों को पूरक करेगा:

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

"आधुनिक मुफ्त संकलक पीवीएस-स्टूडियो के समान काम कर सकते हैं"

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

पीवीएस-स्टूडियो के लाभ:

उपयोगकर्ता का समर्थन।
रिच इन्फ्रास्ट्रक्चर (अन्य उत्पादों के साथ एकीकरण)।
नैदानिक क्षमताओं का विकास किया।

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

यह संदेहपूर्ण पाठकों को समझाने के लिए पर्याप्त नहीं है। इसलिए, समय-समय पर हम अन्य संकलक की जांच करते हैं और दिखाते हैं कि पीवीएस-स्टूडियो उनमें त्रुटियां खोजने में सक्षम है:

पुनश्च

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

उपयोगी लिंक

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

पीवीएस-स्टूडियो स्थैतिक कोड विश्लेषक को विकास प्रक्रिया में पेश करने के कारण