Akıllı sözleşmeleri test etme

Ethereum gibi halka açık blokzincirler değişmezdir, bu da bir akıllı sözleşmenin kodunu dağıtımdan sonra değiştirmeyi zorlaştırır. "Sanal yükseltmeler" gerçekleştirmek için Sözleşme yükseltme kalıpları mevcuttur, ancak bunların uygulanması zordur ve sosyal mutabakat gerektirir. Dahası, bir yükseltme bir hatayı yalnızca keşfedildikten sonra düzeltebilir; eğer bir saldırgan güvenlik açığını önce keşfederse, akıllı sözleşmeniz bir istismar riski altındadır.

Bu nedenlerden dolayı, akıllı sözleşmeleri Ana Ağ'a dağıtmadan önce test etmek, güvenlik için asgari bir gerekliliktir. Sözleşmeleri test etmek ve kod doğruluğunu değerlendirmek için birçok teknik vardır; hangisini seçeceğiniz ihtiyaçlarınıza bağlıdır. Yine de, farklı araçlardan ve yaklaşımlardan oluşan bir test paketi, sözleşme kodundaki hem küçük hem de büyük güvenlik açıklarını yakalamak için idealdir.

Ön koşullar

Bu sayfa, Ethereum ağında dağıtmadan önce akıllı sözleşmelerin nasıl test edileceğini açıklar. Akıllı sözleşmelere aşina olduğunuzu varsayar.

Akıllı sözleşme testi nedir?

Akıllı sözleşme testi, bir akıllı sözleşmenin kodunun beklendiği gibi çalıştığını doğrulama sürecidir. Test etme, belirli bir akıllı sözleşmenin güvenilirlik, kullanılabilirlik ve güvenlik gereksinimlerini karşılayıp karşılamadığını kontrol etmek için faydalıdır.

Yaklaşımlar farklılık gösterse de, çoğu test yöntemi bir akıllı sözleşmeyi işlemesi beklenen verilerin küçük bir örneğiyle yürütmeyi gerektirir. Sözleşme örnek veriler için doğru sonuçlar üretirse, düzgün çalıştığı varsayılır. Çoğu test aracı, bir sözleşmenin yürütülmesinin beklenen sonuçlarla eşleşip eşleşmediğini kontrol etmek için test senaryoları (opens in a new tab) yazmak ve yürütmek için kaynaklar sağlar.

Akıllı sözleşmeleri test etmek neden önemlidir?

Akıllı sözleşmeler genellikle yüksek değerli finansal varlıkları yönettiğinden, küçük programlama hataları kullanıcılar için büyük kayıplara (opens in a new tab) yol açabilir ve sıklıkla açar. Ancak titiz testler, bir akıllı sözleşmenin kodundaki kusurları ve sorunları erkenden keşfetmenize ve Ana Ağ'da başlatmadan önce bunları düzeltmenize yardımcı olabilir.

Bir hata keşfedilirse bir sözleşmeyi yükseltmek mümkün olsa da, yükseltmeler karmaşıktır ve yanlış ele alınırsa hatalarla sonuçlanabilir (opens in a new tab). Bir sözleşmeyi yükseltmek, değişmezlik ilkesini daha da geçersiz kılar ve kullanıcılara ek güven varsayımları yükler. Aksine, sözleşmenizi test etmek için kapsamlı bir plan, akıllı sözleşme güvenlik risklerini azaltır ve dağıtımdan sonra karmaşık mantık yükseltmeleri gerçekleştirme ihtiyacını azaltır.

Akıllı sözleşmeleri test etme yöntemleri

Ethereum akıllı sözleşmelerini test etme yöntemleri iki geniş kategoriye ayrılır: otomatik test ve manuel test. Otomatik test ve manuel test benzersiz avantajlar ve ödünleşimler sunar, ancak sözleşmelerinizi analiz etmek için sağlam bir plan oluşturmak üzere her ikisini de birleştirebilirsiniz.

Otomatik test

Otomatik test, bir akıllı sözleşmenin kodunu yürütmedeki hatalar için otomatik olarak kontrol eden araçlar kullanır. Otomatik testin faydası, sözleşme işlevlerinin değerlendirilmesine rehberlik etmek için betikler (opens in a new tab) kullanmaktan gelir. Betikli testler, minimum insan müdahalesiyle tekrar tekrar çalışacak şekilde planlanabilir, bu da otomatik testi manuel test yaklaşımlarından daha verimli hale getirir.

