性能测试如果从其性质上区分，可以分为以下3种不同的测试
1.诊断性质的测试
2.调优性质的测试
3.检测性质的测试
如何确定软件需要做性能测试，分开来讲就是如何确定软件需要诊断性质、调优性质、检测性质的测试。
诊断性质的测试一般发生在软件系统出现性能瓶颈之后，由开发人员要求测试方进行性能测试，通过性能测试诊断一下性能瓶颈的位置。
上面我有说到，是由开发方提出的测试要求给测试方，这种性质的测试是测试方针对开发方这样的客户做的测试，做不做诊断性质的性能测试就由开发方做决策。如果开发方提出需求那么这个软件就需要执行此种性能测试。
调优性质的测试可以分为配置上的调优测试和程序上的调优测试
配置上的调优测试可以是测试方在开发方的配合下调整各种服务器上的参数，例如数据库系统分配内存大小、CPU数量等又如weblogic上的线程数、JDBC链接池等获得应用系统在性能方面最优的配置。
这种性质的测试通常情况下在软件的集成阶段和验收阶段，由用户提出的对系统性能测试的需求，所以根据客户需求而定，通常情况下这方面的测试都容易被忽略。
程序的调优测试可以是测试方告知开发方大致确定的性能瓶颈的位置，由开发人员调整程序，再交由测试方进行性能的回归测试，确认调优的效果。
程序的调优测试同样根据客户的需求而定，根据检测结果确定软件性能与客户需求的差距确定是否需要此种测试。
检测性质的性能测试仅仅是通过性能测试确定系统响应时间、CPU处理能力、资源利用率等数据，判断是否符合已经确定的性能指标。
根据经验检测性质的性能测试不应跟需求有关系，而是每个软件都应该执行的，其结果应作为软件的规格交付客户，就像一个充电器的电流，大小，重量一样。
另外测试方可以通过了解开发方当前处在某个阶段时，可以初步判定开发方提出的性能测试工作需求是否合适或合理。
例如：开发方在集成测试阶段提出检测性质的工作需求时，测试方可以初步判定这样的性能测试工作需求是不合理的。
因为在集成测试阶段，软件的开发尚未完成，代码在后续的测试过程中还需要大量的修改因此此时测试方可以建议开发方在此阶段执行诊断性质的或者调优性质的性能测试。

引用:

原帖由 godn_1981 于 2008-5-4 09:11 发表
任何一个软件都需要做性能测试的，只是你做没做的问题，不能因为你没做，就是不需要做啊。
你没做，只能说明你们不规范，没做好而已。

这话说的有点过了
任何一个软件……这话说的也有点空
说到底测试需求来源于用户的要求以及被测产品的行业标准或法律法规的相关规定，如果上述要求都没有，被测软件又是一个单机版且功能简单的小软件，测试人员却非要强调性能测试，那就有点矫枉过正了
当然，在我们的测试规范中，也有关于性能测试方面的相关说明，如，在做测试需求分析时，规定了如何对系统需求中的性能指标的提取；在测试设计时，如何设计测试用例、测试脚本或测试方法，以满足对系统性能指标测试的覆盖；对产品行业标准以及法律法规中的寿命和可靠性指标的测试设计和测试执行相关标准……
这一切的前提都在于我们测试的系统是一个被测需求清晰明确的系统，因为测试并不是空穴来风，它一定是有所依据的

如存在性能需求，就需要做相关测试——听起来是正确的。

其实，就自己的经验，即使有时候存在性能需求，只要其影响面不大，不足以影响全局时，基本上都是忽略不做的。况且，现在很多系统都是基于中间件构建或者组件构建，而这些组件或中间件都是由第三方厂商提供的，相应的，其组件的性能风险就会被押在厂商身上。

作为一个产品而言，其性能风险始终存在，即使购买了第三方的产品作为研发的基准。但作为一个项目，其性能风险往往是隐性存在的，有时候客户没有提供任何性能需求，却在最后阶段以性能表现差把项目拦下的情况也时有发生。所有的测试都有基准和依据。至于规不规范，也仅是一家之言，对于企业而言，能在有限的时间内，达成双方的最大利益即意味着成功（即客户满意，公司的成本又相对低）

