軟件測試之數據庫設計中的敏捷方法[2]

關鍵字：數據庫設計 敏捷方法

　　3.4數據庫包含計劃和測試數據

　　當提到數據庫的時候，我們并不僅僅指數據庫計劃，而且還包括相當規模的數據。這些數據包括應用所需的標準數據，如全國所有的省份名，以及一些樣本客戶的樣本數據。

　　數據的作用：

　　1、 易于測試

　　使用大量的自動化測試可以幫助穩定應用的發展。這樣的測試在敏捷方法里是常用的方法。為了使這些測試有效進行，很理智的方法是在一個有樣本測試數據的基礎上工作，這樣所有的測試可以在程序正式進行之前完成。

　　2、測試數據庫的遷移

　　除了測試代碼之外，樣本測試數據允許我們測試數據庫的遷移，當改變了數據庫的計劃后，我們還必須保證所有的計劃變更也能夠處理樣本數據。

　　在大多數項目中這些樣本數據是虛構的。然而在某些項目中人們使用實際數據作為例子。在這些情況下，數據從先前由自動化數據遷移代碼的系統中提取出來。很明顯不能馬上遷移所有的數據，因為在早期迭代中數據庫只有小部分建立起來。但是我們希望當應用和數據庫發展時，改變遷移代碼。這樣不僅能夠盡早解決遷移問題，也使行業專家易于處理這個正在開發的系統。因為有他們熟悉的數據，所以他們會指出可能給數據庫和應用設計帶來問題的地方。因此我們建議在項目的早期迭代中引入實際數據。

　　3.5所有的變化應該數據庫重構

　　重構技術就是應用所有可控技術來改變現有的代碼基礎。與此類似我們定義了數據庫重構也給數據庫的改變提供了類似的控制。

　　數據庫重構的不同之處在于它必須將三種不同的變化同時完成：

　　*** 改變數據庫計劃

　　*** 進行數據遷移

　　*** 改變數據庫存取代碼

　　于是當描述數據庫重構時，我們必須描述變化的三個方面，并確保在應用另一個重構之前完成了這三種變化。

　　我們必須文檔化不同的數據庫重構，因此我們還不能詳細描述他們。然而這里有幾點需要指出：像代碼重構一樣，數據庫重構非常微小。概念鏈一系列微小的變化，數據庫和代碼很相似。變化的三個屬性使保持小的變化更加重要。

　　許多數據庫重構，如增加一個字段，可以不必更新所有存取系統的代碼來完成。但是如果在使用新計劃之前并不了解它，該字段將會無用，因為新計劃不知道其變化之處。許多變化，沒有考慮整個系統計劃，我們稱之為破壞性變化，如將一個已經存在的空值列設置為非空。破壞性變化需要多加留心，留心的程度依賴于包含破壞性的程度。一個小破壞性的例子是將一個已經存在的空值列設置為非空，在這種情況下你可以蒙著頭做。

　　而重構將考慮數據庫中空值數據。開發人員將更新數據庫映射代碼，因此更新不會破壞其它人的代碼;如果偶然會破壞，開發人員將在建立和使用測試時發現問題。

　　將一個經常使用的表分成兩個是一種更復雜的破壞。在這種情況中提前讓所有人知道變化到來很重要，這樣他們可以有所準備。此外應該在一個更安全的時刻來實施變化。

　　這里面很重要的一點是選擇適用于你做出的變化的過程。

　　3.6自動重構

　　在代碼世界中許多語言能夠實現自動重構。在計劃變化和數據遷移過程中，這種自動化對于數據庫也非常重要。因此每個數據庫重構都可以通過編寫SQL DDL(對于計劃變化)和DML(對于數據遷移)來完成。這些變化不是通過手工實現，而是通過一些SQL語句來自動實現變化。

　　一旦完成代碼，我們保存這些代碼文件來產生數據庫變化的完整的變化記錄，作為數據庫重構的結果。我們于是可以更新任何實例到最新的主數據庫，通過運行在我們拷貝主數據庫來產生更早的數據庫實例的變化記錄。

　　自動化變化的序列化是對于持續集成和遷移產品數據庫的一個基本功能。

　　為了最后產品數據庫我們并不在常規迭代周期中實施變化。我們在每一個發布之間建立完整的數據庫重構變化日志。毫無疑問，這是一個巨大的變化，我們必須離線實施該變化。在實際應用之前先測試遷移計劃絕對是明智之舉。迄今為止，這項技術相當管用。通過將大變化分解為小的簡單的變化，我們可以對產品數據進行大的變化，同時又不會給我們太多的麻煩。套用兵法中的一句話，就是“化整為零”。

　　除了自動化向前的變化，我們也要考慮重構時向后的變化。如果能夠做到這樣就可以回到以前的數據庫狀態。在我們的項目中并沒有這樣做，因為沒有這個需求，但這同樣是很重要的基本原則。

原文轉自：http://www.anti-gravitydesign.com