मुख्य सामग्री पर जाएँ
Change page

स्मार्ट अनुबंधों का परीक्षण

पेज का अंतिम अपडेट: 26 फ़रवरी 2026

corwintinesc (opens in a new tab)
MOSHKA-GOTM (opens in a new tab)
mdqstm (opens in a new tab)
+22

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

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

पूर्वापेक्षाएं

यह पेज बताता है कि एथेरियम नेटवर्क पर डिप्लॉय करने से पहले स्मार्ट अनुबंधों का परीक्षण कैसे करें। यह मानता है कि आप स्मार्ट अनुबंधों से परिचित हैं।

स्मार्ट अनुबंध परीक्षण क्या है?

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

हालांकि, दृष्टिकोण अलग-अलग होते हैं, ज़्यादातर परीक्षण के तरीकों को डेटा के एक छोटे से नमूने के साथ एक स्मार्ट अनुबंध लागू करने की आवश्यकता होती है जिसे इसे प्रबंधित की उम्मीद है। अगर अनुबंध नमूना डेटा के लिए सही परिणाम देता है, तो यह माना जाता है कि यह ठीक से काम कर रहा है। अधिकांश परीक्षण उपकरण यह जांचने के लिए टेस्ट केस (opens in a new tab) लिखने और निष्पादित करने के लिए संसाधन प्रदान करते हैं कि अनुबंध का निष्पादन अपेक्षित परिणामों से मेल खाता है या नहीं।

स्मार्ट अनुबंधों का परीक्षण करना क्यों महत्वपूर्ण है?

चूंकि स्मार्ट अनुबंध अक्सर उच्च-मूल्य वाली वित्तीय संपत्तियों का प्रबंधन करते हैं, मामूली प्रोग्रामिंग त्रुटियां यूज़र्स के लिए बड़े पैमाने पर नुकसान (opens in a new tab) का कारण बन सकती हैं और अक्सर बनती भी हैं। हालांकि, कठोर परीक्षण आपको स्मार्ट अनुबंध के कोड में गड़बड़ियों और मुद्दों को जल्दी खोजने और मेननेट पर लॉन्च करने से पहले उन्हें ठीक करने में मदद कर सकता है।

हालांकि बग का पता चलने पर अनुबंध को अपग्रेड करना संभव है, अपग्रेड जटिल हैं और अगर गलत तरीके से संभाला जाए तो त्रुटियों में परिणाम (opens in a new tab) हो सकते हैं। एक अनुबंध को अपग्रेड करना अपरिवर्तनीयता के सिद्धांत को और नकारता है और उपयोगकर्ताओं के लिए विश्वास की अतिरिक्त मान्यताओं का बोझ बढ़ाता है। इसके विपरीत, आपके अनुबंध के परीक्षण के लिए एक व्यापक योजना स्मार्ट अनुबंध सुरक्षा जोखिमों को कम करती है और डिप्लॉय करने के बाद जटिल तर्क लागू करने की आवश्यकता को कम करती है।

स्मार्ट अनुबंधों के परीक्षण के तरीके

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

स्वचालित परीक्षण

स्वचालित परीक्षण ऐसे उपकरणों का उपयोग करता है जो निष्पादन में गड़बड़ियों के लिए स्वचालित रूप से स्मार्ट अनुबंध कोड की जांच करते हैं। स्वचालित परीक्षण का लाभ अनुबंध की कार्यात्मकताओं के मूल्यांकन का मार्गदर्शन करने के लिए स्क्रिप्ट (opens in a new tab) का उपयोग करने से आता है। स्क्रिप्टेड परीक्षणों को न्यूनतम मानवीय हस्तक्षेप के साथ बार-बार चलाने के लिए निर्धारित किया जा सकता है, जिससे परीक्षण के लिए मैन्युअल दृष्टिकोण की तुलना में स्वचालित परीक्षण अधिक कुशल हो जाता है।

स्वचालित परीक्षण विशेष रूप से उपयोगी होता है, जब परीक्षण दोहराए जाते हैं और समय लेने वाले होते हैं; मैन्युअल रूप से बाहर ले जाने के लिए मुश्किल; मानवीय गड़बड़ी के लिए अतिसंवेदनशील; या महत्वपूर्ण अनुबंध संबंधी कार्यों का मूल्यांकन करना शामिल है। लेकिन स्वचालित परीक्षण उपकरणों में कमियां हो सकती हैं—वे कुछ बग चूक सकते हैं और कई गलत सकारात्मक (opens in a new tab) उत्पन्न कर सकते हैं। इसलिए, स्मार्ट अनुबंधों के लिए मैन्युअल परीक्षण के साथ स्वचालित परीक्षण को जोड़ना बेहतर रहता है।

