長文詳解PlatON測試Case全景圖

2021-08-26 18:08:55

說PlatON測試之前，我們需要先了解下關於區塊鏈測試和傳統互聯網測試的區別，其主要體現在系統邊界模糊，對於區塊鏈的測試不僅僅是前端API與某個區塊鏈節點之間的測試，還涉及大量區塊鏈節點與節點之間的測試。

同時還要注意PlatON鏈本身包含公有鏈、私有鏈，不同類型在管理、用戶身份、最大節點數等平臺自身特徵方面均有不同，測試需要考慮所有的模式，導致測試方案和場景也比常規的傳統測試更加復雜。

現在我們可以來認識下PlatON，首先它不屬於交易所類型的業務產品，而是於基於區塊鏈的技術以及鏈技術產生的價值的生態基礎服務，測試的重點也是不一樣的。我們的測試會更加關注底層，比如共識算法、網絡、存儲、經濟模型等。

PlatON測試範圍總覽

長文詳解PlatON測試Case全景圖

從Case全景圖可以看出，我們對PlatON的Case過程進行分類，主要是通過5個方面去驗證系統保證安全可靠。

初始化階段

主要是通過在鏈初始化時，搭建私鏈或者鏈接主網時對經濟模型中的合約账號、信息以及參數進行合理性的驗證。

隱式初始化-不指定網絡時鏈接PlatON主網絡，這時候需要驗證網絡節點搭建成功之後鏈上信息和內置的信息保持一致。

顯式初始化-搭建私鏈則是通過創世文件初始化的方式加入到特定的私有網絡，成功加入鏈之後驗證鏈上信息和配置的信息保持一致初始化參數。

共識參數-經濟模型參數、治理參數、懲罰參數、獎勵參數、增發參數。

初始化參數是通用的系統參數，參數分主網參數和自定義參數兩類：

主網參數-通過在啓動節點時增加命令參數來實現鏈接PlatON主網絡，需要驗證的就是鏈上共識參數、經濟模型參數、治理參數等和主網參數保持一致。

自定義參數-在啓動節點時，通過調整初始化創世文件裏的初始化參數來實現自定義參數，然後通過鏈初始化啓動節點，這時候鏈上的參數應該和創世文件中的參數保持一致。

但是這裏需要注意的是自定義參數時，創世文件中數值閾值的調整需要合理，不同的參數組合最終會導致鏈啓動成功與否以及鏈上運行的規則發生變化，我們的測試過程正是驗證這些參數變動帶來的各種邊界值，以及參數是否給鏈的運行提供合理的標准。

啓動階段

啓動階段測試我們分為兩種模式進行驗證，分別是單節點和集群，因為不同的節點數量鏈運行方式也會有所不同，我們從簡單的結構出發，然後慢慢擴展數量，從而達到模擬真實環境。

單節點

啓動節點

查看節點信息

查看版本信息

鏈上功能

集群

快速參數集群

主網集群

鏈上功能

作為區塊鏈運轉的載體，所有的事情幾乎都要節點參與，網絡通信、邏輯運算、交易、數據驗證等，而區塊鏈一般是由多個節點組成協同工作，因此節點屬性及對節點的管理至關重要。在實際管理中，節點能由管理者操作加入或者退出區塊鏈網絡，而不影響業務的正常運行，以及擴容新增節點。

在節點相關驗證，主要包含了鏈部署時不同節點數量的情況下節點的運行情況檢查，創世文件啓動時不同的參數組合對鏈影響，如共識節點數量、治理參數配置、同步方式等，我們會根據不同的組合去驗證配置參數的合理性，同時節點本身具備了不同的啓動參數，在整個鏈運行的過程中需要對啓動參數的調整來驗證這些啓動命令的有效性以及對鏈的影響。

同時還需要分別在單節點和集群模式下進行鏈上功能的驗證，確保在不同模式下PlatON經濟模型業務表示是一致的。

鏈上功能階段

這個階段也是PlatON主要的測試內容，這個階段主要包含了對底層和業務層兩個方面。

長文詳解PlatON測試Case全景圖

底層

Giskard共識

正所謂「無共識，不區塊」，作為區塊鏈的核心屬性，「共識機制」決定了區塊鏈的安全性、去中心化和可擴展性等重要性質，並且保證各共識節點對交易執行結果達成一致。

PlatON的Giskard共識協議由概率性權益證明PPoS(PlatON proof of stake)和Giskard拜佔庭容錯協議-Giskard BFT(Giskard Byzantine Fault Tolerance) 組成。PPoS使用質押、委托、隨機選取的形式選出參與共識的驗證節點，Giskard BFT使用類BFT算法實現區塊的生產和驗證。

針對Giskard共識我們設計了相應的驗證場景來覆蓋PlatON共識模塊。

1. 從共識的不同階段我們來驗證每個階段共識

