稳定性测试怎么测

稳定性测试怎么测

稳定性测试怎么测，来说说性能测试:性能是软件的一种非功能特性,他关注的不是软件是否完成了特定的功能,而是软件在完成特定功能是展示出来的及时性。以下是稳定性测试怎么测

稳定性测试怎么测1

软件稳定性测试的测试点

1、对软件多次测试，长时间运行，是否正常运行

2、长时间对软件开启关闭软件和系统是否正常

3、软件长时间执行某个业务后切换到别的不同的业务操作是否受影响

4、软件长时间开启但是不执行任何操作，然后检查能否正常执行业务操作

5、软件长时间对日常的用户数进行操作运行，观察系统内存占用率是否越来越大，可用内存是否减少，内存是否溢出，饱和运算内存是否占用过大、是否溢出

6、软件长时间开启正常运行，观察系统CPU是否使用率是否越来越高,在饱和运算时,观察系统cup使用率，饱和运算结束时，CPU使用率能否回到正常值

7、在系统运行过程中，对系统饱和施压，观察系统的各种性能指标，以及服务器的指标、观察服务器电源电压是否降低、机箱、内存、硬盘、CPU等硬件指标来观察系统的稳定性

8、模拟平常的压力，模拟实际中日常的用户数进行操作。要存、取、建、查数据，验证数据库是否正常读写

9、模拟饱和压力测试，模拟实际中日常最大用户数进行操作。要存、取、建、查数据，验证数据库是否正常读写，系统运行是否受影响

10、多个关联软件，存在接口访问数据交流，关闭其中的一个软件，检查软件是否稳定运行

11、多对不同功能模块软件同时操作是否能够正常响应，数据库运行是否正常

12、对依靠网络运行的软件，使用网络工具将软件的带宽限制到最低，检查系统处理是否正常

13、对依靠网络运行的软件，在执行业务时断网，检查系统处理是否正常，软件能够正常运行

14、有数据库操作的软件，如果数据库停止运行，检查程序是否能正常处理

15、对不同功能模块软件同时操作是否能够正常响应

16、对不同的操作系统主要是windows系列操作，比如XP,WIN7等，检查不同操作系统能否稳定运行、报错

17、系统断电后此软件是否能够正常启动、正常运行，或者给出异常提示

18、多个关联软件，存在接口访问数据交流，关闭其中的一个软件，检查软件是否稳定运行

19、版本升级后对原有功能稳定性是否受到影响，对原有数据操作是否存在异常

20、软件某单元模块异常后是否影响整个软件正常运行

21、当系统出现崩溃时，重起系统软件能否正常运行

22、分析系统操作中，哪些业务或功能存在大数据量的处理，如果存在，要将这些功能或业务反复处理，检查系统是否能正常运行，并观察系统的性能和资源使用情况

23、分析系统操作中，哪些业务或功能存在大数据量的输出或生成，如果存在，要将这些功能或业务反复处理，检查系统是否能正常运行，并观察系统的性能和硬盘占用情况

