目录
 
一、什么是稳定性
 
二、稳定性测试方法
 
方法一：线下稳定性测试通常的做法
 
关注

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

 
 

  
阿里 qa 导读：久违了，夏去秋至，阿里巴巴技术质量新人手册又开始更新啦~ 上期我们给大家带来的是成为测试多面手中的移动测试篇，今天我们继续和大家讲讲服务端测试。
 
 

 
服务端测试
 
服务端测试有两种：一种是直接对 WEB 或者 APP 的 API 接口进行测试；另一种是对更后端的数据库、缓存系统、中间件、文件系统等进行测试，核心就是输入输出是否符合服务设计。必备的测试手段包括：
 
接口测试
性能测试
稳定性测试
异常测试
 
其中稳定性测试中涉及：异常、超时、重试幂等、性能等
 
基于 API 的服务端测试
 
这种服务端就是为 WEB／APP 端提供一些后台的接口，一般都是用 HTTP、HSF、MTOP 接口的方式提供。这种后台的测试从流程上来说是跟随着发布节奏来的，根据时间、提测以及持续集成目标，可以采用不同的测试方法：
 
手工接口测试
 
根据接口设计，测试人员可以借助中间件平台，自有工程，第三方工具进行接口测试了。接口测试过程中，特别需要关注异常场景测试，单接口异常测试主要包括输入异常、操作异常、依赖服务异常，测试验证时关注「容错逻辑」以及「异常返回码是否符合接口约定」。
 
输入异常：包括入参为特殊字段类型、非法长度、边界值等
操作异常：例如操作为特殊业务流程、非法修改数据等非正常业务操作
依赖服务异常：包括访问超时、服务挂掉、异常返回码等场景
 
手工集成测试
 
待需求的前端和上下游都交付之后就可以进入集成测试阶段，在这个环节测试人员除了协调各涉及端的测试进度、测试环境和自己域的业务验证之外，同样需要关注异常测试，集成阶段的异常主要包括输入异常、接口异常、操作异常，测试验证时关注「异常文案交互是否符合业务预期」。
 
输入异常：包括入参为特殊字段类型、非法长度、边界值等
接口异常：例如接口超时、非约定返回码等
操作异常：业务流程中高频导致的并发、乱序等非法操作场景
 
「异常测试」主要分为功能异常、服务端异常
 
功能异常主要通过各种入参模拟进行验证，接口测试目前可用自建平台、postman 以及其他任意接口测试平台
 
测试常用功能介绍：
 
保存参数、导入参数：平台支持保存当前参数模板，方便下次导入调用，但需注意仅支持保存一套参数
自定义 Timeout：可以自定义时间，越过接口原超时限制，mock 超时场景下接口返回
指定 Provider 调用：指定 IP 进行调用，便于调试和问题定位
活用执行结果信息：接口执行失败需要上下游配合排查定位时，traceId、Provider 是关键排查参数
 
注意事项：
 
特定角色才能在控制台进行 hsf 接口测试（例如测试负责人）
入参输入建议切换到 Code 模式下编辑，以免类型转换错误
 
服务端异常目前主要可通过一些强弱依赖平台进行验证，很多平台支持对线上流量自动进行分析并生成用。
 
持续集成
 
借助类似 Jenkins 工具平台完成手工测试的自动化持续集成，实现接口级别的回归和链路级别的回归。
 
对更后端的数据库、缓存系统、文件系统等中间件进行测试
 
对于这类后端服务来说，接口只是暴露给外用的部分，内部逻辑通常是非常复杂的，所以，除了针对接口做测试之外，测试人员还需要细致地了解这些服务端产品的技术框架及技术实现，需要了解到模块的级别，对于系统框架图、时序图等都有很好的理解，针对这些理解去设计用例和执行。下面介绍几种常见中间件的测试思路和方法：
 
模拟消息发送，验证消费消息后的代码逻辑
 
打开消息控制台，找到对应的 topic 点击发送，输入 body 消息后确定发送
 
 
 
验证 metaq 消息是否按照约定发送
 
打开 metaq 控制台，点击进入“消息查询”，查看消息体和轨迹，验证是否符合期望
 
DTS 任务的调试
 
schedulerx 分布式系统调度任务的调试和排查可以使用控制台
 
编辑：输入 job 运行参数
触发一次：手动触发
指定机器：可以勾选指定 job 运行的服务器
 
完
 
往期推荐
 
超实用的 Python 库推荐！
 
Nose | 超轻的单元测试框架-入门
 
超实用的18个 Python 高效编程技巧
 
点亮在看！
 

 
 
 
  

   
阿里 qa 导读：久违了，夏去秋至，阿里巴巴技术质量新人手册又开始更新啦~ 上期我们给大家带来的是成为测试多面手中的移动测试篇，今天我们继续和大家讲讲服务端测试。
  
  

  
服务端测试
  
