1, 黑盒测试:也称功能测试或数据驱动测试。它在已知产品应具有的功能的条件下，通过测试来检测每个功能是否都能正常使用

黑盒测试-主要试图发现几类错误：功能不对或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误。

黑盒测试有两种基本方法，即通过测试和失败测试

具体的黑盒测试方法包括等价类划分、因果图、正交实验设计法、边值分析、判定表驱动法、功能测试等。

 

 

功能测试:检查软件的功能是否符合规格说明

基本方法: 测试基本的方法是构造一些合理输入（在定义域内），检查是否得到期望的输出。

(在定义域内使用等价类划分比较有效)

 

等价类划分;是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

容错性测试:检查软件在异常条件下的行为（输入不同的数据类型或者定义域之外的值进行测试）。

 

 

边界值分析（Boundary Value Analysis，BVA）:是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试效果。BVA不仅重视输人条件边界，而且也从输出域导出测试用例。

边界值设计测试遵循的五条原则：
1、如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值；
2、若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例；
3、针对每个输出条件使用上述1、2条原则；
4、如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例；
5、分析规格说明，找出其他的可能边界条件。

 

 

错误推测设计方法:就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

 

因果图方法:是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。

 

正交试验设计法，\:就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

 

 

2, 白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作

【摘要】 我们对自动化测试充满了希望，然而，自动化测试却经常带给我们沮丧和失望。虽然，自动化测试可以把我们从困难的环境中解放出来，在实施自动化测试解决问题的同时，又带来同样多的问题。在开展自动化测试的工作中，关键问题是遵循软件开发的基本规则。本文介绍自动化测试的 7 个步骤：改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计（ design for sustainability ），有计划的部署和面对成功的挑战。按照以上 7 个步骤，安排你的人员、工具和制定你的自动化测试项目计划，你将会通往一条成功之路。

　　一个故事 :

　　我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。

　　以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。她委派一位员工 ——Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作，还有其他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候，遇到了问题。这个测试工具太复杂，难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后， Jerry 认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。在打过几个电话后，测试工具厂商派过来一位技术专家。技术专家到达后，找出问题所在，测试工具可以正常工作了。这还算是顺利了。但是，几个月后，他们还是没有真正实现测试自动化， Jerry 拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。

　　项目经理 Anita 把项目重新指派给 Kevin Shorttimer ，一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训，避免 Kevin 步 Jerry 的后尘 —— 由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。一个主要的版本发布后， Kevin 准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过， Kevin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本，并且确实发现了 bug 。接下来， Kevin 得到一个从事软件开发职位的机会，离开了自动化的岗位。

　　Ahmed Hardluck 接手 Kevin 的工作，从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少，并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中， Ahmed 经历了很多失败，并且不能确信测试执行的方法是否正确。测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有 BUG ，导致测试执行失败，发现产品的 BUG 后，每个人都很高兴。接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。按照计划，产品的下一个发布版本有几个主要的改动， Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来，在测试产品的新版本中，绝大多数测试用例执行失败了， Ahmed 对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。经过商讨，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。最后，大家根据新接口修改自动化测试，测试都通过了。产品发布到了市场上。接下来，用户立刻打来投诉电话，投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。

　　这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过，我希望你没有这样的相似结局。本文将给出一些建议，避免出现这样的结局。

　　问题

　　这个故事阐明了几个使自动化测试项目陷入困境的原因：

　　自动化测试时间不充足：根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。

　　缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。

　　缺乏经验：尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。

　　更新换代频繁（ High turnover ）：测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。

　　对于绝望的反应：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。

　　不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。

　　关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。

　　遵守软件开发的规则

　　你可能了解 SEI （软件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分为 5 个界别，该模型用来对软件开发组织划分等级。 Jerry Weinberg （美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别。很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别 [Weinberg 1992] 。恰恰在这类组织环境中，经常采用自动化测试方法。因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。

　　像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。像其他软件开发项目一样，测试自动化也会出现 BUG ，因此，需要有计划的跟踪 BUG ，并且对修改后的 BUG 进行测试。像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。

　　本文中不对软件开发做过多讲述。我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。

　　? 改进软件测试过程

　　? 定义需求

　　? 验证概念

　　? 支持产品的可测试性

　　? 可延续性的设计（ design for sustainability ）

　　? 有计划的部署

　　? 面对成功的挑战

　　步骤一：改进软件测试过程

　　如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。同样的，上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。

　　例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行，并且单调乏味。怎样才能做好回归测试文档化的工作呢？通常的做法是采用列有产品特性的列表，然后对照列表检查。这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。

　　在你开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。如果测试掌握了基本的产品知识，这会更好。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。

　　我以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后，我没有机会完成测试自动化的实现工作。不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了 BUG 。从某种角度看，这实际上是一次很成功的自动化测试。在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。

　　另外一个提高测试效率的简单方法是采用更多的计算机。很多测试人员动辄动用几台计算机，这一点显而易见。我之所以强调采用更多的计算机是因为，我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作，这种情况下由于错误的使用了测试设备、测试环境，导致测试没有效果。因此，自动化测试需要集中考虑所需要的支撑设备。

　　针对改进软件测试过程，我的最后一个建议是改进被测试的产品，使它更容易被测试，有很多改进措施既可以帮助用户更好的使用产品，也可以帮助测试人员更好的测试产品。稍后，我将讨论自动化测试的可测试需求。这里，我只是建议给出产品的改进点，这样对手工测试大有帮助。

　　一些产品非常难安装，测试人员在安装和卸载软件上花费大量的时间。这种情况下，与其实现产品安装的自动化测试，还不如改进产品的安装功能。采用这种解决办法，最终的用户会受益的。另外的一个处理方法是考虑开发一套自动安装程序，该程序可以和产品一同发布。事实上，现在有很多专门制作安装程序的商用工具。

　　另一些产品改进需要利用工具在测试执行的日志中查找错误。采用人工方法，在日志中一页一页的查询报错信息很容易会让人感到乏味。那么，赶快采用自动化方法吧。如果你了解日志中记录的错误信息格式，写出一个错误扫描程序是很容易的事情。如果，你不能确定日志中的错误信息格式，就开始动手写错误扫描程序，很可能面临的是一场灾难。不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。最终用户也不愿意采用通过搜索日志的方法查找错误信息。修改错误信息的格式，使其适合日志扫描程序，便于扫描工具能够准确的扫描到所有的错误信息。这样，在测试中就可以使用扫描工具了。

　　通过改进产品的性能对测试也是大有帮助的。很显然的，如果产品的性能影响了测试速度，鉴别出性能比较差的产品功能，并度量该产品功能的性能，把它作为影响测试进度的缺陷，提交缺陷报告。

　　上面所述的几个方面可以在无需构建自动化测试系统的情况下，大幅度的提高测试效率。改进软件测试过程会花费你构建自动化测试系统的时间，不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。

　　步骤二：定义需求

　　在前面的故事中，自动化工程师和自动化测试的发起者的目标存在偏差。为了避免这种情况，需要在自动化测试需求上保持一致。应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。很多人认为自动化测试显然是一件好事情，但是，他们不愿意对自动化测试的目标给出清晰的描述。下面是人们选用自动化测试的几个原因：

　　? 加快测试进度从而加快产品发布进度

　　? 更多的测试

　　? 通过减少手工测试降低测试成本

　　? 提高测试覆盖率

　　? 保证一致性

　　? 提高测试的可靠性

　　? 测试工作可以由技术能力不强测试人员完成

　　? 定义测试过程，避免过分依赖个人

　　? 测试变得更加有趣

　　? 提高了编程技能

　　开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。除非三者之间达成一致，否则很难定义什么是成功的自动化测试。

　　当然，不同的情况下，有的自动化测试目标比较容易达到，有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高，测试人员必须能理解充分的理解自动化测试，从而通过自动化测试不断发现软件的缺陷。不过，自动化测试不利于测试人员不断的积累测试经验。不管怎么样，在开始自动化测试之前应该确定自动化测试成功的标准。

　　手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源，建立测试环境，执行测试用例。测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。接下来，他们写作缺陷报告单，保证缺陷被修改，并且总结所有的缺陷报告单，以便其他人能够了解测试的执行情况。

