第壹:依據明確。
眾所周知，壹個項目是先建立的，然後經過壹系列的動作來分析需求。經過昨晚的需求分析，測試可以做測試需求，然後就可以寫測試用例了。因此，編寫測試用例的基礎是需求。那太籠統了。舉個例子。壹個系統在前期經歷需求分析、詳細設計、模塊設計等壹系列動作，最終生成詳細的需求描述和詳細的設計文檔等。在這些文檔中，所有的需求點和功能點都有詳細的描述，也有詳細的技術描述。接下來的工作就是如何把這些功能點和需求點變成測試點，這就需要做好測試需求分析和測試方案，生成可測試的測試點。這也反映了可衡量性的必要性。
假設經過前期工作，分析出系統有5個模塊，50個大功能點，500個具體需求點，最後產生5000個測試點。好，那麽，我們將編寫5000個測試用例。再次，壹個測試用例只能對應壹個測試點，測試點和用例的關系是1到1；壹個需求點可以對應多個用例，需求點和用例的關系是1對多。這樣做的目的從統計學上來說。
第二:目的明確
用例有壹個測試目的，就是有壹個明確的目的，而且只有壹個目的。不管之前走了多少步，都是為了找到通往這個目的的路。功能有從大到小的層次，我們做測試用例也是如此。否則，如何定義用例的優先級？在測試最小的功能點時，其他所有支持這個功能點的上層功能點默認都是正確的，這是我們的預期，所以在測試步驟中我們不需要專門為上層功能考慮測試數據，只需要把它當作壹個尋找當前功能點的正確方法。換句話說，妳要測試的功能點需要10個連接才能找到，所以我們之前應該已經設計好了前9個連接的用例，在10個連接中默認為正確是可以的。這個用例的前9步只告訴妳如何找到10步。就是這樣。
第三，便於統計。
測試用例對於整個測試過程的質量控制和評估具有重要意義。
首先，妳可以做測試需求覆蓋分析。這樣，如果壹個用例寫了幾個測試點，就無法完成需求覆蓋分析，至少是違反規則的。
第二，做用例成功率分析。壹個用例有多個測試點，肯定會減少用例的數量，大大增加用例的失敗率。那麽妳用例的成功率有什麽意義呢？
還可以通過模塊劃分來分析哪個模塊的問題更多，問題可能更多(因為不同的程序員能力不同，缺陷喜歡分布在壹起，大家都知道)。問題較多的模塊需要進壹步測試或者是下壹步的測試重點。如果妳的統計不準確，就會誤導結果。
第三，做缺陷分析。如果用例失敗，就會產生缺陷。如果壹個用例中寫了多個測試點，那麽這些測試點在返回的時候也會返回，壹些可能與缺陷無關的測試點也會被妳返回。
更詳細地說，我想給妳介紹壹下中國IT實驗室的網站，裏面有很多信息。