【海量数据测试】大型项目中的海量数据迁移测试实践与方案

项目背景(某项目重构) 

      某应用很多联系人的信息重复情况，统一维护到欧若拉系统；并且进行根据相同的客户进行合并联系方式，排除很多客户冗余的情况。（个人理解）

数据分析与准备
线上异常数据处理，通常是在测试环境下面去验证数据迁移的逻辑和规则的正确性，那么必然我们需要对与线上的异常数据情况进行汇总和归类。比如线上数据存在电话号码存在小灵通(134432423424);一三五七八六二一；等特殊的异常数据情况进行分析
线上数据库的字符集判断；保证真实模拟线上数据迁移的字符集情况，一般情况下数据迁移是在老系统迁移新系统过程中就会有不同的字符集情况。建议开发不要再同一个库中进行迁移数据。
线上数据模拟的数量情况和脚本的性能问题，通常数据量是迁移的重要条件之一，一方面是需要技术经理和项目经理进行评估迁移的数据量是否满足线上迁移的条件，另一方面能够模拟迁移脚本的性能问题。
数据表结构检查，新系统迁移老系统会存在表结构长度不一致的情况，这类问题会出现在反迁的情况(反迁脚本是当新系统迁移的数据有更新的情况，则需要反迁脚本迁移回到新系统，保证新系统和老系统的数据一致性；数据迁移的两种情况：正迁(一次性迁移数据)，反迁(实时同步数据迁移))；通常反迁过程中会发现新系统的部分字段长度大于老系统的字段长度，就会引申部分数据截取的逻辑情况。
迁移的规则业务熟悉，对于QA来说，数据迁移不仅仅需要验证迁移的表关联和映射的关系，也需要通过测试脚本不断的通过不同的数据去验证迁移的业务规则，我这边举个联系人重构的迁移的例子：如当老表的姓名迁移到新表拆分为姓和名；(如果联系人姓名大于2个字符，判断最后两个汉字是不是长度为2的称呼，是的话，将这两位截取为称谓；如果联系人姓名等于2个汉字，判断是否最后1个汉字是否为长度为1的称谓，是的话，将这1位截取为称谓 ；l 取联系人姓名剩余部分的前两位，到姓氏库中去匹配是否是复姓，如果匹配成功就返回姓氏，作为姓；剩余部分作为名l 在前一点的前提下，如果未匹配到的，继续提取联系人姓名的前1位，到姓氏库中匹配，匹配成功就返回，作为姓；剩余部分作为名如果都不成功，就将其全部作为姓。称呼和姓氏表)
项目前期QA给出数据迁移的测试方案，包括迁移的数据分析，数据逻辑检查，验证的数据容量情况等。
DBA给出迁移方案评估和迁移发布方案与计划。

数据迁移方案设计
DBA配合数据迁移：DBA角色在 数据迁移过程中，必不可少 ， 但是DBA需要对于开发和PD提出的 数据 迁移 方案，从整个系统的 数据 结构和性能上面进行把关。而且通常需要给开发和PD给出 数据 迁移 的指导方向。包括前期真实的从正式库自动build一部分满足 迁移 需求的 数据 等(保证 迁移 测试的 数据 质量)和后期 数据 迁移 和整体项目的发布计划安排上面，如何在多部门多系统上线带来的一些风险评估等。
实施数据迁移： 迁移包括正迁(一次性 迁移)与反迁(实时同步 迁移)，至于为什么需要分两次 迁移，在前面 数据分析的时候已经提到过。

特性	正迁数据迁移	反迁数据迁移
大批量数据迁移	是	否
一次性迁移	是	否
以分钟单位进行迁移	否	是
转换逻辑比较复杂，需要大批量每字段验证	是	否
转换逻辑比较复杂，需要小批量数据验证	否	否
需要保证整理大批量数据量一致性检查	是	否
需要保证整理小批量数据量一致性检查	否	是
细化业务场景	是	是
测试驱动	是	是
持续集成	是	是
多线程和偏移量方式进行数据检查	是	否

     细化业务场景
