【深度解析】Jmeter性能测试指标的重要性与实现方法！_jmeter 性能需求分析

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

l 响应时间

目前大多数的软件系统客户端与服务器交互过程如图7- 1所示，用户通过客户端（如浏览器）发出业务请求（网络传输时间T1），服务器接收并处理该请求（服务器处理时间T2），然后根据实际的处理模型返回结果（网络返回数据时间T3），客户端接收请求结果（客户端处理展示时间T4）。在这个处理流程中，涉及到的各个业务节点的处理时间总和T1+T2+T3即为系统响应时间。这个时间的计算忽略了用户端数据呈现的时间T4。从用户角度来讲，用户应用客户端发出业务请求，到客户端（通常为浏览器）展现相应的请求结果，这个时间越短越好，即用户视角的响应时间为T1+T2+T3+T4。从服务器角度来讲，服务器接收到客户端发来的请求，并给出结果的响应，这个过程所消耗的时间，记录为响应时间，即服务器仅关注T2的处理时间。因此，不同的视角，衡量的响应时间指标也不同。

通过上述两个不同视角的描述不难发现，用户与服务器所理解的响应时间存在明显的差异。用户关注的是发出请求至看到响应结果的时间，而服务器关注的是接受请求到返回结果的时间，对于用户而言，忽略了浏览器展示的时间，对于服务器而言，则忽略了浏览器展示、网络传输等时间。因此，在实际测试过程中，需明确以什么视角验证被测对象的性能。

大多数情况下，性能测试主要是以用户视角进行，因此在实际测试过程中，通常关注用户行为，所以，响应时间一般指客户端发出请求到接收到服务器端的响应数据所消耗的时间。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】

需注意的是，性能测试工作中，客户有时可能需要测试公网的系统来验证性能指标，从测试经验来看，最好不要尝试在公网进行性能测试，原因有二：

第一、 可能影响现网用户。实施性能测试过程中，可能产生大量的压力与垃圾数据，从而破坏生产环境，导致缺陷的产生，影响实际的业务。

第二、 压力模拟可能无法真实体现。性能测试工程师实施性能测试时，利用测试工具，模拟了大量的并发数，产生了大量的业务数据，但因负载生成器所在的网络与服务器所在网络不同，或者服务器的网络安全设置，导致压力数据无法达到被测服务器，整个网络环境不可控，从而导致测试失败。

有一种情况除外，模拟固定带宽网络访问的场景，可在局域网中使用限制带宽的手段进行测试。遵循一个原则，测试过程中，任何资源都必须可控。

l 吞吐量

单位时间内系统处理用户请求的数量，可以用请求数/单位时间或者点击数/单位时间，或者字节数/单位时间等方式来衡量，其中通过字节数/单位时间的计算方式，与当前的网络带宽比较，可以找出网络方面的问题。例如，1分钟内系统可以处理1000次转账交易，则吞吐量为1000/60=16.7。吞吐量指标直接体现了软件系统的业务处理能力，尤其适用于系统架构选型，做对比测试。

l 系统资源耗用

系统资源耗用，客户端与服务器系统各项硬件资源的耗用情况，如CPU使用率、内存使用率、网络带宽占用率、磁盘I/O输入输出量等。一个系统的高效运行，除了软件资源外，硬件资源也是不可缺少的部分，因此在性能测试过程中，需关注系统资源的耗用。

l 业务成功率

业务成功率意为用户发起了多笔业务请求，成功的比率有多少。例如，测试银行营业系统的并发处理性能，全北京100个网点，中午12:30到13:30一个小时的高峰期里，要求能支持50000笔开户业务，其中成功率不少于98%，也就是需要成功开户49000笔，其他的1000笔可能是超时，或者其他错误导致未能开户成功。业务成功率展示了在特定压力或负载情况下，服务器正确稳定处理业务请求的能力。

l TPS

单位时间内服务器处理的事务数，该指标值越大越好。一般情况下，用户业务操作过程可能细分为若干个事务，单位时间处理的事务数越多，说明服务器的处理能力越强。

根据上述各个指标的概念，结合被测对象本身的业务情况，做出如下测试需求及指标分析。

ECShop是一个面向广大网络用户的电子商务系统。大部分用户会在某个时间段访问该电商平台，进行网络购物，但如何确定用户访问的时间段呢？

新系统没有上线时，没有历史数据可以依据，这种情况下，测试工程师可以通过竞品分析，获取友商系统的运营数据作为参考。以淘宝运营数据为例，通过运营团队统计，大部分消费者集中在如图7- 2所示的时间段访问电商平台。

通过上图分析，业务峰值几乎在15点-17点及21点-23点左右，业务峰值期持续2个小时左右，若要测试稳定性，则需根据实际业务情况模拟用户应用场景。

确定性能测试评估的时间段后，需确定在该时间段内需完成的业务量，这就需要统计有多少人在这个时间段使用ECShop电商系统。统计这个数据比较难，因为各个公司运营规模不一样。这种情况下，测试工程师需根据产品团队的业务规划、产品设计给出一个参考值，比如系统初期设计规模在单天15万业务量，峰值交易5000笔、最高并发100用户（如秒杀业务）等。通过对预设业务目标的分析，可得出以下几个数据：

1. 峰值时间段2个小时；

2. 单天15万业务量访问；

3. 峰值交易5000笔；

4. 最高并发100个用户。

接着分析，满足上述需求的同时，还需要考虑业务的响应时间。被测对象的响应时间，作为一个很直观的用户体验数据，可很好的衡量被测对象是否让用户感受好，但感受好并没有一个量化的指标，只是个相对的概念。响应时间在业内一个经验值，采用Apdex联盟的建议值：3秒、3秒-12秒，12秒以上。0-3秒的业务处理响应时间是非常理想的，而3秒-12秒则是普遍可容忍的时间，但超过12秒的响应时间，用户一般不会接受，可能选择刷新，甚至放弃操作。这样的经验值在实际测试中对确定响应时间有很高的参考价值，当然响应时间还应该根据业务类型确定，而不能仅从用户的感官考虑。本次项目测试采用常规的5秒为目标，也就是说ECShop平台处理登录、商品随机浏览购买等业务的服务器响应时间均不超过5秒。

单天15万业务量，表明在一天时间内总的业务量为15万，但未明确是哪些业务的数据量叠加，还是每项业务都是此要求。此处假定单项业务每天有15万的数据量。

从图7- 2得知，用户访问并非是均分在24个小时内，因此，在没有历史数据可依据的情况下，利用经济学中的“二八原则”进行分析，80%的业务量集中在20%的时间段内。单天峰值时间段共有2个：15点-17点，21点-23点，可得如下业务量分解数据：

15万*80%=12万

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

54613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！