软件测试工具LoadRunner经常遇到的问题    loadrunner 破解

8.1 VuGen的问题

MILY: 宋体; mso-hansi-font-family: Calibri; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 宋体" twffan="done">在使用VuGen 中经常会遇到的问题。

8.2 Controller的问题

在使用Controller 中经常会遇到的问题。

1. 在添加完Load Generators 机器时， 连接老是失败； 添加的机器明明已经安装了

loadrunner， 并且网络通讯正常。

解决方法： 在安装loadrunner 的第七步骤， 应该选择第2 项， 如果选择了第一项，

就会有这种问题。重新安装一下即可。

2. 在VuGen 中运行良好的脚本， 到Controller 中运行却出问题。

这种问题可能会遇到。为了确定问题出在Controller 中的场景，而不是脚本的问题，

你应该在所有的Load Generators 机器上使用VuGen 运行测试脚本， 确保都能够运

行正确。因为VuGen 和Controller 运行的机制不一样。在VuGen 中运行时使用的

是完整的浏览器， 而在Controller 中运行时使用的只是浏览器的基本的部分。

8.3 计数器的问题

在使用性能计数器中经常会遇到的问题。

1. 添加了Windows Resources 计数器后， 却看不到实时的数据。

解决方法： 要得到监视的数据， 必须要在被监视的服务器（Web Server） 上获得管

理员权限。最简单的方法是在“ 网络邻居”中以administrator 身份登陆Web Server。

当然使用下面的控制台命令也可以：net use \\< 机器名> 然后登陆用户名和密码即

可。（登陆的用户名必须具有管理员权限）

2. 添加了一些默认的性能计数器后， 出现了错误。

解决方法： 可能是一些LoadRunner 默认的计数器在WebServer 上已经不存在的原

因， 尤其是数据库的计数器方面。简单的解决方法，就是删除有问题的计数器， 添

加比较接近的计数器（ 可能需要参考Windows 帮助或者数据库的帮助）

文章来源于领测软件测试网 http://www.ltesting.net/

TAG: loadrunner LoadRunner Loadrunner loadRunner 工具 软件测试

软件测试技术: 软件测试工程师　测试用例　功能测试　测试管理　缺陷管理　手机测试　自动测试　单元测试　性能测试　安全测试 软件测试环境: Windows　Unix　网络知识　服务器 开源测试:开源功能测试　开源性能测试　开源缺陷管理　开源配置管理　开源解决方案　测试开发: JAVA　.net　UML　脚本语言　数据库　中间件　测试资料: 商业测试工具　开源测试工具　软件测试教程 质量保证: 项目管理　需求管理　软件度量　项目估算　质量模型　解决方案 测试工具: Mercury测试工具 Rational测试工具 Segue测试工具 其它

领测国际作为合作伙伴受邀参加2009 IBM峰会

发布: 2009-8-20 11:20 | 作者: 领测国际 | 来源: 本站原创 | 查看: 7次 | 进入软件测试论坛讨论

站在不同视角 感受性能测试

发布: 2009-8-24 08:36 | 作者: 网络转载 | 来源: 领测软件测试网 | 查看: 0次 | 进入软件测试论坛讨论

