本文章出自【码同学软件测试】
码同学公众号：自动化软件测试
码同学抖音号：小码哥聊软件测试

当前我司业务发展蒸蒸日上，业务需求像洪水一样袭来。系统服务的稳定性重要作用不言而喻。本文主要就服务端的稳定性测试工作浅谈一下。

稳定性测试背景及目标

稳定性测试主要测试系统的长时间稳定运行能力，通过对用户实际使用场景的负载及应用场景分析，模拟真实的用户使用场景，并进行长时间的稳定运行，以保证产品在长时间运行方面可能存在的潜在问题的及时发现和有效解决。

稳定性测试引入必要性分析

首先，部分问题，如内存泄露、句柄泄露、死锁等，在常规功能测试中难以发现，需要通过压力的注入以及系统的运行达到一定的时间后，才能触发问题的产生，所以引入稳定性测试，可以有利于该类问题的及时发现和提前解决；同时，在系统正常上线之前，通过对真实环境的长时间模拟测试，也可以有效的验证系统在正式上线以后的稳定运行能力，为产品上线后的稳定性和鲁棒性提供一定的数据参考。

稳定性测试执行策略及方法

具体执行策略

测试时间：最好保证系统持续稳定性运行724小时，最小稳定运行时间为324小时。

测试场景：参考业务的实际使用场景构建压力模型，模拟实际的场景运行（实际负载和并发量等），并且在测试中模拟实际日常的用户操作，操作中需要考虑并发因素，包括单操作并发和不同操作并发两种场景。

测试负载选择策略：一般和线上的实际场景保持一致，如果没有线上数据的时候，采取梯度加压的方法来进行变化。

稳定性测试是概率性的测试，就是说即使稳定性测试通过，也不能保证系统实际运行的时候不出问题。所以要尽可能的提高测试的可靠性。可以通过多次测试，延长测试时间，增大测试压力来提高测试的可靠性。

稳定性测试的测试时间和压力存在一定的关系。在测试时间不能保证的情况下，可以通过增强压力以及增大测试对象数量来达到快速验证的目的，但是建议最小测试时间不要小于3*24小时。

我是极简标题

时间
大流量
并发
使用环境
使用方法
极端情况

时间，产品能持续长时间工作吗？可能会导致的问题：内存泄漏，队列堆积，存储等慢速设备持续跟不上，Cache，Buffer累积性问题，内存溢出等。

大流量，产品能处理这么大流量吗？可能导致的问题：系统崩溃，性能严重下降，资源耗尽，DB或磁盘空间满，触发系统的一些行为（流量控制等），依赖系统的一些异常等。

并发，在一定并发量的情况下系统有无异常？可能导致的问题与上面两种类似。并发包括平均并发量；峰值并发量；均值为主，特定时间加入峰值；加压，使系统资源达到特定值，维持压力，持续运行等情形。

使用环境：不同平台，网络，基础架构等。一般来说此为客户端稳定性测试需要考虑的验证点。

免费领取 码同学软件测试 课程笔记+超多学习资料+完整视频+最新面试题，可以转发文章 + 私信「码同学666」获取资料哦

使用方法：客户对相关应用的使用方式。具体到服务端来说，有被依赖方调用底层接口使用姿势等问题。

极端情况：极端情况下，应用可以crash，但是不能丢数据等情形的验证。

测试关注点

观察系统在有负载的情况下业务运行是否正常，是否存在内存泄露、句柄泄露、数据一致性等问题导致系统出现崩溃、异常重启。

是否存在系统长时间运行下，系统性能下降明显，响应时间快速增长，可用内存是否在减少，CPU利用率是否在上升等等都可以说明系统是否存在问题。

其他项：包括CPU，MEM，disk i/o，网络，应用的日志，数据库状态，请求准确率，响应时间，吞吐量等。

常用测试工具介绍

压力工具方面，根据压力维度的不同主要分为CPU、内存、网络IO以及磁盘IO的压力工具，各种维度中的常用工具请参考如下内容。

典型服务端稳定性bug举例与分析

Bug：系统在长时间连续运行3天以后，虚拟机出现异常重启现象。

分析：典型稳定性测试问题，该类问题一般需要在长时间的连续运行情况下才会触发，该问题主要由于系统中存在内存泄露现象导致，在连续运行3天以后，泄露达到了问题的触发点，导致虚拟机异常重启，一般该类问题的出现时间还与系统的负载有一定的关系，在系统负载很高的情况下，问题的触发几率会增大，同时发生的时间间隔也可能出现一定的缩短。

笔者跟大家分享一个福利！扫码回复【csdn码哥群】入软件测试自学交流群，可免费听技术讲座+领学习资料+视频课免费看

