京东到家数据构造平台设计与实践

文｜袁盼 李磊

编辑｜刘慧卿

一 前言

二 背景和目标

三 系统架构设计

        3.1 系统介绍

        3.2 典型功能详解

四 成果与展望

一 前言

随着到家业务与小时购业务的快速发展，系统迭代日新月异，测试效率面临巨大挑战。通过我们调研和分析，发现人工准备测试数据的工时占整个软件测试周期的30%及以上，且准备测试数据的过程极其枯燥繁琐。如何快速响应各业务方提出的不同场景测试数据支持，是我们面临的一项极大挑战。本文将会带你详细了解京东到家数据构造平台的诞生及应用。

二 背景和目标

项目的发起方为京东到家质量提升部业务测试组，发起原因主要有以下两个方面。

2.1 构造数据成本高且不灵活

作为业务测试部门，需要随时支持来自多个业务方的测试需求，而人工准备测试数据不仅时间成本高而且不灵活。

首先，时间成本方面，我们以一个达达专送全履约正向流程为例，创建一个订单需要通过到家 App、商家 App、达达 App，三端多步骤来实现订单状态的流转，整体构造一个全流程正向订单至少需要20分钟。

以上示例只是最简单的一套正向订单流程，稍微复杂一点的还包括带有优惠券、运费项以及会员红包等各种叠加场景的测试数据，这种情况下就需要多个系统的测试人员一起配合来完成测试物料的准备，耗时耗力。

其次，在灵活性方面，静态数据还好，动态数据就需要相应人员预留时间跟随项目来支持数据构造，如果碰上多个项目同时需要支持，就更加崩溃了。

如上图所示，测试数据一般分为静态数据和动态数据两种。比如商家信息、门店信息、商品信息、配送方式等这样固定的数据为静态数据；像 Promise 时效、时段运费等有时效性的数据或者需要在联调及测试时配合修改的数据为动态数据。

2.2 提高业务测试人员的技术能力

业务测试同学常年扎根于需求测试任务中，有非常丰富的业务测试经验，但技术能力却得不到明显的提高，每个业务测试同学都迫切需要一个机会来提升自己的技术能力。只有业务测试经验和技术能力同时提升才能有效提高测试质量和效率，测试同学才能在团队中得到更全面的发展。如何让大家快速参与到平台的建设上来是我们面临的新的挑战。

首先，大部分业务测试同学已经具备简单的代码开发能力，但模块化开发能力欠缺，需要考虑如何辅导大家快速进入状态并上手开发。为此，我们在完成技术框架搭建后，专门写了一个 demo 模块，并且准备了详细的框架使用步骤及模块开发步骤，让大家可以根据 demo 快速学习并上手开发。

其次，我们成立了平台开发小组，并选了三个小组长，在开发过程中遇到问题时，由小组长对其进行有针对性的指导，解决他们的当务之急，并传授开发经验，让他们在遇到类似问题时能举一反三。

我们最终的目标是想开发一个平台，把各个模块的数据构造能力进行一个整合，缩短数据构造时间，让各个角色都能随时构造自己所需要的测试数据，释放业务测试同学人力的同时，又能使参与平台开发的业务测试同学技术能力得到一个提升。

三 系统架构设计

3.1 系统介绍

采用成熟的Springboot+Mybatis+Vue框架。

基础功能接入了账号系统、配置系统，支持环境切换、权限控制、埋点数据统计

整个平台面向用户包含了京东到家、达达配送、海博全渠道、京东主站侧的各业务线的产、研、测同学。覆盖了多种业务类型下的场景构造，涉及多个平台系统。

3.2 典型功能详解

3.2.1 一键下单

订单是整个到家业务中极其重要且不可或缺的核心流程，无论是下订单前的系统流程还是下订单后的后续流程。从统计的实际使用数据来看，一键下单功能使用频率颇高。

一键下单功能实现逻辑是模拟真实用户提单流程，抓包获取用户提单操作触发的各系统接口，除了抽取少部分可参数化的入参供用户灵活选择外，底层不另做其它业务逻辑处理，完全按照真实提单流程进行，这在提高下单流程效率的前提下，保证了自动化生成数据与真实下单数据的一致性。

3.2.2 订单状态流转

订单后系统，如订单系统、拆分系统、售后系统、赔付系统、计费系统、评价、结算等，无论是小时购订单还是到家订单，都依赖提单后的订单状态流转到特定的状态节点，一个需求的测试用例往往多达几十个订单。在上文也提到过，一个订单操作需要20分钟，一是操作流程繁琐，二是要完成订单状态流转，需要测试人员深入了解各端系统的操作流程，学习成本较高。

而在“哆啦 A 梦平台>订单相关>变更订单状态“里，可直观便捷地支持一键操作95%以上的订单状态流转，如下图：

提单后订单要流转到任何节点只需一键触达即可。

达达专送订单流转：

商家自送订单流转：

还提供一些日常不易构建的运单异常状态变更等功能。

3.2.3 优惠券支持的业务范围

在新零售业务中，营销活动占据重要位置，优惠券是其中必不可少的一个环节，无论在前期活动创建还是后期下单用券过程中，与很多系统密切交互，所以在各系统联调与测试过程中，需要频繁创建不同类型的优惠券。但在建券过程中，需要输入的参数既多流程又长，占用较多业务测试时间。

目前本系统可支持创建多类型、多渠道、多承担方的一键创建优惠券功能，尽可能地满足相关产品、研发、测试同学在工作中的需求。

3.2.4 权限限制

哆啦 A 梦构造平台主要目标用户为到家侧、达达侧、海博侧、主站侧的相关人员，数据平台作为日常工作高频使用的查询工具，如何让正式数据与测试数据隔离开显得尤为重要，为了避免不熟悉业务的人员误操作正式商家数据，造成线上事故。对此我们在底层划分了两类，一种是基础功能（非敏感信息的查询与创建功能），会根据输入的商家、门店、订单等相关信息获取到对应的商家编号与配置系统内可支持操作的测试商家白名单进行一一校验，在白名单内的继续流转，不在白名单内的提示无权限操作;另一种是敏感功能，在原有基础功能权限限制的基础上加一层人员使用的校验，以用户 pin 为维度限制，把风险降到可控范围内。

四 成果与展望

成果

目前系统已经开始对外提供服务，前面介绍的订单全履约流程，现效果如下：

上图展示的是单个订单缩短的时间，实际在一个需求中，一个订单并不能满足全部功能点的验证，可能需要30+单子才能测试完成，这时此工具就可以节省整体测试周期的30%。

按如下图功能排名：

一键下单：调用量4900+，由之前20min->20s，节省1600h+

变更订单状态工具：调用量4000+，由之前2min->1s，节省127h+

售后单工具：调用量1400+，由之前2min->1s，节省44h+

此平台目前所支持的构造能力，并不能覆盖所有的测试场景，像一键下单、订单/售后单的状态流转等，对提单后测试场景的数据构造非常实用，但对提单前的一些测试场景，主要还是由专业的测试人员在 app 端进行常规测试。

数据构造平台不仅大幅提高了构造测试数据的效率，也带动了业务测试同学更高涨的学习热情，使个人能力和价值在工作中都得到了充分体现，团队技术氛围得到了提高。

展望

哆啦 A 梦平台已支持140+功能的数据构造能力。而构造数据只是业务测试步骤中的一个环节，我们可以利用现有的构造能力对外提供构造数据的接口，结合自动化平台，完善测试流程，更好的提高测试效率。

我们要像哆啦 A 梦的百宝袋一样，应有尽有！