智能合約測試的技巧與實踐｜FISCO BCOS超話區塊鏈專場（篇7）

時間 2020-04-20

標籤智能合約測試技巧實踐 fisco bcos 區塊專場欄目比特幣简体版

原文原文鏈接

前言

區塊鏈的發展伴隨着信息安全的話題。在Solidity不長的發展歷程中，發生過不止一次駭人聽聞、影響深遠的安全攻擊事件，給一些機構和組織形成不可挽回的損失。html

『禍亂生於疏忽，測試先於交付』，若是這些缺陷和漏洞在測試環節被發現，就能有效避免損失。java

測試是智能合約開發與交付過程當中相當重要的一環。其能有效檢驗實際結果是否符合設計預期，有助識別錯誤、查缺補漏。同時，高質量、可複用的測試，還有助於提高總體開發效率。git

前文介紹了Solidity的前世此生、語法特性、設計模式、編程攻略和底層原理。做爲系列終篇，本文將重點介紹和分享Solidity的測試場景、方法和實踐。github

前置準備

進入測試前，須要完成如下步驟：鏈的搭建、控制檯安裝、智能合約開發、智能合約編譯與部署、利用Java等SDK開發一個應用。web

詳細準備工做可參考《FISCO BCOS零基礎入門，五步輕鬆構建應用》和FISCO BCOS官方文檔，此處再也不贅述。FISCO BCOS官方文檔地址：spring

https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/installation.html sql

測試環境

FISCO BCOS提供控制檯、WeBASE-Front和SDK代碼測試，這三種環境適用於不一樣測試場景：數據庫

控制檯：提供命令行交互界面，經過在控制檯建立合約和輸入調用、查詢指令，來進行簡單調試。適用於很是簡單的合約。編程
WeBASE-Front：提供可視化交互界面以及簡易的IDE環境。適用於業務邏輯並不複雜的合約，更推薦開發人員進行一些調試。設計模式
SDK：例如集成Java Web3sdk，建立一個Java項目，並編寫應用和測試代碼。適用於對智能合約質量要求較高、要求測試案例可複用、業務邏輯複雜或要求持續集成的場景。

控制檯測試

FISCO BCOS 2.0及以上版本提供了方便易用的命令行終端、『開箱即用』的區塊鏈利器，詳情可參考《FISCO BCOS 控制檯詳解，飛通常的區塊鏈體驗》。

接下來將經過一個合約示例來說解如何運用控制檯進行測試。

首先，咱們寫一個HelloWorld合約：

pragma solidity ^0.4.25;

contract HelloWorld{
    string public name;
    constructor() public{
       name = "Hello, World!";
    }
  
    function set(string n) public{
      name = n;
    }
}

而後，將這個合約命名爲HelloWorld.sol，並保存到控制檯所在的contracts/solidity/路徑下。隨後，執行./start.sh 啓動控制檯並部署合約：

=============================================================================================
Welcome to FISCO BCOS console(1.0.8)!
Type 'help' or 'h' for help. Type 'quit' or 'q' to quit console.
 ________ ______  ______   ______   ______       _______   ______   ______   ______
|        |      \/      \ /      \ /      \     |       \ /      \ /      \ /      \
| $$$$$$$$\$$$$$|  $$$$$$|  $$$$$$|  $$$$$$\    | $$$$$$$|  $$$$$$|  $$$$$$|  $$$$$$\
| $$__     | $$ | $$___\$| $$   \$| $$  | $$    | $$__/ $| $$   \$| $$  | $| $$___\$$
| $$  \    | $$  \$$    \| $$     | $$  | $$    | $$    $| $$     | $$  | $$\$$    \
| $$$$$    | $$  _\$$$$$$| $$   __| $$  | $$    | $$$$$$$| $$   __| $$  | $$_\$$$$$$\
| $$      _| $$_|  \__| $| $$__/  | $$__/ $$    | $$__/ $| $$__/  | $$__/ $|  \__| $$
| $$     |   $$ \\$$    $$\$$    $$\$$    $$    | $$    $$\$$    $$\$$    $$\$$    $$
 \$$      \$$$$$$ \$$$$$$  \$$$$$$  \$$$$$$      \$$$$$$$  \$$$$$$  \$$$$$$  \$$$$$$

