敏捷測試用例的設(shè)計

敏捷測試用例設(shè)計敏捷宣言:個體和交互比過程和工具更有價值；能工作的軟件比全面的文檔更有價值；顧客的協(xié)作比合同談判更有價值；及時響應(yīng)變更比遵循計劃更有價值。并非每個企業(yè)都能嚴(yán)格按敏捷的相關(guān)開發(fā)方法進(jìn)行項目管理，例如測試驅(qū)動、XP、SCRUM等。也并非都需要按這些方式管理才能實現(xiàn)敏捷。只要我們理解了敏捷的原則和精髓，我認(rèn)為很多方法、很多地方都可以應(yīng)用敏捷的思想，實現(xiàn)敏捷的管理。測試用例的設(shè)計是其中一項。測試用例的粒度測試用例可以寫得很簡單，也可以寫得很復(fù)雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內(nèi)容，如探索性測試(ExploratoryTesting)中的測試設(shè)計，僅會指出需要測試產(chǎn)品的哪些要素、需要達(dá)到的質(zhì)量目標(biāo)、需要使用的測試方法等。而最復(fù)雜的測試用例就像飛機(jī)維修人員使用的工作指令卡一樣，會指定輸入的每項數(shù)據(jù)，期待的結(jié)果及檢驗的方法，具體到界面元素的操作步驟，指定測試的方法和工具等等。測試用例寫得過于復(fù)雜或過于詳細(xì)，會帶來兩個問題：一個是效率問題，一個是維護(hù)成本問題。另外，測試用例設(shè)計得過于詳細(xì)，留給測試執(zhí)行人員的思考空間就比較少，容易限制測試人員的思維。測試用例寫得過于簡單，則可能失去了測試用例的意義。過于簡單的測試用例設(shè)計其實并沒有進(jìn)行“設(shè)計”，只是把需要測試的功能模塊記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設(shè)計的本質(zhì)應(yīng)該是在設(shè)計的過程中理解需求，檢驗需求，并把對軟件系統(tǒng)的測試方法的思路記錄下來，以便指導(dǎo)將來的測試。大多數(shù)測試團(tuán)隊編寫的測試用例的粒度介于兩者之間。而如何把握好粒度是測試用例設(shè)計的關(guān)鍵，也將影響測試用例設(shè)計的效率和效果。我們應(yīng)該根據(jù)項目的實際情況、測試資源情況來決定設(shè)計出怎樣粒度的測試用例。軟件是開發(fā)人員需要去努力實現(xiàn)敏捷化的對象，而測試用例則是測試人員需要去努力實現(xiàn)敏捷化的對象。要想在測試用例的設(shè)計方面應(yīng)用“能工作的軟件比全面的文檔更有價值”這一敏捷原則，則關(guān)鍵是考慮怎樣使設(shè)計出來的測試用例是能有效工作的。基于需求的測試用例設(shè)計基于需求的用例場景來設(shè)計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。要把測試用例當(dāng)成"活"的文檔(EffectiveSoftwareTesting:50SpecificWaystoImproveYourTesting-ElfriedeDustin)，因為需求是“活"的、善變的。因此在設(shè)計測試用例方面應(yīng)該把敏捷的“及時響應(yīng)變更比遵循計劃更有價值”這一原則。不要認(rèn)為測試用例的設(shè)計是一個階段，測試用例的設(shè)計也需要迭代，在軟件開發(fā)的不同的階段都要回來重新審視和完善測試用例。測試用例的評價測試用例設(shè)計出來了，質(zhì)量如何，如何提高測試用例設(shè)計的質(zhì)量？就像軟件產(chǎn)品需要通過各種手段來保證質(zhì)量一樣，測試用例的質(zhì)量保證也需要綜合使用各種手段和方法。測試用例的檢查可以有多種方式，但是最敏捷的應(yīng)當(dāng)屬臨時的同行評審。我認(rèn)為同行評審，尤其是臨時的同行評審，應(yīng)該演變成類似結(jié)對編程一樣的方式。從而體現(xiàn)敏捷的“個體和交互比過程和工具更有價值”，要強(qiáng)調(diào)測試用例設(shè)計者之間的思想碰撞，通過討論、協(xié)作來完成測試用例的設(shè)計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設(shè)計測試用例。除了同行評審，還應(yīng)該盡量引入用戶參與到測試用例的設(shè)計中來，讓他們參與評審，從而體現(xiàn)敏捷的“顧客的協(xié)作比合同談判更有價值”這一原則。這里顧客的含義比較廣泛，關(guān)鍵在于你怎樣定義測試，如果測試是對產(chǎn)品的批判，則顧客應(yīng)該指最終用戶或顧客代表(在內(nèi)部可以是市場人員或領(lǐng)域?qū)＜?；如果測試是指對開發(fā)提供幫助和支持，那么顧客顯然就是程序員了。因此，參與到測試用例設(shè)計和評審中來的人除了測試人員自己和管理層外，還應(yīng)該包括最終用戶或顧客代表，還有開發(fā)人員。測試用例數(shù)據(jù)生成的自動化在測試用例設(shè)計方面最有希望實現(xiàn)自動化的，要當(dāng)屬測試用例數(shù)據(jù)生成的自動化了。因為設(shè)計方面的自動化在可想象的將來估計都很難實現(xiàn)，但是數(shù)據(jù)則不同，數(shù)據(jù)的組合、數(shù)據(jù)的過濾篩選、大批量數(shù)據(jù)的生成等都是計算機(jī)擅長的工作。很多時候，測試用例的輸入?yún)?shù)有不同的類型、有不同的取值范圍，我們需要得到測試用例的輸入?yún)?shù)的不同組合，以便全面地覆蓋各種可能的取值情況。但是全覆蓋的值域可能會不可思議地廣泛，我們又需要科學(xué)地篩選出一些有代表性的數(shù)據(jù)，以便減輕測試的工作量。在這方面可利用正交表設(shè)計數(shù)據(jù)或成對組合法設(shè)計數(shù)據(jù)?？衫靡恍┕ぞ撸鏣Config、PICT等來產(chǎn)生這些數(shù)據(jù)。在性能測試、容量測試方面，除了設(shè)計好測試用例考慮如何測試外，還要準(zhǔn)備好大量的數(shù)據(jù)。大量數(shù)據(jù)的準(zhǔn)備可以使用多種方式：編程生成、SQL語句生成（基于數(shù)據(jù)庫的數(shù)據(jù)）、利用工具生成。工具未必能生成所有滿足要求的數(shù)據(jù)，但是卻是最快速的，編程能生成所有需要的數(shù)據(jù)，但是可能是最復(fù)雜、最慢的方式。所以應(yīng)該盡量考慮使用一些簡單實用的工具，例如DataFactory等。測試用例設(shè)計方法與技巧測試用例對測試來說，無非是一副實際的良藥，就看測試者怎么對良藥的處方的搭配和設(shè)計。對一個項目三要素來講，時間上對測試的不允許，可能處方開的就會縮水，或者是治標(biāo)不治本（功能點沒有覆蓋到或業(yè)務(wù)測試未被測試到）以上所說的是在沒有明確的軟件需求及設(shè)計規(guī)格文檔的存在。測試用例設(shè)計方法與技巧嚴(yán)格來講，測試用例必須要根據(jù)軟件需求及設(shè)計規(guī)格進(jìn)行設(shè)計，但在實際的軟件開發(fā)過程中這兩項文件常常缺失，在這種情況下，軟件測試人員要如何設(shè)計測試用例呢？這里有兩種測試設(shè)計方法可選擇，一個就是將幾個項目列為主要模塊，然后將不同的測試用例歸納于模塊內(nèi)。

