在实际的工作中系统的性能需求通常是一个笼统的需求，而且有可能给提需求的人并不知道具体的性能需要，所以只能含糊的列出。如果测试人员不搞清楚，就会出现实际要把杀猪刀，需求标明能屠龙！！！

下面，还是举一个讲个我真实经历过的故事来做实例分析。

故事开始：

需求方是一个研究机构（甲方），它旗下本身也有一个软件技术部（但不承担开发测试任务），但是这个项目是外包方（乙方）来做的，我们公司当时是中间的监理机构（第三方），主要监理整个项目系统的性能质量以及整个工程（包括开发、测试以及系统运行）的质量，对我来讲任务只是考察系统的性能，系统讲的是一个图书检索系统，包含主要功能:图书上传，图书分类，目录索引，图书搜索，图书下载以及图书的全文检索功能。

我也参加了他们项目组组织的一次“性能需求”会议，当时的合同我们监理拿给我看了一下，实际在合同上并没有规定具体的性能指标，只有一句话：系统需要满足甲方5年内的业务需求。

系统甲方在会议上张口提出了需求：并发用户要到5000，业务响应时间要控制在3秒内；乙方开发组长是个年轻的小伙子，对这个性能完全没有概念，就问我们监理这个是否合理，监理把这个问题抛给了我，我用笔在纸上做了提纲，然后对甲方和乙方提出了问题。

(1) 请问甲方，当前的业务量或者访问量是每天多少？答：10000左右，有时候15000访问用户

--我扭头想骂人，这不是欺负人吗？

(2) 请问甲方5000的TPS从哪儿来的？答：10000的用户并发1000，估计5年内业务能上升到5倍，所以是5000

--我低头对监理说：这个5000太不合理了，是不想让上线啊。

--监理：给出合理解释，给个合理的范围。你直接说。

--好吧，每天的业务峰值才只有15000，咱们就按10倍来计算，150000，每天8个小时正常工作时间，按照只有20%的时间用户会集中，就算20%的时间所有用户都集中在这，那么TPS计算一下150000/(0.2860*60) 大约是26，还不到30的TPS，怎么会出现5000并发呢；当然30对一个系统来说可能是有点小，咱们来平衡一下。

最后在各方的努力下做出如下的改变：

当前峰值访问15000，5年内，假设业务发展增加100倍，最后定到并发访问用户和TPS在300，响应时间根据业务而定，全文检索在3分钟内，下载，上传业务不做限制，图书索引和图书索引搜索（模糊搜索）在5秒内。

故事结束。

这个例子，其实没有其他意思，只是想说，很多时候需求可能是“拍脑袋”想出来的，没有数据支撑，这个时候我们需要的是需要多次的沟通，需要达到项目组多方的一致认可（理由和数据充分，才可行）（作为监理需要既不偏袒甲方也不包庇乙方，一个项目组的共同目的就是项目保质保量、完美的上线运行）。

这个例子也是一个没有既定具体需求的案例，需要我们了解业务功能，并应用常用的规则来进行推导一些可能的需求。

这个业务里面，全文检索业务响应时间是一个比较难定义的点，需要在图书库里面（注意图书不是录入数据库的，都是PDF文件要在各个文件里面）进行检索，虽然文件进行了科目的分类检索，但是每一个科目图书还是很多的，全文检索那速度可能就更是问题了，这个问题为了给用户更好的体验，在前端进行了处理，有一个类似于进度条的展示，展示当前的所有进度，并且逐渐展示已经检索到的部分内容，提供用户的体验度。这个并没有使用任何的后台技术进行调优，因为这个代价可能非常大，只是在设计上进行了优化，而这个需求的最终确定也是测试和整个项目组一起讨论后确定下来的。

这里要说的，并不是一个具体可以拿来照搬的（需求分析）方法，只是想强调一点：分析和了解需求很重要，并且你分析得到的需求与整个项目组的沟通和确认至关重要，它关系到你后面所做的所有事情是否有效。

接下来，我们总结一下需求分析的方法：

(1) 具体有文档的和需求的，先分析文档需求，找出疑问和项目组进行确认，最好自己整理一个系统结构和业务流程图在项目组进行讲解确认，达成一致观点。

(2) 没有文档需求的，需要和整个项目组进行沟通交流，先大致了解，然后逐渐细化分析系统的各个业务流，最终形成系统结构和业务流程图在项目组进行讲解确认，达成一致观点。

(3) 一些细节的性能需求，项目组不能提供时，需要结合一些原理进行分析拿出具体数据和项目组进行确认，达成一致观点。

