軟體測試領域中，有眾多測試方式，通常都是因為測試的目的不同，而才有了這些測試種類
以下先整理出常見的測試種類

Unit Test(單元測試)

參考出處:

是指工程師撰寫完成每一段 function 時，需要有個測試去檢驗該 function 是否正確。

它的著重點在於

1. 最小的測試單位 = 盡量撰寫最基本的測試(參考下方範例)
2. 沒有外部相異性 = 不能受到 DB、環境、Service 等因素影響到
3. 不具備邏輯 = 如同第一點延伸，所以不能撰寫過於複雜的業務/商業邏輯在裡面(參考下方範例)
4. 測試案例之間相異性為零 = 所以的單元測試在執行測時，不能彼此影響到
5. 一個測試案例指有一種方式 = 如果第一點延伸，只需用一種最簡單的方式進行單元測試(參考下方範例)

e.g. 以 js 為例
function add(a,b){
  return a + b
}

上方功能為一個簡單加法回傳

add(1,2) === 3 //這種就是最簡單的驗證方式，當然可以會透過更好的測試框架對所有單元測試進行統一管理

由於很多時候工程師是撰寫 code 時，會改到較底層的邏輯

最好的情況就是在每段 function 都寫 單元測試 以確保基礎的 function 可以正常

之後可以再透過其他測試種類(e.g. Integration Test/Systen Test/Regrssion Test/…) 進行較整合性的驗證。

Integration Test(整合測試)

最重要的名詞就是【整合】，也就是將多個不同的單元測試進行整合。

它就會須有有一定的程度的 業務/商業邏輯、DB、不同 Service 在其中，同時也是確保每個單元彼此之間是可以串起來的。

所以也有可能單元測試驗證結果通過，但整合測試驗證結果是失敗的情況

如同上方的慘案

1. 鎖頭單獨驗證沒問題
2. 推拉門單獨驗證沒問題

但當兩者放在一起，彼此邏輯若沒處理好，就出現問題了XDD

Smoke Test(冒煙測試)

針對主要系統核心功能進行驗證，而不會對具體功能進行更深入的測試。

它的目的也就是確認至少這個系統/產品能達到最低標準，作用就是保證系統主流程和新模組的基本功能正常。

註: 
每間公司的【最低標準】都會不一樣，但大多數至少是
- 不能讓 user 中斷操作流程(e.g. 閃退/無限loading/白畫面/503/404 等)
- 不能讓 user 的權益受損(e.g. 金錢/個資 等)

• 優點是節省測試時間，防止 build 失敗
• 缺點則是覆蓋率較低，畢竟只有針對主要流程。

通常會有一種情境是，在開發週期中，往往都會有【時程壓力】，會需要在某個時間點一定要將產品功能上線

但如果測試範圍很龐大時，又沒有自動化輔助時，若要執行 Regrssion Test 也執行不完

這時候可以與團隊之間討論進行 Smoke Test 也是一種折衷的方式。

Regression Test(回歸測試)

主要目標就是對產品進行大範圍且詳細的測試，除了主流程外，連同欄位的細詳規則、文案等 都會測試。

因為軟體的世界中，一定會一直不斷的進行更新，也因為【更新】，所以意味著需要進行測試。

因為每一次的更新都有可能造成其他功能異常的風險 (修 A 壞 B 應該是工程師最常遇到的事情了吧XDD)

我們都預期都希望新功能正常，同時也要確保舊有功能也要能正常

所以這時候進行 Regression Test 是可以盡量 cover 該產品的全面性功能。

但這前提也是該產品的測試案例要足夠多，至少都要有列到重要功能以上，這樣 Regression Test 才能有 cover 到的效益。

假設該產品測試案例有 5000 個，但這時候只用純手動進行驗證，那就會是回歸測試地獄了XD

所以如果有 Automation Test 進行 cover 的話，這樣整個測試時間既能縮短還能讓 QA 可以做更有價值的測試或流程改善等。

回歸測試得標準也一定是全部都要驗證，它也是可以針對測試計畫的不同而有所改變，取決於範圍大小和風險評估

可參考下列表格

參考來源:

• [30天快速上手TDD][Day 2]Unit Testing 簡介
• 鼠年全馬鐵人挑戰 WEEK 03：軟體測試的種類 - 第二集
• 回歸測試 (Regression Testing)