背景
最近面試了幾個人，問了一些關于測試用例的問題，但是基本上沒有能回答的讓我滿意。作為一個測試人員，測試用例的編寫絕對是非常重要的技能。別小看測試用例，小小的用例里面包含了大大的只會。
測試用例
毫無疑問，測試用例的編寫是一個測試人員的基本功，無論做什么方式的測試，都離不開測試用例，一份好的測試用例能夠在測試執行過程中給予非常好的指導意義。
測試用例的產出一般來說，是根據產品（業務）的需求分析后得出測試需求，再根據測試需求進行細分，得到測試用例。這中間的學問就非常大了。
測試設計
軟件測試的目的就是保證軟件的質量，漏測是最大的忌諱，因此在測試設計過程中，如何防止設計遺漏是非常關鍵的。產品（業務）的需求對功能上描述是比較清晰的，按照功能來設計，只要設計的方法正確，那么功能上基本不會有問題。但是這僅僅是從業務的角度來分析問題，還需要分析開發的設計文檔，根據開發的設計，適當的補充一些需求文檔上沒有覆蓋的點。最后，還需要用自己的經驗做一些探索性的測試用例。
所以一個好的測試設計應該包括以下幾個部分：
- 業務功能的覆蓋
- 開發設計中針對業務功能的補充
- 某些專題模塊的單獨測試
- 工作經驗的探索設計
測試用例的顆粒度
這個問題在早期工作中有專門嘗試過，不同的設計方式對后續的維護以及執行影響非常大，因此在項目的初期就要想好用例設計的顆粒度。在網上看了一些文章，對于這點的理解都不深，我簡單列一下，不同顆粒度的優缺點如下：
粗顆粒度
優點
- 設計的周期短
- 可維護性強
- 能夠快速的應對頻繁變更的需求
- 執行時靈活度高，能夠有效的調動執行人員的積極性
- 占用測試資源少，少量的人員花費少量的時間即可完成
缺點
- 漏測的可能性高
- 項目質量過于依賴測試人員的職業素養
- 用例數量少
適用場景
粗顆粒度的測試用例相對適合小團隊適用，人少，時間短，而且能夠快速的相應變化的需求。當然，缺點也是非常明顯的，沒有了詳細的測試用例的束縛，每個點的質量就非常依賴測試人員的素質，需要測試人員有很高的職業道德，并且對于業務的理解程度，系統的架構的熟悉程度都有很高的要求。
在大項目中也并不是不能使用，我曾經在項目中這么干過，說實話，效果還不錯，在大項目中，開發人員數量多，對于業務的理解也是參差不齊，很有可能他們沒有按照約定的方式進行實現，而這種情況在大項目中會導致大量的測試用例需要維護，而粗顆粒度的設計，能夠低成本的快速響應這些變化。
我在缺點中的列的用例數量少，不是開玩笑隨便列的。一般來說要拿資源都是以數據說話，測試用例數量少就意味著，你的談判籌碼就少，能申請到的資源也就少，但是在項目不減少的情況下，工作量是固定的，因此每個人的工作量就會相應的增加，這也是進行粗顆粒度拆分時需要注意的地方
細顆粒度
優點
- 漏測的可能性小
- 風險左移，對于管理者來說容易把控
- 用例數量多，利于申請資源
- 不依賴測試人員的綜合素質
- 能夠針對測試用例提前準備大量的測試數據
缺點
- 測試設計的周期長
- 可維護性極弱
- 執行束縛大
適用場景
細顆粒度的好處也顯而易見，能夠把所有風險集中到設計階段，對于管理者來說省了非常大的精力來做其他事，但是由于精細的設計，導致小團隊沒有很多的資源往測試設計中投入，因此細顆粒度的設計比較適合大團隊，對于測試人員的要求非常低，即使是剛入職的新人也能夠快速的上手進行測試。在測試顆粒度細的情況下，能夠非常清晰的了解將來執行階段需要使用的數據，環境等資源，因此能夠將數據提前準備，這將極大的減少測試執行階段的時間。
當然，缺點也是顯而易見的，需求做一點變更或者開發不老實一點，馬上就會血崩，案例維護的成本非常之高，尤其是大項目的用例，維護起來非常的折磨人。而且在執行過程中實際結果和用例產生一點偏差，都會讓執行人員非常的尷尬。
總結
總結了那么多內容，都是一些理論，在實際的工作中是可以穿插起來進行的。測試用例的顆粒度在一個項目中是可以共存的，并不是所有的用例都要粗或者都要細，可以根據自身的情況做一些調整，比如按照業務進行拆分的時候，可以把自己熟悉的業務做粗顆粒度的編寫，變化非常小的部分做細顆粒度的編寫，提前做好分工的情況下，根據不同執行人員的素質也可以做顆粒度的拆分。理論知識永遠是死的，人才是活的，根據自己的實際情況合理的利用理論知識才是自我提升的途徑。
