軟件測試之測試用例的概念

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

原文轉自：http://www.kjueaiud.com