=============================================================================================
[group:1]> deploy HelloWorld
contract address: 0x34e95689e05255d160fb96437a11ba97bb31809f

[group:1]>

合約被成功部署後就能夠開始測試了。咱們先打印這個合約中name的值，而後修改成新的值，最後從新查詢name中的值。

[group:1]> call HelloWorld 0x34e95689e05255d160fb96437a11ba97bb31809f name
Hello, World!

[group:1]> call HelloWorld 0x34e95689e05255d160fb96437a11ba97bb31809f set "Hello, test!"
transaction hash: 0x72c8a95b651fb5d12c44b69624d5213d58af1509f00920757fce94d019b5eae8

[group:1]> call HelloWorld 0x34e95689e05255d160fb96437a11ba97bb31809f name
Hello, test!

[group:1]>

上述例子演示瞭如何使用控制檯部署與調試合約。控制檯設計簡潔優雅，使用體驗如絲般順滑。不過，在處理一些複雜場景，例如須要切換外部帳戶，或經過可視化界面進行操做時，WeBASE-Front當仁不讓地扛起大旗。

WeBASE-Front測試

WeBASE-Front爲開發者提供了運行核心信息的可視化操做、Solidity開發的IDE環境以及私鑰管理功能，讓你們更便捷地開啓區塊鏈之旅。

關於WeBASE-Front的介紹可參考《WeBASE節點前置組件功能解析》與《安裝部署說明》。《安裝部署說明》地址：

https://webasedoc.readthedocs.io/zh_CN/latest/docs/WeBASE-Install/developer.html#

接下來，咱們演示一個須要切換外部帳戶的測試案例，如下是合約代碼：

pragma solidity ^0.4.25;

contract BasicAuth {
    address public _owner;

    constructor() public {
        _owner = msg.sender;
    }

    function setOwner(address owner)
        public
        onlyOwner
{
        _owner = owner;
    }

    modifier onlyOwner() { 
        require(msg.sender == _owner, "BasicAuth: only owner is authorized.");
        _; 
    }
}

在這個示例中，合約owner被自動賦值爲合約部署者。修飾器onlyOwner決定了setOwner函數只能由_owner用戶來發起。

在合約管理-合約IDE中，建立test文件夾，並複製合約代碼：

而後，點擊私鑰管理-新增用戶，建立user1和user2兩個用戶。

這時，選擇部署合約，會彈出用戶地址窗口選項，選擇user1。

合約部署成功後，會展現合約地址、合約名、abi、合約binary等系列信息：

點擊合約調用，彈出調用窗口，『方法』下拉框裏包含了全部可調用的函數列表，選擇_owner函數，點擊確認，就可返回該合約的_owner變量值。

如今，咱們來測試setOwner()函數。如上所述，本合約的_owner是user1，經過切換用戶user2來調用這個函數，預期結果是調用失敗。咱們選擇setOwner方法，選擇私鑰地址爲user2：

正如預期，這個函數的調用失敗了：

以上執行結果打印出了整個交易的TransactionReceipt，點擊還原可轉換爲原始output值。『所見即所得』，WeBASE-Front讓區塊鏈變得更簡單易用。

使用WeBASE-Front測試最大短板在於測試案例沒法複用。假若合約很是複雜，那全部測試案例都得靠人工一遍遍輸入，操做原始低效。

SDK測試

在系統測試中，須要遵循經典的AIR實踐原則：

