稳定性对产品的重要性不言而喻。

 而作为质量保障，在稳定性测试方面的探索也在不断演化。记得两年前我们做稳定性测试还是基于恒定的压力，7*24小时长时间运行，关注的指标无非是吞吐量TPS的抖动、响应时间的变化趋势，以及各种资源是否泄露。稳定性测试的场景设计简单，和线上实际运行有较大的出入。带来的直接结果是稳定性测试发现的问题比较有限，做完之后仍然没有特别大的信心。

那稳定性测试究竟该如何做？别人在怎么做？性能测试组今年在这方面做了一些思考和改进，虽然称不上很好的解决方案，但是通过努力比以前的做法还是有不少增强。

一、稳定性测试的三个阶段

第一个阶段：恒定压力阶段

目标是为了检验在恒定的大压力下，系统的服务是否稳定，比如是否存在吞吐量TPS指标的波动，响应延迟的抖动、毛刺等。波动情况必须在恒定的压力下进行验证，如果是波动的压力，出现吞吐量波动或者响应延迟的长尾现象会难以捕捉分析，难以区分是业务的问题还是服务的问题，为性能问题定位带来较大难度。

第二个阶段：基于一定的产品压力模型的，已上线产品

我们不难观察产品线上的典型业务及业务比例，那么在过去的七天或者一个月的时间内，产品每天的业务模型是什么样的？根据线上监控及统计不难得出。这个阶段就是为了模拟线上的这种业务模型下，也即是存在峰谷变化的压力、典型的一些Web产品每天的压力模型是比较固定的，比如每天早上9点，下午4点，晚上10点都会存在压力峰值。这种方式的模拟会为系统的稳定性带来一定的压力，如用户量突增等情况，会不会导致错误或宕机等。

第三个阶段：是在恒定压力下，引入异常干扰，注入异常用例

如CPU波动、网络延迟、主节点挂掉或重启等异常情况的出现，来充分拷打产品的稳定性和可靠性。在google的测试之道中也有提及这种模式，虽然没有更多细节暴漏出来，不过在这方面还是值得探索的。

二、对稳定性测试三个阶段的定义

目前稳定性测试采用的性能测试场景设计使用混合场景模式，基于产品业务模型或用户行为来定义场景，包括产品的典型业务、典型业务之间的组合关系、典型业务之间的比例等，这里不详细介绍，有兴趣欢迎联系。另外，关于稳定性测试场景的设计还有比较大的优化和提升空间，这个后面会畅谈下。

1.恒定压力阶段

• 定义
  恒定压力阶段顾名思义保持压力大小恒定不变，在恒定不变的压力模式下，评估系统的吞吐量波动、响应延迟情况。
  吞吐量TPS是指服务端每秒或每分钟正确处理的请求数，服务资源比较充足且比较稳定的情况下，通常TPS波动很小；如果TPS波动比较大，如突然下降，或剧烈抖动，则系统肯定存在性能问题，比如某个资源成为瓶颈，或某个缓冲队列堆积或爆掉等情况。
  
• 恒压阶段的并发选择
  恒压阶段改如何选择并发？
  恒压阶段并发大小的设置一般参考负载测试阶段的结果，选取性能拐点或资源临界点如CPU使用率80%左右的压力，或接近扩容指标的压力。因为一般情况下线上运行最大压力基本在扩容指标之下，选择这个压力对系统的考验会更加严格
  
• 恒压阶段的性能通过指标
  通过指标包括两类，性能指标和资源指标。
  ①性能指标：TPS上下波动率不超过30%，TPS波动率是有个计算公式的；错误率肖武0.1%，且错误影响范围不大。
  ②资源指标：资源指标无异常，如CPU无波动，不均衡等现象；无内存泄露、连接数泄露、句柄泄露等问题。

2.压力变化阶段

• 定义：变压阶段的并发选择则需要根据不同场景的实际线上运行场景，或者几种典型的产品，如Web产品，或后端基础支持类的产品来进行压力定制波峰和波谷。
  

我们对压力变化模型的不精确定义为：

1.初始并发数需要配置，保持时间默认30min

2.上升时间T需要配置

3.最大并发数需要配置，默认为初始并发数的2倍

4.最小并发数需要配置，默认为初始并发数的1/2

5.最大最小并发数保持时间，需要配置，两段时间相等

6.周期重复数，需要配置，默认重复两次

7.下降时间不需要配置，固定为上升时间的2倍

• 变压阶段的并发选择
  最大并发数一般选取负载测试时最大TPS对应的压力
  最小并发数为最大TPS对应压力的一半，初始并发选择最大TPS对应压力的80%左右
  
• 变压阶段的性能通过指标
  ①性能指标：TPS波动后能够回到原来的稳定值；在波峰时，响应时间增幅不会过大；错误率小于0.1%
  ②资源指标：资源指标无异常，如在波峰增长阶段CPU不存在大幅度的波动情况；无内存、连接数、句柄数泄露
  
• 变压阶段的实施效果
  当前我们在某些产品的实施过程中还是能发现一些问题的，如在压力上升过程中，在各项资源指标没有成为瓶颈之前，响应时间增幅很大，性能严重下降的情况
  

下图为在某个产品上实施的效果，可以看到响应时间是有波动，但这个波动还是可以接受的。

在某产品的稳定性测试的压力变化阶段发现在压力变化时出现少量请求错误，且响应时间增幅很大。

原因是在压力突增的时候出现数据库连接数不够用，导致请求出现失败。

3.异常干扰阶段

在进行稳定性测试时，除了压力变化手段之外，应随机增加一些异常，这样做的目的是检验系统在遇到一些异常时能否做出预期的处理和响应，而不是卡死或是不响应，异常撤消后系统能够快速恢复正常服务。

那么，增加哪些异常手段比较合适呢？

稳定性测试中选取的异常测试用例主要是一些系统层资源争用的异常，如下所示。主要包括的CPU、内存磁盘、网络异常以及服务故障及恢复等场景。稳定性中增加异常手段的主要目的是为了验证系统在受到一些异常扰动时能否快速做出响应。

• 异常干扰的并发选择
  同恒压阶段
  
• 异常干扰的异常用例设计
  部分异常测试点，非完整测试用例
  

• 异常干扰的通过标准
  ①性能指标：随机异常撤销后能够回到原来的稳定值，错误类型分拣，明确错误原因，是否符合预期
  ②资源指标：资源指标无异常(CPU/IO/网络)；无内存、连接数、句柄数泄露；程序无挂掉等情况。
  
• 异常干扰测试的实施效果
  基于异常干扰的稳定性测试目前在若干个产品有实施，均能发现一些不稳定的性能问题，如高可用切换问题，异常恢复等问题
  

下图为在对存储盘施加一定的磁盘io压力的情况下，应用吞吐量的抖动情况，还是很坚挺的，没有出现失败或服务挂掉的情况。

（上图为TPS、下图为响应时间，TPS图的左坐标轴为TPS，右坐标轴为错误率，响应时间左坐标轴为平均响应时间，右坐标轴为最大响应时间）