如果你爱她，就把她送到纽约，因为它是天堂；
如果你恨她，就把她送到纽约，因为它是地狱。
如果你爱她，她打你一个嘴巴，你会说：乖乖，打是亲啊！
如果你烦她，她给你挠挠痒痒，你会说，讨厌，烦着呢！
如果你爱她，她瘦，你会说她苗条，苗条的有点病态美；她胖，你会说她得体，富
态的有福相。
如果你厌她，她瘦，你会说她瘦骨嶙峋，象根火柴棍；她胖，你会说她腰肥体阔，
象个大赤包。
如果你爱它（ISO9000），你会说，搞和不搞大不一样，过和不过大不一样，过了
9000，员工的精神面貌不同了，企业的形象不同了，沟通更容易了，管理更顺畅
了，质量和信誉都有保障了，太好了！
如果你对它有了偏见，你会说，太烦了，太繁了。
不管怎样，纽约，你还爱着，你更多地想，她是天堂。因为，那里是世界贸易的中
心，机会多多。人生能有几回搏？
不管怎样，太太，你仍爱着，你更多地想，她已陪你走过的风风雨雨，来日方长，
你们还将一起走过！
不管怎样，ISO9000，你要爱它，你要去想，它已成功了太多太多……
成功的人，会告诉你怎样走向成功；
失败的人，更多地给你失意和彷徨……
ISO9000，是一个文化的缩影。
西方文化在工业文明的时代崛起，不容忽视。
这也是老祖宗教给我们的生产力生产关系之辩证关系的一个诠释。
在西方语言里，回答一般疑问句，只有“YES”或者“NO”；
在东方语言里，回答一般疑问句，更多地使用“还行”、“凑乎”、“差不
多”……
为什么从美国走出了麦当劳？
我们曾不无讥讽地说：鬼佬的厨房里还用量杯和温度计！
就是量杯和温度计造就了世界级的企业和品牌！
我们不用量杯，我们不用温度计，
大厨走了，就要更换口味。
我们的IT企业，
又何尝不是如此相似？
中国的软件企业，
老总怕总工，
总工怕程序员，
已经是一个普遍的现实。
ISO9000是中国IT的救命草。
让扭曲的箭头拉直过来。
走路留下脚印，
知识不再私有，
沟通与协作成为制度。
ISO9000的准备过程，
就是一个BPR。
老板是痛苦的，员工是痛苦的，
本来就已经忙不迭的你还要接受“医生”从里到外的检查，
更痛苦的是
不符合“9000”的就要坚决地改过来，
不容妥协。
改革是伟大的，是痛苦的，
自己苦心经营的自以为高明的一条条制度，一款款规范，
在经过一次深刻的审查之后，就要变成历史，
我们正在实践“扬弃”！
没有否定怎么能有提高？
如果没有改变就轻松拿到“9000”，
那“9000”也就真的成了“狗皮膏药”，
要它何用？
追求客户满意，
是ISO9000的中心；
持续改进，
是ISO9000的手段。
ISO9000的实施，
需要每一个参与者的决心和信心，
需要每一个人的真正重视。
ISO9000其实很简单，
说你所做，
写你所说，
做你所写。
ISO9000，
愈爱愈顺，愈烦愈累。

大家在开展配置工作,尤其是公司中刚刚准备开展配置工作时.肯定会有许多人会有疑问,配置管理到底能起到什么作用.

　　以下是缺乏配置管理造成的常见问题,大家可以作为参考.这些方面也可以作为配置工作开展的方向.
　　由于缺乏必要的配置管理流程和工具，很多软件企业在日常的开发工作中都会或多或少的遇到如下的问题：

　　 组织的知识和过程财富流失

　　现代的社会竞争激烈，人员流动频繁，如果由于没有必要的配置管理流程和工具，大量的文档和代码等知识财富必然缺乏统一的管理，可能随意地保存在项目经理和软件工程师各自的机器里，往往会因为硬盘的故障或人员的离职而永远的消失，软件组织的数字财富就这样因为缺乏必要的配置管理而白白的流失。
　
　　 不能及时了解项目的进展状况

　　现代软件工程思想认为越早发现缺陷和风险，采取相应措施的代价越小。CMM 的一个重要作用就是要提高软件开发过程中的可视性，使得问题能够被及时的发现。然而由于缺乏配置管理的流程和工具的支持，部门主管无法确切得知项目的进展情况，即便是项目经理也不知道各个开发人员的具体工作，项目进展随意性很大。所有的问题往往都会集中到项目里程碑时一起出现，这必然会造成巨大的开销，其结果往往是容忍部分缺陷存在或者延误开发周期。所有问题只能寄希望于最终实施时再解决，项目的实施工作因此变成了无法汇报、无法理清、无休止的维护。

　　  缺乏实现并行开发的手段

　　在日常的开发工作中，经常会出现并行开发的需求，比如：对于一个项目可能要在开发新版本的同时继续对先前的版本进行必要的维护，或者针对某个特定的版本需要针对不同的客户同时进行客户化的修改等等。在并行模式下，不同开发人员可以同时编辑修改某一文件，并行开发有可能产生冲突，但是却能够提高开发效率。如果没有配置管理工具的支持，进行并行开发将十分困难，单单通过人工操作，往往会造成修改过的bug 重复出现或者几个人进行相同的工作，产生不必要的浪费。
　软件复用率低下

