作為被冠以敏捷名稱的測試，敏捷測試同樣以快為目標。在敏捷測試中，快有三個方面的含義：

1. 團隊能夠通過測試快速獲知系統當前所處的狀態，了解距離可工作的軟件還有多遠；
2. 能夠在一個迭代周期中快速完成回歸測試和對新功能的測試；
3. 開發工程師能夠從持續的測試中得到快速的關于提交代碼反饋。

　　簡而言之，敏捷測試要求測試能夠測試在短的時間間隔內持續發生且能夠在短時間內完成。考慮到純粹的依賴人工測試基本不可能達到短的時間間隔內持續發生和短時間內完成這兩個目標，而自動化測試在執行效率方面具有天然的優勢，在敏捷測試中使用自動化測試技術應該是自然而然的選擇。

　　考察敏捷開發中的一個迭代周期：

1. 在迭代周期開始的時候，團隊與客戶一起定義本迭代周期內需要完成的功能；
2. 團隊建立驗收測試驗證標準；
3. 開發工程師開始實現新功能，使用TDD為產品建立安全網，使用持續集成盡可能保證每一次代碼提交不引入新的缺陷；
4. 所有新功能被添加后，在RC上運行回歸測試保證原有功能的正確性；針對新功能運行測試保證新功能的正確性；
5. 執行驗收測試驗證系統是否達到可交付的標準。

　　除1和2外，剩下的3個項目都與測試執行密切相關，如果依靠手工測試來進行這些項目，毫無疑問，測試會成為整個敏捷開發的瓶頸。而如果把這些項目中的測試建立在合適的自動化測試基礎上的話，測試就可以和開發一起敏捷起來。從這個角度來說，把自動化測試描述成敏捷測試的基石毫不夸張。

　　自動化測試并不是新鮮事物。從80年代起，對軟件自動化測試的研究就從來沒有停止過，而自動化測試工具也一直是測試工程師津津樂道的話題。IBM、HP、Borland等許多提供軟件開發解決方案的公司都擁有完整的測試解決方案；在開源社區，自動化測試工具的種類也不下于100多種。這么說起來，是不是只要選擇了合適的工具在測試中進行部署，就能快速的建立起敏捷測試需要的自動化測試基礎了呢？根據美國某組織在2005年開展的一項非正式的調查，在所有參與被調查的200多個自動化測試項目中，完全成功的只有30多個，不到20%；完全失敗的卻達到100多個，占到了50%的比例。

　　自動化測試項目為什么會失敗？根據調查，不合適的自動化測試目標與從自動化測試中無法獲得收益是項目失敗的主要原因。希望把自動化測試定義為完全替代手工操作、期望僅僅在UI層建立自動化測試都不是合適的自動化測試目標；尤其是在UI層建立自動化測試這個目標一定會帶來無法從自動化測試中獲得收益的后果。

　　UI自動化測試是自動化測試領域中較早被研究的，其主要出發點是使用工具和腳本驅動應用操作，依靠工具對UI層的元素屬性進行驗證。現有的大部分商業測試工具，如IBM Functional Tester、HP QTP等都屬于這一類工具。從好的方面來說，UI自動化測試相對其他自動化測試更接近真實用戶；但不得不說的是，UI自動化測試的高昂的投入往往是組織不能持續進行自動化測試原因。

　　我參與第一個自動化測試項目的時間是在12年前。在那些慘痛的日子里，我會痛苦地看著我苦心建立的自動化測試腳本以高達50%的失敗率運行，然后再花上2個星期更痛苦的調試和修復自動化測試腳本的時間。隨著腳本數量的增加，我的痛苦如日俱增。最后，我不得不放棄了對這些昂貴的自動化測試腳本的維護，轉向我情感上不情愿，理智上卻不得不做的選擇：重回手工測試。

　　12年前的例子并不是我唯一經歷的UI自動化測試的痛苦，實際上，在10多年的軟件測試生涯中，這樣的不愉快各種情況下一再重復。下表是前年我們的某個完全依賴于UI自動化測試項目中的自動化測試投入產出比較表。

