共计 2126 个字符，预计需要花费 6 分钟才能阅读完成。
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
@得物技术公众号