　　软件复用是现代软件工程中的重要思想，是提高软件产品生产效率和质量的重要手段。软件产品是一个公司的宝贵财富，代码的可重用性是相当高的，如何建好知识库，用好知识库将对公司优质高效开发产品产生重大的影响。但如果没有良好的配置管理流程，软件复用的效率将大打折扣，比如对于复用的代码进行了必要的修改或改进，却只能通过手工的方式将发生的变更传递给所有复用该软件的项目，效率如何可想而知。另外由于缺乏进行沟通的必要手段，各个开发人员各自为政，编写的代码不仅风格迥异，而且编码和设计脱节，往往会导致开发大量重复的难以维护的代码。

　　无法开展规范化的测试工作

　　在传统的开发方式中，由于缺乏必要的配置管理和变更控制，测试工作只是人们的一种主观愿望，根本无法提出具体的测试要求，加之开发人员的遮丑，测试工作往往是走走过场，测试结果既无法考核又无法量化，当然就无法对以后的开发工作起指导作用。

　　对软件版本的发布缺乏有效的管理

　　因为缺乏有效的管理手段，往往会在产品发布时却无法确定该版本所有的组件，或者向用户提供了错误的版本。对于特定客户出现的问题，无法重现其使用的版本，只能到用户的现场才能进行相应的调试工作。由于应用软件的特点，各个不同的客户会有不同的要求，开发人员要手工地保持多份不同的拷贝，即使是相同的问题，但由于在不同 地方提出，由不同人解决，其做法也不尽相同，程序的可维护性越来越差。这些都会延长实施的周期，同时意味着人力物力的浪费。

　　 缺乏历史数据的积累，没有软件开发的历史数据

　　缺乏软件开发的历史数据是大多数软件项目失败的关键所在，这样的结论也许使很多人感到吃惊，但事实就是如此。因为软件开发的历史数据是反映软件开发队伍的能力的标尺，没有了这个标尺，就无法对软件的开发过程有一个清醒的认识。而良好的配置管理正是收集软件开发历史数据的重要来源。

　　 无法有效的管理和跟踪变更

　　软件的一个显著特点就是易于改变，没有配置管理将无法对软件的变更进行有效的记录、跟踪和控制。

软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：

　　需求的描述问题

　　笔者曾经被紧急委派主管一个已经进入了编码后期阶段的项目，该项目已经换过2次项目经理了，这是第3次更换项目经理，用户方的IT部经理找笔者抱怨："我已经是第3次来给你们讲补货申请的处理规则了!"。我只能表示抱歉，因为我无法找到原来的需求描述，这是一个变更的需求，前任的项目经理讲他只是将当时与用户交流的需求记到2页草稿纸上，不幸的是，那2页珍贵的手稿现在已经找不到了!更不幸的是，该IT部经理是在转述业务部门的需求，当软件开发完毕后，业务部门讲"这不是我们最初给IT部反映的需求，我们说的不是这样的!"。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。曾经有多个项目经理向我抱怨，在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户(用户)关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。

　　需求的完备程度问题

　　需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。

　　需求开发的工期问题

　　在需求上花费了大量的时间(而不是人*工时，因为需求阶段人多了也没有作用)，客户、软件公司是否能够忍受?为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。

　　需求的细致程度问题

　　需求到底描述到多细，才算可以结束了?仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家(客户、用户、需求分析人员、设计人员、测试人员)认为描述清楚了，就可以进入设计阶段了。

　　需求的变化问题

　　在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。

　　需求变化的原因很多，如：

　　一开始没有识别全，需要增加需求;

　　业务发生了变化，需求必须变化;

　　需求错误;

　　需求不清楚;

　　需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。

　　难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是"项目需求的渐变"(Project Scope Creep)问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。 控制需求渐变需要注意以下几点：

　　(1)需求一定要与投入有显示的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

　　(2)需求的变更要经过出资者的认可，需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量?quot;小"的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。

