前幾天都在忙著上駕校，測試時代論壇升級好幾天都沒法進去看資料，今天運氣不錯，論壇可以進去了，可以翻翻老貼，把一些自己認為比較有價值的整理整理然后收藏；看完測試時代的接著就要翻一翻51testing的了。

今天收錄的關于歷史數據遷移的測試，通常很少碰到；在我過去工作的5年多里，運氣還不錯，做過一次這方面的測試任務，在此記錄記錄。

歷史數據遷移的測試

歷史數據遷移，說白了就是數據庫數據遷移，比如：把一個ACCESS數據遷移到ORACLE數據庫，或者是其它數據庫之間的數據遷移。

有的人可能會想，既然是數據庫數據遷移，不需要做測試需求的確認了，檢查一下數據就可以了；有的人由于沒有做過這類測試、第一次碰到，傻眼了這可怎么測試啊，書籍上說的黑盒測試技巧里并沒有歷史數據遷移的測試方法，該怎么辦。

我第一次接到這個測試任務時，感覺很特殊，因為實在少見，怎么做呢？

首先，在做歷史數據遷移測試之前，也需要做測試需求的確認，主要是弄清楚用戶為什么要做這個歷史數據的遷移。

我記得，當時這個案例的用戶是因為它的一個系統，之前的老系統是在ACCESS數據庫中存儲的，后來有了新系統、新系統的數據是在ORACLE里，為了把數據統一，就需要把老數據導入到新系統的數據庫ORACLE里，便于新系統能查看到即可。

從這個需求，得出如下測試需求點：

1、 ACCESS數據庫里有很多張表，要和用戶確認要遷移的是那幾張表？弄清楚老庫中的老表對應要遷移到新庫中的那幾張新表？

2、 遷移的表中，那些數據字段需要遷移，那些數據字段不需要遷移？

3、 老表遷移到新表中，新表中有些必填字段在老表中沒有的，用什么數據填寫？

4、 老表遷移到新表中，老表數據在新表中沒有對應字段存儲，怎么處理？

5、 老庫老表數據與新庫新表重復，數據怎么處理？

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

和用戶弄清楚這些疑問點后，還需要和開發確認疑問點：

1、 老庫中老表的表關系遷移到新系統新表中的表關系是怎樣的？

2、 確認用開發編寫的數據遷移程序遷移完后的數據檢查方法？

確認上面的疑問點后就開始做工期時間計劃安排、編寫測試計劃和測試用例。

    其次，要注意數據遷移后，新系統對老數據功能的使用。

記得當時在確定了測試需求點后，在編寫測試用例時，我重點使用了一下新系統、確認新系統會用到老表數據的業務都有哪些？把這部分業務也作為測試用例點進行測試。也許有的人會想，只要后臺把數據庫表正確遷移完畢，前臺應用程序應該是沒有問題的，不需要檢查的。這是一種偷懶懷著僥幸心理的想法。回到之前的用戶需求，用戶為什么要數據遷移，目的就是為了能在新系統使用這些數據，因此在數據遷移完畢后，還要重點的檢查老數據在新系統中的使用。

就在這個數據遷移測試的過程中，我跟我們的部門經理說，用戶肯定會有其它的需求、遷移這些數據肯定要做一些業務處理、新系統程序可能會有改動。結果在遷移數據做完后，用戶真的提出了新的需求，被我說中了。^_^。為了讓這些老數據在新系統能很好的完成新業務處理，要對老數據進行特殊標識后才進入新系統、同時新系統針對這部分數據相應要增加功能。這就是用戶需求沒有摸透、沒有看清楚需求背后的真正需求，導致遷移程序需要再次進行修改。

有些人，在測試數據庫遷移時，一開始想到的理論知識就是：測試數據的完整性、可靠性、有效性；有的人就會問，數據的完整性、可靠性、有效性的測試用例怎么寫啊？說實話，我也沒有寫過數據的完整性、可靠性、有效性的測試用例，我只會根據用戶給的需求、整理并發掘測試需求，根據需求形成測試用例。也許數據的完整遷移測試點就屬于數據完整性測試用例吧；數據遷移完后新系統對遷移數據可正常使用并處理業務，就屬于數據的可靠性、有效性測試用例吧。

不管怎樣，在測試的過程中，一定要弄明白用戶的真正需求，才不會走彎路，雖然只是個數據遷移，但不只是簡單的數據遷移，背后有著很多不為人知的故事！！！！！^_^