以自動化測試撬動遺留系統

面對遺留系統，選擇合適的測試策略，能讓自動化測試的投入在一定時期內看到效果，并且建立可持續進行的機制。同為自動化測試，每種測試在面對遺留系統時遇到的挑戰是不同的，起到的效果也不盡相同。
背景

我目前所服務的企業大部分系統是遺留系統，其中多數處于相對需求平穩階段，即需求并不多，也沒有大需求。但這些系統牽制了和需求所需人力不成比例的大量人力，從系統本身的原因看，有這么幾點。

• 系統晦澀難懂，可讀性可理解性很差。理解原有系統往往占據了進行一個修改的大部分時間。
• 系統設計僵化，改動困難，一個小修改，會迫使系統很多部分的改動。
• 系統難以重用，大多軟件單元缺乏可重用性。
• 系統脆弱，引入一個小功能會引入幾個缺陷，修復一個缺陷又引起幾個新缺陷。

投入大量人力，產生的價值卻微乎其微。面對激烈的市場，同質化的競爭，成本和質量問題日益凸顯。而所謂遺留系統，即沒有自動化測試保護的系統?？蛻艉芟Ｍㄟ^引入“自動化測試”來提升系統質量，最終幫助他們建立自動化測試機制。

過去幾個月里，我先后投入到幾個遺留系統的自動化測試提升工作中。這些工作都進展不錯，很多系統的核心模塊都有了自動化測試的覆蓋。另外，這次專門針對“遺留系統”所做的自動化測試工作，也帶給我一些新想法：自動化測試，很可能是我們撬動遺留系統的一個支點。

測試策略選擇

圖1是測試金字塔模型，從上至下分別是驗收測試、API測試、集成測試和單元測試。你可以有不一樣的分類，但從上至下，測試粒度越來越小，測試數量越來越多。一個具備完善自動化測試的系統，應該具備類似的測試分布。

圖1 測試金字塔模型

當我們面對的是遺留系統時，追求理想模型肯定是不現實的，那么應該選擇何種測試策略呢？

每 個遺留系統的狀況都不盡相同，可能選擇的策略也會不一樣。但有一點是一致的——所有的測試都不是沒有成本的，在人力并不寬裕的情況下，必須讓測試投入“值 回票價”。而且，必須讓測試投入到短期最有價值的地方，才能讓團隊盡快看到效果和建立信心。我們選擇的策略之一是：快速建立穩定性較高的功能測試防護墻， 以此保護系統的核心功能不被任意破壞。這里有兩個關鍵點。

• 快速，要選擇可以快速建立的測試，讓一定的價值在短期之內就能得到體現。
• 穩定，指的是測試本身的穩定——不因系統變化而對測試產生太大的沖擊，因而維護成本也就相對較低。

這里的功能測試可以是驗收測試、API測試或集成測試，根據每個系統的情況選擇更好滿足上面兩個關鍵點的測試類型。

例如，我們曾面對一個Web系統，大部分頁面邏輯比較簡單，主要是呈現內容；前端通過REST接口跟業務后臺交互數據。剛開始我們選擇基于 WebDriver的驗收測試，但隨后即發現這類測試編寫成本較高，需要學員掌握較多技能，無法在短期內快速為整個系統建立一個防護墻；另一方面，它的穩 定性也較低，測試較易受到頁面布局的影響，維護成本較高。在這種情況下，最后我們轉而選擇了基于REST接口的測試，因為它的建立成本更低，穩定性也更高 （REST接口變化較少），而且也可以覆蓋所有核心功能，相比而言，是個更好的選擇。

我們還選擇了另一個策略：針對熱點區域（包括需求熱點和缺陷熱點等）添加測試。選擇這些區域主要基于兩點理由。

• 首先，“非熱點”區域，也就是暫時穩定的區域，在初期并不是最值得投入為其建立測試的。例如，有個Web系統，它有兩個相對獨立的組件，一個是社區，另一個是網店，如果前者是熱點區域而后者不是，那么前者就更有價值在初期投入建立測試。
• 其次，遺留系統的脆弱性往往體現在“Bug重復出現”、“解決一個Bug，出現兩個Bug”等情形。針對這些活躍區域添加測試可以對它們起到保護作用，減少出現上述情況出現的機會；同時，也是對這塊區域的一個重構契機。

  原文轉自：http://www.uml.org.cn/Test/201305025.asp

  • 共4頁:
  • 上一頁
  • 1
  • 2
  • 3
  • 4
  • 下一頁