　　(3)小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。

　　(4)精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。

　　注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更"精致"，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。

　　软件需求的复用问题

　　笔者曾经遇到过一位领域专家，他在有20多年的领域工程经验，积累了大量的领域需求，可是在其每进行一次产品开发时，他总是感到他所理解的需求无法为与他配合的分析人员、设计人员所接受。当我们一起来讨论这个问题的时候，共同的一个观点就是：没有对需求进行有效的管理，已经形成的需求文档没有很好的复用。所以需求管理一个很重要的目标应是提高软件需求的复用率。

　　基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用。

考虑时间Thinking Time指的是在性能测试脚本中，事务与事务之间，会有一些短暂的停顿，就好像真实用户在操作时，两次操作之间需要考虑一下。比如用户注册的时候，在打开注册页面到提交注册页面之间，是有一段考虑时间的（用户在填写个人信息）。
 
        下面就讨论一下在性能测试实战中，为什么要设置考虑时间。
 
        先说一个概念：吞吐量，这指的是服务器系统（包括软件和硬件）单位时间内处理业务的数量。我们现在做一个小试验，写一个小程序，执行一个简单的业务，并且在程序中进行计时，计算每分钟能执行多少次。然后当我们运行1路这个程序的时候，每分钟能完成约6万次。好，现在问一个问题，如果我们起2路，是不是每一路都能达到 6万/分钟 的吞吐量？
 
        试验发现，当运行2路的时候，两个程序的数值都降了下来，但是它们的总和仍然是6万次。而且不管我们起多少路，这些程序的性能总和都接近于6万。
 
        这就好像一个人1分钟最快能吃1个馒头，你让他一个一个吃，他两分钟能吃2个，如果你让他一手拿一个，同时吃，他两分钟吃不了4个，还是只能吃两个。
 
        我们不是在说“考虑时间”么，哈哈，别急，因为上面的问题必须要先说清楚。
 
        如果我们需要进行性能测试的业务是一个单纯的业务，就好像上面举的那个例子一样，那么测试脚本中就不需要设置“考虑时间”，因为不管你用什么方法测试，一个服务系统处理单一业务的吞吐量总是一个定值。
 
        但是在实际环境里面，往往一个系统都是要处理多种业务，并且这些业务之间是有逻辑关系的。举例说明，比如一个论坛系统，每天最常处理的业务有两个：A打开帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢，答案很明显，看帖子多，回复的少一些。假设A:B=2:1。
 
        好，如果我们不设置考虑时间，起2路A的脚本，1路B的脚本进行性能测试，我们会得到什么结果呢？我们会得到这两个业务的吞吐量，并且能算出每个小时系统完成A、B业务的总数，吞吐量 × 时间 ＝ 总数。
 
        这时我们发现，同样时间，AB业务的处理总数却不是2:1的关系，这是为什么呢？原因是这样的，我们在跑AB脚本的时候，这两组脚本都在尽全力争夺服务器的资源，他们的并发路数虽然是2:1，但是给服务器的压力却不一定是2:1，可能会出现偏差，测试结果就是最好的证据。A查看帖子由于响应时间短，因此跑的次数更多，最后的比例可能是4:1。
 
        那么这样的结果有什么问题呢。总结为一句话：测试环境的业务和真实环境不符，这样测出的数据没有价值。即使测试通过，也不能证明真实环境是ok的；或者即使测试不通过，也不能说明真实环境不ok，呵呵。
 
        比如上面的例子，如果我们测出的结果是B回复帖子的吞吐量不够，响应时间太长，那可能是因为A业务抢走了过多的，本不属于A的资源，而引起了B的性能降低。
 
        说到这里，大家应该明白了，我们设置考虑时间，是为了保证测试复合业务的时候，各个业务之间的比例关系符合我们的真实生产环境。
软件测试技术: 软件测试工程师　测试用例　功能测试　测试管理　缺陷管理　手机测试　自动测试　单元测试　性能测试　安全测试 软件测试环境: Windows　Unix　网络知识　服务器 开源测试:开源功能测试　开源性能测试　开源缺陷管理　开源配置管理　开源解决方案　测试开发: JAVA　.net　UML　脚本语言　数据库　中间件　测试资料: 商业测试工具　开源测试工具　软件测试教程 质量保证: 项目管理　需求管理　软件度量　项目估算　质量模型　解决方案 测试工具: Mercury测试工具 Rational测试工具 Segue测试工具 其它

