當工程師發覺自己的腦袋無法確保自己寫的程式正確運作時,決定透過寫測試來解決這問題。作為一個使用 Go 語言的新手,在摸完 go test 方便簡潔的功能後,一時手癢就決定自己動手寫一個更適用於 Functional Verification Test 的工具。
本次議程講者會從 go test 使用思維開始,整理開發中遇到的 Unit Test、Functional Verification Test 性質及需求,並分享設計和實作測試框架的經驗。
本次議程大綱如下:
- go test 設計思維
- 撰寫測試案例
- 收集測試資料
- 開發中遇到的 Unit Test、Functional Verification Test 性質及需求
- Unit Test
- 偏向個別 Function 或 Package 的功能正確性
- 通常要在開發時就測試過
- 最遲也要在 CI 時檢測出問題
- Functional Verification Test
- 從使用者怎麼使用的角度來思考,而不是開發者怎麼開發
- 一個功能的呈現可能需要多個 Packages,甚至多個 Microservices
- 預計在 CI 或是 CD Pipeline 的尾端執行
- 需求
- 不能因為單一 Case 失敗就停止測試
- 能持續收集各個 check point 重要資訊並在最後整理回報
- 希望能用到 Go 併發的特性,加速測試工作
- 盡可能降低進行測試的成本,避免架設環境的麻煩
- 進一步讓非 SQA,甚至絕大多數團隊成員有辦法自行進行測試
- Unit Test
- 設計及實作方式
- 從測試案例函數參數傳入 Instance 持續收集資料,並在最後整理回報
- 各個 Test Case 不應該有相依性,拆分後併發執行提升效率
- 設計為 REST API Server 可以透過 endpoints 方便的觸發執行
- 防止從外部觸發惡意測試,再加一層 jwt 驗證機制
About Rain Wu
Hi All, 我是 Rain,目前是成功大學 CCNS 社團的成員。技能樹上長著軟體工程、3D 美術、商業分析的神奇組合,主要使用 Python 和 Go 兩種語言進行後端及 DevOps 相關工具開發,熱愛閱讀開源工具原始碼挖掘神奇的寫法和暗藏的地雷。閒暇時常用 Blender 畫畫 (有時候手癢會寫一些小插件)、看一些商業策略相關的書和文章、並積極參與多個技術社群協助商務及贊助的適宜。
如果想更了解我或是和我聯繫,可以參考我的 LinkedIn:https://www.linkedin.com/in/rain0114/