-
按版本大小靈活的設置用例
目前針對測試用例，有不同的呈現方式，在網易使用最多的可能有以下2種：
Xmind腦圖的形式和TC形式； - 大版本用例（業務邏輯複雜，測試點多）
一般針對大型版本，比如校招專場重構等比較複雜的版本，我們建議2種結合着看，先用Xmind把所有的邏輯和測試點羅列，然後在tc上編寫具體的用例，明確冒煙的範圍等，但是該種方式有一個缺點是耗時較長，建議預留一定的編寫用例的時間；一般我們在用例評審的時候更關注的是測試點的羅列； - 中小版本用例（業務邏輯相對簡單，測試點明朗）
如果是中小型版本，建議可以採用TC或者Xmind的單獨走的形式。
特別是小版本迭代，可以直接用Xmind羅列所有的測試點，Xmind可以非常清晰的羅列出整個迭代產品邏輯，快速的產出；但是需要針對邏輯或者操作不太複雜的版本，如果開發在冒煙上仍然有困難，可以單獨羅列冒煙用例，或者跟開發達成冒煙共識；
還有一種是直接用TC，如果版本邏輯不復雜，寫用例時間相對充裕，可以直接用該種方法，TC用例的產出需要對用例的完整性和可讀性有較高的要求，形式上來說對開發冒煙和用例的執行是友好的，但是需要遵守一定規則。
-
TC用例編寫原則
編寫tc用例需要遵守如下原則：
-
系統性
在寫用例的時候，需要系統的考慮整個測試點的輸出。無論從測試類型上以及業務功能輸出上，都需要完整的考慮；參考系統測試設計思維建議
-
規範性
tc測試用例包含有幾個重要字段，比如用例的等級，標題，前置條件，操作步驟和預期結果，在寫用例的時候，很多時候我們可能忽略了重要字段的填寫，這樣在給開發以及產品在用例的執行和參考上可能會帶來一些困惑；針對重要字段，在tc上需要填寫完整，確保用例的規範性；
-
可讀性
用例的可讀性體現在文字輸出上也體現在整個用例的設計結構上；舉個例子，比如我們拿到一個迭代，如何非常清晰的合理的去對功能進行分層，可能直接影響到了用例整體結構的可讀性上，所以前期拿到整體產品結構的時候，不要急於下筆，而要學會給用例或者腦圖進行合理的分層；再比如說，在文字描述上，儘可能的要少出現一些模棱兩可的語句，引起不必要的理解錯誤；我們寫用例的話有兩個重要的目的：
1.梳理產品邏輯以及查看是否有需求漏洞
2.要將產品邏輯和需求正確的輸出給開發，達成三方共識。
以上兩點對用例的可讀性提出了重要的要求。 -
可操作性
舉個例子，比如有個需求是登錄失敗，提示“登錄失敗”。那我們寫用例的時候，是需要細化登錄失敗的場景（比如離職員工登錄失敗，用戶密碼錯誤等等），將每個用例細化成一個可以操作的指南，而不是在操作步驟上很籠統的概括“登錄失敗”。
以上是我們需要共同遵守和維護的用例規範，後續大家有好的建議可以繼續補充~