服务端稳定性测试

https://blog.csdn.net/huazhongkejidaxuezpp/article/details/89632907

本文链接:https://blog.csdn.net/wodeyijia911/article/details/89632907
目录

一、什么是稳定性

二、稳定性测试方法

方法一:线下稳定性测试通常的做法

关注指标:

测试注意事项

方法二:线上监控/线上巡检

三、故障模拟测试在提升系统稳定性中的实际应用

四、客户端稳定性测试

一、什么是稳定性
稳定性定义:系统长期稳定运行能力,需要时间累积才能度量

潜在的问题:某些系统问题,只有在一天、一星期甚至更长的时间才会暴露的问题。比如:内存泄漏问题

二、稳定性测试方法
稳定性测试整体思路:一定负载下,持续运行长时间,验证系统是否可以正常提供服务。

稳定性测试的边界:稳定性测试本质上仍然属于概率测试。即即使稳定性测试通过了,也不能保证系统100%没有稳定性问题了。实际项目中,要尽可能的提高测试的可靠性,可以通过多次测试,延迟测试时间、加大流量/并发等,来尽可能多暴露问题,来提高测试的可靠性。

影响稳定性测试的考虑因素:

时间:是否需要不间断连续运行?长时间运行是否会有数据累积或者资源泄露?如测试稳定性,推荐测试时间 8小时以上

大流量:哪些模块、数据和流量有关?极限流量下系统还能正常吗?

大并发:正常逻辑业务的大并发以及操作冲突任务的并发下是否都能正常?

环境:系统运行的环境如何?负载高、网络延迟、抖动等是否会影响系统正常工作?

使用方式:用户真正的配置及使用模式和测试是否类似?

极端情况:宕机、服务被kill等系统是否高可用?

方法一:线下稳定性测试通常的做法
  长时间对系统施压,观察系统的各种性能指标,以及服务器的指标。例如,观察系统的各种监控指标曲线,预测系统的发展状况。响应时间是否有增长,可用内存是否在减少,CPU利用率是否在上升等等都可以说明系统是否存在问题

1)模拟线上长时间运行的情况:模拟平常的压力,模拟实际中日常的用户数进行操作

2)模拟的具体工具:可以使用通常的性能测试工具

3)测试的时间:每次有影响稳定性方面的修改时,上线前进行,并将稳定性测试作为一项常规测试。比如:为了管理稳定性测试的整个生命周期,上线前回归自动触发稳定性测试脚本,平台展示和通知稳定性测试结果

4)故障演练

目标:模拟强依赖,弱依赖服务异常情况下,本系统可正常提供服务的能力

模拟异常情况:

模拟下游超时,延时情况下不被下游依赖服务拖垮
强依赖的服务异常/超时时,其他非依赖的核心服务仍然正常
系统实现合理性。比如,sso数据是否需要实时获取,可以模拟SSO挂掉了,公司wiki业务还正常,但系统完全不可用了
中间件的异常(消息服务、数据库服务、缓存服务)
模拟集群中一台主机突然出现CPU飙升、物理内存不足、网络不通等问题,是否还可以稳定地对外提供服务
关注指标:
关注系统指标:

如果是CPU密集型,重点关注CPU占用率,e.g.报价系统

如果是内存密集型,重点关注内存占用率,e.g.搜索引擎Elastic Search

如果是网络IO密集型,关注网络IO情况,e.g.消息队列相关系统,是否存在消息堆积等

测试注意事项
ps: 稳定性测试、性能测试均需要注意

1)内部数据污染

该服务对数据库的依赖、缓存依赖, 是否只读, 会不会对线上数据造成污染

如涉及写操作,请提前联系DBA准备数据源

2)外部数据污染

该服务对外部接口/服务有依赖,是否只读, 会不会对线上数据造成污染

3)业务方影响

外部服务(业务方)对本服务的依赖,压测过程中是否影响业务方,是否周知到业务方

4)降级方案&监控报警

当压力过大时,降级方案或措施是什么,是否有监控报警 

5)压测基本信息

明确机器、具体接口、并发数、测试时间段(必须在业务流量低峰期)、预期目标、关注的指标

方法二:线上监控/线上巡检
监控/巡检属于后置行为了,即保证如果问题发生,可以及时发现/暴露出来。

三、故障模拟测试在提升系统稳定性中的实际应用
目标:通过故障模拟测试发现很多影响系统稳定性的问题

分类

具体问题

依赖服务

1.事务中包含外部调用

2.弱依赖服务故障影响交易核心链路,不符合预期(代码缺陷)

3.超时问题:只设置读超时未设置连接超时、上下游超时时间设置不合理、超时重试次数不合理

4.熔断参数设置不合理,未按照预期熔断

5.限流后未正常触发报警

基础组件(消息队列、缓存等)

1.缓存降级方案失效,未按预期降级到本地缓存(代码缺陷)

2.消费者未对错误、过期、重复的MQ进行处理

3.Leaf、MQ等存在单点风险,没有容灾处理

4.缓存恢复后放量没有预热,一次性放量导致响应超时

数据库

1.全部强制读主库(允许延迟的场景需要优先读从库,减轻主库压力)

2.主从延迟敏感的场景未强制读主库(交易核心链路中的回调场景)

核心全链路系统验证

1.系统未对下游的回调请求进行限流,下游故障恢复后,大量请求涌入,将系统打挂了(故障恢复后,服务无法自恢复

四、客户端稳定性测试
通过Monkey测试App稳定性:它通过发送一系列伪随机的用户事件流进行压力测试

例如,将IOS云测上的稳定性测试接入jenkins,可以持续地进行IOS稳定性测试,便于更好地发现问题
————————————————
版权声明:本文为CSDN博主「多则惑少则明」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/huazhongkejidaxuezpp/article/details/89632907

原文地址:https://www.cnblogs.com/ceshi2016/p/11673879.html