將測試用作證據

從需求開始

測試為特定說法提供證據。一次成功測試執行，不能證明軟體的所有性質。要求測試前，先指出重要行為，以及每項檢查應偵測的缺陷。

對虛構組織資料匯出功能而言，主要要求是資料隔離。組織 A 的使用者不得收到組織 B 的紀錄。只檢查下載成功的測試，無法證明這項要求。

請代理程式解釋需求與斷言的關係。測試套件規模變大前，這樣比較容易發現遺漏案例。

選擇適當測試範圍

單元測試能快速檢查小型轉換。整合測試檢查元件如何協作。端對端測試則可透過已部署或具代表性的應用程式，檢查重要使用者操作流程。

選擇能提供必要證據的最小範圍。格式化工具不必為每項輸入執行完整瀏覽器測試；授權邊界可能需要真實路由和資料存取路徑；重要瀏覽器互動則需要實際呈現介面的證據。

沒有固定的測試類型比例適合所有系統。應根據需要偵測的失敗，以及維護檢查的成本選擇。

避免共同的錯誤假設

代理程式可能基於同一個誤解，同時撰寫實作與測試。兩者可以一致，需求卻仍未滿足。

假設實作依照請求中的組織 ID 篩選紀錄，而測試讓登入使用者和請求使用相同 ID。測試通過了，卻漏掉使用者請求另一組織 ID 的情況。

透過實際可信身分與授權路徑加入該案例。一律回傳「允許」的模擬函式，不能證明租用戶隔離，只能證明授權成功後的行為。

驗證測試能失敗

對已知缺陷，在隔離分支中，用有缺陷的版本執行新迴歸測試。確認測試因預期原因失敗，再套用修正並重新執行。

如果測試因測試資料無法載入而失敗，還不能作為業務行為的證據。應檢查失敗原因，不要只看結束代碼。

對較廣泛變更，變異測試可以協助評估特定程式碼變動是否造成測試失敗。它有成本，也不能替代需求審查。只有額外證據能支持後果重大的決策時，才使用它。

讓證據對應實際變更

在最終版本執行相關檢查。記錄略過的檢查及原因。審查修正後，先前提交的結果可能不再適用。

保持測試易懂。明確的準備步驟和斷言，比隱藏重要條件的大型輔助函式更合適。如果重複檢查只增加維護成本，無法偵測不同失敗，就移除它。

審查者應能說明測試證明了什麼，以及還有什麼不確定。這種解釋比大量測試數目更有用。