按照本專欄的計劃，本來第四篇文章會以“敏捷測試工程師的績效”作為主題，但由於以上的原因，我最終還是選擇了自動化測試這個主題來談論敏捷測試。和前三篇文章相比，這一篇更像是雜感。

　　實際上，在本專欄的第二篇文章《自動化測試-敏捷測試的基石 》 中我已經就敏捷測試中的自動化測試進行了討論，並給出了一些我認為合適的自動化測試測試策略和方法。為什麼我們還需要用一篇文章來討論自動化測試？ 自動化測試的具體做法肯定不止一種，自動化測試的技術和方法更是多如過江之鯽，但當我們談論到自動化測試時，我們想傳達的是究竟什麼資訊？

　　Cockburn在《敏捷軟體開發》中提到“溝通的成功依賴於傳送者和接收者有可以引用的共同體驗”，因此當我們提到自動化測試時，就一定需要有共同的詞彙表。首先，什麼是自動化測試？對一些人來說，一提到自動化測試，第一個閃過腦海的念頭就是QTP

、 WebDriver等自動化測試工具，以及依據這些工具建立的針對功能或是UI的自動化測試測試指令碼，但其實這些只是自動化測試中的一小部分而已，在我看 來，所有“使用機器的能力”對測試進行部分或全部自動化的操作都應該被叫做“自動化測試”。無論是針對程式碼中的類或是方法建立的單元測試 ， 還是針對產品建立的需要人工參與的diff的方式，都是自動化測試的具體方法。對測試來說，自動化測試不是一個存在的目標，而僅僅是一種用以達成測試目標 的手段。我們希望從自動化測試中得到什麼？自動化測試覆蓋率？自動化測試覆蓋率是用來衡量自動化測試所佔比例的一種手段，但這仍然不是我們在專案中開展自 動化測試的目標。我們在專案中開展自動化測試，目標只能是“通過自動化測試提高測試或是產品的質量”。因此，在談論自動化測試時，可以被稱為目標的，只能 是下面這幾項：

　　1、在保證相同的測試覆蓋率的情況下，減少人力資源的投入；

　　2、在相同人力資源投入的情況下，增加了測試覆蓋率；

　　3、讓測試的執行向上遊移動，幫助開發者更早的發現產品中的問題，從而降低修復成本。

　　有了目標，剩下來的就是怎麼做的問題。“減少人力資源的投入”是一個最容易被直觀理解的自動化測試目標，因此，不少團隊的做法就是“用自動化測試替代手工測試”，將原先需要手工執行的測試用例 變 成UI自動化測試用例，改由自動化測試工具來執行指令碼。不能說，這種方式沒有效果，但由於自動化測試在識別缺陷方面的有效性遠遠低於手工測試（從UI測試 的角度來說，一個非“預期”產生的缺陷很難被自動化測試發現，而手工測試則能輕鬆的發現這個缺陷），而且由於UI本身的變化性，要想達到和手工測試相同的 覆蓋率，單純的UI自動化測試往往很難證明自己的投資回報。

