首先抽象地描述一下項目背景，這個項目是一個面向消費者的Web系統（以下簡稱系統A）。用戶訪問系統A，輸入數據，系統A 接收數據，然后調用系統B 的REST接口返回處理過的數據給用戶。其中系統B 是由另一個團隊開發和維護的。描述地夠抽象的吧，不過你可以想象，比如一個電商網站。
該項目采用Java，框架是Spring，構建工具是Maven，技術不算很新啦。
好了，要說到自動化測試，肯定得先說說我們是如何按照需求進行開發的。
首先，我們不是按照一份全面的12頁的需求說明文檔來開發，那樣的話，無休止的前期的設計討論會、數據庫設計、代碼框架設計、架構討論會，再加上編碼和測試的時間，等全部功能都開發出來都已經是一個月以后了。對我們這個面向消費者的互聯網應用來說，一個月太長了。等到一個月以后，這些一個月以前收集的需求和實現的功能，對消費者還有沒有價值，都不一定呢。
我們的工作是價值拉動的，所以我們要快速響應變化，我們的哲學是：“先把應用跑起來，完成一小部分可以使用的業務功能，看看反饋再說”。
所以我們按照故事點來劃分需求，比如這三天我們就開發”登錄功能“，這里面包括頁面的登錄框，頁面JS校驗，后臺邏輯校驗，數據庫表字段調整，調用系統B 的驗證接口等。這樣，三天以后，團隊就能給產品經理/Boss演示“登錄功能”，接受產品經理/Boss的反饋，并在第四天就開始改進，第五天就可以再給產品經理/Boss演示改進后的“登錄功能”了。
而不像傳統的軟件開發方式，團隊跟產品經理/Boss說，“一個月以后你才能看到全部功能中的登錄功能，到時候你要是不滿意，走需求變更流程，需要再等一個月！”。
那么，這個“登錄功能”包括頁面的登錄框，頁面JS校驗，后臺邏輯校驗，數據庫表字段調整，調用系統B 的驗證接口，這些都是可以自動化驗證的。頁面的登錄框我們用Selenium驗證，JS校驗邏輯我們用Jasmine驗證，后臺邏輯校驗我們用JUnit驗證，數據庫表字段調整，我們用DBUnit驗證，調用系統B 的接口，我們用Mockito來mock接口調用驗證。
當開發人員對測試人員說，我們已經開發完成了“登錄功能”，測試人員會問，“如何證明你們已經開發完成了登錄功能？給我看下你們的自動化測試代碼！”
是的，只有通過自動化測試的代碼，才能證明功能是正確開發完成的。因為如果沒有這些自動化測試，兩個星期之后，代碼被多處修改，當時寫的代碼還能不能工作，都不一定呢。
沒錯，這些自動化測試代碼都是開發人員寫的。我們的哲學是：“You build it， You test it！”
看到這里，你可能會問，Selenium 驗證，Jasmine 驗證，JUnit驗證， DBUnit和 Mockito 驗證，寫了這么多的自動化測試代碼，該怎么運行呢？
沒問題，我們的構建工具是用的Maven嘛，這些測試都有對應的Maven插件，我們把這些測試都集成到了Maven的構建腳本里，這樣，在本地命令行，僅僅運行 “mvn clean install” 就能挨個運行這些測試了，當運行到Selenium測試時，我們的腳本還會在本地把Jetty服務器運行起來，打開本地的Firefox進行Web UI測試，運行完畢后退出Firefox，關閉Jett服務器。如果中途有測試失敗的話，腳本就會給出失敗提示。
下面是我們項目中實際的自動化測試代碼，在powershell中的運行截圖：
上圖是我們項目目前總共的532個JUnit測試運行結果。
上圖是76個Jasmine測試運行結果
那么測試人員如何做測試？
開發人員都開始寫自動化測試代碼了，那么測試人員干什么呢？
我們是這么做的，測試人員負責故事點的測試策略分析，比如“登錄功能”有一個要求是：“密碼必須包含字母和數字”。
那么測試人員會事先設計至少三個測試用例：
1）密碼全部是字母，不通過
2）密碼全部是數字，不通過
3）密碼有部分字母，部分數字，通過
當開發人員開始開發“登錄功能”時，測試人員會和他說，這里有三個測試用例，你的開發完成時，我需要看到至少三個自動化測試覆蓋這三種情況。開發人員說，沒問題。
當開發人員開發完畢，測試人員看到了這三個自動化測試用例后，測試人員說，“可以了，我再進行一些登錄的手工測試和探索性測試，你給我一個測試環境吧。”
那么開發人員如何給測試人員準備測試環境呢？
這也好辦，我們不是有持續集成服務器（以下簡稱CI）嘛，開發人員提交代碼到SVN后，CI檢測到有代碼提交，會自動運行一遍“mvn clean install”， 如果結果是Success，CI會生成一個構建號碼，比如“1292”。
開發人員會對測試人員說，“我的功能代碼對應的CI構建號是1292，你去把1292號版本發布到測試環境吧。”
這里先說明一下，我們的環境分為DEV，SYS，UAT等。這幾個環境的配置大都是一樣的，只是給不同的人使用。其中，DEV是給開發人員開發用的，SYS是給測試人員測試用的，UAT是給產品經理和BOSS演示用的。
這時候，就是自動化帶來的威力了。
如上圖，測試人員訪問CI服務器，會看到這樣的構建流水線，1292號版本已經在CI上運行通過（第一個綠色），并且被部署到DEV環境中（第二個綠色），SYS和UAT還沒有部署1292號版本（藍色）。
由于我們事先已經在CI上配置好了把代碼部署到測試環境的腳本，用Groovy寫的，所以測試人員只需要在“1292”號版本的sys環境上點擊一個按鈕（上圖中紅色框所示），就能把代碼發布到測試環境了。
上圖就是一個已經發布到測試環境的版本。我們也可以用同樣的辦法發布某個特定版本到UAT環境，隨時給BOSS做演示。
幾分鐘之后，測試人員就開始Happy地進行手工測試和探索性測試了。
新功能發布到測試環境后，如果測試人員發現功能不對，想手工驗證下當前測試環境的版本，也是可以的。只需要在瀏覽器輸入“http://應用地址/appcheck.jsp”，就能得到如下頁面，
其中的信息包括：應用的maven版本號，CI服務器（我們用的是免費的Jenkins）構建號碼，SVN提交版本號，構建時間等信息。
如果測試人員又發現了一些Bug，就會和開發人員一起嘗試著再寫一些自動化測試代碼，以此保證一些重復的驗證都由便宜又聽話的機器去做，測試人員則抽出他們寶貴的精力來關注測試策略和探索性測試。
好了，三天以后，具有自動化測試代碼的“登錄功能”OK了，產品經理/Boss看后非常滿意，說可以發布到產品環境了。
那么，我們是怎么發布到產品環境，我們的上線流程是怎么樣的呢？
還有和系統B 的聯調，我們是怎么做的呢？
未完待續，敬請期待。。。