軟件敏捷測試是否寫測試用例(2)

　　軟件是開發人員需要去努力實現敏捷化的對象，而測試用例則是測試人員需要去努力實現敏捷化的對象。要想在測試用例的設計方面應用“能工作的軟件比全面的文檔更有價值”這一敏捷原則，則關鍵是考慮怎樣使設計出來的測試用例是能有效工作的。

　　基于需求的測試用例設計

　　基于需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。

　　要把測試用例當成“活”的文檔(Effective Software Testing ： 50 Specific Ways to Improve Your Testing – Elfriede Dustin)，因為需求是“活”的、善變的。因此在設計測試用例方面應該把敏捷的“及時響應變更比遵循計劃更有價值”這一原則。

　　不要認為測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟件開發的不同的階段都要回來重新審視和完善測試用例。

　　測試用例的評價

　　測試用例設計出來了，質量如何，如何提高測試用例設計的質量?就像軟件產品需要通過各種手段來保證質量一樣，測試用例的質量保證也需要綜合使用各種手段和方法。

　　測試用例的檢查可以有多種方式，但是最敏捷的應當屬臨時的同行評審。我認為同行評審，尤其是臨時的同行評審，應該演變成類似結對編程一樣的方式。從而體現敏捷的“個體和交互比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設計測試用例。

　　除了同行評審，還應該盡量引入用戶參與到測試用例的設計中來，讓他們參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。這里顧客的含義比較廣泛，關鍵在于你怎樣定義測試，如果測試是對產品的批判，則顧客應該指最終用戶或顧客代表(在內部可以是市場人員或領域專家);如果測試是指對開發提供幫助和支持，那么顧客顯然就是程序員了。

　　因此，參與到測試用例設計和評審中來的人除了測試人員自己和管理層外，還應該包括最終用戶或顧客代表，還有開發人員。

　　測試用例數據生成的自動化

　　在測試用例設計方面最有希望實現自動化的，要當屬測試用例數據生成的自動化了。因為設計方面的自動化在可想象的將來估計都很難實現，但是數據則不同，數據的組合、數據的過濾篩選、大批量數據的生成等都是計算機擅長的工作。

　　很多時候，測試用例的輸入參數有不同的類型、有不同的取值范圍，我們需要得到測試用例的輸入參數的不同組合，以便全面地覆蓋各種可能的取值情況。但是全覆蓋的值域可能會不可思議地廣泛，我們又需要科學地篩選出一些有代表性的數據，以便減輕測試的工作量。在這方面可利用正交表設計數據或成對組合法設計數據。

　　可利用一些工具，例如TConfig、PICT等來產生這些數據。

　　在性能測試、容量測試方面，除了設計好測試用例考慮如何測試外，還要準備好大量的數據。大量數據的準備可以使用多種方式：編程生成、SQL語句生成(基于數據庫的數據)、利用工具生成。

　　工具未必能生成所有滿足要求的數據，但是卻是最快速的，編程能生成所有需要的數據，但是可能是最復雜、最慢的方式。所以應該盡量考慮使用一些簡單實用的工具，例如DataFactory等。

　　seanhe ： 先拋觀點：需要寫測試用例

　　先看測試用例是什么，也就是我們打算進行的測試執行的具體內容

　　測試用例可以分級別：如大綱型、方案型、具體操作數據型，但是根本一點就是要使測試過程有序的進行，盡量少做無必要的重復。

　　敏捷宣言是什么?擁抱變化

　　擁抱變化不代表著雜亂無章，代碼即文檔，不代表著代碼沒有注釋，所有人都靠代碼去看邏輯。

　　敏捷下測試是需要規劃的，用例是需要書寫的，但是書寫的用例并不應該是我們通常意義上非常詳盡的測試用例，而可能演變成單元測試框架或者功能自動測試框架，或者測試大綱。

　　總之，測試過程是需要規劃的，在有效規劃的前提下，盡量少的做無用工作

原文轉自：http://www.uml.org.cn/Test/20112235.asp