Automatic：測試應該被全自動執行，這也是實現持續集成的前提。
Independent：測試案例彼此保持獨立，不存在相互依賴和調用。
Repeatable：測試案例必須可被複用。能夠跨越軟硬件環境，被重複執行。

要知足以上甚至更多測試實踐原則，使用控制檯或WeBASE-Front的方式就顯得有些力不從心，而集成SDK並編寫測試代碼的方式更值得推薦。

這種方式雖然前期花費時間較長、成本較高；但測試後期能大大下降重複的工做量，顯著提高總體測試效率。

這也符合IT公司現行的軟件測試實踐規範。通常這部分代碼由公司開發測試人員或質量保證（QA）工程師編寫。但在不少公司中，這部分代碼由開發人員編寫。良好的測試代碼，能提高代碼質量，下降代碼重構難度，提升開發效率。

FISCO BCOS提供了多語言SDK，如Java、Python、Node.js等，其中最爲成熟與經常使用的是Java版Web3SDK。《手把手教你在Eclipse中使用JavaSDK》詳細介紹了在Eclipse建立新工程以及將已經提供的示例項目導入Eclipse。

在Java開發實踐中，Springboot使用更爲深刻人心，FISCO BCOS也提供了相應使用案例，相關配置文檔能夠參考：《Spring Boot項目配置》，經過spring-boot-starter開發者可快速下載示例工程，並導入偏好的IDE中。

配置工程鏈基本環境後，下面將以上述spring-boot-starter工程爲例，介紹具體測試步驟和要點。

編寫合約：HelloWorld合約。
編譯智能合約，將其轉爲Java文件，從上述WeBASE-Front中，也能編譯並導出Java文件。
將編譯生成的Java文件導入工程中，如HelloWorld.java。
基於上述文件，調用合約功能和接口，編寫相關測試案例，例如：ContractTest。
基於Spring提供的gradle插件，咱們能夠經過"./gradlew test"命令來運行全部測試案例。
若是須要持續集成，能夠在配置和初始化FISCO BCOS後，將步驟5命令加入自動化腳本中。

接下來，咱們將具體分析核心測試代碼ContractTest：

@Test
public void deployAndCallHelloWorld() throws Exception {
    // deploy contract
    HelloWorld helloWorld = HelloWorld
           .deploy(web3j, credentials, new StaticGasProvider(GasConstants.GAS_PRICE, GasConstants.GAS_LIMIT))
           .send();
    Assert.assertNotNull(helloWorld);
    // call set function
    helloWorld.set("Hello, World!").send();
    // call get function
    String result = helloWorld.get().send();
    Assert.assertTrue("Hello, World!".equals(result));
 }

第4行中，HelloWorld合約被部署。爲符合獨立性原則，建議在每一個測試案例中部署獨立的合約，以免測試案例執行順序對正常測試形成干擾。須要模擬合約依賴性的狀況除外。
第9行和第11行，分別調用了set和get。爲符合可重複性原則，該測試案例必須設計成冪等，即在任意的軟硬件環境下，測試案例預期結果都是一致的。
第7行和第12行，使用了Junit框架提供的斷言方法，用來判斷智能合約執行結果是否符合預期。

值得一提的是，在Java SDK中，任意交易上鍊後，會得到一個回執TransactionReceipt對象，該對象中包含了返回狀態和錯誤信息（若是交易成功，則message爲null），可經過這個狀態判斷交易是否正常，例如：

TransactionReceipt tr = helloWorld.set("Hello, World!").send();
 Assert.assertEquals(tr.getMessage(), "0x0", tr.getStatus());

以上基於Springboot提供的測試特性，實現了合約測試，若是須要了解更多細節，請參考Spring的相關文檔。相關參考地址：

https://docs.spring.io/spring-boot/docs/2.2.6.RELEASE/reference/html/spring-boot-features.html#boot-features-testing

測試類型

如傳統軟件，智能合約的測試一樣可分爲功能測試、非功能測試、安全性測試和迴歸測試，下面將對這些測試做逐一介紹。

