數據遷移的需求背景

公司内部出現業務先合并、新舊系統替換、業務擴大需要進行數據庫分表等情況下，就需要涉及到數據遷移。對應的常見的遷移場景有：

1、需要将兩個系統的部分數據統一從A數據庫讀取，a數據庫和b數據庫通過指定字段進行關聯的情況。

2、直接廢棄舊的系統，将舊系統的數據遷移到新系統，後續僅維護新系統。

本文主要總結分享比較場景的數據遷移場景，業務線合并，2個系統的用戶數據進行關聯的場景。

測試分析

正式環境用戶數據分析

在進行數據正式遷移之前，産品/開發/測試均需要參與對線上已有的用戶數據進行分析，分析線上大量用戶的數據特征，從而進行歸納分類，對不同的分類數據進行遷移策略設計。

以用戶賬号為例，可能存在：用戶使用手機号注冊、用戶未使用手機号注冊等情況，在進行分析時需要考慮到對這兩種的用戶數據進行遷移的策略。

假設遷移的目标庫存在該用戶數據，則根據基礎信息以目标庫為準，并建立源庫和目标庫的關聯關系。

假設遷移的目标庫内不存在該用戶數據，則直接将源庫的用戶信息同步在目标庫内進行創建。

數據遷移測試分析

數據遷移目标是什麼

在進行數據遷移測試之前，需要了解到對應的遷移策略，了解兩個系統的數據如何關聯，以及對應的目标數據庫和源數據庫，通過兩個數據庫數據創建關聯：以源數據庫b為基礎在目标數據庫a中創建關聯，且将b中的相同的基礎字段數據直接選擇性的覆蓋填充到目标庫a中。

在遷移過程中，關聯數據部分基礎字段沖突的處理邏輯。

若兩個數據庫相同字段同時存在數據：

選擇行覆蓋：b内的數據覆蓋a内的數據；

選擇性丢棄：按照優先級，直接丢棄b内的數據，以a的數據為準（或者丢棄a數據，以b數據為準）。

源數據庫和目标數據庫的同一個字段的規則差異。

除了數據兼容沖突兼容外，還需要考慮數據庫兼容，所謂的數據庫兼容就是字段的長度、類型等。例如：

1、字段長度限制。

2、字段區分大小寫：例如：用戶郵箱，在源數據庫内支持大小區分，但是在目标庫内不支持。

3、字段支持特殊字符：例如用戶昵稱在目标數據庫内不支持特殊字符，但是在源數據庫内支持。

4、字段格式不合法：例如手機号格式、郵箱格式。

遷移方案

在評審階段，與開發産品确認對應的遷移方案：

1、正式遷移時，是否需要停機。

2、評估遷移失敗産生的風險以及對應的解決措施。

3、在測試階段進行遷移：

a)是否允許針對指定的數據進行遷移測試。

b)測試期間未停機導緻的髒數據如何處理。

c)評估遷移失敗可能産生的風險，是否可進行數據恢複。

4、遷移準備：提前根據測試分析的各個遷移場景，準備對應的“待遷移”數據，數據要盡可能的模拟線上用戶真實數據。

遷移驗收

數據遷移成功後驗收，需要基于業務場景的角度進行數據對應的功能場景驗收，必須要覆蓋「增」、「删」、「改」、「查」。

【新增】：遷移後往新的數據庫内添加數據後，在軟件内訪問個人中心查看用戶信息獲取正确。

【查詢】：對用戶的基本信息進行遷移後，需要在軟件内訪問個人中心查看用戶的信息是否獲取成功，是否有異常報錯。

【修改】：對用戶的基本信息進行修改，修改後數據存儲成功，再次訪問個人中心可展示最新的用戶數據。

【删除】：删除用戶數據後，該用戶無法訪問。

發布留觀

由于遷移數據版本發布後，勢必會影響到用戶的數據，所以在分析階段對用戶可能出現的反饋制定出對應的應答策略，提前進行人員分工。同時關注由于發布後的功能使用情況。

用戶反饋

發布後對用戶反饋及時響應，快速定位用戶的數據出現變更是否由數據遷移引起，以及如何引導用戶正常繼續使用，提高用戶的滿意度。

留觀數據

重點梳理關于遷移數據涉及到的相關的核心接口數據，在發布後進行定時監測：

1、相關接口調用量：關注數據遷移後，接口的調用量是否暴漲。

2、相關接口錯誤率：關注數據遷移後，接口的錯誤率是否異常上漲。

3、相關接口告警率：關注數據遷移後，接口的告警率是否異常上漲。

小案例

以上是個人對于小部分數據遷移測試後的總結反思。一個人必須不停地總結歸納，才能不被茫茫人海淹沒～

1）關注 私信回複：“測試”，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql數據庫、抓包工具、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試等。

2）關注 私信回複："入群" 就可以邀請你進入軟件測試群學習交流~~

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!