在測試工作中，如果趕上App改版或者重構，很難躲過數據遷移這個老大難問題。對于測試，遷移相關的工作也是相當頭大，基本上一個考慮不周就極易會有遷移失敗或者臟數據的產生。下面就來說說我們在數據遷移過程中的工作及注意事項，希望能盡量避免大家會遇到的問題：

1. 確認遷移需求

這個永遠是一切的開始，無論做啥沒有需求就沒有后續(xù)的工作。在遷移過程中需要確認的需求有很多，也有很大一部分是和業(yè)務緊密相關的，所以下面就來說說常見的需求。

a. 雙向遷移還是單向遷移。如果是單項遷移，是老系統(tǒng)向新系統(tǒng)遷移還是新系統(tǒng)向老系統(tǒng)遷移（雖然場景很少）。

b. 需要遷移的數據&不需要遷移的數據。

c. 觸發(fā)遷移的方式（實時自動遷移 or 人工遷移）、遷移過程中的UI展現及遷移后結果的UI展現。

d. 是否只遷移一次，還是可以多次遷移（增量更新）以及遷移時的覆蓋邏輯等。

e. 原數據包含空字符串、默認值、null等遷移后展現。在遷移后的系統(tǒng)上該如何展示之前系統(tǒng)中內容為空字符串、null、默認值等的數據。

f. 遷移時間。對遷移效率有什么樣的期許，可以接受的最長時間。

g. 各業(yè)務自己的邏輯注意事項及其他...

2. 和RD溝通遷移技術方案

這個事情往往被忽視，因為大部分測試并不關心數據遷移的技術方案，而只關心遷移的數據是否一致。但是其實了解遷移的技術方案有幾點好處：

a. 可以根據RD的技術方案提前找到技術漏洞，如內容默認值等細節(jié)問題，尤其是在RD根據需求講解技術方案的時候。

b. 在code review時可以根據方案的內容很快的切入到編碼邏輯中。

c. 可以提前開始測試工作，比如：如果知道遷移是通過隊列發(fā)送消息觸發(fā)，就不用等到RD提供接口或者UI再開始測試，直接自己發(fā)消息就可以了。

d. 發(fā)現問題后的定位更為準確。

3. 整體測試

這就是測試的重頭戲了。

a. 首先重要的事情說三遍，數據，數據，數據。遷移的最主要東西：數據。

剛才在需求里面其實說了很多關于數據的事兒，老系統(tǒng)和新系統(tǒng)在遷移后所有需遷的字段當然要保持數據的一致。然而，這里面的不可見細節(jié)還是很多的。數值精度，字符串長度，日期格式，null值轉化，空字符串轉化，特定格式校驗（手機號等），附件能否打開等都需要注意。

b. 數據量匹配

這個不用多說了吧，數據量應該前后是一致的，除非有業(yè)務的特殊需要?？梢砸猿闃訑祿w移前后是否一致來測試，如果很重要的項目，需要加大樣本量。

c. 大數據量遷移。

一些遷移的問題在小數據量的情況下很難發(fā)現，但是如果增大數據量就會暴露一些問題。如大數據量遷移下出現的數據缺失，程序死鎖，性能緩慢，緩存溢出等問題。

需要注意的是，大數據量不止說數據的條數多，還指單個數據里面的數據體量大，如很多的附件等。

d. 多次遷移（增量遷移）

在老系統(tǒng)上修改或者刪除一些數據，然后去驗證遷移后新系統(tǒng)是否符合業(yè)務需求。

e. 雙向遷移

同多次遷移，需要驗證遷移后新老系統(tǒng)是否符合業(yè)務需求。

f. 遷移效率

在實時遷移（數據同步）時，查看雙方數據同步的效率是否滿足需求需要。

g. 接口自動化測試輔助

人眼始終比不過電腦。一個兩個病歷還可以比對，再多人也受不了。這個時候就需要自動化測試的幫助了。比如新老版本都是有獲取用戶信息的接口的，然后我們要測試遷移完成后數據的一致性，接口測試就能派上用場。寫完了一個接口測試，只要去變換不同的用戶，就可以去驗證他們的數據是否一致。

h. 服務端日志監(jiān)控

千算萬算，很難能夠模擬好所有可能遇到的場景。這時候通過監(jiān)控遷移所在服務的日志往往能夠看到一些考慮不到的問題。