服务端测试有两种：一种是直接对 WEB 或者 APP 的 API 接口进行测试；另一种是对更后端的数据库、缓存系统、中间件、文件系统等进行测试，核心就是输入输出是否符合服务设计。必备的测试手段包括：
  
接口测试
性能测试
稳定性测试
异常测试
  
其中稳定性测试中涉及：异常、超时、重试幂等、性能等
  
基于 API 的服务端测试
  
这种服务端就是为 WEB／APP 端提供一些后台的接口，一般都是用 HTTP、HSF、MTOP 接口的方式提供。这种后台的测试从流程上来说是跟随着发布节奏来的，根据时间、提测以及持续集成目标，可以采用不同的测试方法：
  
手工接口测试
  
根据接口设计，测试人员可以借助中间件平台，自有工程，第三方工具进行接口测试了。接口测试过程中，特别需要关注异常场景测试，单接口异常测试主要包括输入异常、操作异常、依赖服务异常，测试验证时关注「容错逻辑」以及「异常返回码是否符合接口约定」。
  
输入异常：包括入参为特殊字段类型、非法长度、边界值等
操作异常：例如操作为特殊业务流程、非法修改数据等非正常业务操作
依赖服务异常：包括访问超时、服务挂掉、异常返回码等场景
  
手工集成测试
  
待需求的前端和上下游都交付之后就可以进入集成测试阶段，在这个环节测试人员除了协调各涉及端的测试进度、测试环境和自己域的业务验证之外，同样需要关注异常测试，集成阶段的异常主要包括输入异常、接口异常、操作异常，测试验证时关注「异常文案交互是否符合业务预期」。
  
输入异常：包括入参为特殊字段类型、非法长度、边界值等
接口异常：例如接口超时、非约定返回码等
操作异常：业务流程中高频导致的并发、乱序等非法操作场景
  
「异常测试」主要分为功能异常、服务端异常
  
功能异常主要通过各种入参模拟进行验证，接口测试目前可用自建平台、postman 以及其他任意接口测试平台
  
测试常用功能介绍：
  
保存参数、导入参数：平台支持保存当前参数模板，方便下次导入调用，但需注意仅支持保存一套参数
自定义 Timeout：可以自定义时间，越过接口原超时限制，mock 超时场景下接口返回
指定 Provider 调用：指定 IP 进行调用，便于调试和问题定位
活用执行结果信息：接口执行失败需要上下游配合排查定位时，traceId、Provider 是关键排查参数
  
注意事项：
  
特定角色才能在控制台进行 hsf 接口测试(例如测试负责人)
入参输入建议切换到 Code 模式下编辑，以免类型转换错误
  
服务端异常目前主要可通过一些强弱依赖平台进行验证，很多平台支持对线上流量自动进行分析并生成用。
  
持续集成
  
借助类似 Jenkins 工具平台完成手工测试的自动化持续集成，实现接口级别的回归和链路级别的回归。
  
对更后端的数据库、缓存系统、文件系统等中间件进行测试
  
对于这类后端服务来说，接口只是暴露给外用的部分，内部逻辑通常是非常复杂的，所以，除了针对接口做测试之外，测试人员还需要细致地了解这些服务端产品的技术框架及技术实现，需要了解到模块的级别，对于系统框架图、时序图等都有很好的理解，针对这些理解去设计用例和执行。下面介绍几种常见中间件的测试思路和方法：
  
模拟消息发送，验证消费消息后的代码逻辑
  
打开消息控制台，找到对应的 topic 点击发送，输入 body 消息后确定发送
  

   
   
  
  
验证 metaq 消息是否按照约定发送
  
打开 metaq 控制台，点击进入“消息查询”，查看消息体和轨迹，验证是否符合期望
  
DTS 任务的调试
  
schedulerx 分布式系统调度任务的调试和排查可以使用控制台
  
编辑：输入 job 运行参数
触发一次：手动触发
指定机器：可以勾选指定 job 运行的服务器
  
- To Be Continued -
  

  
   前方剧透！！！
  

  
《技术质量新人手册》
  
测试开发工程师的角色——完成
修炼测试基本功——完成
研发过程中的测试工作 —— 完成
如何做到测试场景不遗漏？ —— 完成
成为测试多面手
    
移动测试篇
服务端测试篇
性能测试篇
安全测试篇
算法测试篇
数据测试篇
如何做好跨域项目？
稳定性保障&大促保障
如何从0-1实现自己的效能创新，思路和解法
测试分析的主要方法
测试用例设计之常见风险点
  扫码关注「阿里巴巴技术质量」，手册在手，天下我有
  
  关注「阿里巴巴技术质量」阅读更多