大纲：
1.性能测试基本概率
2.信息收集
3.如何制定性能测试计划
4.设定性能指标
5.测试环境和测试数据的建模
6.性能测试执行流程
7.常见的性能测试瓶颈和调优方法
一。性能测试基本概率：
多种正常、峰值以及异常负载对系统各项性能指标进行测试
负载测试--不同负载系统各指标的变化
压力测试--测系统在什么并发下出错
稳定性测试--长期稳定工作能力（7*24h）
二。参与关联人员：
客户（明确需求）
产品经理（核心业务）
运营人员（秒杀活动）
公司领导
项目经理
系统架构师
开发人员
运维工程师
DBA
安全人员
测试经理
测试团队其他成员
三。信息收集
客户需求
运营人员需求
产品人员需求
架构师的系统架构设计
开发人员的详细设计
数据库的数据字典
项目时间的安排（开发、测试、上线）
在系统代码开发完成之后和功能测试完成之前
测试组织派专人采用现场或非现场的方式
技术调研重点内容：1.被测系统的技术实现。2.与其他系统接口关系及其技术实现。3.本系统测试数据。4.与相关系统测试数据的关系
目的：初步确定测试技术方案及相关的测试数据准备方案
四。策略
在性能测试正式启动之前，需要对两个方面进行评审
1.被测系统是否符合准入标准
2.实施性能测试的可行性和必要性
目的：考察被测试系统是否具备性能测试的条件
1.不符合测试条件的系统会导致测试难以实施，或者测试结果严重失真
2.勉强测试会使测试工作失去意义，浪费大量的时间、人力和软硬件资源
（主要功能能跑 ，提测阶段）
五。测试计划
测试目的（清晰明确，没有歧义）
测试范围（交易列表，路径图等）
性能指标（要可测量，量化指标最好给出具体数值，无法定量的给出说明，tps，平均响应时间）
数据量（给出具体数值和参考依据，无法定量的给出说明）
测试环境（分为网络、硬件、软件和拓扑图）
测试工具和监控工具及其相关环境
风险控制（风险描述、严重程度、规避办法、负责人等明确清晰）
测试策略（符合项目实际情况，具有可执行性）
角色分工（无遗漏，职责描述清楚）
时间周期
六。组件测试团队
系统架构师
核心开发人员
运维工程师
DBA（数据库管理人员）
性能测试方案设计人员（可以1人同时承担此角色）
性能测试工具和脚本开发工程师
性能测试执行人员
测试环境维护人员
确认测试项目干系人一起确定本次测试的具体目的：
1.严重改进的性能效果，需要和以前的测试结果进行对比
2.新的业务上线，验证新系统能够满足系统的上线指标（上线指标：压最大、对未来的期望计算预估指标-订单量（8小时3600秒算出并发数）*10=浏览量）*4 并发数的均值的4倍（一般经验之说）大概不会出现问题
3.验证系统稳定性
4.验证系统的架构是否存在瓶颈（压测到极限）
列出性能测试成功的数据指标：
1.吞吐量TPS
2.每个事务平均响应时间
3.确定数据库的数据量（DBA-开发-自动化造数据）
4.系统的稳定运行时间要求（一般7*24h）
5.是否需要考虑系统支持水平扩展（通过加机器能提高性能瓶颈）
6.考虑系统的最大容量
七。环境
分析系统真实运行的网络拓扑环境
明确公司可对性能测试进行投入的软硬件资源
最好的性能测试环境就是待发布的生产环境
次好的性能测试环境就是1:1复制的生产环境
对于软硬件资源不足情况下，同比例缩小系统每一层结构中的机器数量，注意：系统中的每一层必须要有机器（分布式需要最少两台以上）
（即使性能测试环境与生产环境有差异，但是也要进行测试，可以排除大多性能问题）
八。建模
数据库中该有多少测试数据才是合理的呢？
1.需要考虑、中长期系统运营的数据出现的可能性（扩大，指标*2或者1.5）
2.和性能测试干系人讨论，讨论得出数据
3.需要考虑数据库配置文件缓存参数的设置情况
4.明确Cache预load的数据说明
九。流程
规划测试
创建Vuser脚本
创建方案
运行方案
监视方案
分析测试结果（缓存调优、数据库配置或者SQL调优）
十。工具选择
Loadrunner
Jmeter
Siege
Apache Bench
自写工具
十一。项目
原则：用户最经常使用的功能，产生IO操作比较多的功能，系统的核心功能、系统产生密集计算的功能等
1.确定哪些接口要进行性能测试和稳定性测试
2.确定哪些页面业务流程要进行性能测试和稳定性测试
注意：需要验证性能测试功能的可测试性（能事先手工验证）
十二。用例设计
业务流程
使用参数化方式
断言内容
加压策略
监控方法
日志分析方法
十二。用例设计思路
测试执行阶段主要包括以下工作项：
1.基准测试：获得各个典型交易在无压力条件下性能表现
2.单交易负载测试：获得各个典型交易在负载条件下的性能表现
3.混合场景序列负载测试：按照场景序列一次获得各场景负载条件下的性能表现
4. 稳定性测试：通过长时间、较大压力的负载运行，获得被测系统的稳定性表现
十三。问题分析
系统性能的稳定性，响应时间是否波动很大？（方差）
Cpu资源是否耗尽？（一台机器平均cpu占用率不能长期高于70%）
系统是否利用了多核CPU？
系统内存是否被耗尽（free）
Swap内存是否被占用？（free）
IO是否出现大量的排队（Iostat）
系统的错误日志
系统的访问日志（请求处理时间）
Java虚拟机的垃圾回收情况以及虚拟机内部的占用内存情况
十四。成功标准
如何界定性能测试的结果满足预定的目标，一般如下几个标准：
1.新上线的测试系统没有明确的数字标准化比对情况下，被测试系统预计被测试到了系统极限（系统的某些资源以及耗尽，cpu，句柄，内存，数据库出现大量的slow query，系统有些处理已经变慢），并且系统证明是可以水平扩展的，则可以上线
2.有以往测试结果对比，只要证明类似的测试条件下，此次的结果比以往的测试结果更好即可（每秒处理个数更多，单次请求的处理速度更快）
3.没有可以比较的测试结果，但是产品已经上线一段时间（至少3个月），有一些运营数据，则需要分析运营的数据来作为比对的基准，只要被测系统达到3个月内系统并发峰值的4倍就可以认为是可以接受的。（如果是接口为测试对象，则需要混合主要的接口来进行性能测试）
4.开发人员提供经验值作为比对的基准，则被测对象只要证明满足开发人员提出的经验值即可。
十五。常见瓶颈
业务逻辑优化：减少秒杀这类业务的出现，均摊在不同时间执行
优先系统架构：
1.动、静分离
2.高效缓存
3.CDN
4.分布式计算：负载均衡、多台应用、多台DB（主从同步）、多台缓存
程序优化：找到程序中最耗时的部分，进行算法优化、缓存优化、根据业务情况将同步请求尽量转变异步请求
中间件优化：参数优化：连接数、缓存、内存大小等
数据库优化：建立和优化索引、优化数据存储，减少表空间占用，减少重复数据存储、减少数据库的函数，存储过程和触发器的所有内部计算功能、优化连接数
JVM的虚拟机参数优化
系统参数优化
提升硬件系统