你今天單元測試Unit Test了嗎?

在軟體開發過程中, 單元測試有點像買保險的概念
在上次被問到單元測試的一些問題後
紀錄一下

自動測試 VS 手動測試

項目自動測試手動測試
開發時程
測試時程極快 (秒/分)系統越大越慢 (分/時)
測試完整度依照覆蓋率判斷落觀音
系統更新掌握度有把握自我意識良好, 沒把握時自己嚇自己
持久性無限人類會心累
CI/CD可自動化人工測試/人工佈署
改A壞B及時反應不明不白

人工測試碰到的狀況

ex: 測試會員購物流程

  1. 註冊會員帳號
  2. 填一堆會員資料
  3. 會員登入
  4. 綁定資料
  5. 選擇商品
  6. 加入購物車
  7. 結帳
  8. 付款
  9. 後台確認訂單
  10. etc…

人工測試的狀況常常會遇到

  1. 會員帳號重複申請
  2. 驗證碼又打錯
  3. 密碼要中英文混用
  4. etc…

有寫單元測試就一定沒問題?

有單元測試沒有整合測試
會遇到每項功能測試都正常
但…流程上似乎有問題

什麼是單元/整合測試?

單元測試

  • 確保方法或物件可獨立運作, 進行檢查和驗證
  • 可重複測試
  • 可反應驗證結果
  • 可及時發現設計和需求存在的缺陷
  • 可在系統Runtime狀態發現Bug

 整合測試

  • 確保模組與模組之間互動行為正確無誤
  • 確保單一物件測試通過, 是否影響整體流程

單元測試的好處有哪些?

單元測試的優點 (減少觀落陰時間)

  • 迅速找到程式出錯點
  • 提升回饋速度與開發效率
  • 降低系統Bug含量
  • 提高系統品質

減少測試人力成本

  • 短時間快速全面測試系統
  • 大型系統測試甚至要跑20分鐘
  • 降低測試人員負擔(心累想離職)
  • 減少重複性工作
  • 減少On call人力成本

多一層保障

  • 重構系統維持可維護性
  • 系統更新多了一層保障
  • 後續維護不怕改壞系統
  • 公司老闆說話更有立場

單元測試適用於…

  • 系統結構比較清晰穩定
  • 系統耦合性低
  • 系統底層穩定
  • 開發團隊需具備 S.O.L.I.D. 設計原則 知識
  • 公司時程沒壓力為前提下

不是每一套系統都適合進行單元測試

開發時程非常緊湊的專案

  • 程式碼撰寫量變大 (原系統程式碼 + 測試程式碼)
  • 時程會拉長

需求不確定

  • 初期建置需交付Demo
  • 若硬要寫可能會因時程拉長, 降低公司業務競爭力

價值性不高

  • 產值較低的系統
  • 公司認為價值較低的系統

人力成本低的公司

  • 要寫出低耦合性的系統, 代表系統架構可能難度較高
  • 公司需聘請較多資深工程師, 或聘請外部講師或顧問協助

所以導入自動化測試系統就保證不會有問題?

NO!

畢竟測試也是人寫出來的, 也是會有鬼遮眼的地方
自動化測試比較像是一種買保險概念
若遇到單元測試沒測到的
就只能持續補強各種測試案例
讓系統每次改版與更新都能安安穩穩!

訂閱
通知
guest
0 留言
預約回饋
查看所有留言