摘自云层的书《性能测试进阶指南——Loadrunner11实战》　　

1）硬件上的性能瓶颈

　　一般指的是CPU、RAM方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、Web服务器等）、应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）。

例如，确定了在数据库服务器上需要6个CPU、12GB内存。但是在测试时，发现CPU的持续利用率超过95%，这时可以认为在硬件上出现了性能瓶颈。

2）应用软件上的性能瓶颈

　　一般指的是应用服务器、Web服务器等应用软件，还包括数据库系统。

　　例如：在WebLogic平台上配置了JDBC连接池的参数，最大连接数为50，最小连接数为5，增加量为10。在测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接，导致交易处理的响应时间大大增加。这时可以认为在应用软件上出现了性能瓶颈。

3）应用程序上的性能瓶颈

　　一般指的是开发人员新开发出来的应用程序。

　　例如，某程序员开发了一个缴费处理程序。在测试时发现，这个缴费处理程序在处理用户的并发缴费请求时，只能串行处理，无法并行处理，导致缴费交易的处理响应时间非常长，这时可以认为在应用程序上出现了性能瓶颈。

4）操作系统上的性能瓶颈

　　一般指的是Windows、UNIX、Linux等操作系统。

　　例如，在Windows操作系统中，对某软件进行性能测试，出现物理内存不足时，如果虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加。这时可以认为在操作系统上出现了性能瓶颈。

5）网络设备上的性能瓶颈

　　一般指的是防火墙、动态负载均衡器、交换机等设备。

　　例如，在动态载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡机制没有起到相应的作用，这时可以认为在网络设备上出现了性能瓶颈。

　　性能瓶颈出现的原因及其定位是十分复杂的，这里只是简单介绍常见的几种瓶颈类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员一起定位性能瓶颈。

读别人的文章，有些觉得自己需要的就摘录下来

摘录内容只做参考，因为正确性我个人暂没能力判断。

摘录一 ： 摘自 51Testing软件测试网 » mmhao_54的美丽生活 » 日志2007-12-07 14:11:42 / 个人分类：LR使用分享

1、Running Vusers

这张图表遵循着标准的测试时间表，每分钟增加10个用户，到达最大用户数250时运行10分钟，之后每分钟减少25个用户

2、Throughput(吞吐量)，完美的吞吐量应该是随着每秒点击率的增加而增加，这种增加是建立在带宽足够处理用户提出的所有请求的基础上的。

摘自：51Testing软件测试网 » mmhao_54的美丽生活 » 日志

上一篇 / 下一篇  2007-12-07 14:11:42 / 个人分类：LR使用分享

转摘地址：http://bbs.51testing.com/thread-402388-1-1.html

1.     根据测试范围和测试方法来估计工作量：
　　a）制定测试计划以前，明确测试范围：

　　不同的测试范围，对测试量的评估起到至关重要的因素，比如说测试一个模块或测试多个模块或测试整个系统等等，都属于测试范围不一样，明显工作量也不同，差别也挺大的。还有测试范围还包括功能性测试范围或非功能性测试范围等等，在做测试工作量评估的时候，都必须考虑。

　　b）确定合理、有效的测试方法：

　　比如说你要考虑测试某个项目，你必须考虑测试方法是否合理。比如说某个模块的功能测试，你可以采用QTP做自动化功能测试，还是手工做功能测试，工作量就不一样，做测试计划以前必须考虑清楚。要不然，估算的工作量肯定不准。

　　2.     根据测试任务来评估工作量：

　　a）质量需求和项目背景决定工作量：

　　不同的项目背景，不同的质量要求，决定不同的测试工作量。如果我们测试的是一个银行系统，涉及到每个人的经济利益，我们测试时必然会对性能测试或安全测试放到第一位，设计较多的异常测试用例，这样一做，必然增加我们的工作量。如果是一般的系统，我们可以只执行一般的功能测试通过就可以了，没有必要去做其它的异常、安全测试。如果系统的质量需求要求高，也许就要进行更深层次的测试，回归测试的力度必然要加大，工作量自然就上去了。

　　b）尽可能详细的罗列出项目测试内容：