功能測試

功能測試包括但不限於單元測試、集成測試、冒煙測試、用戶驗收測試。除用戶驗收測試外，其餘測試均可經過開發或測試人員編寫代碼實現。

智能合約測試重要目的之一是檢測合約代碼正確性，在預約輸入值前提下，檢查輸出值是否符合預期。

上文咱們介紹了控制檯、WeBASE-Front和SDK三種測試環境。

在一些邏輯複雜的智能合約中，測試難點之一在於構造測試案例。在這種場景下，使用智能合約能夠更好地模擬和構造測試數據，直接使用Solidity編寫智能合約更爲原生、友好。

最後，測試並不遊離於智能合約開發以外，而是其中重要的一環，測試也需遵循依賴關係原則，即開發者在進行開發時須要考慮智能合約的『可測試性』。

例如，假設測試代碼徹底使用SDK編寫，那智能合約的修改就可能致使測試代碼須要作出對應變動，這會對測試效果形成影響，提高測試成本。基於軟件設計『不可依賴多變部分』的原則，可測試性一樣不能依賴於多變部分。

爲了解決上述問題，咱們在智能合約層引入測試代碼。這些代碼僅被設計爲測試組件，不會發布到線上環境，以此將測試案例改動影響解耦並封裝到智能合約層。測試合約做爲獨立組件，支持開發和測試環節。

測試組件中首先能夠抽象和定義一些測試的工具合約，例如：

pragma solidity 0.4.25;

library LibAssert {
    event LogTest(bool indexed result, string message);

     function equal(uint8 a, uint8 b, string message) internal returns (bool result) {
        result = (a == b);
        log(result, message);
    }

    function notEqual(uint8 a, uint8 b, string message) internal returns (bool result) {
        result = (a != b);
        log(result, message);
    }

    function log(bool result, string message) internal {
        if(result)
            emit LogTest(true, "");
        else
            emit LogTest(false, message);
    }
}

這是一個最簡單的測試合約庫，提供了equal和notEqual的方法來判斷uint8變量，開發者可基於此工具擴展本身的測試工具合約。

其次，依託於工具合約，咱們能夠編寫獨立的測試合約案例。

下面將以上述Uint8MathTest爲例，演示如何使用此工具合約，首先，咱們定義一個TestDemo合約：

pragma solidity ^0.4.25;
import "./Uint8MathTest.sol";
import "./LibAssert.sol";
contract TestDemo {
  using LibAssert for uint8;
  function testAdd() external returns (bool result) {
    uint8 a = 1;
    uint8 b = 1;
    Uint8MathTest math = new Uint8MathTest();
    uint8 c = math.add(a,b);
    uint8 expectedValue = 2;
    result = expectedValue.equal(c, "Not equal");
  }
}

而後，在控制檯中運行這個測試案例：

[group:1]> deploy TestDemo
contract address: 0xd931b41c70d2ff7b54eb9b2453072f9b1a4dc05c

[group:1]> call TestDemo 0xd931b41c70d2ff7b54eb9b2453072f9b1a4dc05c testAdd
transaction hash: 0xe569e5d8eae1b949a0ffe27a60f0b4c8bd839f108648f9b18879833c11e94ee4
---------------------------------------------------------------------------------------------
Output
function: testAdd()
return type: (bool)
return value: (true)
---------------------------------------------------------------------------------------------
Event logs
---------------------------------------------------------------------------------------------

除了依賴自定義的智能合約測試代碼，也能夠用智能合約自己來編寫測試案例。在SDK層，咱們只需實現TestDemo中的測試函數代碼。即便將來測試邏輯改動，也無需改動SDK代碼，從而保證了測試代碼的健壯性。

合約測試代碼組件需貫徹智能合約在總體設計中所遵循的設計原則。

非功能測試

