話說作爲一個測試人員，測試用例的設計與編寫是一項必須掌握的能力，若想寫出有效的測試用例則需要多方面的技術知識。平時工作遇到功能測試較多，但過多是敏捷型的，涉及少。我認爲認真仔細的寫好測試用例是有必要的。
就如何設計測試用例需從如下幾個因素出發：1：複用率，隨產品不斷升級，需要涉及更詳細些，可一勞永逸；如僅使用一兩次，沒必要寫的太仔細。2：項目進度，時間允許可詳盡，時間緊可執行即可。3：使用對象，如果供多人使用，尤其讓後參加測試的工程師來執行，則需要設計的更加詳細些。4：關注有效功能，大多數情況：我們不太可能在一個測試用例包含全部測試要求，因爲衆多的功能及不同的路徑組合將使測試用例步驟繁多，操作複雜，或者完全不具可操作性。說這些並不是意味爲需求中定義的每個功能和特性，編寫一個或多個測試用例，只要把握好適度即可。
如何區分有效功能：
第一點，這個功能是可以還原到用戶原始的手工業務流程中去的。
第二點，這個功能是否標誌用戶實際業務的一個階段性結束，並且這項業務完成後，被完成的業務實體是否可以交付給其他用戶或業務供完成下面的工作？5：做好需求分析，這裏的需求包含顯示和隱式需求，根據需求文檔將不同需求來源劃分成一個個需求點，針對每小點進行測試分析，界定測試範圍，並運用多種測試用例設計方法產生測試節點。6：注重測試用例評審，評審會以檢驗功能是否覆蓋完全，評審會成員有設計，開發，測試及專家成員。
如果測試用例編寫不規範，後果不堪設想。
請參見：http://www.51testing.com/?uid-5939-action-viewspace-itemid-1219
囉嗦下：測試全面不等於全面測試，要結合實際進行覆蓋而不是盲目的追求全面覆蓋。有時候測試不全面但在不影響主流程的情況下，存在功能Bug也需要上線，這是測試人員無法掌控的。在成本面前測試人員總是無可奈何。。。
專家給的建議：在測試需求階段進行測試需求分析（如果是已有的升級版本，可通過已確定的需求說明書及開發人員的功能描述，對過往的測試用例進行補足編寫；如果是一個全新的需求可通過PRD，開發對產品的可實現功能描述及經驗，相關業務知識進行用例設計），明確需求並找出隱式需求，隨後制定測試策略。同時進行測試時間的估算和風險的預估，初步制定測試時間，測試工時，測試環境以及測試中可能需要的測試工具（如果有，可考慮）。