數據遷移測試項目實戰，2個系統的用戶數據如何進行關聯？（圖）

數據遷移的需求背景

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

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、相關接口告警率：關注數據遷移后，接口的告警率是否異常上漲。

小案例

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

最后：在我的V ：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。