性能测试最开始的需求分析工作细致与否，与后面的性能测试结果息息相关。需求分析是一个繁杂的过程，它并非我们想象的那么简单。做需求分析除了要对系统的业务非常了解，还需要有深厚的性能测试知识，这样才能够挖掘分析出真正的性能测试需求。
很多时候，性能测试的需求是比较模糊的，需要性能测试工程师去挖掘和分析。在工作中，作者经常被问到的一个问题是:应该设置多少个JMeter线程去压测？还有不懂技术的客户提出想要做性能测试,但是没有提供指标，只说系统支持100万用户。这些都是我们日常工作中司空见惯的泛泛的需求。
此时，我们可以通过“3步法”对产品进行正确的需求分析和用户业务模型建立。
1.剖析被测系统
（1）了解系统架构。首先我们需要与开发人员沟通，了解清楚系统的部署架构釆用了哪些中间件、数据库、容器、缓存等，以及它们之间的架构关系，并画出对应的网络拓扑图和系统部署架构图。
（2）了解业务模型。首先我们需要采用用户行为分析，分析用户使用产品的习惯，确定系统的典型业务及发生时间。很多大型系统的业务使用都有流量高峰。这类系统业务使用的流量高峰可能出现在一天、一月、一年中的某个时间点上或时间段内。对于新浪、网易等门户网站，在周一到周五的早上刚上班时，可能使用邮件系统的用户比较多，而在中午休息时间浏览热点新闻的用户较多；对于一般的OA系统，早上阅读公告的用户较多，在其他时间可能没有用户使用系统或者仅有少量的用户，比如秘书或领导使用系统起草和审批公文；对于电信缴费系统，在月末很可能会出现用户集中使用交费业务的情况。
然后是调研历史统计数据，通过分析数据确定热点模块。如果产品已上线，可以统计和分析线上历史数据。对于Web类产品，我们可以获取和分析独立用户数、页面访问量和最大在线用户数；对于后台类产品，则可以分析如Nginx的Accesslog,从而得出最大的访问量；对于数据库类产品，我们还可以分析出热点SQL等。如果产品未上线，有同类产品参考，可以参考公司内同类产品或者同行的同类产品进行热点模块预估，虽然不能完全照搬，但可以根据业务增长数据进行统计分析，输出用户访问热点轨迹图。
2.选取性能测试点
选取性能测试点是性能测试需求分析中非常重要的一个环节。面对一个功能繁杂的系统，要设计出有效的测试场景，最大程度上覆盖系统的性能问题和瓶颈，需要较多的经验积累。目前我们可以按照以下原则来进行性能测试点的选取：
(1)核心业务模块，例如支付业务、核心算法；
(2)并发量较高的业务模块；
(3)逻辑较复杂的业务模块；
(4)有复杂数据库操作或事务的模块；
(5)有较频繁的磁盘读写操作的模块。
然后根据不同类型的系统应用，选取的原则也可以进一步细分。
对于Web应用，其性能测试点的选取原则为：
(1)依据业务数据统计中几种典型业务的用户使用数比例；
(2)调用频繁、占用空间大的数据库表的交易；
(3)占用最大存储空间或其他资源的交易；
(4)对磁盘、常驻内存的数据过度访问的交易。
对于后台类应用，其性能测试点的选取原则为：
(1)读(査询)、写(增删改)、读写(增删改查)混合的业务模块；
(2)配置服务器的业务模块；
(3)功能的实现方式，如同步和异步，轮询和notify等；
(4)分布式业务模块，如单客户端和多客户端，单节点和多节点；
(5)数据规模，如数据库已存在大量记录，存储可用空间少；
(6)缓存，如对文件系统缓存和数据库缓存的利用等；
(7)负载均衡，如多节点情况下是否负载均衡。
对于分布式数据库，其性能测试点的选取原则为：
(1)数据库读写混合业务模块；
(2)数据库之间数据同步；
(3)SQL语句；
(4)数据规模。
此外，当系统应用包含长连接消息服务时，其性能测试点的选取原则为：
(1)单机能支撑的最大并发长连接数；
(2)并发一定数量的用户时的消息推送情况，包括消息到达时间、消息丢失率等。
3.量化测试目标
梳理出来性能测试场景后，就需要进一步明确各个场景的测试指标，而大部分的产品经理给出的指标都是不完整的，通常情况下可以结合上面釆集的数据和二八定律进行具体量化，让性能测试指标更明确。
下面举个例子说明性能测试指标量化方法。
例如，某互联应用，预计推广群体达500万人，用户使用应用的时间是每天早上8点至晚上8点，共12h。
分析建模过程如下：
(1)注册用户转化率预估为5%,那么注册用户数为5000000x5%=250000；
(2)高峰时段(比如有活动时)每日在线用户活跃率预估为10%,那么活跃用户数为250000X10%=25000；
(3)用户常用下单到成功触发20个请求，总请求量为25000x20=500000；
(4)利用二八定律计算，得出的吞吐量为500000x0.8/(12x3600x0.2)=46.7个每秒。
若是更新需求，如发布新产品，定时抢购优惠活动(某日10点开始抢购，12点结束)。
重新建模如下：
(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%的时间内。