　　“增加測試覆蓋率”是自動化測試可以產生收益的另一個方面。容易想到的例子是效能測試 和 模糊測試（Fuzz testing）。依靠機器的能力，模擬大量使用者的併發，以及依靠機器的能力，基於規則產生大量隨機資料併發送給伺服器，用於檢測伺服器可能的安全性問 題，在這些領域，自動化測試能帶來明顯的收益。但，當我說到“增加測試覆蓋率”時，我所想要談論的不僅僅是效能測試或是模糊測試這一類的針對應用某個質量 屬性的驗證。在說到“覆蓋率”時，我腦海中的另一個場景是“通過自動化測試覆蓋應用中更多的介面和服務”——也就是說，通過自動化測試的方式覆蓋那些在 UI和功能測試 無 法或很難達到的部分。這一類的自動化測試可以與整合測試中的測試方式和方法進行類比，關注的是對子系統或是模組之間介面的驗證。但作為自動化測試來說，關 注的不僅僅是建立對介面和服務的驗證指令碼，往往還需要通過推動介面和服務設計的合理性，使得建立儘可能多和儘可能完善的介面/服務的自動化測試成為可能。 假設我們要對某web 應 用的Frontend進行介面/服務級別的自動化測試，顯然，在這個Frontend應用中存在很多介面和可以被解耦的服務。如果Frontend採用了 類似Clearsilver+Java的開發方式，從理論上來說，這裡存在一個天然的接縫：Clearsilver作為“模板系統”，提供的主要是展現頁 面的能力；Java程式碼則主要是業務邏輯實現；Java程式碼通過填充模板中的動態資料項來生成使用者所能看到的頁面。在這種模式下，如果能夠推動應用具有良 好的分層設計，使得Clearsilver端完全不包含邏輯實現，而且可以通過某種方式直接訪問邏輯部分（Java程式碼）生成的所有動態資料，那麼，在自 動化測試中就可以考慮採用完全不同的方式驗證模板部分和Java程式碼部分：用瀏覽器展現填充了資料的模板，基於圖片比較的方式進行測試和diff；用資料 驗證或是diff的方式驗證Java邏輯實現的正確性。通過這種方式，就能夠為應用建立更多層次的驗證和測試。這部分的自動化測試設計與實施通常同時伴隨 著可測試性設計。尋找應用中可能的測試點，改善應用的可測試性，進而為應用建立更多的不同測試的自動化測試，這就是“增加測試覆蓋率”的一般方式。

  　“推動測試到上游”指的是將測試的執行推動到開發和設計階段。持續整合就是一種“在上游執行測試”的方法，這種方法用定期（以天或小時為單位）的 方式或是程式碼提交觸發的方式對提交的程式碼進行驗證，能夠及時地向開發工程師提供程式碼質量反饋。這種方式可以保證儘早發現缺陷，且由於測試的執行者和修正者 是同一個人，可以極大減少溝通帶來的開銷。在我看來，類似於持續整合的方式是自動化測試能帶來最大收益的做法。但要想將測試推動到上游，並非建立一個持續 整合框架都足夠，如果開發工程師需要花費巨大的精力來建立、執行和維護測試，顯而易見，他們是不會接受這種“在上游執行測試”的理念的。Android和 iPhone都提供了自動化測試框架（Android上的Instrumentation和iOS上的UI Automation），理論上來說，開發工程師可以完全自己來建立、執行和維護針對自己應用的自動化測試。但如果考察下開發工程師在執行這些測試時的成 本，就會發現，由開發工程師自行維護Android和iPhone上應用的自動化測試，實在是很難被開發工程師接受。以iOS上的自動化測試為例，如果開 發工程師想要在真實的裝置上執行測試，他/她必須首先找到一臺iPhone裝置並連線到自己的機器，編譯好需要被測試的應用，用iTunes將需要被測試 的應用同步到iPhone裝置，然後開啟UI Automation的IDE環境，載入測試指令碼，執行測試，人工檢查測試結果是否正確——我敢打賭，除非是獨立開發者，否則沒有哪個開發工程師能堅持用 這種方式執行自動化測試超過一週的時間，開發工程師一定會像扔掉燙手的山芋一樣把這個工作扔給測試團隊。那，怎麼樣才能在這種情況下把測試推動到上游？這 裡的主要瓶頸在於測試執行的消耗太大，如果能夠建立一個移動裝置的實驗室，將iPhone和Android的測試執行統一為一個命令列，只要指定了被測試 應用的binary、需要執行測試的裝置、需要執行的測試指令碼、結果存放的地方，就可以通過這個命令列直接告訴開發工程師測試的執行結果——在這種情況 下，與自動化測試的維護和建立成本相比，自動化帶來的收益要遠遠高於投入（能夠得到立即的反饋，能夠重複不斷的快速執行測試）。“將測試推動到上游”並不 是具體的自動化測試技術，但卻是非常值得嘗試的自動化測試方向。在上面的iPhone和Android測試的例子中，“建立可以讓測試執行成本降低的自動 化測試執行環境”在這種狀況下是“將測試推動到上游”的最佳選擇，在其他情況下可能需要解決的是其他的問題。不管怎麼說，秉承“將測試推動到上游”的觀 點，並通過自動化測試創造推動到上游的可能性，在我看來，是自動化測試的一個可以持續帶來收益的途徑。

　　自動化測試不是萬能的，但沒有自動化測試是萬萬不能的。和金錢一樣，自動化測試不可或缺，越多越好，但也不能期望用自動化測試解決掉所有的問 題。什麼問題不適合用自動化解決呢？自動化測試技術是依靠機器的能力進行測試執行和驗證，因此，凡是不適合使用機器執行和驗證的都不適合使用自動化測試技 術：例如，某些需要人工體驗的操作，對音視訊的流暢性的判斷等等；另外，從收益上來說，還沒有穩定下來的需求和UI，不適合對其進行自動化測試；又或者， 在敏捷開發的環境下，測試者需要通過使用軟體和探索軟體等方式對每個迭代的新功能進行探索和學習。在這些情況下，我們通常需要依賴於手工測試的手段，使用 探索性測試等技術幫助我們瞭解應用、在指令碼之外發現應用中的缺陷、以及填補自動化測試無法達到的空缺。

　　該在什麼地方進行自動化測試？一個簡單的幫助你決定是否要在某個地方引入自動化測試的判斷方法是：

　　1、從技術上來說，這裡可能被自動化嗎？

　　2、如果引入自動化測試，能帶來收益嗎？

　　如果兩個答案都是yes，那就毫不猶豫的開始你的自動化吧。