测试工具近来在测试人员间刮起了一阵旋风，在我们群内也不可避免地掀起了一阵工具热。我不是支持无工具测试者，因为这是一种愚蠢行为。但对当前出现的厚此薄彼思想，说说我对测试基础与测试工具的认知。在此诚邀各路英雄过来参与讨论与拍砖。最理想的目的是让我们对正确测试有一个不会偏离得太远的认知。
　　有不少测试员目前把测试工具与测试思想的学习分为两个相反方向，重视工具的使用学习而忽略了测试思想的煅练。这不利于测试能力的提升，提高我们的测试技能，如仅仅是工具的使用，就好巧妇难为无米之炊，而这“米”指的是测试思想。
　　测试工具只是一个辅助工具，帮助我们进行一些手工测试不能完成的测试内容，但它不能替代测试思维。该测什么，要怎么测还是要以测试思想为基础，然后才是借用工具帮我们实现。就算我们精通Rational、Mercury等一系列的工具，如果心中没有测试用例，我们也不知对着一个需要测试的软件，要对它进行怎样的测试项，作为一个测试人员，我们不应当只是一个执行者，更应该是一个设计者，怎样设计一个合理有效的用例去完成对产品质量的控制，在这个基础上才是怎样去达到对这个产品质量的检验。而测试用例，是测试思想的集中体现。先煅练思想再在此基础上进行使用辅助工具的提升，我们的测试才能做得更好。这也不是说一定要有了测试思想再学习工具，因为思维与工具都是测试的技能点，最好是一并重视，把测试思维的学习与测试工具的学习调至一个方向。
　　如果把测试比喻成树的话,那么测试基础是主干,工具是支干和叶子,支干和叶子的茂盛使树显得更强盛,但如果少了主干的支撑,支干也就无扬展的空间
　　后来想想，新接触测试的许多同行比较工具的学习，很多是由于现在招聘企业的对测试工具要求比对测试思维要求更多对测试行业产生的误导。
　　测试员本身对测试基础与测试工具的偏重度问题，希望能分层次讨论测试所有知识与技术，此举是希望能给新接触这个行业并且不太了解这个行业的同行们一个循序渐进的讨论主题，利于测试发展。
　　另外测试技能的煅练不仅仅是思维与工具，还包括行业知识，因为大多数测试员从事的都是针对某一行业的产品，对所属行业有了了解，我们的测试才更有针对性
　　下面是我当时的回复
　　从必要性上来看，如果有测试工具是不是所有的软件都能测试？反过来如果有测试思想是不是能进行所有软件测试？从覆盖率来看，相信有测试思想的测试范围要广些。
　　举个例子，比如做手术，你会各种工具的使用，一定就知道什么时候该用哪种工具吗？呵呵， 想来都是思想来指导我们行动的。
　　实际软件测试中比如测试photoshop这款软件，想来用工具的机会就不大，很多都是业务应用和逻辑思维方面的测试，测试时候是跟开发基本同步的，出一版本就进行测试，同时对上一版本进行返测。界面、功能不断变化，使用工具的机会真的很少。
　　另外具备行业知识和操作技能的非常受重视，促使我们去学习和研究。但是这些知识和经验不是单单在IT领域所能获得的，那么我们要接触的社会将需要更加全面和立体（相对开发人员），希望不要陷入为测试而测试的境界。

