一： SEI负载
测试计划过程
SEI 负载测试计划过程（SEI Load Testing Planning Process）是一个关注于负载测试计划的方法，其目标是产生“清晰、易理解、可验证的负载测试计划”。SEI 负载测试计划过程包括6 个关注的区域（Area）：目标、用户、用例、生产环境、测试环境和测试场景。
SEI 负载测试计划过程将以上述6 个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容：
1．生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。
2．用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。
3．用例：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。
从SEI 负载测试计划过程的描述中可以看到，SEI 负载测试计划过程给出了负载测试需要关注的重点区域，但严格来说，其并不能被称为具体的方法论，因为其仅仅给出了对测试计划过程的一些关注内容，而没有能够形成实际的可操作的过程。同功能测试一样，性能测试也必须经历测试需求、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特殊性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程。
SEI 负载测试计划过程在负载测试需要关注的具体内容上提供了参考，但其并不是一个完整的测试过程。
二： RBI（Rapid Bottleneck Identify）方法： 用于快速识别系统性能瓶颈的方法。 该方法基于以下一些事实：
1. 发现的80%系统的性能瓶颈都由吞吐量制约；
2. 并发用户数和吞吐量瓶颈之间存在一定的关联；
3. 采用吞吐量测试可以更快速定位问题。
RBI 方法首先访问服务器 style="COLOR: #000000" href="http://server.it168.com/" target=_blank>服务器上的“小页面”和“简单应用”，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。
在确定具体的性能瓶颈时，RBI 将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4 个环节确定系统性能具体的瓶颈。
RBI 方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。
三： 性能下降曲线分析法
实际上描述的是性能随用户数增长而出现下降趋势的曲线。 而这里所说的“性能”可以是响应时间， 也可以是吞吐量或是单击数/秒的数据。 当然， 一般来说， “性能”主要是指响应时间。
对性能下降曲线分析来说， 主要关注的是性能下降曲线上的各个区间和相应的拐点， 通过识别不同的区间和拐点， 从而为性能瓶颈和性能调优提供依据。
四： LoadRunner的性能测试过程
LoadRunner的性能测试过程如下：
计划测试——测试计划——创建VU脚本——创建测试场景——运行测试场景——分析结果。
该方法并不是一个适应性广泛的性能测试过程。
五： Segue提供的性能测试过程
从确定性能的基线开始， 通过单用户对应用的访问获取性能取值的基线，然后设定可接收的性能目标（响应时间）， 用不同的并发用户数等重复进行测试。
Segue提供的这种性能测试方法非常适合性能调优和性能优化， 通过不断重复的try-check过程， 可以逐一找到可能导致性能瓶颈的地方对其进行优化。
六： PTGM模型
该性能测试模型将性能测试分为测试前期准备、 测试工具引入、 测试计划、 测试设计与开发、 测试执行和管理以及测试分析等6个步骤。