可以看到，最后都是落实到和项目组确认，你确认的时候，从这几个方面入手：

(1) 对给出的每一个需求点，给出需求是怎么来的？要有数据说明。

(2) 对给出的每一个需求点，给出这个值合理性？做好数据和原理说明。

(3) 最后询问一下项目组是否有遗漏？一个人的力量始终是没有一组人的力量大。整个项目组一起思考也许就能够补充一个人所想不到的一些放面。

(4) 当项目组提不出问题的时候，要主动提出一些问题，比如是否需要稳定性测试，是否需要考察可靠性，咱们是否需要做这些等等。

这个方法其实应该是所有的项目都能够采用，可能有些项目时间上比较紧张的时候，不允许我们有时间进行全面的分析，这就是测试中的最大风险所在。

那我们该如何学习性能测试呢？

性能测试的目的是发现系统处理能力的瓶颈而系统调优才是最终的目的，如果能进一步提高各业务服务器、数据库服务器的调优技能，对性能测试工作来说是如虎添翼。

性能测试针对

1、系统的性能指标

2、建立性能测试模型

3、制定性能测试方案

4、制定监控策略

5、在场景条件之下执行性能场景

6、分析判断性能瓶颈并调优

7、最终得出性能结果来

8、评估系统的性能指标是否满足既定值

有人说，我们在做项目的时候，就没有指标，老板只说一句，系统压死为止。听起来很儿戏，但这样的场景不在少数。在我看来，把系统压死也算是一种指标。至于你用什么手段把系统“压死”，那就是实现的问题了

一、准备工作

1、系统基础功能验证 性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。

2、测试团队组建 根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发和执行人员；在正式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。

3、工具的选择 综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具。

最起码应该满足一下几点：

①支持对web（这里以web系统为例）系统的性能测试，支持http和https协议；

②工具运行在Windows平台上；

③支持对webserver、前端、数据库的性能计数器进行监控；

4、预先的业务场景分析 为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。

二、测试计划

测试计划阶段最重要的是分析用户场景，确定系统性能目标。 1、性能测试领域分析 根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致系统无法跟上业务发展？

确定测试领域，然后具体问题具体分析。

2、用户场景剖析和业务建模 根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。

3、确定性能目标 前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；

其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使用率等目标；

例如：

①登录请求到登录成功的页面响应时间不能超过2秒；

②报表审核提交的页面响应时间不能超过5秒；

③文件的上传、下载页面响应时间不超过8秒；

④服务器的CPU平均使用率小于70%，内存使用率小于75%；

⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；

4、制定测试计划的实施时间 预设本次性能测试各子模块的起止时间，产出，参与人员等等。

三、测试脚本设计与开发

性能测试中，测试脚本设计与开发占据了很大的时间比重。

1、测试环境设计 本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！

因此在测试环境中，需要部署多个不同的测试环境，在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。 这里所说的配置大概是如下几类： ①数据库服务器 ②应用服务器 ③负载模拟器 ④软件运行环境

平台测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的测试数据来使得测试环境的数据保持一致性等等。

可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。

2、测试场景设计 通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。

3、测试用例设计 确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述。

用例大概内容如下：

用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）

用例条件：用户已登录、具有对应权限等。。。

操作步骤：

①进入对应页面。。。。。。

②查询相关数据。。。。。。

③勾选导出数据。。。。。。

④修改上传数据。。。。。。

PS：这里的操作步骤只是个例子，具体以系统业务场景描述；

4、脚本和辅助工具的开发及使用 按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；

PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；

一句话：能写就绝不录制！！！

四、测试执行与管理

在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。

1、建立测试环境 按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。

2、执行测试脚本 这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。

3、测试结果记录 根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。

五、测试分析

1、测试环境的系统性能分析 根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。

2、硬件设备对系统性能表现的影响分析 由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。

3、其他影响因素分析 影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析； 至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。

4、测试中发现的问题 在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点。

六、总结

只要你有能力去做的事就一定要去做，不要给自己留下任何遗憾，人生最重要的不是所站的位置，而是所朝的方向。

一个没有目标责任制的人就像一艘没有过舵的船，永远漂流不定，只会到达失望失败和丧气的海滩。

生于忧患，死于安乐。如果你想跨越自己目前的成就，就不能画地自限，而是要勇于接受挑战。对畏畏缩缩的人来说，真正的危险正在于不敢冒险！

 正在做测试的朋友可以进来交流，群里给大家整理了大量学习资料和面试题项目简历等等....