點擊關注，我們共同每天進步一點點！

最近經歷了一場大型的數據遷移測試，因為以前對數據遷移測試研究甚少，所以對測試實施方案的制定非常的棘手，在網上也查詢了很多，發現相關資料很少，并且大部分都是一些理論指導，沒有講到具體的如何去做的方法，整個方案也不夠全面，沒有實際的實施指導價值。

所以結合了這次自己經歷的數據遷移測試實施以及前人的觀點，寫了這么一篇比較完善的，更具實施指導意義的測試方案，一方面是對這次經歷的數據遷移測試的一個總結，另外一方面是想能有更多的朋友參與到這數據遷移測試的討論中，能為后面可能經歷的同學留下更好的參考資料，由于能力有限，文中肯定有很多紕漏，歡迎大家吐槽拍磚，哈哈！希望后面能把這篇文章完善的更好。

下面進入正文

---

前期準備工作

數據遷移范圍確定

在做數據遷移測試前需要和開發部門確認好數據遷移范圍，主要包含以下幾點：

基本數據遷移

基本數據遷移就是從老庫中把一些老表直接復制到新庫的新表中，或是：

拆表：老庫的老表拆分到新庫的其他幾張新表中去

合表：老庫中的幾張老表的字段合并到新庫的一張新表中去

所以需要提前和開發部門確認好以下問題：

要和和開發一起確認要遷移的是那幾張表？

弄清楚老庫中的老表對應要遷移到新庫中的哪幾張表？

遷移的表中，哪些數據字段需要遷移，哪些數據字段不需要遷移？

老表要遷移的數據記錄條數是多少？

新老系統數據庫表結構變化

1.新增字段和老系統表完全不存在關系

老表遷移到新表中，新表中有些必填字段在老表中沒有的，需要和開發確認這些數據的填寫規則(給什么默認值)

2.新增字段是由老系統特定字段轉換而來

新系統中的一些字段可能是老系統中的一些字段通過一些規則轉化而來的，所以需要和開發部門確認這些轉換規則

遷移范圍統計方法

基本數據遷移

1.直接復制表

2.非直接復制表(拆表&合表)

新老系統數據庫表結構變化

1.新增字段和老系統表完全不存在關系

2.新增字段是由老系統特定字段

測試方案

測試類型分以上幾大塊，下文會對每種類型的測試做詳細的說明：

基本數據遷移測試

要保證老系統到新系統的無縫切換，必須要保證數據的正確性，而將老系統中數據遷移到新系統，首先就要保證所遷移的數據量是一致的，只有在保證數據量一致的情況下，才能進行其他方面到測試，如果數據量都不一致，說明遷移方法或者腳本就是錯誤的，需要尋找原因。

方法1：

測試工具：

Navicat，文本比較工具(以 Beyond Compare為例)

測試流程：

遷移范圍確定：

開發部門統計好本次的數據遷移范圍給到測試部門

數據表導出：

1.對于直接復制的表

根據“遷移范圍確定”中的庫名、表名、條數，通過Navicat工具以txt格式，分別導出對應的遷移前的老表和遷移后的新表，如果不是全表的數據，可以通過SQL語句選擇需要的條數。

以上文中的“表1”為例：

導出老庫old中的老表hxuser，保存到 hxuser老.txt 中

以及新庫new中的新表hxuser，保存到?hxuser新.txt 中

2.對于非直接復制的表

需要在Navicat中先用SQL語句查詢到對應的遷移前的老表數據和遷移后的新表數據，然后再用txt格式導出。

以上文的“表(2)”為例

1) 先用SQL查詢遷移前的老表數據，并導出

2) 再用SQL查詢遷移后的新表數據，并導出

3.新舊數據比對

使用Beyond Compare比較老數據和新數據是否一致，一致則說明遷移正確，不一致則說明遷移中存在問題。

繼續用上文的“表1”為例，比較上一個步驟導出的 “hxuser老.txt” 和“hxuser新.txt”

如果數據一致，則在Beyond Compare中不會有數據差異

如果數據不一致，則在Beyond Compare中能比較出差異數據，并且能直接能定位到差異數據所在，可以統計到新舊數據所有的差異點

方法2：

測試工具：

Navicat，文件MD5生成工具(以Hash為例)

測試流程：

測試流程基本和方法1一致，只有在進行第三步“新舊數據比對”有區別，這里是使用Hash工具。

使用Hash，為新老數據文本生成 MD5 值，并比較2個MD5值是否一致，一致則說明遷移正確，不一致則說明遷移中存在問題。

(MD5可以為任何文件(不管其大小、格式、數量)產生一個獨一無二的md5“數字指紋”，如果任何人對文件做了任何改動，其MD5也就是對應的“數字指紋”都會發生變化，MD5只會對文件內容進行運算，并不對創建時間，文件名等進行比對)

