在軟件的生命周期中，經常遇到由于業務發展，系統迭代更新帶來的數據遷移工作；或者軟件系統本身的重構抑或其他因素，幾乎都需要對數據進行遷移。

最近看了一些關于數據遷移測試相關的資料，由于以前對這方面沒有太多實踐，所以瀏覽的同時也在思考如何進行數據遷移測試

想象一下，數以億計的數據，在生產環境的數據庫上進行遷移，比如一個數據對象（有關聯的N條數據）遷移需要一秒鐘，那么如果按照順序遷移，則可能花費幾個月甚至幾年的時間。

企業通過不斷的對用戶提供服務產生效益，所有的系統升級、產品迭代現在基本都是在線進行，而不依賴于有計劃的維護時段。

因為不能在遷移過程中中斷或者停止所有或部分服務，那么在這個遷移過程中必須要保證服務100%處于可用狀態。

正確性：代碼中很多的代碼都是在直接使用數據庫某些表中的數據，如果試圖一次性的修改整個應用里面的代碼，那么涉及的方面將是巨大的，也很容易忽略一些邊界情況。

在數據遷移過程中，必須確保每項服務獲取到的數據都是正確無誤的。

一致性：在數據遷移過程中，必須確保從原有的數據庫遷移過來的數據和新數據庫表中存儲的數據保持一致。

可用性：即無論是遷移前，還是遷移過程抑或遷移完成后，數據都必須是100%可用。

在進行數據遷移前需要和開發、運維等相關部門確認好數據的遷移范圍，分析原有系統和現有系統的功能模塊、大致的處理流程，分析兩者的區別，以及歷史數據對用戶的影響程度等，

確認工作量和工作進度，這樣才方便確認數據遷移邊界和范圍，不至于盲目的全部遷移。

①、基礎數據遷移

基礎數據也可以稱為主檔數據，通常來說這一類數據都是需要全部復制到新的系統數據庫中，因為它會影響所有的業務。

②、流程性數據

這一類數據只有在記錄完全關閉后才能結束，需要進行增量導入和數據更新，同時還要進行相關查詢界面的開發，以保證舊有數據能夠在新系統中查詢的到。

③、歷史數據

對于這一類的數據，需要和業務部門確認好歷史數據對用戶的影響，哪些是必須要遷移的，哪些是可以通過備份或雙寫模式進行遷移的，確認數據范圍和新老系統的差異以及庫表結構等。

①、可以通過excel表格等方式確認相關表的數據字典對照，勾畫出對應字段、轉換邏輯、依賴關系等，必要時在新系統表上做相應的冗余，等數據遷移完畢后再清除；

②、注意不同數據庫的字段類型的匹配問題，比如SQLServer的text，在oracle應該對應clob，根據具體情況和實現的難易程度來確認具體做法；

③、關于主鍵的問題，一致的數據類型盡量維持現有狀態，不一致的盡量采用oracle的序列或sqlserver的identity int，但遷移完畢后，要注意序列值的更新。

將原有系統數據庫中的表直接復制到新系統的數據庫中；

拆表：將原有系統數據庫中的表數據拆分到新系統數據庫中的幾張表中；

合表：將原有系統數據庫中的表字段合并到新系統數據庫中的一張表中；

PS：需要確認清楚，哪些表分拆遷移，哪些表合并遷移，遷移的數據字段、條數等！

要做到新老系統無縫切換，就必須保證數據的正確性和一致性，首要條件就是遷移的數據量是保持一致的，否則無法進行其他測試。

方法：①、可以通過文本統計工具或者數據庫連接工具將遷移前的數據庫表名、字段、數量等進行統計，然后將遷移后的新數據庫表名、字段、數量等進行統計，然后進行比較。

②、通過MD5生成工具，對新老數據文本進行MD5值比對測試，如果一致則表示數據量一致，如果不一致，則表明遷移后的數據有部分存在問題。

這種測試分2種情況：一種是新老數據庫表結構完全不存在關系，新數據庫表的字段都是給定的默認值；還有一種是新數據庫表字段是由原有系統數據庫表字段轉換而來。

方法：針對第一種情況，因為新增的字段都是給定的默認值，所以只需要根據開發提供的填寫規則，檢查該字段的所有值是否滿足填寫規則。

針對第二種情況，可以通過編寫自動化測試腳本或者人工抽樣或者切片方式進行，具體的抽樣選擇根據數據量等具體情況選擇合適的比例即可。

完成上面的數據遷移測試后，需要在新的系統中進行回歸測試，以確保遷移過來的數據是100%可用的。

回歸測試前需要和業務、開發確認哪些業務模塊涉及了哪些表，然后根據具體情況，盡可能的提高測試用例覆蓋率，做一次全系統的功能回歸測試（可以考慮自動化測試來替代一部分手工測試）。