　　千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择，或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲，除非测试的各个环节都采用自动化方式，否则不是真正意义上的自动化测试，这真是胡言乱语。如果仅仅是为了寻找挑战，可以尝试在测试的每个环节都采用自动化方法。但是，如果寻找成功测试的方法，请关注那些可以快速建立的，可以反复利用的自动化测试。

　　定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求，距离成功的自动化测试近了一步。

　　步骤三：验证概念

　　在前面的故事当中，那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过，在项目的进行中，他得到了来自各个方面的支持。

　　你可能还没有认识到这一点，不过，你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长，并且需要来自你身边的各种人的帮助。

　　很多年前，我从事一个测试自动化项目的工作，参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统，并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度，甚至演示已经完成的部分功能。但是，我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后，整个项目被取消了，此后，我再也没有犯这个错误。

　　你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的，需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性，从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。

　　对于很多人来说，自动化测试意味着 GUI 自动化测试，我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试，并惊奇的发现这两类测试的测试计划有很大的互补性。不过， GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的，因为，如果没有选择合适的测试工具，你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中，找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期，你可能打算现在购买一份测试工具，然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前，找出工具存在的问题。这样，你可以从测试工具供应商得到更好的帮助，当你打算更换工具的时候，你不会感觉很为难。

　　下面是一些候选的验证概念的试验：

　　回归测试：你准备在每个版本运行同样的测试用例吗？回归测试是最宜采用自动化测试的环节。

　　配置测试：你的软件支持多少种不同的平台？你打算在所有支持的平台上测试执行所有的测试用例吗？如果是的，那么采用自动化测试是有帮助的。

　　测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。

　　非 GUI 测试：实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。

　　无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。

　　步骤四：支持产品的可测试性

　　软件产品一般会用到下面三种不同类别的接口：命令行接口（ command line interfaces ，缩写 CLIs) 、应用程序接口（ API ）、图形用户接口（ GUI ）。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看， API 接口和命令行接口比 GUI 接口容易实现自动化，去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者 API 接口，从而支持产品的可测试性。

　　下面，更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能，这确实是个很好的方法。可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法，但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本，但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果， GUI 测试还是主要由手工完成。

　　第二个原因，把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的 BUG ，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。 GUI 测试中，困难总是意外出现，让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。

　　第三个原因， GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。一般来讲，第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候，就开展 GUI 自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。

　　上面提到的这些原因都是基于采用 GUI 自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试，可以考虑实现 GUI 测试自动化。不过，你也应该考虑采用其他方法测试产品的核心功能，并且这些测试不会因为图形界面发生变化而被中断，这类测试应该采用命令行接口或者 API 接口。我曾经看到有人选择 GUI 自动化测试，因为，他们不打算修改被测试产品，但是，最终他们认识到必须对产品做修改，以保证 GUI 测试自动化可以正常工作。无论你选择哪种方法，自动化都需要对被测试的产品做修改。因此，采用可编程的接口是最可靠的。

　　为了让 API 接口测试更为容易，应该把接口与某种解释程序，例如 Tcl 、 Perl 或者 Python 绑定在一起。这使交互式测试成为可能，并且可以缩短自动化测试的开发周期。采用 API 接口的方式，还可以实现独立的产品模块的单元测试自动化。

　　一个关于隐藏可编程接口的例子是关于 InstallShield—— 非常流行的制作安装盘的工具。 InstallShield 有命令行选项，采用这种选项可以实现非 GUI 方式的安装盘，采用这种方式，从提前创建好的文件中读取安装选项。这种方式可能比采用 GUI 的安装方式更简单更可靠。

　　另一个例子是关于如何避免基于 WEB 软件的 GUI 自动化测试。采用 GUI 测试工具可以通过浏览器操作 WEB 界面。 WEB 浏览器是通过 HTTP 协议与 WEB 服务器交互的，所以直接测试 HTTP 协议更为简单。 Perl 可以直接连接 TCP/IP 端口，完成这类的自动化测试。采用高级接口技术，譬如客户端 JAVA 或者 ActiveX 不可能利用这种方法。但是，如果在合适的环境中采用这种方式，你将发现这种方式的自动化测试比 GUI 自动化测试更加便宜更加简单。

　　我曾经受雇在一家公司负责某个产品 GUI 相关的自动化测试，该产品也提供命令行接口，不过，他们已经实现了 GUI 的自动化测试。经过一段时间的研究，我发现找到图形界面中的 BUG 并不困难，不过，用户并不关注图形界面，他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能（这些功能即可通过 GUI 的方式，也可以通过命令行的方式使用）实现自动化测试。我决定推迟 GUI 自动化测试，扩展命令行测试套，测试新增的产品功能。现在回过头看这个决定，我没有选择 GUI 自动化测试是最大的成功之处，如果采用了 GUI 自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做 GUI 自动化测试了，并且已经购买了一套测试工具和其他需要的东西，但我知道在开展具体的 GUI 自动化测试活动中，会遇到各种各样的困难和障碍。

　　无论你需要支持图形界面接口、命令行接口还是 API 接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，未来的测试工作中，你很可能成功。尽可能早的启动自动化测试项目，提出可测试性需求，会使您走向自动化测试成功之路。

　　步骤五：具有可延续性的设计

　　在开篇的故事中，我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来，导致测试自动化达不到预期的效果。自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过，测试人员应该相信得到的结果，测试执行的实际结果也应该是通过了。其实，有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果，而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误，都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。

　　性能： 提高代码的性能往往增加了代码的复杂性，因此，会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析，很多测试套都是花费大量的时间等候产品的运行。因此，在不提高产品运行性能的前提下，无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能，而并没有实际的操作经验。如果测试套的性能问题无法改变，那么应该考虑提高硬件的性能；测试套中经常会出现冗余，也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务，都是很好的办法。

　　便于分析： 测试自动化执行失败后应该分析失败的结果，这是一个棘手的问题。分析执行失败的自动化测试结果是件困难的事情，需要从多方面着手，测试上报的告警信息是真的还是假的？是不是因为测试套中存在缺陷导致测试执行失败？是不是在搭建测试环境中出现了错误导致测试执行失败？是不是产品中确实存在缺陷导致测试执行失败？有几个方法可以帮助测试执行失败的结果分析，某些方法可以找到问题所在。通过在测试执行之前检查常见的测试环境搭建问题，从而提高测试套的可靠性；通过改进错误输出报告，从而提高测试自动化的错误输出的可分析性；此外，还可以改进自动化测试框架中存在的问题。训练测试人员如何分析测试执行失败结果。甚至可以找到那些不可靠的、冗余的或者功能比较独立的测试，然后安全地将之删除。上面这些都是减少自动化测试误报告警、提高测试可分析性的积极有效的方法。另外，有一种错误的测试结果分析方法，那就是采用测试结果后处理程序对测试结果自动分析和过滤，尽管也可以采用这种测试结果分析方法，不过这种方法会使自动化测试系统复杂化，更重要的是，后处理程序中的 BUG 会严重损害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为异常，那该怎么办？我曾经看到测试小组花费开发测试自动化两倍的时间来修改测试脚本，并且不愿意开展培训过程。那些仅仅关注很浅层次测试技术的测试管理者对这种方法很感兴趣，他们排斥采用隐藏测试复杂度的方法。

　　综上所述，应该集中精力关注可以延续使用的测试套，从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

　　可读性： 很多情况下，在测试人员开始测试项目之前，公司已经有了一套测试脚本，并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它，但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性，在具体应用中，那些脚本常常没有多大的实用价值，越来越让人迷惑。因此，测试人员很难确定他们实际在测试什么，反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本，并且理解测试脚本究竟测试了什么，这是很关键的。好的文档是解决问题的手段之一，对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法，我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩，把所有执行的产品相关的命令记录到日志里。这样，当分析日志确定执行了哪些产品命令，命令采用了何种参数配置时，可以提供一个非常好的测试记录，里面记录了自动化测试执行了什么，没有执行什么。如果测试脚本可读性不好，很容易变得过分依赖并没有完全理解的测试脚本，很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后，可以更容易的开展同行评审活动。