　　一般来说，测试工作量的评估工作都是交给测试经理或项目组成员协助共同来完成的。准确评估项目测试的工作量，必须要求测试Leader明确详细的测试内容，只有知道测试什么？哪些需要测试？详细分析需求规格说明书，明确测试任务以后，评估才会有依据，所以

　　尽可能详细的罗列出项目测试内容非常必要。

　　c）把测试任务细化到每个测试功能点：

　　我们在估算测试时间的时候，可以把测试任务细化到每个测试的功能点，比如说“新增”、“修改”、“删除”、“暂停”、“恢复”等等都记成一个功能点，在预算的时候，同时把编写测试用例和执行测试用例的时间都要计算进去。例如：编写一个测试用例或执行一个功能测试各需要一个小时，如果我们有100个功能点，我们就知道大约要200个小时。这样估算出来的时间比较精确一点，比较符合实际。

　　d）预估业务测试或模块交叉测试的复杂容易程度：

　　很多时候，我们测试初期，对业务了解不是很多，忽视了对业务方面或交叉模块测试的评估，等到了测试后期，大量的业务测试没有测试，测试时间特别紧，所以在测试初期预估测试的复杂容易程度，在评估工作量方面至关重要。

　　3.      根据开发阶段来评估工作量：

　　不同的开发阶段，测试时间估算也不太相同。比如说，开发的系统是第一个版本，相对以后的测试工作来说，可能安排的时间要多一点。大多数情况下是这样的，也许后面的版本增加很多新功能，测试工作量还大于第一个版本也是常有的事情。作为测试负责人，对于使用测试阶段来评估工作量，必须根据实际情况来定，不能盲目给出数字，应付了事。

4.     根据测试经验的积累来评估工作量：

　　我们可以借鉴类似项目的测试经验，比如说被测试的系统，我们做过类似的产品，就可以把相关的测试文档，修改一下，复用以前的测试用例，这时候测试工作量就减少了很多。如果没有，我们只能重来。还有就是借鉴以前项目编写测试用例或执行测试的时间，对测试工作量的准确评估，也具有一定的参考价值。

　　5.     根据测试风险来评估工作量：

　　a）测试人员变动带来的风险：

　　在一般的软件公司，测试人员的流动是常有的事情，所以估计测试工作量的时候，我们一定要把它计算在里面，留有一定的余地，以防不测。比如说：以前安排了一个做过类似项目，对类似项目熟悉的测试人员，也许给他安排了一天的工作量。如果他不在了，其它的人去做这个测试也许就2天，甚至3、5天都不一定能够搞定。测试人员带了的风险还是特别高的。

　　b）系统测试环境的风险：

　　系统测试环境带来的风险，一般来说比较小，发生的可能性很小，如果一旦发生了，也相当可怕。最可怕的就是硬件故障，在经济实力允许的情况下，我们一般的方法是准备两套测试环境，一套测试环境出现问题，我们立马切换到另外一个测试环境中去继续测试，避免影响正常的测试进度。但是大部分的公司都不愿意花血本，来购买昂贵的硬件，而是以牺牲时间来付出代价。

　　c）、开发人员版本发布延迟风险：

　　不做好版本配置管理或没有正规的测试规范的公司，大部分情况下很难估计工作量，他们基本上都是边改边开发边测试，如果一旦开发出现异常，整个测试就立马终止，这对测试的相互制约作用也会更大，这样对我们估算的工作量也不准确。

　　d）、项目变更带了的风险：

　　一个项目做到中途，由于客户对技术不断深入的了解，很多时候不是“需求变更”，就是“设计变更”，弄得我们测试人员特别郁闷，不断修改测试文档。如果相关部门没有正规的变更管理，变更引起的工作量更没办法估算。很多测试后期出现工作量加大，测试延期的问题，都是对项目风险估算不足造成的。

　　6.     发挥项目团队的力量来评估工作量：

　　a）积极调动下属，发挥集体的智慧：

　　我带领的测试团队，对工作量的估计大致是这样的：

