測試策略與測試報告

是什麼？

測試策略（Test Strategy）回答的是「用有限的時間與成本，怎麼把測試火力分配到最該測的地方」。它不是「把所有東西都測一遍」，而是一份取捨計畫：哪些用快又便宜的單元測試守、哪些必須串起來測、哪些只能靠少量端到端測試把關，以及效能、安全這些非功能面要不要測、測到什麼程度。

對資深 C# 開發者而言，重點不在「會不會寫測試」，而在能不能說清楚這個系統的測試取捨與風險。本課直接回答四個讀者最常問的問題：要測哪些、測試報告怎麼寫、測試如何傳承、以及「寫完是不是就不用看了」。

要測哪些

測試金字塔（Test Pyramid）描述的是數量比例：越底層越多、越快、越便宜；越上層越少、越慢、越貴。倒過來變成「冰淇淋甜筒」（E2E 一大堆、單元測試很少）是反模式 —— 跑得慢又脆弱。

除了金字塔上的功能性測試，還有一整類常被忽略的非功能性測試（NFR），這正是資深工程師與資淺工程師的分水嶺：

各層測試該驗證什麼

每一層有不同的「職責邊界」，搞混就會寫出又慢又難維護的測試：

判斷原則：能在單元層測的，就不要拉到整合層測（慢且脆）；反過來，牽涉到 SQL 語法、序列化、跨服務契約的，單元測試 mock 不出真相，該往整合層走。E2E 只留給「最賺錢、出錯最痛」的關鍵動線，例如登入、下單、付款。

測試報告怎麼寫

測試報告是給決策者看的（PM、QA Lead、發布負責人），核心問題只有一個：這個版本能不能發布？ 一份能被信任的報告通常包含這個骨架：

缺陷一定要分嚴重度（Severity），不要只丟一張「有 12 個 bug」的清單：

測試如何傳承

測試最被低估的價值，是它能成為活文件（Living Documentation）：永遠跟程式碼同步、不會像 Word 規格書那樣過期。三年後接手的人，讀測試就能讀懂需求。

• 測試命名即規格：方法名要描述「在什麼情境下、做了什麼、預期什麼結果」，而不是 Test1、TestAddItem。
• BDD/Gherkin 規格：用 Given / When / Then 把驗收條件寫成「業務也讀得懂」的語言（SpecFlow / Reqnroll），需求與測試合而為一。
• 覆蓋率報告進 CI：每次提交自動產生覆蓋率與趨勢，讓「品質可見」。
• 用測試表達意圖：當你想說明「這個邊界條件為什麼要這樣處理」，與其寫註解，不如寫一個命名清楚的測試 —— 註解會過期，會失敗的測試不會。

Feature: 購物車金額計算
  Scenario: 滿千折百
    Given 購物車內商品總額為 1200 元
    When 結帳
    Then 應折抵 100 元，應付金額為 1100 元

「寫完就不用看了嗎？」

不是。測試是活的資產，不維護就會腐爛、甚至反過來騙你。

C# 範例

一個好的測試，光看名字就知道它在驗什麼；內部則用 Arrange / Act / Assert 三段式讓意圖一目了然。

using Xunit;
 
public class ShoppingCartTests
{
    // 命名即規格：情境_動作_預期結果
    [Fact]
    public void Checkout_當總額滿千_應折抵一百元()
    {
        // Arrange：準備情境
        var cart = new ShoppingCart();
        cart.AddItem(new Item("書", price: 1200m));
 
        // Act：執行被測動作
        var payable = cart.Checkout();
 
        // Assert：驗證單一明確結果
        Assert.Equal(1100m, payable);
    }
 
    [Theory]
    [InlineData(999, 999)]   // 未達門檻不折
    [InlineData(1000, 900)]  // 剛好達門檻
    public void Checkout_依總額是否滿千_決定是否折抵(decimal total, decimal expected)
    {
        var cart = new ShoppingCart();
        cart.AddItem(new Item("X", total));
 
        Assert.Equal(expected, cart.Checkout());
    }
}

重點：測試名稱用中文或清楚的英文描述「情境＋預期」，後人不用讀實作就懂規則；[Theory] + InlineData 把多個邊界條件變成可讀的規格表。

常見誤區

實戰補充（Q&A）

Q：測試金字塔一定要遵守 70/20/10 嗎？ A：比例是經驗法則不是聖旨。重點是「底層多、頂層少」的形狀。某些以整合為核心的系統（例如薄商業邏輯、重資料庫的服務）整合層會更厚，這合理；但 E2E 永遠該是最少的。

Q：沒時間寫測試怎麼辦？ A：用風險排序。先替「改最頻繁 × 出錯最痛」的模組（金流、權限）補測試，其餘暫緩。沒有資源全測時，測試策略的價值正是幫你決定「不測什麼」。

Q：測試報告要多詳細？ A：看讀者。給工程師的可附失敗堆疊與 log；給發布決策者的，一頁講清楚「通過率、關鍵缺陷、可否發布」即可。同一份原始數據，產出不同摘要。

Q：覆蓋率守門設多少合理？ A：與其設一個高總門檻，不如設「新增/異動程式不得低於 X%」（diff coverage）。這樣不會被舊程式拖累，又能保證新債不增加。

理解測驗

重點整理