जब आपके पास स्टेटिक विश्लेषण हो तो डायनामिक विश्लेषण का क्या उपयोग है?

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

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

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

स्टैटिक कोड एनालिसिस सॉफ्टवेयर की सोर्स कोड में त्रुटियों और कोड स्मेल का पता लगाने की प्रक्रिया है। एक कार्यक्रम का विश्लेषण करने के लिए, आपको इसे निष्पादित करने की आवश्यकता नहीं है; विश्लेषण उपलब्ध कोड आधार पर किया जाएगा। स्थैतिक विश्लेषण का निकटतम सादृश्य तथाकथित कोड समीक्षा है सिवाय इसके कि स्थैतिक विश्लेषण कोड समीक्षा का एक स्वचालित संस्करण है (यानी एक बॉट प्रोग्राम द्वारा निष्पादित)।

स्थैतिक विश्लेषण के मुख्य पेशेवरों:

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

स्थैतिक विश्लेषण का उद्देश्य बुरा:

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

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

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

गतिशील परीक्षण के साथ, आप निम्नलिखित मीट्रिक और चेतावनी प्राप्त कर सकते हैं:

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

गतिशील विश्लेषण के मुख्य पेशेवरों:

1. आपको इसका विश्लेषण करने के लिए प्रोग्राम के सोर्स कोड तक पहुंच नहीं है। हालांकि, यह ध्यान दिया जाना चाहिए कि डायनेमिक विश्लेषण टूल विश्लेषण के तहत कार्यक्रम के साथ बातचीत करने के तरीके से भिन्न होते हैं (यह यहां अधिक विस्तार से चर्चा की गई है )। उदाहरण के लिए, एक बहुत ही सामान्य गतिशील विश्लेषण तकनीक में चेक से पहले कोड इंस्ट्रूमेंटेशन शामिल होता है, यानी त्रुटियों के निदान के लिए सक्षम होने के लिए विश्लेषक के आवेदन के स्रोत कोड में विशेष कोड के टुकड़े शामिल होते हैं। उस स्थिति में, आपको प्रोग्राम का स्रोत कोड हाथ में होना चाहिए।
2. यह जटिल मेमोरी हैंडलिंग त्रुटियों का पता लगा सकता है जैसे कि सरणी सीमा और मेमोरी लीक से परे अनुक्रमण।
3. यह निष्पादन के समय में मल्टीथ्रेड कोड का विश्लेषण कर सकता है, इस प्रकार संभावित समस्याओं का पता लगाता है जो साझा संसाधनों या संभव गतिरोधों तक पहुंच के साथ करना है।
4. डायनामिक एनालाइज़र के अधिकांश कार्यान्वयन झूठे सकारात्मक उत्पन्न नहीं करते हैं क्योंकि त्रुटियों को पकड़ा जाता है क्योंकि वे होते हैं। इसलिए, एक गतिशील विश्लेषक द्वारा जारी की गई चेतावनी प्रोग्राम मॉडल के विश्लेषण के आधार पर टूल द्वारा की गई भविष्यवाणी नहीं है, बल्कि इस तथ्य का एक मात्र बयान है कि एक त्रुटि हुई है।

गतिशील विश्लेषण की विपक्ष:

1. पूर्ण कोड कवरेज की गारंटी नहीं है। यही है, आप गतिशील परीक्षण द्वारा 100% कवरेज प्राप्त करने की बहुत संभावना नहीं है।
2. डायनामिक एनालाइज़र तर्क त्रुटियों का पता लगाने में खराब हैं। उदाहरण के लिए, एक हमेशा सही स्थिति एक गतिशील विश्लेषक के दृष्टिकोण से बग नहीं है क्योंकि इस तरह की गलत जांच बस संकलन कदम पर पहले गायब हो जाती है।
3. कोड में त्रुटि का पता लगाना अधिक कठिन है।
4. स्थिर विश्लेषण के साथ तुलना में गतिशील विश्लेषण का उपयोग करना अधिक कठिन है क्योंकि आपको बेहतर परिणाम प्राप्त करने के लिए कार्यक्रम के लिए पर्याप्त डेटा खिलाने और यथासंभव पूर्ण कोड कवरेज हासिल करने की आवश्यकता है।

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

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

निम्नलिखित उदाहरण क्लैंग परियोजना से लिया गया है:

MapTy PerPtrTopDown; MapTy PerPtrBottomUp; void clearBottomUpPointers() { PerPtrTopDown.clear(); } void clearTopDownPointers() { PerPtrTopDown.clear(); } 

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

एक और उदाहरण। मान लें कि हमारे पास निम्नलिखित कार्य हैं:

 void OutstandingIssue(const char *strCount) { unsigned nCount; sscanf_s(strCount, "%u", &nCount); int array[10]; memset(array, 0, nCount * sizeof(int)); } 

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

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

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

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

संदर्भ:

1. शब्दावली। स्थैतिक कोड विश्लेषण ।
2. शब्दावली। डायनामिक कोड विश्लेषण ।
3. एंड्री कारपोव। स्थिर और गतिशील कोड विश्लेषण ।
4. एंड्री कारपोव। स्थैतिक विश्लेषण के बारे में मिथक। तीसरा मिथक - गतिशील विश्लेषण स्थैतिक विश्लेषण से बेहतर है ।
5. एंड्री कारपोव। पीवीएस-स्टूडियो आरओआई ।