得物App订单配置类文案测试右移实践

1. 背景

得物App版本订单详情页中的文案有对应的文案配置后台统一收口文案取值，优化订单详情页的信息展示效果。

基于交易侧业务的广度和复杂度，仅仅靠人还是有一定的局限性，当面对此类业务特性时，功能为主+技术辅助的方式也更多的被应用，对于此次的需求，得物小伙伴们也尝试使用更多的方式尽可能保障线上质量，接下来就介绍下配置类文案测试订单侧的测试右移实践。

2. 分析思考

2.1 需求简介

在得物App的版本迭代中，为提升用户体验，产品侧提出订单详情页优化新需求，定义客户端模块组件，制定各个模块的信息展示规范，重新梳理订单详情页的全部文案，搭建文案配置后台，支持订单详情页头部文案支持可配置，方便用户清晰了解订单详细信息。

功能包含：

• 支持所有订单状态节点文案灵活配置
• 订单各状态节点配置基础文案
• 特殊订单类型支持差异化文案配置
• 文案支持变量参数可选项

取值逻辑：

• 命中灰度，取对应订单节点配置
• 订单状态节点下有配置差异化文案，取差异化文案
• 未配置差异化文案，取基础文案。

2.2 测试策略

基于订单侧多订单类型、多业务流程等特性，此次采取的测试策略为：流程相同订单取一种类型测试+特殊订单类型重点覆盖的方式。

2.3 订单配置类文案测试的难点痛点

• 订单业务现状：订单侧目前已有的订单类型有几十种，已有的正向订单状态更是有很多，并且部分订单有着自己特殊的业务流程。
• 作为交易的中间链路，订单侧对接的上下游以及自身业务系统的交互较为复杂，对改动点感知不及时。
• 线上线下配置不一致。
• 涉及到所有订单类型的需求，目前多数采用的测试策略为：流程相同订单抽一种类型测试+特殊订单类型重点覆盖+自动化case回归覆盖，全量回归单纯靠人力不太现实。
• 技改项目多，目前线上灰度中的功能较多，未全量灰度完成时，测试需要同时覆盖新老版本。

2.4 文案质量保障手段优化

此次新需求所涉及的业务广度以及测试难点和痛点，研发跟测试也进行了复盘，针对当前难点痛点分析讨论，引出下面几点尝试：

（1）后续测试中，特殊流程订单类型重点覆盖策略不变，开发提出测试环境保留最复杂配置 。
（2）自动化验证文案展示，需要做到全量场景覆盖。
（3）线上所有订单类型、所有节点文案在业务监控平台新增脚本尝试。

3. 优化实践

使用者的行为不可预知，那么在代码设计开始就需要从严考虑，对所有可能发生的场景底层都要做基本处理，同样对于测试来说，各种可能发生的场景都需要考虑到，基于上述难点痛点以及有限的资源情况下，测试侧同样也需要考虑更多的方案。具体如下：

3.1 方案分析

（1）测试环境保留最复杂文案配置

讨论下来，该方案不可行，有些字段只有特定订单类型有，都配置成最复杂文案后，会有部分订单类型展示成${xxxx}，迷惑测试。最终采用现在默认配置成与线上一致的文案。

（2）自动化脚本进行接口测试的方式校验

使用自动化脚本进行接口测试的方式讨论发现有如下优缺点：

（3）业务监控平台增加脚本实现线上提前灰度

得物自研业务监控平台实现提前灰度方案优缺点如下：

3.2 实践

针对无法覆盖到线上真实配置并且对所配置的内容check异常，结合上述两种方案的优缺点，在业务监控平台增加脚本刚好可以实现这一部分场景的覆盖，在后续的迭代规划中，类似的功能仍有不少，讨论后决定对此类功能的校验增加业务监控脚本对线上数据check并告警，上线后能提前灰度，发现问题。

3.2.1 业务监控平台

得物自研的一款用于数据和状态验证的平台，数据流向如下：

3.2.2 脚本实现

通过业务监控平台建立校验接口返回值文案中包含异常数据则飞书告警的规则，及时发现问题，具体实现如下：

• 在业务监控平台编写数据校验脚本
• 通过平台监听上线后命中灰度的数据，脚本实现check接口返回的文案中包含“$”的异常数据（包含$则变量未解析）
• 配置监控规则，及时发现存在的异常数据
• 打印出错误信息并线上飞书告警群及时告警
• 线上有最全的订单类型以及各种状态的数据，打印各种订单类型、各种状态下的文案，检查文案展示正确性。

3.2.3 逻辑图

3.2.4 告警

目前线上告警采用的最多的是飞书告警，告警如下：

3.2.5 后续规划

业务监控平台目前支持防资损类的巡检告警，后续平台功能支持场景增加后，可满足更多的场景，则可以替代部分人工测试，提高测试效率。

业务监控平台若是可以支持预发环境，则配置中心在预发环境的配置同步线上配置，可以在预发验证文案的变更。业务监控平台能够支持指定机器访问，发布后摘流，线上验收文案的正确性。

3.2.6 配置类文案测试展望

通过在业务监控平台增加脚本实现文案测试右移，右移到预发或者线上，拿线上最全的数据、线上真实的配置，获取各种订单类型、各个状态下的真实文案。同时大大减少了造数的时间损耗，提效的同时保障业务质量。

5. 总结

文案虽小，但体验不佳，面对订单侧深而广的业务交互，如何能够高效且有效测试，是每一个订单组测试小伙伴都在不停思考和探索的问题，包括当前应用自动化case、流量录制回放、防资损监控等方式，都是回归测试的利器，一起为质量保驾护航。方案仍在不断迭代中，我们的测试探索并没有停止。同样我们的测试策略跟技术手段都在不断的优化，质量保障是整个团队的事情。欢迎有其他idea的小伙伴们一起交流经验。

*文/Kelly