　　可维护性： 在工作中，我曾经使用过一个测试套，它把所有的程序输出保存到文件中。然后，通过对比输出文件内容和一个已有的输出文件内容的差别，可以称已有的输出文件为 “ 标准文件 ” （ “gold file” ）。在回归测试中，用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了，它会产生很多错误的警告。随着时间的推移，软件开发人员会根据需要修改产品的很多输出信息，这会导致很多自动化测试失败。很明显，为了保证自动化测试的顺利进行，应该在对 “ 标准文件 ” 仔细分析的基础上，根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是，每次只检查选定的产品的某些特定输出，而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试，这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改，并研究使测试修改量最小的方法，测试中采用库是解决问题的方法。当产品发生变化的时候，只需要修改相关的库，保证测试与产品的变动同步修改即可。

　　完整性： 当自动化测试执行后，报告测试执行通过，可以断定这是真的吗？这就是我称之为测试套的完整性。在前面的故事中，当没有对自动化测试完整性给予应有的关注的时候，发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果？自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败，但是，对于自动化测试误报告警的情况，大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效，当测试发现异常的时候，能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法，分类包括 PASS ， FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果，它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分，另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ，这个 BUG 引起测试队列中部分测试用例被跳过，没有执行。当测试队列运行完毕后，没有上报任何错误，我不得不通过走读代码的方式发现了这个 BUG 。如果，我没有关注到这个 BUG ，那么可能在认识到自动化测试已经出现问题之前，还在长时间运行部分测试用例。

　　独立性： 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候，通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化，测试执行是由一台不会说话的计算机完成的，你必须告诉计算机什么样的情况下测试执行是失败的，并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境，因此，保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档，以便一个接着一个有序地完成测试执行，每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误，这个错误源于 “ 多米诺骨牌 ” 测试套，当一个测试执行失败，会导致后续一系列测试失败。更糟糕的是，所有的测试关联紧密，无法独立的运行。并且，这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后，人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式，不过，重要的是在不牺牲测试的可靠性的前提下保证测试的独立性，如果测试可以在无需人看守情况下运行，那么测试的执行效率就不是大问题了。

　　可重复性： 自动化测试有时能够发现问题，有时候又无法发现问题，对这种情况实在没有什么好的的处理办法。因此，需要保证每次测试执行的时候，测试是以同样的方式工作。这意味着不要采用随机数据，在通用语言库中构造的随机数据经常隐藏初始化过程，使用这些数据会导致测试每次都以不同的方式执行，这样，对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试，需要在可预测，并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据，然后在测试过程中使用这些数据。这样做看起来似乎很好，但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候，往往匆匆忙忙整理文件名和测试数据记录。当对这些测试采用自动化测试方法，该做哪些工作呢？办法之一是，可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用，那么就需要制定命名规则，避免在不同的测试中命名冲突，采用命名规则是一种很好的方法。然而，我曾经看到有些测试只是随机的命名数据记录，很不幸，事实证明采用这种随机命名的方式不可避免的导致命名冲突，并且影响测试的可重复性。很显然，自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次，测试数据记录的名字中包含四个随机产生的数字，经过简单的推算如果我们采用这种命名方式的时候，如果测试使用了 46 条记录，会存在 10% 冲突的可能性，如果使用 118 条记录，冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录，这样引入了问题，损害了测试的可靠性和测试的完整性。

　　测试库： 自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库，自己也写了一些。当要求测试不受被测试产品接口变动影响的时候，采用测试库方法是非常有效的。不过，根据我的观察测试库已经使用的太多了，已经被滥用了，并且测试库往往设计的不好，没有相关的文档支撑，因此，使用测试库的测试往往很难开展。当发现问题的时候，往往不知道是测试库自身的问题，还是测试库的使用问题。由于测试库往往很复杂，即便在发现测试库存在问题，相关的维护人员也很不愿意去修改问题。通过前文中的论述，可以得出结论，在一开始就应该保证测试库设计良好。但是，实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致，即 " 你将不需要它 " 。这会导致在测试用例之间的代码出现一些重复，我发现微小的变化可能仍然存在，很难与测试库功能协调。你可能打算对测试用例作修改，采用源代码的方式比采用库的方式更容易修改。如果有几个测试，他们有某些共同的操作，我使用剪切和粘贴的方式去复制代码，有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码，我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的，因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试，并且很方便扩展测试套。在开发软件测试项目的时候，大多数程序员找到与他们打算实现功能类似的源代码，并对源代码做修改，而不是从头开始写代码。同样，在写测试套的过程中可以采用上述方法，这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库，这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义，并且文档化，从始至终都应该保持。我会对测试库作充分的测试后，才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库，不要希望有朝一日测试人员会利用你的测试库完成大量的测试，这一天恐怕永远不会到来。

　　数据驱动测试： 把测试数据写入到简单表格中，这种测试技术得到了越来越广泛的应用，这种方法被称为表驱动（ table-driven ），数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试（ "third generation" automation ）。这需要写一个解析器，用来解释表格中的数据，并执行测试。该测试架构的最主要的好处是，它允许把测试内容写在具有一定格式的表格中，这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试，采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的，所以，上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作，还存在各种困难。代码所采用的编程语言是不断发展的。也许，测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入，这样，加入了新的变量。接下来，也许有人需要让测试中的某个环节运行一百次，这样加入一个循环。你可以采用其他语言，不过，如果你预料到会面临上述情况的时候，那么做好采用一些能够通过公开的渠道获取的编程语言，比如 Perl,Python 或者 TCL ，这样比设计你自己的语言要快的多。

　　启发式确认： 我曾经看到很多测试自动化没有真正意义上的结果校验，其原因有两个，一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的，另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过，采用手工校验测试结果的方法是真正意义上的测试校验。标准文件（ Gold file ）是另外一中校验测试结果的方法。首先，捕获被测试程序的输出，并检视程序的输出，然后，把输出信息文档化，并归档，作为标准文件。以后，自动化测试结果与标准文件作比较，从而达到结果校验的目的。采用标准文件的方法，也有弊端。当产品发生变化，自动化测试的环境配置发生变化，产品的输出发生变化的时候，采用标准文方法，会上报大量的误报告警。做好的测试结果校验方法是，对输出结果的特定内容作分析，并作合理的比较。有时候，很难知道正确的输出结果是什么样的，但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法，是因为担心如果结果校验漏掉了任何信息，可能导致自动化测试自身出现错误。不过，我们在测试过程中往往采用折衷的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法，那么他必须找相关人员咨询，寻找一种合适的测试结果校验策略，这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下，找到被测试产品的缺陷。

　　把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，你将进一步迈向成功的自动化测试。

　　步骤六：有计划的部署

　　在前面的故事中，当自动化工程师没有提供打包后的自动化测试程序给测试执行人员，会影响到测试执行，测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。

　　作为自动化工程师，你知道如何利用自动化方法执行测试和分析执行失败的结果。不过，测试执行人员却未必知道如何使用自动化测试。因此，需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配，出现安装错误的时候，能够给出有价值的提示信息，便于定位安装问题。

　　能够把自动化测试程序和测试套作为产品对待，那真是太好了。你应该对自动化测试程序和测试套开展测试，保证它们不依赖于任何专用的库或者是设备上的任何其他程序。

　　保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作；保证自动化测试是符合一般测试执行人员的思维习惯的；保证测试执行人员能够理解测试结果，并能够正确分析失败的测试执行结果；这需要自动化工程师提供自动动化测试相关的指导性文档和培训。

　　作为测试管理者，你希望在自动化工程师离开前，能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的，如果你没有及时的把测试套中的问题提出来，就会面临废弃已有的测试套的决定。

　　良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试；良好的测试套在新的软件平台上可以很方便的验证产品的功能；良好的测试套支持每天晚上开始的软件每日构造过程；甚至开发人员在代码 check in 之前，用良好的测试套验证代码的正确性。

　　测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此，尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上，这是个很好的办法。这样，大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美，而没有拿出来与人分享，这种做法一定要改变，共享出来的测试套不一定非常完美，共享才是关键。

　　有计划的自动化测试部署，保证你的测试套能够被产品相关人员获取到，你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。

　　步骤七：面对成功的挑战

　　当你完成了所有的事情，测试套已经文档化了，并且文档已经交付了。测试执行人员能够理解要开展的测试，并知道如何完成测试执行。随着你所负责产品的进一步开发和维护，测试被反复重用。虽然，在自动化使测试变简单的同时，也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况，如果不这样做，测试执行人员会认为执行失败的情况是由自动化引起，然后，自动化工程师被叫过来帮助诊断每一个执行失败的情况，开发人员往往也会认为执行失败是由于自动化测试自身引起的问题，这样，测试执行人员就不得不学习通过手工的方式，或者通过采用少量脚本的方式重现自动化测试发现的问题，以证明他们确实发现了产品当中的 BUG 。

