《 自動化測試最佳實踐：來自全球的經典自動化測試案例解析》一一1.4 利用驗收測試驅動開發，使用FitNesse測試GUI

1.4　利用驗收測試驅動開發，使用fitnesse測試gui

現在已經是我們自動化之旅的第8個月了，程式員已經建立了一個自動化單元測試的實用庫。對于應用程式的核心區域我們已經進行了冒煙測試，覆寫微量代碼的大約100個junit測試已經完成了。但是中間層還什麼都沒有，tdd此時變成了一個空殼。現在我們開始對自動化測試金字塔的中間層進行填充。

1.4.1　記憶體内測試

我們的金融理财産品有許多複雜的算法，這可以通過在記憶體中提供輸入來進行測試。與單元測試相比，這種測試的級别要高很多，但我們還是不想通過gui來進行測試，因為其速度慢、成本高。我們發現可以很迅速、友善地編寫fitnesse夾具（fixture）來自動進行這類測試。在客戶測試層次，我們開始用fitnesse測試來驅動新的使用者故事的開發。這些測試使用夾具在記憶體中建構測試輸入，并把這些輸入發送到應用層代碼，就如同産品在實際使用時進行的輸入一樣。然後夾具會傳回代碼的實際輸出，并把它與fitnesse表中的期望結果進行對比。

測試人員和客戶填寫fitnesse測試用例，之後程式員用夾具來自動運作它們。這意味着我們需要交流！提高團隊的交流能力是使用這種工具進行自動化測試的最大好處之一。我們測試人員與産品所有者和其他利益相關者坐在一起分析每個使用者故事預期的和非預期的行為。我們将這些使用者故事轉化為fitnesse測試用例表，并與客戶核對以保證當測試用例通過測試的時候能夠滿足客戶的要求。我們與開發人員核對測試，以保證我們清楚需求并保證測試設計與代碼設計相容。開發人員編寫夾具來自動運作測試。這一過程在單個使用者故事的很多小的疊代中不斷重複，直到開發和測試都完成。

1.4.2　使用資料庫的測試

我們的應用是資料密集型應用，我們想自動運作更加端到端（end-to-end）的測試。我們也可以使用fitnesse在資料庫中建構測試資料，并使用遺留代碼在它上面運作，以此來測試遺留代碼。

這種類型的測試腳本編寫和維護都更加昂貴。作為fitnesse的初學者，我們犯了一些錯誤，如，不知道将測試元件子產品化，而這可以通過fitnesse中現有的部件來完成。我們徹底違反了代碼設計中的“不要重複自我”準則。例如，在幾十個不同的測試頁面中，有包含同樣員工資訊的表，如果又有一列新資料需要添加到員工資訊表中，那麼在每個測試頁面中都要加進去，這很糟糕。等到我們知道如何正确去做的時候，又遇到了一個更難以處理的麻煩。

【經驗教訓】

在前期進行工具使用的教育訓練，之後就可以避免因工具使用不熟練而造成的巨大的時間浪費。

我們将每個能想到的測試用例都進行了自動化，包括發生幾率低、影響小的邊緣測試用例，并把它們都放在自動回歸測試套件（test suite）裡面。上述過程花費的時間并不長，但是接下來，這個測試套件要花費大量時間和主機功率（machine power）來運作，維護成本也随之提高了。是以，我們要學會慎重選擇測試用例，確定它們能提供充分的測試覆寫，并隻将這些測試用例放在回歸測試套件中。

【小竅門】

精化回歸測試套件可以在保證收益的同時降低維護費用。

正如在産品應用代碼中所做的那樣，我們現在不斷地重複通路和重構fitnesse測試用例，以保證我們所需要的測試覆寫，同時不會過多地延長回報周期或者花費太多時間維護測試。

【真知灼見】

經常檢查自動化測試用例以保證它們是有效的。

1.4.3　使用fitnesse測試的好處

我們的fitnesse測試提供了比gui測試套件更快的回報，盡管比junit測試要慢很多。fitnesse測試套件需要60 ~ 90分鐘來運作，而junit測試的運作時間僅僅隻需要不到8分鐘。像gui測試腳本那樣，我們将fitnesse測試內建到建構過程中，并且在其中運作。一開始，我們隻在晚上運作這種“完全建構”（full build），但這無法提供及時的回報，并且如果測試失敗的話，我們隻有在第二個晚上才能知道問題是否修複了。我們投入了更多的硬體，這樣我們就可以“連續地”運作單元級别上的所有測試的完全建構。如同運作單元級别測試的建構一樣，這是為了使源代碼控制每接收到一次檢入就能運作。大概需要90分鐘運作一次，是以經常同時測試幾個新的檢入。