在明确性能需求时，测试活动相对来说，较为容易开展。但实际工作中，经常会碰到没有明确性能需求的测试要求。因此，测试工程师需要具备不同输入分析，获取性能测试需求的能力。以ecshop项目为例，产品团队并未指明性能测试需求，那么测试工程师可以按以下方法，分析提取量化的性能指标。
从用户应用角度考虑，被测试对象常用业务性能存在瓶颈的话，很容易引起用户的反感。
以登陆功能为例，输入用户名与密码，点击登录按钮到显示成功登录信息，如果耗时1分钟，这样的速度用户绝对无法忍受。用户不常用，比如年度报表汇总功能，三个季度甚至是一年才使用，等个10分钟或者更长的时间，也是正常的。
不同的应用频率，决定了用户的使用感受，也决定了测试的需求。针对本次ecshop电商系统而已，商城用户经常时候用的功能，且存在大量用户使用的业务为用户注册和登陆、随机浏览商品及购买业务等。而其他功能，则相对用户较少。
具体的数据如果系统已经运营了，则可从系统运营日志分析。如果尚未上线的运营，则需要调研用户或根据自身经验进行分析获取。
测试工程师，需要根据理论知识，分析哪些是用户常用或交易占比超过80%的业务、从运营及项目组角度分析，哪些业务相对重要，然后确定这些业务为测试点。
综合分析，以用户登陆、随机浏览并购买商品为测试点。确定业务测试点后，即可进行详细的业务需求分析，从而明确性能测试指标。
通常情况下，性能测试关注被测试对象的时间与资源利用特性及稳定性。
时间特性：即被测试对象实现业务交易过程中所需的处理时间，从用户角度来说，越短越好。
资源利用特性：即被测试对象的系统资源占用情况，一般web系统不关注客户端的资源占用情况。仅关注服务器端，通常 为服务器的CPU、内存、网络带宽、磁盘等（根据被测试对象架构设计，还可分为web服务器、中间件、数据库、负载均衡等）。稳定性，关注被测试对象在一定负载情况下，持续稳定提供服务的能力。
不同的被测试对象，不同的业务需求，可能有不同的指标需求，但大多数测试需求中都包括以下几个性能指标。
并发数：
并发，即为同时出发，从应用系统架构层面来看，并发就是单位时间内服务器接受到的请求数。客户端的某个具体业务行为包括了若干个请求，因此，并发数被抽象理解为客户端单位时间内发送给服务器端的请求，而客户端的业务请求一般为用户操作行为，因此，并发数，也可理解为并发用户数。而这些用户是虚拟的。又可称为虚拟用户。
并发数，广义来讲，是单位时间内同时发送给服务器的业务请求，不限定具体业务类型，侠义来看，是单位时间内同时发送给服务器的相同的业务请求，需要限定具体业务类型。在性能测试实施过程中需要注意二者的区别。
响应时间：
用户关注的是：发出请求至看到响应结果的时间，而服务器关注的是接受请求到返回结果的时间。对于用户而言，忽略了浏览器展示的时间，对于服务器而言，则忽略了浏览器展示、网络传输等时间。因此，在实际测试过程中，需明确以什么视角验证被测试对象的性能。
大多数情况下，性能测试主要是以用户视角进行。因此在实际测试过程中，通常关注用户行为，所以，响应时间一般指客户端发出请求到接收到服务器端的响应数据所消耗的时间。
需要注意的是，性能测试工作中，客户有时可能需要测试公网的系统来验证性能指标，从测试经验来看，最好不要尝试在公网进行性能测试，原因是：
- 可能影响现网用户。实施性能测试过程中，可能产生大量的压力与垃圾数据。从而破坏生产环境，导致缺陷的产生，影响实际的业务。
- 压力模拟可能无法真实体现。性能测试工程师实施性能测试时，利用测试工具，来模拟了大量的并发数，产品了大量的业务数据，但因负载生成器所在的网络与服务器所在的网络不同，或者服务器的网络安全设置，导致压力数据无法达到被测试服务器，整个网络环境 不可控，从而导致测试失败。
有一种情况除外，模拟固定宽带网络访问的场景，可在局域网中使用限制宽带的手段，进行测试。遵循一个原则，测试过程中，任何资源都必须可控。
吞吐量
单位时间内系统处理用户请求的数量，可以用请求数/单位时间、或者点击数/单位时间，或者字节数/单位时间等方式来衡量。其中通过字节数/单位时间的计算方式，与当前的网络带宽比较，可以找出网络方面的问题。
例如：1分钟内系统可以处理1000次转账交易，则吞吐量为1000/60=16.7。
吞吐量指标直接体现了软件系统的业务处理能力，尤其使用于系统架构选型，做对比测试。
系统资源耗用
客户端与服务器系统各项硬件资源的耗用情况。如CPU使用率，内存使用率，用户带宽占用率，磁盘I/O输入输出量等。一个系统的高效运行，除了软件资源外，硬件资源也是不可缺少的部分，因此在性能测试过程中，需关注系统资源的耗用。
业务成功率
业务成功率意为用户发起了多笔业务请求。成功的比率有多少。如果测试银行营业系统的并发处理性能，全北京100个网点，中午12:30到13:30一个小时的高峰期里，要求能支持50000笔开户业务，其中成功率不少于98%，也就是需要成功开户49000笔，其他的1000笔可能是超时，或者其他错误导致未能开户成功。
业务成功率展示了在特定压力或负载情况下，服务器正确稳定处理业务请求的能力。
每秒服务器处理的事务数TPS
单位时间内服务器处理的事务数，该指标值越大，越好。一般情况下，用户业务操作过程可能细分为若干个事务，单位时间处理的事务数越多，说明服务器的处理能力越强。
通过上图分析，业务峰值几乎在15点-17点及21点-23点左右。业务峰值期待持续2个小时左右。若要测试稳定性，则需根据实际业务情况，模拟用户真实的应用场景。
确定性能测试评估的时间段后，需确定在该时间段内需完成的业务量。这就需要统计有多少人在这个时间段使用ECShop电商系统，统计这个数据比较难。因为各个公司运营规模不一样。这种情况下，测试工程师需根据产品团队的业务规划，产品设计给出一个参考值。比如系统初期设计规模在单天15w业务量，峰值交易5000笔，最高并发100用户（如秒杀业务）等。通过对预设业务目标的分析，可得到以下几个数据：
- 峰值时间段2个小时
- 单天15w业务量访问
- 峰值交易5000笔
- 最高并发100用户
接着分析，满足上述需求的同时，还需要考虑业务响应时间。被测对象的响应时间，作为一个很直观的用户体验数据。可很好的衡量被测对象是否让用户感受好，但感受好并没有一个量化的指标。只是个相对的概念。响应时间在业内一个经验值，根据2-5-8原则，在实际测试中对确定响应时间有很高的参考价值。当然响应时间还应该根据业务类型确定，而不能仅从用户的感官考虑。本次项目测试采用常规的5秒为目标，也就是说Ecshop平台处理登陆、商品随机浏览购买等业务的服务器响应时间均不超过5秒。
看图得知，用户访问并非是均分在24小时内，因此，在没有历史数据可依据的情况下，利用经济学中的’二八原则‘进行分析。80%的业务量集中在20%的时间段内。单天峰值时间段共有2个：15点-17点，21点-23点，可将业务量这么分解数据：
15w * 80% = 12w
24个小时 * 20% = 4.8小时
4小时 / 4.8小时 = 83%
以15点-17点，21点-23点为总考察时间段，则期望业务量值为：
12w * 83% = 9.96w
以15点-17点为测试考察段，则期望业务量值为：
12w * （2小时 / 4.8小时） = 5 w
通过上述分析，需测试Ecshop平台在2小时内支持5w用户登陆及商品随机浏览购买。
除了软件性能要求外，还应该对硬件资源进行监控，比如服务器CPU使用率，内存使用率，网络带宽等。如果用户需求，项目组或其他利益相关未提出性能指标要求，则可按照行业经验，cpu使用率不超过80%、内存使用率不超过80%，网络带宽占用不超过50%。cpu使用率超过80%表面CPU繁忙，如果持续维持在90%甚至更高，很可能导致机器响应慢，死机等问题。当然，过低也不好，说明CPU比较空闲，可能存在资源浪费的问题。对于内存存在同样的问题，当然，80%只是一个经验值，最终的性能测试指标需经过评审才能最终确定。
来源：CSDN
作者：测试开发老鸟
链接：https://blog.csdn.net/Lylianko/article/details/104229368