随着测试流程的不断规范以及技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本 期所要讨论的话题。　　目前，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化(如单元测试、以及方面)。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率; 其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测试中尤其具有意义; 此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据Oppenheimer Funds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。
　　方案选型六大原则
　　然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢?也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台; 或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。
　　以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议:
　　● 选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本;
　　● 测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求;
　　● 在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑;
　　● 在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性;
　　● 尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;
　　● 应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。
　　实战模拟
　　以下笔者结合一个典型的企业客户，剖析其适用的软件测试自动化方案选型过程。
　　1.公司背景介绍
　　A公司是一家大型保险公司，拥有近20个城市的分公司，并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右(新业务系统和原有业务系统的主要版本发布)。目前A公司的专职测试团队人数不足30人，而且测试团队的测试人员技能参差不齐，目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段，主要依靠手工测试。由于已上线应用系统的问题，开发团队必须分出一部分资源去维护和修复上线应用，而同时测试团队的测试成果和效率却无法和这些应用质量挂钩，也更无从谈起对软件质量的控制。所以，A公司决定在软件质量和测试方面进行投入，他们考虑以下几方面:
　　● 引进软件测试流程管理的自动化，提高软件测试过程的管理水平，使软件测试和软件开发一样可被评估、被衡量。
　　● 实现性能测试自动化，所有应用上线之前必须有应用性能风险评估报告和相关部门的确认
　　● 逐步实现功能测试的自动化，在目前人员配置的情况下，把部分手工测试变成自动化测试，提高测试可信度，降低人为错误。
　　● 通过软件测试自动化，管理软件测试中的案例、缺陷、报告等资产，进一步提升软件测试的效率并建立测试基础库。
　　● 在规划中，将来的2～3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。
　　2.公司应用系统的情况
　　由于保险公司的业务种类繁多，同时在经过了几十年的经营后，公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有，鱼龙混杂。IT部门已经建立的3年规划，即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构，但当前仍然需要对这些旧应用系统进行维护，以保证业务的顺利进行。对于开发部门来说，目前新应用开发基本上已经以B/S架构为主，主要是基于J2EE架构的Web HTTP应用和部分Window.NET Form的应用。
　　3.公司软件测试现状
　　企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定，缺乏实事求是的理性思考。
　　测试部门目前仅负责系统测试和对用户验证测试进行管理，对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段，测试部门也无法收集和确定集成测试和单元测试的完成情况，在整个软件测试过程中，业务需求是由开发部门通过Rational RequisitePro进行管理，但测试需求目前尚没有提出要求，测试案例主要通过在公司公用的文件服务器中的目录管理方式管理，对测试中缺陷流程等管理主要依靠邮件的流转进行处理。目前90%以上的测试是通过Excel和Word等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在“记录+回放”的认识上。
　　4.可供选择的方案
　　方案A: A公司可以采用美科利(Mercury)公司产品为主的软件测试自动化方案。
　　● 依照原先的邮件流转过程配置TestDirector缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，取消原有邮件方式。
　　● 部署Mercury Quick Test Professional，以便完成应用程序相关功能测试。
　　● 部署Mercury Load-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组，和业务部门协调，建立A公司应用系统上线性能指标，通过LoadRunner给出测试指标。
　　● 建议A公司成立专门的质量控制部门，对TestDirector中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
　　方案B: A公司也可以采用IBM Rational产品为主的软件测试自动化方案。
　　● 采用Rational Test manager来进行整个测试流程的管理，为相关开发和测试小组成员分配相应权限，改变以前通过邮件以及Word、Excel文档管理测试的工作方式。
　　● 部署Rational Robot，用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外，Rational Robot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。
　　● 部署Rational Purify plus，使测试工作前移到开发阶段。由于Purify plus能较好地支持白盒测试，编程人员在编码阶段引入的错误能尽早被检测到，这大幅降低了后期测试的开销。
　　● 建议A公司成立专门的质量控制部门，对Test manager中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
　　方案C: A公司也可以采用开源软件为主的软件测试自动化方案。
　　● 采用Bugzilla来进行Bug跟踪管理，采用Bugzilla Test Runner进行测试用例管理，采用CVS进行测试资源的配置管理。
　　● 采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。
　　● 采用DBMonster、Open-STA、LoadSim进行性能相关测试。
　　● 可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。
　　● 建议A公司成立专门的开源软件维护小组，以解决可能会碰到的工具维护工作。
　　● 建议A公司成立专门的质量控制部门，对Bugzilla、Test Runner、CVS中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
　　5. 方案评价
　　由于不同客户在组织架构、员工素质以及流程管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性。在上面的例子中，笔者给出了3种可行的方案，具体选择哪一个，需要仔细权衡。这里笔者给出一般性的意见，对于不想受制于某个测试自动化厂家的企业，开源绝对是一个理想的选择。此外，它不需要支付成本，工具的源代码可以随意修改，因而具有较好的灵活性。但开源工具的弊端也是明显的: 缺乏使用培训和技术支持，工具的用户界面一般也较为粗糙。而对于那些比较看重培训和售后支持的企业，笔者建议选择IBM Rational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。
　　实施中的注意事项
　　首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100%的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、Oracle ERP等测试库规划十分完善的套件，其测试自动化率也不会超过70%。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。性能测试功能测试软件测试