viewChange：對viewChange基本信息校驗同時包含viewChange發起、收到等場景組合來驗證正確性。

prepareBlock：對prepareBlock消息基本校驗同時窗口期內viewChangeQC後發起的不同狀態下的prepareBlock進行驗證。

prepareVote：對prepareVote消息基本校驗同時不同窗口期以及不同節點狀態下的prepareVote進行驗證。

VerifyQC：包含了viewChangQC和prepareQC，主要檢測不同籤名數量下場景驗證。

2. 模擬拜佔庭場景下共識模塊的驗證

Giskard-非拜佔庭場景：模擬參與節點在非拜佔庭場景下共識模塊各個階段的驗證。

Giskard-拜佔庭場景：模擬參與節點在拜佔庭場景雙出、惡意等操作下共識模塊各個階段的驗證。

3. 異常場景下共識模塊的驗證

Giskard-節點啓停：通過啓停節點、間隔啓停、節點恢復等操作來驗證共識模塊的完整性和連續性。

Giskard-消息丟失：模擬丟棄投票、prepareBlock等場景下驗證共識消息傳遞的有效性。

Giskard-容錯：通過構建超時、惡劣環境的運行穩定性場景來驗證共識的容錯性。

通過以上場景我們測試需要驗證的是，這種共識機制能否按預期算法完成從交易觸發到數據落塊，以及在容錯和容災範圍內依然正常工作。區塊鏈平臺上线前，對其使用的共識算法需要做嚴格的測試驗證，涉及功能、安全、易用性等各方面。

P2P網絡驗證

涉及到連接的地方主要有節點間P2P連接、節點與客戶端的連接，以及鏈下機構間通過鏈上節點進行通信。通常在環境條件正常時，以上連接都能順利進行，並且通過網絡連接命令和日志信息能查詢對應結果。而真正考驗連接的健壯性是在異常環境下系統的應對能力，以及環境恢復正常之後，連接能否也恢復正常。

從而我們需要考慮從以下幾個方向來驗證p2p網絡的安全性：

1. 節點數

不同的節點數量組合，可以驗證網絡通信中消息傳遞所需要的時間是否滿足以及消息傳遞過程中是否出現遺漏和丟失。

2. 網絡流量

監控網絡流量，則是為了驗證在一個鏈運行過程中的各種業務功能和節點操作時，鏈上資源消耗情況是否能達到預期的要求，避免出現運行過程中異常流量的產生導致鏈出現無法共識的情況。

3. 節點發現

通過配置種子節點數、靜態節點數來驗證節點在互聯過程中靜態節點連接數限制，主動鏈接數限制、被動鏈接數限制是否生效，模擬在不同級別的數量節點配置情況下鏈的運行是否穩定。

發送到節點的交易，應當能同步到網絡中其他節點。不同的區塊鏈平臺，根據節點的類型、組網模式，會採用不同的同步邏輯。區塊同步涉及場景較多，新入網節點、進程停止一段時間在重啓、節點遭遇故障導致數據丟失等，都會觸發區塊同步邏輯，以及在沒有交易處理時，節點間也會保持狀態的同步，以上都涉及到很多的同步場景，在測試中需對每一個場景設計詳細、全面的驗證過程，包括一些場景的交叉測試。

區塊存儲驗證

區塊存儲功能的驗證主要還是穩定性和正確性，在落塊成功的基礎上還要保證節點之間數據都一致。

每個節點根據不同節點啓動策略部署的數據存儲的信息能有效且准確的保留信息，一般我們會根據啓動參數以及同步模式的不同採取fast或者full模式進行驗證，這時候我們需要考慮的是多交易在發送過程中記錄在本地的區塊信息是否有遺漏，同時在進行功能驗證的時候可採用混沌模型測試，各業務場景進行組合，驗證每個節點存儲穩定且數據正確。

業務層

長文詳解PlatON測試Case全景圖

經濟模型驗證

PlatON的經濟模型就是在鏈上進行各種會產生經濟活動的場景組合，所有參與到經濟活動的主體在互動時，都將伴隨着Token的變化，針對不同的經濟活動我們可以運用測試理論中的測試手段，如邊界值、等價類、因果法、場景構建等方法進行驗證，主要是活動主體的Token的數量進行校驗。

鎖倉

鎖倉創建

鎖倉質押委托

鎖倉回退

鎖倉結算

處罰通知....

Staking

createStaking (質押)

editCandidate (修改候選人信息)

increaseStaking (增持質押)

withdrewStaking (撤銷質押)

delegate (委托)

withdrewDelegate (撤銷委托)

withdrawDelegateReward (領取獎勵)

getVerifierList (查詢當前結算周期的驗證人列表)

ElectNextVerifierList (選舉下一個結算周期的驗證人列表)激勵 ……

激勵

發放質押獎勵

