一、背景及目的

喜马拉雅业务量爆发式增长，服务端功能趋近复杂，回归范围扩大化。测试团队要在提高测试质量的同时面对回归成本和交付效率的双重压力，所以对业务逻辑覆盖的测试是平衡以上两个问题的最优解决方案。

   ❓ 自动化的目标是什么？

       描述你理想中的自动化？

二、框架概述

框架图

系统名称和设计灵感FAST - 士兵突击外壳技术头盔 轻量化，更好的舒适度，方便调整 自定义模块化和优秀装载性 提前侦测威胁，协助把控整体势态          提升战术优势，降低未知风险

设计与开发原则：

三、场景化测试体系

1、 思考

• 什么时候回归？上线后忘记通知测试人员需要定时测试的服务，需要人工介入（结算业务）

• 回归范围多大？本次影响了哪些业务逻辑？下游业务方是谁？要执行哪些用例？是否要连带其他业务线测试一起回归？

• 如何获取测试结果？

• 如何阻止带问题上线？

2、 核心能力

面对以上问题，仅靠人工或者常规测试流程，很难做到快速交付。为此我们开始了场景化测试的探索，经过8个多月的体系搭建，形成了特有的场景回归体系。核心能力如下：

1、测试资源不需要参与每次的交付过程

• 触发机制多样化，更贴合喜马发布体系，自动调度（日常发布、灰度发布、定时任务）

• 测试覆盖面更广，更早发现问题（单应用及其接口==>单应用及其与上下游有关的场景）

2、压缩成本

• 流程可视化

• 多种导入方式（case,curl,模块）

• 整合喜马前后台账号体系，自动登录，不再担心鉴权问题（passport,ops）

• 解决痛点，提供定制化服务（下单，验签，mock参数等等）

• 数据传递&共享

• 无人值守

3、监控｜反馈体系完善

• 钉钉工作通知（开发、测试、相关负责人）

• 机器人群通知

• Dashboard

  
  

四、接入策略（推荐）

该流程已在多个业务线实践推广，可作为标准流程进行操作

核心概念

1. 【场景集】：等同于原有的【项目】

2. 【测试场景】：与原有的【用例集】类似 ,

无论我们在测试的用例设计中，尽可能保障覆盖功能点在操作上的闭环，以覆盖一个业务流为目标，这个场景的定义就是连续性操作的闭环，可能是N个功能、也可能是一个功能。

    一个场景 = A Test Story  

1. 【步骤】：等同于Testcase

     步骤存在于场景之中，是整个场景化的最小有效单位，本质上是一次接口调用+校验

目录层级

通用执行路径

1、前期准备

场景化的过程就是基于现有用例，决策哪些业务流能够从人工回归转化为机器回归的过程，做好这个过程，需要团队内部讨论：

推荐流程：

1. 梳理用例和对应服务等级（Xdcs应用分级，流量分级等），筛选S级业务流，产出用例 业务场景接口自动化

   👉  适合场景化用例特征：

1. 核心兜底业务场景，比如，购买专辑-支付-验证支付状态-查看权限-收听-退款-验证退款状态

2. 无论是否跨应用，两步以上，步骤有前后有数据依赖关系，如上述场景中的订单号

3. 前后台混合操作，例如声音审核通过-上架-客户端搜索该声音并可收听

1. 约定规范

场景接口自动化规范

1. 分配重要测试数据（提高效率）

• 共享类型：专辑id

• 非共享：账号等等

2. 组长创建业务组-场景集

3. 分配到个人

2、正式搭建

3、执行

4、测试反馈

1. 通知内容

2. 新版测试报告‍

个人通知

群通知

五、核心价值和落地效果

在2022年下半年，场景化测试体系基本完备的情况下，多个团队进行了接入，从而在无需人工介入的情况下，实现批量化测试，实现了第一阶段的目标。

2022.1.1～2022.12.23运行收益计算（实际运行半年）

六、未来方向与趋势