【无规矩不成方圆】
没有合适的方法论指导，性能测试很容易成为一种随意的测试行为，而随意进行的性能测试难取得实际的作用和预期的效果
【SEI负载测试】
目标：产生清晰、易理解、可验证的负载测试计划
6个关注的区域：
- 目标
- 用户
- 用例
- 生产环境
- 测试环境
- 测试场景
1.生产环境和测试环境不同
测试环境的应用系统进行的负载测试结果很可能不能准确反映应用系统在生产环境上的实际性能环境，为了规避这个风险，必须仔细设计测试环境
2.用户分析
必须通过对用户行为进行分析，依据用户行为模型建立用例和场景
3.用例
用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用分析和分解出关键的业务网，判断每个业务发生的频道、业务出现性能问题的风险
RBI方法
RBI（Rapid Bottleneck Identify ）方法是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法。该方法基于以下一些事实：
- 发现的80%系统的性能瓶颈都是由吞吐量制约
- 并发用户数和吞吐量瓶颈之间存在一定的关联
- 采用吞吐量测试可以更快速地定位问题
【自上而下的分析，-并发，-吞吐量，-网络、数据库、应用服务器，-代码】
先访问‘小页面’和‘简单应用’，从应用服务器，网络等基础的层次了解系统吞吐量表现；
再选择不同的场景，设定不同的并发用户数，使其吞吐量保持一致的增长趋势；
通过不断增加并发用户数和吞吐量，观察系统的性能表现。
性能下降曲线分析法
描述的是性能随用户数增加而出现下降趋势的曲线
性能：响应时间，吞吐量，单击数/秒
分部分描述：
【单个用户触发业务】
对系统的一个单用户的响应时间。
对简历性能的参考值很有帮助
【性能平坦区】
在不进行更多性能调优情况下，所期望达到最佳性能
该区域作为的是基线或者是benchmark
【并发区域】
应用轻微下降的区域
典型的、最大的建议用户负载时压力区域的开始
【拐点】
性能开始急剧下降的点
性能测试过程（不一定普适性）
计划测试
测试设计
创建VU脚本
创建测试场景
运行测试场景
分析结果
计划测试
测试需求的收集
典型场景的确定
测试设计
测试用例的设计
创建VU脚本
根据用例设创建脚本
创建测试场景
进行测试场景的设计和设置，包括监控指标的设定
运行测试场景
对已创建的测试场景进行执行，收集相应数据
分析结果
进行结果的分析和报告工作
基于基线测试
通过单个用户对应访问获取性能基线，
然后设定可接受的性能目标（响应时间），
用不同的并发用户数等重复进行测试
适合调优和优化，不断重复捕获性能瓶颈的地方，进行优化
但是依赖工具自身，缺乏对计划、设计阶段的明确划分，没有具体的活动和目标
敏捷性能测试
目标不一：（不同层次）
端到端的性能：
吞吐量为40QPS，X页面的服务端响应时间少于5秒；
对复杂环境的支持依赖大，一般是一键部署脚本，指定环境
接口的性能：
模块B能够每秒处理来自模块A的1000个请求；
需要多环境的支持，设置脚本环境，例如Junit
面向具体函数的性能：
某个类从服务器端获取的信息方法耗时不超过100毫秒
对环境的依赖级别小，单元测试一般，容易持续集成
性能测试的自动化
- 测试工具与脚本
- 设置环境的脚本
部署工具的支持