　　测试套的相关工作还没有结束，为了提高测试覆盖率或者测试新的产品特性，需要增加更多的测试。如果已有的测试不能正常工作，那么需要对之修改；如果已有的测试是冗余的，那么需要删除这部分测试。

　　随着时间的推移，开发人员也会研究你设计的测试，改进产品的设计并且通过模拟你的测试过程对产品做初步测试，研究如何使产品在第一次测试就通过，这样，你设计的测试很可能无法继续发现新的问题，这种现象被称为一种杀虫剂悖论。这时候，会有人对你的测试有效性提出质疑，那么，你必须考虑是否应该挖掘更严格的测试，以便能够发现开发人员优化之后的产品中的缺陷。

　　以前，我提到过一个基本上无法实现的设想，设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的，手工测试是永远无法完全替代的。

　　有些测试受测试环境的影响很大，往往需要采用人工方法获取测试结果，分析测试结果。因此，很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题，因此，千万不要陷入到一切测试都采用自动化方法的错误观念中。

　　我曾经主张保证给与测试自动化持续不断的投入。但是，在开展自动化测试的时候，一个问题摆在面前，测试自动化应该及时的提供给测试执行人员，这个不成问题，但是如何保证需求变更后，能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步，那么自动化测试的效果就无法保证了，测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期，然后把这个日期作为里程碑，并计划达到这个里程碑。当达到这个里程碑后，自动化工程师应该做什么呢？如果自动化工程师关注当前产品版本的发布，他需要为测试执行人员提供帮助和咨询，但是，一旦测试执行人员知道如何使用自动化测试，自动化测试工程师可以考虑下一个版本的测试自动化工作，包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候，如果考虑了自动化测试需求，那么自动化测试师的设计工作就很好开展了，采用这种方法，自动化测试工程师可以保持与开发周期同步，而不是与测试周期同步。如果不采用这种方式，在产品版本升级的过程中，自动化测试无法得到进一步的改进。

　　持续在在自动化投入，你会面临成功的挑战，当自动化测试成为测试过程可靠的基础后，自动化测试的道路将会越来越平坦。

　　参考文献：

　　Bach, James. 1996. “Test Automation Snake Oil.” Windows Technical Journal , (October): 40-44. http://www.satisfice.com/articles/test_automation_snake_oil.pdf

　　Dustin, Elfriede. 1999. “Lessons in Test Automation.” Software Testing and Quality Engineering (September): 16-22.
http://www.stickyminds.com/sitewide.asp?ObjectId=1802&ObjectType=ART&Function=edetail

　　Fewster, Mark and Dorothy Graham. 1999. Software Test Automation , Addison-Wesley.

　　Groder, Chip. “Building Maintainable GUI Tests” in [Fewster 1999].

　　Kit, Edward. 1999. “Integrated, Effective Test Design and Automation.” Software Development (February). http://www.sdmagazine.com/articles/1999/9902/9902b/9902b.htm

　　Hancock, Jim. 1997 “When to Automate Testing.” Testers Network (June).
http://www.data-dimensions.com/Testers'Network/jimauto1.htm

　　Hendrickson, Elisabeth. 1999. “Making the Right Choice: The Features you Need in a GUI Test Automation Tool.” Software Testing and Quality Engineering Magazine (May): 21-25. http://www.qualitytree.com/feature/mtrc.pdf

　　Hoffman, Douglas. 1999. “Heuristic Test Oracles: The Balance Between Exhaustive Comparison and No Comparison at All.” Software Testing and Quality Engineering Magazine (March): 29-32.

　　Kaner, Cem. 1997. “Improving the Maintainability of Automated Test Suites.” Presented at Quality Week. http://www.kaner.com/lawst1.htm

　　Linz , Tilo and Matthias Daigl. 1998. “How to Automate Testing of Graphical User Interfaces.” European Systems and Software Initiative Project No. 24306 (June). http://www.imbus.de/html/GUI/AQUIS-full_paper-1.3.html

　　Jeffries, Ronald E., 1997, “XPractices,”
http://www.XProgramming.com/Practices/xpractices.htm

　　Marick, Brian. 1998. “When Should a Test Be Automated?” Presented at Quality Week. http://www.testing.com/writings/automate.pdf

　　Marick, Brian. 1997. “Classic Testing Mistakes.” Presented at STAR. http://www.testing.com/writings/classic/mistakes.html

　　Pettichord, Bret. 1996. “Success with Test Automation.” Presented at Quality Week (May). http://www.io.com/~wazmo/succpap.htm

　　Thomson, Jim. “A Test Automation Journey” in [Fewster 1999]

　　Weinberg, Gerald M. 1992. Quality Software Management: Systems Thinking . Vol 1. Dorset House.

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=651566

最近一直在做智能手机小应用的跟踪验证测试，故障单是由测试高手提供的，是一个非常完善的测试队，连我们的开发团队都感叹他们的敏锐，能发现潜在的Bug。

   在验证之余，我认真研究了他们出的故障单，做了一些总结。

   1、手机软件系统测试的角度分为：功能模块测试，交叉事件测试，压力测试，容量性能测试，性能测试和用户手册测试等。

   2、功能模块测试：首先应分析功能模块的功能项，测试每个功能项是否能够实现对应的功能。一般根据测试案例（Test Case）或软件本身的流程就可以完成基本功能测试。（相对简单，故障也较容易解决）

   3、交叉事件测试：又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或来响闹。应该以执行干扰的冲突事件不会导致手机死机或花屏等严重的问题。
   交叉事件测试非常重要，能发现很多应用中潜在的性能问题。另外有中英文模式的切换的手机要注意中英文模式切换后的功能实现存在的问题，通常会被测试人没忽略。

   4、压力测试：又叫边界值容错测试或极限负载测试，即测试过程中，已经达到某一软件功能的最大容量，边界值或最大的承载极限，仍然对其进行相关操作。例如连续进行短信的接收和发送，超过收件箱和PIM卡所能存储的最大的条数，仍然进行短消息的接收或发送，以检测软件在超常态条件下的表现，来评估用户能否接受。
   压力测试用手工测试非常繁锁，可以考虑自动化测试，目前没有比较大量使用的工具，一般都是由开发人员配合开发出的工具，或者高级的测试人员编写出的脚本。

   5、容量测试：又叫满记忆体测试，包括手机的用户可用内存和SIM/PIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试，如果软件的极限容量状态下处理不好，有可能导致死机或严重的花屏等问题的出现。
   与压力测试有些类似，也可考虑自动化测试。

   6、兼容性测试：也就是不同品牌手机，不同网络，不同品牌和不同容量大小的SIM/PIM卡之间的互相兼容的测试，以短消息为例：中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息，接收，显示和回复功能是否正常等

   另外从我测试的这几个小模块中，按与时间相关和文字两方面容易出现故障的地方总结如下：

   1、与时间相关：首先是时间的输入域，是否有输入限制，如：文字、标点符号、小时大于24或12、分钟大于60、秒大于60、月大于12、日大于31（按月情况而定）等
   特别注意日期变更分界点如23：59或12：59的变化。以及12/24小时切换模式的测试。

   2、文字输入相关：当界面过多时，注意功能按钮的点击事件能否正常完成相应功能的实现。超过文字字数限制时的系统提示等。

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而， Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

_

由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。

软件测试步骤

2007-08-08 15:06:49 / 个人分类：软件测试技术

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展：从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门；测试工作也从简单测试演变为包括编制测试计划、编写测试用例、准备测试数据、开发测试脚本、实施测试、测试评估等多项内容的正规测试；测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

一、测试用例是软件测试的核心

       软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

       影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

       因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

二、什么叫测试用例

       测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

       不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

三、编写测试用例

       着重介绍一些编写测试用例的具体做法。

1、测试用例文档

       编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

       软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

       测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2、测试用例的设置

      我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

      按功能测试是最简捷的，按用例规约遍历测试每一功能。

      对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

      但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例

      测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

      设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

      可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

四、测试用例在软件测试中的作用

