如果你有梦想，就要守护它。
电影《当幸福来敲门》
一、SEI负载测试计划过程
SEI 负载测试计划过程将目标、用户、用例、生产环境、测试环境和测试场景6个区域作为负载测试计划需要重点关注和考虑的内容，重点关注以下几个方面的内容：
1. 生产环境和测试环境的不同
由于负载测试环境与实际的生产环境存在一定的差异，测试环境上对应用系统进行的负载测试结果很可能不能准确反映该系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。
2. 用户分析
通过对用户行为进行分析，依据用户行为模型建立用例和场景。
3. 用例
用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。
SEI 负载测试计划过程对负载测试需要关注的具体内容上提供了参考 ，但并不是一个完整的测试过程。
二、RBI方法
RBI方法是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法，该方法基于以下一些事务：
1. 80%的系统性能瓶颈由吞吐量制约。
2. 并发用户数和吞吐量瓶颈之间存在关联。
3. 采用吞吐量测试能够更快速的定位问题。
RBI方法先访问“小页面”和“简单应用”，从应用服务器、网络等基础层次上去了解系统吞吐量表现；再选择不同场景、设定不同并发数，使吞吐量保持趋势增长，观察系统的性能表现。按照“自上而下”的方式进行分析，首先确定是并发还是吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器、代码本身4个环境确定系统性能具体的瓶颈。
RBI方法在性能瓶颈定位过程中能发挥良好的作用，对性能分析和瓶颈定位值得借鉴，但也不是完整的性能测试过程。
三、性能下降曲线分析法
性能可以是响应时间，也可以是吞吐量或单击数/秒的数据，一般来说，主要指响应时间。
一条响应时间性能下降曲线包括以下几个区域：
1. 单用户区域： 一个单用户的响应时间，对建立性能的参考值很有帮助。
2. 性能平坦区：系统性能最优秀的区间。
3. 压力区域：系统性能开始变坏的区间。
4. 拐点： 性能开始急剧下降的点。
该方法通过识别不同的区间和拐点为性能瓶颈识别和调优提供依据。
四、LoadRunner的性能测试过程
1. 计划测试: 测试需求收集、典型场景确定。
2. 测试设计: 测试用例设计。
3.创建VU脚本: 根据用例创建脚本。
4. 创建测试场景: 测试场景设计和设置，包括监控指标设定。
5. 运行测试场景: 执行测试场景，收集相应数据。
6. 分析结果: 结果分析和报告工作。
该方法依赖工具本身，被称为是“使用LoadRunner进行测试的过程”，不是一个适应性广泛的性能测试过程。
五、Segue提供的性能测试过程
1. 通过单用户对系统的访问获取性能取值的基线。
2. 设定可接受的性能目标。
3. 用不同的并发用户数重复进行测试。
该方法非常适合性能调优和优化, 通过不断重复的try-check过程，逐一找到可能导致性能瓶颈的地方并进行优化，与LoadRunner的性能测试过程一样，过于依赖工具本身。
六、敏捷性能测试
在敏捷开发中开展性能测试的难点：
1. 周期短，没有足够的时间和人力资源。
2. 需求变化频繁，性能测试缺乏持续不变的可以依赖的基准。
为了让性能测试适应敏捷开发，不少组织和个人提出了面向敏捷开发的性能测试方法，这些方法不是完全面向过程的组织方法，而是技巧、组织与建议的混合。
1. 每个迭代目标中包含明确的性能目标
迭代目标中的性能目标可以是基于端到端，也可以是基于接口，甚至是面向具体的函数，例如以下性能描述：
a. 在吞吐量为40QPS的情况下，X页面的服务响应时间小于5秒。
b. 模块B能够每秒处理来自模块A的1000个请求。
c. Employee类从服务器获取给定Employee信息的方法耗时不超过100ms。
2. 建立不同层次的性能测试
a. 面向函数的性能测试： 可以通过JUnit4或TestNG中的@Test来设置验证标准。
b. 接口级别的性能测试：需要将模块或子系统运行起来，并设置好测试的支撑环境，因此，需要设置一些环境支持脚本， Junit4也能够支持接口级别的性能测试。
c. 端到端的性能测试：准备好一键部署的脚本，通过一个命令就能够将被测应用部署到指定的环境上，然后使用合适的工具和脚本对其进行测试。
3. 完全或接近完全自动化的性能测试
因为要达成敏捷与快速，敏捷测试极大的依赖于自动化。
市面上有一些商业或开源的性能测试工具，如LoadRunner和Jmeter、JUnit等，能够建立相应的性能测试脚本执行特定的性能测试需求，
但不能直接帮助性能测试需要的环境，不能基于某个基线进行结果的比较，要实现高度自动化还需要其他自动化工具的支持。
4. 使用测试驱动方法保证性能与优化性能
如果有明确的性能标准，该标准同样可以被包含在TDD测试中，并作为函数实现与否的一个判定标准。
例如使用JUnit4的@Test(Timeout=xxx)或是其他同类工具中的类似功能均能达成这个目标。
除了在函数级的性能测试中建立标准外，在更高层面设置持续的性能验证标准也是一个可用的实践。
“不低于上一个版本的性能表现”可以作为一个基本通用的标准。
七、PTGM和APTM
PTGM(Performance Testing General Model): 非敏捷过程中的性能测试模型，分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行与管理和测试分析6个步骤，包括了测试团队组建到测试分析的全部过程，每个活动都有详细的活动指引和参考模板。
APTM(Agile Performance Testing Model): 敏捷过程中的性能测试模型，结合敏捷开发的特点，由检查表、活动和建议工具3部分组成，可以很容易的适应不同的敏捷开发模型。
摘自段念《软件性能测试过程详解与案例剖析》