前言
最近乾的最多的事情就是設計測試用例、評審測試用例了，於是我不禁又想到了一個經典的問題：如何設計出優秀的測試用例？
可能有些童鞋看到這個問題會有些不以爲然，這有什麼好想的？幹個測試誰還不會設計測試用例？
但是以我個人經歷，以及一些接觸來說，這個測試基本功確實不是那麼容易做好的。可能很多人都覺得這個太基礎了，往往就越容易忽略，而喜歡趨之若鶩的追求各種開發語言、自動化測試、測試平臺這種上層建築。
在我看來，業務測試是基礎，其他的各種技術棧都是用來提效的手段，主次是分明的。另一方面來說，只有深入透徹得理解業務，才能更好的挖掘可以提效的點。
ok，言歸正傳，下面以我個人理解來淺談如何設計測試用例，歡迎交流。
如何設計測試用例
一、研究需求文檔
通常來說，正確的測試流程應該是：需求評審->測試用例設計->測試方案設計->測試環境\數據準備->提測後執行用例進行測試&查漏補缺，所以仔細的研究需求文檔是重中之重。
一般來說需求文檔裏會定義產品的功能點，我們可以先通篇閱讀對整個產品功能有個整體的印象，然後再開始從多個角度去深入產品細節中去，挖掘有價值的東西：
- 產品顯性功能點：這個很簡單，就是產品裏明確定義出來的內容。
- 產品隱性功能點：產品沒明確定義，但是會涉及到的功能點。
- 疑問點：需求定義不清楚的地方，或者涉及到一些測試範圍的確認等等。
在需求文檔輸出之後，一般相關部門也會跟着輸出其他輔助文檔，比如：UE交互文檔，UI設計頁面，這些可以更好地幫助我們形象化產品，更好的去設計測試用例。
二、知曉開發設計
需求確定後，開發一般也會開始進行開發設計。通常會有一些架構設計、流程圖、時序圖、接口文檔等內容輸出，千萬不要忽略這些文檔，我覺得是非常有價值的。
記住：就算是做黑盒測試，也不要把被測系統真正的當做一個大黑盒。
必須對內部的架構有清楚的認識，數據背後傳輸的鏈路、數據庫的讀寫分離、消息中間件 Kafka 的配置、緩存系統的層級分佈、第三方系統的集成等。
拿最近在忙的車控業務來說吧，當你在手機APP上點擊開車門後，這個指令如何達到車端，車端又是如何返回結果的。整個鏈路經過了哪些服務，中間件等你都要清楚纔行，否則你就不能說是真正地熟悉這個業務。不是真正的熟悉業務，那麼又如何真正設計出一份優秀的測試用例呢？
單單根據測試需求點設計的用例，只能覆蓋“表面”的一層，往往會覆蓋不到內部的處理流程、分支處理，而沒有覆蓋到的部分就很可能出現缺陷遺漏。
另外，我們可以去了解開發的實現思路，有能力的童鞋或許可以直接去看開發代碼。看不了的也可以通過跟開發溝通了解實現過程，這些對我們都有很大的幫助。
有時候開發在給你講述實現過程的時候，甚至就能自覺地發現一些問題。
但是，我們也不要完全根據開發的代碼實現爲依據去設計測試用例，還是根據原始需求來設計。
三、用例設計方法
瞭解的足夠多了，開始要去設計測試用例了。我們是先寫腦圖，記錄出思路和問題點，最後我們纔會編寫Excel版的測試用例。一般傳統互聯網可能也不要求寫Excel了，這個看不同公司規定。
然而不管你用什麼形式，你還是要通過運用一些方法來設計你的case，這裏提一下最常用的三種測試用例設計方法：
- 等價類劃分方法
- 邊界值
- 錯誤推斷法
當然了這裏只列出了這三種，我覺得是最常用的，起碼對於大多數的軟件測試場景都是這樣的。除非一些特定的領域，還會用到因果圖方法、判定表驅動分析法、正交實驗設計方法等等，這些就不表了。
方法在於你能真正的實際運用好纔行，記得在面試的時候問到候選人類似問題，方法說的頭頭是道，讓舉個具體的例子有的人就開始支支吾吾了，這些都是基本功不紮實的表現。
四、多角度拓展
基本功能點都設計完了，就要站着更多的角度去拓展下，挖掘一些隱形需求了。比如：
- 功能：與其他模塊產生交互，集成測試是否充分
- 性能：涉及到的接口是否存在壓力場景，併發場景等
- 安全：數據傳輸/存儲的加密、是否脫敏等
- 兼容性：不同設備、不同系統、不同屏幕是否顯示完好，覆蓋市面主流機型
- 易用性：功能是否好友，提示是否友好等