測試設計
乙個好的測試設計應該包括以下幾個部分：
（1）業務功能的覆蓋
（2）開發設計中針對業務功能的補充
（3）某些專題模組的單獨測試
（4）工作經驗的探索設計
測試用例的顆粒度
個問題在早期工作中有專門嘗試過，不同的設計方式對後續的維護以及執行影響非常大，因此在專案的初期就要想好用例設計的顆粒度。不同顆粒度的優缺點如下。
粗顆粒度
優點
設計的周期短
可維護性強
能夠快速的應對頻繁變更的需求
執行時靈活度高，能夠有效的調動執行人員的積極性
占用測試資源少，少量的人員花費少量的時間即可完成
缺點
漏測的可能性高
專案質量過於依賴測試人員的職業素養
用例數量少
適用場景
粗顆粒度的測試用例相對適合小團隊適用，人少，時間短，而且能夠快速的相應變化的需求。當然，缺點也是非常明顯的，沒有了詳細的測試用例的束縛，每個點的質量就非常依賴測試人員的素質，需要測試人員有很高的職業道德，並且對於業務的理解程度，系統的架構的熟悉程度都有很高的要求。
在大專案中也並不是不能使用，我曾經在專案中這麼幹過，說實話，效果還不錯，在大專案中，開發人員數量多，對於業務的理解也是參差不齊，很有可能他們沒有按照約定的方式進行實現，而這種情況在大專案中會導致大量的測試用例需要維護，而粗顆粒度的設計，能夠低成本的快速響應這些變化。
我在缺點中的列的用例數量少，不是開玩笑隨便列的。一般來說要拿資源都是以資料說話，測試用例數量少就意味著，你的談判籌碼就少，能申請到的資源也就少，但是在專案不減少的情況下，工作量是固定的，因此每個人的工作量就會相應的增加，這也是進行粗顆粒度拆分時需要注意的地方
細顆粒度
優點
漏測的可能性小
風險左移，對於管理者來說容易把控
用例數量多，利於申請資源
不依賴測試人員的綜合素質
能夠針對測試用例提前準備大量的測試資料
缺點
測試設計的周期長
可維護性極弱
執行束縛大
適用場景
細顆粒度的好處也顯而易見，能夠把所有風險集中到設計階段，對於管理者來說省了非常大的精力來做其他事，但是由於精細的設計，導致小團隊沒有很多的資源往測試設計中投入，因此細顆粒度的設計比較適合大團隊，對於測試人員的要求非常低，即使是剛入職的新人也能夠快速的上手進行測試。在測試顆粒度細的情況下，能夠非常清晰的了解將來執行階段需要使用的資料，環境等資源，因此能夠將資料提前準備，這將極大的減少測試執行階段的時間。
當然，缺點也是顯而易見的，需求做一點變更或者開發不老實一點，馬上就會血崩，案例維護的成本非常之高，尤其是大專案的用例，維護起來非常的折磨人。而且在執行過程中實際結果和用例產生一點偏差，都會讓執行人員非常的尷尬。
總結
在實際的工作中是可以穿插起來進行的。測試用例的顆粒度在乙個專案中是可以共存的，並不是所有的用例都要粗或者都要細，可以根據自身的情況做一些調整，比如按照業務進行拆分的時候，可以把自己熟悉的業務做粗顆粒度的編寫，變化非常小的部分做細顆粒度的編寫，提前做好分工的情況下，根據不同執行人員的素質也可以做顆粒度的拆分。根據自己的實際情況合理的利用理論知識。
如何提高測試用例的復用性
問題描述 在階段編寫的 測試用例 少則幾百，多則過萬，花費時間很多，而且有相當一部分用例只執行一兩次，復用性不佳。這裡想討論一下如何提高用例的復用性，尤其是不同專案之間。系統測試 精彩答案 對於測試用例的復用，我想很多測試工程師都會非常有話說，系統變更頻繁，業務變化大，流不統一等等，很多現實存在的問...
常見的測試用例設計方法有哪些？
1.等價類劃分 常見的軟體測試面試題劃分等價類 等價類是指某個輸入域的子集合，在該子集合中，各個輸入資料對於揭露程式中的錯誤都是等效的，並合理地假定 測試某等價類的代表值就等於對這一類其它值的測試。因此，可以把全部輸入資料合理劃分為若干等價類，在每乙個等價類中取乙個資料作為測試的輸入條件，就可以用少...
這樣的需求如何設計測試用例
測試點 1.db查詢a標誌位成功清除 2.db查詢a標誌位清除後，不會影響到b c d e f g標誌位 邏輯 手動下架商品，可以清除a標誌位 商品賣完自動下架，也可以清除a標誌位 實現方式 某資料表的w欄位用來標識商品的 a b c d e f g 標誌位 w欄位的值 是十進位制 轉換成16進製制...