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

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

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

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

आवश्यक शर्तें

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

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

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

हालांकि, दृष्टिकोण अलग-अलग होते हैं, ज़्यादातर परीक्षण के तरीकों को डेटा के एक छोटे से नमूने के साथ एक स्मार्ट अनुबंध लागू करने की आवश्यकता होती है जिसे इसे प्रबंधित की उम्मीद है। अगर अनुबंध नमूना डेटा के लिए सही परिणाम देता है, तो यह माना जाता है कि यह ठीक से काम कर रहा है। अधिकांश परीक्षण उपकरण परीक्षण मामलों(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) के इस (संक्षिप्त) उदाहरण का उपयोग करके समझाएंगे

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 स्टेटमेंट।

३ कोड कवरेज मापें

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

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

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

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

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

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

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

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

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

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

संपत्ति-आधारित परीक्षण उपकरण

स्थैतिक विश्लेषण उपकरण

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

अग्रिम पठन

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