1

业务背景

网约车业务作为滴滴的核心业务，系统架构复杂、整个订单链路涉及众多下游服务，整体迭代频率高，同时在产品形态上通过不同品类提供差异化服务能力，整体品类从最初的专车、快车延展到如今多个品类，这就导致在日常的功能迭代中需要实现特定品类场景或者特定功能测试的成本非常高。举几个典型的例子：

A拼车场景：

需要两个乘客同时登陆、同区域发单，由同一个司机实现两个订单的接单并完成履约。

B连环派订单场景：

需要司机在未完成上一单的情况下，已经接到下一单。

这两个典型的例子是网约车同学测试工作中常见的测试和验收场景，但是上述的场景对于测试乘客账号所在区域和测试司机账号具备的听单能力等要求很高，往往需要通过多个端同时操作，耗费大量的时间，结果也很难完成该场景的构造，因此各个业务线对于便利的订单场景构造和测试能力有着强烈的诉求，网约车质量效能团队在不同的业务发展阶段结合业务特点形成了具备服务化、标准化的订单测试能力，以求提高研测效率、保证业务高质量交付。

2

订单测试流程

网约车整体订单交易链路上下游涉及多个服务、服务与服务之间相互关联，在核心打车业务中，服务端API向上接收端上请求并组装返回，向下串接订单、计价、收银等业务中台的各个系统，完成整个打车流程。

在订单测试中，不同的上下游依赖订单状态流转、为了完成订单过程流转、订单测试通过调用服务端主流程API，实现节点间参数传递完成流订单程串联，进而实现订单状态变更。

3

订单测试演进过程

端造单测试(2015年以前)

业务应用

业务发展早期的测试模式完全依靠端实现订单测试，在真实乘客端模拟乘客进行价格预估发单、通过真实司机端实现完单，进而完成场景验证。

端造单测试

“

测试优势

端测试具备高度仿真性、完全模拟在正常业务场景下乘客发单到司机完单的全流程，整个过程不存在业务mock、场景验证更加全面、完整。

“

测试不足

• 由于纯端测试走正常的分单和派单逻辑，因此在日常的业务测试过程中需要在特定地区进行造单，尽管如此也不能保证每次都可以被指定司机接单，成功率较低。
• 端测试需要通过代理配置打到指定环境，这就导致每次造单测试需要经过复杂的代理配置。
• 复杂订单场景通过端构造步骤繁琐、非常耗费人力。

工具化造单测试(2015年-2020年)

“

业务诉求

端模式是业务初期研发测试的主要手段，伴随着网约车业务的快速发展，业务复杂度越来越高，单纯通过端已经不能完全模拟线上订单场景，业务上需要更复杂的发单和接单场景订单，需要更高的接单成功率、更稳定的造单能力。

“

工具建设

通过构建订单流转工具维护高频订单测试场景、mock司机接单，通过工具造单方式，全部脱离或者半拖离端的模式实现特定订单场景链路构造。

在工具侧主要实现4类核心能力：

• 订单场景库：维护核心订单场景的参数信息。
• 订单流转：mock乘客和司机全流程测试面板。
• 司机流转：mock司机全流程面板。
• 通用接口请求：支持接口测试。

工具化造单测试

“

工具不足

随着业务的发展，基于端+订单流转工具的模式的弊端开始凸显出来，主要体现在3个方面：

• 场景的更新和维护存在延迟，由于工具的维护方主要在质量中台，这就导致业务场景的迭代变化很难同步到工具维护方，并且随着敏捷开发的推进，这种延迟越发明显。
• 订单流转工具的流转结果无法在不同用户之间进行协同共享，整个订单测试过程无状态管理、难以有效跟踪整体测试流程。
• 订单流转工具目前只能支持主流程的订单链路测试，针对更具有一般化的订单分支支持力度不足，并且由于人力原因，新增场景的周期一般都在天级别，制约业务迭代。

自助化造单测试(2020年至今)

“

业务诉求

订单流转工具经过长时间积累，在场景上具备了网约车核心订单流转场景超过70多个，但是由于工具的维护和迭代固有的弊端，存量场景和线上真实场景在数量和仿真性上差距明显，业务上希望可以通过在现有订单流转场景的基础上可以快速构建个性化场景链路测试，实现订单测试场景的快速搭建。

“

功能架构

基于可视化、标准化和智能化的原则，在订单流转工具的基础上，构建了自助化的造单测试能力。

智能化造单功能架构

基于自助化造单测试的变化点：

• 可视化的链路组装能力，通过简单积木搭建方式实现链路场景沉淀。
• 便利的场景共享能力，实现跨团队合作协同。

针对订单场景多样性的核心诉求在于将场景的维护和迭代交给一线业务同学，让业务同学可以自己生产场景、应用场景，因此提供便利的链路组装调试能力、和互相协同共享能力，将很大程度赋能业务同学实现自助测试。

“

链路组装调试

订单场景编辑调试的难点主要有两方面：

1、初始化参数构造困难

2、场景编排调试耗时严重

解决思路：通过链路数据预置降低用户获取参数成本，同时基于组件化思想将编排调试做到更灵活易用。

具体解决方案：

链路编排调试

• 在链路编辑过程中打通把脉日志系统，在历史日志中基于链路抽取规则经过数据脱敏实现链路数据的初始化，同时基于模版复用的能力，已经沉淀到平台的链路场景也可以提供初始化能力。
• 在链路编排时，将数据、环境、链路进行组件化打包形成链路节点，基于web拖拽实现链路调整，场景沉淀时通过标准化的数据拆分持久化存储到DB，为后续数据分析统计以及场景复用提供便利。

编排效果：通过页面拖拽快速进行链路调整调试如下。

web编排

“

场景协同共享

• 场景协同

将业务沉淀的场景归属属性进行扩展，形成跨归属用户的协同属性，通过协同将沉淀场景进行复用，形成跨业务线的订单测试管理和管控。

• 共享池

用户可以将调试好的订单场景推到本部门共享池，通过共享方式将订单场景的协同从点对点扩展到点对面，所有的用户都可以方便的在共享池使用已经沉淀的订单场景。

协同共享

4

应用效果

目前通过自助测试能力已经沉淀330多个订单测试场景，且在持续新增中；使用人群方面、每月支撑500多位用户调试执行。

5

总结展望

订单测试演进至今，在各个业务团队的协同合作下，在效率和可用性方面有了阶段性发展。但是随着业务的不断演进，针对订单测试的诉求在不断迭代，订单测试能力需要不断优化适应业务变化，基于现有业务特点，在未来会在以下两个方面继续探索：

赋能测试左移

自助测试降低订单测试构造成本，让业务同学可以快速的构建的订单测试场景，实现问题的提前发现，助力测试左移，在流程中订单测试需要打通环境准备、测试集成、结果反馈、实现无感知的全流程订单测试。

智能场景构建

进一步通过线上流量分析，场景数据回放等实现测试场景的智能化构建，降低场景构造成本，实现一键式场景链路搭建验证。

END

作者及部门介绍

本篇文章作者宋玉磊、于敞，来自滴滴网约车出行技术团队，出行技术作为网约车业务研发团队，通过建设终端用户体验平台、C端用户产品生态、B端运力供给生态、出行安全生态、服务治理生态、核心保障体系，打造安全可靠、高效便捷、用户可信赖的出行平台。
招聘信息