1、指导测试的实施

       测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

       根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2、规划测试数据的准备

       在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

      除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的"设计规格说明书"

      为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准

      完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准

      通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

五、相关问题

1、测试用例的评审

      测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新

      测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

      一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

3、测试用例的管理软件

      运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

      有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

 

1 测算系统的性能指标
 1.1 综述
  测算系统的性能指标是其它性能测试的基础，因为无论任何测试目的，都必须通过某些性能指标来说明问题。
 1.2 测试方法
  测算系统的性能指标在做法上比较简单，关键是找到相应的计算公式，并根据这些公式确定所需要的原始数据，然后在测试实施中获得这些原始数据。
 1.3 术语
  测试时间：一轮测试从开始到结束所使用的时间
  并发线程数：测试时同时访问被测系统的线程数。注意，由于测试过程中，每个线程都是以尽可能快的速度发请求，与实际用户的使用有极大差别，所以，此数据不等同于实际使用时的并发用户数。
  每次时间间隔：测试线程发出一个请求，并得到被测系统的响应后，间隔多少时间发出下一次请求。
  平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。
  处理能力：在某一特定环境下，系统处理请求的速度。
  cache影响系数：测试数据未必如实际使用时分散，cache在测试过程中会比实际使用时发挥更大作用，从而使测试出的最高处理能力偏高，考虑到这个因素而引入的系数。
  用户习惯操作频率：根据用户使用习惯估算出来的，单个用户在一段时间内，使用此类功能的次数。通常以一天内某段固定的高峰使用时间来统计，如果一天内没有哪段时间是固定的高峰使用时间，则以一天的工作时间来统计。
  预期平均响应时间：用户实际使用时，系统将在多长时间内响应。注意，这个值并不是某一次访问的时间，而是一段时间多次访问后的平均值。
  最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。这个数据就是实际可以同时使用系统的用户数。
 1.4 计算公式
  成功率＝成功次数÷（成功次数＋失败次数）
  处理能力＝成功次数÷测试时间
  最短平均响应时间＝MIN（平均响应时间）
  最高处理能力＝MAX（处理能力）×（1－cache影响系数）
  最大并发用户数＝（最高处理能力－1÷（预期平均响应时间－最短平均响应时间＋（1÷最高处理能力）））÷用户习惯操作频率，此公式要注意各时间单位的不同和转换
 1.5 测试过程
  1 设计方案
   见范例《范例1（web系统性能测试报告）.doc》。关键点是术语、计算公式、需收集的原始数据三部分
  2 测试实施
   根据成功、失败次数确定本组数据是否有效（成功率大于95%，成功次数大于20）
   根据成功、失败次数确定是否需要调整一组数据的测试时长
   根据数据的发散情况确定本组数据是否有效
   根据前后数据的对比确定本组数据是否有效（10%以内）
   根据前后数据的对比确定是否需要在同样情况下再次测试
   根据CPU占用率确定下一步的负荷
   ……
  3 数据分析
   基本上不需要分析，因为根据计算公式和测试实施中得到的原始数据，就可以直接得出所需要的性能指标
  4 测试报告
   见范例《范例1（web系统性能测试报告）.doc》。一般情况下，测试报告与测试方案基本一样，只是把测试出的原始数据和计算出的性能指标添加进去
 1.6 注意事项
  预期平均响应时间与最大并发用户数之间存在公式计算的关系，只有预先确定了其中之一，才能计算出另外一个
  除非在测试脚本中使用随机函数来模拟用户的访问，否则，测试脚本对被测系统的访问将存在一定的规律，从而导致平均响应时间与用户使用时出现较大差异。因此，一般都不可以把测试出的平均响应时间作为用户使用时的预期平均响应时间来对待

2 检验硬件配置能否满足客户要求
 2.1 综述
  客户在购买机器的前后，往往需要确定该机器是否满足其性能要求，这就需要进行这种目的的性能测试。由于提供给客户的配置方案基本上都是经过验证，或者根据以往经验能确定是没有问题的，所以要做的更多只是重复测算系统的性能指标，并形成一份测试报告交给客户。
 2.2 测试方法
  与测算系统的性能指标一样
 2.3 测试过程
  1 设计方案
   与测算系统的性能指标一样
  2 测试实施
   与测算系统的性能指标一样
  3 数据分析
   与测算系统的性能指标一样
  4 测试报告
   见范例《范例2（检验硬件配置能否满足客户要求）.doc》。报告的重点是说明系统在怎样的配置下能满足客户的要求，且给出数据来证明。由于测试报告是要交给客户看的，所以，测试报告的内容只需说明系统能满足客户要求即可，不需要写其它更多的东西。
 2.4 注意事项
  这里的整个过程和做法都类似于测算系统的性能指标，不同的只是最后形成的报告。

3 查找系统的性能瓶颈
 3.1 综述
  通常来说，在测算系统的性能指标之后，发现某些指标不满足要求，于是就要进一步去查找系统的哪部分是性能瓶颈，作为之后进行系统调优的基础。
  查找系统的性能瓶颈，一定是首先发现了系统存在性能问题，如果不能确定系统是否存在性能问题，那就应该只是测算系统的性能指标。
 3.2 测试方法
  由于已经确定了系统存在性能问题，所以，只需重复相同的软硬件配置，重复测试不能满足要求的性能指标，并在此过程中记录系统各部分的CPU占用率、物理内存、虚拟内存、磁盘IO等信息，有条件的还可以使用测试工具去统计各函数和方法的执行时间，综合分析出性能瓶颈的位置。
 3.3 测试过程
  1 设计方案
   见范例《范例3（查找系统的性能瓶颈）.doc》。
  2 测试实施
   与测算系统的性能指标的测试实施一样
  3 数据分析
   CPU占用率远大于其它部分的就是瓶颈，占用物理内存、虚拟内存远大于其它部分的可能是瓶颈，磁盘IO远多于其它部分的可能是瓶颈
   执行时间（不包含调用函数的时间）远多于其它部分的就是瓶颈
  4 测试报告
   见范例《范例3（查找系统的性能瓶颈）.doc》。报告的重点是判断性能瓶颈的依据和说明。
 3.4 注意事项
  如果没有发现明显的性能瓶颈，而系统的响应又经常超时，有可能是系统的并发处理机制出现问题，例如死锁

4 系统调优
 4.1 综述
  查找出系统的性能瓶颈后，下一步的工作就是系统调优（性能调优）。由于系统的性能是由软件和硬件两方面共同决定的，所以，系统调优分为软件调优和硬件调优。
  软件调优通常由开发人员完成，一般包括程序调优和数据库调优两方面。程序调优就是修改性能瓶颈部分的程序，提高其运行效率。数据库调优通常是增加或减少索引、增加cache等等，对数据库的各种参数进行调整。
  硬件调优通常由测试人员完成，一般是调整系统各部分的分布、增加机器、增加物理内存、调整虚拟内存、更换硬盘等等。
 4.2 测试方法
  系统调优是查找系统的性能瓶颈的延续，所以，前半部分的工作就是查找系统的性能瓶颈。之后，针对发现的瓶颈，与开发人员交流协商调优的方法，调整后再重复前面的工作。
 4.3 测试过程
  1 设计方案
   见范例《范例4（系统调优）.doc》。
  2 测试实施与数据分析
   查找出系统的性能瓶颈
   与开发人员交流协商系统调优的方法
   调整系统后再次测试
  3 测试报告
   见范例《范例4（系统调优）.doc》。报告的重点是系统的调整方法，以及在各种状态下的性能。
 4.4 系统调优结束的判定
  系统通过一定的调整，能达到各方都满意的性能
  项目经理以及高层确定系统不需要达到如此高的性能，从而修改需求
 4.5 注意事项
  需要经过各方的认同，系统调优才能结束

