測試案例 (test case) 的輸出方針
爭什麼爭？摻在一起做「撒尿牛丸」啊！
📢 如果此文章有幫助到你，請按此追蹤 一日測試 IG (oneday.software) ，與我們保持高度互動，以獲取最新的軟體資訊與技術方案！
近期筆者需要針對測試案例的管理系統與測試案例輸出模式制定一方案，讓團隊能更好的管理手動與自動化的測試案例，而有些許想法油然而生，因此透過此篇文章做個紀錄，也希望能讓更多測試人員有更多的思考方向。
產品功能會依據生命周期進行迭代。迭代的過程中，產品面貌會不斷的調整與優化；而對於測試團隊而言，除了對產品知識地圖的更新與測試技術能力的積累外，對於其他團隊最客觀的貢獻則是「測試案例的輸出」。
建立測試團隊知識庫
「測試案例」是測試團隊的知識庫。測試案例依測試目的與場景能被分為手動領域與自動化領域，但這兩者存在著本質上的差異，這也是一般公司的謬誤。一旦手動測試人員不足，直接要求測試人員做 E2E 自動化，所以理所當然的就想把手動測試案例「逐條」翻成自動化測試案例，覺得這樣才能取代原本手動的工，但實際上並非如此！這樣直翻的作法雖然驗證目的一樣 (達成同樣的測試覆蓋率)，但想造成的效果不同所費的成本大相逕庭，因此，筆者並不建議將手動的測試案例直翻成自動化的測試案例。
舉個例子，參考上方的路線圖，從臺北車站到機場第一航廈站 (A1 → A12)，總共是 12 個站點。假設「藍線」是手動測試案例，「紫線」是自動化測試案例，「每個車站是否能讓列車通過」則是驗證點 ，而無論是手動測試或是自動化測試都會通過各車站，差別只在於列車是否停靠該站，而「列車是否停靠該站」則是測試案例 。
- 藍線 (手動測試) 停 12 站，可視為有 12 個測試案例，驗證點 12 個
- 紫線 (自動化測試) 停 4 站，可視為有 4 個測試案例，驗證點 12 個
在自動化測試的部份，明明花費較少時間就能達成一樣的測試覆蓋率，那為什麼自動化測試案例數要跟手動測試案例數對齊，逐條翻成一樣的測試案例數量呢？
自動化要在可控的成本下，盡可能增加有效測試的範圍
依上述的想法，自動化的測試案例數量應該是比較少的。但與其說自動化能夠減少測試案例的數量，大幅縮短回歸驗證 (Regression Test) 的時間，不如說自動化要在可控的成本下 (e.g. 產生案例的時間、案例執行時間、錯誤排查成本、測試案例數量…) ，盡可能增加有效測試的範圍，才符合做自動化的初衷：自動化測試並不是用來取代手動測試，而是減少定期功能回歸測試所投入的手動資源。因此，讓自動化測試案例參考手動測試案例適時解耦，不要逐條直翻，應該會是比較好的做法。
測試案例紀錄方式多樣，混合使用更符合當今趨勢
測試案例紀錄方式很多種類，有的團隊使用試算表軟體 (e.g. Excel)，有的團隊則使用第三方測試案例管理平台 (e.g. TestRail, TestLink)，有的團隊則直接自建資料庫，都有其優劣勢，但由於文章篇幅有限，相關分析不在此贅述。
在「測試之美：領略頂尖專家改善軟體的測試法則」該書 (初版 2011.11) 中的第十七章 (p.250-p.252) 中提及，心智圖 (mindmap) 是種傳統的腦力激盪工具，想法由中心概念分枝而出，隨著愈遠離中心也更加明確、具體。心智圖只顯示了該測試什麼，而這些對測試人員與相關人員來說是更重要的資訊。
在書中也有提到心智圖有助於保持測試文件的更新，這其實有助於當需求更迭時，測試人員也能透過心智圖的節點分布快速更新相關的測試案例，當然，當團隊若有分成不同領域，心智圖的優勢則更為明顯。在做領域轉換時，測試人員也能以此熟悉特定領域的核心功能與知識地圖，不至於讓測試團隊的人員有異動時而產生核心知識的斷層。
其實筆者第一次看到使用心智圖當做測試案例的輸出，是在阿里巴巴服務 (2016–2018) 的時候，因為阿里巴巴的專案步調非常快，但筆者發現使用心智圖的撰寫方式，可以快速的把新的需求拆解成細小的驗證點。以往在 HTC 動輒寫測試案例就需要花費筆者至少一周到兩周的準備期。而在阿里巴巴寫測試用例只需 1 到 2 天，相形之下，這足足的省去筆者 3 到 8 天的工作天，其影響力不言而喻。
但難道心智圖沒有缺點嗎？其實是有的！心智圖的動態結構讓每個人對於測試案例都有自己的想像，所以不容易對齊，但其實這是可以透過團隊內的溝通與標準統一出一套思考的架構標準而解決的。另一方面，心智圖也無法統整出回歸測試的測試案例以便後續使用，但就如同書中作者提及，「心智圖所帶來的好處，特別是在他所經歷過的小到中型團隊當中，這些好處在抓住與組織測試靈感上遠遠勝過所付出的代價」。
筆者在不同的公司任職期間，上述相關的測試案例管理工具皆有使用過，也深知都有各的好處，而筆者的建議是：一次性或是專案組多人討論驗測範圍與內容時使用心智圖進行同步並完成快速的測試案例建立；當發現有特定重要且會一再被手動執行的測試案例則編入測試案例管理系統以做後續的回歸驗證使用。在現今的時代 (2023) 將不同管理工具混合使用，截長補短，能讓團隊的測試案例管理更有效率。
測試案例遵守原子性原則
原子性原則為「最小單位，不可分割且不可簡化」，若將原子性原則套用於測試案例的產生：一個最佳的測試案例僅會驗測一個結果。
原子性測試案例應用於自動化測試場景
原子性測試案例在自動化的適用場景為「單元測試」，在原子性特徵的基礎下，具有執行時間快、各單元相互解耦、精確反應錯誤點等優勢。測試人員只要清楚系統邊界與功能模組的交互，以數個 API 進行溝通後建立系統/功能的整合測試 (Integration Testing) 則能覆蓋大部份的主要功能。在系統整合測試中盡可能的減少測試路徑的長度，即能大幅地縮短每個自動化測試案例的時間，並獲得更完整的測試使用情境。因此，建議若有自動化需求的測試團隊，先把資源主要投放於熟悉系統交互並實作整合測試，相信能在一定的時間內得到自動化的最大效益。
而原子性測試案例的實踐並不適用於 E2E Testing (End-to-end, E2E) ，在整個 E2E Testing 的過程中，數個斷言同時存在於一個測試案例中，一旦發生錯誤，無法依據特定的最小單位進行除錯排查，再者整體維護耗時也耗力，算是投資報酬率相對低的自動化方案，但這裡指的並非不做相關開發，而是需要判定哪些重要的案例值得投資，而透過定期迭代有目的性的新增 UI 的自動化案例，方能達到最大效果。
原子性測試案例應用於手動化測試場景
這篇文章假設大家對於一般的測試案例編寫已有一定的基礎，因此不細說測試案例的組成要件，主要描述在產出測試案例的當下，編寫的思維與原則。若先以系統功能模組為其變因，在編寫手動的原子性測試案例有幾點需要特別注意：
- 測試路徑單一僅專注於單一功能點，不受其他模組的影響結果
- 透過系統架構進行測試案例的分層
以街口支付 App 為例，若目前想要寫一個「支付成功」的測試案例，範例如下：
- ❌ 支付成功
案例過於簡單，即便在測試步驟中說明測試步驟，但變因過多，無法收斂因此不符合原子性測試案例的特徵。 - ❌ 出示付款碼，支付成功
街口支付要做付款有兩條路徑，一條是出示付款碼，另一條是掃描條碼，這兩條路徑會經過不一樣的服務路由經過優惠計算、額外活動進行、支付工具都有不一樣的選擇，因此也不符合原子性測試案例的特徵。 - ⭕️ 出示付款碼，信用卡付款，不用街口幣，沒任何優惠，支付成功
加上了可能的三個變因會讓測試案例的目標更為明確，且這三項變因分散在不同的模組，一但確立了模組的入參，此測試案例自然不受其他模組的影響，因此這個測試案例比起前面兩條是個成功的案例。
結語
Ross Collard 曾於 Use Case Testing 的文獻 (p.35) 中提及，前 10% 到 15% 重要的測試案例揭露了 75% 到 90% 的重大缺陷。因此只要在測試案例的產生、維護與應用上都有一套既定的流程進行規範，並將手動與自動化的測試案例依團隊需求進行妥善的管理，相信在後續的專案中，測試的核心知識沉澱與輸出必定能更得心應手，團隊也會更有默契。
Howard Chiang
2023.2.6
