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