5 给出较适合的软硬件配置方案
 5.1 综述
  系统的性能与软硬件配置相关，不同的配置之下，系统将表现出不同的性能。性能要求较高的客户，需要较高的配置方案；性能要求较低的客户，需要较低的配置方案。什么样的配置能达到什么样的性能，从而能满足什么样的客户，这信息对于售前人员非常重要。
  通常，做这种目的的性能测试基本上能确定软件方面的系统调优不需要再进行，接下来做的只是，确定系统在不同档次的硬件上面所表现出的性能差异。
 5.2 测试方法
  首先需要确定判断是否“较适合”的标准，通常就是确定某些性能指标及其相应的数值范围，当这些性能指标在该范围之内时，就是“较适合”。通常都是取系统的处理能力作为标准。
  然后，选择不同的软硬件配置，在这些配置下测算那些性能指标。
  最后把各个结果汇总，确定几种较适合的方案。
 5.3 测试过程
  1 设计方案
   见范例《范例5（给出较适合的软硬件配置方案）.doc》。
  2 测试实施与数据分析
   把硬件进行不同的搭配，测算系统的性能指标
   筛选出一系列满足“较适合”标准的配置方案
  3 测试报告
   见范例《范例5（给出较适合的软硬件配置方案）.doc》。测试报告需要把测试过的软硬件配置及其相应的性能指标列出来，并列出推荐使用的若干种配置方案
 5.4 注意事项
  对于每种配置方案，都需要经过实际测试才能说那是较适合的配置方案，不可以通过类似的配置来推测

按进程运行VUSER难道没有意义？

 

在被监视windows机器上安装，Remote Service，仅安装这一个组件就行。到程序里启动，然后在控制台Coller中增加就成了...

要不windows加个服务端口也行

 

 

