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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。