測試類型全解

是什麼？（測試類型為何要分這麼多種）

身為資深 C# 開發者，你一定寫過 xUnit 的 [Fact]，也跑過整個系統的端對端冒煙。這些「測試」表面上都是在驗證程式，但它們回答的問題、執行的時機、由誰負責、跑起來多快多貴，差異極大。

把測試分類的核心理由，是讓團隊能在不同抽象層級回答不同問題：

• 這個方法的邏輯對不對？（單元）
• 兩個模組接在一起會不會出事？（整合）
• 整個系統符合規格書嗎？（系統）
• 使用者真正想要的東西做出來了嗎？（UAT）

分類不是學術潔癖，而是讓你能有意識地分配測試投資：哪些要多寫、哪些要少寫、哪些要自動化、哪些必須人工。這份課程就是測試類型的「地圖」。

兩大分類：功能性 vs 非功能性測試

最頂層的分類，是問測試在驗證「行為」還是「品質屬性」。

功能性測試問「對不對」，非功能性測試問「夠不夠好」。兩者都會失敗讓使用者離開，只是離開的理由不同。

功能性測試逐一詳解

下面每一種都從四個角度說明：定義、測什麼、誰做、何時做。

單元測試（Unit Test）

• 定義：針對最小可測單位（通常是一個方法或類別）進行隔離驗證，外部相依以 mock／stub 取代。
• 測什麼：純邏輯、分支、邊界條件、例外處理。
• 誰做：開發者本人，通常與生產程式碼一起寫（TDD 更是先寫測試）。
• 何時做：每次 commit、每次 build，秒級回饋。

整合測試（Integration Test）

• 定義：驗證多個元件「組合在一起」是否正確協作，常會碰到真實的資料庫、訊息佇列或外部 API。
• 測什麼：模組邊界、資料庫對應、序列化、交易、第三方串接。
• 誰做：開發者為主，有時與 QA 協作。
• 何時做：CI 階段，比單元測試慢（牽涉 I/O）。

系統測試（System Test）

• 定義：把整個系統當成黑箱，驗證它整體是否符合規格書。
• 測什麼：完整功能流程、跨模組情境、與規格的一致性。
• 誰做：QA／測試團隊。
• 何時做：功能開發完成、進入測試環境後。

端對端測試（E2E Test）

• 定義：從使用者實際入口（瀏覽器、App）出發，走完一條完整業務流程。
• 測什麼：真實環境下的關鍵使用者旅程，例如「下單到付款成功」。
• 誰做：QA 或開發者，常用 Playwright、Selenium 自動化。
• 何時做：發布前的關鍵路徑驗證，數量應精選。

驗收測試／UAT（User Acceptance Test）

• 定義：由真實使用者或業務代表驗證系統「是不是他們真正要的」。
• 測什麼：商業需求、實際工作流程的可用性。
• 誰做：終端使用者、產品負責人、業務單位。
• 何時做：上線前最後一關。（下方有專段詳解。）

冒煙測試（Smoke Test）

• 定義：建置完成後的「能不能開機」檢查，確認最關鍵功能可運作，值不值得繼續測。
• 測什麼：少數核心路徑，例如服務能啟動、首頁能開、登入能過。
• 誰做：QA 或自動化流水線。
• 何時做：每次新版本部署到測試環境後第一件事。

健全測試（Sanity Test）

• 定義：針對某個修改或修復，做一次窄而淺的快速驗證，確認該特定功能合理運作。
• 測什麼：剛改動的小範圍功能。
• 誰做：QA。
• 何時做：收到小型修補後，決定要不要進行完整回歸。

回歸測試（Regression Test）

• 定義：在程式碼變動後，重新執行既有測試，確認原本好的功能沒被改壞。
• 測什麼：既有功能集合，理想上盡量自動化。
• 誰做：自動化流水線為主，QA 補充。
• 何時做：每次有變更（修 bug、加功能、改設定）之後。

非功能性測試

功能對了，不代表系統能用。非功能性測試驗證的是品質屬性（NFR）。

測試金字塔與重要性權衡

測試金字塔（Test Pyramid）告訴你各層級該寫多少量。

為什麼底層多、上層少？因為越往下：

• 越快：單元測試毫秒級，E2E 動輒數十秒。
• 越穩：單元測試很少 flaky；E2E 受網路、時序、環境影響容易隨機失敗。
• 越便宜：定位失敗成本低，一個單元測試紅了就知道哪壞了。