性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析：
•A、应用服务死掉。
   （小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
   （应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
   (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:   
     很慢的响应时间(slow response time)
     CPU空闲时间为零(zero percent idle CPU)
     过高的用户占用CPU时间(high percent user CPU)
     过高的系统占用CPU时间(high percent system CPU)
    长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
     过高的磁盘利用率(high disk utilization)
    太长的磁盘等待队列(large disk queue length)
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：
SQL Server数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
   4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL区）和数据字典快存的命中率：
   select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由内存：    select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
  缓冲区高速缓存命中率：
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
     select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
   内存排序命中率 ：
     select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
   
    注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

说明：
    以上只是个人的体会和部分资料的整理，并不代表专家之言。算抛砖引玉，有不同看法和更深入的分析的，希望大家勇要发言，以推动我们国内的性能测试工作。

测试方法概述

 

1.         功能测试

1.1.        手工测试与自动化工具测试划分

分析软件系统的各个模块，

将需要大量重复操作测试的功能做自动化测试

将自动化测试实现较难的功能做手工测试

1.2.        手工测试

a           分析系统需求说明书和规格说明书，

b           编写测试需求，

c           根据测试需求书写测试用例

d           按照测试用例，手动运行软件

e           发现bug，

f            将bug填写在vsts软件中

g           通知开发人员修改程序

h           进行回归测试

1.3.        自动化测试

a           分析系统需求说明书和规格说明书，

b           编写测试需求，

c           根据测试需求书写测试用例

d           根据测试用例编写\录制测试脚本

e           调试和整理测试脚本，

f            运行测试脚本，进行测试。

g           分析运行结果，发现bug

h           将bug填写在vsts软件中，

i             通知开发人员修改程序

j             进行回归测试

 

1.4.        测试通过标准

如果测试结果与预期结果一致测试通过，否则不通过。

 

1.5.        测试结果审批过程

测试工作执行完毕，写测试总结报告，召开测试总结会议，讨论产品是否可以发布（评审标准：测试案例是否完全，测试程序是否正确，测试结果是否令人满意，…）。

 

1.6.        测试挂起和恢复条件

l         测试挂起条件：

由于程序中存在重大问题或者问题过多，测试无法正常进行，测试人员申请测试挂起，经领导审批通过；

由于存在其他优先级更高的任务，通过批准，测试挂起。

l         测试恢复条件：

重大问题被解决或者程序通过重新修正；

优先级更高的任务被完成。

 

2.         性能测试

2.1.        测试的要点

速度 系统反应速度是否可以符合要求

负载 测试系统是否可以在正常的负载范围内正常运行

压力 测试系统的限制和故障恢复能力，是否会崩溃

2.2.        具体实施方法

预期指标的性能测试----测试系统要求的基本性能是否可以满足

模拟多用户同一时间数据的上传和下发

模拟多用户同一时间使用系统的相同功能

模拟多用户同一时间使用系统的不同功能

模拟多用户长时间适用系统，系统长时间运行（3至4天），测试系统的稳定性

大量数据同时上传或下发，数据的传输是否有误

网络性能测试测试，测试系统在网络延迟，网络断开，网络不稳定的状况下系统的运行情况以及是否可以有相应的措施

 

 

3.         图形测试

Ø         要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

Ø         验证所有页面字体的风格是否一致。

Ø          背景颜色应该与字体颜色和前景颜色相搭配。

Ø          图片的大小和质量也是一个很重要的因素，一般采用JPG 或GIF 压缩。

4.         内容测试

内容测试用来检验应用系统提供信息的正确性、准确性和相关性

5.         界面测试

整体界面是指整个Web 应用系统的页面结构设计，是给用户的一个整体感。

6.         操作系统版本测试

检验在不同的操作系统版本下，系统的运行

7.         安装与卸载测试

今天来说说ＬＲ里的组和用户的问题。
　　前几天看到一个帖子问：一个组里１０个用户和１０个组每个组一个用户有什么区别？
　　我们先看一下ＬＲ的官方帮助：
 
Multithreading
Vusers support multithread environments. The primary advantage of a multithread environment is the ability to run more Vusers per load generator. Only threadsafe protocols should be run as threads. (not applicable to Mercury Business Availability Center)
Note: The following protocols are not threadsafe: Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo.
o      To enable multithreading, click Run Vuser as a thread.
o      To disable multithreading and run each Vuser as a separate process, click Run Vuser as a process.
The Controller and Tuning Console use a driver program (such as mdrv.exe or r3vuser.exe) to run your Vusers. If you run each Vuser as a process, then the same driver program is launched (and loaded) into the memory again and again for every instance of the Vuser. Loading the same driver program into memory uses up large amounts of RAM (random access memory) and other system resources. This limits the numbers of Vusers that can be run on any load generator.
Alternatively, if you run each Vuser as a thread, the Controller or Tuning Console launches only one instance of the driver program (such as mdrv.exe), for every 50 Vusers (by default). This driver process/program launches several Vusers, each Vuser running as a thread. These threaded Vusers share segments of the memory of the parent driver process. This eliminates the need for multiple re-loading of the driver program/process saves much memory space, thereby enabling more Vusers to be run on a single load generator.
 
 
　　从上面的描述可以看到，
　　如果是线程安全的协议，在一个组（进程）里并发多个vusers，可以不用开那么进程。这可以减少系统的开销。
　　如果不是线程安全的协议，我们需要开多个进程来处理Ｖusers。这样势必增加系统的开销。
　　其实对现在的硬件来说，基本上客户端成为瓶颈的机会不是很大。（除非这公司太穷了）
^_^
 
 
　　这里我做了个实验，画了一张表，来形象的说明一下组/vusers/线程／进程的关系。
注：这里，我假定的是１０vsuers：

设置vusers按进程还是线程运行	Vusers(个／组)	组（个）	mmdrv.exe中的线程数（个／组）	Mmdrv.exe进程（个）	平均每个进程占的内存（k）	Mmdrv.exe占有内存总数（k）
线程	１０	１	１２	１	７，５００	７，５００
线程	１	１０	３	１０	５，１５０	５１，５００
进程	１０	１	１	１０	４，６７６	４６，７６０
进程	１	１０	１	１０	５，１５０	５１，５００

　　我这里脚本都是一样的。
　　大家如果自己做实验，内存可能会不一样。
　　在表里，我们可以很清楚的看到，进程多的时候，占用内存肯定是多的。
　　如果在同一组里开多个线程，占用内存就少得多。
　　我们还要注意一个细节就是在用线程来运行vusers的时候，每个进程中会多出几个线程来。
　　这多出来的很个进程在做什么，我没有查它的ＡＰＩ，我想可能是维护进程之间的运行。
 
　　很显然的，还有个问题，就是哪个压力更大。
　　这个问题也有些人在问，我想这个应该是很明显的吧。
　　其实对服务器来说，只要是１０个用户都在正常工作，而速度不会受到本地硬件的影响。
　　对服务器的压力是一样的。
　　这么来思考：
　　假设来说。
　　我们是从客户端来发数据库的，１０个用户，如果一秒钟发２０个数据包。
　　那对服务器来说，收到的数据包都是一样多的。所以压力也会是一样的。
　　那会不会存在在同一个进程里开１０个线程速度更慢呢。
　　这个，我以为不会的。
 
　　所以我认为压力是一样的。
 

我觉得Vuser用户在客户端无论进程还是线程来并发，只能影响到客户端，至于服务器段呢？接受到的并发用户数都一样，所以给服务器承受的压力都是一样的。

一般情况下，我会把应用服务器和数据库服务器搭建在同一机器上。

    几天前的测试环境搭建也不例外。

   
    快下班的时候，老板说要做一下性能测试。

  
   
    当时我只注意的环境是：

    服务器：tomcat-6.0.13

    数据库：mysql5.0

    操作系统：CentOS 4

   所知道的要素：

      1：tomcat的优化：将maxThreads设置成100

    然后将数据库的maxActive分别设置：15，20，25 。

      2：需要测试的有三个地方：首页、电影分类、单个电影

      3：测试持续时间为5分钟，虚拟用户为100个

   期望结果：
    
      根据不同的数据库maxActive值，在条件3相同的情况下，对比哪种的测试结果的性能比较好。

 
   这个相对来说比较简单，在很快的时间我就录制好了三个需要测试的脚本， 在运行脚本的时候，

   遇到的问题：LoadRunner的关联

   解决方法：http://www.51testing.com/?58025/action_viewspace_itemid_44330.html

   得到的结果是：

    在数据库maxActive值为20时，首页、电影分类、单个电影等测试结果的性能最好。

   判断的要素：

   吞吐量、点击量、平均响应时间

   分析的方法：

     在测试持续时间和虚拟用户都相同的情况下，比较不同maxActive值时，所得到的吞吐量、点击量、平均响应时间，

   如果吞吐量和点击量都比其他两种情况下要大，而且平均响应时间比其他两种情况下要低，则其性能比较好！

  做到这里，我已经很明确在哪种配置下得到的性能比较好，下一步要做的是，就是弄清楚到底是什么影响了性能？

  是应用服务器，还是数据库服务器，还是操作系统呢？

  接下来我想先对应用服务器进行优化，

   具体情况请查看：http://www.51testing.com/?58025/action_viewspace_itemid_61154.html

 然后在：

   所知道的要素：

    1：tomcat的优化：将maxThreads设置成100
       数据库的maxActive设置：20

    2：需要测试的有三个地方：首页、电影分类、单个电影

    3：测试持续时间为5分钟，虚拟用户为100个

   期望结果：
    
      对比在没有安装apr之前的测试结果和已安装了apr之后，对比哪种的测试结果的性能比较好。

  得到的结果：
   
      在安装apr之前和安装apr之后，没有明显的变化，所以排除应用服务器的问题。（虽然比较粗，但目前水平有限也只能做到这样了）

 接下来就要找出是数据库服务器，还是操作系统的性能有问题了。

   第一步：将应用服务器和数据库服务器分开

    我把数据库服务器从CentOS 4 移到了WINDOWS XP 下。

   第二步：分别监控两台机器
   
    遇到的问题：如何监控呢？
   
    解决方法：http://www.51testing.com/?58025/action_viewspace_itemid_44676.html
              http://www.51testing.com/?58025/action_viewspace_itemid_44562.html

   第三部：确定在运行脚本，需要监控哪些计数器

   1: 监控两台机器的CPU使用情况
   2：吞吐量、点击量、平均响应时间和成功率

  期望结果：
     对比应用服务器和数据库服务器没有分开之前的测试结果和分开之后的测试结果哪种性能比较好。

  得到的结果：
    1：CentOS 4 这台机器的CPU使用率在两次运行中一直居高不下。
    2：首页在应用服务器和数据服务器分开之后，吞吐量和点击量高了很多，并且平均响应时间也少了很多
    3：单个电影的吞吐量和点击量都比以前有所提高，但平均响应时间却没有降低。
    4：电影分类的吞吐率，点击率和平均响应时间都没有什么变化。

  分析结果：
    1： 根据两次性能测试结果：CentOS 4 这台机器的处理器存在着瓶颈，需要增加处理器来提高性能

    2： 首页没有使用到数据库的查询，而电影分类中使用到数据库查询比较多，所以初步分析数据库的性能存在着问题，需要做进一步的优化。
        由于MYSQL5.1版本中支持了分区，建议开发人员使用分区技术。
   

 参考指标：  
 度量 指标    问题
 cpu 95%以上  瓶颈
 80－85％ 最大上限
 70％以下 正常

    本次测试中欠缺的是：对数据库服务器的监控。

    期望提高的是：对操作系统的监控，进一步分析出问题所在，
                 对数据库服务器的监控，给出明确点优化意见

   写在这里，不知道我这样做性能测试的方法对不对，还希望看过此文章的朋友给出意见和建议。

同一场景
1.小用户量的情况下测试
2.大用户量情况下的测试

分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu

使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time
System\ Processor Queue Length

通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）

性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析：
•A、应用服务死掉。
  （小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
  （应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
  (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆: 
    很慢的响应时间(slow response time)
    CPU空闲时间为零(zero percent idle CPU)
    过高的用户占用CPU时间(high percent user CPU)
    过高的系统占用CPU时间(high percent system CPU)
    长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
    过高的磁盘利用率(high disk utilization)
    太长的磁盘等待队列(large disk queue length)
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：
SQL Server数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
  4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL区）和数据字典快存的命中率：
  select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由内存：    select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
  缓冲区高速缓存命中率：
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
    select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
  内存排序命中率 ：
    select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'

 

简介

Iperf 是一个 TCP/IP 和 UDP/IP 的性能测量工具，能够提供网络吞吐率信息，以及抖动、丢包率、最大段和最大传输单元大小等统计信息，从而能够帮助我们测试网络性能，定位网络瓶颈。其设计 从根本上克服了原来的一些工具，如 ttcp 和 nettest 等的固有的缺陷。

下载:

Offical Site: http://dast.nlanr.net/Projects/Iperf2.0/iperf-2.0.2.tar.gz

安装:

在指定目录下，按老三步进行：(1)./configure (2)make (3)make install

功能介绍

• TCP

测量网络带宽

报告MSS/MTU（最大传输单元）值的大小和观测值

支持TCP窗口值通过套接字缓冲

当P线程或Win32线程可用时，支持多线程。客户端与服务端支持同时多重连接

• UDP

客户端可以创建指定带宽的UDP流

测量丢包

测量延迟

支持多播

当P线程可用时，支持多线程。客户端与服务端支持同时多重连接（不支持Windows）

• 在适当的地方，选项中可以使用K（kilo-）和M（mega-）。例如131072字节可以用128K代替。
• 可以指定运行的总时间，甚至可以设置传输的数据总量。
• 在报告中，为数据选用最合适的单位。
• 服务器支持多重连接，而不是等待一个单线程测试。
• 在指定时间间隔重复显示网络带宽，波动和丢包情况。
• 服务器端可作为后台程序运行。
• 服务器端可作为Windows 服务运行。 使用典型数据流来测试链接层压缩对于可用带宽的影响。

参数与说明

命令行选项	环境变量选项	描述
客户端与服务器端选项
-f, --format	$IPERF_FORMAT	格式化带宽数输出。支持的格式有： 'b'=bits/sec  'B'=Bytes/sec  \)GF1zZxD65703'k'=Kbits/sec 'K'=KBytes/sec  (?:Dm1^]eb65703'm'=Mbits/sec 'M'=MBytes/sec 51Testing软件测试网8t&}9O1e'h]b 'g'=Gbits/sec 'G'=GBytes/sec 51Testing软件测试网:VvHm R H 'a'=adaptive bits/sec 'A'=adaptive Bytes/sec51Testing软件测试网o l3M.\HM%v 自适应格式是kilo-和mega-二者之一。除了带宽之外的字段都输出为字     节，除非指定输出的格式，默认的参数是a。 51Testing软件测试网(p5w.T'M [ 注意：在计算字节byte时，Kilo=1024， Mega=1024^2，Giga= 1024^3。通常，在网络中，Kilo=1000， Mega=1000^2， and Giga=1000^3，所以，Iperf也按此来计算比特（位）。
-i, --interval	$IPERF_INTERVAL	设置每次报告之间的时间间隔，单位为秒。如果设置为非零值，就会按照此时间间隔输出测试报告。默认值为零。
-l, --len	$IPERF_LEN	设置读写缓冲区的长度。TCP方式默认为8KB，UDP方式默认为1470字节。
-m, --print_mss	$IPERF_PRINT_MSS	输出TCP MSS值（通过TCP_MAXSEG支持）。MSS值一般比MTU值小40字节。
-p, --port	$IPERF_PORT	设置端口，与服务器端的监听端口一致。默认是5001端口，与ttcp的一样。
-u, --udp	$IPERF_UDP	使用UDP方式而不是TCP方式。参看-b选项。
-w, --window	$TCP_WINDOW_SIZE	设置套接字缓冲区为指定大小。对于TCP方式，此设置为TCP窗口大小。对于UDP方式，此设置为接受UDP数据包的缓冲区大小，限制可以接受数据包的最大值。
-B, --bind host	$IPERF_BIND	绑定到主机的多个地址中的一个。对于客户端来说，这个参数设置了出栈接口。对于服务器端来说，这个参数设置入栈接口。这个参数只用于具有多网络接口的主机。在Iperf的UDP模式下，此参数用于绑定和加入一个多播组。使用范围在224.0.0.0至239.255.255.255的多播地址。参考-T参数。
-C, --compatibility	$IPERF_COMPAT	与低版本的Iperf使用时，可以使用兼容模式。不需要两端同时使用兼容模式，但是强烈推荐两端同时使用兼容模式。某些情况下，使用某些数据流可以引起1.7版本的服务器端崩溃或引起非预期的连接尝试。
-M, --mss	$IPERF_MSS	通过TCP_MAXSEG选项尝试设置TCP最大信息段的值。MSS值的大小通常是TCP/IP头减去40字节。在以太网中，MSS值 为1460字节（MTU1500字节）。许多操作系统不支持此选项。
-N, --nodelay	$IPERF_NODELAY	设置TCP无延迟选项，禁用Nagle's运算法则。通常情况此选项对于交互程序，例如telnet，是禁用的。
-V		绑定一个IPv6地址 服务端：$ iperf -s –V 51Testing软件测试网P/r+R@e;rD"|2| 客户端：$ iperf -c <Server IPv6 Address> -V 51Testing软件测试网#{ P{H#H9i-i p6pm 注意：在1.6.3或更高版本中，指定IPv6地址不需要使用-B参数绑定，在 1.6之前的版本则需要。在大多数操作系统中，将响应IPv4客户端映射的IPv4地址。
服务器端专用选项
-s, --server	$IPERF_SERVER	Iperf服务器模式
-D		(仅用于Windows)Unix平台下Iperf作为后台守护进程运行。在Win32平台下，Iperf将作为服务运行。
-R		(仅用于Windows)卸载Iperf服务（如果它在运行）。
-o		(仅用于Windows)重定向输出到指定文件
-c, --client host	$IPERF_CLIENT	如果Iperf运行在服务器模式，并且用-c参数指定一个主机，那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。
-P, --parallel	$IPERF_PARALLEL	服务器关闭之前保持的连接数。默认是0，这意味着永远接受连接。
客户端专用选项
-b, --bandwidth	$IPERF_BANDWIDTH	UDP模式使用的带宽，单位bits/sec。此选项与-u选项相关。默认值是1 Mbit/sec。
-c, --client host	$IPERF_CLIENT	运行Iperf的客户端模式，连接到指定的Iperf服务器端。
-d, --dualtest	$IPERF_DUALTEST	运行双测试模式。这将使服务器端反向连接到客户端，使用-L 参数中指定的端口（或默认使用客户端连接到服务器端的端口）。这些在操作的同时就立即完成了。如果你想要一个交互的测试，请尝试-r参数。
-n, --num	$IPERF_NUM	传送的缓冲器数量。通常情况，Iperf按照10秒钟发送数据。-n参数跨越此限制，按照指定次数发送指定长度的数据，而不论该操作耗费多少时间。参考-l与-t选项。
-r, --tradeoff	$IPERF_TRADEOFF	往复测试模式。当客户端到服务器端的测试结束时，服务器端通过-l选项指定的端口（或默认为客户端连接到服务器端的端口），反向连接至客户端。当客户端连接终止时，反向连接随即开始。如果需要同时进行双向测试，请尝试-d参数。
-t, --time	$IPERF_TIME	设置传输的总时间。Iperf在指定的时间内，重复的发送指定长度的数据包。默认是10秒钟。参考-l与-n选项。
-L, --listenport	$IPERF_LISTENPORT	指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
-P, --parallel	$IPERF_PARALLEL	指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
-S, --tos	$IPERF_TOS	出栈数据包的服务类型。许多路由器忽略TOS字段。你可以指定这个值，使用以“0x”开始的16进制数，或以“0”开始的8进制数或10进制数。例如，16进制'0x10' = 8进制'020' = 十进制'16'。TOS值1349就是：  1d PaV"T9@ y65703IPTOS_LOWDELAY     minimize delay        0x1051Testing软件测试网+`DxWZ'R(i)QG%?!V S IPTOS_THROUGHPUT   maximize throughput   0x0851Testing软件测试网%o3dD0W oWR#X IPTOS_RELIABILITY  maximize reliability  0x04 !g"?3@Zf s0l65703IPTOS_LOWCOST      minimize cost
-T, --ttl	$IPERF_TTL	出栈多播数据包的TTL值。这本质上就是数据通过路由器的跳数。默认是1，链接本地。
-F		使用特定的数据流测量带宽，例如指定的文件。 $ iperf -c <server address> -F <file-name>
-I		与-F一样，由标准输入输出文件输入数据。
杂项
-h, --help		显示命令行参考并退出 。
-v, --version		显示版本信息和编译信息并退出。

举例：

1）TCP测试51Testing软件测试网 J?s1_O,^`Yo
服务器执行：./iperf -s -i 1 -w 1M51Testing软件测试网'\4A'CT#yxs
客户端执行：./iperf -c host   -i  1  -w 1M51Testing软件测试网+Z%jx7B C,A yO*`(D
其中-w表示TCP window size，host需替换成服务器地址。 51Testing软件测试网%xgQcL
2）UDP测试
MwD!i OB:X65703服务器执行：./iperf -u -s
s#clS*[9u$\$JJ65703客户端执行：./iperf -u -c 10.255.255.251 -b 900M  -i 1  -w 1M  -t 6051Testing软件测试网]jL{w-]0g\
其中-b表示使用多少带宽，1G的线路你可以使用900M进行测试。

 

 

loadrunner的每秒点击数是指 Vuser 每秒向 Web 服务器提交的 HTTP 请求数。这里的请求数应该这样计算：

如果你点击一个链接，这个操作返回的页面上有5张图片，那么下载每一张图片都需要一个http请求，也就是说这个页面下载完成之后的点击数应该是6（有其他需要下载的东西也同样计算）

吞吐量：Vuser 在任何给定的某一秒上从服务器获得的数据量。这个数据量的计算是所下载的各个资源大小的总和

loadrunner的合并图问题

在并发测试结果中，将运行Vuser图与事物响应时间图关联合并，出来的图中，有一种比较奇怪的现象：用户用户越多的时候，反倒事物的响应时间越短，反复捉摸之后，终于理解了：

在并发测试的最后时刻，所有用户同时执行的一个事物，但是各个用户完成事物所用的时间长短一定是不同，比较快完成事物的用户，在完成之后就先退出了系统，在这种情况下，系统中运行着的用户数量越来越少，与此同时，这些用户完成事物所用的时间也就比较长，此时，loadrunner计算事物的平均响应时间也就长了。所以就出现了合并图上用户越少，事物响应时间越长的现象。这样，在并发测试结果中查看用户影响事物响应时间的图也就没什么意义了。

 

 

用LoadRunner监控windows的性能

2007-09-26 18:23:28 / 个人分类：性能测试

有两种情况
第一种：

如果是同一个用例 单机达到本机硬件承受能力极限或者许可证数量的极限 可以分成多个负载生成器统一加压.

第二种：

如果是一个包含多用例的综合场景 可以用多个负载生成器加压 也可以单独在各测试机上独立执行单个用例，加压时间不一定同步，有可能需要看其他机器的测试结果来决定加压的力度和时机