作者 | 曹巧暉
背景
經歷過校招或社招的測試同學，都會被問到測試用例的設計、使用方法，以及用例的重要性。
大概了解過測試行業或者有一些測試基礎的同學面試時能很好的回答上來，設計用例的方法，但是給一個真實場景需要簡單編寫測試用例的時候，往往就暴露了設計用例的短板。再進階一些的測試同學，會很疑惑，測試用例有什么用呢？每次提測前，把測試用例照着需求文檔抄寫一遍，走個過場？提測后，照着用例點點點，執行完畢后沒有測出任何bug，達到了上線狀態？上線后，測試用例毫無價值，用完棄之，最后線上出現bug，無跡可尋。心里一百個怪寫用例浪費時間，沒有實際價值。
為什么要寫用例？
為什么要寫測試用例？或者說我們寫用例到底有什么用？
1、方便理解需求，覆蓋更多場景
2、有助於評估測試工時
3、便於了解測試數據流向
4、把控測試進度
5、上線前核心功能回歸
6、提高測試效率，理清測試思路
所以，測試用例很有必要，是測試理解業務的必備能力，測試的立身之本。
那怎么寫好測試用例呢？
設計測試用例：需求分析是關鍵、用例設計是核心、Case結構很重要
用例完整思路：
需求可行性分析-->業務流程分析→測試用例設計→測試用例評審-->維護/更新測試用例
1、需求可行性分析
從需求文檔中，找出待測試軟需求，通過自己的分析、理解，整理成為測試點，清楚被測試對象具有哪些功能。
測試需求的特點是：包含需求，具有可測試性。
測試需求應該在需求基礎上進行歸納、分類或細分，方便測試用例設計。
2、業務流程分析
軟件測試，不單純是基於功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。
為了不遺漏測試點，需要清楚的了解產品的業務流程。建議在做復雜的測試用例設計前，先根據研發或產品提供的流程圖，從測試角度對現有流程進行補充。業務流程圖可以幫助理解需求的邏輯和數據流向，從而指導測試用例的設計。
從業務流程上，應得到以下信息：
主流程是什么
條件是什么
數據流向是什么
關鍵的判斷條件是什么
3、測試用例設計
用例設計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。
在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。
4、測試用例評審
測試用例設計完成后，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審，在設計用例的時候，有不明確的需求，標記出來。在測試用例評審時，着重和產品、研發溝通確認。確認完后，更新測試用例。
5、測試用例更新
測試用例是“活”的，在軟件的生命周期中不斷更新與完善
5.1）遇到線上問題，復盤當時是否有遺漏這個測試點，更新測試用例
5.2）核心用例，在每次需求上線后，持續更新
6、測試用例結構
傳統測試用例編寫都是通過Excel表格，元素有：測試用例編號、測試用例標題、優先級、測試模塊、前置條件、測試輸入、測試步驟、預期結果。
同上，注冊用例用Xmind格式呈現形式：
可以發現測試結構發生了很大變化，顆粒度也有所不同，相比Excel，xmind更結構化，更適合快速迭代的互聯網。但是，大項目測試方案中測試點梳理，以及一些回歸場景，更建議用Excel。
日常測試中，xmind測試用例注意點
那么我們日常測試中，如果用xmind梳理用例結構注意哪些點呢？
1、不需要復制粘貼需求文檔
每次review組內用例時，會發現用例都會照搬需求文檔，需求文檔中有預期結果1、預期結果2等，用例也是結果1、結果2等等。我們需要把文檔已有的結果1、結果2寫清楚后，再拆解異常結果3、結果4……
2、測試用例一定是要可執行。
3、測試用例要體現測試目標，理解需求的預期結果是什么
4、優先級很重要，核心用例要標記
5、測試用例不僅僅是用例，數據流向也要體現出來。
理解了為什么要設計測試用例、設計用例的關鍵是什么？用xmind結構展示一下測試用例：
第一步，展示干系人信息
第二步，梳理接口、數據流向
第三步，設計功能測試用例
第四步，執行用例，轉轉統一用測試用例平台管理。
截圖來源：zzcase用例平台
第五步，輸出公用用例、上線前featurelist
最終用例效果呈現
end