在敏捷實踐中，“測試”毫無疑問地是一個經常談論的話題。然而，它也是經常被過分談論的術語，所以，當我們想討論“測試的種類”時，應該先了解一些細節。
在敏捷開發中，測試以很多不同的方法扮演着同樣的角色，而且不同的測試種類扮演着不同的角色。爲了說明這些角色，你需要敏捷開發中一些基本思想作爲基礎。
爲什麼要測試？
測試是得到反饋的一個重要方法。測試對於確保代碼做了它應該做的事是非常有用的，對於代碼的修改反過來可以影響功能也是很有用的。測試也是開發人員知道什麼時候算完成他所開發的一個特性。現在，我們有兩個原則作爲判斷一個特性是否被描述的足夠詳細：
1、開發人員可以提供一個相當準確的估計
2、測試人員可以寫出一個接受性測試
不但測試種類有所不同，產生測試的方法也不盡相同。
我們如何測試？
測試包括手工測試和自動化測試。關鍵要注意在開發過程中，每種技術所扮演的不同角色。儘管我們需要儘可能多地進行自動化測試，但並不意味着所有的手工測試就不再需要啦。因爲即使軟件通過了所有的自動化測試，它在用戶剛開始使用時也可能出現錯誤。
根據敏捷原則（做聰明的事），要確保能用自動化測試的事情決不要用手工測試。同時要做到適合手工測試的內容決不要花高昂地成本做成自動化測試。另外，不要因爲某方面不能自動化測試而不做測試。
你應該做哪些種類的測試？
我想，沒有“放之四海皆準”的策略。象敏捷開發中的每個事情一樣，測試也需要你用你的大腦！下面有一些測試的種類及它們在開發過程中扮演的角色，或者說是目的。
單元測試：一般是開發者在編寫他們被分派的特性時建立的。目的是確保代碼所完成的功能在任何變化時都是正確的。另外，單元測試的一個附加作用就是當作軟件API的使用說明文檔。
驗收測試（或叫接受性測試）：用於確保具體的功能是否正常工作。特別地，驗收測試是一個具體的客戶場景，用於完成用戶所期望的功能。
UI測試：一般包括一些頁面流，提供已知輸入並把得到的結果和期望的結果進行對照。有些UI測試是使用bitmap進行對比。
可用性測試：這可以說是另一個領域的測試，它常常需要人的參與！在這裏不多陳述，但是可用性經常是做爲“make-or-break”的驗收條件。某些項目從自動化測試中得到了收益，這些自動化測試確保軟件遵守了UI標準。
性能測試：對於很多應用來說，運行一套測試來確保多個非功能度量要求得到滿足是非常關鍵的。如果你的應用需要很嚴格的性能度量要求，在初始的架構和設計階段，你需要跟蹤這些要求是否滿足。在構建整個應用時，你要確保性能要求得到滿足。通常，性能測試至少要在每個主構建時自動運行－也許你每星期五做一次或每次迭代做一次。
什麼樣的測試技術是有用的？
雖然自動化是一個關鍵，但它並不是唯一的一種測試！我更願意使用手工與自動化相結合的測試。你可以自己定義自動化測試的頻率的執行時間。 下面是幾種不同類型的測試以及在敏捷項目中扮演的角色！
“Smoke”測試：不可缺少的一小撮關鍵測試，用於確保基本的構建功能正常運行。其中一部分是自動化的，還有一些是手工的。運行“smoke”測試很容易的話，可以幫助開發團隊瞭解每日構建是有用的。當需要一些手工測試時（一般來說成本比較昂貴），應該把它放在主構建中，也就是有質量保證人員參與的較爲正試的構建。要避免做代價很大而沒有太多意義的“bad”構建。
Test Harness: 對於粗粒度的功能（特別是對於驗收測試和主要的系統場景）進行制度化地測試來說，TestHarness常常是一個好方法。將一個TestHarness作爲新的功能加入到原有的測試套裝中是很容易的。您可根據捕獲的用戶輸入、正確的輸出建立一個TestHarness並使其自動化。每個捕獲的測試用例都被加入到測試數據庫中，並與後面的迴歸測試相配合。
自動化壓力測試“機器人”：如果你做了分層式的架構設計，且各層之間較爲有清晰的界線的話，你可以構建一些自動化的測試“機器人”。此時，對於那些基礎服務的系統是非常容易地。你可以使用基於XML的配置文件來控制這些測試的運行。你可以執行鍼對某一層來建立自己的測試，並讓它重複執行（UI這一層的部分測試，使用工具也可以做到）。這些測試可以分佈在不同的地方進行。這樣也就相當於做了非常簡單的併發測試。這樣做的前提是：讓配置文件來控制測試的全過程。
手工測試：被認爲一定要用手工才能對系統的某個方面進行測試的那部分內容。讓測試人員集中精力於那些很難進行自動化測試的複雜的部分。
運行於構建服務器上的所有測試結果都應該以某種總結式的結果描述呈現出來，並可以根據需要對總結進行鑽取(drilldown)。一個好的方法就是在Wiki上使用一個特別的位置來顯示當前的構建結果。當新一輪的構建完成以後，我們還要發送email通知大家，特別是那些代碼中有錯誤的開發人員，並自動創建需要修改的Bug列表。有很多工具可以幫助我們來實現這個發佈過程。
把它們組成一體
一般來說，在開發期間，你應該一起使用手工和自動化兩種方式。
* 拿起已定義好的特性(feature)
寫接受性測試，寫代碼，寫單元測試，寫更多必須的代碼，然後讓測試通過，檢入代碼。
這個特性的性能是關鍵嗎？
寫性能測試來度量關鍵點
做進一步開發時，應確保測試通過。
* 加入關鍵點
這個特性有UI要求嗎？
可能需要一個手工測試來確保可用性，以及自動化測試無法完成的複雜功能測試
將接受性測試加入到測試套件（可以使用一個自動化工具）
如果這具特性通過了測試以及性能測試（如果有要求的話），你現在可以聲稱這個特性完成，關閉這個特性，進入下一個特性。
如果你正在使用其它的測試技術，你應該繼續使用它們。
持續改進
從一小步做起。不要剛開始就覆蓋全過程。這些測試和相關技術只要能夠隨着時間滿足你的需要就可以了。如果你發現了一些Bug，那麼應該增加新的接受性測試或單元測試，來阻止這些Bug再次發生。如果用戶抱怨系統性能問題，那麼再加入一批測試到你的性能測試套件中。這樣可以對性能問題生成非常準確的文檔，來定位問題所在，一旦開發人員修改了這些問題，用這些性能測試套件再測試一次，看一看效果就可以啦。如果一些測試不值得再去執行，註釋掉它們好啦。
問題的關鍵是：使用你的大腦！
敏捷並非只是方法！
敏捷項目中的測試大深度和方式上有各種變化，但目標不會變化！構建一組由工具、技術、過程和自動化組成的組合工作方式來正確地做那些應該做的正確的測試！
justluo:我能體會到的是：
（1）敏捷中，自動化測試和手工測試都是必需的，目標只有一個，在恰當的進度中，守護質量。在收益的權衡下，處理好兩者的關係。手工測試的成本是高昂的，自動化創建和維護的成本可能也會高昂。
（2）持續改進，靠的是大腦，不斷髮掘測試過程中的不足和可改進之處。
（3）正如文中所說，找到適合團隊和自己的恰當的測試。或許就是構建一組工具、技術、過程和自動化組成的組合工作方式。