关于系统性能和稳定性测试的信息

本篇文章给大家谈谈系统性能和稳定性测试，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享系统性能和稳定性测试的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、怎样检测电脑的稳定性
• 2、常见性能测试的方法是
• 3、性能测试常见分类及关注指标
• 4、如何测试服务器的稳定性？
• 5、十分钟学会性能测试（上）

怎样检测电脑的稳定性

1/5

下载AIDA64到电脑并安装好，AIDA64可以检测电脑中的软硬件信息，底层的硬件扫描，使它可以详细的显示出PC硬件每一个方面的信息，AIDA64提供的稳定性测试十分强大，能够让CPU、RAM等硬件长时间满负荷运转，同时提供传感器的监测数据，让用户对电脑的稳定性一览无遗，下面使用它进行测试。

2/5

1.打开AIDA64，加载两秒左右进入主界面，可以看到较多项目，用于检测本机硬件参数型号等，有兴趣的可以逐项查看，这里我们点击计算机》传感器，可以看到本机的CPU，硬盘，显卡，南桥的实时温度及其他数据。

3/5

2.我们直奔主题，点击菜单栏工具》系统稳定性测试，打开测试界面，可以看到左上角有六个测试项目（整型，浮点FPU，缓存，内存，硬盘，显卡GPU），下方有CPU的实时状况动态图表，先以仅测试CPU为例，一般使用电脑我们仅需勾选前三项，如果玩游戏多的可以只勾FPU，温度会高很多，选好点击下方start按钮开始烤机测试，；

4/5

3.开始后软件会给CPU 100%的负载，持续若干分钟（10分钟一般足够)，若CPU温度能一直稳定在一个小范围（如我的稳定在65度左右），且该温度不超过80度那散热还可以;点击图表上方的clocks查看CPU实时频率记录，如能一直保持最高频率不降（如我的i3一直保持2.4GHz），此机稳定性较好，因为有些机器尤其笔记本，CPU温度超过一个临界温度（如85度）就会强制降频，甚至有的降为0.8GHZ；测完及时点击下方的stop停止；

5/5

4.还有实时风扇转速记录，电压记录，功耗记录，及统计数据，可以自行查看。其余测试如硬盘，显卡测试AIDA也能进行，才做方法一样，这里就不多说了。

常见性能测试的方法是

常见的性能测试方法有以下几种系统性能和稳定性测试：
1．负载测试
在这里，负载测试指的是最常见的验证一般性能需求而进行的性能测试，在上面我们提到系统性能和稳定性测试了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解系统性能和稳定性测试：
（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。
2．压力测试
压力测试是为系统性能和稳定性测试了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。
3．并发测试
验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。
4．基准测试
当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。
5．稳定性测试
“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。
6．可恢复测试
测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。
提示：每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。

性能测试常见分类及关注指标

性能测试方法是通过模拟生产运行的业务压力量和使用场景组合系统性能和稳定性测试，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。
特点：
1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。
也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。

通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或某种资源已经达到饱和状态。
特点：
1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。
也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“系统性能和稳定性测试我的要求”或系统崩溃。
负载测试方法是对系统或设备进行增加压力并测量其性能指标的过程。执行负载测试以在正常和峰值负载条件下找出系统的行为。有助于指定应用程序的极限操作量以及任何瓶颈，以便隔离导致降级的组件。换一种说法，麻烦制造者。

压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误
特点：
1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。
也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。
当系统上的负载超出标准使用模式，以检查异常极端或最高负载下的系统反应时，这就是压力测试。负荷通常如此之大以至于错误条件是预期的结果，但是当活动不再是负荷测试并且变成压力测试时，不存在明确的边界。

并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者系统性能和稳定性测试他性能问题。
特点：
1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
其主要目的是发现系统中可能隐藏的并发访问时的问题。例如内存泄漏、线程死锁、资源争用等。

配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。
也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。

基准测试是通过科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的可对比的测试；可测量、可重复、可对比是基准测试的三大准则（取自百度百科）

其主要目的是为对某项性能指标（或业务指标）与某一基线指标相对比的测试过程（可对比）

在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
特点：
1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）
3、测试过程中需要关注系统的运行状况。

可靠性测试是为了评估产品在规定的寿命期间内、在预期的使用、运输或储存等所有环境下、保持功能可靠性而运动的活动，是将产品暴漏在自然或人工的条件下经受其作用，以评价产品在实际应用、运输的环境条件下的性能，并分析研究环境因素的影响程度以及其工作机制。。。。

