# 自動測試框架評估表

{%hackmd 1lpg7PuqRoaui6XyJcrylw %}

>各位想讓團隊協作更順利的工程師們:
>Moxa產品軟體的含量與複雜度越來越高，從專案需求釐清、開發到測試，各種資訊、經驗、知識、技能分散在各個團隊成員身上，早已沒辦法像史塔克工業由東尼史塔克一人單幹，專案中各個角色的緊密協作對於軟體專案的時程與品質有著決定性的影響，所以我們必須持續優化溝通協作模式與工具。
>因為世上永遠都有不滿於現狀的工程師，所以這世界是不會停止進步的，為了讓我們日常協作更有效率、更有成就感，邀請各產品線團隊一起規劃未來團隊協作模式的樣貌。
>基於對18個月後協作模式的想像，你所屬的產品團隊在測試程式開發語言、測試規格描述與自動測試Framework有哪些考量呢？請與團隊成員一起討論吧！

## 決策方法

- 決策排序
- MUST
- Better to have(照重要性排序)
- 最後的選擇
- Cucumber
- Robot Framework
- Hadis
- pyTest
- iTest

## 開發語言

- Python*
- Tcl
- Java
- C++

## 選擇使用什麼自動測試框架開發？

- 支援所選的開發語言
- 需求管理可以跟JIRA整合
- Bug管理工具可以跟Mantis整合
- Bug管理工具可以跟JIRA整合
- 測試管理工具可以跟Xray整合
- 測試管理工具可以跟TestLink整合
- CI/CD可以跟Jenkins整合
- CI/CD可以跟GitLab整合
- 設計原則是把測項描述和測試程式分別版控
- 必須是由商業公司維護
- 必須是由社群維護
- 必須是自己開發的框架
- 可以選擇要紀錄在Report要的欄位/資訊
- 測試過程中會記錄步驟執行時間
- 測試log有分level
- Report的檔案格式支援json
- Report的檔案格式支援html
- Report的檔案格式支援xml
- 齊全的User Manual
- 資料交換的架構符合既有的測試框架使用習慣
- 資料交換的架構符合未來的測試框架使用情境
- 語法規範符合既有的測試框架使用習慣
- 語法規範符合未來的測試框架使用情境
- 測項撰寫規範符合既有的測項撰寫習慣
- 測項撰寫規範符合未來的測項撰寫情境
- 開發環境可以容器化（container）
- 開發環境與既有的開發環境類似

## Note
- 小心選項會限制想法的陷阱
- 什麼是「協作模式」?
- 現在的協作的模式可能是
- 選擇後修改的
- 依照