在上年的時候，我曾經把測試用例比喻成盾，而把測試比喻成劍。（http://www.testingreflections.com/node/view/3041），我仍然相信測試用例的創建會有兩個用途或目的：
1） 測試用例被認為是要交付給顧客的產品的一部分。測試用例在這里充當了提高可信度的作用。典型的是UAT（可接受）級別。
2） 測試用例只作為內部使用。典型的是系統級別的測試。在這里測試效率是目的。在代碼尚未完成時，我們基于設計編寫測試用例，以便一旦代碼準備好了，我們就可以很快地測試產品。
a） 測試用例被內部使用，但是目的是可信度，而不是效率。也意味著測試用例會在測試執行過程中被不斷修改和重寫。
b） 探索性測試會取而代之，不寫測試用例
我不回進一步去探討a）的方式，因為很明顯這種是很不可靠的測試管理 – 你不能使管理層相信這是低效的利用資源的方式。也有一些時候，測試用例被創建只是用于報告測試進度。比如說，我們有80%的測試用例編寫了，而其中70%通過測試。我已經在抨擊這種方式，并且還會繼續抨擊它。因為這是典型的用缺陷數字來衡量質量，用測試用例個數來衡量測試進度的錯誤方法。
1、 純探索性測試
2、 執行編寫好的測試用例
3、 執行自動化測試腳本
從上到下，設計所需的時間要不斷增加，但是測試執行的時間不斷減少，因為自動化測試可能僅會驗證你在腳本里寫好要驗證的東西，那就意味著你要預測什么缺陷會出現。而在手工測試過程中，你可能看到間接的證據表明存在某些缺陷。測試用例越詳細，測試人員已經測試的時間就會越多（現在會執行得更快了），能找到那些間接驗證的問題的可能性越低。
講了這么多理論，現在來點實踐性的東西。我在新項目是按下面的方式做的：
首先，我會找出所有在第一個版本中界面自動化失效的地方。這可能會與那些只發布一次的項目不一樣，但是我在那些方面沒有什么經驗。當然單元測試像JUnit執行指定的API函數也會很有用，能被開發人員很好地創建，但是測試人員有時候也應該幫助一下他們。
接下來，在測試執行周期中，我不會寫任何測試用例。我只會在版本發布后更新測試計劃，詳細地寫出被測試功能特性的列表，以及對應有哪些功能特性不生效、對應的缺陷ID。在版本發布后，我創建詳細的測試用例文檔描述怎樣調用每個功能特性，輸入什么數據等等�？雌饋硐袷俏臋n，但是有著不同的目標和用途：目的是讓回歸測試執行更快速進行。例如，我把數據附加上去，從而減少準備數據的時間；我細化一些瑣碎的測試用例，測試人員（新手除外）會添加錯誤處理的一些細節。
我嘗試使用測試白板（Testing Dashboard）去替換正式的包含測試用例執行/通過/失敗/未執行等信息的測試報告。有時候，我只是通過非正式的所謂我的感覺之類的東西來溝通進度，而這其實是PM（項目經理）想要知道的，而不是測試用例的數字。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