摘要：入侵检测系统（Intrusion Detection System，简称IDS），顾名思义，是对入侵行为的检测。它通过收集和分析计算机网络或计算机系统中若干关键点的信息，检查网络或系统中是否存在违反安全策略的行为和被攻击的迹象。本文将对IDS性能测试的几项指标和测试流程进行阐述，同时介绍一个入侵检测漏报率测试的实例。使用的测试工具是IXIA公司的IXIA400T，软件为IXExplorer。

1  IDS性能指标

        入侵检测系统（Intrusion Detection System，简称IDS），顾名思义，是对入侵行为的检测。它通过收集和分析计算机网络或计算机系统中若干关键点的信息，检查网络或系统中是否存在违反安全策略的行为和被攻击的迹象，它是网络安全防护体系的重要组成部分。要全面考察IDS产品，除了功能、易用性等考察外，性能测试是考察IDS产品的重要指标之一。IDS的性能测试指标可以分为两类：面向用户和面向开发。

（1）面向用户的指标

        面向用户的性能指标主要考察IDS产品工作性能状况，主要包括：

●漏报率：系统在检测时出现漏报的概率。漏报：系统未能识别出入侵行为，将其作为正常行为放过。

●误报率：系统在检测时出现误报的概率。误报包括将正常行为判断为攻击而产生报警；将一种攻击错误的判断为另一种攻击而报警。

●事件库：也叫特征库。系统能够匹配检测的攻击种类数量的大小，能够横向体现系统检测能力。

●延迟时间：从攻击发生到系统检测到攻击的时间。延迟时间的长短直接关系到攻击破坏的程度。

●资源占用：系统工作时对资源的消耗情况。

●自身安全性：又称健壮性。系统对直接以自身为攻击目标的攻击的抵抗能力。

（2）面向开发的指标

        除面向用户的性能指标外，IDS产品还有一些面向开发的性能指标，虽然这些指标不为用户了解，但这些指标也甚为重要，主要包括：

●每秒数据流量：每秒数据流量是指网络上每秒通过某节点的数据量。这个指标是考察系统性能的重要指标，一般用Mbit/s来衡量。流量越大，对IDS系统的压力就会越大。

●每秒抓包数：每秒抓包数是指网络传感器每秒能够捕获的包数。反映网络入侵检测系统网络嗅探器性能的重要的指标。抓包数越大，产生漏报率的可能性就越小。

●每秒能监控的网络连接数：网络连接的跟踪能力和数据包的重组能力是网络入侵检测系统进行协议分析、应用层入侵分析的基础。

●每秒能够处理的事件数：每秒能够处理的事件数，反映了检测分析引擎的处理能力和事件日志记录的后端处理能力。

2  IDS性能测试要点

2.1  测试流程

        知己知彼，百战不殆。做性能测试也是一样。我们不能拿到一个设备，就急急忙忙的开始搭环境，开始测试。没有严格的计划，没有周全的布置，是不可能完成一项测试任务的。根据实际工作经验，我们总结了图1的流程图。下面将针对该流程中的几个重点部分进行一些阐述。

2.2  测试环境

        测试环境的搭建是测试部署中较为重要的部分，它直接影响测试结果的准确性。为了使测试处于可控状态，避免更多的外部因素干扰测试结果的分析，在进行IDS性能测试时需要搭建一个封闭的网络环境。图2是我们进行鹰眼网络入侵检测系统产品面向用户的漏报率性能指标测试的环境图。需要注意的是，该拓扑图只是较通用的一个，在实际使用中，根据测试指标的不同，可能会有不同的测试环境部署。