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

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

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

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

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

　　可利用一些工具，例如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樓的朋友注意，你說的一你們平常的工作，第一點，你們做的不是敏捷開發，當然你們也不是敏捷測試，你們按部就班沒有問題，但是我們今天的辯題是”敏捷測試“作為現在一個新的概念，或者一種新的方法，正在為大家研究，所以你的經驗主義不值得一提

原文轉自：http://www.anti-gravitydesign.com