实际上，当我们做过的性能测试项目越多，就会发现越多的因素可能会影响性能测试项目的成败，甚至可以是千奇百怪的。
在本节中，我们主要是寻找出不同性能测试项目的共性，而总结出一个具有普遍意义的性能测试过程。遵循过程做性能测试，在大多数情况下可以有效地规避风险，并能取得比较好的性能测试结果。这当然不是意味着我们有了这个过程，就不考虑其他因素了，只是说每个项目都会有自己的独特因素要考虑，尽管这些因素可能很重要，但它们并不在本节的讨论范围内。
在给出此过程模型之前，我们要澄清两点事实：
第一，性能测试过程从何时开始，又在何时结束?
这是一个基本而重要的问题。
在各种书籍和资料中，有关性能测试过程的描述不尽一样：
比如LoadRunner手册中提供的过程是：计划测试→测试设计→创建VU脚本→创建测试场景→运行测试场景→分析结果。
而在Segue中提供的性能测试过程，是一个try-check过程，即：评估需求→开发测试→建立基线→执行测试→分析结果→回归测试→测试结束。
上面LoadRunner和Segue描述各自的性能测试过程最大的区别不在于工具部分，而是在于两者过程的入口和出口条件不一致。这使得它们其实在描述两件事情，或者说是在描述一个事情的两个部分。
在CMM中，软件测试和软件设计、编码一样，隶属于软件工程过程，而需求分析过程在软件工程过程之前。这就隐含着一个默认的先决条件：在CMM这个体系下，产品在进入软件测试阶段的时候，软件需求是已经明确下来并文档化了的。
实际情况却经常并非如此，同样是软件需求，软件功能需求在进入测试阶段就已经产生了各种文档，包括需求文档和设计文档，确保功能需求是详细、明确、无二义性的;而软件性能需求往往进入了性能测试阶段还不明确(可参见Controller一章开篇的例子)。这会给性能测试项目带来很大的风险。
因此，我们应该突破已有的理论束缚，寻找更合适的性能测试过程模型。经过对多个性能测试项目的实践经验总结，我们在本节提出GAME(A)性能测试过程模型，其开始于软件需求分析阶段，非常符合目前国内的性能测试实践。
第二，性能测试本身有没有质量?
以前我们总是讨论软件产品的质量、开发代码的质量，但对软件测试的质量却鲜有提及。我们知道“一个好的测试用例是发现了一个原先未发现的bug”，这其实是对用例质量的度量。软件性能测试项目也有质量，并可以度量。下面是部分度量的方法：
(1)性能测试耗费的资源，包括时间、人力、物力。
(2)性能测试中发现的bug数目，以及各自的级别。
(3)软件系统交付用户，在生产环境运行后发现的性能bug数目、级别。
而一个好的性能测试过程模型对提高性能测试质量是很有帮助的。
GAME(A)性能测试过程模型：
G：Goal，目标
A：Analysis，分析
M：Metrics，度量
E：Execution，执行
(A)：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式。
性能测试过程模型如图1-5所示。
图1-5 性能测试GAME(A)模型
文章来源于领测软件测试网 https://www.ltesting.net/