其实可靠性测试的概念大致概念就是通过给系统加载一定的业务压力（例如资源在70%~90%的使用率），让应用持续运行一段时间，测试系统在这种条件下能否稳定运行。
也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。

稳定性测试是就测试系统长期稳定运行的能力，在系统的运行过程中，对系统进行施压，观察系统的各项性能指标，以及服务器指标。

其主要目的在与系统长期处于压力下的运行能力（或者正常业务压力下）；在测试过程中尽量延长测试时间，增大压力来提高测试的可靠性。
容量测试：（Capacity Testing）

容量测试，顾名思义，大致概念偏向于负载测试（百度百科巴拉巴拉，不再粘贴）

扩展性测试：（Extensibility Testing）

通常说的水平伸展（也是高并发系统中的一个重要因素），何谓水平伸展，在保证系统性能的情况下，可以通过增加机器来释放系统压力，谓之水平伸展。

失效恢复测试是针对有冗余备份和负载均衡的系统设计的。该测试方法可以用来检验如果系统局部发生故障，用户是否能够继续使用系统，以及如果这种情况发生，用户将收到多大程度的影响。

特点：
（1）主要目的在于验证在局部故障情况下、系统能否继续使用；一般的关键业务系统都会采用热备份或负载均衡的方式来实现。这种业务系统一般要求如果有一台或者几台服务器发生故障，应用系统仍然能够正常执行业务。测试时可以模拟服务器故障，观察恢复技术是否能够发挥作用。

（2）这种性能测试方法还需要指出，当问题发生后系统能够支持多少用户访问的概念或者采取某种应急措施的方案。

（3）一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。不是所有的系统都需要进行该测试的。

浪涌测试是中模拟加压的场景测试，固定的线程数量在不同的时间内持续运行相同的时间。

例如：
10个线程在10s启动，持续运行10s，10s停止。

10个线程在20s启动，持续运行10s，10s停止。

10个线程在30s启动，持续运行10s，10s停止。

接口性能测试方案 白皮书 V1.0

性能常关注指标

如何测试服务器的稳定性？

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。
正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。
一些测试方法主要分以下几种：
压力测试：已知系统高峰期使用人数，验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如：宕机、应用异常中止等)。
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资源监控命令等。并在场景运行过程中辅以手工测试。

十分钟学会性能测试（上）

本文分上下两个部分系统性能和稳定性测试，上半部分主要介绍：

一、什么是性能测试

二、术语

三、性能测试类型
下半部分主要介绍：

四、性能测试流程

五、性能测试执行（三分钟教会系统性能和稳定性测试你用Jmeter进行性能压测）

六、结果查看及分析
    通篇的风格以寓教于乐为主，介绍知识为辅。希望大家能在快乐中学习，在开心中成长。时间仓促，错误纰漏在所难免，还请“大神”不惜指正系统性能和稳定性测试！
一、什么是性能测试
     性能测试 是通过对系统进行性能需求分析，在合理评估的性能测试环境上，通过测试工具模拟正常、峰值、以及异常负载条件对系统各项性能指标进行测试，旨在发现性能缺陷、进行能力验证、验证规划能力和性能调优，并针对测试结果进行分析总结定位的测试过程。（* 引自专家测试团队《性能测试白皮书》）

************解释************

   通俗点说，就是使用用各种“酒具”（jmeter、LoadRunner、Power平台）配合着各种“红、白、啤酒”（入参数据+并发数）来让你达到“正常嗨（正常）、非常嗨（峰值）、嗨过头（异常负载）”的状态，并在这期间通过“心电图”（JMC-- Java Mission Control）或者把你放到“提前定制化的座椅”（RSMS、Dolphin）来持续对你进行观察、监控，从而记录下你在不同剂量下的反应。并根据观察结果来分析“红酒您能喝几瓶”、“白酒能喝几瓶”、“啤酒能喝几瓶”（能力验证）；强化系统性能和稳定性测试了身体素质（系统性能优化）之后又能喝几瓶；甚至是规划一下“有蒙古大汉自远方来不亦喝乎”时，你能不能喝翻他（容量规划）等等……，这些过程，就是“性能测试”！

二、术语

    在继续介绍性能测试之前，我们有必要先解释一下经常用的一些术语。否则我瞎逼逼半天，您一脸懵逼，大家就真的在尬聊了……

