1.3　建立自動化策略
我們需要在不破壞現有功能的前提下發布產品的新功能特性。而且，需要盡快知道一個新的代碼變動是否會引起回歸測試的失敗。手動回歸測試在每兩周的迭代后期才能給予我們反饋，以至于沒有時間進行充分的回歸測試。
我們中一些人曾經在其他敏捷團隊中進行過測試驅動開發（Test-Driven Development, TDD）。我們發現TDD能幫助創建出設計良好的、健壯的代碼。
我們現有的回歸測試是手動操作的，整個團隊通過使用團隊Wiki上所記錄的腳本進行手動測試。在每兩周的迭代周期中，這就花費了整個團隊的20%的時間。這些測試僅僅為程序最核心的部分提供了最小程度的覆蓋。產品中報告的缺陷表明，回歸測試的失敗仍有可能發生。在每次迭代周期中，我們至少要花20%的時間修復這些產品缺陷，從而限制了我們能開發的新功能的數量。
自動化的回歸測試會帶來更高、更準確的覆蓋率，這需要投入大量的時間、金錢和精力，我們可能需要硬件和軟件來建立構建過程、持續運行測試所需要的環境，我們也需要使測試實現自動化的架構和驅動。然而，我們可以計算出這一自動化將會節省我們40%的時間，利用這些時間可以進行更多有價值的活動，比如進行新的開發，所以，其收益遠大于成本。
繼續進行手動回歸測試必將會失敗，我們需要一個明確的決策來進行自動化。因為我們都在進行手動回歸測試，每個人都感受到了沒有自動化測試的痛苦。所以，我們有了解決這一問題的動力。首先，我們需要一個可測試的架構……
1.3.1　一個可測試的架構
TDD這條路是要走的，但是當前的代碼在業務邏輯、數據庫訪問和UI等處相結合時，情況比較復雜，自動化單元測試也就變得很難了。往往很難隔離任何一個組件單獨進行測試。
這樣看來，似乎找到一種把軟件進行分層的新架構是非常明智的。我們開發出了這一新架構的所有新功能。
【小竅門】
不要嘗試解決老問題，進行新的開發來開展更好的實踐。
如果進行自動化測試的成本比其收益高，那么進行自動化測試就沒什么意義。我們研究圖1-1所示的自動化測試金字塔（這一金字塔是由我們當時的經理Mike Cohn提出的）。單元級別的測試一般ROI最高。程序員可以很快寫出它們并運行，而且測試可以根據需要進行更新。因此可以將單元級別的測試作為自動化回歸測試的堅實基礎。
我們的業務邏輯相當復雜，而且新架構將這一邏輯從數據庫和用戶接口層中分離出來，這樣就可以通過設置內存中數據并在其上運行產品代碼來進行測試。這是金字塔的中間層———比底層運行的測試要少但是依然很重要。
我們還需要測試UI，但是通過UI進行的自動化測試本身就非常脆弱、維護費用高且運行緩慢。因為最終想使UI測試所占的比例盡量最小，所以它就處在金字塔的最頂端。盡管如此，與其他團隊一樣，我們從圖形用戶界面（GUI）冒煙測試（smoke test）開始，來獲取一些代碼防護。所以，從這個角度，我們的金字塔是上下顛倒的，但是沒關系———最終我們會將它翻轉過來。（我們最終花了4年時間才獲得為之努力的三角形形狀！）

