軟件敏捷測試是否寫測試用例
敏捷測試是否寫測試用例？答案多種化如果是你，你會選用寫還是不用寫呢？
軟件測試時代風起云涌，問題雖小，意義卻大，讓大家一起學習一起探討！
經過大家的水深火熱的探討答案出來了，但是各有各的想法各有各的不同，但我想他們的所想和所論對于大家都是有幫助的，大家可以看一下這個討論題，希望在技術上能幫到大家一些。
LoveTT ： 我覺得敏捷測試不需要寫測試用例；
所謂敏捷，就是要快準狠，快速的找到系統中存在的問題，高效率的完成測試任務！
誰來跟我辯論？
傲氣凌云 ： 我認為需要寫，因為所有的用例都是人類靠思維來編寫的，不是憑空出現的。就算是敏捷性測試，也是需要記錄的。
tigerbbs ： 在敏捷開發中，測試管理者不可能像傳統的項目測試一樣制定詳細的測試計劃，那怎樣執行測試呢？以下是我總結的一些瑣碎經驗： 在敏捷開發中整個團隊都是測試人員，一起需要對產品質量負責，測試管理人員需要指引大家共同測試，需要發動起大家一起執行測試，而不僅僅是測試人員的事情，這同時也要求整個團隊中每個成員對自己的產品了如指掌，測試人員需要共同參與產品的設計和需求分析，在敏捷開發中需求在不斷變化，你不可能等著完整的需求文檔進行測試需求分析，當產品定義和需求不斷的細化時，測試分析也要不斷的細化，我很喜歡讓測試人員去繪制業務流程圖，以及整理功能列表進行測試分析，因為在繪制業務流程圖中你可以發現很多的邏輯問題，和產品定義問題，可以即時的和產品定義人員、需求人員進行溝通，立馬改進產品設計，敏捷測試中，根據業務流程圖或測試分析圖書寫主要測試用例就行了，你根本就沒有時間能面面俱到去維護那么的測試用例，更何況需求和產品定義一直在變化一定要自動化測試，自動化測試腳本中要寫好注釋，這是測試用例的體現，也便于讀取在測試之前制定好測試方案，但測試執行的時間很難控制，一定要熟知數據庫。
LoveTT ： 樓上的傲氣凌云 有點狡辯了，混淆視聽，人類的精髓很多，馬克思主義毛澤東思想，都是人類的精華，但是這些老前輩都還說，具體問題具體分析呢，而你一概而論，我覺得站不住腳！我覺得閣下還是好好看看什么是敏捷開發，和敏捷測試再來發表見解吧！否則貽笑大方就不好了！
test110 ： 肯定得寫哈，那是測試的依據。
敏捷宣言：
個體和交互比過程和工具更有價值；
能工作的軟件比全面的文檔更有價值；
顧客的協作比合同談判更有價值；
及時響應變更比遵循計劃更有價值。
并非每個企業都能嚴格按敏捷的相關開發方法進行項目管理，例如測試驅動、XP、SCRUM等。也并非都需要按這些方式管理才能實現敏捷。只要我們理解了敏捷的原則和精髓，我認為很多方法、很多地方都可以應用敏捷的思想，實現敏捷的管理。
測試用例的設計是其中一項。
測試用例的粒度
測試用例可以寫得很簡單，也可以寫得很復雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試（Exploratory Testing）中的測試設計，僅會指出需要測試產品的哪些要素、需要達到的質量目標、需要使用的測試方法等。而最復雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項數據，期待的結果及檢驗的方法，具體到界面元素的操作步驟，指定測試的方法和工具等等。
測試用例寫得過于復雜或過于詳細，會帶來兩個問題：一個是效率問題，一個是維護成本問題。另外，測試用例設計得過于詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。
測試用例寫得過于簡單，則可能失去了測試用例的意義。過于簡單的測試用例設計其實并沒有進行“設計”，只是把需要測試的功能模塊記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，并把對軟件系統的測試方法的思路記錄下來，以便指導將來的測試。
大多數測試團隊編寫的測試用例的粒度介于兩者之間。而如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。我們應該根據項目的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。
軟件是開發人員需要去努力實現敏捷化的對象，而測試用例則是測試人員需要去努力實現敏捷化的對象。要想在測試用例的設計方面應用“能工作的軟件比全面的文檔更有價值”這一敏捷原則，則關鍵是考慮怎樣使設計出來的測試用例是能有效工作的。
基于需求的測試用例設計
基于需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。
要把測試用例當成“活”的文檔（Effective Software Testing ： 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因為需求是“活”的、善變的。因此在設計測試用例方面應該把敏捷的“及時響應變更比遵循計劃更有價值”這一原則。
不要認為測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟件開發的不同的階段都要回來重新審視和完善測試用例。
測試用例的評價
測試用例設計出來了，質量如何，如何提高測試用例設計的質量？就像軟件產品需要通過各種手段來保證質量一樣，測試用例的質量保證也需要綜合使用各種手段和方法。
測試用例的檢查可以有多種方式，但是最敏捷的應當屬臨時的同行評審。我認為同行評審，尤其是臨時的同行評審，應該演變成類似結對編程一樣的方式。從而體現敏捷的“個體和交互比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設計測試用例。
除了同行評審，還應該盡量引入用戶參與到測試用例的設計中來，讓他們參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。這里顧客的含義比較廣泛，關鍵在于你怎樣定義測試，如果測試是對產品的批判，則顧客應該指最終用戶或顧客代表（在內部可以是市場人員或領域專家）；如果測試是指對開發提供幫助和支持，那么顧客顯然就是程序員了。
因此，參與到測試用例設計和評審中來的人除了測試人員自己和管理層外，還應該包括最終用戶或顧客代表，還有開發人員。
測試用例數據生成的自動化
在測試用例設計方面最有希望實現自動化的，要當屬測試用例數據生成的自動化了。因為設計方面的自動化在可想象的將來估計都很難實現，但是數據則不同，數據的組合、數據的過濾篩選、大批量數據的生成等都是計算機擅長的工作。
很多時候，測試用例的輸入參數有不同的類型、有不同的取值范圍，我們需要得到測試用例的輸入參數的不同組合，以便全面地覆蓋各種可能的取值情況。但是全覆蓋的值域可能會不可思議地廣泛，我們又需要科學地篩選出一些有代表性的數據，以便減輕測試的工作量。在這方面可利用正交表設計數據或成對組合法設計數據。
可利用一些工具，例如TConfig、PICT等來產生這些數據。
在性能測試、容量測試方面，除了設計好測試用例考慮如何測試外，還要準備好大量的數據。大量數據的準備可以使用多種方式：編程生成、SQL語句生成（基于數據庫的數據）、利用工具生成。
工具未必能生成所有滿足要求的數據，但是卻是最快速的，編程能生成所有需要的數據，但是可能是最復雜、最慢的方式。所以應該盡量考慮使用一些簡單實用的工具，例如DataFactory等。
seanhe ： 先拋觀點：需要寫測試用例
先看測試用例是什么，也就是我們打算進行的測試執行的具體內容
測試用例可以分級別：如大綱型、方案型、具體操作數據型，但是根本一點就是要使測試過程有序的進行，盡量少做無必要的重復。
敏捷宣言是什么？擁抱變化
擁抱變化不代表著雜亂無章，代碼即文檔，不代表著代碼沒有注釋，所有人都靠代碼去看邏輯。
敏捷下測試是需要規劃的，用例是需要書寫的，但是書寫的用例并不應該是我們通常意義上非常詳盡的測試用例，而可能演變成單元測試框架或者功能自動測試框架，或者測試大綱。
總之，測試過程是需要規劃的，在有效規劃的前提下，盡量少的做無用工作
LoveTT ： 樓上的Test110寫了很多關于測試用例設計的東西，寫道粒度問題！我不知道這些你是從哪里抄來的，但是我覺得用例這樣寫沒有問題，但是敏捷測試作為一種特殊的測試類型如”tigerbbs“所說 因為敏捷開發和測試的快捷性和多變性，導致測試的設計變得困難，或者根本就沒辦法實現”你根本就沒有時間能面面俱到去維護那么的測試用例，“正如文章中提到，所以我覺得樓上的論據站不住腳，如果說一般的測試類型，應該沒有問題的！
魅力彩虹 ： 我認為測試用例是一定要的，沒有用例怎樣做到快和準？請問LOVETT一個系統中你能記住那里測過那里沒有測過？等到新的版本出來，恐怕就會亂套了吧，何來快準狠？敏捷有從何體現？
test110 ： CASE也有簡單和復雜呀~~`針對不同的項目也可以具體考慮的，但是肯定是必須寫的
LoveTT ： 樓上的說道用例設計過程中的跟蹤，說道那些是測試了那些是沒有測試，這個我們完全可以通過功能點，或者流程圖等跟蹤方式進行跟蹤，只要我所有的需求被覆蓋被測試，就可以了！
shinnoshi ： 敏捷測試需要寫測試用例，既然是敏捷測試，就應有與其相襯的敏捷測試用例。
敏捷測試同樣需要合理的分析，快速、準確并不應建立在毫無條理的測試中。敏捷不是拋棄所有只注重效率。
test110 ： 其實我們在這里說的都是理論的，老大弄個模擬環境吧 我們實際做下就得了的 我很現實的，實踐才是真知
LoveTT ： 樓上的又在教條主義，和本本主義，你為什么說測試必須寫測試用例呢！
另外敏捷測試作為一種快速的測試方式，我們沒有必要把時間花費到用例設計的過程中，但是我們當然需要設計，但設計的不是測試用例，而是細化的需求！
test110 ： 設計case都是測試流程中的一部分的，我們平時測試項目也是按照流程去測試的，也就是說流程制約著我們去測試的，如果我們把測試流程做得很細化了的，那我們的測試就是很精確的，我們得一步一步的走，設計case必須是測試流程中的一部分
實際還有一個問題的，就是時間！我們在前期就把時間放在case的設計上的，到我們實際測試的時候就會節約很多時間的；如果你一邊測試一邊在自己大腦中設計case肯定會浪費時間的，而且還會造成自己和項目組內的人一種緊張的氣氛。 大家可以對比下的，case在前期設計和在測試過程中設計，那個更節約時間！那個 效率更高的
pi_pi ： 個人覺得不管是為了告訴領導你做了那些東東，還是自己記錄分析自己的測試思路和策略也好，暫且不管用例的簡易復雜程度有多少，這個用例肯定是需要寫的。
魅力彩虹 ： 沒有用例的測試是不可行的，首先你的測試是不是有效的驗證了需求呢？要有一個測試的執行步驟和執行數據，通過評審之后才能夠成為可行的測試。否則只是個人進行的測試怎樣判定是系統真的有缺陷還是測試的過程或測試的理解存在問題？總不能等到發現問題后再來討論測試步驟及測試數據你是否合理吧？即使可以，又怎樣能夠正確的描述出當時的操作步驟呢？
angel0527 ： 在對一個系統進行測試之前，都會去找測試點，再從測試點整理出測試用例。只是所整理用戶的簡單復雜程度不同。
如果不去整理測試用例，就沒有辦法明確是否將該進行測試的點都已經測試完。有可能會做許多重復的工作。這樣就談不上敏捷了。
shinnoshi ： 如果說沒有必要寫測試用例，其實最終想說的就是時間，寫測試用例需要時間，需要大量的時間。
其實不然，清晰的了解需求，用簡潔的語言，可以是符號語言，從代碼級出發，與開發同步，直到最終的組件完成。如果說你在開發人員寫代碼的時候都無法利用，那你所謂的時間真的很不夠。隨著開發的繼續，反復的回歸測試，如若不是記憶力超群，測試已經達到什么程度，你能給出一個準確的答案嗎？
LoveTT ： 請16樓的朋友注意，你說的一你們平常的工作，第一點，你們做的不是敏捷開發，當然你們也不是敏捷測試，你們按部就班沒有問題，但是我們今天的辯題是”敏捷測試“作為現在一個新的概念，或者一種新的方法，正在為大家研究，所以你的經驗主義不值得一提
appoint ： 測試肯定要用到測試用例。敏捷開發是靠測試來驅動開發，測試通過了開發就完成了。所以支持正方觀點
LoveTT ： 一看你就是科班出身，是做質量管理的吧！
什么事情都看得這個規矩，我覺得規矩沒有錯，但是規矩制約了發展就是錯誤了，你所謂的評審，審核，在一般的測試過程中是沒有問題的，而在敏捷測試過程中，他的測試團隊覆蓋面很廣，可以快速的識別問題并且修改問題，要是等待你的評審恐怕黃花菜都涼了！
魅力彩虹 ： 樓上LOVETT的觀點我不同意，你老說這個教條，那個是平時的工作，不是做敏捷測試。那請問一下你做過敏捷測試嗎？你的觀點依據又是什么呢？
LoveTT ： 根據我這個測試新手孜孜不倦的學習，倒是接觸過一些，記得前幾天IBM剛開了一個什么大會好像這個論壇中也有報道，我演戲了他的整個敏捷開發的過程，以及他的質量控制方法，所以我以此為依據說出上述論斷，大家要是有爭議，可以看IBM關于敏捷開發的文章
魅力彩虹 ： 評審用例不僅是規矩的問題，用例不去評審就盲目的執行，怎樣保證執行的正確性？發現了BUG怎樣反應給開發人員？有些用例你認為覆蓋了需求，你有怎樣知道自己執行的用例真正體現了需求的定義？如果根據個人臨時在大腦中想到的用例來測試系統，測試的有效性和以體現
LoveTT ： 《Agile Testing - What is it？ Can it work？》和《Agile Testing Challenges》
大家可以看一下這個兩本書！
所以我覺得敏捷測試有沒有設計測試用例，要不要評審，這個是兩個概念，樓上的跑題了
傲氣凌云 ： 但是在你工作中，你可以這么做嗎？即便是公司就你一個測試人員，也是需要編寫測試用例的。同樣，也就伴隨著評審等一系列活動。
shinnoshi ： 敏捷是少文檔，少流程，多溝通，使開發與測試更加緊密。不是不需要文檔，不需要流程，不需要測試用例。
請問你提及的測試通過，開發完畢是用什么來衡量的？
ash ： 敏捷的不是反文檔的。
測試用例最終生成也會以文檔數據方式存在，并且是顯性知識，是可以傳播、共享和繼承的。（不清楚看下面解釋）
我們應該清楚文檔的本質是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形態，顯性的和隱性的，傳統的觀念是盡量把隱性知識顯性化，即文檔化，而忽略了這其中的代價（特別是更新同步文檔的代價）。
因此，在實施敏捷的時候，需要在團隊內明確哪些知識是必須顯性的，這些知識可以通過文檔交流。哪些知識是可以隱性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。
new.bug ： 個人覺得，敏捷測試只是相對而言的，比如讓你測試一個比較復雜的系統，功能很多，那你說不用測試用例怎么比較有條理的進行測試？
文章來源于領測軟件測試網 http://www.k11sc111.com/
