seanhe : MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">先拋觀點：需要寫測試用例
先看測試用例是什么，也就是我們打算進行的測試執行的具體內容
測試用例可以分級別：如大綱型、方案型、具體操作數據型，但是根本一點就是要使測試過程有序的進行，盡量少做無必要的重復。
敏捷宣言是什么？擁抱變化
擁抱變化不代表著雜亂無章，代碼即文檔，不代表著代碼沒有注釋，所有人都靠代碼去看邏輯。
敏捷下測試是需要規劃的，用例是需要書寫的，但是書寫的用例并不應該是我們通常意義上非常詳盡的測試用例，而可能演變成單元測試框架或者功能自動測試框架，或者測試大綱。
總之，測試過程是需要規劃的，在有效規劃的前提下，盡量少的做無用工作
LoveTT : 樓上的Test110寫了很多關于測試用例設計的東西，寫道粒度問題！我不知道這些你是從哪里抄來的，但是我覺得用例這樣寫沒有問題，但是敏捷測試作為一種特殊的測試類型如”tigerbbs“所說 因為敏捷開發和測試的快捷性和多變性，導致測試的設計變得困難，或者根本就沒辦法實現”你根本就沒有時間能面面俱到去維護那么的測試用例，“正如文章中提到，所以我覺得樓上的論據站不住腳，如果說一般的測試類型，應該沒有問題的！
魅力彩虹 : 我認為測試用例是一定要的，沒有用例怎樣做到快和準？請問LOVETT一個系統中你能記住那里測過那里沒有測過？等到新的版本出來，恐怕就會亂套了吧，何來快準狠？敏捷有從何體現？
test110 : CASE也有簡單和復雜呀~~`針對不同的項目也可以具體考慮的，但是肯定是必須寫的
LoveTT : 樓上的說道用例設計過程中的跟蹤，說道那些是測試了那些是沒有測試，這個我們完全可以通過功能點，或者流程圖等跟蹤方式進行跟蹤，只要我所有的需求被覆蓋被測試，就可以了！
shinnoshi : 敏捷測試需要寫測試用例，既然是敏捷測試，就應有與其相襯的敏捷測試用例。
敏捷測試同樣需要合理的分析，快速、準確并不應建立在毫無條理的測試中。敏捷不是拋棄所有只注重效率。
test110 : 其實我們在這里說的都是理論的，老大弄個模擬環境吧 我們實際做下就得了的 我很現實的，實踐才是真知
LoveTT : 樓上的又在教條主義，和本本主義，你為什么說測試必須寫測試用例呢！
另外敏捷測試作為一種快速的測試方式，我們沒有必要把時間花費到用例設計的過程中，但是我們當然需要設計，但設計的不是測試用例，而是細化的需求！
test110 : 設計case都是測試流程中的一部分的，我們平時測試項目也是按照流程去測試的，也就是說流程制約著我們去測試的，如果我們把測試流程做得很細化了的，那我們的測試就是很精確的，我們得一步一步的走，設計case必須是測試流程中的一部分
實際還有一個問題的，就是時間！我們在前期就把時間放在case的設計上的，到我們實際測試的時候就會節約很多時間的；如果你一邊測試一邊在自己大腦中設計case肯定會浪費時間的，而且還會造成自己和項目組內的人一種緊張的氣氛。 大家可以對比下的，case在前期設計和在測試過程中設計，那個更節約時間！那個 效率更高的
pi_pi : 個人覺得不管是為了告訴領導你做了那些東東，還是自己記錄分析自己的測試思路和策略也好，暫且不管用例的簡易復雜程度有多少，這個用例肯定是需要寫的。
魅力彩虹 : 沒有用例的測試是不可行的，首先你的測試是不是有效的驗證了需求呢？要有一個測試的執行步驟和執行數據，通過評審之后才能夠成為可行的測試。否則只是個人進行的測試怎樣判定是系統真的有缺陷還是測試的過程或測試的理解存在問題？總不能等到發現問題后再來討論測試步驟及測試數據你是否合理吧？即使可以，又怎樣能夠正確的描述出當時的操作步驟呢？
angel0527 : 在對一個系統進行測試之前，都會去找測試點，再從測試點整理出測試用例。只是所整理用戶的簡單復雜程度不同。
如果不去整理測試用例，就沒有辦法明確是否將該進行測試的點都已經測試完。有可能會做許多重復的工作。這樣就談不上敏捷了。
shinnoshi : 如果說沒有必要寫測試用例，其實最終想說的就是時間，寫測試用例需要時間，需要大量的時間。
其實不然，清晰的了解需求，用簡潔的語言，可以是符號語言，從代碼級出發，與開發同步，直到最終的組件完成。如果說你在開發人員寫代碼的時候都無法利用，那你所謂的時間真的很不夠。隨著開發的繼續，反復的回歸測試，如若不是記憶力超群，測試已經達到什么程度，你能給出一個準確的答案嗎？
LoveTT : 請16樓的朋友注意，你說的一你們平常的工作，第一點，你們做的不是敏捷開發，當然你們也不是敏捷測試，你們按部就班沒有問題，但是我們今天的辯題是”敏捷測試“作為現在一個新的概念，或者一種新的方法，正在為大家研究，所以你的經驗主義不值得一提
appoint : 測試肯定要用到測試用例。敏捷開發是靠測試來驅動開發，測試通過了開發就完成了。所以支持正方觀點
LoveTT : to魅力彩虹
一看你就是科班出身，是做質量管理的吧！
什么事情都看得這個規矩，我覺得規矩沒有錯，但是規矩制約了發展就是錯誤了，你所謂的評審，審核，在一般的測試過程中是沒有問題的，而在敏捷測試過程中，他的測試團隊覆蓋面很廣，可以快速的識別問題并且修改問題，要是等待你的評審恐怕黃花菜都涼了！
魅力彩虹 : 樓上LOVETT的觀點我不同意，你老說這個教條，那個是平時的工作，不是做敏捷測試。那請問一下你做過敏捷測試嗎？你的觀點依據又是什么呢？
LoveTT : 根據我這個測試新手孜孜不倦的學習，倒是接觸過一些，記得前幾天IBM剛開了一個什么大會好像這個論壇中也有報道，我演戲了他的整個敏捷開發的過程，以及他的質量控制方法，所以我以此為依據說出上述論斷，大家要是有爭議，可以看IBM關于敏捷開發的文章
魅力彩虹 : TO LOVETT
評審用例不僅是規矩的問題，用例不去評審就盲目的執行，怎樣保證執行的正確性？發現了BUG怎樣反應給開發人員？有些用例你認為覆蓋了需求，你有怎樣知道自己執行的用例真正體現了需求的定義？如果根據個人臨時在大腦中想到的用例來測試系統，測試的有效性和以體現
LoveTT : 《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》
大家可以看一下這個兩本書！
所以我覺得敏捷測試有沒有設計測試用例，要不要評審，這個是兩個概念，樓上的跑題了
大家可以看一下，以前本論壇的一個版主的博客關于敏捷測試的文章：
http://blog.csdn.net/Testing_is_believing/category/333219.aspx
傲氣凌云 : 34# LoveTT
但是在你工作中，你可以這么做嗎？即便是公司就你一個測試人員，也是需要編寫測試用例的。同樣，也就伴隨著評審等一系列活動。
shinnoshi : 敏捷是少文檔，少流程，多溝通，使開發與測試更加緊密。不是不需要文檔，不需要流程，不需要測試用例。
請問你提及的測試通過，開發完畢是用什么來衡量的？
ash : 敏捷的不是反文檔的。
測試用例最終生成也會以文檔數據方式存在，并且是顯性知識，是可以傳播、共享和繼承的。（不清楚看下面解釋）
我們應該清楚文檔的本質是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形態，顯性的和隱性的，傳統的觀念是盡量把隱性知識顯性化，即文檔化，而忽略了這其中的代價（特別是更新同步文檔的代價）。
因此，在實施敏捷的時候，需要在團隊內明確哪些知識是必須顯性的，這些知識可以通過文檔交流。哪些知識是可以隱性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。
new.bug : 個人覺得，敏捷測試只是相對而言的，比如讓你測試一個比較復雜的系統，功能很多，那你說不用測試用例怎么比較有條理的進行測試？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
