5.2 質性使用者測試
5.2.3 改善與修正方向
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 37 受測者平均操作時間
比較各組受測者之操作本研究平台之平均操作時間，有智能合約撰寫經驗 B 組在操 作時間優於無智能合約操作經驗 A 組，發現 A 組平均的受測時間比平均值（10 分 20 秒）所花費還要多 14%，B 組平均則是小於平均值 14%。在此比較中可發現此平台對於 有智能合約開發經驗者仍是比較易於使用。
5.2.3 改善與修正方向
上述驗證本研究的可行性與易用程度，另外，在受測結束後根據受測者的問卷調查 整理成易用性評分表，使用者可以給予 1-5 分，其中 1 為最不同意，5 為最同意，本實 驗調查正向與非正向易用性正向調查問題並整理如下表。
表 3 易用性正向調查
問題敘述 總分
1. 因為操作順暢，若需要開發智能合約時，我願意使用此選軟體 26
2. 我認為此介面系統易於使用 22
3. 我發現此系統良好地整合了各個功能 25
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
求時進入 BDD 流程並且撰寫測試程式，經過不斷地討論且撰寫測試的流程，開發者可 以更為熟悉 BDD 開發方法，所以方法的名稱一般來說將為開發者自行定義或者熟悉，
並不會有此問題產生。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第六章 結論
本論文針對區塊鏈服務（BssS,Blockchain as a Service）產出使用基於行為測試驅動開發 的智能合約測試技術，針對目前智能合約欠缺成熟的開發工具之議題開發一智能合約整 合測試平台。此平提供 BDD 風格的智能合約自動整合測試，可在整個智能合約開發週 期提供開發支援，協助將業務邏輯轉為可執行的規格書，到自動化部屬智能合約且驗證 業務邏輯正確性與功能正確性，並且導入中介技術協助區塊鏈應用更快速的發展。此論 文提出可支援 Solidity 智能合約語言的自動整合測試平台，並且以紅利點數交換為案例 說明本平台，就所開發的系統進行可行性驗證，以 Web 方式提供自動整合測試服務，整 合目前智能合約開發與測試所需工具，提供並降低目前開發與測試 Ethereum 上以 Solidity 寫作智能合約與測試時，必須面臨的高複雜度工作所產生的負擔。
根據易用性實驗結果，本研究未來可以透過中介層改善，將介面封裝的更完善，替 換整合測試程式所使用的 Web3.js，改以更簡易的使用介面，將 address、abi、byteCode 等一般無智能合約開發經驗者不易理解的參數封裝，簡化撰寫測試程式的難易度。另外，
將針對 Web 介面的使用性進行優化，例如將介面文字與 BDD 開發方法的名稱一致，隱 藏 Mocha 等標籤頁面名稱改為一般開發者可以理解的單元測試等。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
參考文獻
[1] N. Szabo, "Formalizing and securing relationships on public networks," First Monday, vol. 2, no. 9, 1997.
[2] Nakamoto, Satoshi Bitcoin: A peer-to-peer electronic cash system. 2009.
[3] K. Christidis and M. Devetsikiotis, "Blockchains and smart contracts for the internet of things," IEEE Access, vol. 4, pp. 2292–2303, 2016.
[4] M. Swan, Blockchain: Blueprint for a new econ- omy. “O’Reilly Media, Inc.”, 2015.
[5] D. Mamnani, “Testing of smart contracts in the blockchain world,” Blog post, 2017.
[Online]. Available: https://www. capgemini.com/blog/capping-it-off/2017/01/ testing-of-smart-contracts-in-the-blockchain-world
[6] L. Crispin and J. Gregory, Agile testing: A prac- tical guide for testers and agile teams.
Pearson Education, 2009.
[7] J. F. Smart, BDD in Action. Manning, 2014.
[8] M. Gärtner, ATDD by example: a practical guide to acceptance test-driven development.
Wesley, 2012.
[9] M. Hüttermann, “Speci cation by example,” De- vOps for Developers, pp. 157–170,
‧
[10] W. Trumler and F. Paulisch, “How speci cation by example and test-driven development help to avoid technial debt,” in Managing Technical Debt (MTD), 2016 IEEE 8th
International Workshop on. IEEE, 2016, pp. 1–8
[11] C. Matts and G. Adzic, “Feature injec- tion: three steps to success,” 2011. [On- line].
Available: https://www.infoq.com/articles/ feature-injection-success
[12] M. Wynne and A. Hellesoy, The cucumber book: behaviour-driven development for testers and de- velopers. Pragmatic Bookshelf, 2012.
[13] R. Lawrence and P. Rayner, Behavior-Driven De- velopment with Cucumber. Pearson, 2016.
[14] N. Li, A. Escalona, and T. Kamal, “Sky re: Model-based testing with cucumber,” in Software Testing, Veri cation and Validation (ICST), 2016 IEEE International Conference on. IEEE, 2016, pp. 393–400.
[15] M. Rahman and J. Gao, “A reusable auto- mated acceptance testing architecture for mi- croservices in behavior-driven development,” in Service-Oriented System Engineering (SOSE), 2015 IEEE Symposium on. IEEE, 2015, pp. 321– 325.
[16] S. Sivanandan et al., “Agile development cy- cle: Approach to design an e ective model based testing with behaviour driven automation frame- work,” in Advanced Computing and Communica- tions (ADCOM), 2014 20th Annual International Conference on.
IEEE, 2014, pp. 22–25.
[17] J. S. Dumas and J. Redish, A practical guide to usability testing. Ablex Pub. Corp., 1993.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
[18] J. Nielsen,” Why You Only Need to Test with 5 Users”, User Testing, in Nielsen Norman Group, 2000
[19] S. Porru, A. Pinna, M. Marchesi, R. Tonelli, Blockchain-oriented software engineering:
challenges and new directions. In Proceedings of the 39th International Conference on Software Engineering Companion, 2017, pp. 169-171
[20] K. Benk, Test-driven development: by example. Addison-Wesley Professional, 2003
[21] J. Nielsen, "10 usability heuristics for user interface design," Fremont: Nielsen Norman Group. [Consult. 20 maio 2014]. Disponível na Internet, 1995.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
附錄 附錄一 相關發表著作
1. 廖峻鋒,鄭敬儒,陳恭,賴晨禾,邱天,”基於行為驅動開發製程的區塊鏈智能合約整合測 試服務平台,” 台灣軟體工程研討會 (TCSE), 台中, 台灣, 2017.
2. Chun-Feng Liao, Ching-Ju Cheng, Kung Chen, Chen-Ho Lai, Tien Chiu, and Chi Wu- Lee,
“Toward a Service Platform for Developing Smart Contracts on Blockchain in BDD and TDD styles,” in Proc. 10th IEEE International Conference on Service- Oriented Computing & Applications (IEEE SOCA), 2017.
‧
表示整合測試，此為 javascript 所撰寫，定義 feature 所敘述的每一個步驟 (Step)所表示的實際運行內容。 HTTP Method
GET
‧
PasswordError 密碼錯誤 註冊(sign up) HTTP Method
post
userIDExistError 帳號已被註冊過錯誤 formatError 帳號或密碼格式錯誤
3. 專案管理
查看現有 projects HTTP Method
‧
create_date string 創建日期，yyyy-mm-dd hh:mm:ss last_update string 上次儲存日期，yyyy-mm-dd hh:mm:ss 4XX 失敗 回傳值
名稱 描述
ApiKeyInvalidError API KEY 損毀或不合 法
取得 project 內容 HTTP Method
GET
:project_name stirng 專案名稱200 成功 回傳值(json)
字段 類型 說明
feature string step-definitions string mocha string
‧
ApiKeyInvalidError API KEY 損毀或不合 法
ProjectNameError 查無此 project
更新專案 HTTP Method
PUT
:project_name stirng 專案名稱 成功回傳值(json) 200 OK
字段 類型 value
feature string 如不要更新請略過 step-definitions string 如不要更新請略過 mocha string 如不要更新請略過 solidity string 如不要更新請略過 4XX 失敗 回傳值(json)
名稱 描述
ApiKeyInvalidError API KEY 損毀或不合 法
ProjectNameError 查無此 project
新增專案 HTTP Method
‧
:project_name stirng 專案名稱 contract_name stirng 陣列 智能合約陣列
ApiKeyInvalidError API KEY 損毀或不合 法
ProjectNameExistError Project name 已使用 過
刪除專案 HTTP Method
delete
:project_name string 專案名稱成功回傳值(json) 200 OK 字段 類型 說明
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
名稱 描述
ApiKeyInvalidError API KEY 損毀或不合 法
ProjectNameError 查無此 project
‧
HTTP MethodGET
:project_name string 專案名稱成功回傳值(json) 200 OK
字段 類型 說明
result string 執行結果
4XX 失敗 回傳值(json)
名稱 描述
ApiKeyInvalidError API KEY 損毀或不合 法
ProjectNameError 查無此 project
執行 mocha HTTP Method
GET
:project_name string 專案名稱‧
ApiKeyInvalidError API KEY 損毀或不合法 ProjectNameError 查無此 project
solidity compile HTTP Method
GET
:project_name string 專案名稱成功回傳值(json) 200 OK 字段 類型 說明 result string 執行結果 4XX 失敗 回傳值(json)
名稱 描述
ApiKeyInvalidError API KEY 損毀或不合 法
ProjectNameError 查無此 project