　　测试主管对自己带的项目做一个整体时间预估，给出一个大致估计时间。我再把每个模块分配给准备安排测试这个项目的每个测试工程师做一个测试工作量评估，得到结果后和测试主管的工作量对比。这个时候我要考虑他们每个人的实际能力做适当的调整，最后把调整相对准确的时间，递交项目组评审，如果通过，就OK，如果他们有建议，视建议的程度好坏，再决定是否做修改。有空的时候，我会定时检查每个人的工作内容是否准时完成，督促一下工作。一般来说，时间偏差相差不会超过一周，呵呵！！！

　　b）建立一个测试工作量的预算表格：

　　测试计划书写结束，我一般是把测试工作量的每一项，写成一个Checklist，每项大致多少时间，写出来。邮件的形式发给部门的全体成员，提高工作量的透明度。每天下班结束以前，每个人都要对测试的工作做汇报，包括已经完成的工作或未完成的工作都进行汇报，时间不是很长，就几分钟的时间，测试Leader也要做Review，以防虚报。

【总结】

1、   测试还是不够重视，项目测试出了很多问题的时候反应也没人管，现在要求测试配合的时候也是轻描淡写，公司轻视测试的这种大局势一时半会改不了。（很多项目测试一再延期、测试的bug有去无回、回来的bug一半拒绝等等）

2、   上面不配合，测试部很难要求开发规范测试版本、测试交接条件、测试跟踪流程，为了这些已经屡屡让人气愤了，但上面根本不重视。郁闷，对于喜欢规范化的我对这种现状痛心疾首啊。公司说走五级，要规范，实际却又这样做，开玩笑！

3、   对这种现状我心有余而力不足，人家说做事不能做铁，要做钢，铁只有硬的一面，很快就会被折断作废，而钢则软硬兼具，不但不易废掉还能解决很多问题。可是，说起来容易做起来难啊？

4、   我承认开发重要，但测试一再忍让不代表有利于项目改善，千百回的琢磨，或许，换种方式会更好，正面不行，反面试试看吧。

哎，不知道是我过于较真还是太傻，这么长时间，应该习惯了，说了不要生气，但项目乱搞的时候我还是火冒三丈，要想活得长一点，还是改改我的脾气吧！

最近想关注关注性能测试了，于是从论坛里摘录收集了几个朴实却很根本的术语定义。如下：

1：软件测试是什么？

   让系统更完美，尽可能在系统面向消费者之前发现问题，然后让团队解决。

. 分析结果：使用LoadRunner Analysis 创建图和报告并评估性

   迷迷糊糊就做了测试这个行业，然后又不知不觉的做了一年多的测试...哎，这期间因为测试，我欢喜过，也郁闷过！

   其实做哪个行业对我来说都无所谓，感觉都那样，开始时费劲，但时间长了就好了。对此我一直奇怪，是不是自己太平凡，平凡的没有一点爱好专长，要不然怎么能做什么行业都一样呢？这似乎是个很深奥的问题，一直没有答案，习惯了没有答案，对此也就没有什么失望，无所谓了。

   对自己是不是没有专长虽然不在乎了，但是目前的测试工作，却时常让我头疼，我一直在问：“我到底适不适合做测试？”虽然测试没有做出什么名堂，但相比之下毕业后做的最长的就是测试工作了，呵呵，日久生情吧，如果换行业，还有些不舍呢！再想起测试有意思的地方，如：你可以接触到和人类有关的各种系统、可以疯狂的对系统搞破坏...这就是欢喜！但同时也有忧郁的时候，如：对同一个系统反复测试、开发人员对bug的忽视、测试技术不够用导致缺陷漏测...

   干一行爱一行，每当自己迷茫和怀疑时只好用这句话来指引和安慰自己了。或许，是我对测试付出得不够，或许，是我对测试的路不够信任，又或许，是我对测试的信心不够...当你要对一个行业下达判决书时，先全力去付出，去信任，如果一段时间后，你仍然无所进步，那么，你才能判定你可能真的不适合那个行业。反之，如果你总是带着一种怀疑和不自信的态度去试探，那么，一路走过，你会发现：世界上没有任何一种职业是你适合的。

   呜呼！或许，我应该换种心态！

与http://www.51testing.com/ 结识几个月了，觉得这是个不错的网站，这段日子有时间就来此看看，慢慢就产生了感情，还有一种老朋友的感觉，很高兴有缘与这里的朋友们相识。

今天开通了个人空间，第一天，我竟有点兴奋！