story)敘述的需求文件。如行為驅動開發(BDD, Behavior-Driven Develop- ment) [7]，接受 測試驅動開發 ATDD(Acceptance-Test Driven Development) [8]、可執行的規格案例(SBE, Speci cation By Example) [9] 等均是被提出來解決類似問題的方法。在實現步驟上雖有 些許差異，但主要目的均是以「情境(scenario)」為核心來測試。
智能合約的開發與測試仍欠缺系統化的整合開發測試工具或平台。具體來說，目前 並沒有適合智能合約的 BDD 工具被提出，也沒有使用 BDD 方法開發區塊鏈與智能合 約結合應用場域的應用案例與經驗報告出現。因此，針對此一挑戰，本研究首先將探究 基於 BDD(Behavior-Driven Development) / ATDD (Acceptance-Test Driven Development)，
以「情境(scenario)」為核心來測試就業務邏輯的角度來驗證合約正確運作時應有的可行 性。藉由實現一個可支援 Solidity 智能合約語言的自動整合測試平台進行研究，以紅利 點數交換的智能合約開發為案例，就所開發的系統進行可用性驗證。此平台以 Web 方 式提供自動整合測試服務，將整合數個現有工具，包含 Cucumber.js、Web3.js 與 Mocha，
提供並解決目前開發與測試 Ethereum 上以 Solidity 寫作的智能合約的橫切面考量，也就 是將每次使用這些工具開發、測試智能合約時都必須進行的重覆工作，整合封裝為 Web API，並提供簡易 Web 使用介面，能有效降低智能合約開發測試複雜度與負擔，提升合 約品質。
1.4 相關研究
BDD 如何有效應用在各式開發場域，近年來是軟體工程研究的熱門議題。Li 等人[14]認 為使用 cucumber 作為 BDD tool，因需要手動敘述測試場景，通常會造成測試場景的覆 蓋度不夠，故他們建議並設計了一種 Model- Based Testing tool 可以自動生成有效的 cucumber 測試場景，藉由讀取 UML 圖(例如： state machine diagram)，識別 elements 後
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Rahman 與 Gao[15]提出了當 BDD 應用於微服務(micro-service)時，針對重用性、可 追縱性與可維護性形成了主要問題，他們提出了一個自動驗收測試架構來解決此問題。
Sivanandan 與 Yogeesha 則探討了在敏捷開 發過程中如何有效的使用 Model Based Testing 進行 BDD[16]，並對 BDD 的使用方式進行了深度的探討。
雖然藉由讀取 UML 圖形式別 elements 生成測試場景，雖然可以改善手動敘述而會 遺漏的困難，但一般而言非資訊相關背景者，例如：業務人員、銀行背景人員……等。
在撰寫 UML 圖時便會遭遇困難，因為不是每個使用者都懂得如何撰寫，故在本篇論文 使用撰寫需求的規格是使用 Gherkin 作為撰寫。
而使用 Model Based Testing 進行 BDD 可以解決系統難以維護的問題，以及可以更 容易驗證所撰寫的系統是否符合業務需求，但使用這樣的架構在智能合約開發上面，雖 然可以獲得此架構所帶來的好處，但這樣的架構使開發流程變得更為複雜，以及若直接 只用此架構，在撰寫整合測試以及單元測試時仍需要了解區塊鏈背景才能順利使用此開 發方法流程，故在本篇論文針對了此議題提供了相對應的解決方式。
‧
使用行為驅動開發（Behavior-driven development, BDD）技術來解決智能合約缺乏成熟 的開發工具與方法、缺乏系統性的驗證與測試機制來確保所開發合約的正確性以及目前‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
小美撰寫了一個交易訊息，內容為將 100 元傳送給小王，並使用小美的私鑰解鎖自 己的帳戶，取出 100 元放至訊息內並使用小王的公鑰加密（公鑰在區塊鏈中實際意義為 使用者的帳戶號碼），區塊鏈會透過公鑰傳送給小王此封訊息。當小王收到訊息後，因 區塊鏈公鑰為公開，則小王取得訊息後，區塊鏈會告知小王此封訊息由誰傳送，小王得 知傳送者為小美後可小美的公鑰解開小美的公私鑰鎖，而小美先前使用小王公鑰加密的 公私鑰小王則可使用自身的私鑰解鎖並取得訊息內所包含的金額。如此在傳送訊息時可 透過加密技術，區塊鏈中資金的動用必須透過本人帳戶的公私鑰解鎖才能夠動用，達到 第一項訊息傳遞的信任問題，沒有人可以隨意的動用自己帳戶內的資金流動。
圖 1: 區塊鏈交易過程
而比特幣的區塊鏈平台上存在一種名為智能合約的物件，實際上為程式碼，用來輔 佐區塊鏈交易訊行的自動化，例如上述小王及小美賭局的例子，小王與小美可撰寫一個 智能合約，個別將 100 元押金放入至其撰寫好的智能合約中，三日後依據氣象快報，三 日後不管下雨於否，智能合約的程式碼將透過外部資訊被觸發，並且自動將押金匯入正 確的帳戶中。但因比特幣原系統的限制，每一筆交易的大小最大僅僅只有 1MB，比特幣 平台中的智能合約無法做複雜的判斷，僅僅能夠做簡單的交易。數年後，於 2013 年 Vitalik Buterin 提出了《以太坊白皮書》在文內說明了以太坊讓開發者創建更具擴充性、易於開
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
發及應用的目標，並且在 2014 年透過 ICO 眾籌於並於 2015 年的 7 月正式上線，成為目 前區塊鏈應用程式最常使用的區塊鏈平台。
在以太坊區塊鏈平台上的智能合約抽象架構如下圖所示，區塊鏈中的每一個參與者
（Participabts）皆為一個節點，而每個節點們分別相互連結，形成一個部分連結網路拓 樸（Partially Connected Mesh Topology）。每個節點將會將所有記錄的交易記錄在各自 的帳本中，帳本實際上由一個接著一個的區塊（Block）鏈結而成，而區塊中又包含數個 交易，每過一段時間，發出的交易會被打包成一個區塊，當有新的區塊被打包完成後，
則會被廣播至所有相連的節點，並透過共識演算法進行驗證，驗證該區塊中的所有交易 是否合法，以及是否安全，當通過後則會將該區塊串連至已被成功驗證為合法的區塊中，
故每個節點將會各自擁有一份相同的帳本。
如圖 2 所示，在以太坊中，區塊中的交易（Transaction）可分為兩種，一種為一般 金錢轉移的交易，而另一種則為智能合約，而以太坊區塊鏈平台提供每一筆交易內可擺 放一些資料，智能合約撰寫完成並被成功編譯後會將其位元碼（Byte code）放入至交易 中的資料欄位，當區塊成功的串連至前一個區塊後將會回傳該智能合約在區塊鏈網路中 的帳號位址，故在以太坊中智能合約又被稱為內部帳戶（Internal Account），因智能合 約存在於區塊鏈內部且不須透過公私鑰解鎖，但智能合約卻也有帳戶位置，可以存放資 金至帳戶中，其存取資金的方式則仰賴於開發人員在撰寫程式碼時的設計。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 2: 區塊鏈網路架構
區塊鏈內智能合約的存在，相當於把上述小美與小王的賭局透過智能合約，數位化 成程式碼，並將其放入至區塊鏈平台中，當時間一到，由外部系統觸發智能合約判定結 果的程式碼，便可以自動將資金移動至正確的帳戶中，解決了信任中的第二個問題，將 合約數位化，當需要合約判定時該程式可以自動執行正確的資金流動，一旦合約數位化 可以透過程式碼自動執行時，則可以大大減低需要外部人力介入的問題。
其區塊鏈系統之所以稱為區塊鏈實際上是因為區塊鏈系統其實是由一個個區塊串 接而成，如下圖所示，每一個區塊內將會記載前一個區塊的號碼且其內部的交易將會形 成一個樹狀結構，如此區塊鏈因各個節點個別記載相同的區塊鏈結的資料，又因為其鏈 結關係，故其擁有公開透明且可追朔的特性。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 3: 區塊架構
這樣的特性又解決了上述小美與小王的替三個問題，原本第三方可能會有捲款潛逃 亦或者向雷曼兄弟公司那樣破產的可能，透過區塊鏈上智能合約以及可追朔、公開、透 明且分散式的特性，儘管區塊鏈上有任何一個節點中途離開，都不至於影響整體區塊鏈 的運作，因各個節點皆記載相同的帳本資料，交易可以不用仰賴第三方且又可以安全地 進行交易。
智能合約大大的提升了複雜交易的效率，但欲開發智能合約，必須深度了解區塊鏈 知識包含如何參與一個區塊鏈系統以及其運作原理為何，且當了解了區塊鏈的科學知識 後，又必須擁有基本的金融知識，當開發一應用系統時，必須正確地將實體合約數位化，
將該合約成功部署至區塊鏈平台後，必須學習要如何觸發合約的運行，須經過嚴謹的測 試，確認其智能合約正確且完整的將實體合約數位化後，才能確定該區塊鏈應用程式的 合約能依預期正常運行，故本論文提出了使用行為驅動開發(Behavior-driven development)
‧
2.1.2 測試驅動開發（Test-Driven Development, TDD）
在早期，開發圖靈機（Turing machine）程式，大部分的開發流程為：放入輸入磁帶 (Tape)，並且準備一個預期的結果磁帶（標準答案），然後不斷的修改程式碼，直到其 結果與預期完全相符則完成。而此方法正為 TDD 的前身測試先行（Test-first
development,TFD），Kent Beck 在撰寫第一個 xUnit framework 時開始研究此方法，並 且於 2003 年發表了 TDD 的概念[20]，被視為發展這項技術的元老或”rediscovered”的 人。
一般而言，會透過 Red-Green-Refactor cycle 來表示 TDD 流程，Red 表示一開始需 先撰寫的程式碼必定會失敗，因為目標程式碼尚未撰寫，Green 表示撰寫足夠的目標程 式碼使其通過，最後 Refactor 則是重構。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 4: Red-Green-Refavtor cycle
使用 TDD 作為開發方法的優點除了可以透過設計測試程式，清晰的了解功能需求，
並且以通過測試為目標，使開發者更專注於達成功能的撰寫，最後可以透過不斷的重構 獲得更佳品質的程式碼。
TDD 這種開發方法雖然可以透過設計測試更清晰地了解功能需求，但是在區塊鏈 應用程式中，參與合作的人員一般會包含金融背景的專業人員，而這些人恰好大部分是
TDD 這種開發方法雖然可以透過設計測試更清晰地了解功能需求，但是在區塊鏈 應用程式中，參與合作的人員一般會包含金融背景的專業人員，而這些人恰好大部分是