Otomatik test, testler tekrarlayıcı ve zaman alıcı olduğunda; manuel olarak gerçekleştirilmesi zor olduğunda; insan hatasına açık olduğunda; veya kritik sözleşme işlevlerini değerlendirmeyi içerdiğinde özellikle yararlıdır. Ancak otomatik test araçlarının dezavantajları olabilir; belirli hataları gözden kaçırabilir ve birçok yanlış pozitif (opens in a new tab) üretebilirler. Bu nedenle, akıllı sözleşmeler için otomatik testi manuel testle eşleştirmek idealdir.

Manuel test

Manuel test insan desteklidir ve bir akıllı sözleşmenin doğruluğunu analiz ederken test paketinizdeki her bir test senaryosunu birbiri ardına yürütmeyi içerir. Bu, bir sözleşme üzerinde aynı anda birden fazla izole test çalıştırabileceğiniz ve başarısız olan ve geçen tüm testleri gösteren bir rapor alabileceğiniz otomatik testten farklıdır.

Manuel test, farklı test senaryolarını kapsayan yazılı bir test planını izleyen tek bir kişi tarafından gerçekleştirilebilir. Ayrıca, manuel testin bir parçası olarak birden fazla kişinin veya grubun belirli bir süre boyunca bir akıllı sözleşmeyle etkileşime girmesini sağlayabilirsiniz. Test uzmanları, sözleşmenin gerçek davranışını beklenen davranışla karşılaştıracak ve herhangi bir farkı hata olarak işaretleyecektir.

Etkili manuel test önemli kaynaklar (beceri, zaman, para ve çaba) gerektirir ve testleri yürütürken insan hatası nedeniyle belirli hataları gözden kaçırmak mümkündür. Ancak manuel test de faydalı olabilir; örneğin, bir insan test uzmanı (örneğin, bir denetçi), otomatik bir test aracının gözden kaçıracağı uç durumları tespit etmek için sezgilerini kullanabilir.

Akıllı sözleşmeler için otomatik test

Birim testi

Birim testi, sözleşme işlevlerini ayrı ayrı değerlendirir ve her bileşenin doğru çalıştığını kontrol eder. İyi birim testleri basit olmalı, hızlı çalışmalı ve testler başarısız olursa neyin yanlış gittiğine dair net bir fikir vermelidir.

Birim testleri, işlevlerin beklenen değerleri döndürdüğünü ve işlev yürütüldükten sonra sözleşme depolamasının düzgün bir şekilde güncellendiğini kontrol etmek için yararlıdır. Dahası, bir sözleşmenin kod tabanında değişiklik yaptıktan sonra birim testleri çalıştırmak, yeni mantık eklemenin hatalara yol açmamasını sağlar. Aşağıda etkili birim testleri çalıştırmak için bazı yönergeler bulunmaktadır:

Akıllı sözleşmelerin birim testi için yönergeler

1. Sözleşmenizin iş mantığını ve iş akışını anlayın

Birim testleri yazmadan önce, bir akıllı sözleşmenin hangi işlevleri sunduğunu ve kullanıcıların bu işlevlere nasıl erişip kullanacağını bilmek yardımcı olur. Bu, bir sözleşmedeki işlevlerin geçerli kullanıcı girdileri için doğru çıktıyı döndürüp döndürmediğini belirleyen mutlu yol testlerini (happy path tests) (opens in a new tab) çalıştırmak için özellikle yararlıdır. Bu kavramı, bir açık artırma sözleşmesinin (opens in a new tab) bu (kısaltılmış) örneğini kullanarak açıklayacağız

constructor(
        uint biddingTime,
        address payable beneficiaryAddress
    ) {
        beneficiary = beneficiaryAddress;
        auctionEndTime = block.timestamp + biddingTime;
    }

