目录

一、什么是稳定性

二、稳定性测试方法

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

关注指标：

测试注意事项

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

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

四、客户端稳定性测试

一、什么是稳定性

稳定性定义：系统长期稳定运行能力，需要时间累积才能度量

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

二、稳定性测试方法


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

稳定性测试的边界：稳定性测试本质上仍然属于概率测试。即即使稳定性测试通过了，也不能保证系统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稳定性测试，便于更好地发现问题

1.网易易测：稳定性测试实践篇 
	
2.极客时间-服务端稳定性测试
	
3.关于软件稳定性测试的思考与实践
 

1.网易易测：稳定性测试实践篇 

稳定性测试的设计思想，主要包含以下6个方面：

时间：是否需要不间断连续运行？长时间运行是否会有数据累积或者资源泄露？

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

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

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

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

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

下面根据以上稳定性测试设计的6个思想，针对网易云iaas服务中nvs的稳定性测试谈谈稳定性测试的实践。

（备注1：网易云iaas服务，基于openstack架构，参考下图，nvs服务为其中云主机部分）

（备注2：部分测试设计及结果的数据仅为阐明问题，非实际数据）



1

测试设计思想


	
测试对象：物理机+VM（固定+变化）
	
	

	
测试周期：无故障运行的时间
	
	

	
测试规模：物理机规模+虚拟机规模
	
	

	
业务场景：业务类型+调用频率+调度策略
	
	

	
负载模型：负载类型+负载梯度
	
	

	
调用方式：单用户多并发+多用户并发
	
	

	
告警推送：邮件推送+短信提醒
	
测试对象：物理机+VM（固定+变化）

测试周期：无故障运行的时间

测试规模：物理机规模+虚拟机规模

业务场景：业务类型+调用频率+调度策略

负载模型：负载类型+负载梯度

调用方式：单用户多并发+多用户并发

告警推送：邮件推送+短信提醒

2

测试整体框架



3

稳定性实现方式

预定场景测试：包括固定场景和动态变化场景两个部分。

固定场景设计，默认使用10个租户，每个租户选择5个vm进行固定场景测试。固定场景如下图所示：



随机调度测试：模拟线上的真实客户应用，具体调用哪些业务无法预知，主要验证在此情况下系统是否会出现异常。举例如下：

环境中有10个tenant，，每个tenant下面有50-100台虚拟机不等。

随机选择一个tenant，然后在此tenant下面随机选择一台云主机，在预设的操作库（包含云主机常规操作等）中随机选择一种业务操作，如migrate进行操作，操作后进行对应的结果分析和告警等。

负载策略：考虑使用负载加压工具对CPU、内存、网络IO、磁盘IO在同时或者分时加压前提下对非互斥任务进行最大化运行。



其他策略：


	
业务规模：根据宿主机的实际能力确定业务规模的大小。
	
	

	
调用频率及优先级：对业务进行优先级划分，调用频率较高的业务增加优先级设置，随机调度的时候出场率增加，我们把网络初始化、云主机生命周期、云硬盘挂卸载等操作作为最常规的操作。
	
	

	
多次调度均未调度的业务，适当增加提升优先级，增加触发几率。
	
	

	
并发策略方面，通过两种方式实现，不同tenant的并发以及业务的连续无等待串行实现（异步场景）。
	
	

	
极端异常（宕机、断网等）随机注入。
	
业务规模：根据宿主机的实际能力确定业务规模的大小。

调用频率及优先级：对业务进行优先级划分，调用频率较高的业务增加优先级设置，随机调度的时候出场率增加，我们把网络初始化、云主机生命周期、云硬盘挂卸载等操作作为最常规的操作。

多次调度均未调度的业务，适当增加提升优先级，增加触发几率。

并发策略方面，通过两种方式实现，不同tenant的并发以及业务的连续无等待串行实现（异步场景）。

极端异常（宕机、断网等）随机注入。

4

稳定性测试结果

