稳定性测试怎么做

只看该作者 · 2022-7-14 23:07

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

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

图片

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

01

稳定性测试的三个阶段

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

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

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

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

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

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

只看该作者 · 2022-7-14 23:11

02

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

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

01

恒定压力阶段

02

压力变化阶段

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

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

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

只看该作者 · 2022-7-14 23:22

03

异常干扰阶段

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

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

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

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

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

只看该作者 · 2022-7-15 07:48

长期可靠性运行