4、資源配置：
資源配置較少，無法實現測試用例的細化時，可以采用粗顆粒度的測試用例。
資源配置較多，可滿足用例編寫、評審、修訂的交叉進行時，可采用細顆粒度。
舉例：如果測試人員配置較少，一共就三五個人，每人負責一個項目，彼此沒有時間去做評審，甚至項目都存在臨時增多的現象，就無從談起測試用例的細化，甚至粗顆粒度都較難實現，只能拉一個測試大綱出來。
或者測試團隊有十多個人，但是項目是流水式過來的。需求、開發、測試是流水線模式處理大批量的項目，無法做到一個項目的全流程參與時，也很難展開測試用例評審、修訂以致細化事宜。
5、需求變更：
需求變更較多時，建議采用粗顆粒度的用例，可較靈活的覆蓋需求。經過一輪輪的評審，等需求基線化之后，在實際的滾動測試中，在逐步細化用例——根據項目實際情況。
需求變更較少時，或需求變更波及較小，不是系統設計框架的頻繁改動——具體的標準需要不同行業產品的評估，可對應較大的細化測試用例變更量。
舉例：一個需求，粗顆粒度的用例為100條，細顆粒度的用例為10000條。此需求變更，如果要修改粗顆粒度的用例，只需要修改10條；修改細顆粒度的用例，牽扯到細化的交叉邏輯，需要審閱2000條用例并可能修改1200條。
如果測試用例修改人非測試用例編寫人，則修改時間還可能延長1.3倍。
6、項目對象：
如果項目/產品最終面對的客戶是特定人員、專業人員、技術人員、培訓后的操作員，可以采用粗顆粒度的用例。
如果項目/產品最終面對的客戶是廣義的使用群體、人民大眾消費者，要采用細顆粒度的用例。
面向專業人員的項目/產品，測試傾向于正向測試，一些問題或使用方式在規定、需求之外，可以在培訓或規范中指定操作模式，或憑借技術人員的功底來避免問題。
面向非專業人員的項目/產品，無法做到培訓和操作約定，各種稀奇古怪的使用方法，操作習慣，所以更傾向于細顆粒度，覆蓋負向和隨機操作的測試用例。
7、測試團隊素質：
團隊個體素質較高，可適應粗獷、敏捷的風格時，可以采用粗顆粒度的用例。
團隊處于成立初期或磨合期，需要細化的規則約定來指導時，采用細顆粒度的用例。
8、公司決策投入：
公司對測試工作的投入，對產品質量的要求，對行業節奏的把握。具體分析，可參考項目質量性質部分的論述。
測試用例粗細的另外一個概念：用例的文字描述粗細。
（舊文貼成）
文檔分為好多種，在后面寫測試用例的時候你們會遇到類似的顆粒度的問題。
第一類是寫給自己，以及懂這個技術的，差不多水平的同事看的。這樣只需要大致的描述核心關鍵點就可以。
第二類是給技術一般的員工，但是有一定底子的人看的，這樣基本的概念就不用描述，整體步驟描述清楚就可以。
第三類是給不懂技術，只會看圖一步步操作的外行看的，這樣就要詳細細致的描述基本概念，步步都截圖，傻瓜式的對比參照的搞過去。
舉個例子，使用ping 命令
第一類寫法：如果網絡不通，使用ping命令測試一下網絡是否通暢。
第二類寫法：如果網絡不通，在cmd模式下，使用ping X.X.X.X 的命令格式，測試一下網絡是否通暢。
第三類寫法：如果網絡不通，點擊開始，選擇運行，然后在運行框里輸入cmd，然后在彈出框里面，使用ping X.X.X.X 的命令格式，如果顯示Reply from X.x.x.x bytes=32 time=3ms TTL=64，就是通暢，其他顯示就是不通暢。
那么？你這份文檔是寫給誰看的？
———————————————————————————————————————————————
上述都是針對單一的外部環境給出的建議。如果外部環境參數較多，并且互相矛盾，比如團隊新手多，但測試項目對質量要求很高，并且項目周期短時，如何構建測試用例的顆粒度，就更需要測試管理人員的平衡。
測試用例的粗細：掌握質量與效率之間的平衡。
相關鏈接：
測試用例之度——系列之顆粒度（上）