2020年初，电商研发团队展开了交易中台建设，基于主数据的思路，通过统一逻辑接入、同步加工、无逻辑收单接入，将几十个业务线融于一体。中台测试的难点在于数据多样性、量级大、一致性难保证、接入没有标准。1. 自动化用例代码耦合度高：每个测试重复编写用例中的校验点，没有复用能力。2. 校验逻辑不内聚：中台同时对接多个业务，多个测试人员去测相同的系统，不同的业务流程，各自编写完用例，覆盖率各不相同，后续还要沟通共识，产生极大的认知成本。3. 缺少跨多个数据源的全表自动化比对能力：中台涉及业务库、同步库和主数据库的一致性问题，数据复杂度高，数据量级大，测试必须具备验证三套数据库数据一致性的手段。为了优化上述问题，对自动化测试框架进行了如下的升级改造
2）数据具有行为，如：订单数据可以创建、查询、取消等等。3）行为包含上下文校验规则，如：代付款的订单取消预期成功，反之则预期失败，又或者取消会还库存、还券、还积分等等。1）将规则抽离，并且纳入数据和行为做被动校验，一次编写处处校验，测试人员只需要关注流程编排、数据驱动和并发测试即可，极大地降低了测试人员自动化用例编写的成本。2）测试人员持续维护内聚的规则，相对于维护散乱在用例里的校验更加容易，不易遗漏。订单数据的多样性导致我们有非常多的规则逻辑，线性校验，代码会非常繁杂；而其中有很多是通用规则，通用的东西不需要重复的去维护，为了实现分层思想，方便管理规则，我们引入Drools规则引擎我们可以把订单的核心规则维护到drl规则文件内，根据drools提供的分组功能，灵活的分成基础规则组、定制规则组、差异化规则组等，并且可以随时调整，再搭配其调用规则校验时支持的各种匹配方法，让我们可以非常方便的去按需求触发规则校验无论是接口的自动化回归，还是同步数据对比测试，传统的解析结果提取字段去校验，而想要方便的提取字段，就要封装对应的数据对象，而手动封装的开发成本也并不低，所以，我们采用jooq框架，该框架可自动生成数据库访问的实体类代码，引入接口对应的开发jar包，用反序列化的方式获取接口出参对象的实体类操作代码；
我们把自动化工具设计成多层结构，功能模块相互独立，以达到更加灵活和通用的目的，
电商中台，承接着车服务、旅行家、经销商、家家内购等几十个业务线的交易数据，通过同步程序或者收单接口写入中台主库，测试需要保证数据正确性，而动则几十万的数据量级，我们起码需要抽取一定量级的数据测试才具有代表性；
自动化前我们的测试方法是：
手动查询几千/几万条数据，复制进excel，用对比命令测试
缺点：操作费时费力，效率低，结果不方便查看
自动化实现：
1）自动查询双方数据源，对比字段，输入结果；
订单数据的多样性，导致测试场景繁多复杂，回归测试，人工测试成本高、效率低下，
并且因为交易系统逻辑复杂、学习成本高，测试依赖经验，导致不熟悉的人无法测试，
无法靠人力横向扩展，提升效率；
自动化实现：
1）工具自动回归，提升效率：
把订单的价格、状态等核心逻辑规则，维护成一套模板，对各场景命中的规则自动校验，
2）核心规则自动化校验，让不熟悉的人也能进行测试，提升了横向扩展能力；
各业务线同步进主库的订单数据，少量会产生错误，我们缺乏主动发现错误数据的手段；
自动化实现：
1）定期自动对一段时间内的订单按规则回归校验，找出错误数据
1）回归测试效率提升
订单核心功能回归，之前需要1小时的工作量，现在只需要几分钟；
各业务线数据同步的对比测试，之前需要1天的工作量，现在只需要30分钟；
之前线上经常会有同步出现的错误数据，往往是靠别人发现告知，
现在我们主动筛选出错误数据，快速推动解决；
我们可以与自动化平台相结合，配合前端页面能够更好的管理和维护，也能自动托管实现一些接口的定时自动回归；我们还可以把自动化与精准测试diff引擎相结合，这样可以根据自动化测试用例的覆盖率反馈不断的对用例进行调优、校准和补充，直到最后获得一套高覆盖率的自动化测试脚本。这样不但大大减轻了手工测试的人力消耗，同时也提升了自动化测试的准确性，让结果更可靠。
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
