性能测试最开始的需求分析工作细致与否，与后面的性能测试结果息息相关。需求分析是一个繁杂的过程，它并非我们想象的那么简单。做需求分析除了要对系统的业务非常了解，还需要有深厚的性能测试知识，这样才能够挖掘分析出真正的性能测试需求。

很多时候，性能测试的需求是比较模糊的，需要性能测试工程师去挖掘和分析。在工作中，作者经常被问到的一个问题是: 应该设置多少个JMeter线程去压测? 还有不懂技术的客户提出想要做性能测试，但是没有提供指标，只说系统支持100万用户。这些都是我们日常工作中司空见惯的泛泛的需求

此时，我们可以通过“3步法”对产品进行正确的需求分析和用户模型建立。

一、剖析被测系统

(1) 了解系统架构。首先我们需要与开发人员沟通，了解清楚系统的部署架构采用了哪些中间件、数据库、容器、缓存等，以及它们之间的架构关系，并画出对应的网络拓扑图和系统部署架构图

(2) 了解业务模型。首先我们需要采用用户行为分析，分析用户使用产品的习惯，确定系统的典型业务及发生时间。很多大型系统的业务使用都有流量高峰。这类系统业务使用的流量高峰可能出现在天、一月、一年中的某个时间点上或时间段内。对于新浪、网易等门户网站，在周一到周五的早上刚上班时，可能使用邮件系统的用户比较多，而在中午休息时间浏览热点新闻的用户较多;对于一般的OA系统，早上阅读公告的用户较多，在其他时间可能没有用户使用系统或者仅有少量的用户，比如秘书或领导使用系统起草和审批公文;对于电信缴费系统，在月末很可能会出现用户集中使用缴费业务的情况。

然后是调研历史统计数据，通过分析数据确定热点模块。如果产品已上线，可以统计和分析线上历史数据。对于web类产品，我们可以获取和分析独立用户数、页面访问量和最大在线用户数;对于后台类产品，则可以分析如Nginx的Access log，从而得出最大的访问量对于数据库类产品，我们还可以分析出热点SQL等。如果产品未上线有同类产品参考，可以参考公司内同类产品或者同行的同类产品进行热点模块预估，虽然不能完全照搬，但可以根据业务增长数据进行统计分析，输出用户访问热点轨迹图。

二、选取性能测试点

选取性能测试点是性能测试需求分析中非常重要的一个环节。面对一个功能繁杂的系统，要设计出有效的测试场景，最大程度上覆盖系统的性能问题和瓶颈，需要较多的经验积累。目前我们可以按照以下原则来进行性能测试点的选取:

(1)核心业务模块，例如支付业务、核心算法;

(2)并发量较高的业务模块;

(3) 逻辑较复杂的业务模块

(4) 有复杂数据库操作或事务的模块;

(5) 有较频繁的磁盘读写操作的模块

然后根据不同类型的系统应用，选取的原则也可以进一步细分。

对于Web应用，其性能测试点的选取原则为:

(1)依据业务数据统计中几种典型业务的用户使用数比例:

(2) 调用频繁、占用空间大的数据库表的交易，

(3) 占用最大存储空间或其他资源的交易;

(4) 对磁盘、常驻内存的数据过度访问的交易

对于后台类应用，其性能测试点的选取原则为:

(1) 读 (查询)、写 (增删改) 、读写 (增删改查) 合的业务模块;

(2)配置服务器的业务模块；

(3)功能的实现方式，如同步和异步，轮询和notify等:

(4) 分布式业务模块，如单客户端和多客户端，单节点和多节点；

(5) 数据规模，如数据库已存在大量记录，存储可用空间少:

(6)缓存，如对文件系统缓存和数据库缓存的利用等;

(7)负载均衡，如多节点情况下是否负载均衡。

对于分布式数据库，其性能测试点的选取原则为:

(1) 数据库读写混合业务模块;

(2) 数据库之间数据同步

(3) SQL语句;

(4) 数据规模4

比外，当系统应用包含长连接消息服务时，其性能测试点的选取原则为:

(1)单机能支撑的最大并发长连接数;

(2)并发一定数量的用户时的消息推送情况，包括消息到达时间、消息丢失率等

三、量化测试目标

梳理出来性能测试场景后，就需要进一步明确各个场景的测试指标，而大部分的产品经理给出的指标是不完整的，通常情况下可以结合采集的数据和二八定律进行具体量化，让性能测试指标更明确。

下面举个例子来说明性能测试指标量化方法。

例如，某互联应用，预计推广群体达500万人，用户使用应用的时间是每天早上8点至晚上8点，共12h。

分析建模过程如下:

（1）注册用户转化率预估为5%，那么注册用户数为5000000x5%=250000

（2）高峰时段 (比如有活动时) 每日在线用户活跃率预估为10%，那么活跃用户数为250000x 10%=25000

（3）用户常用下单到成功触发20个请求，总请求量为25000x20=500000

（4）利用二八定律计算，得出的吞吐量为500000x0.8/(12x3600x0.2)=46.7个每秒

若是更新需求，如发布新产品，定时抢购优惠活动 (某日10点开始抢购，12点结束，共2h)。

重新建模如下:

（1）注册用户数为25万不变

（2）高峰时段在线用户在线率预估为20%，那么这2h的在线用户数为250000x20%=50000

（3）用户常用下单到成功触发20个请求，总请求量为50000x20=1000000

（4）利用二八定律计算，得出的吞吐量为1000000x0.8/(2x3600x0.2)=555.6个每秒

由此可见，评估出来的TPS值和需求业务模型息息相关。

在性能测试的前期，通过上述“3步法”整理分析的详尽程度将直接决定后续性能测试的有效性和准确性。

注意

在评定服务器的性能时，应该结合TPS和并发用户数，以TPS为主‘并发用户数为辅来衡量系统的性能。如果必须要并发用户数来衡量的话，则需要一个前提，那就是交易在多长时间内完成，因此只用并发用户数来衡量系统的性能没太大的意义。

提示

• 响应时间：根据国外的资料，一般操作的响应时间为2秒、5秒和8秒，即2秒内为优秀、5秒内为良好、8秒内为可接受；对于其它一些特殊的操作，如上传、下载，可以依据用户体验的情况延长响应时间。
• 二八定律：又称帕累托效应，例如，一些系统一天中80%的访问量集中在20%的时间内。