function bid() external payable {

      if (block.timestamp > auctionEndTime)
            revert AuctionAlreadyEnded();

      if (msg.value <= highestBid)
            revert BidNotHighEnough(highestBid);

 if (highestBid != 0) {
    pendingReturns[highestBidder] += highestBid;
        }
        highestBidder = msg.sender;
        highestBid = msg.value;
        emit HighestBidIncreased(msg.sender, msg.value);
    }

 function withdraw() external returns (bool) {
        uint amount = pendingReturns[msg.sender];
        if (amount > 0) {
           pendingReturns[msg.sender] = 0;

        if (!payable(msg.sender).send(amount)) {
                pendingReturns[msg.sender] = amount;
                return false;
            }
        }
        return true;
    }

function auctionEnd() external {
       if (block.timestamp < auctionEndTime)
            revert AuctionNotYetEnded();
        if (ended)
            revert AuctionEndAlreadyCalled();

        ended = true;
        emit AuctionEnded(highestBidder, highestBid);

        beneficiary.transfer(highestBid);
    }
}

Bu, teklif verme süresi boyunca teklifleri almak için tasarlanmış basit bir açık artırma sözleşmesidir. Eğer highestBid artarsa, önceki en yüksek teklif sahibi parasını alır; teklif verme süresi bittiğinde, beneficiary parasını almak için sözleşmeyi çağırır.

Bunun gibi bir sözleşme için birim testleri, bir kullanıcının sözleşmeyle etkileşime girerken çağırabileceği farklı işlevleri kapsayacaktır. Bir örnek, açık artırma devam ederken bir kullanıcının teklif verip veremeyeceğini (yani, bid() çağrılarının başarılı olup olmadığını) kontrol eden bir birim testi veya bir kullanıcının mevcut highestBid değerinden daha yüksek bir teklif verip veremeyeceğini kontrol eden bir test olabilir.

Bir sözleşmenin operasyonel iş akışını anlamak, yürütmenin gereksinimleri karşılayıp karşılamadığını kontrol eden birim testleri yazmaya da yardımcı olur. Örneğin, açık artırma sözleşmesi, açık artırma sona erdiğinde (yani, auctionEndTime, block.timestamp değerinden düşük olduğunda) kullanıcıların teklif veremeyeceğini belirtir. Bu nedenle, bir geliştirici, açık artırma bittiğinde (yani, auctionEndTime > block.timestamp olduğunda) bid() işlevine yapılan çağrıların başarılı olup olmadığını veya başarısız olup olmadığını kontrol eden bir birim testi çalıştırabilir.

2. Sözleşme yürütmesiyle ilgili tüm varsayımları değerlendirin

Bir sözleşmenin yürütülmesiyle ilgili tüm varsayımları belgelemek ve bu varsayımların geçerliliğini doğrulamak için birim testleri yazmak önemlidir. Beklenmeyen yürütmeye karşı koruma sağlamanın yanı sıra, doğrulamaları (assertions) test etmek sizi bir akıllı sözleşmenin güvenlik modelini bozabilecek işlemler hakkında düşünmeye zorlar. Yararlı bir ipucu, "mutlu kullanıcı testlerinin" ötesine geçmek ve bir işlevin yanlış girdiler için başarısız olup olmadığını kontrol eden negatif testler yazmaktır.

Birçok birim testi çerçevesi, doğrulamalar (bir sözleşmenin ne yapıp ne yapamayacağını belirten basit ifadeler) oluşturmanıza ve bu doğrulamaların yürütme altında geçerli olup olmadığını görmek için testler çalıştırmanıza olanak tanır. Daha önce açıklanan açık artırma sözleşmesi üzerinde çalışan bir geliştirici, negatif testleri çalıştırmadan önce davranışı hakkında aşağıdaki doğrulamaları yapabilir:

Kullanıcılar açık artırma bittiğinde veya henüz başlamadığında teklif veremezler.
Bir teklif kabul edilebilir eşiğin altındaysa açık artırma sözleşmesi geri alınır (revert).
Teklifi kazanamayan kullanıcıların fonları iade edilir

Not: Varsayımları test etmenin başka bir yolu, bir sözleşmedeki işlev değiştiricilerini (modifiers) (opens in a new tab), özellikle require, assert ve if…else ifadelerini tetikleyen testler yazmaktır.

3. Kod kapsamını ölçün