首先要对业务场景 迁移的逻辑要非常清楚，杜绝根据看开发的代码实现在去设计 迁移测试脚本；这样会直接影响你陷入开发的对于逻辑思路的圈子里面，必须完全根据需求，这样才可以通过测试脚本检查开发的 迁移逻辑检查。比如下面是联系人重构的 数据迁移的整体业务流程图 
  

 
测试驱动
      根据需求和 迁移 业务流，明确业务逻辑和设计整体的测试 迁移 脚本框架。
      检查老系统正常的业务 数据 迁移 至新系统。For Example
      测试环境：联系人表 数据 的联系电话为：086-021-64230699
      测试目的：检查新表 数据 表的对应联系人表国家号，区号，电话
      测试的脚本举例：
      assert_equal(wt,deal_phonefax(wt[contact_typed])[0],db[0],"country_code","检查的类型为：#{contact_type},Aurora_Contact_Info")
      assert_equal(wt,deal_phonefax(wt[contact_typed])[1],db[0],"area_code","检查的类型为：#{contact_type},Aurora_Contact_Info")
        assert_equal(wt,deal_phonefax(wt[contact_typed])[2],db[0],"phone_number","检查的类型为：#{contact_type},Aurora_Contact_Info")
         ------这边尽量把断言和逻辑处理尽量抽象出来，这样可以更多的进行重复调用。(正常 数据 不预警)
        检查老系统异常的业务 数据 迁移 至新系统。For Example
通过断言输出文档来告诉用户 数据 迁移 老系统的表字段与新系统的表字段与需求不符合。举例异常 数据 日志：(该异常日志是在偏移量在0到1000条 数据 日志)
 
         全量 数据检查，当 数据迁移后验证； 数据量检查是 迁移验证的首要目的，一旦出错则中断验证脚本 数据。( 数据量是 数据迁移的重要检查点之一，而且是放在逻辑检查点之前)
       测试框架介绍 



持续集成 
  

 
CaseStudy分享
             Case one
问题描述：
中供 迁移欧若拉系统过程中，在500多万条 数据中，有70几万条 数据的电话，手机号码，传真，EMAIL存在乱码问题。
原因分析：
a、 由于前期没有评估到测试环境的 数据是否涵盖线上的异常 数据情况。
b、 测试环境模拟 迁移测试的 数据库字符集与线上的 数据库字符集存在差异。
措施和方案：
a、 PD在项目前期拟定 数据迁移数据分析的方案，在与技术经理、DBA、QA、项目经理确认后续 数据迁移的具体方案。
b、  数据迁移前期，DBA自动build线上 数据至测试环境； 数据异常 数据情况涵盖线上所有的 数据情况。
c、 DBA同学给出线上 数据库表结构配置情况与 数据迁移发布方案，并且与项目成员确定。
Case two
问题描述：
今早发现客户的联系人全部显示为“先生”且修改时间全部为2010-11-5
原因分析:
  由于DBA错改了联系人表的性别字段长度，导致大批量 数据性在 迁移的时候都改成了F。
措施与方案：
a、 DBA同学给出线上 数据库表结构配置情况与 数据迁移发布方案，并且与项目成员确定。
b、 由于真实 数据库环境QA没有权限访问；通过预发布环境验证字段是否异常。
Case three
问题描述：
项目后期，某应用系统的反迁应用老系统的定时同步脚本的运行时间超出客户的承受范围
原因分析：
  由于前期 数据分析没有及时评估，反迁做更新，删除，新增操作的实时同步时间是否满足客户的需求。
措施与方案：
a、    前期QA给出 数据迁移的 迁移方案中，需要PD给出反迁与正迁的性能要求。
b、    需要DBA同学评估线上与测试环境的集群差异，真实模拟线上 迁移情况。
总结
目前项目 数据迁移过程关注度不够，开发还是停留在人肉比对的测试手段；对于QA的测试验证信心不足，这方面会大力培训 数据迁移方面的方案和风险。
项目发布后发现的一些问题，只是给出处理此问题的方案；没有很好的在根本问题上面解决，不能避免下次出现这样的问题再次发生。
项目迭代的版本不够清晰，开发想怎么修改开发脚本就改，导致持续集成运行频率加快。
DBA同学对于整体的 数据迁移把控力度不够，还停留在QA同学希望做线上同步 数据做模拟线上 数据迁移的测试。并且很多线上 数据库结构信息和 迁移发布信息不够透明。
本次 数据迁移验证1万多 数据左右；但是线上 数据量是500万，如何的 数据量比例才能满足完全测试，需要我们QA在 数据迁移这块做一定的容量规划；为以后的项目做参考。
Review开发的 迁移脚本，容易被开发的思想左右测试 迁移脚本；这点一定要根据需求来设计。
FAQ
推荐文章： http://www.infoq.com/cn/articles/thoughtworks-practice-partii