軟件測試，從測試對象來區分，可以划為系統軟件和應用軟件兩大塊。應用軟件是為了某種特定的用途而被開發的軟件，包括終端用戶的衣食出行、教育、娛樂等，簡單理解，和用戶相關聯的大部分軟件都是應用軟件。而系統軟件是用來管理硬件或者服務上層軟件的，比如操作系統、驅動管理等用戶基本不直接打交道的軟件，大部分處於應用軟件下一層的位置。
---加個應景圖？應用軟件在系統軟件上面---
應用軟件一般是為了解決實際問題而專門設計的業務代碼，在使用過程用戶體驗性強，所見即所得，輸入后即有輸出響應。因此，在測試過程中，應用軟件更多的是通過輸入和輸出結果就能判斷代碼的正確性，即每個功能特性是否都實現了，代碼運行的結果是否正確。而系統軟件一般是偏底層作為服務支撐類，例如操作系統，它的主要作用就是服務於上層應用。內存管理、進程調度以及對文件系統的管理等一些核心功能都是用於服務應用的，這些特性模塊僅從輸入輸出結果的測試很難保證其質量。比如內存管理，我們首先想到的是它會分配內存，用完在回收內存。啟動一個進程進行驗證，運行一段時間，然后退出，不出意外整個過程應該很順利，即使同時啟動多個進程進行驗證，大概率也能得到滿意的結果。這樣的內存管理是否就沒問題呢，不一定，我們可以對前面的驗證過程稍加改動，寫個腳本對進程循環的啟停，或者對一批應用進程做這種驗證，再去檢查內存，驗證效果可能就不同，甚至提供的機器內存本身就可以動態調整，測試效果肯定又會不一樣了。
從以上分析，可以看到，應用軟件的測試重點會關注到軟件本身，它的功能、代碼執行結果以及相應條件下的性能，這也是用戶在上線后關注的焦點，而對於一些外部因素，比如斷電業務不能再使用，網絡波動導致消息發送很慢，甚至無法發送等，對於這些導致的問題，通常不會影響到對軟件本身的評價。而系統軟件除了它自身的功能需滿足外，更重要的是在各種不確定的外部環境下還能否也正常工作。比如常見的數據庫管理軟件mysql，讓數據有序的存儲並管理起來，以供業務能按預期正常工作是它重要功能，但也是它最下限基礎功能。業務在使用mysql的時候其實對它應對極端場景的能力更為關注，比如應用程序跑飛、進程異常、系統重啟等等，在這些異常環境下，數據庫系統能怎樣處理正在交易的數據，落盤、容災、容錯等，這些能力在生產使用中會更重要。
區塊鏈是一個分布式的共享賬本及數據庫，它的定義很長，我們用幾個關鍵字來描述下它，“去中心化、加密算法、不可篡改、可以追溯、集體維護、公開透明”，所有這些特點，都是為了服務上層應用，從它的特性我們把區塊鏈歸類為系統軟件中。區塊鏈平台一般是由分布在不同區域、不同機器上的節點組成，節點間通過網絡構成一個分布式系統，區塊鏈實質上就是一個分布式系統軟件。因此，在質量管理上，系統軟件和分布式系統是區塊鏈測試的兩個大方向。目前業界主要有公有鏈、聯盟鏈以及私有鏈三種模式，不管哪種運轉模式，對於區塊鏈這種底層平台軟件，測試過程應至少需包含四大塊內容，分別為功能、性能、可靠性和安全性，下面從這四個角度討論區塊鏈平台的一些測試思路。
功能
任何軟件，不管是系統軟件還是應用軟件，首先會關注它具有的功能，這基本上決定了一個軟件的可用范圍。區塊鏈作為一個分布式的系統軟件，在質量體系建立過程，基礎功能是每個版本必須重點測試的部分，它覆蓋了區塊鏈能服務於應用所具備的基礎能力，下面討論幾個比較關注的功能。
環境支持
一個軟件的使用，我們首先考慮的是它能在怎樣的環境下運行，通常來說兩方面，硬件環境和軟件環境。硬件要求，主流的X86架構、ARM架構等是否支持，或者說騰訊雲、阿里雲以及華為雲等雲服務器能否適配。
而軟件環境除了外部條件還要考慮自身因素，比如操作系統類型以及版本，依賴的組件或者庫。對於區塊鏈這類分布式軟件，節點間組網模式采用內網、外網以及混合組網，還有采用Nginx代理進出的方式，以上都是在構建區塊鏈環境時需規划考慮的。
節點管理
作為區塊鏈運轉的載體，所有的事情幾乎都要節點參與，網絡通信、邏輯運算、交易、數據驗證等，而區塊鏈一般是由多個節點組成協同工作，因此節點屬性及對節點的管理至關重要。根據節點的分工不同，可分為記賬節點和觀察節點，記賬節點負責打包共識，觀察節點同步最高塊數據，不同節點類型可進行切換。
在實際管理中，節點能由管理者操作加入或者退出區塊鏈網絡，而不影響業務的正常運行，以及擴容新增節點。長期使用的軟件，一般都會迭代更新，區塊鏈節點也應能夠進行升級，包括灰度升級能力，升級后業務正常運行。
連接
區塊鏈的顯著特點它是一個分布式系統，因此連接尤為重要，節點間任一網絡抖動都可能影響到區塊鏈的正常工作。只有連接正常，才能保證后續的交易、共識、同步等功能特性正常展開。
在區塊鏈系統中，涉及到連接的地方主要有節點間p2p連接、節點與客戶端的連接，以及鏈下機構間通過鏈上節點進行通信。通常在環境條件正常時，以上連接都能順利進行，並且通過網絡連接命令和日志信息能查詢對應結果。而真正考驗連接的健壯性是在異常環境下系統的應對能力，以及環境恢復正常之后，連接能否也恢復正常。
實際生產應用中，會影響連接的因素很多，區塊鏈系統本身來看，節點（SDK）證書合法性、黑白名單等將影響節點發起的連接能否成功。更常見的是外部環境對連接的影響，比如節點所在的服務器斷連、網絡的閃斷或者帶寬偏低、端口及網卡故障，以及CPU、內存的使用過高，甚至是機器重啟導致進程重啟等，這些都會對連接產生嚴重的影響。在測試驗證過程，這些異常因素出現時，連接效果是不確定的，最壞的結果就是斷連。但是在以上各種外部故障問題解決，環境恢復正常后，連接也應當能恢復正常，而不用去重啟進程，這些在測試過程需重點檢查。
連接的邊界很多，需要通過一些工具或命令進行模擬，在清楚連接的原理和過程之后，要做的就是把各種可能影響連接的因素模擬出來，或者是多個場景的混合模型進行組合，驗證代碼處理邏輯的正確性。
共識算法
正所謂“無共識，不區塊”，作為區塊鏈的核心屬性，共識機制不僅決定記賬節點如何打包出塊，還需要提供系統能正常工作的容錯機制，並且保證各共識節點對交易執行結果達成一致。
一個底層平台選擇哪種共識算法，主要與該平台使用的場景以及想解決的問題有關。它能支持的共識機制類型，以及在不同的場景，共識算法是否可插拔，提供便利的算法配置方式。因此底層平台完成共識算法選型后，我們需要驗證的是，這種共識機制能否按預期算法完成從交易觸發到數據落盤，以及在容錯和容災范圍內依然正常工作。區塊鏈平台上線前，對其使用的共識算法需要做嚴格的測試驗證，涉及功能、安全、易用性等各方面。
共識過程一般包括打包、執行、簽名、驗證、落盤等主要階段，任一階段出現問題都會導致流程無法進行，對應節點無法參與共識，甚至整個鏈無法工作。對共識算法的質量要求實際上就是在共識的某個階段遇到問題，它的應對機制是否可行，而不是卡在那或者直接系統崩潰。就比如打包，正常節點打完包執行之后發出去，其他節點共識。但遇到節點打包失敗情況，其他節點如何反應，一般共識會有超時機制，如果此時在模擬下節點機器時間的改動，就能驗到系統時間對共識的影響了。所以在測試共識算法前，需要清楚共識內部主要流程，才能對每一步驟構造場景進行相應測試。對於一個區塊鏈平台，只是保證共識每一步邏輯沒問題還遠遠不夠，這只是證明它能正常共識，還需考慮更多外部場景，比如每個節點所處的環境就可能不一樣，導致大家共識效率也會不一樣。
在系統正常運行，無故障、無欺詐節點時，能正確共識，各節點數據能一致，但是在涉及一些安全方面，平台也要有相應處理機制，比如共識過程某節點把交易篡改了，網絡中其他節點能識別該欺詐節點信息並做相應處理。處於網絡中的節點不可避免的會受到外部環境干擾，導致節點不能正常工作，共識算法在應對這類故障時，應具備容錯能力，保證故障節點數少於理論值區塊鏈系統還能正常共識。在復雜的多群組架構中，一個記賬節點可能會同時屬於多個群組，系統需要保證節點在不同群組能獨立共識獨立存儲。
智能合約
作為區塊鏈2.0的標簽，智能合約猶如靈魂，通過代碼的運行展示了區塊鏈這種新型技術的獨特魅力。如何最大程度發揮合約特性，關鍵還看區塊鏈平台提供了哪些合約管理能力。
合約的本質是由語言寫出來的一些代碼，通過區塊鏈平台提供的執行環境，運行其中的代碼邏輯，達到預期目標。平台支持的合約語言越豐富，用戶實現功能選擇的余地就越多，對項目盡早落地能有更好的保障。通用的solidity合約以其語法簡單、操作便利等優勢而廣泛使用，而對於有高性能要求的應用，預編譯合約將會是更好的選擇。以及逐漸開始流行的rust、go等語言在合約中使用，讓項目的合約開發選擇有了多樣性，滿足了不同開發者要求。
除了合約語言的支持，合約的使用和管理對區塊鏈平台是一個更重要的評測標准。包括合約的部署方式是否簡便，即能提供哪些語言支持的客戶端或者中間件工具部署合約，以及發送交易。合約是否支持升級，升級后如何管理版本。除了合約本身的升級，區塊鏈節點升級后，已經部署的老合約也應當能繼續調用，兼容性都沒問題，正常發送交易。
隨着對合約使用靈活性要求越來越高，像普通軟件一樣，合約的生命管理周期也納入了區塊鏈平台測試范圍。從合約編寫、部署、調用一直到廢棄，這一整個過程需要驗證的功能點非常多，我們只從合約的角度考慮。拿solidity語言來說，需要驗證提供的各種變量類型、語法表達式、控制接口等合約結構，在區塊鏈平台是否都能跑通。某些安全場景下，能否凍結或者銷毀合約，使之不能再被調用執行，在需要使用時，又能解凍。
同步
在環境正常時，區塊鏈各節點數據都應一致，同步特性至關重要。區塊鏈系統同步主要包括交易同步、區塊同步和狀態同步，只有每個場景下的同步始終保持正常，區塊鏈才能正常工作。
連接正常時，客戶端發送到節點的交易，應當能同步到網絡中其他節點。不同的區塊鏈平台，根據節點的類型，組網模式，會采用不同的同步邏輯。區塊同步涉及場景較多，新入網節點、進程停止一段時間在重啟、節點遭遇故障導致數據丟失等，都會觸發區塊同步邏輯，以及在沒有交易處理時，節點間也會保持狀態的同步，以上都涉及到很多的同步場景，在測試中需對每一個場景設計詳細、全面的驗證過程，包括一些場景的交叉測試。
存儲
區塊鏈從狹隘角度看，是一個數據庫，可用於存儲數據，類比常見的業務存儲模式，需要從數據組織模式和數據存儲介質，以及容災等幾大塊展開測試驗證。區塊鏈存儲也類似，各種區塊的數據在存儲前需要進行相應的組織管理再存到介質中，但是區塊鏈數據在落盤存儲前要經歷較漫長復雜的共識過程，也就是最終的數據都是共識確認過的。
可以從賬戶狀態和存儲介質對區塊鏈的存儲進行功能和穩定性測試。賬戶狀態對應着合約局部變量的狀態存儲形式，根據平台提供的選擇，配置成默克爾樹結構或者分布式存儲的世界狀態模型，來進行相應的測試驗證。而對於存儲介質的選擇，主要看區塊鏈平台提供了哪些存儲驅動，常見的leveldb、rocksdb、mysql，因此可以將賬戶狀態模型和存儲介質引擎進行組合測試。
存儲功能的驗證主要還是穩定性和正確性，在落盤成功的基礎上還要保證節點間數據都一致。每個節點根據條件可以選擇不同的存儲介質，而涉及到存儲的地方很多，共識，同步等都要存儲，可采用混沌模型測試，各場景進行組合，驗證每個節點存儲穩定且數據正確。
兼容
任何產品在使用周期內，不論硬件還是軟件，兼容性是一個不能避開的話題。區塊鏈是一個復雜系統軟件，涉及很多模塊特性，以及最為重要的鏈上數據，所以在架構設計和升級時，兼容性必須謹慎規划和全面測試。
在區塊鏈系統中，兼容性主要考慮兩大塊，自身兼容和周邊兼容。對於自身兼容主要關注的是，在完成一次區塊鏈版本升級后，鏈上歷史數據是否還能正常使用，包括各種業務操作以及歷史功能特性都能正常運行。而周邊兼容則需要考慮周邊組件和工具等配套，甚至一些版本的對應關系。
在分布式系統中，處於不同條件下節點管理方式可能存在差異，因此還需考慮灰度升級的情況，也就是節點有新老版本共存的現象，這種模式下需要測試驗證的場景會較多，所有的功能特性在新老節點上都應操作驗證一遍。
接口
類似於操作系統為應用層提供了系統調用接口，用於訪問內核，區塊鏈也有許多RPC接口供外部調用，根據實際需要調用合約，去鏈上讀或者寫數據，或者直接http協議調用RPC接口。接口的測試重點在輸入穩定輸出正確，多關注邊界，外部對節點的訪問能持續不斷連。接口測試采用自動化是比較簡單的，同時模擬接口在一定壓力訪問下，客戶端對節點發送交易，鏈上共識能否保持正常。
數據治理
鏈上有大量的數據，怎樣管理這些數據以供使用，特別是在業務量大的應用中，面對海量的鏈上數據，如何做適當的處理，讓歷史數據歸檔甚至是刪除，而又不影響業務的正常運行。這些都離不開現在越來越熱的一個話題--數據治理，即數據有了，怎么去治理和利用它。
想要最優化管理和利用鏈上數據，主要還是看區塊鏈平台自身屬性和相關組件能提供什么工具。鏈上主要有區塊數據、交易數據以及狀態數據，常見的治理方式有數據導出、數據導入、數據裁剪等，不同的需求對應不同數據治理方式。
數據導出
對於上層應用來說，區塊鏈上的數據不易查看和使用，可以通過數據導出工具將數據遷移到mysql或者oracle中，后續做成可視化報表或者進行業務對賬，就可以利用數據庫中的數據完成相關設計。整個過程主要關注導出數據的正確性，是否和鏈上的數據一致，以及數據缺失、重復和覆蓋等現象。
數據裁剪
隨着區塊鏈長時間運行，業務產生的數據越來越多，對存儲和性能都是很大的考驗，但另一方面鏈上有大量使用率低的冷數據，嚴重影響查詢性能，這時就可以考慮對數據進行裁剪。舉個例子，區塊鏈塊高到達三萬時，可以將前兩萬塊數據進行裁剪，鏈上只保留最新一萬塊的數據，同時，被裁剪的數據保存在其他地方能繼續被使用。裁剪不僅是工具處理數據的過程，還要保證被裁剪的數據可用性。數據裁剪后所有上層業務需保證繼續正常運行，包括已部署的合約業務和新部署的合約，都能正常調用，同時節點自身的退網、入網、同步、兼容性等各種特性都不受影響。被裁剪的數據雖然不在鏈上，但鏈上業務運行過程還是可能會用到，因此涉及到這部分數據的測試場景也需要全覆蓋驗證。
數據導入
在區塊鏈系統中，當有新節點加入組網時，為了和其他節點保持同樣狀態，需要從其他節點同步數據，直到塊高相同。這種同步方式需要考慮兩方面的影響，一是在塊高很大時，同步完所有數據需要耗費很長時間，另一方面節點從其他節點同步數據過程，也會影響系統性能。通過已導出的全量鏈上數據，來快速完成這部分同步工作，使新節點快速達到鏈上最新狀態。用這種數據導入的方式能快速完成同步過程，而不對原組網產生影響。除了新入網節點，在遇到突發情況導致組網中節點數據丟失時，采用數據導入讓節點快速同步數據。對數據導入特性的驗證，重點是數據被導入后新節點功能的完整性，也就是網絡中老節點具有的特性，新節點也完全一致，打包、執行交易、同步等功能都正常。
性能
作為一個底層平台，性能一個很關鍵的指標，它決定了上層應用在高峰期能跑多少的業務量。一個系統中每個接口，每個功能特性都會涉及到性能，但並非都需要壓出其性能。對於區塊鏈來說，重點關注的是它處理交易的性能，從客戶端發起交易，簽名，到節點打包、共識，最后數據落盤，這一完整過程系統的性能。
任何一個性能數據背后都對應着軟件和硬件配置組合的結果，包括cpu、內存、磁盤、帶寬等硬件條件，以及壓測的合約類型、交易大小，節點組網模式等因素都會影響性能結果。理論上，代碼自己沒有邏輯錯誤，只要配置跟上，性能是可以無限的。但實際生產條件肯定有個上限，因此壓測的性能數據可以提供兩份，生產常用的硬件及軟件配置條件下的，和實驗室里高配的硬件和軟件時的性能數據。
性能壓測可以達到兩個目的，一是壓出系統的性能，還一個是通過壓測發現代碼的一些bug，比如cpu、內存等硬件沒有發現瓶頸，但是性能確一直上不去，這可能就是代碼實現的邏輯有問題了。在性能數據基礎上，繼續加大交易並發量，就能對系統做進行壓力測試，驗證其他指標。在性能數據基礎上，適當減少交易並發量，也能對系統進行穩定性測試。
可靠性
區塊鏈測試與傳統的軟件測試有較大區別，文章開頭很大篇幅討論了系統軟件和應用軟件的側重點，底層系統軟件更關注穩定性，而上層應用軟件在於功能特性。因此，在區塊鏈質量體系的構建過程中，可靠性是最重要的內容之一，需要投入大量的資源去模擬各種可能的場景，完成可靠性驗證。
熟悉區塊鏈之后會發現，它邊界比較模糊。傳統的軟件，不管是是獨立的應用程序，還是客戶端/服務器模式的應用程序，都有明顯的系統邊界，可以通過UI用戶界面或者客戶端去進行測試。區塊鏈底層，則是一個完全去中心化的分布式網絡。這個網絡有可能跨越多個子網、多個數據中心、多個運營商、甚至多個國家，其邊界是模糊的。對於區塊鏈底層的測試，不僅僅是前端API與某個區塊鏈節點之間的測試，還涉及大量區塊鏈節點與節點之間的測試。所以，如果只是單一的去做某個特性的測試，比如連接或者同步，同樣條件，這次成功，下次可能就會失敗，因為區塊鏈是個分布式的系統軟件，一個節點的正常不代表整個系統正常。
既然是一個分布式的軟件，測試過程也需要融入分布式思想，而不能停留在中心化軟件上。某個節點在同步，其他節點可能在共識，包括節點所在機器環境也可能隨時發生變化，在場景模擬的過程，需要將軟件、硬件以及區塊鏈自身操作進行各種組合驗證，稱為混沌測試。常用的混沌測試工具有操作系統自帶的iptables、tc、 wondershaper 等，可用於模擬機器間連接、端口是否可用、丟包、帶寬控制，或者使用開源工具ChaosBlade也能完成以上模擬，包括cpu、內存等使用率。在結合前面章節討論的節點連接、共識、同步等特性測試方法，進行各種混合測試。區塊鏈的邊界比較模糊，而混沌測試法正是通過模擬的方式，讓系統盡可能運行在邊界處，就比如PBFT共識算法，四節點的網絡，讓其中三個正常運行，剩下的一個節點進程停止，比同時讓四個節點都正常跑着，進行場景模擬會更容易發現一些邊界問題。所有場景模擬過程，可同時進行一些壓力測試，保證時刻有交易在鏈上處理。
安全
任何產品在上線前都會考慮安全的問題，對軟件來說安全威脅主要有人為主觀因素和自然客觀因素兩種，為應對各種安全風險，有監管提前預防的措施，比如設置機器或者端口訪問權限，或者通過拉專線進行聯絡等。還有的是通過技術手段來防范這些安全隱患，本章主要討論采用相關的技術手段來保證區塊鏈的安全。
區塊鏈系統涉及的安全包括很多方面，從連接到共識、從算法到隱私保護，都和安全息息相關，安全措施覆蓋的越全面，系統被攻擊的概率越低，運行更穩健。區塊鏈是由節點組成，而對於非法節點的加入，平台是否提供了證書網絡准入機制或者黑白名單特性，解決非法連接和入網問題。鏈上大量的數據或者各種類型的表，需要提供權限管理機制給不同用戶授予不同操作權限，包括部署合約及發送交易。
而對於加密算法，需要考慮能否支持國密算法，以及在隱私保護中，同態加密和群環簽名是都具備。落盤數據能否進行加密，而不影響系統的正常運行，包括在多群組中，數據是否隔離等，以上都是作為一個區塊鏈底層平台需要覆蓋到的安全措施。
總結
以上從四個方面對區塊鏈平台應具備的基本要素進行了簡要討論，但一個區塊鏈系統涉及的內容遠不止這些，每個功能特性都是作為區塊鏈的一個重要標簽。除了完成上面各種場景的測試驗證，還應結合具體業務模型，在區塊鏈上進行大量的實際應用批跑，只有經過長時間的運行，穩定性才能越來越高。