1.并发用户数

    同一时刻操作某个页面或某个功能的用户数，描述系统能够承受的并发性能。它是一个时间段内发生的事情，它意在表达“并发”的可能性，是压力的一种度量。计算公式：C=nl/t

 n :  业务在线的总用户数量

 l :  业务产生的平均时间长度

 t :  考察的时间段总长度

************解释************
  我们假想出一个很长很长的水泥管道，管道入口处站了1000个高矮胖瘦一致的人，其中有400人想要通过这个管道。每个人走过这个管道平均需要1个小时，前面的人没走完时入口不放行下一组进入，且入口处每天只有8小时可以放行让人进入。那么，这时“预期”的并发用户数就是400*1/8=50，也就是说，只有管道宽的可以装下50人并排走，才能在一天之内让400人都通过。

    为什么说是“预期”呢？那是因为可能您胆子小，假想的时候没敢想太大，就只想出了一个允许2人通行的小水管。那8小时肯定走不完所有人啊，所以你需要继续想、使劲努力YY出一个巨大的管子（性能优化）！当然，不排除您跟我一样天赋异禀，一开始就构想出能同时并排200人的巨管。这意味着，就并发用户数这一项，您的系统性能指标完爆当前既定业务量。

  

2.响应时间

   用户发起请求到响应返回的时间，描述交易执行快慢程度。（计算规则：响应时间=网络传输时间+系统响应时间）

90%Percent：每个事务90%用户的响应时间在该值以下

Minimum：每个事务所有用户中最小的响应时间

Average：每个事务所有用户的响应时间算数平均值

Maximum：每个事务所有用户中最大的响应时间

************解释************

    还是继续走管道……我们给每个人发一个秒表，人们并排进入管道的同时每个人按下秒表。每个人行走的速度不同，虽然是并排进入，但并不是一同出来。每一个人走出管道的同时，再次按下秒表……这时，秒表记录的时间就是这个人（请求）开始到结束的响应时间。

90%Percent：我们把同时走管道的一波人看做一个队伍，队伍中90%的人是在这个时间以内就走出了管道；

Minimum：走的最快的那个人所用的时间；

Average：所有人花费时间的平均值（在这个例子中为1小时）；

Maximum：走的最慢的那个人所用的时间。

  

 3.TPS

 指每秒处理的事务数，TPS=总事务数/总的时间，描述了服务器的处理能力。

 ************解释************

    一句话，就是每秒钟通过管道的人。这里肯定有人觉得这个概念看着眼熟，很像最开始的并发用户数，对么？仔细看一下他们的区别：并发用户数是指同时进入管道的“肩并肩”的人，吞吐量是指每秒钟那些肩并肩进入管道的人中，平均多少人走了出来。所以，在这里“TPS = 并发数/平均响应时间”

    

4.二八法则

   【80%的业务请求在20%的业务时间里面产生。】

   如：信用卡客服系统中"客户信息查询功能”年使用量为4800万次，系统服务时间为7*24小时。每秒请求数：

   48000000*80%/365*24*3600*20%=38400000/6307200=6次/秒

 ************解释************

 这个有毛用呢？试想一下，如果我们要压这个信用卡客服系统，是不是真的需要7*24小时不停压一年凑够4800万个请求呢？用脚趾头也能想明白，肯定不用啊！那如何在减少工作量的情况下尽可能的模拟真实场景呢？这个时候二八法则就出场了！（别问我为什么不是三七、四六、五五法则，你当是在分赃吗？）
5. 2-5-8原则

    WEB系统性能测试中的2-5-8原则描述如下：

用户在2秒以内得到响应时，系统的响应很快，用户对系统的体验较优；

用户在2-5秒之间得到响应时，系统的响应速度还可以，用户对系统的体验一般；

用户在5-8秒以内得到响应时，系统的响应速度较慢但还在接受范围，用户对系统的体验较慢；

用户在超过8秒后仍然无法得到响应时，通常会认为系统已经失去响应，选择离开或者发起第二次请求，用户对系统的体验很糟糕。

************翻译************

这个没啥好解释的，就是个“业界”非标准化的一个标准……所以，以后在项目中没有明确要求某功能or页面的响应时间时，就拿这个当标准来考量吧！另外需要补充的一点是，我们用jmeter一般是压接口，我们得出的响应时间一般会小于直接压页面，为什么呢？这里影响响应时间的除了网络传输时间+系统响应时间，还有个前端页面渲染的时间。所以如果我们想web用户体验较好（3秒内），压接口的响应时间最好就要低于3秒，这给页面渲染留出一定的冗余时间。
三、性能测试类型

    终于要开始介绍性能测试的干货（Fuck foods）了。