作者：码同学软件测试
本文著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

服务端测试分两种：
1-对web或者app的服务端进行测试：一般为接口测试，若预期上线有大流量时，需要做性能测试，需要需三端开发沟通（ios/android/web）
2-对更后端的数据库，缓存系统，中间件，文件系统进行测试：内部逻辑负载，所以除了接口测试外，还要了解服务端的技术架构和技术实现，需要了解到模块级别。若用到开源软件，还需要关注开源社区的发展。

测试类型：
异常测试：硬件异常-机器挂掉的情况；网络异常-断网吗，网络流量小；系统异常-系统挂掉等。这些情况都要验证数据是否丢失，能否尽快恢复，系统状态是否异常，使用工具创造异常
稳定性测试：模拟系统在7*24的运行下不会出现问题，用接口用例或性能测试用例不断的跑，在运行期间，模拟各种变化，如:负载变化，系统干扰等
性能测试：负载测试，压力测试，配置测试，线上压测，容量规格。常规的性能测试为规定系统需要承受的压力，设置一个并发场景，然后进行压测，遇到问题解决问题，然后继续压测。

服务端测试:
主要测试后端的业务，业务逻辑很复杂，后端会使用集群。需要测试集群性能，安全测试，压力测试。需要掌握shell，python，linux命令。最主要的是搞清楚业务场景

服务端接口测试流程：
1，一般从功能开始测试，请求参数，响应参数，业务逻辑或业务规则，数据库操作校验
2，然后安全，性能测试及系列扩展测试，如与旧版本兼容性，超时验证，设计合理性

数据库测试关注点：
1-对数据库操作是否频繁，是否在写过程占用大量CPU，写库完成进程是否释放
2-业务数据入库是否正常，是否重复数据入库，数据入库是否乱码，日志数据入库是否正常
3-数据更新是否正常，时间格式数据存储是否正常，是否是24小时进制的。
4-数据删除，备份是否正常。

安全性：
1-敏感信息是加密

性能：
1-接口什么时候出现并发，并发有多少，并发场景，并发会导致什么问题
2-最大并发，响应时间，吞吐量，资源消耗

与历史版本兼容性问题：
1-同一系统，不同服务之间的接口相互调用，新接口是否受历史接口的影响

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

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

图片

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

01

稳定性测试的三个阶段

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

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

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

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

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

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

02

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

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

01

恒定压力阶段

定义

恒定压力阶段顾名思义保持压力大小恒定不变，在恒定不变的压力模式下，评估系统的吞吐量波动、响应延迟情况。

吞吐量TPS是指服务端每秒或每分钟正确处理的请求数，服务资源比较充足且比较稳定的情况下，通常TPS波动很小；如果TPS波动比较大，如突然下降，或剧烈抖动，则系统肯定存在性能问题，比如某个资源成为瓶颈，或某个缓冲队列堆积或爆掉等情况。


恒压阶段的并发选择

恒压阶段改如何选择并发？

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


恒压阶段的性能通过指标

通过指标包括两类，性能指标和资源指标。

①性能指标：TPS上下波动率不超过30%，TPS波动率是有个计算公式的；错误率肖武0.1%，且错误影响范围不大。

②资源指标：资源指标无异常，如CPU无波动，不均衡等现象；无内存泄露、连接数泄露、句柄泄露等问题。

02

压力变化阶段

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

图片

我们对压力变化模型的不精确定义为：
1.初始并发数需要配置，保持时间默认30min

2.上升时间T需要配置

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

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

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

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

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


变压阶段的并发选择

最大并发数一般选取负载测试时最大TPS对应的压力

最小并发数为最大TPS对应压力的一半，初始并发选择最大TPS对应压力的80%左右


变压阶段的性能通过指标

①性能指标：TPS波动后能够回到原来的稳定值；在波峰时，响应时间增幅不会过大；错误率小于0.1%
②资源指标：资源指标无异常，如在波峰增长阶段CPU不存在大幅度的波动情况；无内存、连接数、句柄数泄露


变压阶段的实施效果

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

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

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

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

03

异常干扰阶段

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

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

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

异常干扰的并发选择
同恒压阶段


异常干扰的异常用例设计
部分异常测试点，非完整测试用例

异常干扰的通过标准
①性能指标：随机异常撤销后能够回到原来的稳定值，错误类型分拣，明确错误原因，是否符合预期
②资源指标：资源指标无异常(CPU/IO/网络)；无内存、连接数、句柄数泄露；程序无挂掉等情况。


异常干扰测试的实施效果
基于异常干扰的稳定性测试目前在若干个产品有实施，均能发现一些不稳定的性能问题，如高可用切换问题，异常恢复等问题

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

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