非功能測試主要包括性能測試、容量測試、可用性測試等。因爲智能合約運行於FISCO BCOS的底層節點，容量測試和可用性測試更多與底層節點相關，所以，對用戶而言，非功能測試的重點就在性能測試上。

雖然，咱們可使用系列通用性能測試工具對智能合約進行測試，可是，實際壓測過程當中會存在一些痛點，例如：

針對具體合約場景測試，存在大量且重複的測試代碼，費時費力；
性能指標缺少統一度量，沒法橫向對比；
展現結果不夠直觀。

爲了解決以上痛點，FISCO BCOS適配了區塊鏈測試專業工具Caliper，讓用戶能夠優雅地進行性能測試。更多細節和內容請參考：《性能測試工具Caliper在FISCO BCOS平臺中的實踐》。

安全性測試

智能合約上線前須要進行嚴格的安全性測試。

安全性測試的方式包括：公開智能合約併發布懸賞、聘請專門的智能合約安全機構對合約進行檢測和評估、使用智能合約專用的工具進行審計等。

你們能夠視自身合約的重要性及邏輯複雜程度選擇對應的安全性測試級別。對於我的開發者或非重大業務的智能合約，選擇免費的智能合約工具檢測便可。

下面以VS Code爲例，演示如何使用智能合約安全插件對合約進行安全性檢測。打開VS Code，在其插件庫中搜索Beosin-VaaS: ETH，選擇安裝。

隨後，打開智能合約文件，右鍵選擇Beosin-VaaS:ETH選項，在彈出的窗口中選擇當前合約代碼版本。安裝完成後，會自動彈出以下界面：

點擊start便可對所選合約進行安全檢測。如下是對HelloWorld合約的檢測結果：

start compile!
compile over!
start deploy!
deploy over!
start execute function name: set(string)
execute function name : set(string) end!
No problem was found in the contract
---end---

當咱們對Uint8MathTest合約進行檢測時，會發現報錯：