मैन्युअल परीक्षण

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

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

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

स्मार्ट अनुबंधों के लिए स्वचालित परीक्षण

यूनिट परीक्षण

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

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

स्मार्ट अनुबंधों के यूनिट परीक्षण के लिए दिशानिर्देश

1. अपने अनुबंधों, व्यापार तर्क और वर्कफ़्लो को समझें

यूनिट परीक्षण लिखने से पहले, यह जानने में मदद करता है कि एक स्मार्ट अनुबंध क्या कार्यक्षमता प्रदान करता है और उपयोगकर्ता उन कार्यों का उपयोग कैसे करेंगे। यह विशेष रूप से हैप्पी पाथ टेस्ट (opens in a new tab) चलाने के लिए उपयोगी है जो यह निर्धारित करते हैं कि अनुबंध में फ़ंक्शन मान्य यूज़र इनपुट के लिए सही आउटपुट लौटाते हैं या नहीं। हम इस अवधारणा को एक नीलामी अनुबंध (opens in a new tab) के इस (संक्षिप्त) उदाहरण का उपयोग करके समझाएंगे

1constructor(
2        uint biddingTime,
3        address payable beneficiaryAddress
4    ) {
5        beneficiary = beneficiaryAddress;
6        auctionEndTime = block.timestamp + biddingTime;
7    }
8
9function bid() external payable {
10
11      if (block.timestamp > auctionEndTime)
12            revert AuctionAlreadyEnded();
13
14      if (msg.value <= highestBid)
15            revert BidNotHighEnough(highestBid);
16
17 if (highestBid != 0) {
18    pendingReturns[highestBidder] += highestBid;
19        }
20        highestBidder = msg.sender;
21        highestBid = msg.value;
22        emit HighestBidIncreased(msg.sender, msg.value);
23    }
24
25 function withdraw() external returns (bool) {
26        uint amount = pendingReturns[msg.sender];
27        if (amount > 0) {
28           pendingReturns[msg.sender] = 0;
29
30        if (!payable(msg.sender).send(amount)) {
31                pendingReturns[msg.sender] = amount;
32                return false;
33            }
34        }
35        return true;
36    }
37
38function auctionEnd() external {
39       if (block.timestamp < auctionEndTime)
40            revert AuctionNotYetEnded();
41        if (ended)
42            revert AuctionEndAlreadyCalled();
43
44        ended = true;
45        emit AuctionEnded(highestBidder, highestBid);
46
47        beneficiary.transfer(highestBid);
48    }
49}
सभी दिखाएँ

यह एक साधारण नीलामी अनुबंध है जिसे बोली अवधि के दौरान बोलियां प्राप्त करने के लिए डिज़ाइन किया गया है। यदि highestBid बढ़ती है, तो पिछले उच्चतम बोली लगाने वाले को अपना पैसा मिल जाता है; एक बार बोली लगाने की अवधि समाप्त हो जाने के बाद, beneficiary अपना पैसा पाने के लिए अनुबंध को कॉल करता है।

इस तरह के अनुबंध के लिए यूनिट परीक्षण विभिन्न कार्यों को कवर करेगा जो उपयोगकर्ता अनुबंध के साथ बातचीत करते समय कॉल कर सकता है। एक उदाहरण एक यूनिट परीक्षण होगा जो यह जांचता है कि नीलामी जारी रहने पर कोई यूज़र बोली लगा सकता है या नहीं (यानी, bid() पर कॉल सफल होते हैं) या एक जो यह जांचता है कि कोई यूज़र वर्तमान highestBid से ऊंची बोली लगा सकता है या नहीं।

एक अनुबंध परिचालन वर्कफ़्लो को समझना यूनिट परीक्षणों को लिखने में भी मदद करता है जो जांचते हैं कि निष्पादन आवश्यकताओं को पूरा करता है या नहीं। उदाहरण के लिए, नीलामी अनुबंध निर्दिष्ट करता है कि जब नीलामी समाप्त हो जाती है तो यूज़र बोली नहीं लगा सकते हैं (यानी, जब auctionEndTime block.timestamp से कम हो)। इस प्रकार, एक डेवलपर एक यूनिट परीक्षण चला सकता है जो यह जांचता है कि bid() फ़ंक्शन पर कॉल नीलामी समाप्त होने पर सफल होते हैं या विफल (यानी, जब auctionEndTime > block.timestamp)।