邊界測試冋卜I測試UI測試功能測試狀態(tài)測試爪力測試他諜處珂測試邊界測試冋卜I測試UI測試功能測試狀態(tài)測試爪力測試他諜處珂測試TkiCj^j.I；y十mmmLIT?tlCaseI.?RW魯IJiI^Hmxc3I皿g壯Fold丄設(shè)計方法一這種設(shè)計方法不是以軟件的設(shè)計規(guī)格作為出發(fā)點，而是將所設(shè)計的用例做歸類。進(jìn)行這樣的測試，一樣可以找出軟件錯誤，但是這樣的測試用例不易管理而且也無法提供給其他產(chǎn)品來使用。另一個方式是將產(chǎn)品依照產(chǎn)品功能特色切割成不同的模塊，然后在不同模塊下來設(shè)計測試用例。品功能模板會漢條統(tǒng)安裝期亀皿倉負(fù)"獄瓠壓力品功能模板會漢條統(tǒng)安裝期亀皿倉負(fù)"獄瓠壓力r戀苗辻凰U-1?SATfl?CTCwe2「Srfl沁、腔曲薩理■擊養(yǎng)幅爪Uti融1*?卻"機(jī)試.11捋II!tW*CW]論文收僅發(fā)衷論文集設(shè)計方法二雖然缺少軟件需求文件或軟件設(shè)計文件，我們還是可以使用自底向上的組合來組織軟件的產(chǎn)品功能模塊（如果一個軟件沒有需求那開發(fā)出來的軟件就