如何做好稳定性测试？我们的探索和实践

作者：刘林霞

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

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

我们将稳定性测试分为三个阶段：

• 第一个阶段为恒定压力阶段，目标是为了检验在恒定的大压力下，系统的服务是否稳定，比如是否存在吞吐量TPS指标的波动，响应延迟的抖动、毛刺等。波动情况必须在恒定的压力下进行验证，如果是波动的压力，出现吞吐量波动或者响应延迟的长尾现象会难以捕捉分析，难以区分是业务的问题还是服务的问题，为性能问题定位带来较大难度。
• 第二个阶段是基于一定的产品压力模型的，已上线产品，我们不难观察产品线上的典型业务及业务比例，那么在过去的七天或者一个月的时间内，产品每天的业务模型是什么样的？根据线上监控及统计不难得出。这个阶段就是为了模拟线上的这种业务模型下，也即是存在峰谷变化的压力、典型的一些Web产品每天的压力模型是比较固定的，比如每天早上9点，下午4点，晚上10点都会存在压力峰值。这种方式的模拟会为系统的稳定性带来一定的压力，如用户量突增等情况，会不会导致错误或宕机等。
• 第三个阶段是在恒定压力下，引入异常干扰，注入异常用例，如CPU波动、网络延迟、主节点挂掉或重启等异常情况的出现，来充分拷打产品的稳定性和可靠性。在google的测试之道中也有提及这种模式，虽然没有更多细节暴漏出来，不过在这方面还是值得探索的。

我们对稳定性测试三个阶段的定义：

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

恒定压力阶段

恒定压力阶段顾名思义保持压力大小恒定不变，在恒定不变的压力模式下，评估系统的吞吐量波动、响应延迟情况。吞吐量TPS是指服务端每秒或每分钟正确处理的请求数，服务资源比较充足且比较稳定的情况下，通常TPS波动很小；如果TPS波动比较大，如突然下降，或剧烈抖动，则系统肯定存在性能问题，比如某个资源成为瓶颈，或某个缓冲队列堆积或爆掉等情况。

• 恒压阶段的并发选择 

恒压阶段改如何选择并发？恒压阶段并发大小的设置一般参考负载测试阶段的结果，选取性能拐点或资源临界点如CPU使用率80%左右的压力，或接近扩容指标的压力。因为一般情况下线上运行最大压力基本在扩容指标之下，选择这个压力对系统的考验会更加严格

• 恒压阶段的性能通过指标 

通过指标包括两类，性能指标和资源指标。 性能指标，TPS上下波动率不超过30%，TPS波动率是有个计算公式的；错误率肖武0.1%，且错误影响范围不大。 资源指标，资源指标无异常，如CPU无波动，不均衡等现象；无内存泄露、连接数泄露、句柄泄露等问题。

资源指标：资源指标无异常，如在波峰增长阶段CPU不存在大幅度的波动情况； 无内存、连接数、句柄数泄露

• 变压阶段的实施效果 

当前我们在某些产品的实施过程中还是能发现一些问题的，如在压力上升过程中，在各项资源指标没有成为瓶颈之前，响应时间增幅很大，性能严重下降的情况

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

在某产品的稳定性测试的压力变化阶段发现在压力变化时出现少量请求错误，且响应时间增幅很大。
原因是在压力突增的时候出现数据库连接数不够用，导致请求出现失败。

异常干扰阶段

在进行稳定性测试时，除了压力变化手段之外，应随机增加一些异常，这样做的目的是检验系统在遇到一些异常时能否做出预期的处理和响应，而不是卡死或是不响应，异常撤消后系统能够快速恢复正常服务。那么，增加哪些异常手段比较合适呢？稳定性测试中选取的异常测试用例主要是一些系统层资源争用的异常，如下所示。主要包括的CPU、内存磁盘、网络异常以及服务故障及恢复等场景。稳定性中增加异常手段的主要目的是为了验证系统在受到一些异常扰动时能否快速做出响应。

• 异常干扰的并发选择 

    同恒压阶段

• 异常干扰的异常用例设计

  部分异常测试点，非完整测试用例

• 异常干扰的通过标准 

   性能指标：随机异常撤销后能够回到原来的稳定值，错误类型分拣，明确错误原因，是否符合预期 

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

我们开发的稳定性测试工具链：

做好稳定性测试需要相当多的工具链进行辅助，施加压力的测试工具、制造异常干扰的工具、进行实时性能监控与性能分析的工具、以及稳定性测试结束后巨大的数据指标分析的工具等，针对这些问题，我们开发了一系列的工具进行支持；

压测工具Grinder及自动化性能测试平台PTP（开发者：QA测试开发组）

Grinder是开源的负载压力测试工具，具有较好的灵活性，脚本基于jython，较强的自定义场景设计等功能，基本能满足绝大多数产品的性能测试需求，基于Grinder，我们将Grinder整合到PTP平台上，支持一键式性能测试执行。

PTP online： http://perf.hz.netease.com（欢迎大家试用） PTP用户手册：http://doc.hz.netease.com/pages/viewpage.action?pageId=38671950

Grinder压力变化插件开发（开发者：赖冬林）

上文提到压力变化模型的定义，那么现有的工具并没有很好的支持，在grinder基础上开发了grinder-concurrentcontrol 插件来让用户方便的定义自己的压力变化模型。

tinkmaster异常干扰随机制造工具（开发者：张伟杰）

tinkmaster是一个轻量级，高度自动化的随机异常注入工具，可以在被测系统中，持续、随机触发用户自定义的异常事件，已集成部分集成异常用例，用户可以很方便的自定义自己的异常用例。可一键式启动。

thrall性能指标实时监控工具（开发者：张翱）

thrall实时展示性能测试数据，TPS、错误率、平均响应时间、最大响应时间，帮助你及时发现性能问题，性能指标采集1s级监控。另外thrall在异常干扰阶段会非常有用，能帮助你观察在异常触发的情况下系统性能发生的细微变化。

基于Hadoop的离线数据分析工具（开发者：张翱）

稳定性测试结束后，性能测试工具生成的性能数据是以本地日志方式存储的，进行7*24的性能测试，数据量比较大。或许可以采用其他方式存储，如实时写入数据库，或者使用Datastream推送到HDFS等，后续可以优化。 当前解决的问题是讲整个稳定性测试过程指标化，图形化。

我们对稳定性测试的延伸计划：

稳定性测试绝对不是只做成这样紫就能模拟产品线上的各种复杂情况，而且稳定性测试目前的难题在于性能监控以及出现性能问题后的排查上，如何保存当时的问题现场，自动抓取有用信息等，都是我们要继续深入实践的方向。

网易云大礼包：https://www.163yun.com/gift