同一個功能，測試新人可能設計3個用例，而經驗豐富的測試人員可以設計出6-10個測試用例，這是爲什麼呢？因爲你想不到。只有經過不斷的實踐和栽跟頭，你才能積累經驗，知道哪裏會出問題。而這些，是測試新人和開發想不到的地方。這就是優勢。
一個產品的質量好不好，跟測試用例的設計的覆蓋度有很大關係。如果你的用例，只覆蓋了60%的缺陷，那麼剩下的40%呢？有可能剩下的30%是你在測試的過程中發散出來的邏輯，而10%，可能就是你遺漏的。那麼這個30%，可以作爲我們的經驗，及時的補充到測試用例裏去，下次你設計的時候，你可能能覆蓋65%的缺陷了。可別小看這5%，水滴穿石，日積月累後，你可以很放心的把設計的用例交與新人去執行了；
上面說的是測試用例的設計的重要性。下面再談下設計方法。
目前我設計過的主要有幾種方式：1、步驟執行的形式；2、思維導圖的形式（Xmind）；（當然還有很多其他形式，歡迎大家拍磚）
我比較推薦思維導圖的形式，思路清晰，對功能點一目瞭然，測完可以review下功能點以確保無遺漏。最主要的是好維護，因爲系統的功能是經常會變的。步驟執行的形式就是對新人來說，很好執行，但是維護成本太大了，不推薦。
那麼怎麼使用思維導讀來寫case呢？
首先，寫case之前我們要做一個設計，深度閱讀需求文檔，整理出系統的功能點，如果開發有寫UC那就更好了，直接使用開發的UC功能點並對不全的功能點進行補充。但是這裏功能點描述切記太過冗餘，最好能用自己的語言進行歸納總結。總結之後對功能點會有自己的理解，而不要拷貝PD提供的需求文檔。
接下來我們就針對功能點開始設計case了，寫case 的時候，用最簡潔的語言描述出邏輯就可以了，其實也就是一個個idear；對於執行起來很複雜的，可以備註上執行步驟；
寫case的時候我們要注意幾點：
1、最基本的，要保證功能點正常操作流程。
2、儘可能的把所有執行路徑（邏輯）都列出來。
3、考慮邊界值、異常情況、用戶的操作習慣、不同的機器環境、不同的電腦分辨率。
4、對於前端的web類的系統：那麼我們還要考慮瀏覽器兼容性。
下面，給出我做過的一個功能點的case示例：