我们会在重大更新上线前或者按迭代进行稳定性测试。每次测试周期均为7*24小时，测试过程中发现了不少内核crash等导致系统崩溃的问题，避免了线上出现事故。网易的云服务在公有云能够支撑不同类型的客户；在私有云保障网易各个互联网产品（考拉、云音乐等）的稳定运行，其中稳定性测试发挥了重大作用。

本次着重以网易iaas服务中云主机服务的稳定性测试为例，与大家交流一下稳定性测试的实践，稳定性测试目前已经累计运行数十次，整个稳定性测试已经完成平台化的开发，后续会为大家带来稳定性测试平台的相关介绍。

2.极客时间-服务端稳定性测试

服务端稳定性：系统要素在各类外界因素的影响下，表现出的稳定状态

长连接集群混部+流量徒增引发的问题case:IM消息和直播聊天室这两个长连接部署的同一套集群，活动直播+长连接消息阻塞，kafka

延迟，

要素：1.系统要素：服务正常运行，响应时间可以接受，资源占用合理2.外界影响：第三方依赖，大量集中的用户行为，基础设施依赖3.稳定状态：服务长时间运行，变更期平稳，异常情况可以快速回复

稳定性测试：服务本身的逻辑争取，大量用户长时间使用后的稳定

1.模块重构（技术重构）：流量回放

2.日志改造引发的逻辑bug，核心业务，调用量top5接口测试脚本，性能测试例行化

3.流量徒增：容量评估

4.极端情况：线下模拟：服务被杀模拟，网络异常，

5.故障模拟和演练：降级，削峰，限流（构造压力），熔断（构造API异常），故障摘除（自动或手动摘流量）

6.监控

3.关于软件稳定性测试的思考与实践

 

    
什么是稳定性测试？
简单来说，就是测试系统在不同程度的环境下稳定运行的能力。
 
稳定性测试可分为针对客户端和服务端的。
客户端常见的是测试程序长时间运行，或某个功能长时间不断重复的运行的稳定性。
服务端常见的是测试并发压力下服务端运行的稳定性。
 
稳定性测试如何做？（3句话简单描述）
1、根据需求设计场景，录制脚本和制定策略
2、监控和记录系统测试时的运行状态和指标数据
3、分析系统运行状态和指标数据并汇总成报告

转载于:https://www.cnblogs.com/whylaughing/p/5406880.html

H5测试和App测试的区别
原理

H5的App先调用系统的浏览器内核，相当于是在网页中进行操作，较原生APP稳定性稍差，似乎还没有百万级用户量的H5 App

App是使用原生系统内核的，相当于直接在系统上操作，是我们传统意义上的软件，更加稳定

易用性

H5最大的优点是可以跨平台，开发容易

App的话需要用Android的语言和iOS的语言各自写，H5只要开发一套

存放位置

H5是基于web，H5页面放在服务端，网速慢的时候，页面出来的就慢

App基于客户端，页面都是本地写出来的。可以用弱网测试来看区别

访问机制

H5的页面都是访问url（H5直接访问url看是否可通）

App都是本地写出来的页面，不需要访问url，只需要访问接口获取数据进行展示

测试方法

H5页面测试一般都需要扫码或者直接访问url进行测试

App需要下载进行测试

缓存方式

H5页面用的是浏览器的缓存，重新请求数据需清缓存

App页面基本都写在了本地

返回

H5页面返回遵循浏览器的返回机制，返回都需要指定返回到哪个页面

App则不一样，比如Android，采用堆栈的方式来存储activity，返回默认都是返回上一级

刷新

H5页面刷新重新访问ur

App页面刷新重新拉取接口

分页

H5分页加载大量数据时，由于页面渲染，会出现卡顿现象

App页面虽然也绘制，因为有自己的复用机制，相对流畅很多

适配

H5除 App关注的手机不同机型和品牌外还需关注浏览器适配
服务端测试
一般主要测接口：耗时、吞吐量、并发、服务器资源使用率