२. अनुबंध निष्पादन से संबंधित सभी मान्यताओं का मूल्यांकन करें

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

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

  • नीलामी समाप्त होने या शुरू नहीं होने पर उपयोगकर्ता बोलियां नहीं लगा सकते।

  • यदि कोई बोली स्वीकार्य सीमा से कम है, नीलामी अनुबंध वापस आ जाता है।

  • जो उपयोगकर्ता बोली जीतने में विफल रहते हैं, उन्हें उनके फ़ंड का क्रेडिट दिया जाता है

ध्यान दें: धारणाओं का परीक्षण करने का एक और तरीका उन परीक्षणों को लिखना है जो एक अनुबंध में फ़ंक्शन मॉडिफायर (opens in a new tab) को ट्रिगर करते हैं, विशेष रूप से require, assert, और if…else स्टेटमेंट।

3. कोड कवरेज मापें

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

4. अच्छी तरह से विकसित टेस्टिंग फ़्रेमवर्क का उपयोग करें

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

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

एकीकरण परीक्षण

जबकि इकाई परीक्षण अलगाव में अनुबंध कार्यों को डीबग करता है, एकीकरण परीक्षण एक पूरे के रूप में एक स्मार्ट अनुबंध के घटकों का मूल्यांकन करते हैं। एकीकरण परीक्षण एक ही स्मार्ट अनुबंध में क्रॉस-अनुबंध कॉल या विभिन्न कार्यों के बीच बातचीत की वजह से होने वाली समस्याओं का पता लगा सकता है। उदाहरण के लिए, एकीकरण परीक्षण यह जांचने में मदद कर सकते हैं कि वंशानुक्रम (opens in a new tab) और डिपेंडेंसी इंजेक्शन जैसी चीज़ें ठीक से काम करती हैं या नहीं।

एकीकरण परीक्षण उपयोगी है अगर आपका अनुबंध निष्पादन के दौरान अन्य ऑन-चेन अनुबंधों के साथ मॉड्यूलर आर्किटेक्चर या इंटरफ़ेस को अपनाता है। एकीकरण परीक्षण चलाने का एक तरीका एक विशिष्ट ऊंचाई पर है (Forge (opens in a new tab) या हार्डहैट (opens in a new tab) जैसे टूल का उपयोग करके) और आपके अनुबंध और तैनात अनुबंधों के बीच इंटरैक्शन का अनुकरण करना।

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

गुण-आधारित परीक्षण

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

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

स्टेटिक विश्लेषण

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

लिंटिंग (opens in a new tab) और स्टेटिक परीक्षण (opens in a new tab) अनुबंधों पर स्टेटिक विश्लेषण चलाने के सामान्य तरीके हैं। दोनों को कंपाइलर द्वारा आउटपुट किए गए अनुबंध निष्पादन के निम्न-स्तरीय अभ्यावेदन जैसे सार वाक्य रचना ट्री (opens in a new tab) और नियंत्रण प्रवाह ग्राफ़ (opens in a new tab) का विश्लेषण करने की आवश्यकता होती है।

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

गतिशील विश्लेषण

गतिशील विश्लेषण स्मार्ट अनुबंध के कार्यों के लिए प्रतीकात्मक इनपुट (जैसे, प्रतीकात्मक निष्पादन (opens in a new tab) में) या ठोस इनपुट (जैसे, फ़ज़िंग (opens in a new tab) में) उत्पन्न करता है यह देखने के लिए कि क्या कोई निष्पादन ट्रेस विशिष्ट गुणों का उल्लंघन करता है। संपत्ति-आधारित परीक्षण का यह रूप यूनिट परीक्षणों से अलग होता है जिसमें परीक्षण मामले कई मामलों को कवर करते हैं और एक कार्यक्रम परीक्षण मामलों को प्रबंधित करता है।