24、如果系统同时允许多个不同的客户端版本同时访问服务器，要构造尽量多的不同版本的客户端，进行大量的访问服务器的`操作，看是否会产生数据冲突或异常

25、与开发或设计人员确认，系统的哪些业务或功能在处理过程中，会占用大量的内存，（例如批量生成大容量文件，批量实例化对象，批量产生连接等），要对这些操作进行大量重复，检查系统是否存在内存泄漏问题

26、若系统结构中使用了负载均衡，则要考虑负载均衡的策略，要模拟大量用户进行各种不同的并发操作，检查负载均衡是否发生有效地作用

稳定性测试怎么测2

如何判断系统的稳定性

系统的四个性质即线性、时不变性、因果性和稳定性都很重要，上次王英吉同学问到系统稳定性的判断问题，下面进行进一步的介绍。

对于连续系统和离散系统的判断，教材中的叙述如下：如果连续系统H(s)的极点都在s平面的左半开平面，离散系统H(z)的极点均在z平面的单位圆内，则该系统是稳定的因果系统。

如果系统函数是已知的，那么根据上面的方法，先求出系统函数的极点，然后根据极点的位置，就可以判断系统的稳定性，于是，问题最后归结为求解一元多次方程的根，即解方程。

吴大正的教材举出一些简单的例子，说明如何判断系统的稳定性，以及当满足系统的稳定性时，一些系统参数应该满足什么条件。但是，当方程是高次的，比如3次、4次等，如果不能进行因式分解而求出方程的根，那么应该怎么办呢？教材没有交代。另一本教材，也是我第一次自学这门课程时所采用的教材，即西电陈生潭等编著的《信号与系统》(第二版，西安电子科技大学出版社，2001年)则介绍了两个重要的准则，即罗斯-霍尔维茨(Routh-Hurwitz)准则和朱里(July)准则。

罗斯-霍尔维茨准则在传统的控制理论课程中都要讲授，它是判别代数方程根的实部特征的一种方法，可以不用解方程就知道方程包含多少个负实部的根。

由于计算机技术的发展，现在用计算机求解高次方程已经很成熟了，因而罗斯-霍尔维茨准则和朱里准则的重要性逐渐降低，很多教材已经不讲这两个准则了。但是，这两个准则曾在历史上有着不可磨灭的功绩，而且难度不大，易于掌握，同学们应该对这两个准则有所了解。

稳定性测试怎么测3

椅类的稳定性测试

（1）适用范围：所有椅类。

（2）测试程序：①将椅固定在地上。②将椅的可调节部分调至最不稳定的状态。③在坐垫及椅背上绑上78kg的重量。④用力于椅背且向后拉直所有重量都着力于椅背上。⑤测量所需的拉力

（3）评定：如果第1及2A类椅所需的拉力少于9kg，2B类的椅所需拉力少于16kg则符合品质要求。

椅子稳定性测试台的特点

1、多功能实现：AFreeFall冲击功能；BLoadEase功能；C单次手动冲击功能；

2、铝型材框架结构，不锈钢测试平台，结构美观大方；

3、利用电磁铁吸合和释放，完全模拟自由跌落状态，跌落过程无阻力，噪音低、

4、配置了液压缓冲机构，大大降低了冲击噪音；

5、椅子水平方向采用"脚杯"结构保持位置，使椅子在垂直方向不受外力约束、

6、电动调节横梁高度，设置了极限开关；

7、安全可靠、所有可动部件全部加装保护罩，防止意外发生、

8、椅子稳定性测试台操作简易，无需任何专用工具辅助、

9、具有停断电记忆功能。

10、可选不同控制形式。

桌子稳定性测试要求

本欧洲标准详述了所有成人的家用椅子的确定稳定性的测试方法和要求。

本标准不适用于靠背可调节，与水平线角夹小于10°的椅子。

稳定性可以根据实验的方法测得或通过计算的方法测得，两种方法都建立在实际应用同样的力和同样的点的基础上。

计算的方法不适用于：在加载力的作用下几何外形易变和明显弯曲的座椅。

如果计算的方法测出来的结果是不确定的或处于临界合格的状态时，如果可能，用实验的方法进行确认。

桌子稳定性测试，会用到以下标准，BS4875-5：2001和BSEN581-3：1999。

桌子稳定性测试（BS4875-5）

用摆锤冲击桌面边缘

摆锤重量：

45kg。摆动高度35mm

检查桌子是否翻倒。

桌子稳定性测试（BSEN581-3）

在桌子边缘100mm位置施加垂直载荷F。F在200N到400N之间

检查桌子是否翻倒。

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。

正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。

一些测试方法主要分以下几种：

压力测试：已知系统高峰期使用人数，验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如：宕机、应用异常中止等)。

Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称(如：lr_rendzvous("same"))在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能)，估算最终并发用户人数。

场景设计思想：

从稳定性测试场景的设计意义，应分多种情况考虑：

针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

1)场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

2)场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

测试方法：采用1)Ramp Up-Load all Vusers simultaneously

2)Duration-Run Indefinitely

3)在Sechedule-勾选Initalize all Vusers before Run

容错性测试：通过模拟一些非正常情况(如：服务器突然断电、网络时断时续、服务器硬盘空间不足等)，验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统)，还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标(如：事务响应时间、最大并发用户数等)。

评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。

评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。

评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。

该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

---