【小竅門】
解決問題的最直接途徑未必是最佳途徑。
我們現在明白了我們需要做什么，所以我們開始著手實施那個能給我們帶來**最大實惠的任務。
1.3.2　建立構建過程**
我們只有4位程序員，但是他們會經常檢查源代碼控制系統中的變化。我們需要確保他們沒有不小心修改別人的內容或者破壞現有的任何功能。同時，我（測試人員）有時候不得不等待好幾天，部署在測試環境中的代碼才能完成一次構建。一個自動化的構建過程（build process）將保證在每次檢入后的幾分鐘內，最新代碼的可部署版本就是可用的。
管理層向我們強調了質量是我們的第一目標，他們樂意寬限一些時間來讓我們搭建一個好的基礎結構。
【真知灼見】
好的管理者會準許團隊花時間去開發自動化的基礎結構。
我們停下正在做的事情，使用CruiseControl和一個新的Linux服務器建立了一個持續集成（Continuous Integration, CI）過程。因為我們還沒有可以運行的任何測試實例，所以只是簡單編譯代碼和構建可部署的二進制文件。我可以看到每次構建的檢入文件并能夠選擇想部署到產品中的二進制文件。這很有用，但是還不夠。
1.3.3　獲取測試的基準：GUI冒煙測試
程序員正在學習如何使單元測試自動化并編寫測試先行（test-first）的代碼，但是要真正實施測試驅動開發需要花好幾個月的時間。針對遺留代碼，使用GUI冒煙測試可能是一個快速獲得自動化測試覆蓋的途徑。但是使用什么工具最好呢？
我們有購買一個付費工具的預算資金，但是團隊里的程序員是Java程序員，他們萬不得已是不愿意使用另一種腳本語言來進行測試的。捕獲/回放并不適合我們，因為我們需要可維護的、穩定的測試腳本。我們選中了 Cannoo WebTest——一個可以讓我們修改XML文件中的測試用例，并使用Ant運行它們的開源框架。而且它很容易與我們的構建過程集成。
【真知灼見】
昂貴的商業工具不一定是最好的選擇。
我讓業務專家把需要用冒煙測試來保護的系統核心區域按優先等級進行劃分。每個沖刺時間段里，都安排了時間讓我用WebTest工具自動運行測試腳本。我們首先追求的是“快贏”，針對系統中每個用戶角色的基本功能實現自動測試。
首先， CI構建過程只運行了少量單元測試和一些覆蓋系統高得分點的GUI冒煙測試。隨著在這兩個級別引入更多測試，我們將GUI測試移到單獨的構建過程中并只在晚上運行，這樣，我們可以更快得到的反饋信息。
與此同時，我們將單元測試和每個新用戶故事（user story）的GUI冒煙測試都放在迭代中完成。新的功能將會在自動化的單元測試和GUI測試中被覆蓋。一旦程序員能夠熟練使用TDD，我們就將進入金字塔的中間層。
1.3.4　在單元級別驅動開發
我們的程序員中只有一人曾經實施過TDD，但每個人都支持這種理念。我們根據別人的介紹，找到了我們能找到的最好的顧問來幫助我們學習如何實施TDD，很多時候我們都是自帶午餐以便擠出時間來進行TDD試驗。但是很遺憾的是：它很難學！我們團隊需要時間來掌握它。
我們的管理層知道這個道理：目標是寫出優美的代碼，優美到可以拿回家給媽媽，當做冰箱貼。我們的公司——一個剛剛成立3年的商業公司，因為網絡應用問題和無能力及時發布新功能而面臨倒閉。我們的商業合作伙伴也準備放棄我們了，但自從我們實施敏捷開發（Scrum）以后，他們看到了我們為提高穩定性和響應能力所做的努力。我們的執行者致力于具有長遠收益的投資。
【經驗教訓】
一個迫在眉睫的災難可能是巨大進步的推動力。
我們知道這些單元級別的測試具有最好ROI。我們也理解TDD事實上是代碼設計，而不是測試。考慮“代碼是用來做什么的”可以幫助程序員寫出正確的代碼，而快速實施測試，才能及時地提供重要的反饋信息。
單元級別測試的最大好處就是能夠提供最快速的反饋。在研究一些好的實踐之后，我們決定將代碼構建過程的時間控制在10分鐘內。這需要單元測試的隨機重構。早些時候，單元測試需要訪問數據庫，之后，程序員掌握了如何構造、模擬它，以及消除它的影響，使測試快速運行又能提供正確的測試覆蓋。

總結

以上是生活随笔為你收集整理的《 自动化测试最佳实践：来自全球的经典自动化测试案例解析》一一1.3　建立自动化策略...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。