फ़ज़िंग (opens in a new tab) स्मार्ट अनुबंधों में मनमाने गुणों को सत्यापित करने के लिए एक गतिशील विश्लेषण तकनीक का एक उदाहरण है। एक फ़ज़र एक परिभाषित इनपुट मूल्य के किसी भी क्रम में या विकृत रूपांतरों के साथ एक लक्ष्य अनुबंध में कार्यों को आमंत्रित करता है। अगर स्मार्ट अनुबंध एक त्रुटि स्थिति में प्रवेश करता है (उदाहरण के लिए, जहां एक अभिकथन विफल हो जाता है), तो समस्या को फ्लैग किया जाता है और इनपुट जो कमजोर पथ की ओर निष्पादन को चलाते हैं, एक रिपोर्ट में जेनरेट होते हैं।

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

  1. कई परिदृश्यों को कवर करने के लिए परीक्षण मामले लिखना मुश्किल है। एक गुण परीक्षण के लिए केवल यह आवश्यक है कि आप व्यवहार का परीक्षण करने के लिए एक व्यवहार और डेटा की एक श्रृंखला को परिभाषित करें - प्रोग्राम स्वचालित रूप से परिभाषित गुण के आधार पर परीक्षण मामले उत्पन्न करता है।

  2. आपका परीक्षण सूट कार्यक्रम के भीतर सभी संभावित रास्तों को पर्याप्त रूप से कवर नहीं कर सकता है। 100% कवरेज के साथ भी, एज मामलों से चूकना संभव है।

  3. यूनिट परीक्षण यह साबित करते हैं कि एक अनुबंध नमूना डेटा के लिए सही ढंग से निष्पादित होता है, लेकिन क्या अनुबंध नमूने के बाहर इनपुट के लिए सही ढंग से निष्पादित होता है, यह अज्ञात रहता है। गुण परीक्षण एक दिए गए इनपुट मान के कई रूपों के साथ एक लक्ष्य अनुबंध को निष्पादित करते हैं ताकि उन निष्पादन ट्रेस को ढूंढा जा सके जो अभिकथन विफलताओं का कारण बनते हैं। इस प्रकार, एक संपत्ति परीक्षण अधिक गारंटी प्रदान करता है कि एक अनुबंध इनपुट डेटा के व्यापक वर्ग के लिए सही ढंग से निष्पादित करता है।

स्मार्ट अनुबंधों के लिए गुण-आधारित परीक्षण चलाने के लिए दिशानिर्देश

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

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

स्मार्ट अनुबंधों के लिए मैन्युअल परीक्षण

स्मार्ट अनुबंधों का मैन्युअल परीक्षण अक्सर स्वचालित परीक्षण चलाने के बाद विकास चक्र में बाद में आता है। परीक्षण का यह रूप स्मार्ट अनुबंध का मूल्यांकन एक पूरी तरह से एकीकृत उत्पाद के रूप में करता है, यह देखने के लिए कि क्या यह तकनीकी आवश्यकताओं में निर्दिष्ट के रूप में प्रदर्शन करता है।

स्थानीय ब्लॉकचेन पर अनुबंधों का परीक्षण

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

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

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

विकास नेटवर्कों के बारे में और जानें।

टेस्टनेट पर अनुबंधों का परीक्षण

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

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

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

एथेरियम टेस्टनेट के बारे में और जानें।

परीक्षण बनाम औपचारिक सत्यापन

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

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

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

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

स्मार्ट अनुबंधों के लिए औपचारिक सत्यापन के बारे में और जानें।

परीक्षण बनाम ऑडिट और बग बाउंटी

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

फिर भी, आप एक स्वतंत्र कोड समीक्षा प्राप्त करके अनुबंध से जुड़ी कमजोरियों को पकड़ने की संभावना को और बढ़ा सकते हैं। स्मार्ट अनुबंध ऑडिट (opens in a new tab) और बग बाउंटी (opens in a new tab) आपके अनुबंधों का विश्लेषण दूसरों से करवाने के दो तरीके हैं।

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

इसके विपरीत, एक बग बाउंटी प्रोग्राम में आमतौर पर किसी व्यक्ति को वित्तीय इनाम की पेशकश करना शामिल होता है (आमतौर पर व्हाइटहैट हैकर्स (opens in a new tab) के रूप में वर्णित) जो एक स्मार्ट अनुबंध में भेद्यता का पता लगाता है और इसे डेवलपर्स को बताता है। बग बाउंटी ऑडिट के समान हैं, क्योंकि इसमें दूसरों को स्मार्ट अनुबंधों में दोष खोजने में मदद करने के लिए कहना शामिल है।

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

परीक्षण उपकरण और पुस्तकालय

