在敏捷測試中如何設計用例

1.測試用例的粒度
測試用例能夠寫得很簡單，也能夠寫得很複雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試（Exploratory Testing）中的測試設計，僅會指出須要測試產品的哪些要素、須要達到的質量目標、須要使用的測試方法等。而最複雜的測試用例就像飛機維修人員使用的工做指令卡同樣，會指定輸入的每項數據，期待的結果及檢驗的方法，具體到界面元素的操做步驟，指定測試的方法和工具等等。
測試用例寫得過於複雜或過於詳細，會帶來兩個問題：一個是效率問題，一個是維護成本問題。另外，測試用例設計得過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思惟。
測試用例寫得過於簡單，則可能失去了測試用例的意義。過於簡單的測試用例設計其實並無進行「設計」，只是把須要測試的功能模塊記錄下來而已，它的做用僅僅是在測試過程當中做爲一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程當中理解需求，檢驗需求，並把對軟件系統的測試方法的思路記錄下來，以便指導未來的測試。
大多數測試團隊編寫的測試用例的粒度介於二者之間。而如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。咱們應該根據項目的實際狀況、測試資源狀況來決定設計出怎樣粒度的測試用例。
軟件是開發人員須要去努力實現敏捷化的對象，而測試用例則是測試人員須要去努力實現敏捷化的對象。要想在測試用例的設計方面應用「能工做的軟件比全面的文檔更有價值」這一敏捷原則，則關鍵是考慮怎樣使設計出來的測試用例是能有效工做的。

2。 基於需求的測試用例設計
基於需求的用例場景來設計測試用例是最直接有效的方法，由於它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。
要把測試用例當成「活」的文檔（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），由於需求是「活」的、善變的。所以在設計測試用例方面應該把敏捷的「及時響應變動比遵循計劃更有價值」這一原則。
不要認爲測試用例的設計是一個階段，測試用例的設計也須要迭代，在軟件開發的不一樣的階段都要回來從新審視和完善測試用例。

3。 測試用例的評審
測試用例設計出來了，質量如何，如何提升測試用例設計的質量？就像軟件產品須要經過各類手段來保證質量同樣，測試用例的質量保證也須要綜合使用各類手段和方法。
測試用例的檢查能夠有多種方式，可是最敏捷的應當屬臨時的同行評審。我認爲同行評審，尤爲是臨時的同行評審，應該演變成相似結對編程同樣的方式。從而體現敏捷的「個體和交互比過程和工具更有價值」，要強調測試用例設計者之間的思想碰撞，經過討論、協做來完成測試用例的設計，緣由很簡單，測試用例的目的是儘量全面地覆蓋需求，而測試人員總會存在某方面的思惟缺陷，一我的的思惟老是存在侷限性。所以須要一塊兒設計測試用例。
除了同行評審，還應該儘可能引入用戶參與到測試用例的設計中來，讓他們參與評審，從而體現敏捷的「顧客的協做比合同談判更有價值」這一原則。這裏顧客的含義比較普遍，關鍵在於你怎樣定義測試，若是測試是對產品的批判，則顧客應該指最終用戶或顧客表明（在內部能夠是市場人員或領域專家）；若是測試是指對開發提供幫助和支持，那麼顧客顯然就是程序員了。
所以，參與到測試用例設計和評審中來的人除了測試人員本身和管理層外，還應該包括最終用戶或顧客表明，還有開發人員。

4。 測試用例數據生成的自動化
在測試用例設計方面最有但願實現自動化的，要當屬測試用例數據生成的自動化了。由於設計方面的自動化在可想象的未來估計都很難實現，可是數據則不一樣，數據的組合、數據的過濾篩選、大批量數據的生成等都是計算機擅長的工做。
不少時候，測試用例的輸入參數有不一樣的類型、有不一樣的取值範圍，咱們須要獲得測試用例的輸入參數的不一樣組合，以便全面地覆蓋各類可能的取值狀況。可是全覆蓋的值域可能會難以想象地普遍，咱們又須要科學地篩選出一些有表明性的數據，以便減輕測試的工做量。在這方面可利用正交表設計數據或成對組合法設計數據。
可利用一些工具，例如TConfig、PICT等來產生這些數據。
在性能測試、容量測試方面，除了設計好測試用例考慮如何測試外，還要準備好大量的數據。大量數據的準備可使用多種方式：編程生成、SQL語句生成（基於數據庫的數據）、利用工具生成。
工具未必能生成全部知足要求的數據，可是倒是最快速的，編程能生成全部須要的數據，可是多是最複雜、最慢的方式。因此應該儘可能考慮使用一些簡單實用的工具，例如DataFactory等