并且涉及的大多是有关开发和系统管理工作，AAdjust调整。E执行失败后才进入A阶段。因此A设为隐式。

      只要若干因素之中的一个出现问题，一个项目要取得成功是困难的因为胜利的项目需要多个因素和条件来支持；而一个项目失败却很容易。就有可能导致项目失败。比如中途测试人员发生变化，性能指标未和用户达成统一理解等。笔者还曾看过一个例子，因为测试演讲的格式与用户要求的格式不一致，而不得不重新再执行一次所有的性能场景，来采集用户要的数据。

当我做过的性能测试项目越多，实际上。就会发现越多的因素可能会影响性能测试项目的成败，甚至可以是千奇百怪的

      主要是寻找出不同性能测试项目的共性，本节中。而总结出一个具有普遍意义的性能测试过程。遵循过程做性能测试，大多数情况下可以有效地规避风险，并能取得比较好的性能测试结果。这当然不是意味着我有了这个过程，就不考虑其他因素了只是说每个项目都会有自己的独特因素要考虑，尽管这些因素可能很重要，但它并不在本节的讨论范围内。

要廓清两点事实：给出此过程模型之前。

性能测试过程从何时开始，第一。又在何时结束？

这是一个基本而重要的问题。

有关性能测试过程的描述不尽一样：各种书籍和资料中。

比方LoadRunn手册中提供的过程是计划测试→测试设计→创立VU脚本→创建测试场景→运行测试场景→分析结果。

      一个try-check过程，而在Segu中提供的性能测试过程。即：评估需求→开发测试→建立基线→执行测试→分析结果→回归测试→测试结束。

      而是于两者过程的入口和入口条件不一致。这使得它其实在描述两件事情，上面LoadRunn和Segu描述各自的性能测试过程最大的区别不在于工具部分。或者说是描述一个事情的两个部分。

      软件测试和软件设计、编码一样，CMM中。隶属于软件工程过程，而需求分析过程在软件工程过程之前。这就隐含着一个默认的先决条件：CMM这个体系下，产品在进入软件测试阶段的时候，软件需求是已经明确下来并文档化了

      同样是软件需求，实际情况却经常并非如此。软件功能需求在进入测试阶段就已经产生了各种文档，包括需求文档和设计文档，确保功能需求是详细、明确、无二义性的而软件性能需求往往进入了性能测试阶段还不明确（可参见Control一章开篇的例子）这会给性能测试项目带来很大的风险。

      应该突破已有的理论束缚，因此。寻找更合适的性能测试过程模型。经过对多个性能测试项目的实践经验总结，本节提出GA MEA性能测试过程模型，其开始于软件需求分析阶段，非常符合目前国内的性能测试实践。

性能测试自身有没有质量？第二。

      但对软件测试的质量却鲜有提及。知道“一个好的测试用例是发现了一个原先未发现的bug这其实是对用例质量的度量。软件性能测试项目也有质量，以前我总是讨论软件产品的质量、开发代码的质量。并可以度量。下面是局部度量的方法：

包括时间、人力、物力。1性能测试耗费的资源。

以及各自的级别。2性能测试中发现的bug数目。

生产环境运行后发现的性能bug数目、级别。3软件系统交付用户。

而一个好的性能测试过程模型对提高性能测试质量是很有帮助的

GA MEA性能测试过程模型：

? 

GGoal目标

? 

A Analysi分析

? 

MMetric度量

? 

EExecut执行

?