冰淇淋甜筒反模式（Ice-cream Cone） 是金字塔倒過來：大量手動與 E2E 測試、極少單元測試。結果是測試又慢又脆、回饋遲緩、維護成本爆炸。很多團隊在「補測試」時不小心就堆成了甜筒。

各類型一覽比較

UAT 專段

UAT＝User Acceptance Testing，使用者驗收測試，是上線前由真實使用者或業務代表執行的最後一道關卡。

和系統測試的關鍵差別（面試常考）：

• 系統測試問「做得對不對」——系統行為是否符合規格書，由 QA 以技術視角驗證。
• UAT 問「是不是真正要的」——系統是否滿足實際商業需求，由使用者以業務視角驗證。

規格可能本身就寫錯，所以系統測試全綠、UAT 卻不通過，是完全可能而且很常見的情況。

Alpha 與 Beta：

• Alpha 測試：在開發方內部、受控環境，由內部人員（非開發團隊本身）模擬真實使用。
• Beta 測試：把產品交給真實外部使用者在真實環境試用，蒐集回饋（即「公測」）。

誰來測、驗收標準： UAT 由終端使用者、產品負責人或業務單位執行，依事先約定的驗收標準（Acceptance Criteria） 逐條確認。標準通常以業務語言寫成，例如「主管能在一個畫面核准請假並收到通知」。

C# 範例（xUnit）

下面用同一個情境，對照單元測試與整合測試的差別。注意單元測試把相依隔離掉，整合測試則真的碰外部資源。

// 受測對象：下單服務
public class OrderService
{
    private readonly IInventoryRepository _inventory;
    public OrderService(IInventoryRepository inventory) => _inventory = inventory;
 
    public bool TryPlaceOrder(string sku, int qty)
    {
        if (qty <= 0) return false;
        var stock = _inventory.GetStock(sku);
        return stock >= qty;
    }
}

// 單元測試：用 mock 隔離資料庫，只驗 OrderService 的邏輯
public class OrderServiceUnitTests
{
    [Theory]
    [InlineData(5, 3, true)]   // 庫存足夠
    [InlineData(5, 10, false)] // 庫存不足
    [InlineData(5, 0, false)]  // 數量非法
    public void TryPlaceOrder_ChecksStockCorrectly(int stock, int qty, bool expected)
    {
        var repo = new Mock<IInventoryRepository>();
        repo.Setup(r => r.GetStock("SKU-1")).Returns(stock);
        var sut = new OrderService(repo.Object);
 
        var result = sut.TryPlaceOrder("SKU-1", qty);
 
        Assert.Equal(expected, result);
    }
}

// 整合測試：接真實 DB（測試容器），驗 Repository 與資料庫的協作
public class InventoryRepositoryIntegrationTests : IClassFixture<SqlServerFixture>
{
    private readonly string _connectionString;
    public InventoryRepositoryIntegrationTests(SqlServerFixture fx)
        => _connectionString = fx.ConnectionString;
 
    [Fact]
    public void GetStock_ReadsSeededRowFromDatabase()
    {
        // 前置：資料庫已 seed 一筆 SKU-1 庫存 7
        var repo = new InventoryRepository(_connectionString);
 
        var stock = repo.GetStock("SKU-1");
 
        Assert.Equal(7, stock); // 真的查到資料庫的值
    }
}

重點對照：單元測試毫秒級、無外部相依、可大量寫；整合測試較慢、需真實 DB、驗的是接線正確。

常見誤區

實戰補充（Q&A）

Q：回歸測試怎麼自動化？ 把過去出過 bug 的案例與關鍵路徑沉澱成自動化測試套件，掛進 CI，每次 commit／PR 觸發。策略上以單元與整合測試承擔大部分回歸（快又穩），E2E 只覆蓋最關鍵旅程。修了一個 bug，就補一條對應的回歸測試，避免同一個洞再掉進去。

Q：該寫多少 E2E？ 依金字塔精神，E2E 應精選而非全面：只覆蓋「壞了就會出大事」的關鍵業務流程（登入、結帳、付款）。其餘邏輯下推到單元與整合層去驗。一個常見的健康訊號是：當你想用 E2E 去測一個分支邏輯時，多半代表那段邏輯應該被往下挪到單元測試。

理解測驗

重點整理