通常情况下，性能测试关注被测对象的时间与资源利用特性及稳定性。时间特性，即被测对象实现业务交易过程中所需的处理时间，从用户角度来说，越短越好。资源利用特性，即被测对象的系统资源占用情况，一般Web系统不关注客户端的资源占用情况，仅关注服务器端，通常为服务器端的CPU、内存、网络带宽、磁盘等（根据被测对象架构设计，还可分为Web服务器、中间件、数据库、负载均衡等）。稳定性，关注被测对象在一定负载情况下，持续稳定提供服务的能力。

不同的被测对象，不同的业务需求，可能有不同的指标需求，但大多数测试需求中都包含以下几个性能指标：

l 并发数

并发，即为同时出发，从应用系统架构层面来看，并发意为单位时间内服务器接受到的请求数。客户端的某个具体业务行为包括了若干个请求，因此，并发数被抽象理解为客户端单位时间内发送给服务器端的请求，而客户端的业务请求一般为用户操作行为，因此，并发数，也可理解为并发用户数，而这些用户是虚拟的，又可称为虚拟用户。

并发数，广义来讲，是单位时间内同时发送给服务器的业务请求，不限定具体业务类型，狭义来看，是单位时间内同时发送给服务器的相同的业务请求，需限定具体业务类型。在性能测试实施过程中需注意二者的区别。

l 响应时间

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

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

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

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

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

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

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

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

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万

24个小时*20%=4.8小时

4小时/4.8小时=83%

以15点-17点，21点-23点为总考察时间段，则期望业务量值为：

12万*83%=9.96万

以15点-17点为测试考察段，则期望业务量值为：

12万*（2小时/4.8小时）=5万

通过上述分析，需测试ECShop平台在2小时内支持5万用户登录及商品随机浏览购买。

除了软件性能要求外，还应该对硬件资源进行监控，比如服务器CPU使用率、内存使用率、网络带宽等。如果用户需求、项目组或其他利益相关方未提出性能指标要求，则可按照行业经验，CPU使用率不超过80%、内存使用率不超过80%、网络带宽占用不超过50%等。CPU使用率超过80%表明CPU应用繁忙，如果持续维持在90%甚至更高，很可能导致机器响应慢、死机等问题。当然，过低也不好，说明CPU比较空闲，可能存在资源浪费的问题。对于内存存在同样的问题。当然，80%只是一个经验值，最终的性能测试指标需经过评审才能最终确定。

通过上述业务数据分析，最终得到本次测试的性能需求指标如下图所示

得出本次测试的性能参考指标后，测试工程师即可进行性能测试模型的建立

END，今天的分享就到此结束了！点赞关注不迷路！