目录结构
通过前文 性能测试需求分析 对性能测试的必要性评估之后，敏捷开发团队确定利用开源工具JMeter实施性能测试工作根据被测对象的应用特性，首先需要获取 具体的性能测试需求
对于相对规范的产品，产品团队一般会给出相对明确量化的性能测试要求，如下表所示：
可以看出，上表给出的性能指标比较明确性能测试活动实施过程中，测试工程师只需收集随机购买商品的 [ 响应时间访问成功率并发数CPU使用率内存使用率 ] 等相关指标的监测数据，与表中的量化指标比对即可满足相关指标，则测试通过；若未满足，则需要进行问题分析定位，最终进行调优与回归，直至达到性能测试需求
以本次项目为例，产品团队并未指明性能测试需求，那么测试工程师如何分析提取量化的性能指标呢？
从用户应用角度考虑，若被测对象 常用的业务 的性能存在瓶颈，则很可能引起客户的反感以登录功能为例，输入用户名和密码，点击登录按钮到显示成功登录信息，若耗时1min，用户绝对无法忍受用户 不常用的功能 ，如年度报表汇总功能，一个季度甚至是一年才使用一次，等几分钟or更长时间也有可能被接受
So，不同的应用频率，决定了用户的使用感受，也决定了测试的需求
针对本次ECShop电商系统而言，商城用户经常使用的功能，且存在大量用户使用的业务有：用户注册登录随机浏览商品购买业务等，而其他功能则相对用户较少若电商系统已经正式运营，则可从系统 运营日志 中分析具体的数据若尚未上线运营，则需要 调研用户 or根据 自身经验 进行分析获取
根据 [JPT_01]性能测试需求分析 中的描述，分析哪些是用户常用or交易占比超过80%的业务；从运营及项目组角度分析，哪些业务相对重要，然后确定为 业务测试点
综合分析，本次项目实践以 用户登录随机浏览并购买商品 为测试点确定业务测试点后，即可进行详细的业务需求分析，从而明确性能测试指标
不同的被测对象，不同的业务需求，可能有不同的指标需求，但大多数测试需求中都包含以下几种性能指标：
目前，大多数软件系统客户端与服务器交互的过程，如下：
因此，不同的视角，衡量的响应时间指标也各不相同实际测试过程中，需明确以什么视角验证被测对象的性能
大多数情况下，性能测试响应时间主要以客户端发出请求，直至接收到服务端的响应数据过程中所消耗的时间作为参考
严格来讲： 响应时间=呈现时间+网络传输时间+服务器端响应时间+应用延时时间
Tips：
不建议尝试在公网进行性能测试，原因如下：
可能影响现网用户 实施性能测试过程中，可能产生大量压力与垃圾数据，从而破坏生产环境，导致缺陷的产生，影响实际的业务
压力模拟可能无法体现真实场景 实施性能测试时，利用压测工具模拟大并发数，会产生大量业务数据因负载生成器与服务器所在的网络不同，or服务器特定的网络安全设置，导致压力数据无法达到被测服务器，整个网络环境不可控，从而导致测试失败
有一种情况除外，模拟固定带宽网络访问的场景，可在局域网中使用限制带宽的手段进行测试
总之，需要遵循一个原则： 在测试过程中，任何资源都必须可控
衡量方式：
其中，[字节数 / 单位时间] 的计算方式，与当前的网络带宽比较，可找出网络方面的问题
吞吐量计算：例如1分钟内系统可以处理1000次转账交易，则吞吐量为1000/60=16.7 (次/秒)
一个系统的高效运行，除了软件性能要求外，还需要对硬件资源进行监控若用户需求项目组or其他利益相关方均未提出性能指标要求，则可参考行业经验，CPU使用率80%内存使用率80%网络带宽占用50% ...
PS：
80%只是作为一个经验参考值，最终的性能测试指标需要经过项目相关各方评审才能确定
通过上述业务数据分析，最终得到本次项目测试的性能需求指标，如下：
例如，测试银行营业系统的并发处理性能，有100个网点，上午10:00-11:00的一个小时高峰期里，要求能支持50000笔开户业务，其中成功率不低于98%，也就是需要成功开户49000笔，其他的1000笔可能是超时，或者其他错误导致未能开户成功
根据上述各指标，结合被测对象本身的业务情况，进行测试需求及指标分析：
通过对预设业务目标的分析，可得出以下数据：
计算业务量的分解数据：
综上，需要测试ECShop电商平台在2h内支持5w用户登录随机浏览商品进行购买的业务