發放出塊獎勵

是否到達年末……

處罰

舉報雙籤

舉報雙出

查詢舉報信息

處罰規則……

在這個過程中，我們也會對節點排名、狀態、節點的收益進行驗證，針對不同的經濟活動場景進行有效的組合，其中包括了節點的狀態以及鏈的結算周期和共識周期的變化，根據不同的組合我們可以通過自動化的方式檢查活動主體的Token數量和狀態變化情況是否滿足設計要求，從而驗證了經濟模型的合理性和正確性。

治理模型驗證

PlatON治理模型主要是驗證PlatON進行鏈上治理時，鏈上節點參與投票的進行更新或者修復的一個過程，在這個過程中節點的選擇行為會影響到鏈上發展方向和鏈的一個狀態，如果節點對治理的內容有分歧則會出現不同的結果，治理升級的驗證主要是驗證治理前後鏈上數據的一致性和區塊的連續性。

提交提案

提交升級提案

提交文本提案

提交參數提案

提交取消提案 ……

投票

有效提案投票

無效提案投票

放棄投票

投票統計……

版本聲明

有效的提案聲明

無效提案聲明……

提案全流程

提交文本提案統計

提交升級提案

提交取消提案……

通過不同的結算周期、共識周期、投票節點狀態的變化來驗證治理機制的正確性。同時為了滿足實際場景中的復雜運行環境，需要增加經濟活動的場景來豐富可能出現的異常情況，從而驗證整個治理模型的可靠性。

穩定性

對於區塊鏈底層的測試，不僅僅是前端API與某個區塊鏈節點之間的測試，還涉及大量區塊鏈節點與節點之間的測試。所以，如果只是單一地去做某個特性的測試，比如連接或者同步，同樣條件，這次成功，下次可能就會失敗，因為區塊鏈是個分布式的系統軟件，一個節點的正常不代表整個系統正常。

測試過程也需要融入分布式思想，而不能停留在中心化軟件上。某個節點在同步，其他節點可能在共識，包括節點所在機器環境也可能隨時發生變化，在場景模擬的過程，需要將軟件、硬件以及區塊鏈自身操作進行各種組合驗證，區塊鏈的邊界比較模糊，而各種組合測試正好通過模擬現實運行的場景，讓系統盡可能運行在邊界處，就比如共識算法，多節點的網絡，讓其中部分正常運行，剩下的部分節點在正常的閾值內進程啓停，進行場景模擬會更容易發現一些邊界問題。所有場景模擬過程，持續運行測試，觀察資源的消耗情況，從而找到系統的盲點。

性能

作為一個底層平臺，性能是一個很關鍵的指標，它決定了上層應用在高峯期能跑多少的業務量。一個系統中每個接口，每個功能特性都會涉及到性能，但並非都需要壓出其性能。對於區塊鏈來說，重點關注的是它處理交易的性能，從客戶端發起交易、籤名，到節點打包、共識，最後數據落盤，這一完整過程系統的性能。

任何一個性能數據背後都對應着軟件和硬件配置組合的結果，包括CPU、內存、磁盤、帶寬等硬件條件，以及壓測的合約類型、交易大小，節點組網模式等因素都會影響性能結果。理論上，代碼自己沒有邏輯錯誤，只要配置跟上，性能是可以無限的。但實際生產條件肯定有個上限，因此壓測的性能數據可以提供兩份，生產常用的硬件及軟件配置條件下的，和實驗室裏高配的硬件和軟件時的性能數據。後續會再出一篇專門的性能文章，來講解PlatON性能是如何提升上去的。

擴展

合約編譯及支持

合約的使用和管理對區塊鏈是一個重要的評測標准。包括合約的部署方式是否簡便，即能提供哪些語言支持的客戶端或者中間件工具部署合約，以及發送交易。合約是否支持升級，升級後如何管理版本。除了合約本身的升級，區塊鏈節點升級後，已經部署的老合約也應當能繼續調用，兼容性都沒問題。

PlatON提供對應的編譯工具，為此我們也要對合約編譯工具及本身合約版本進行驗證，確保鏈上支持不同版本的合約語法。拿solidity語言來說，需要驗證提供的各種變量類型、語法表達式、控制接口等合約結構，在鏈上是否都能跑通，包括能否跨合約調用鏈上的內置合約功能。

安全

區塊鏈系統涉及的安全包括很多方面，從連接到共識、從算法到隱私保護，都和安全息息相關，安全措施覆蓋得越全面，系統被攻擊的概率越低，運行越穩健。區塊鏈是由節點組成，而對於非法節點的加入，平臺是否提供了證書網絡准入機制或者黑白名單特性，解決非法連接和入網問題。鏈上大量的數據或者各種類型的表，需要提供權限管理機制給不同用戶授予不同操作權限，包括部署合約及發送交易。