如果是研发的测试，一般在项目之初，开发人员是提不出很明确的性能指标的，那么我们怎么引导开发人员给出量化的性能指标呢？

做性能测试之前，相关功能测试必须完成，架构、部署已基本稳定，把描述性的性能指标转换成量化的指标，才具备可测试性

立项之初性能需求一般是模糊：系统性能好、反应速度快，那么如何转成量化指标呢？一般从最终用户、业务、技术和标准等某个方面获得足够的信息和数据

□ 最终用户的体验：2-5-10原则，页面响应时间

□ 商业需求：竞品分析（对手产品的处理能力、等待时间、响应速度、容量）

□ 技术需求：技术指标一般都差别不大，服务器CPU不能超过80%，IO不能超过100，网络吞吐不超过网卡带宽

□ 标准：国家或行业标准中的性能指标

常见量化性能指标

时间：一般是用户的关注

○ 页面下载时间

○ 处理时间

○ 发送时间

○ 连接时间

○ 系统/事务的响应时间

容量/数据吞吐量：产品关注点

○  最大用户数

○  最佳用户数

○  页面浏览量

○  吞吐率：每秒服务器处理的HTTP请求

○  每秒点击率

○ 每秒连接数

系统资源占用率：开发关注点

○ CPU

○ 内存

○ IO

○ 网口

【性能需求分析】业务要求支持2亿用户，每天支持2000万次交易量，交易响应时间要求在1s之内

• 2亿用户：说明数据库中要有2亿的用户，按1%（需根据实际情况而定）用户会在线，意味着2亿用户需要有200万用户同时在线

• 每天2000万次交易：按交易时间18h计算（早上8点-凌晨2点），平均每秒309次

• 若高峰期间处理能力要求是平均值的3倍，则最大吞吐量要到927次/秒

• 交易响应时间不超过1s，峰值不超过3s

• 正常交易成功率100%，峰值不低于99.9%

• 服务器cpu不能持续超过70%，内存不能持续超过XXXG(需根据实际配置确定)，IO为xxx，网络带宽不超过100M/S

从上述分析中有一些潜在的经验值（监控指标），有些是需要对实际业务进行摸底（1%用户在线，高峰是平均值的3倍）

后续性能测试的大体流程：

第一步：摸底测试

在没有量化指标的情况下，第一个版本的性能测试主要是摸底，

一般会拍脑瓜定个并发数，场景设置成系统主要的功能监控收集该状态下，系统的各种指标：

• 哪个服务和组件占用资源（CPU、内存、吞吐量）过多

• 哪个环节（页面、操作、接口）费时多

• 算法消耗资源

• 有没有内存泄漏

• 加大压力，看系统是否会崩溃

第二步：把第一次的测试结果展现给开发，让开发对这些关键的指标有认识，并共同分析产生这些结果的原因并指定要达到的量化指标。

第三步：一般开发会提出优化方案（可能是更换组件），达到量化目标后，做长时间的压力测试