繼續用上文的“表1”為例，分別用Hash為?“hxuser老.txt” 和“hxuser新.txt”生成MD5值

可以看到如果數據一致的時候，MD5值是一致的

當數據不一致時，MD5值也會不同

方法3

測試工具：

代碼腳本(任何一種語言都可以，Python和Java優選)

測試流程：

這里可以開發自動化測試腳本，來完成整個測試，這里因為都是在做字段的比對動作，所以盡量開發可以復用的測試腳本

幾種方法比較：

新老系統數據庫表結構變化測試

新增字段和老系統表完全不存在關系

對于這種“新增字段和老系統表完全不存在關系”的測試，因為都是在新表中給新增字段一個固定的默認值，所以只需要根據開發提供的填寫規則，檢查該字段的所有值是否滿足填寫規則。

測試工具：

Navicat

測試流程：

以上文“表3”為例，這里需要檢查agent庫中表hxuser的status字段的所有值是否都為“1”，其實只需要4步就能完成所有的測試：

1.范圍及規則確定

開發部門統計好所有新加字段填寫規則給到測試部門

2.計算新字段所有行數

計算表hxuser的status字段對應的所有行數，可在Navicat運行SQL語句：

SELECT COUNT(status) FROM hxuser

3.計算新字段中滿足規則的行數

計算status字段中值為1的所有行數，可在Navicat運行SQL語句：

SELECT COUNT(status) FROM hxuser WHERE status=1

4.比較兩次的行數

比較以上2步計算的行數是否相同，如果相同則表示測試通過，如果不相同則表示新增字段中有不滿足取值規則的行，可以通過其他的SQL語句來定位不滿足取值規則的行。

新增字段是由老系統特定字段轉換而來

方法1

測試工具：

代碼腳本(任何一種語言都可以，Python和Java優選)

測試流程：

以上文“表3”為例

1.范圍及規則確定：

開發部門統計好所有轉化字段以及轉化規則給到測試部門

2.測試腳本開發

根據“范圍及規則”，編寫對應的測試腳本，以達到校驗新老字段的所有值是否滿足規定的轉化規則

3.實施測試

運行測試腳本，檢查是否測試通過，若未測試通過，可以做進一步的異常數據定位

方法2

如果沒有條件使用測試腳本自動化測試時，可以使用人工的切片抽樣測試

測試工具：

Navicat

測試流程：

1.數據切片抽樣

用Navicat篩選到需要校驗的新老數據，假設需要校驗的數據有n行，然后對n行進行分段切片抽樣，影響分段的密度，分段后每一段抽取的數量的因素很多，需要綜合考慮之后，確定一個最優值，可以主要參考以下2點因素：

1) n的大小，如果n在100以內，我們甚至可以對n行全量抽取，如果n的值很大，則可以把n均分為若干段，然后在每段中隨機抽取相同的數量的行數

2) 實際工作中可以使用到的工時及人力資源，如果很充足的話，我們可以相對高密度的分段，每段大數量的抽取；

如果很緊張的話，那我們只能相對低密度的分段，每段少數量的抽取。

2.數據校驗

針對上一步抽樣得到的數據，人工檢驗其是否滿足轉換規則

幾種方法比較

業務邏輯測試

“基本數據遷移測試”和“數據庫表結構變化測試”做完以后，需要使用從老系統中遷移過來的數據，在業務系統中進行流程測試，功能測試確保遷移后到數據可用。

在做功能測試時要注意以下2點：

1.需要和開發部門確認新系統會用到老表數據的業務都有哪些，但是每一張表涉及的業務會非常的多，所以想百分百的覆蓋所有業務是非常困難的，只能在有限的資源下統計相對全面的的業務范圍，這些業務點也就組成了針對數據遷移的功能測試范圍。

2.上面這點也說到了，測試的“新系統會用到老表數據的業務”肯定是不全面的，所以最后一定要做一輪全系統的功能回歸測試。

注意點

1.賬號權限，在Navicat操作數據庫時，對于線上數據實施遷移，一定需要提前申請到有線上數據庫操作權限的賬號

2.上述各種測試方法的采用，一定要結合實際的資源情況，不要盲目追求全自動化測試，我們最終目的是要達到測試效果

3.業務邏輯測試中不要去追求百分百的覆蓋率，只需要在現有的資源下，盡可能的提高覆蓋率

原文地址：

https://www.jianshu.com/p/9f6253e6fcc3

喜歡請關注，有用請轉發~

升職、加薪、無漏測-點“在看”

總結

以上是生活随笔為你收集整理的sql语句在navicat中可以查询到所有数据但是在idea程序中不行_数据迁移测试实施方案...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。