Kod kapsamı (opens in a new tab), testler sırasında yürütülen kodunuzdaki dalların, satırların ve ifadelerin sayısını izleyen bir test metriğidir. Test edilmemiş güvenlik açıkları riskini en aza indirmek için testlerin iyi bir kod kapsamına sahip olması gerekir. Yeterli kapsam olmadan, tüm testler geçtiği için sözleşmenizin güvenli olduğunu yanlış bir şekilde varsayabilirsiniz, oysa test edilmemiş kod yollarında güvenlik açıkları hala mevcut olabilir. Ancak yüksek kod kapsamı kaydetmek, bir akıllı sözleşmedeki tüm ifadelerin/işlevlerin doğruluk açısından yeterince test edildiğinin güvencesini verir.

4. İyi geliştirilmiş test çerçeveleri kullanın

Akıllı sözleşmeleriniz için birim testleri çalıştırmada kullanılan araçların kalitesi çok önemlidir. İdeal bir test çerçevesi, düzenli olarak bakımı yapılan; yararlı özellikler (örneğin, günlük kaydı ve raporlama yetenekleri) sağlayan; ve diğer geliştiriciler tarafından kapsamlı bir şekilde kullanılmış ve incelenmiş olandır.

Solidity akıllı sözleşmeleri için birim testi çerçeveleri farklı dillerde (çoğunlukla JavaScript, Python ve Rust) gelir. Farklı test çerçeveleriyle birim testleri çalıştırmaya nasıl başlayacağınız hakkında bilgi için aşağıdaki kılavuzlardan bazılarına bakın:

Entegrasyon testi

Birim testi sözleşme işlevlerinde izole olarak hata ayıklarken, entegrasyon testleri bir akıllı sözleşmenin bileşenlerini bir bütün olarak değerlendirir. Entegrasyon testi, sözleşmeler arası çağrılardan veya aynı akıllı sözleşmedeki farklı işlevler arasındaki etkileşimlerden kaynaklanan sorunları tespit edebilir. Örneğin, entegrasyon testleri kalıtım (opens in a new tab) ve bağımlılık enjeksiyonu gibi şeylerin düzgün çalışıp çalışmadığını kontrol etmeye yardımcı olabilir.

Sözleşmeniz modüler bir mimari benimsiyorsa veya yürütme sırasında diğer zincir içi sözleşmelerle arayüz oluşturuyorsa entegrasyon testi yararlıdır. Entegrasyon testlerini çalıştırmanın bir yolu, blokzinciri belirli bir yükseklikte (Forge (opens in a new tab) veya Hardhat (opens in a new tab) gibi bir araç kullanarak) ve sözleşmeniz ile dağıtılmış sözleşmeler arasındaki etkileşimleri simüle etmektir.

Çatallanmış blokzincir, Ana Ağ'a benzer şekilde davranacak ve ilişkili durumları ve bakiyeleri olan hesaplara sahip olacaktır. Ancak yalnızca korumalı bir yerel geliştirme ortamı olarak işlev görür, yani örneğin işlemler için gerçek ETH'ye ihtiyacınız olmayacak ve değişiklikleriniz gerçek Ethereum protokolünü etkilemeyecektir.

Özellik tabanlı test

Özellik tabanlı test, bir akıllı sözleşmenin tanımlanmış bazı özellikleri karşıladığını kontrol etme sürecidir. Özellikler, bir sözleşmenin davranışı hakkında farklı senaryolarda doğru kalması beklenen gerçekleri ileri sürer; bir akıllı sözleşme özelliğine örnek olarak "Sözleşmedeki aritmetik işlemler asla taşma (overflow) veya yetersizlik (underflow) yapmaz" verilebilir.

Statik analiz ve dinamik analiz, özellik tabanlı testleri yürütmek için yaygın iki tekniktir ve her ikisi de bir programın (bu durumda bir akıllı sözleşme) kodunun önceden tanımlanmış bazı özellikleri karşıladığını doğrulayabilir. Bazı özellik tabanlı test araçları, beklenen sözleşme özellikleri hakkında önceden tanımlanmış kurallarla birlikte gelir ve kodu bu kurallara karşı kontrol ederken, diğerleri bir akıllı sözleşme için özel özellikler oluşturmanıza olanak tanır.

Statik analiz

