转自于部门组内
需求调研
1、需求沟通
2、业务学习
3、技术、架构、数据特点了解
（1）系统架构：物理架构（硬件及部署策略）和逻辑架构（系统的功能与服务），包括中间件产品与配置、数据库配置等，供我们搭建测试环境时进行参考。
（2）业务流程：业务量和业务分布。采集业务（分析出哪些业务纳入性能测试范围）并量化业务、业务扩展趋势（年增长率或者未来的业务量）、业务发生时段（业务高峰的发生时间和高峰业务量）、业务分布（各项业务之间的比例）。
（3）用户信息：在线用户数、活动用户数、业务分布。有些系统用户量特别大，会对系统造成性能瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。
（4）系统是否与第三方系统有关，是否需要做挡板（Mock程序）。
（5）系统是否有归档机制：如果数据库有归档机制，可以把一些无用或者过时的信息移到归档库，这样就减少当前数据库的数据，有利于提高系统性能。
（6）性能指标：吞吐率、响应时间、事务成功率，CPU、内存、磁盘、带宽使用阀值。
需求分析
确定此功能的可测性、可验证性：功能是否可验证（是否牵连到第三方程序，是否需要做挡板Mock程序）。
明确性能指标
业务性能指标
1. 吞吐量（PV）、吞吐率（TPS等）
2. 响应时间（RT）/ 应用响应时间（ART）：3秒以内
3. 事务成功率：99%以上
4. 稳定波动正常范围
硬件性能指标及阀值
CPU、内存、磁盘、网络带宽等。具体数据来源于非功能需求、组织要求（公司运维总结出来的可行性指标）或者行业标准建议。
分析业务量
测试数据的多少对测试结果会有影响。特别是数据成千万上亿条之后，性能影响明显，所以需要做足一定数量的历史数据。除此之外，还得关注业务的增长。如果系统需要满足未来三年的业务增长需求，那么在测试时就需要生成三年的存量业务数据。对于关系型数据库来说，数据最大时对性能的影响还是比较明显的。
估算TPS与并发数
一般我们会从运维那里得到整个系统在一天内按小时进行统计的PV趋势图。根据访问高峰业务量，估算出TPS与并发用户数等性能测试执行依据。一般采用二八原则，即80%的业务在20%的时间内完成。二八原则计算的结果是吞吐量（即TPS），而并发数 = TPS *（ThinkTime+RunTime）。
分析系统协议
一般性能测试脚本可以通过录制或者手动开发，而录制方式对协议的依赖性相当强。一般我们先分析系统协议（向开发团队咨询，或者截包分析），再评估用什么工具完成。HTTP可以用JMeter或者LoadRunner，Java接口可以用JMeter的JavaRequest元件与JUnit元件测试。
测试计划
根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；测试系统能否满足实际运行时的需要，目前的系统在哪些方面制约系统性能的表现或者哪些系统因素会导致
和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使用率等目标；
预设本次性能测试各子模块的起止时间，产出，参与人员等等。测试准备
测试环境准备：
包括服务器和负载机。找出这些：
- 请求顺序、请求之间相互调用关系。
- 数据流向，数据是怎么走的，经过哪些组件、服务器等。
- 预测可能存在性能瓶颈的环节（组件、服务器等）。
- 明确特点：磁盘 I/O密集型，CPU I/O密集，内存消耗型->弄清楚重点监控对象。
- 关注应用是否采用多进程、多线程架构->多线程容易造成线程死锁、数据库死锁，数据不一致等。
- 是否使用集群/是否使用负载均衡。
生产环境和测试环境的硬件架构和配置需要进行估算，否则结果会有很大的偏差。了解测试环境部署和生产环境部署差异，是否按1:1的比例部署。通常建议测试时先不考虑集群，采用单机测试，测试通过后再考虑使用集群，这样有个比较，比较能说明问题。
性能测试脚本开发：
录制脚本或手动开发，添加固定计时器模拟ThinkTime，增加同步定时器模拟集合点，增加IF条件控制器判断逻辑，添加后置处理器获取参数。脚本注意做断言，验证事务是否成功。
开发挡板程序，开发测试工具等。事务定义
合理的定义事务，能够方便分析耗时（特别是混合业务功能场景测试），进而方便分析瓶颈。比如，购买商品，我们可以把下订单定义为一个事务，把支付也定义为一个事务。
测试数据准备：
1、根据测试对象的特点和测试目的，准备相应的测试数据
测试执行
（1）检查网络环境
确保环境独立，不会对生产系统、外部系统等的使用造成影响。
确保环境可靠，不会因为生产系统、外部系统而影响测试结果。
为了方便分析问题，排除网络IO的影响，测试在局域网中进行。
（2）检查测试数据
确保基础数据完整，能够支持性能测试脚本对业务功能的覆盖。
确保基础数据量，能够支持性能测试脚本的参数化要求。
确保存量数据量，能够尽量真实反映系统数据环境。
确保存量数据分布，能够对结果施加有意义的影响。
（3）检查监控设备
监控工具是否已经准备完毕可用。
（4）脚本检查
确认脚本能够模拟业务场景。
确认脚本无性能风险不影响测试结果。
（5）性能测试执行
在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。
（6）测试结果记录
根据测试采用的工具不同，结果的记录也有不同的形式；
1、性能测试工具都提供比较完整的界面图形化的测试结果
2、服务器的资源使用等情况，利用一些计数器或第三方监控工具来对其进行记录
3、执行完测试后，对结果进行整理分析。
结果分析
测试环境分析：
根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。
硬件设备对系统性能表现的影响分析：
根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。
其他影响因素分析：
影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析；
至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析
测试报告
需求决定了测试报告需要包含以下内容。
性能测试背景：测试原因，性能测试开展的必要性。
性能测试目标：对系统进行定容定量、响应时间、配置、稳定性等测试，风险评估。
性能测试范围：参考测试计划中的测试范围。
名词术语： 涉及专业名词的解释，参考测试计划。
测试环境：报告结果基于的测试环境，不同的环境结果可能大相径庭。
测试数据：报告测试数据量，参考测试计划。
测试进度：报告测试过程，什么时候做什么工作，比如哪一天执行了哪些测试脚本。
测试结果：基准测试、配置测试、负载测试、稳定性测试等，全面多方位的报告测试结果，TPS、ART、事务成功率、硬件资源使用率（CPU、内存、网络、IO等）。
测试结论：分析给出测试结论，系统能否满足性能要求？存在什么问题？有哪些缺陷？解决了哪些问题？还有哪些问题没有解决？列出仍没有解决的系统缺陷。
系统风险：报告系统可能存在的风险，帮助决策层应对风险。
优化建议：对本次结果分析后，给出合理的优化建议
测试报告要非专业人士也能看懂，尽量做好指标对比、用图表表达性能变化趋势。评审
组织相关人员一起对测试报告进行综合评审，对大家不明白或有疑问的地方进行讲解，参与人员包括：需求提出方、开发、测试、运维等