本文由 dbaplus 社羣授權轉載。
我們的核心繫統是一個單體系統，支撐全球多個國家和地區的業務。同時，業務部門近年生意紅火，接了幾個大客戶，針對這些大客戶的大型項目也在如火如荼地進行中。
由於生產環境只有一套，而且已經有業務在生產環境上跑，這些大項目最終也要在這套生產環境上上線。這套系統是糅合了各地、各不同業務的複雜系統。
之前，爲了滿足各個客戶交付時間，每個項目都拉了一個獨立的分支進行開發，減少各項目之間的依賴，但這也導致了每個項目各自爲政，互不交流。一旦這些項目開發完成，要和生產環境的版本進行合併。這種巨型合併勢必帶來巨大風險，相互隔絕的開發模式也將帶來大量的合併衝突。
我們一直在思考如何降低這種合併風險，以及如何打破各大型項目各自爲政的困局，實現產品化的敏捷交付。迴歸測試成爲實現這些使命的基礎。
使命——實現敏捷交付
前面提到，目前的開發模式是針對不同的大客戶，分別設立了不同的大型項目進行開發。這些項目的交付週期往往數以年計，交付週期長，風險大。
生產環境又只有一套，而且已經有業務在生產環境上跑，代碼合併困難，上線風險巨大。
我們希望能打破這種大型項目的交付形式，以產品化的思維進行管理。
具體實施的思路是：
- 合併——對各大型項目的現有代碼與生產環境的版本進行一次性的合併；
- 統一Backlog——各類需求（包括現在以大型項目形式服務的大客戶的需求）以用戶故事的形式進入到同一個Backlog；
- Scrum——建立以Scrum爲形式的持續交付機制，以一個月作爲Sprint的週期，通過Sprint計劃會議敲定Sprint的交付計劃；
- 持續交付——每個Sprint完成計劃內各用戶故事的交付全流程，包括迴歸測試和上線到生產環境。
要實現以上模式，上線前的迴歸測試至關重要。而且由於一個Sprint內，也就是一個月內，要完成Sprint交付計劃內所有用戶故事的需求澄清、設計、開發、測試、用戶驗收和上線，時間非常緊，迴歸測試也必須在一、兩天內完成。
如何實現既能充分保護生產環境，又能實現快速反饋的迴歸測試，成爲一個重要議題。
自動化大量功能測試不可行
對於如何設計和實施覆蓋率高、執行穩定而且快速的自動化迴歸測試，一直是一個難題。
我們曾經的一個思路是把現有的功能測試用例進行自動化，但很快發現這個思路不可行，主要原因如下：
- 只能依賴UI測試——由於核心系統是供應商產品，開發是由供應商負責的，對我們來說就是個黑盒子，我們只能通過UI進行測試。衆所周知，UI的自動化測試，開發、維護成本高，脆弱而且執行時間長；
- 無法快速反饋——通過功能進行覆蓋，要求不斷增加測試用例來提高覆蓋率，由於UI測試的執行時間長，用例越多，整體執行時間越長，如果執行週期要數以天計，則無法達到快速反饋的目的；
- 性價比低——功能測試用例的覆蓋率其實是不可見的，即使把所有功能測試都自動化了，其實際覆蓋率依然不高，也就是說這個投入的性價比很低。
我們必須要尋找一種方法，以最小的投入獲取最大的保障。
我們對迴歸測試自動化的預期進行了重新定位。 我們進行迴歸測試，就是要保護生產環境的關鍵業務可以照常進行。我們要防止的，是新的特性發布造成生產環境災難，也就是導致關鍵業務無法進行的大面積故障。 對於非災難性的小故障，完全可以通過運維手段來處理。
因此，我們不應該把迴歸測試定位爲防止一切問題。
以不變應萬變
基於以上對迴歸測試預期的重新定位，我們和業務部門協商，請他們列舉出當前在生產環境上最關鍵的業務過程有哪些。我們要保證的是， 當新的特性上線後的首個交易日，原有的最關鍵的業務過程不會受到嚴重影響。
基於這個預期，我們以業務部門提供的關鍵業務過程作爲測試用例，並形成以下的迴歸測試思路：
準備階段：
- 在某個測試環境裏，系統版本與生產環境版本相同；
- 備份環境數據；
- 以某個交易日爲基準，執行相應的測試用例；
- 備份輸入、輸出數據（包括生成的接口文件和報表）。
執行階段：
- 在該測試環境裏，導入在準備階段備份的環境數據；
- 升級系統到目標版本；
- 以準備階段相同的交易日和相同的輸入數據（在準備階段已備份）執行相同的測試用例，生成相應的接口文件和報表；
- 與準備階段的輸出（接口文件和報表）進行比對；
- 如果目標版本的輸出與原版本的對比沒有非預期的差異，視爲通過。
簡單總結， 就是對比兩個系統版本在相同測試環境、相同環境數據、相同交易日、相同輸入的情況下，輸出是否有非預期的差異。
這個思路的最大特點是，以不變應萬變。生產環境的關鍵業務過程不會經常變化，也就是說測試用例基本上比較固定。通過反覆運行固定的測試用例實現迴歸測試的目標，保護生產環境上的關鍵業務過程，避免災難。以最少的用例實現最大的保護。
而且測試的結果驗證是通過比對不同版本的輸出，我們 不必在乎具體的輸出內容 ，只需要關注輸出是否有非預期差異。
當然，一旦有新的大客戶上線，也就是有新的關鍵業務過程，這些過程也應該放入到迴歸測試用例中，當然，用例的選擇還是以避免災難爲準則。
在前面提到的功能測試思路里，我們需要不斷增加測試用例以增加測試覆蓋率，但是由於測試只能在UI進行，這樣無限增加功能測試用例是不可持續的。
通過實踐，我們發現要充分發揮這個新思路的價值，要注意以下幾點：
- 專屬環境——由於這套環境需要反覆整理環境數據和升級，一定要爲這個迴歸測試準備一套專屬的測試環境，不要在共享的環境裏進行；
- 明確檢查點——由於執行測試輸出的接口文件、報表裏一定有時間戳、自增ID等每次執行都會變化的信息，不能簡單通過文件來比對。在擬定測試用例時，就應該明確這些接口文件、報表裏的有哪些數據需要檢查。在每個版本交付時，開發人員也應該明確告知哪些數據檢查點會有預期差異。否則對比工作將耗費大量的時間和精力；
- 變更範圍要小——如果對比的兩個系統版本的變更範圍太大，會導致輸出有大量差異，比對意義不大。因此這個方法不太適合大的合併，比較適合落實了敏捷交付後，由於每個Sprint的變更範圍較小，兩個系統版本間的輸出差異不多，比對較容易。
以這個思路建立了迴歸測試框架，我們便可以着手執行過程的自動化，從而提升其執行的效率。
總結
我們的核心繫統是一套單體複雜系統，支撐全球多個國家和地區不同的業務。
爲了實現敏捷交付，我們希望打破目前以大型項目爲形式的各自爲政，把各項目的所有需求放在統一的Backlog通過Scrum的方法進行持續交付。
要實現這一點，我們需要在每個Sprint都進行有效的迴歸測試，以保護生產環境的關鍵業務在新特性上線後不會有災難性的故障。
通過對比兩個系統版本在相同測試環境、相同環境數據、相同交易日、相同輸入的情況下，執行關鍵業務過程的有限的測試用例，輸出是否有非預期的差異的迴歸測試方法，以少勝多，以不變應萬變，持續保護生產環境的核心業務，爲持續交付保駕護航。
作者介紹：
劉華（Kenneth），就職於世界500強銀行，負責基金服務業務軟件開發與交付，DevOps團隊負責人。敏捷、精益、DevOps領域專家，精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧。著有《獵豹行動：硝煙中的敏捷轉型之旅》一書。
原文鏈接：