如何判断是否需要对一个软件进行性能测试,我认为这个判断的依据就是用户的需求以及用户的潜在需求.软件就是用户的业务管理流程的计算机语言化的体现.因此,脱离了用户的需求的软件就是失败的软件.判断是否需要对一个软件进行性能测试,归根结底就是要判断用户的业务管理流程以及实际运行环境是否有性能测试的需求，再具体点就是用户的哪些业务需求需要进行性能测试或者说软件的哪些模块需要进行性能测试。当然，为了开发一个好的软件，不仅仅需要考虑用户的当前需求，还要考虑用户的潜在需求，一般在设计软件的性能指标时，应至少考虑两到三年后的用户业务增量。
   在分析用户的需求时，应注意以下几个方面：
   1、系统使用人员的数量；
   2、系统使用的频率；
   3、系统不同业务之间的使用频率以及实际运行环境的高峰时的使用频率；
   4、服务器部署模式；
   5、系统是否属于实时系统；
   6、系统是否属于大数据量系统（读操作、写操作、读/写操作）；
   7、系统运行的实际环境（软件环境、硬件环境以及网络环境）；
   8、系统的业务增量以及增加速度（测试强度估算）。
   以上为个人意见，有错误或疏漏的地方请大家及时指正和补充。

根据测试需求的显示需求和隐含需求来判断

测试不仅要考虑质量，也要考虑与商业利益的平衡，软件购买商其最终目的是为企业创造价值利益，软件提供商的最终目的也是软件的利润创造。所以是否做性能测试最终要考虑到质量与利益的平衡。这也是一些小型项目通常不进行性能测试的根本原因

从理论的角度来分析：所有的软件都需要做性能测试；
从实际的角度来分析：根据实际性能需求来做性能测试；
至于怎么来衡量，楼上的各位都已经讲了很多。

1、可以从用户需求中提炼性能测试需求和潜在性能测试需求；
2、没有用户需求的情况下，在实际条件允许的前提下发掘潜在性能测试需求；

用户要做就做，不要做跟他说明利害关系，不要做就不做，合同上说好了的事

性能测试，当然这里我说的是产品可以使用，但需要对产品的性能进行深一步评判的这种性能测试，我会考虑三个因素：
1.客户需求中的优先级，并确定我们要做什么样的性能测试，要做到一个什么样的程度。
2.做这次性能测试的成本。
3.测试的时间是否足够，计划是否能够安排跟得上。

即成本，进度，范围这三个方面作考虑。

如果软件公司对自己开发的软件有责任心的，自己不用客户提出就会做的~~~要等到客户提出才做，说明公司是没有责任心的，最自己的软件也是不负责任的~~

楼上有N多位说性能测试居然不要做，或者根据客户的要求。
个人认为这是不负责任的，对自己公司，对客户都是不负责任的。
一般软件都是要性能测试的，特别是一些交互操作比较多的系统。
如果客户不要求就不做，明明知道有性能隐患，却视而不现，对软件测试人员来说是有悖职业原则的。
我觉得，这个东西事先要给客户讲清楚的，有些客户压根不懂，根本不懂性能为何物，到时候上线之后发现不行了，再来找麻烦，会更郁闷。

以前对软件性能测试没有清晰的认识，只是在做项目时感觉那块运行比较慢，就研究一下，对代码进行调优或对数据库进行调优。后来做一些数据量比较大、交互比较频繁、实时性要求较高的项目，才真正开始引入压力测试工具，对项目进行认真的性能测试。经过大家对这个问题的讨论，从理论上对性能测试有了更深刻的认识。当然，具体到实践中，还需要大家仔细的揣摩、体会。

