服务端质量保障做什么？
回答这个问题之前，先要看看影响服务端质量的因素有哪些？从当前服务端研发流程来看一个需求上线的全部阶段以及每个阶段的主要活动：
可以看到质量相关的活动贯穿全部研发流程，测试作为质量的构建者和守护者，需要保障的不仅仅是提测后的功能质量，而是整个研发过程的质量和效率。
定义每个阶段影响质量的主要因素
- 需求确认：需求的有效性以及业务价值
- 方案审计：方案的合理性以及变更导致的质量风险
- 代码开发：代码逻辑和编码规范
- 线下验证：回归测试的效率和质量；新功能测试的效率和质量
- 安全生产：留观流量的有效性；质量验证的充分性
- 线上发布：线上稳定性保障机制和异常检查能力
结合优酷业务特性和研发现状，确定测试当前需要重点关注的保障内容
- 代码开发：通过建立静扫、单元测试，实现开发提交代码后的持续验证
- 线下验证：保障提测代码质量、线下验收质量；
- 安全生产：保障安全生产验证有效性
- 线上发布：保障线上服务稳定性
总结成一句话：服务端质量保障体系就是要构建贴合业务特性的自动化测试保障能力，并融入研发流程关键质量阶段(测试准入、冒烟测试、提测、回归测试、安全生产验证、线上发布)，保障应用变更可持续集成、可持续部署、可持续发布。
如何构建质量保障体系?
1. 推流程
保障能力只有嵌入到研发流程，才能真正的发挥作用，为此，通过自定义应用发布流程和组件，构建了优酷线下部署、线上发布的流程，借助发布流程的统一升级，实现保障体系升级
- 保障内容：验收单元测试结果、静态代码扫描结果，保障进入测试阶段的代码基本质量；避免无效部署(代码调试、开发自测)触发测试任务执行
- 准出条件：静扫无Block问题；单元测试通过
冒烟测试
- 保障内容：构建自动化测试实验室，验收应用基本功能，阻断低级问题流入提测阶段以及集成测试阶段，保障后续测试活动的质量和效率
- 准出条件：冒烟测试完成；完成失败用例分析；
提交测试
- 保障内容：通过自定义“提测”组件打通发布平台和优酷研发效能平台，开发在发布流程中一键提测，自动收集提测相关信息并生成提测单，保障提测信息有效性，阻断低质量提测流入测试环节
- 准出条件：冒烟测试结果满足业务提测基线；提测单包含代码变更、功能说明、影响接口等测试信息；
集成测试
- 保障内容：构建贴合业务特性的回归测试任务，对变更进行全量回归测试，保障变更代码不影响原有功能
- 准出条件：回归测试完成；完成失败用例分析；没有影响线上发布的问题
安全生产验证
- 保障内容：对接安全生产验证组件，为应用发布提供安全生产环境的验证能力，保障安全生产留观期间内的流量有效性、质量稳定性。
- 准出条件：安全生产验证完成；完成失败验证点分析；没有影响线上发布的问题
灰度验证
- 保障内容：在微灰环境建立压测分组，通过引流的方式对压测分组机器自动压测，并和历史压测基线做对比，提供性能评估能力，保障变更代码的性能稳定性
- 准出条件：对比性能基线，压测评估结果通过
线上部署
- 保障内容：通过构建线上巡检任务，定时巡检核心接口的核心场景，及时发现因为配置变更、代码变更、依赖变更导致的线上问题
- 准出条件：无
2. 建能力、搭平台
统一应用发布流程后，如何快速协助业务构建流程中需要的各种保障能力，也是质量保障体系必须解决的问题。
在“不重复造轮子”的原则下，通过整合阿里在服务端测试领域的能力和服务，形成了一套能适合优酷业务特性的质量保障能力，并通过平台化向各个业务提供接口，协助业务团队快速构建质量保障体系的能力。
研发流程
通过自定义发布流程组件，打通发布流程和优酷效能平台，实现在发布流程上一键提测，主要为提供提测承载页、提测代码变更分析、提测卡口功能。
基础能力
基于JVM-Sandbox提供的能力、平台实现了采集模块自动部署、模块状态自动维护、请求采集自动调控、增强类自动解析，支持应用一键接入保障体系所需要的基础能力：
- 全环境数据采集能力(请求入参和返回结果、应用内部方法链路)
- 全环境、全接口协议、多方式请求回放能力(实时回放、mock回放、泛化回放)
- 线下环境Mock能力(模拟返回结果、模拟异常、模拟超时)
自动化测试任务
不同业务需要的保障能力可能来自集团不同平台，业务的接入和分析成本比较高，为此，自动化测试页面提供了各种任务的接入配置、调度执行、结果回收、失败分析功能，实现了任务调度、分析处理的闭环能力
目前支持的任务类型和配置如下：
- 支持任务类型：自动化实验室、智能回放、安全生产验证、单机性能评估
- 支持任务配置：持续集成配置、结果通知配置
自动化测试框架优酷自研接口测试框架，通过提供远程接口调用、Wrapper断言、自定义测试报告、中间件跨环境访问、Pandora类隔离机制等能力，业务团队可以低成本完成测试脚本开发，有效支撑优酷全部业务场景的冒烟测试、回归测试、线上巡检脚本开发和维护，框架主要模块如下：
- 远程接口调用模块：提供集团常用协议接口的跨环境调用能力
- 断言模块：无需编写任何断言方法，提供所见即所得的断言机制
- 报告模块：自动记录测试脚本中的接口调用、断言等信息，生成完整的测试报告
- 类隔离模块：实现通过容器运行测试脚本，解决测试工程的包冲突问题
智能回放
阿里已有的回放测试平台都是基于线下mock回放的子调用对比测试，但优酷的业务形态决定了服务端读接口偏多，更适合做实时回放，既可以规避配置变更导致的返回结果不一致，又降低了业务接入和使用成本。
为此，基于JVM-Sandbox提供的链路采集能力和回放能力，优酷实现了基于线上热度链路推荐的实时回放能力，相比集团已有回放平台，具备以下特性：
- 更有效的请求推荐能力：通过聚合线上采集的应用内部方法链路，有效识别出线上热度链路，基于热度链路推荐回放请求，相比基于子调用链路推荐请求，能更有效的覆盖应用内部代码链路和真实业务场景
- 更稳定的对比回放测试(只适用读接口的回放)：采取实时非Mock回放，同时请求目标环境和回放环境，对比接口返回结果，有效规避了由于子调用变更和配置数据变更导致的对比失败
- 更低的接入和使用成本：基于JVM-Sandbox实现应用无侵入部署；对只读接口，不需要配置子调用对比逻辑，指定接口后就可以开始回放，即配即用
安全生产
优酷构建了针对安全生产环境的验证机制和能力，能有效保障安全生产留观期间的流量有效性和质量稳定性，目前主要提供的验证能力如下：
- 业务质量规则验证：通过配置接口返回结果的质量规则，全量验证安全生产留观期间内接口的返回结果，保障接口返回结果的业务质量
- 智策告警：监控和分析安全生产留观期间内产生的业务告警，保障常规业务指标监控、中间件监控提前在安全生产阶段发现
- 接口RT对比：对比留观时间段内，核心接口在安全生产的平均RT和线上的平均RT，提前发现接口性能相关的问题
- 接口自动化验证：通过自动化脚本验证安全生产环境接口质量，及时发现接口调用失败、无数据返回等重大接口问题
- 智能回放：通过智能回放，对比安全生产和线上的接口返回结果，保障读接口功能稳定性
- 业务场景覆盖率：通过建立核心接口的业务场景规则，保障留观期间内的流量能覆盖到核心业务场景
如何度量保障体系质量?
构建服务端保障体系主要是为了提升服务端发布质量和研发效率，优酷将降低服务端故障数和提升变更发布效率定义为主要需要解决的问题。
基于这2个问题，对目标的定义如下：
业务质量
- 发布导致的故障数：应用发布导致的线上问题数。评估拦截发布导致故障的价值
- 线上突发故障数：线上突发故障数。用来评估线上服务稳定性
研发效率
- 变更无人值守率：评估持续集成体系对提升回归测试效率的价值
- 变更验证停留时长：评估持续集成体系对提升变更发布效率的价值
确定保障体系各项指标后，就要通过收集需要的基础数据，按照不同维度聚合，形成准确可靠的度量指标。能让业务团队、专项负责人、测试负责人通过指标数据发现问题，为后续优化提供方向，这个就是保障体系的度量能力。
优酷服务端保障平台通过和各个外部系统打通，并提供了通用失败分析能力，形成了数据收集、失败分析、聚合指标的度量闭环。
经过过去半年的能力建设和持续推进，已经有几百个应用接入服务端测试平台，其中核心场景应用接入率 100%，用户活跃度高，保障效果明显，能有效发现质量问题，并且实际拦截了若干次会引发回滚甚至是线上故障的问题，极大的提高了服务端上线质量和研发效率。
