1.看項目Schedule：在項目時間緊張的情況下，往往留給測試人員的時間很有限，測試工作的重點就是多測試，早發現問題，這時候我認為測試用例的粒度是可以放粗一些的，但是“粗”不代表隨意，雖然可以放“粗”一些，但是要能明確測試要點，分清主次。而在項目時間寬裕的情況下，我還是希望能盡量將測試用例寫細一些，因為在寫測試用例的同時，也能加深對產品的理解。此外，測試用例的粒度寫的細，也能為后期的測試執行提供很大的幫助，為后期確定測試退出提供一定的數據支撐。
2.看項目人員情況：在項目實施過程中，測試用例通常是由具有較豐富測試經驗的人來負責并主導編寫的。對于測試新人，測試用例往往對新人更快更好的理解產品并完成測試任務提供了非常大的幫助。因此，對于測試新人，希望測試用例粒度細點是可以理解并認可的。而對于測試老鳥，很多時候他們既是測試用例的編寫者，同時也是測試用例的執行者，他們往往會有這樣一種認知：既然測試用例都是我來執行，我為什么要寫的那么細呢?我自己知道不就可以了嗎?編寫測試用例只是從流程上保證項目質量的手段之一，只要我能將把好質量關，又何必苛求于測試用例的粗細?重要的是測試的思想，而不是測試用例的粗細，測試用例粒度寫的太細會占用太多的時間，我為什么不把時間投入到如何提高測試效率等更有價值的事情上去?測試新人有測試新人的道理，而測試老鳥的認知也有其道理，因此，在一個項目組中，如果測試新人所占比例較大，對測試用例的粒度要求還是要盡可能細些，這樣可以幫助新人更好的適應項目角色，而對測試老鳥來說，一起教總比一個個教來得更有效率。
3.看客戶需求：有些客戶，在驗收產品的時候，會要求一并提供測試用例以及其執行情況，這種情況下，無論項目Schedule是否緊張，都需要按照客戶的要求來完成，因為這也是一項需求。
4.看項目本身是否具有延續性：隨著產品的多元化，產品的升級換代速度是很快的，換個UI，換個組織架構，或者重新包裝一下就是一個新的產品。這種情況下，總會有些功能模塊是一致的，測試用例也是可以復用的。因此，對于一些具有延續性的項目，個人還是認為測試用例的粒度可以盡量細一些，這樣有利于知識的傳承。而對于那些一次性的項目，測試用例粒度稍微粗些也沒關系，只要不影響項目質量就好。
總的來說，個人認為測試用例的粒度并沒有特定的標準，要依據項目實際情況而定。測試用例粒度當然是越細越好，但這僅是理想上的，實際上可操作性還是一個大大的問號。在實際執行中，要依據項目的實際情況和公司的相關制度而定，適用的才是最好的，畢竟項目的質量好壞才是最終的目標，如果因為糾結于過程而影響到最終的結果恐怕就不好了，過程是為了服務于結果，可不要陷入為了過程而過程的怪圈。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
