測試用例設計的粒度需要考慮幾方面的因素：

1、複用率：如果隨著產品不停得升級，需要設計的詳細些，追求一勞永逸;僅使用一兩次，則沒有必要設計的過於詳細;

2、專案進展：專案時間如果允許可以設計的詳細些，反之則能執行即可;

3、使用物件：測試用例如果供多人使用，尤其讓後參加測試的工程師來執行，則需要設計的詳細些。

我們不太可能在一個測試用例包含全部測試需求，因為眾多的功能以及不同的路徑組合將使這樣一個測試用例步驟繁多，操作複雜，完全不具有可操作性。

當然，這也並不是要您走向另一個極端，為需求中定義的每個特性或功能都提供一個甚至多個測試用例。這裡的關鍵，是要尋找一個合適的度。推薦的方法是：關注有效功能.

區分有效功能的關鍵有2點：

1、這個功能是可以還原到使用者原始的手工業務流程中去的。

2、這個功能是否可以標誌著使用者實際業務的一個階段性結束?並且這項業務完成之後，被完成的業務實體是否可以交付給其他使用者或業務以供完成下面的工作?

功能測試中要保證測試的覆蓋率，首先要做好測試需求分析，測試需求獲取方法包含了2種，顯式需求及隱式需求。

做好需求分析，及時維護測試需求文件。將不同的需求來源劃分成一個個需求點，針對每一點進行測試分析，界定測試範圍，利用各種測試設計的方法產生功能測試節點。

用例設計階段，首先要保證產品或專案在主要功能測試用例完全覆蓋的情況下去對細節進行測試用例設計，可以運用多種測試用例設計方法來減少功能遺漏。

強化測試用例評審階段的作用，以測試用例評審會議來檢驗功能是否覆蓋完全，評審會成員需要有設計，開發，測試及專家組成員。

測試全面不等於全面測試，不要過分的追求高測試覆蓋率，要結合實際情況去考慮，有些情況下，即使測試不全面，哪怕功能還有BUG也需要上線，這是測試人員也無可奈何的事情，因為畢竟要考慮到成本等一些其他的問題。

1、測試需求階段是沒有辦法進行實質性的測試工作的，在測試需求階段應該進行的測試需求分析。 明確測試需求，並分析出隱式需求，然後制定測試策略，初步制定測試時間，測試工時，測試環境，測試中是否需要使用工具(如果需要，就要確定選擇哪款工具，或那幾款工具)，並將可能會影響測試工作進行的風險進行預估，這些實際上就是測試計劃的部分內容，而測試需求就是制定測試計劃的基礎和重點。

2、如果是一個已有產品的升級版本，那麼可以通過已確定的需求說明書及開發人員對功能的描述，過往的測試用例來進行功能測試用例的編寫;如果是一個全新的軟體那麼可以通過需求說明書，使用者手冊說明書，開發對產品的可實現功能描述及經驗和業務知識來進行功能測試用例設計，但是在脫離了需求文件的情況下這些用例可用度非常低。