####### Compile Problem #######
file: /Users/maojiayu/Downloads/Uint8MathTest.sol
title: Compile Problem
description:  Function state mutability can be restricted to pure
code:   function add(uint8 a, uint8 b) public returns (uint8 c) {
warningType: Info
line: 5

經過報錯信息，咱們能夠發現該函數既沒讀取也沒使用區塊鏈上的狀態，符合pure修飾符的使用條件，建議使用『pure』關鍵字來修飾。

安全性測試是合約測試過程當中不可或缺的一環，需高度重視。在嚴格的工程實踐中，合約上生產前必須由相關的測試負責人出具安全性檢測報告。

此外，開發人員能夠收集和總結Solidity安全編程規則和漏洞風險提示，並動態更新維護。在交付測試前，開發人員可組織代碼審查和走查，依據總結，集中、逐項進行風險排查。

安全性測試是檢測和評價智能合約是否安全的必備環節，但不能將合約安全性徹底寄望於測試。更重要的是，在設計、開發和測試的各個階段，都須要用戶時刻保持安全意識，創建和培養安全編碼習慣。合約發佈上線後，也不能放鬆警戒，時刻關注業界最新的安全警告，並按期、動態對全部代碼進行檢測和掃描。

迴歸測試

迴歸測試一般包括執行持續集成的自動化測試案例以及合約上線前的人工測試。

上述SDK以及智能合約測試案例可有效覆蓋測試案例所執行的路徑和範圍。自動化的迴歸測試有助於快速檢測並發現問題，節省大量重複人力，保證合約經歷系列修改和測試後，不偏離主幹功能。一樣，開發者可以使用Jenkins、Travis等工具進行構建和測試。

除了執行個別自動化測試沒法執行的案例外，人工測試更多地是確認以前修改的代碼是否符合預期，智能合約的運行是否符合當初設計。此外，在合約最終發佈前，人工測試還起到審覈檢查做用，故而必定要認真對待。

測試要點

不管何種類型的系統測試，均需特別注意如下測試要點。

注意邊界值的測試，例如數字溢出、特殊取值、循環邊界值等。
注意檢查智能合約的實現是否符合預期，其運行邏輯和流程是否與設計一致。
除了正常流程外，還須要模擬和測試在各類異常環境，甚至是極端環境下，智能合約運做是否正常，可否達到預期的處理結果。
圍繞智能合約不變的業務邏輯，忽略變化值，進行對應測試。

邊界值

邊界值測試是一種常見的軟件測試方法。據統計，絕大多數的bug發生在輸入或輸出範圍的邊界上，而非其內部。

咱們來演示一個典型的數值溢出測試案例。以下簡單的合約，實現了兩個uint8數值加法，並返回告終果：

pragma solidity 0.4.25;

contract Uint8MathTest {
    function add(uint8 a, uint8 b) public returns (uint8 c) {
        c = a + b;
    }  
}

這時，咱們須要設計一個邊界值的測試案例。已知uint8的取值範圍在[0,28)即[0,256)之間，以此設計一個溢出的測試案例：（a=255, b=1），測試結果以下：

[group:1]> deploy Uint8MathTest
contract address: 0xd8a765995c58eb8da103bdcc2c033c0acb81e373

[group:1]> call Uint8MathTest 0xd8a765995c58eb8da103bdcc2c033c0acb81e373 add 255 1
transaction hash: 0x0583185839bc52870ac57cdfd00c0c18840c2674d718b4cc3cb7bc1ef4c173e0
---------------------------------------------------------------------------------------------
Output
function: add(uint8,uint8)
return type: (uint8)
return value: (0)
---------------------------------------------------------------------------------------------

能夠看到最後結果變爲0，而不是預期的256，顯然，這是由於結果發生了溢出。

固然，在使用邊界值測試方法取值時，並不是只取有效邊界值，還應包含無效邊界值。邊界值測試可幫助查出更多錯誤和缺陷。

是否符合預期

在建築公司交付房屋後，開發商會依據設計標準檢驗房屋建造是否合格。一樣，除了檢查合約執行結果是否正確外，在測試中還需檢查合約交互、操做、數據流向、性能表現等各方面實現是否符合設計。

舉個例子，在金融業場景中，咱們會使用Solidity開發具體鏈上業務邏輯。

其中，不可避免與金額打交道，就須要測試對應資產規模是否符合設計標準。在需求和設計階段，咱們會預估運行在鏈上的資產規模並做設計要求，例如要求某個供應鏈金融區塊鏈業務系統能在千億資產規模下正常運行。

假設在智能合約中，定義金額的字段是uint32，能夠計算其最大能表示的值爲232即不到43億。

雖然在智能合約發佈上線後大多數時間內，該問題不會形成任何影響；可是，一旦業務快速增加，當資產規模超過43億後，就會出現嚴重故障。

這類問題很是隱蔽，所以，須要更加全面、仔細的測試來提前發現和定位。

異常流程

在實際業務場景中，即使通過系列測試保證智能合約運行符合絕大多數場景需求，也可能由於疏忽或遺漏，致使在特定異常流程下，出現問題，在智能合約發佈後形成了重大影響。

故而，開發者須要特別重視在測試範圍和內容中對異常流程的搜尋和覆蓋，儘量測試覆蓋到全部的異常流程。

變與不變

使用Solidity測試與其餘語言的顯著不一樣還在於合約中的不少交易和值沒法復現。正如『人的一輩子沒法兩次踏入同一條河流』，隨着私鑰、證書、環境等改變，其交易Hash值、區塊Hash、合約地址等也會隨之不一樣，這也給測試帶來一些客觀困難。

另外一方面，Solidity對於一致性有着嚴苛要求，例如對EVM執行指令語義的一致性、對外部隨機變量的『排斥』等。掌握合約測試的關鍵在於抓住其中不變的方面。

測試技巧

做爲區塊鏈上專用編程語言，相比其餘高級語言，Solidity有很是多限制。例如，缺少成熟的測試工具支持，沒法在運行時進行debug以及查看EVM虛擬機內的狀態與數據。

同時，Solidity缺少獨立的數據抽象層，致使沒法像傳統應用那樣直接經過鏈接數據庫來查看合約內詳細的變量狀態，只能經過在合約內增長查詢調用來『曲線救國』。

固然，咱們也能夠採起一些技巧，儘量規避以上問題。

如何展現合約更多內部變量？

編寫Solidity代碼與其餘高級語言最大差異是沒法進行debug。這個問題解決辦法之一是打印和展現更多內部變量。

問題場景：

仍是上述的HelloWorld合約，如今咱們沒法在set函數執行時獲取原有的name值，只能經過name()函數來查詢。有沒有辦法在set函數執行時，記錄和打印出name原來的值呢？

解決方案：

定義一個event，在set函數內部進行調用。例如：

pragma solidity ^0.4.25;

contract HelloWorld{
    string public name;
    event LogSet(string oldValue, string newValue, address sender);
    constructor() public{
       name = "Hello, World!";
    }
  
    function set(string n) public{
      emit LogSet(n, name, msg.sender);
      name = n;
    }
}

而後，在控制檯中執行，能夠看到剛纔定義的LogSet事件被打印出來了。咱們在事件中還定義打印了msg.sender的地址，以下圖所示，對應地址也被打印出來。

Event至關於提供了log日誌的簡單機制，當出現沒法解決且須要展現合約內部狀態的狀況，Event提供了合適的方法和機制。

如何得到鏈上全量數據模型？

問題場景：

都說Solidity是圖靈完備的語言，EVM是設計簡潔的狀態機，若是想要獲取狀態機內部每一個狀態和交易的『世界狀態』蛛絲馬跡，有什麼好的解決方案？

解決方案：

Solidity缺少獨立的可對外訪問的數據層，沒法直接獲取每筆交易或每一個狀態的詳情。不過，咱們能夠經過WeBASE數據導出組件來導出全部鏈上數據。

WeBASE-Collect-Bee能夠導出區塊鏈上的基礎數據，如當前塊高、交易總量等。

若是正確配置了FISCO BCOS上運行的全部合約，WeBASE-Collect-Bee能夠導出區塊鏈上合約的業務數據，包括event、構造函數、合約地址、執行函數的信息等。

數據導出組件WeBASE-Collect-Bee的目的在於下降獲取區塊鏈數據的開發門檻，提高研發效率。研發人員幾乎無需編寫任何代碼，只進行簡單配置，就能夠把數據導出到Mysql數據庫。

仍是以上面的HelloWorld爲例，參考安裝文檔：WeBASE-Collect-Bee快速部署。

安裝過程略過不表，導出之後會自動在數據庫中生成以下的表：

數據庫表的功能以下：

account_info: 記錄了全部在鏈上部署的合約信息，包括了合約名、合約地址、塊高、上鍊時間等。
blcok_detail_info: 記錄了每一個區塊的信息，包括區塊hash、交易數量、塊高、上鍊時間等。
block_task_pool：數據導出的任務表，記錄了任務詳情和狀態信息。
block_tx_detail_info：記錄了每筆交易的信息，包括了交易的合約名稱、函數名稱、交易發送者地址、交易接收者地址、交易hash等。
hello_world_log_set_event：數據導出會自動生成每一個event的數據庫表，命名規則爲合約名+事件名。上面例子中定義的event所自動生成的表，包括了event中定義的全部變量和交易信息等。
hello_world_set_method：數據導出會自動生成不一樣transaction的數據庫表，命名規則爲合約名+函數名。上面例子中定義的set函數表，包含了函數的入參、返回碼和交易hash等。