正文
文：崔蓉
本文原创，转载请注明作者及出处
交易平台这一年进行了几次大规模的迁移工作，从最开始的商品域，到订单域，现在订单退换货（RMA）的迁移也已经完成。虽然几个系统现在在线上已稳定运行，但是在测试过程中还是碰到了一些问题的，在此做个简要的总结，以便之后类似的项目借鉴。
迁移的测试范围大致可以分为：数据一致性测试、接口逻辑测试、功能测试、数据同步测试、性能测试 。上线前还进行了与各相关业务方间的预演，及回滚方案的预演。
数据一致性测试
由于迁移需要做到调用方无感，因此数据一致性显得尤为重要，在此块我们做了 .net 与 java 接口请求参数一致性对比、返回值一致性对比及 DB 数据的一致性对比。
我们用 python 自动化脚本实现此块测试，引入了 python 语言的装饰器概念，通过传递环境参数以指定测试用例运行的环境，以做到迁移结束后可简单的通过只修改环境参数而实现自动化脚本的复用，如下图所示。
def deco_compare(env=1, db_compare=False, ex='', db_ex='',
no_additional=False, ex_only_none=False,
is_none_equal_empty=False):
def deco_resp(func):
@wraps(func)
def wrapper(*args, **kw):
print '执行用例 %s():' % func.__name__
func_result_one = None
func_result_two = None
# 只调用java创建订单接口，不进行任何比对
if env == 1:
...
# 只调用dotnet创建订单接口，不进行任何比对
elif env == 2:
...
elif env == 3 or env == 4:
# 先调用java接口，后调用dontnet接口，并比对返回值
if env == 3:
...
# 用于query-order中部分接口是从其他服务迁入的情况
elif env == 4:
...
# 如果要求不进行数据库对比,只比对response
if db_compare is False:
...
# 如果进行数据库比对，先比对response，再对比数据库查询数据
elif db_compare is True:
...
return func(*args, **kw)
return wrapper
return deco_resp
测试过程中，主要是使用 env = 3 或 4 的情况，在进行数据对比时，我们使用了 json_tools 工具，可以对传入的两个 json 体进行对比，并打印出值与类型的差异、属性名的差异。
实现的步骤为：
-
接口在 java 环境中请求一次，记录结果
-
相同参数在 .net 环境中请求一次，记录结果
-
去除无需对比的字段（如新建订单时生成的订单号）后，对比 1、 2 的结果是否相同
-
MySQL 中查询需要校验的字段，记录结果
-
在一定的 mapping 规则下，根据上一步的 SQL 查询语句生成 SQLServer 中可以使用的语句，进行查询，并记录结果
-
去除无需对比的字段后，对比 4、 5 的结果是否相同。
通过此方法，我们可以保证迁移之后的接口及 DB 数据结构与迁移前的相同。
接口逻辑测试
商品系统、订单系统及 RMA 系统所提供的大部分为接口，所以接口逻辑的测试不仅是迁移过程中的重点，更是日常测试中最为关注的部分。
以订单系统为例，测试需要覆盖下单、改单、配送、确认收入、查询等功能模块，下单中又包含了 14 种商品类型、 24 种订单类型及 8 种促销优惠方式。
![]()
如何将如此复杂的场景覆盖全面，是我们在测试之初讨论最久的问题，最后经过几次的讨论，我们确定了覆盖的流程，以商品类型作为大的划分，加入组合的促销方式，生成对应的订单类型。
由于测试的很多场景具有相似性，我们在脚本中大量采用了参数化的方式传递不同类型的数据，使代码简洁并很大程度上减轻了工作量。
我们还把一些很通用的业务功能抽取出来，比如不同类型的基础订单创建、订单收入的验证等，以供流程脚本中直接调用。
这部分的测试贯穿了整个测试过程，保证了上线后并没有出现流程性的问题。
功能测试
交易平台并没有太多外显的功能测试需求，但是功能是用户最先所见的部分，因此后台的功能测试也是极其重要的。 后台功能的使用者主要为客服、运营及财务等，因此在测试前先与产品进行了沟通，列出了功能测试部分的测试要点，上线后并没有出现大的异常。
数据同步测试
此次不仅包含了程序代码从 .net 平台到 java 的迁移，也包含了数据库从 SQLServer 到 MySQL 的迁移。
数据同步包含了起初的全量数据同步（dataX），及增量数据的反向同步（yugong），这保障了上线后用户数据不会丢失，也保障了万一出现回滚操作时 SQLServer 及 MySQL 数据的一致。
由于每次同步的日志很多，且遍布不同的文件夹，因此我们通过脚本分析同步的日志，打印出所有的异常，上线后未出现因数据不一致而产生的问题。
性能测试
性能测试的重要性是毋庸置疑的，尤其是上线时双十一双十二的活动近在咫尺，订单域的压力可想而知。
横向团队帮忙做了重要接口的压测，我们自己也对主要的流程及核心功能做了业务逻辑侧的并发测试。
ThreadPool 库可以很方便的实现并发的需求，如下：
import threadpool
def run_thread_pool(self, threads_num, request_num, target_request):
"""
用于创建线程池
