8.1 VuGen  软件测试工具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测试工具 其它

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

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

　　现代软件工程思想认为越早发现缺陷和风险，采取相应措施的代价越小。CMM 的一个重要作用就是要提高软件开发过程中的可视性，使得问题能够被及时的发现。然而由于缺乏配置管理的流程和工具的支持，部门主管无法确切得知项目的进展情况，即便是项目经理也不]]> 大家在开展配置工作,尤其是公司中刚刚准备开展配置工作时.肯定会有许多人会有疑问,配置管理到底能起到什么作用.

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

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

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

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

　　  缺乏实现并行开发的手段

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

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

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

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

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

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

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

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

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

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

　　需求的描述问题

　　笔者曾经被紧急委派主管一个已经进入了编码后期阶段的项目，该项目已经换过2次项目经理了，这是第3次更换项目经理，用户方的IT部经理找笔者抱怨："我已经是第3次来给你们讲补货申请的处理规则了!"。我只能表示抱歉，因为我无法找到原来的需求描述，这是一个变更的需求，前任的项目经理讲他只是将当时与用户交流的需求记到2页草稿纸上，不幸的是，那2页珍贵的手稿现在已经找不到了!更不幸的是，该IT部经理是在转述业务部门的需求，当软件开发完毕后，业务部门讲"这不是我们最初给IT部反映的需求，我们说的不是这样的!"。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。曾经有多个项目经理向我抱怨，在用户方进行的需求评审会完全是走形式]]> 软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：

　　需求的描述问题

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

　　需求的完备程度问题

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

　　需求开发的工期问题

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

　　需求的细致程度问题

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

　　需求的变化问题

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

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

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

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

　　需求错误;

　　需求不清楚;

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

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

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

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

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

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

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

　　软件需求的复用问题

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

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