यूनिट परीक्षण उपकरण

  • solidity-coverage (opens in a new tab) - Solidity में लिखे गए स्मार्ट अनुबंधों के लिए कोड कवरेज उपकरण।

  • वॉफल (opens in a new tab) - उन्नत स्मार्ट अनुबंध विकास और परीक्षण के लिए फ्रेमवर्क (ethers.js पर आधारित)।

  • रीमिक्स Tests (opens in a new tab) - Solidity स्मार्ट अनुबंधों के परीक्षण के लिए उपकरण। रीमिक्स IDE "सॉलिडिटी यूनिट टेस्टिंग" प्लगइन के तहत काम करता है जिसका उपयोग अनुबंध के लिए परीक्षण मामले लिखने और चलाने के लिए किया जाता है।

  • ओपनज़ेपेलिन Test Helpers (opens in a new tab) - एथेरियम स्मार्ट अनुबंध परीक्षण के लिए अभिकथन पुस्तकालय। सुनिश्चित करें कि आपके अनुबंध अपेक्षा के अनुरूप व्यवहार करें!

  • ब्राउनी यूनिट टेस्टिंग फ्रेमवर्क (opens in a new tab) - ब्राउनी Pytest का उपयोग करता है, जो एक सुविधा संपन्न परीक्षण ढांचा है जो आपको न्यूनतम कोड के साथ छोटे परीक्षण लिखने देता है, बड़ी परियोजनाओं के लिए अच्छी तरह से मापता है, और अत्यधिक विस्तार योग्य है।

  • फाउंड्री Tests (opens in a new tab) - फाउंड्री Forge प्रदान करता है, जो एक तेज़ और लचीला एथेरियम परीक्षण ढांचा है जो सरल इकाई परीक्षण, गैस अनुकूलन जांच और अनुबंध फ़ज़िंग निष्पादित करने में सक्षम है।

  • हार्डहैट Tests (opens in a new tab) - ethers.js, Mocha और Chai पर आधारित स्मार्ट अनुबंधों के परीक्षण के लिए फ्रेमवर्क।

  • ApeWorx (opens in a new tab) - एथेरियम वर्चुअल मशीन को लक्षित करने वाले स्मार्ट अनुबंधों के लिए पायथन-आधारित विकास और परीक्षण ढांचा।

  • वेक (opens in a new tab) - यूनिट परीक्षण और फ़ज़िंग के लिए पायथन-आधारित ढांचा जिसमें मजबूत डिबगिंग क्षमताएं और क्रॉस-चेन परीक्षण समर्थन है, जो सर्वश्रेष्ठ यूज़र अनुभव और प्रदर्शन के लिए pytest और Anvil का उपयोग करता है।

गुण-आधारित परीक्षण उपकरण

स्टेटिक विश्लेषण उपकरण

  • स्लिदर (opens in a new tab) - कमजोरियों को खोजने, कोड की समझ बढ़ाने और स्मार्ट अनुबंधों के लिए कस्टम विश्लेषण लिखने के लिए पायथन-आधारित सॉलिडिटी स्टेटिक विश्लेषण ढांचा।

  • Ethlint (opens in a new tab) - Solidity स्मार्ट अनुबंध प्रोग्रामिंग भाषा के लिए शैली और सुरक्षा सर्वोत्तम प्रथाओं को लागू करने के लिए लिंटर।

  • Cyfrin Aderyn (opens in a new tab) - Rust-आधारित स्टेटिक एनालाइज़र विशेष रूप से वेब3 स्मार्ट अनुबंध सुरक्षा और विकास के लिए डिज़ाइन किया गया है।

  • वेक (opens in a new tab) - भेद्यता और कोड गुणवत्ता डिटेक्टरों के साथ पायथन-आधारित स्टेटिक विश्लेषण ढांचा, कोड से उपयोगी जानकारी निकालने के लिए प्रिंटर और कस्टम सबमॉड्यूल लिखने के लिए समर्थन।

  • Slippy (opens in a new tab) - Solidity के लिए एक सरल और शक्तिशाली लिंटर।

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

  • एकिड्ना (opens in a new tab) - गुण-आधारित परीक्षण के माध्यम से स्मार्ट अनुबंधों में कमजोरियों का पता लगाने के लिए तेज़ अनुबंध फ़ज़र।

  • Diligence Fuzzing (opens in a new tab) - स्मार्ट अनुबंध कोड में गुण उल्लंघनों का पता लगाने के लिए उपयोगी स्वचालित फ़ज़िंग उपकरण।

  • मैंटिकोर (opens in a new tab) - EVM बाइटकोड का विश्लेषण करने के लिए गतिशील प्रतीकात्मक निष्पादन ढांचा।

  • मिथ्रिल (opens in a new tab) - टेंट विश्लेषण, कॉन्कोलिक विश्लेषण और नियंत्रण प्रवाह जांच का उपयोग करके अनुबंध कमजोरियों का पता लगाने के लिए EVM बाइटकोड मूल्यांकन उपकरण।

  • Diligence स्क्रिबल (opens in a new tab) - Scribble एक विनिर्देशन भाषा और रनटाइम सत्यापन उपकरण है जो आपको गुणों के साथ स्मार्ट अनुबंधों को एनोटेट करने की अनुमति देता है जो आपको Diligence Fuzzing या मिथएक्स जैसे उपकरणों के साथ अनुबंधों का स्वचालित रूप से परीक्षण करने की अनुमति देता है।

संबंधित ट्यूटोरियल

आगे की रीडिंग

क्या यह लेख सहायक था?