关于系统性能测试例子的信息

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

本文目录一览：

• 1、常用的性能测试方法有哪些
• 2、性能测试的实现方法是什么
• 3、十分钟学会性能测试（上）

常用的性能测试方法有哪些

1．负载测试
在这里，负载测试指系统性能测试例子的是最常见的验证一般性能需求而进行的性能测试，在上面系统性能测试例子我们提到系统性能测试例子了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。系统性能测试例子我们对负载测试可以有如下理解：
（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。
2．压力测试
压力测试是为系统性能测试例子了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。
例子：负载测试关心的是用户规则和需求，压力测试关心的是软件系统本身。对于它们的区别，我们可以用华山论剑的例子来更加形象地描述一下。如果把郭靖看做被测试对象，那么压力测试就像是郭靖和已经走火入魔的欧阳峰过招，欧阳锋蛮打乱来，毫无套路，尽可能地去打倒对方。郭靖要能应对住，并且不能丢进小命。而常规性能测试就好比郭靖和黄药师、洪七公三人约定，只要郭靖能分别接两位高手一百招，郭靖就算胜。至于三百招后哪怕郭靖会输掉那也不用管了。他只要能做到接下一百招，就算通过。
思考
我们在做软件压力测试时，往往要增加比负载测试更多的并发用户和交易，这是为什么？
3．并发测试
验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。
4．基准测试
当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。
5．稳定性测试
“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。
6．可恢复测试
测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。
提示：每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。

性能测试的实现方法是什么

狭义的软件性能测试指为验证软件性能指标、评估系统服务能力、推荐系统软硬件配置、完成系统性能优化等而开展的测试活动；
广义的软件性能测试指在测试过程中需要相关性能测试方法配合完成的系统测试活动，包括可靠性测试、可恢复性测试、稳定性测试、兼容性测试、可扩展性测试等。
性能测试的七种方法：
1.基准测试
基准测试是指通过设计科学的测试方法，测试工具和测试系统，实现对一类测试对象的某项指标进行定量的和可对比的测试。
2.压力测试
通过对软件系统不断施加压力，识别系统性能拐点，从而获得系统提供的最大服务界别的测试活动，主要目的是检查系统处于压力情况下应用的表现。
3.负载测试
通过在被测系统中不断增加压力，直到达到性能指标极限要求。主要目的是找到特定的环境下系统处理能力的极限。
4.并发测试
主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题，几乎所有的性能测试都会涉及并发测试。主要目的并非是为了获得性能指标，而是为了发现并引起的问题。
5.疲劳测试
通过让软件在一定访问量情况下长时间运行，以检验系统性能在多长时间会出现明显下降，主要目的是验证系统运行的可靠性。
6.数据量测试
通过让软件在不同的数据量情况下运行，以检测系统性能在各种数据量情况下的表现。主要目的是找到支持系统正常工作的数据量权限。
7.配置测试
配置测试主要是针对硬件而言，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
为什么学习性能测试？
门槛相对较低：比起自动化测试的纯写代码，性能测试入门门槛相对较低，是大部分转型和提升的朋友首选的切入口。
快速完善知识体系：优秀的性能测试工程师需要学习数据库、架构、工具等多方面的知识，能帮助大家完善整体的知识体系，提升综合竞争力。
市场大：性能测试工程师目前尚未饱和，处于发展中，机遇和挑战并存，谁能提前切入该领域谁就占领一席之地，你懂得！（单纯的功能测试以后危机会越来越严重）

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

本文分上下两个部分，上半部分主要介绍：

一、什么是性能测试

二、术语

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

四、性能测试流程

五、性能测试执行（三分钟教会系统性能测试例子你用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秒了也叫失效，就看哪个条件先被打破了…… 关于系统性能测试例子和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统性能测试例子的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、系统性能测试例子的信息别忘了在本站进行查找喔。