數據管理

語言: CN / TW / HK

《持續交付 發佈可靠軟件的系統方法》讀書筆記

數據庫腳本化

與系統中其他變更一樣,作為構建、部署、測試和發佈過程的一部分,任何對數據庫的修改都應該通過自動化過程來管理。 也就是説,數據庫的初始化和所有的遷移都需要腳本化,並提交到版本控制庫中。 無論是為開發人員創建一個新的本地數據庫,還是為測試人員升級系統集成測試環境,或者作為發佈過程的一部分遷移生產環境中的數據庫,都應該能夠使用這些腳本來管理交付流程中的每個數據庫。

當然,數據庫的模式會隨着應用程序不斷演變。這就引出了一個要求,即某個版本的數據庫模式應該與該應用程序的某個具體版本相對應。例如,當做試運行環境的部署時,就要能夠把試運行環境的數據遷移到適當的數據庫模式上,以便與正在部署的新版本應用程序相匹配。通過對腳本的細心管理可以讓這項工作成為可能。

增量式修改

持續集成要求在每次修改應用程序後,它都能夠正常運行。這也包括對數據結構和數據內容的修改。

持續交付要求我們必須能夠部署應用程序的任意一個已通過驗證的版本(包括對數據庫變更的版本)到生產環境(對於用户自行安裝且包含數據庫的軟件也是一樣的)。除了那種最簡單的系統,對數據庫進行更新的同時,還要保留它們的數據。最後,由於在部署時需要保留數據庫中的已有數據,所以需要有回滾策略,以便當部署失敗時使用。

數據庫回滾和無停機發布

  1. 當回滾時需要保留本次升級後產生的數據;

  2. 根據簽訂的 SLA ,要保持應用程序的可用狀態,也叫做熱部署或無停機發布;

測試數據的管理

為單元測試進行數據庫模擬

單元測試不使用真正的數據庫是非常重要的,通常單元測試會使用測試替身對象來取代與數據庫打交道的服務。

管理測試與數據之間的耦合

有以下三種方法可以用來做測試設計,以便管理好數據的狀態:

  • 測試的獨立性:合理地組織測試,以便每個測試的數據只對該測試可見。

  • 適應性測試:按如下方式進行測試設計—每次運行時先對數據環境進行檢查,然後使用這些檢查中得到的數據作為數據基礎,對系統行為進行測試。

  • 測試的順序性:按如下方式進行測試設計——按某種已知的序列運行,每個測試的輸入依賴於前一個的輸出。

測試獨立性

測試獨立性是指確保每個測試都具有原子性。也就是説,每個測試不應該用其他測試的結果建立它的初始狀態,並且其他測試也不應該以任何形式影響該測試的成功或失敗。

最簡單的方法是確保在測試結束時,總是將數據庫中的數據狀態恢復到該測試運行之前的狀態。可以用手工方法來做,但最簡單的方法是依靠大多數 RDMS 提供的事務特性。

建立和銷燬

無論選擇的策略是什麼,在測試運行之前建立一個已知的狀態良好的起始點,並且在其運行結束時再重建這個起始點是至關重要的,可以避免測試間依賴。

連貫的測試場景

常常有這樣一種傾向,即創建一個連貫的“故事”(將多個測試場景串在一起),讓一些測試順序執行。這種方法的出發點是已創建的數據是有連續性的,這樣可以將測試用例的建立和銷燬工作最小化。而且,每個測試本身也會簡單一點兒,因為它不再負責管理自己的測試數據了。另外,作為一個整體,測試套件運行得更快,因為它不用花太多時間創建和銷燬測試數據了。

這種策略的問題在於我們正在努力把一個連貫的故事與測試緊緊耦合在一起。這種緊耦合有幾個非常大的缺點。隨着測試套件的增長,測試的設計越來越難。當一個測試失敗以後,會對後續依賴於它的一系列測試造成影響,讓它們也失敗。業務場景或技術實現的變更可能導致重寫測試套件,非常痛苦。

數據管理和部署流水線

我們通過測試來斷言我們所開發的應用程序的行為符合我們期望的結果。

  • 運行單元測試來避免剛做的修改破壞已有的應用程序;

  • 運行驗收測試來斷言應用程序交付了用户所期望的價值;

  • 運行容量測試來斷言應用程序滿足我們的容量需求;

  • 運行一套集成測試來確認應用程序與其依賴的第三方服務可以正常通信;

那麼,對於部署流水線的每個測試階段,我們需要哪些測試數據,並應該如何管理它呢?

提交階段的測試數據

好的提交測試會避免複雜的數據準備。如果你發現自己很難為某個測試準備數據的話,這是一個明顯的信號,表示你的設計需要更好地解耦。要將設計分成多個互相獨立的組件和測試,使用測試替身對象來模擬依賴。

驗收測試中的數據

儘可能減少測試對大型複雜數據結構的依賴。方法基本上與提交階段的測試一樣:我們希望在測試用例的創建方面做到一些重用,並將每個測試對測試數據的依賴最小化。我們應該創建恰好夠用的數據,用來驗證我們對系統的期望行為。

容量測試的數據

容量測試用來指出應用程序所需的數據規模問題,該問題在兩方面體現:

  1. 為測試提供足夠的輸入數據;

  2. 準備適當的引用數據來支撐測試中的多個用例;

我們把容量測試看做驗收測試的重複利用,只是同時運行很多用例而已。

其他測試階段的數據

拋開具體的實現技術,至少從設計理念上來講,在驗收測試階段之後的所有自動化測試階段中,我們都可以使用同樣的方法。我們的目標是重用那些自動化驗收測試所用的“行為規範”作為其他測試(不僅限於功能性測試)的起點。

小結

由於生命週期不同,數據管理也面臨一些待解決的問題。儘管這些問題與部署流水線上下文中的問題有所不同,但管理數據所用的基本原則是一樣的。關鍵是要把創建和遷移數據庫全部變成自動化過程。這個過程是部署流程的一個組成部分,確保它的可重複性和可靠性。

即使有自動化的數據庫遷移過程,細心地管理測試數據仍舊是非常必要的。儘管直接使用生產數據庫的副本是一個充滿誘惑力的選擇,但通常會因為數據太大而不易使用。相反,應該讓測試自己創建它們所需的狀態,並確保每個測試都獨立於其他測試。甚至做手工測試時,也很少使用生產環境中數據庫副本,它不是最佳起點。測試人員應該根據測試目的創建並管理自己的最小數據集。

推薦閲讀