Bir statik analizör, bir akıllı sözleşmenin kaynak kodunu girdi olarak alır ve bir sözleşmenin bir özelliği karşılayıp karşılamadığını bildiren sonuçlar çıkarır. Dinamik analizin aksine, statik analiz, doğruluğunu analiz etmek için bir sözleşmeyi yürütmeyi içermez. Statik analiz bunun yerine, bir akıllı sözleşmenin yürütme sırasında izleyebileceği tüm olası yollar hakkında akıl yürütür (yani, çalışma zamanında sözleşmenin çalışması için ne anlama geleceğini belirlemek üzere kaynak kodunun yapısını inceleyerek).

Linting (opens in a new tab) ve statik test (opens in a new tab), sözleşmeler üzerinde statik analiz çalıştırmak için yaygın yöntemlerdir. Her ikisi de derleyici tarafından çıkarılan soyut sözdizimi ağaçları (opens in a new tab) ve kontrol akış grafikleri (opens in a new tab) gibi bir sözleşmenin yürütülmesinin düşük seviyeli temsillerini analiz etmeyi gerektirir.

Çoğu durumda statik analiz, bir sözleşmenin kodunda güvenli olmayan yapıların kullanımı, sözdizimi hataları veya kodlama standartlarının ihlali gibi güvenlik sorunlarını tespit etmek için yararlıdır. Bununla birlikte, statik analizörlerin daha derin güvenlik açıklarını tespit etmede genellikle yetersiz olduğu bilinmektedir ve aşırı yanlış pozitifler üretebilirler.

Dinamik analiz