<客户的项目需求规格>可作为我们是否进行性能测试或者说做性能测试的标准。不同的终端客户要求肯定不一样，打个比方，同一个OEM厂家，但是终端客户不同（比如分别为SONY, JVC, Philips），它们的性能测试标准肯定不一样。有句话说：请给我结果！我想客户想要的最终结果就是符合它们一贯的产品规格和理念！只有对客户需求有充分的了解和分析，才能做到让客户满意的质量！

我们应该知道我们测试人员的根本目的是什么？测试是为了干什么？
      性能测试是必不可少的，一个软件它之所以成功，那它的前提无疑是经过了很多的测试。不管是什么测试，做了总比不做的好，虽然成本不一样，但是小的成本可以换来以后的利益。客户看的不是你的片面之词，他们要的只是结果。所以所有的测试都是必不可少的，尤其是性能测试！

[ 本帖最后由 yuanjun612 于 2008-5-6 10:57 编辑 ]

参考依据：
1.实际情况；
2.用户需求；
3.公司人力，财务资源；
4.在做功能测试时发现有些地方性能的确不够好的地方可以考虑做下性能测试；
5.风险和以后的软件扩展情况；

本以为该题目已经结束了，没想到竟然还在，呵呵。

简单说一下我的看法
http://www.51testing.com/?10851/ ... e_itemid_81556.html

个人认为任何一个人家都是做性能测试的，只不过区别在于性能测试做的是否专业，是否深入罢了

站在公司与用户的立场我说些不一样的吧。
我以前公司的产品是卖给用户使用，在签合同时有明确要求进行性能测试的我这都要安排进行，另一种情况是开发的产品实在太差，必须通过某些途径获知该产品是否存在哪些瓶颈，这时，进行相关的性能测试成了一种解决的途径。
现在的公司是产品开发了自己用，类似于门户网站那样的。这时客户对象发生了变化，‘上帝’不高兴不满意就会发怒，所以一般都有做性能测试。
当然，做到何种程度这个我想取决于这个团队的技术力量。
其实，这里很多时候都是一种观念在起冲突：利润、成本、质量、信誉。

最近忙，好久没来这里看了，上来看到关于性能测试刚好我也做过，随便说两句。

性能测试应该是要做的，不做性能测试那么几乎必然会在客户那里出性能问题。

第一种情形性能测试最主要的依据也就是客户需求和市场定位。客户需求和市场定位体现在产品设计书里面，就是说产品应该有什么样的性能设计时就应该写明，比如读写速度不低于100M同时访问量可达到5000以上等等。测试本来就是依据设计的，设计书里有还能不测么。这种测试一定要在交给用户前测完，并且必须合格。

第二种情况，系统扩展的性能，比如一个网络管理系统，管理若干节点，当管理10个节点的时候，系统响应正常，但是系统扩展到20个节点时，可能会由于内部某些逻辑导致性能意想不到地迅速下降从而影响系统扩展。这种测试是否要做可以根据开发计划来看，比如目前可能暂时不会有用户要求支持20个节点，那么10个节点反正是正常的20个可以暂缓测试。

第三种情形，就是异常系的性能，还说我们的网络管理系统，管理10台机器，每次发送某个命令会对这10台机器进行查询，一般情况下这个查询是半秒内就可完成，但是比如说查询使用了rsh，而碰巧rsh遇到某种网络错误时会卡死并10秒不返回，命令一直接不到返回值也被卡住，如果不处理，用户那里看到的就是有时候突然性能低下。这种问题比较容易出。

第四，性能测试进行参数调整。性能测试还有一个重要的目的就是参数调整。很多软件开发会用到一些现成工具包或者工具，这些写工具一般有很多参数可以选，假设我们的管理系统借助samba来实现win-linux之间的文件传输，就存在一个samba自身的参数怎么选取的问题，为了给samba找到一个合适的参数组合配合自己的软件使用，做几百上千次不同参数组合的性能测试并不奇怪。当然了自己开发的软件里面的许多参数也同样要调整，比如一次发送的网络包的大小，再考虑和samba参数互相配合，这个测试是极其复杂繁琐的，但是不得不作，将来用户手册里写的请打开xxx文件把xxx相改为xxx之类的话，都是靠这些测试得来的。