1.5 使用增量方法
與很多團隊一樣，我們發現在每兩周的迭代后期都有未完成的測試任務。有時候用戶故事未完成。比如，我們從一個包含5頁向導程序的UI開始一個故事（story），其中只有4頁完成了。
有一位程序員提議用一個“強線程”（steel thread）來標識復雜故事——一個將功能點從不同終端隔離開來的小的功能點。我們為它編寫測試、寫出代碼，然后將測試自動化然后轉移到下一個線程。那樣的話，測試自動化即便在GUI層面，也能與開發保持一致。第一個自動化的測試可能會過于簡單，但可以逐步進行補充。
【小竅門】
強線程是一種保證自動化在時間里程碑內完成的方法。
這種方法很有效，對于每一個計劃的復合功能點，我們首先將線程畫在白板上，并確保在轉移到下個線程之前，當前線程的自動化測試及手動測試都已經完成了。
1.6 正確度量
如何知道我們是否取得進步了呢？如何衡量成功？我們需要一些度量。我們的構建過程會對測試進行統計，所以很容易跟蹤每一個層次的測試數量：JUnit、FitNesse斷言和測試頁面、Cannoo WebTest斷言等。
這些原始數據并不能代表整個趨勢。我們，包括業務經理，都希望看到這些數字在每次迭代中都在增長。在每一次迭代中，指定一份染色的日歷——如果某天所有的回歸測試至少通過了一次，則將其日期標記為綠色，否則標記為紅色。業務人員也非常關注這些數據，如果他們在一行里面看到兩個標記為紅色的日期，他們會向我們詢問原因。他們也會記錄每一次迭代中JUnit、FitNesse和Canoo WebTest的測試數量。當測試數量減少時，他們也會關注并詢問原因。
【真知灼見】
讓經理看到自動化測試的好處。你需要不斷“推銷”自動化的好處。
讓測試結果對外可見也是一種宣傳的形式，可在整個公司范圍內加強公眾對自動化回歸測試的了解。客戶看到測試數量增加，并且發布的功能點越來越多。所以，當我們申請時間來重構產品或者改善構建過程時，我們的客戶就能夠理解了。
我們需要快速的反饋，所以每一次構建花費的時間是一種重要的度量。如果運行JUnit測試的持續構建花費的時間超過10分鐘，就開始備份檢入信息，那么就很難找出是哪一個測試導致了失效。當JUnit構建花費的時間超過10分鐘時，我們停下來查看是什么原因導致了運行緩慢。我們重構測試、添加硬件、升級操作系統、配置測試使其并發運行等，這些都會使反饋循環更快。對運行更高級測試的構建也是這么做的。如果FitNesse測試要花好幾個小時來運行，那么反饋太慢。我們要在測試覆蓋和速度之間權衡。幸運的是，虛擬機可以同時運行多個測試套件，減少反饋周期并且非常廉價。
【小竅門】
不要使自動化停滯不前：在需要的時候進行重構、使用新的硬件、重組測試。記住我們的目標（這里指更快速的反饋），并修改自動化測試來達到我們的目標。
1.7 慶祝成功
100個JUnit測試并不是很多，但每一個測試代表了許多斷言，并且是一個值得慶祝的里程碑。當達到1000個JUnit測試時，我們覺得這值得全公司聚會慶祝一下，并為全公司的人購買了比薩。當慶祝第2000個JUnit測試時，我們組織了一個有飲料和拼盤的小型聚餐。有人曾經問過我，這些慶祝會不會鼓勵一種不好的事情：盲目增加不必要的測試數量。其實，因為每個測試都是剛好在讓其通過的那部分代碼之前編寫的，所以我們沒有進行任何無關的單元測試。如果包含測試的代碼移除了，那么測試也會移除。
當接近3000個JUint測試時，敏捷教練讓我撰寫一份說明書，談談在單元測試級別中一個健壯的回歸測試套件對業務的重要意義。我寫了一份關于TDD的高級描述報告，即它是如何幫助我們開發出健壯的、易維護的代碼，并在單元測試級別為我們提供了回歸測試覆蓋的安全網。我試圖闡明JUnit的目的：幫助設計代碼。也就是說，我們不是胡亂編寫單元測試的。敏捷教練把這份報告發給公司的每個人，并在一家本地飯店預訂了一個聚會。不僅是為了慶祝我們完成任務，而且讓所有的業務利益相關者也能體會其中的意義。
1.8 引入工程沖刺
因為我們已經花時間向業務經理解釋了測試的整個過程和實踐，所以他們了解了技術債務的觀念。每當我們為了顧及截止日期而走捷徑的時候，代碼就變得很難處理。如果我們沒有時間將工具升級到最新版本，或者沒有時間嘗試能讓我們更高效地工作的最新軟件，我們的速度就會下降。這就好比如果我們拖欠信用卡債務，利率就會上升，我們所欠的債務就越來越多。如果我們被技術債務纏身，就無法以客戶期待的速率來發布大量的軟件。
所以，我們每6個月會進行一次特別的迭代，稱為“工程沖刺”在這次迭代中不需要發布任何新的功能點（engineering sprint）。我們可以利用這段時間完成以下工作：升級到最新的Java版本、進行大型重構、嘗試新的測試工具、重構FitNesse測試來消除冗余。在一次工程沖刺中，我們將源代碼版本控制系統從CVS轉變為SVN（Subversion）。在另外一次工程沖刺中，我們將構建過程從CruiseControl轉變為Hudson，從而為縮短反饋周期提供了更多的選擇。每當在更短的時間內發布了更多更好的功能點時，業務人員就可以看到這些投資的回報。
1.9 團隊成功
我們的團隊在一年的時間內，從沒有自動化測試發展到將所有的回歸測試進行自動化。我們的自動化金字塔還不完全是理想的形狀，但是我們有了好的測試框架和在每個級別（見圖1-2）實現測試的驅動程序。盡管這樣，我們卻沒有滿足現狀，而是繼續尋找在各個級別有效地進行自動化回歸測試的方法。當我們可以控制功能測試的自動化之后，我們將著手性能測試的自動化。我們有處理不完的挑戰！
最好的是，我們有時間對每個用戶故事或功能集合進行充分的探索性測試，這樣的話，在產品中就很少會有問題浮出水面。同時自動化測試也可以幫助我們進行探索性測試。我們希望創建：使用Ruby的具有高靈活性的腳本，Watir（Ruby中的Web應用測試）測試驅動，以及測試/單元框架。它們接收運行參數，允許我們在幾秒或者幾分鐘內建立復雜的測試數據和情景，而不再需要花費時間搭建繁瑣的手動測試平臺。通過腳本可以直接對需要進行測試的部分進行測試，這樣我們就可以擁有更多的時間來深入探索軟件。
【真知灼見】
使用自動化測試來支持創新型手動測試。
我們的目標是使所有回歸測試實現自動化，但是這一目標有幾點需要說明。要達到一個合理的ROI，自動化測試在設計時必須要考慮到長期可維護性。因此要求程序員擁有好的設計技巧，可以幫助設計各個級別的自動化測試。我們不斷對測試進行重構以使維護費用較低。同時，在選擇將哪些測試保留在自動化回歸測試套件中時，團隊要有準確的判斷力，需要“正好”（good enough）覆蓋。測試太多意味著反饋周期太長和維護費用過高。同時，我們還有少量的遺留代碼沒有被自動化測試覆蓋，當我們進行可能對遺留代碼造成影響的大范圍的代碼重構時，我們要留一些時間進行手動回歸測試。
圖1-2 自動測試金字塔使用的工具
我們成功的關鍵是采用“完整團隊”（whole-team）的方法,團隊里的每個人都致力于將所有回歸測試實現自動化，我們有很多的技術和觀點來幫助解決自動化中遇到的問題。自動化測試金字塔的每一層都包含不同的工具，而且大家可以關注不同層。開發人員像寫代碼那樣編寫單元測試用例，測試人員更多的是進行GUI測試的自動化，在FitNesse中，雙方在中間層合作。然而，在每一個用戶故事完成之前，團隊中的每個人都負責每個用戶故事的所有測試活動。
自動化測試給我們一個快速的反饋周期。如果在幾小時內任何一個現有的功能點遭到破壞，在工程沖刺時，我們應該騰出時間來做出改變，使加入更多測試用例后的反饋周期仍然很快。我們知道是代碼的哪些改變引起的這個問題，并立刻進行修復。我們可以在經常發布新業務價值的同時，達到公司的要求，開發出最高質量的產品。
1.10 持續改進
2011年是我們自動化測試之旅的第8年，總是要面臨新的挑戰。正如本章所述，我們的GUI測試套件已經增長到需要2個多小時來運行。這個時間太長了，所以我們將它劃分為兩個測試套件，并在兩個從屬機器上并行運行。這需要進行大量的工作，因為有些測試依賴于其他測試，過去沒有好好實施而是采取了折中的方法，現在要為此付出代價。我們有超過5400（這個數字還在增長）個JUnit，并且重構的FitNesse測試套件在30分鐘內完成。
我們知道在單元級別中的測試覆蓋率，但是并不知道在功能性或GUI級別的測試覆蓋率。我們目前采用一個的工具進行實驗，可以測量出FitNesse測試的代碼覆蓋率。
相比于8年前，我們現在對自動化測試設計有了更深入的了解，并且我們的測試需要大規模的重構。無論何時，當加入一個測試用例或者對其進行修改的時候，我們都嘗試去改善測試，但是只在工程沖刺階段才進行大規模重構。我們通過一些開源工具進行觀測，并不斷嘗試我們認為可以降低測試維護費用或者提供更快反饋的新工具。
在GUI測試中我們也是這么做的。幾年前，當我們發現Canoo WebTest并不能很好地支持JavaScript的時候，就在所有回歸測試中開始使用Watir編寫新的功能點。約一年之后，Canoo WebTest升級到比那時的Watir可以更好地處理JavaScript和Ajax，而Watir更難與構建過程整合，所以在保留現有的Watir回歸測試腳本的基礎上，我們又切換回WebTest。
我們也進行了調查，準備使用Slim來替代Fit進行我們的FitNesse測試。同樣，我們可能不會立刻把所有FitNesse測試轉為Slim，但我們同時發現維護多種工具也沒有很大問題。
這些年來，我們的員工相當穩定。一位新程序員和一位測試人員來了又走，但是團隊的核心成員一直保留著。我認為這是因為優秀的人才樂意留在他們可以盡最大努力工作的地方，那就是我們團隊。比如，我們允許他們做類似自動化回歸測試的事情。我們有一些有趣的轉變，一位測試人員決定成為一位程序員，所以他參加了一些Java課程的培訓，另一位程序員跟他一起合作，他的學習速度非常快。同時，他仍然保留了自己在測試方面的興趣，尤其在性能測試方面。另一位程序員一直都無法采用TDD方法，盡管經過了大量的指導和培訓，因為他的代碼始終沒有達到標準，最終只好讓他離開。我們從不會去刻意填補空缺職位，但我們的團隊效率卻在提高。每一個團隊都需要恰當的人選，而且那些人需要時間來學習、實驗和提高。
1.11 總結
你的團隊如何？阻礙你進行自動化測試嘗試的最大問題是什么？你的團隊是否缺乏一個特殊的技能組合？你是否只是需要時間來制定和實施策略？你是否還在等待合適的硬件或者軟件？想想你現在能做一些什么事情來提高自動化測試并縮短反饋周期。要有耐心，一步步慢慢來。對你得到的結果進行試驗和分析評估，不斷進行哪怕只是很小的改進。不知不覺間，你就會享受自動化測試的好處。
（未完待續...）
相關鏈接：
自動化測試最佳實踐 連載一
自動化測試最佳實踐 連載二
自動化測試最佳實踐 連載三