Dinamik analiz, herhangi bir yürütme izinin (izlerinin) belirli özellikleri ihlal edip etmediğini görmek için bir akıllı sözleşmenin işlevlerine sembolik girdiler (örneğin, sembolik yürütmede (opens in a new tab)) veya somut girdiler (örneğin, fuzzing'de (opens in a new tab)) üretir. Özellik tabanlı testin bu biçimi, test senaryolarının birden fazla senaryoyu kapsaması ve test senaryolarının oluşturulmasını bir programın ele alması bakımından birim testlerinden farklıdır.

Fuzzing (opens in a new tab), akıllı sözleşmelerdeki rastgele özellikleri doğrulamak için kullanılan bir dinamik analiz tekniği örneğidir. Bir fuzzer, tanımlanmış bir girdi değerinin rastgele veya hatalı biçimlendirilmiş varyasyonlarıyla hedef bir sözleşmedeki işlevleri çağırır. Akıllı sözleşme bir hata durumuna girerse (örneğin, bir doğrulamanın başarısız olduğu bir durum), sorun işaretlenir ve yürütmeyi savunmasız yola yönlendiren girdiler bir raporda üretilir.

Fuzzing, beklenmeyen girdilerin yanlış işlenmesi istenmeyen yürütmeye neden olabileceğinden ve tehlikeli etkiler üretebileceğinden, bir akıllı sözleşmenin girdi doğrulama mekanizmasını değerlendirmek için yararlıdır. Özellik tabanlı testin bu biçimi birçok nedenden dolayı ideal olabilir:

Birçok senaryoyu kapsayacak test senaryoları yazmak zordur. Bir özellik testi yalnızca bir davranışı ve davranışı test etmek için bir veri aralığını tanımlamanızı gerektirir; program, tanımlanan özelliğe dayalı olarak test senaryolarını otomatik olarak oluşturur.
Test paketiniz program içindeki tüm olası yolları yeterince kapsamayabilir. %100 kapsamla bile uç durumları gözden kaçırmak mümkündür.
Birim testleri, bir sözleşmenin örnek veriler için doğru şekilde yürütüldüğünü kanıtlar, ancak sözleşmenin örnek dışındaki girdiler için doğru şekilde yürütülüp yürütülmediği bilinmemektedir. Özellik testleri, doğrulama hatalarına neden olan yürütme izlerini bulmak için belirli bir girdi değerinin birden fazla varyasyonuyla hedef bir sözleşmeyi yürütür. Bu nedenle, bir özellik testi, bir sözleşmenin geniş bir girdi verisi sınıfı için doğru şekilde yürütüldüğüne dair daha fazla garanti sağlar.

Akıllı sözleşmeler için özellik tabanlı test çalıştırma yönergeleri

Özellik tabanlı test çalıştırmak genellikle bir akıllı sözleşmede doğrulamak istediğiniz bir özelliği (örneğin, tamsayı taşmalarının (opens in a new tab) olmaması) veya özellikler koleksiyonunu tanımlamakla başlar. Özellik testleri yazarken, programın işlem girdileri için veri üretebileceği bir değer aralığı tanımlamanız da gerekebilir.

Düzgün bir şekilde yapılandırıldıktan sonra, özellik test aracı akıllı sözleşmenizin işlevlerini rastgele oluşturulmuş girdilerle yürütecektir. Herhangi bir doğrulama ihlali varsa, değerlendirilen özelliği ihlal eden somut girdi verilerini içeren bir rapor almalısınız. Farklı araçlarla özellik tabanlı test çalıştırmaya başlamak için aşağıdaki kılavuzlardan bazılarına bakın:

Akıllı sözleşmeler için manuel test

Akıllı sözleşmelerin manuel testi genellikle otomatik testleri çalıştırdıktan sonra geliştirme döngüsünün ilerleyen aşamalarında gelir. Bu test biçimi, teknik gereksinimlerde belirtildiği gibi performans gösterip göstermediğini görmek için akıllı sözleşmeyi tam entegre bir ürün olarak değerlendirir.

Sözleşmeleri yerel bir blokzincirde test etme

Yerel bir geliştirme ortamında gerçekleştirilen otomatik testler yararlı hata ayıklama bilgileri sağlayabilse de, akıllı sözleşmenizin bir üretim ortamında nasıl davrandığını bilmek isteyeceksiniz. Ancak, ana Ethereum zincirine dağıtmak gaz ücretlerine neden olur; akıllı sözleşmenizde hala hatalar varsa sizin veya kullanıcılarınızın gerçek para kaybedebileceğinden bahsetmiyoruz bile.

Sözleşmenizi yerel bir blokzincirde (aynı zamanda geliştirme ağı olarak da bilinir) test etmek, Ana Ağ'da test etmeye önerilen bir alternatiftir. Yerel bir blokzincir, bilgisayarınızda yerel olarak çalışan ve Ethereum'un yürütme katmanının davranışını simüle eden Ethereum blokzincirinin bir kopyasıdır. Bu nedenle, önemli bir ek yük getirmeden bir sözleşmeyle etkileşime girmek için işlemleri programlayabilirsiniz.

Sözleşmeleri yerel bir blokzincirde çalıştırmak, manuel entegrasyon testinin bir biçimi olarak yararlı olabilir. Akıllı sözleşmeler yüksek oranda birleştirilebilirdir, bu da mevcut protokollerle entegre olmanıza olanak tanır; ancak yine de bu tür karmaşık zincir içi etkileşimlerin doğru sonuçlar ürettiğinden emin olmanız gerekir.

Geliştirme ağları hakkında daha fazlası.

Sözleşmeleri test ağlarında test etme

Bir test ağı, gerçek dünya değeri olmayan Ether (ETH) kullanması dışında tam olarak Ethereum Ana Ağı gibi çalışır. Sözleşmenizi bir test ağına dağıtmak, herkesin fonları riske atmadan (örneğin, dapp'in ön ucu aracılığıyla) onunla etkileşime girebileceği anlamına gelir.

Bu manuel test biçimi, uygulamanızın uçtan uca akışını bir kullanıcının bakış açısından değerlendirmek için yararlıdır. Burada, beta test uzmanları ayrıca deneme çalıştırmaları gerçekleştirebilir ve sözleşmenin iş mantığı ve genel işlevselliği ile ilgili herhangi bir sorunu bildirebilir.

Yerel bir blokzincirde test ettikten sonra bir test ağına dağıtmak idealdir çünkü test ağı Ethereum Sanal Makinesi'nin davranışına daha yakındır. Bu nedenle, birçok Ethereum yerel projesinin, bir akıllı sözleşmenin gerçek dünya koşulları altındaki çalışmasını değerlendirmek için dapp'leri test ağlarına dağıtması yaygındır.

Ethereum test ağları hakkında daha fazlası.

Test etme ve biçimsel doğrulama

Test etme, bir sözleşmenin bazı veri girdileri için beklenen sonuçları döndürdüğünü doğrulamaya yardımcı olsa da, testler sırasında kullanılmayan girdiler için aynı şeyi kesin olarak kanıtlayamaz. Bu nedenle, bir akıllı sözleşmeyi test etmek "işlevsel doğruluğu" garanti edemez (yani, bir programın tüm girdi değerleri kümeleri için gerektiği gibi davrandığını gösteremez).

Biçimsel doğrulama, programın biçimsel bir modelinin biçimsel belirtimle eşleşip eşleşmediğini kontrol ederek yazılımın doğruluğunu değerlendirmeye yönelik bir yaklaşımdır. Biçimsel bir model, bir programın soyut matematiksel bir temsilidir, biçimsel bir belirtim ise bir programın özelliklerini (yani, programın yürütülmesiyle ilgili mantıksal doğrulamaları) tanımlar.

Özellikler matematiksel terimlerle yazıldığından, sistemin biçimsel (matematiksel) bir modelinin mantıksal çıkarım kurallarını kullanarak bir belirtimi karşıladığını doğrulamak mümkün hale gelir. Bu nedenle, biçimsel doğrulama araçlarının bir sistemin doğruluğunun 'matematiksel kanıtını' ürettiği söylenir.

Test etmenin aksine, biçimsel doğrulama, bir akıllı sözleşmenin yürütülmesinin örnek verilerle yürütülmesine gerek kalmadan tüm yürütmeler için biçimsel bir belirtimi karşıladığını (yani hiçbir hatası olmadığını) doğrulamak için kullanılabilir. Bu sadece düzinelerce birim testini çalıştırmak için harcanan zamanı azaltmakla kalmaz, aynı zamanda gizli güvenlik açıklarını yakalamada da daha etkilidir. Bununla birlikte, biçimsel doğrulama teknikleri, uygulama zorluklarına ve yararlılıklarına bağlı olarak bir yelpazede yer alır.

Akıllı sözleşmeler için biçimsel doğrulama hakkında daha fazlası.

Test etme, denetimler ve hata ödülleri

Belirtildiği gibi, titiz testler bir sözleşmede hata olmadığını nadiren garanti edebilir; biçimsel doğrulama yaklaşımları daha güçlü doğruluk güvenceleri sağlayabilir ancak şu anda kullanımları zordur ve önemli maliyetlere neden olurlar.

Yine de, bağımsız bir kod incelemesi alarak sözleşme güvenlik açıklarını yakalama olasılığını daha da artırabilirsiniz. Akıllı sözleşme denetimleri (opens in a new tab) ve hata ödülleri (opens in a new tab), başkalarının sözleşmelerinizi analiz etmesini sağlamanın iki yoludur.

Denetimler, akıllı sözleşmelerdeki güvenlik açıkları ve zayıf geliştirme uygulamaları vakalarını bulma konusunda deneyimli denetçiler tarafından gerçekleştirilir. Bir denetim genellikle test etmeyi (ve muhtemelen biçimsel doğrulamayı) ve tüm kod tabanının manuel olarak incelenmesini içerecektir.

Buna karşılık, bir hata ödül programı genellikle bir akıllı sözleşmede bir güvenlik açığı keşfeden ve bunu geliştiricilere açıklayan bir kişiye (genellikle beyaz şapkalı bilgisayar korsanları (opens in a new tab) olarak tanımlanır) finansal bir ödül sunmayı içerir. Hata ödülleri, başkalarından akıllı sözleşmelerdeki kusurları bulmaya yardım etmelerini istemeyi içerdiğinden denetimlere benzer.

En büyük fark, hata ödül programlarının daha geniş geliştirici/bilgisayar korsanı topluluğuna açık olması ve benzersiz becerilere ve deneyime sahip geniş bir etik bilgisayar korsanları ve bağımsız güvenlik profesyonelleri sınıfını çekmesidir. Bu, temel olarak sınırlı veya dar uzmanlığa sahip olabilecek ekiplere dayanan akıllı sözleşme denetimlerine göre bir avantaj olabilir.

Test araçları ve kütüphaneleri

Birim testi araçları

solidity-coverage (opens in a new tab) - Solidity ile yazılmış akıllı sözleşmeler için kod kapsamı aracı.
Waffle (opens in a new tab) - Gelişmiş akıllı sözleşme geliştirme ve testi için çerçeve (Ethers.js tabanlı).
Remix Tests (opens in a new tab) - Solidity akıllı sözleşmelerini test etme aracı. Bir sözleşme için test senaryoları yazmak ve çalıştırmak için kullanılan Remix IDE "Solidity Unit Testing" eklentisinin altında çalışır.
OpenZeppelin Test Helpers (opens in a new tab) - Ethereum akıllı sözleşme testi için doğrulama kütüphanesi. Sözleşmelerinizin beklendiği gibi davrandığından emin olun!
Brownie birim testi çerçevesi (opens in a new tab) - Brownie, minimum kodla küçük testler yazmanıza olanak tanıyan, büyük projeler için iyi ölçeklenen ve son derece genişletilebilir, zengin özelliklere sahip bir test çerçevesi olan Pytest'i kullanır.
Foundry Tests (opens in a new tab) - Foundry, basit birim testleri, gaz optimizasyonu kontrolleri ve sözleşme fuzzing'i yürütebilen hızlı ve esnek bir Ethereum test çerçevesi olan Forge'u sunar.
Hardhat Tests (opens in a new tab) - Ethers.js, Mocha ve Chai tabanlı akıllı sözleşmeleri test etme çerçevesesi.
ApeWorx (opens in a new tab) - Ethereum Sanal Makinesi'ni hedefleyen akıllı sözleşmeler için Python tabanlı geliştirme ve test çerçevesi.
Wake (opens in a new tab) - En iyi kullanıcı deneyimi ve performans için pytest ve Anvil'i kullanan, güçlü hata ayıklama yetenekleri ve zincirler arası test desteği ile birim testi ve fuzzing için Python tabanlı çerçeve.

Özellik tabanlı test araçları

Statik analiz araçları

Slither (opens in a new tab) - Güvenlik açıklarını bulmak, kod kavramayı geliştirmek ve akıllı sözleşmeler için özel analizler yazmak için Python tabanlı Solidity statik analiz çerçevesi.
Ethlint (opens in a new tab) - Solidity akıllı sözleşme programlama dili için stil ve güvenlik en iyi uygulamalarını zorunlu kılmak için Linter.
Cyfrin Aderyn (opens in a new tab) - Web3 akıllı sözleşme güvenliği ve geliştirmesi için özel olarak tasarlanmış Rust tabanlı statik analizör.
Wake (opens in a new tab) - Güvenlik açığı ve kod kalitesi dedektörleri, koddan yararlı bilgiler çıkarmak için yazıcılar ve özel alt modüller yazma desteği içeren Python tabanlı statik analiz çerçevesi.
Slippy (opens in a new tab) - Solidity için basit ve güçlü bir linter.

Dinamik analiz araçları

Echidna (opens in a new tab) - Özellik tabanlı test yoluyla akıllı sözleşmelerdeki güvenlik açıklarını tespit etmek için hızlı sözleşme fuzzer'ı.
Diligence Fuzzing (opens in a new tab) - Akıllı sözleşme kodundaki özellik ihlallerini tespit etmek için yararlı otomatik fuzzing aracı.
Manticore (opens in a new tab) - EVM baytkodunu analiz etmek için dinamik sembolik yürütme çerçevesi.
Mythril (opens in a new tab) - Leke analizi (taint analysis), konkolik analiz ve kontrol akışı denetimi kullanarak sözleşme güvenlik açıklarını tespit etmek için EVM baytkod değerlendirme aracı.
Diligence Scribble (opens in a new tab) - Scribble, akıllı sözleşmelere, sözleşmeleri Diligence Fuzzing veya MythX gibi araçlarla otomatik olarak test etmenize olanak tanıyan özelliklerle açıklama eklemenizi sağlayan bir belirtim dili ve çalışma zamanı doğrulama aracıdır.

Daha fazla bilgi

Eğitimler: Ethereum'da akıllı sözleşme testi

Yerel, çok istemcili bir test ağında bir dApp nasıl geliştirilir ve test edilir – Bir akıllı sözleşmeyi yerel bir test ağına dağıtma ve testler gerçekleştirme kılavuzu.
Test için Solidity akıllı sözleşmeleri nasıl taklit edilir (mock) – Sahte (mock) verilerin nasıl kullanılacağı ve birim testinin nasıl uygulanacağı hakkında orta düzey eğitim.
Akıllı sözleşmeleri test etmek için Echidna nasıl kullanılır – Fuzzing ve akıllı sözleşme testine gelişmiş yaklaşımlar.