　　UI自動化測試帶來痛苦的主要根源在于UI本身的不穩定性。由于UI是應用與用戶的直接交互界面，用戶的大量需求都直接對應在UI本身的改變上，這就導致了UI本身的不穩定，建立在UI上的自動化測試也因此不穩定。當然，除了不穩定外，UI自動化測試帶來的測試環境的需求也是導致UI自動化測試開銷劇增的原因之一；另外，UI自動化測試本身并不能很好的幫助定位缺陷，對開發工程師而言，其在反饋上的價值遠不如單元測試。

　　除了UI自動化測試外，在敏捷測試中其他可用的自動化測試還包括單元測試與接口測試（或者叫服務測試）。下圖是敏捷開發中被廣泛認可的自動化測試產出金字塔，在相同投入的情況下，單元或是代碼級測試能帶來最大的收益，而UI層面的收益最小。

　　自動化測試所涉及的技術非常多，例如在單元測試中經常需要使用到的Mock技術，基于針對不同語言而不同的解依賴技術等；在接口測試層面，更是需要根據接口本身的類型和特點確定具體的測試技術；在UI層，根據應用的不同（桌面應用，Web應用，嵌入式應用等），自動化測試技術也存在巨大的差異。

　　關于各種自動化測試技術的討論，本文在后續文章中會選擇其中的一些進行重點介紹，本文則主要介紹Diff技術這種與傳統的比較預期輸出與實際輸出略有不同的自動化測試技術。

　　Diff技術，顧名思義，其主要關心的是不同。以搜索引擎產品的測試為例：以同一個關鍵字在搜索引擎上進行多次重復測試（查詢），隨著時間段的變化，搜索引擎的索引數據也在發生變化，即使對同一個關鍵字，也不太可能在每次測試時給出一個所謂的預期結果。

　　怎樣才能在這種情況下開展測試？一種可行的技術是就是Diff技術。下圖展示了Diff方法的應用。

　　簡單來說，Diff方法的應用包括以下步驟：

1. 設置兩個待比較的版本實例（通常是相鄰的兩個版本，例如RC和上一個產品版本），兩個版本具有相同的數據基礎或后端環境；
2. 使用發送模塊同時向兩個版本發送相同請求；
3. 比較模塊收集兩個實例的輸出并對其進行比較；
4. 比較結果輸出為Diff報告。

　　Diff報告體現的是兩個實例之間的不同，不同并非一定是由于缺陷導致，因此Diff報告需要通過人工審閱，判斷報告中不一致的原因，決定后續步驟后續步驟通常包括創建一個缺陷，安排探索性測試，或是據此確定回歸測試范圍等。

　　Diff測試技術可以在多個測試層面上被應用。例如，在UI層面上，可以通過圖片Diff的方式（比較兩個版本在相同輸入情況下的UI截圖）發現應用界面上的變化；對Web應用來說，也可以以文本Diff的方法比較兩個實例輸出的HTML文檔，或是特定頁面元素；在接口層面上，可以比較在兩個實例上，相同的UI操作導致的前后端通訊的不同

　　Diff技術甚至可以在測試過程中幫助確定測試范圍。例如，對一個RC的全面的Diff發現，所有100個功能點中，有80個功能點的Diff結果與上一個版本沒有任何差異，有20個功能點的Diff結果與上一個版本存在差異。基于這個結果，我們可以很容易的將存在差異的20個功能點作為RC測試的重點個人認為，與依靠代碼分析確定測試范圍相比，這種方式直觀有效得多。

　　當然，在實際項目中應用Diff技術也會遇到很多挑戰，如何盡量消除Diff結果中的噪聲是一個關鍵問題。以應用基于圖片的Diff技術為例，如何消除圖片比較結果中的噪聲就是一個既需要技術手段（通過圖片比較算法）也需要非技術手段（建立針對每個頁面的mask）的話題。