1、基准测试

测试系统是否存在线程安全性问题，并得到一定测试条件下的系统的性能基线数据。目的是得到系统的性能基线数据，并对响应时间、TPS和其他与时间相关的需求进行评估。

************翻译************

俗话说的好，“凡事都有个第一次，再丑的媳妇也要见公婆”。这个类型就是针对之前没有做过性能测试，或者是根据新需求而刚刚开发完成的新系统来说的。这时，您就需要来一份“基准测试”啦！先给自己留个底儿，有了性能基线，我们才能继续后面的“调优”不是？

对比测试

对比不同测试条件下的性能差距，常用于系统优化，技术选型，通过相同的用例对比性能数据。测试方式和负载测试类似。

************翻译************

多说无益，我们“举几个比方，打几个栗子”：

我们对系统的某功能进行了优化，需要验证该功能在优化前后的性能对比数据时，可以进行对比测试；

老板让我说出两种系统架构或者实现方法下，哪一种更好，可以进行对比测试；

老板让我说出这两款设备，哪一款更优秀，可以进行对比测试。

说白了，就是各种比较，没有对比就没有伤害；不对比你怎么能知道你有多胖呢，对不对？！（观众：扔砖头！！！）
2、容量规划

测试系统在软硬件上的扩展能力，常用于测试软件扩容，硬件扩容。容量规划也是对比测试的一种。

************翻译************

就如定义中所说，容量规划也是对比测试的一种。这个类型主要使用场景有：

软件扩容：我们用多线程来代替原有的单线程处理请求；

硬件扩容：我们增加了两台redis，加大了weblogic server的内存或者直接增加了4台服务器。

在这里也要额外说一点：我们扩容，特别是硬件扩容，是不能按照倍数来放大扩容效果的。例如，我们2台server时TPS为100，我们增加到4台同样配置的server时，TPS并不是增加到200了。有可能是160、170、180……这其中并没有一个线性的关系，这点很重要需要知悉。所以，很多时候项目组找到我们做性能测试，说我们生产环境与测试环境配置相同，只是数量不同，是否能直接换算性能指标呢？答案是否定的！我们只能说，你在测试环境中如果满足了预期性能指标，那生产环境理论上是没有问题的，no more！
3、稳定性测试

采用系统稳定运行情况下能够支持的最大并发用户数，或者日常运行用户数，持续运行一段时间。目标是检测系统能否持续稳定工作。

************解释************

其实，我们在用Jmeter压测的时候，至少都要持续10~15min以上，为什么呢？我们要让TPS稳定下来，这时采集的数据才有效；当然，并不是说15分钟就一定够了，某些情况下需要更长时间的压测才能发现性能问题。

稳定性测试多用于对“系统稳定性”有“强需求”的系统，比如金融类的银行、证券等等。如系统要求3*24小时运行，测试当系统在一定的压力情况下（如CPU资源使用率维持在50%左右），选取复合场景的案例，持续运行3x24小时，观测系统的稳定性状态数据。

还有一种是：测试人员发现，系统在短时间（1个小时、8个小时甚至1天）内都是正常的，但一超过一定时间后就会CPU利用率徒增，或者内存持续增高（疑似内存泄露），这也需要来一场轰轰烈烈的稳定性测试……
4、负载测试

负载测试是通过逐渐增加用户量来观察在不同的负载下系统的指标，以检验系统的行为和特性，以发现系统可能存在的性能问题，并可以检测系统的伸缩性。

也可以确定在什么负载条件下系统性能处于失效状态，目标是获得系统能提供的最大服务级别。

************解释************

负载测试是大家平时做性能测试使用最多的一种类型，甚至有些时候大家嘴里所说的性能测试，就是指的负载测试。说的直白点，就是你写好脚本跑个100并发，发现对于系统来说“洒洒水啦”，监控显示内存和CPU指标都懒得波动一下。那我们加到400试试，加到500呢，1000……？所以，这就是一个“试”的过程，直到系统“失效”！这里的“失效”不一定是指系统宕机，监控显示CPU、Memory利用率超过80%了也叫失效，系统响应时间超过预期的3秒了也叫失效，就看哪个条件先被打破了…… 关于系统性能和稳定性测试和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统性能和稳定性测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、系统性能和稳定性测试的信息别忘了在本站进行查找喔。