1. 如果条件中有or，即使其中有部分条件带索引也不会使用。要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引（出现索引合并的话可能性能理差）。
2. 组合索引，要符合最左前缀才会应用。
3. like查询是以%开头不会应用索引。
4. where 子句里对索引列上有数学运算，用不上索引。
5. where 子句里对有索引列使用函数，用不上索引。
6. 如果mysql估计使用全表扫描要比使用索引快,则不使用索引。如查询的数量是大表的大部分，应该是30％以上；或是小表。
7. 统计数据不真实，需要用analyze收集统计信息
8. 隐式转换导致索引失效，也是开发中经常会犯的错误。由于表的字段tu_mdn定义为varchar2(20)，但在查询时把该字段作为number类型以where条件传给数据库，这样会导致索引失效.
9. not in ,not exist可能不会用索引，参数6。
10. B-tree索引 is null不走索引（is not null会走,位图索引 is null,is not null 则都会走索引）

Dim Conn

Dim Rst

set Conn=CreateObject("Adodb.Connection")
Conn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=E:\Work\test\result\gdkkx\运行数据查询\运行数据查询.mdb"
Set Rst=CreateObject("Adodb.RecordSet")

Rst.Open "Select * from Result",Conn

Do while not Rst.EOF:
  scenario  = Rst.Fields("Scenario Name").Value
  name      = Rst.Fields("Result Name").Value
  tz        = Rst.Fields("Time Zone").Value / 3600
  startTime = Rst.Fields("Start Time").Value
  endTime   = Rst.Fields("Result End Time").Value
  Rst.MoveNext

Loop

Wscript.Echo " "
Wscript.Echo "  Scenario: %s " & scenario
Wscript.Echo "    Run ID: %s " &  name
Wscript.Echo "        TZ: %s " &  tz
Wscript.Echo "Start Time: %s " &  time.asctime(time.localtime(startTime))
Wscript.Echo "  End Time: %s " &  time.asctime(time.localtime(endTime))

公司名称：广州粤能电力科技开发有限公司

    本公司主要面向广东电网和南方电网开展业务，现有员工300多人，业务量充沛，

福利待遇稳定有保障（五险一金齐全，有项目提成等激励机制），发展前景较好。

工作内容：软件功能和性能测试

联系人：梁先生

QQ:164685500(注明：应聘）

座机：020-85124034

邮箱：liangzhihong1984@126.com

岗位描述：

岗位一
岗位名称：高级软件测试工程师（2人）

学历要求：大学本科或以上学历 ；

岗位描述：

1、参与软件产品的需求分析，负责测试计划与测试方案制定；
2、带领其他测试工程师执行项目测试；
3、执行软件产品的性能测试和分析，预测系统性能瓶颈，风险和安全隐患；

岗位要求 ：

1、计算机相关专业，本科或以上学历；3年以上软件性能测试工作经验； 
2、有担当软件性能测试项目负责人经验者优先；
3、精通测试用例设计，掌握系统性能测试方法；
4、精通相关测试工具（Winrunner、LoadRunner、SilkPerformer ）
5、精通QC或相关测试以及缺陷管理工具 
6、具有良好的沟通能力和较强的分析和总结软件问题的能力
7、有开发经验者优先考虑


岗位二
岗位名称：软件测试工程师（4人）

学历要求：大学本科或以上学历 ；

岗位描述：

1、参与软件产品的需求分析，负责测试计划与测试方案制定；
2、执行项目测试；
3、执行软件产品的性能测试和分析，预测系统性能瓶颈，风险和安全隐患；

岗位要求 ：

1、计算机相关专业，本科或以上学历；
2、掌握测试用例设计，掌握系统性能测试方法；
3、掌握相关测试工具（Winrunner、LoadRunner、SilkPerformer ）；
4、熟悉Oracle,SQL Server和DB2数据库中的一种或多种；
4、掌握QC或相关测试以及缺陷管理工具； 
5、具有良好的沟通能力和分析总结软件问题的能力、有开发经验者优先考虑

   通常在一般的中小企业中会不将软件测试与软件质量保证加以细分，软件测试人员也叫做质量保证人员即QA，我所在公司也是如此。其实软件测试与软件质量保证是软件质量工程的两人不同层面的工作。
    质量保证（QA）是通过预防，检查与改进来保证软件质量的。QA所关注的是软件质量的检查和测量，他的工作是软件生命周期的管理以及验证软件是否满足质量和用户需求，主要着眼于软件开发活动中的过程、步骤和产物，而不对软件进行剖析找出问题。一般情况下，QA应独立于项目之外，以第三方的姿态来对整个开发过程进行评审，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品

是否遵循模板规定的内容和格式。所以，质量保证是通过过程改进来保证软件质量的。
    软件测试关注的不是过程活动，而是每个过程活动的产出物。它对活动的产物进行剖析，检测以期发现更多的问题，从而保证软件质量。所以软件测试是保证软件质量的一个重要环节，但不是质量保证的一个环节。
    对软件测试与软件质量保证进行区分并不是闲聊而咬文嚼字，而是要知道他们都是为了保证软件质量的两个不同层面的工作，他们对保证软件质量有着不可替代的作用。但现实中大部分中小企业都只知道软件测试而没有专门的质量保证，即使有也是虚设，其实这是本末倒置。软件测试只是项目中的一个流程或是环节，只是对个别项目。所以个别项目如果取得成功，质量得到了很好的保证，可能是因为项目的个别因素，如项目需要做得较好或是测试人员水平较高等个别因素。所以一个项目做得好不能保证别的项目也做得好，即是公司的开发水平，产品的质量水平能够提高。这就需要通过质量保证来提取成功的因素而上升到流程规范上来规范所有项目，从而提高公司产品质量水平。一个公司的好的管理标准就是有个好的规章流程得以执行，所以一个好的项目管理，质量保证也在于规章流程，这些也是共性的东西，才不会以项目中的个别因素改变而改变。当然，也并不是说有好的质量保证就有好的产品质量，他们之间不是充分的关系，而是必要。
    所以软件测试与软件质量保证是两个保证软件质量的重要手段，套些初中教科书上的话，他们的关系就是相互区别，相互联系，相互依存。

 

    selenium ThoughtWorks专门为Web应用开发的自动化测试工具,适合用于功能测试与验收测试.也是近年来较为流行的开源测试工具.selenium这一强大的Web测试工具主要由selenium IDE, selenium core, selenium Remote Control 及selenium Grid组成. 其中selenium RC 应用较为广泛亦算是功能最为强大的一个,通常它会与其它工具结合起来使用以更好地发挥其强大功能.现介绍构建工具Ant与selenium结合用于测试java应用项目.Ant+selenium可以构建测试build,然后部署到相应的测试环境中,再编译执行生成测试报告,最后通过邮件发送测试报告.
    对selenium 和ant 有所了解的同行应该看得出这个应用主要是使用Ant来构建版本,然后部署到测试环境中去,再然后执行测试脚本到生成发送测试报告.即是使用Ant这个强大的构建部署工具帮我们做那些外围的工作,使测试跟开发完美结合,让selenium 自动化测试应用完全自动化.所以这个应用主要是Ant的应用.
    介绍下我当时使用情况.当时一个项目中使用selenium RC来做自动化测试,主要是冒烟测试跟回归测试.我们测试所用的build是在香港开发部门每天使用Bamboo持续构建的,所以我们必须用Ant通过网络从上面拿相应的build下来,修改相应的配置文件,然后部署到相应的测试环境中去. 部署好测试系统后,我们就可以通过Ant编译运行我们的测试脚本(用java写的selenium RC 脚本).运行完成后用Ant自带的方法来生成测试报告，最后还是能过Ant以邮件发送报告．所以，我们只需要用鼠标点一下,甚至不用点而用其它工具每天自动执行.
   当然这也并不是什么很高明的应用,但借助Ant强大功能,使用selenium自动化测试做得更为彻底,将测试各个步骤很好地连接起来,当然带来更高效率.这个应用主要就是Ant的使用,难点也在Ant的使用,因为其中涉及到不少的Ant tasks.不过它官网上都有详细的使用介绍:http://ant.apache.org/manual/index.html. 现贴出我之前使用的ant build 文件,有兴趣的同行可以参考下.

<?xml version="1.0"?>
<project name="camp-testuff" default="main">
 <!-- properies -->
 <property file="./resources/build.properties" />

 <!-- 定义classpath -->
 <path id="master-classpath">
  <fileset file="${lib.dir}/*.jar"/>
  <pathelement path="${classes.dir}" />
  <pathelement path="${resources.dir}" />
  <pathelement path="${src.dir}" />
 </path>

 <!-- 初始化任务 -->
 <target name="init">
  <java jar="${selenimhome}/selenium-server.jar" fork="true" spawn="true" />
 </target>

 <!--下载更新build-->
 <target name="download" if="isdowload">
  <get src="${targeturl}" dest="${filePath.dir}/${filename}" verbose="true" usetimestamp="true" />
 </target>

 <!--更新编绎war文件-->
 <target name="war" depends="download">
  <unwar src="${filePath.dir}/${filename}" dest="${filePath.dir}/project" />
  <propertyfile file="${filePath.dir}/project/WEB-INF/classes/jdbc.properties" comment="My properties">
   <entry key="jdbc.url" value="${jdbc.url}" />
   <entry key="jdbc.username" value="${jdbc.username}" />
   <entry key="jdbc.password" value="${jdbc.password}" />
  </propertyfile>
 
  <propertyfile file="${filePath.dir}/project/WEB-INF/classes/systemConfiguration.properties" comment="My properties">
   <entry key="mail.host" value="${mail.host}" />
  </propertyfile>

  <war destfile="${filePath.dir}/${projectfile}" needxmlfile="false">
   <fileset dir="${filePath.dir}/project" includes="**/*.*" />
  </war>
 </target>

 <!-- 部署项目 -->
 <target name="deploy">
  <mkdir dir="${tomcatlog.dir}" />
  <mkdir dir="${tomcatconfig.dir}" />
  <taskdef resource="cargo.tasks">
   <classpath>
    <pathelement location="${cargo-uberjar}" />
    <pathelement location="${cargo-antjar}" />
   </classpath>
  </taskdef>

  <cargo containerId="tomcat5x" home="D:\tomcat" ōutput="${tomcatlog.dir}/output.log" log="${tomcatlog.dir}/cargo.log" action="start" failonerror="false" wait="false">
   <configuration home="${tomcatconfig.dir}">
    <property name="cargo.servlet.port" value="8080" />
    <property name="cargo.logging" value="high" />
    <property name="cargo.jvmargs" value="-Xmx500m"/>
    <deployable type="war" file="${filePath.dir}/${projectfile}" />
   </configuration>
  </cargo>
 </target>

 <!-- 编译脚本-->
 <target name="compile"  descrīption="compile the source files">
  <mkdir dir="${classes.dir}" />
  <javac srcdir="${src.dir}" failonerror="false" destdir="${classes.dir}">
   <include name="**/*.*" />
   <exclude name="**/*ViewCustomerTest.*" />
   <exclude name="**/*SubmittingMaintenanceApplicationTest.*" />
   <exclude name="**/*SubmittingMaintenanceApplicationTest.*" />
   <exclude name="**/*AddMaintenance.*" />
   <exclude name="**/*EditMaintenance.*" />
   <classpath refid="master-classpath" />
  </javac>
 </target>

 <!-- 测试 Junit脚本-->
 <target name="test" descrīption="run junit test">
  <tstamp>
   <format property="stratTime" pattern="MM/dd/yyyy  HH:mm:ss" />
  </tstamp>
  <mkdir dir="${report.dir}" />
  <junit printsummary="on" haltonfailure="false" failureproperty="tests.failed" showoutput="true">
   <classpath refid="master-classpath" />
   <formatter type="xml" />

   <batchtest todir="${report.dir}">
    <fileset dir="${src.dir}">
     <include name="${testname}" />
     <exclude name="**/*ViewCustomerTest.*"/>
     <exclude name="**/*SubmittingMaintenanceApplicationTest.*"/>
     <exclude name="**/*SubmittingMaintenanceApplicationTest.*"/>
     <exclude name="**/*AddMaintenance.*"/>
     <exclude name="**/*EditMaintenance.*"/>

    </fileset>
   </batchtest>
  </junit>
 </target>

  <!-- 生成报告 -->
 <target name="junitreport" depends="test">
  <mkdir dir="${report.dir}/html" />
  <junitreport todir="${report.dir}">
   <fileset dir="${report.dir}" includes="TEST-*.xml" />
   <report format="frames" todir="${report.dir}/html" />
  </junitreport>
 </target>

 <!-- 发送测试结果 -->
 <target name="SendEmail" depends="junitreport">
  <tstamp>
   <format property="endTime" pattern="MM/dd/yyyy HH:mm:ss " />
   <format property="endTime2" pattern="MM/dd/yyyy " />
   <format property="endTime3" pattern="yyyyMMddHHmmss " />
  </tstamp>
  <zip destfile="${report.dir}/html/Report.zip">
   <zipfileset dir="${report.dir}/html" includes="**/*.*" />
  </zip>
  <mail mailhost="${host}" messagemimetype="${messagetype}"
   mailport="${mailport}" subject="Test Report_${endTime3}"
   user="${user}" password="${password}" messagefile="${messagefile}"
   tolist="${tolist}" cclist="${cclist}">
   <from name="${fromname}" address="${fromaddress}" />
   <attachments>
    <fileset dir="${report.dir}/html">
     <include name="*Report.zip" />
    </fileset>
   </attachments>
  </mail>
 </target>

 <!-- 清除生成文件（报告） -->
 <target name="clean">
  <delete dir="${tomcatconfig.dir}" />
  <delete dir="${report.dir}" />
  <delete dir="${classes.dir}" />
  <delete file="${filePath.dir}/project.war" />
  <delete dir="${filePath.dir}/project" />
  <sql driver="org.gjt.mm.mysql.Driver"
      url="jdbc:mysql://${jdbc.urlAndPort}"
      userid="${jdbc.username}"
      password="${jdbc.password}"
      >
   drop schema ${jdbc.schema};
   <classpath location="${lib.dir}/mysql-connector-java-5.0.5.jar"/>
  </sql>
 </target>

 <!-- 测试完成关闭计算机 -->
 <target name="shutDown">
  <sleep minutes="2" />
  <exec executable="shutdown">
   <arg value="-s" />
  </exec>
 </target>

 <!-- Stop tomcat -->
 <target name="stoptomcat">
  <taskdef resource="cargo.tasks">
   <classpath>
    <pathelement location="${cargo-uberjar}" />
    <pathelement location="${cargo-antjar}" />
   </classpath>
  </taskdef>

  <cargo containerId="tomcat5x" home="D:\tomcat" action="stop">
   <configuration home="${tomcatconfig.dir}"/>
  </cargo>
 </target>

 <!-- 主要目标 -->
 <target name="main">
  <!-- 清理并初始化环境 -->
  <antcall target="clean" />
  <antcall target="init" />
  <!-- 部署项目 -->
  <antcall target="war" />
  <antcall target="deploy" />
  <!-- 编译脚本 -->
  <antcall target="compile" />
  <!-- 测试并发送报告 -->
  <antcall target="SendEmail" />
  <antcall target="stoptomcat" />
  <antcall target="shutDown" />
 </target>

</project>

 

Priority即是优先级,只要我们提到测试用例基本上都会涉及到,或许应该说是完整的测试用例的一个基本元素.但在现实应用中是否有对测试用例进行划分,是否真正有应用到?未必!相信大部分的同行都会对测试用例进行等级划分,但仍不少同行并未认识到其重要性而没有真正应用起来.
    优先级,对此我是感慨良深.春节前一个外包项目测试全面展开,项目还是比较大的,有测试用例接近3000个.拿到最新的测试用例一看,一个汗啊...我负责的接近1200个,有10多个是优先级为3的即是传说中的P3,似乎没有P2的,有也就是30个左右,其余全是P1的.一个关于用户名(注册邮箱地址)的验证如长度,允许输入字符等都设置为P1.更汗的是距离春节放假就6天了,说要春节前完成所有非P3的用例(因为开发在美国,他们没假期...).期间还不只是执行用例还要首先跟踪BUG.当然结果是推迟完成日期,可能是小学数学老师找他们谈心然后恍然大悟吧.可惜他们数学老师只会计数,不知所谓的优先级.测试效果是可想而知了,我们测试员要完成不可能完成的任务,心理感受是可想而知,效果肯定也打折扣;而开发方面收到的BUG大部分是验证不够完善或是一些较为琐碎的问题,而严重的BUG后面才发掘出来,整个项目进度受到相当大的影响.
    或许你会觉得我夸张了,如果不是亲身经历我也难以相信.这是一个十分失败的项目开发测试,而其中一个原因就是没有发挥优先级作用.在软件项目中,我们几乎没有足够的时间来做任何我们需要做的事情,特别是如果测试置于项目边缘的话就更不用谈了.相信同行刚接触测试时都应该听过80/20原理跟测试是不可能穷尽的,也正是因为这样,我们必须对测试用例进行优先级设置.只有对测试用例进行了优先级设置,并在执行测试时根据所处的测试生命周期跟项目进度的需要有所放矢的选择相应的测试用例进行测试,才能有更好的测试效果并保证整个项目的进度.
    那测试用例应该有哪些级别呢?没有明确的答案,这要根据项目所处的生命周期跟进度来决定.通常情况下我觉得设置3级已经足够.P1: 即是确保系统基本功能及主要功能的测试用例;P2则是确保系统功能的完善方面的测试用例;P3则是关于用户体验,输入输出的验证及其它较少使用或辅助功能的测试用例.根据所搜集的资料各优先级所占全部测试用例比例通常如下: P130%-45%,P240%-60%, P310%-15%.
    不少同行却总觉得不用测试用例一样测试,更不用谈用例优先级.这是非常错误的一个观点,省了那么点时间功夫换来的是更多的付出甚至是低劣的产品. 其实,对测试用例进行优先级的设置是最基本的,也是必须的.这并不是很需要技术或技巧的东西,但一旦很好地应用了它,却可收到丰厚的回报. 当然,对测试用例做了优先级的设置还必须能很方便地筛选出所要测试用例,能快速地筛选出某个模块,某个优先级的用例进行测试,这有赖于选择个好的测试管理工具.

   众所周知软件测试这个职业有一个为从业者不悦的一个特点就是有时特别烦琐,要经常做重复性的东西,相信同行或多或少都会有这个感慨,而罪魁祸首就是回归测试.如果每次测试的功能点都是新的,每次执行的测试用例都是未曾执行过的话,我相信同行都不会觉得厌烦反而很有兴致想看下新的功能是怎样的,执行起用例来也特认真.我也是如此,如果做久了一个项目特别是总是推迟发布的话每天就祈祷着当前项目快点了结.一接到新项目就有如获新生的感觉...确实回归测试次数多了,测试员不由变得烦躁起来,特别如果是回归测试策略又不妥当的话简直令人发疯....
   我深受其害.进新公司近半年来还没有完全是自己负责的项目,除了花了一定的时间做自动化方面的东西外,其它的时间就是执行测试用例了,当然也就有大量的回归测试了.更郁闷的是没有相应的回归测试策略,而且不少测试用例已经不再适用了,数量又多(以前新功能测试的用例),我逐渐变得厌烦,然后是麻木,最后几近崩溃.一个汗啊...痛苦泥潭中的只好搜索相关资料并结合自己的实践,总结下如何更有效地做回归测试,让回归测试做得更有意义.
   所谓回归测试就是当软件发生改变时,重新测试已经通过测试的测试区域,以验证修改的正确性及其影响.其实我们做测试的大部分工作也是在做回归测试,严格按照定义的话一旦软件作了修改就必须进行回归测试.我想对修改过后的软件要进行回归测试应该就是无可厚非的,无论是教科书上的介绍还是前人的经验总结都知道回归测试的必要性与重要性.那非要做回归测试,那样怎样才能做得更为有效有意义呢?显然这都需要从测试用例着手.
   首先我们必须有个管理良好的测试用例库,这个用例库中的所有用例必须是有效的,有达到足够的覆盖率,并且是容易查找组织的.这需要有良好的测试管理工具,并有相应的资源(时间与人力)去维护这个测试用例库,务必使其中没有过时,冗余的测试用例,并达到一定的覆盖率.如何管理组织好测试用例已是一个很值得深入研究的课题,在此不再阐述(我也没有很好的见解..)总之,要做好回归测试,组织管理良好的测试用例库是前提.
   有了测试用例库,那我做回归测试时就执行所有有效的测试用例?这个没有绝对的答案,在很多的时候如果你有足够的资源用全部测试用例来做回归测试是最佳选择. 但现实中呢?有足够资源这个理想状态比较少,并且有些时候也没有必要这样做.如果只是修改了某个警告对话框中的单词就要执行完所有测试例以确保其修改正确性及其影响?或许你会说只有疯子才会那么做,但事实上有时候我们正是那个疯子.基本上很多时候连开发自己都不敢肯定会不会影响到其它部分,所以我们就不得不扩大测试范围.那应该如何选择回归测试使用呢?前人已经总结了很多,主要是如下4种.
1>选择全部测试用例
选择测试用例库中的所有测试用例作为回归测试用例,这是一个较为保险的方法.在理想的状态下(有足够的资源,测试人员不知疲惫),这种方法绝对是首选.但理想与现实的差距是惨不忍赌的,测试资源缺乏是行内常情,特别是由于进度而导致测试时间极为苛刻,而且测试人员会因多次执行相同用例而产生厌烦,这对测试质量影响是非常大的.所以,无论从现实资源考虑还是从成本上考虑都不可能每次回归测试包都是选择所以测试用例.
2>基于风险选择测试用例
这是基于一定的风险标准从测试用例库中选择部分测试用例形成测试包.按测试优先级来来选择最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例.这样测试任务会大为减轻但效果并不差,因为由此没有被发现的缺陷是较少并严重性较低的.
3>基于操作剖面选择测试用例
这种方法适用于测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
4>再测试修改部分
这种是基于开发对修改的影响区域有较大把握时所采取的一个策略.通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上,此时只选择相应的测试用例来做回归测试.此策略风险最大,但成本也是最能低的,通常用于做小回归测试.
   以上四种回归测试策略各有优缺点,实际应用中应根据项目的资源,进度及项目开发的模式等实际情况来选择最优策略.1>一般情况在在一个非用于基线的build中作了小修改,建议采用策略4,只测试修改部分,因为现在的开发流程中build更新较快特别是极限编程中,要进行完全的回归测试是比较不现实的,即使有自动化工具的辅助亦未必能实现.2>在一个milestone中,一个作为基线的build中则可采用策略2或3,基于一定的风险选择测试,这是一个较为折中的办法,但如果资源允许的话建议进行全回归测试.3>较重要的mileStone或是最终版本,最好选择全回归测试.因为如果一般来说此时软件改动会较大,选择全部测试较为保险.当然这还是要依据当时的实际出发.
   但无论采取何种策略,回归测试还是让人欲弃之不做却又不得不做的一种测试,因为它重复多并且经常工作量大但经常发现的缺陷相对工作量来说太少.但是谁都不敢承担不做回归测试带来的后果,真是食之无味,弃之不能.所以在做回归测试时我们必须采取一些较为有效的方法来保证做好回归测试.例如安排新的测试者完成手工回归测试,让更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。或是采取轮流执行不同模块,尽量避免一人一直测试某一模块,不论从测试员感受还是测试效果来看,这都是一个不好的方法.但我觉得最重要的就是基于实际可行的话引进自动化测试,因为机器不会累,可以日夜跑.
   回归测试这个令人头痛的问题需要根据项目跟测试资源等实际情况来采取更有效的策略来解决.其中需要注意的是必须重视回归测试,在测试计划中有很好的进度安排及选择相应的回归策略,重视测试用例的维护,借助于自动化工具.

Product:
TestDirector 8.0
TestDirector for Quality Center 8.2
TestDirector for Quality Center 9.0
DB(s):
Not Relevant

Topics:
Integrating with Astra QuickTest / QuickTest Professional
Integrating with WinRunner
Error Messages
Integrating with QuickTest Professional
Integrating with VAPI-XP
Integrating with Business Process Testing
OS:
Windows XP

Creation Date:
14 Aug 2004  Last Modified Date:
18 Sep 2006

 

--------------------------------------------------------------------------------

Problem Descrīption: Error: "RPC server is unavailable" or "Access is denied" during remote execution of automated scrīpts on Windows XP SP2

The user receives the following error message when executing a automated scrīpt remotely after installing Windows XP SP2:

"The RPC server is unavailable."

or

"Access is denied."

Executing the scrīpt locally works correctly.

Diagnosis: Security changes in Windows XP SP2 have blocked the remote agent of the testing tool from being launched. This caused the failure of the automated scrīpt execution.

Note: Windows XP SP2 is supported with TestDirector 8.0 SP2 and TestDirector for Quality Center 8.2 and above only. For more information on supported operating systems, please refer to the links below:
Problem ID 44879 - What are the system requirements for TestDirector for Quality Center 9.0
Problem ID 36167 - What are the system requirements for Quality Center 8.2
Problem ID 25963 - What are the system requirements for TestDirector 8.0

 

--------------------------------------------------------------------------------

Solution: Change the DCOM permissions on the Windows XP SP2 client to allow for remote execution

Notes:

The security changes suggested below should be applied by your System Administrator. Please contact Microsoft Support if you have questions regarding changes in DCOM securities caused by installing Windows XP SP2.

If you disable the firewall installed with Windows XP SP2, you do not need to apply the steps in Part II below. However, a utility (CPT33502C.zip) has been created to automate the steps for opening the ports outlined in Part II.

Part III - VI can be applied automatically by running the attached batch file included in CPT33502B.zip. You will need to extract the contents of this zip file to a temp directory and execute the SetWRandQTPIPDCOM.bat file. The batch file (CPT33502B.zip) will use the dcomperm.exe (CPT33502D.zip) provided by Microsoft to update the DCOM properties of the remote agents for WR, QTP, BPT, System Test, and VAPI-XP. Your system administrator should be able to run this batch file across the network to update each Windows XP SP2 machine. If you apply the batch file, you do not need to implement the steps in Part III - VI below.
The following is the manual process for openning the firewall ports and modifying the DCOM properties for WR, QTP, BPT, System Test, and VAPI-XP.

Part I:
Add both machines into the same domain. For the domain users logged into both machines, add these domain users to the Local Administrators group on the QTP/WR machine. This is required for Windows to authenticate the remote user executing the tests against the DCOM objects.

Part II:
On the Testing Tool client machine configure Windows Firewall to allow Port 135 for DCOM:
1. Select Start -> Control Panel -> Windows Firewall.
2. Navigate to the Exceptions tab.
3. Configure the Remote Agent to be allowed under "Programs and Services." Configuration should be done for each testing tools as given below:

WinRunner Remote Agent (path: <System Drive>:\Program Files\Common Files\Mercury Interactive\WR_Remoter\wrrmtsrv.exe)
QuickTest Professional Remote Agent (path: <System Drive>:\Program Files\Mercury Interactive\QuickTest Professional\bin\AQTRmtAgent.exe)
Execution Agent for Business Process Testing (path: <System Drive>:\Program Files\Common Files\Mercury Interactive\TD2000_80\bp_exec_agent.exe)
4. Click on <Add Port> and add the DCOM TCP port 135 to the Exceptions list.
Note: The WR remote agent is a DCOM object and requires port 135 to work. The list of "Port Assignments for Commonly-Used Services" is provided in the URL below:
http://www.microsoft.com/resourc ... t/cnfc_por_SIMW.asp

Part III:
Modify DCOM Security Properties:
1. Select Start -> Run and enter dcomcnfg.
2. Navigate to Console Root -> Component Services -> Computers -> My Computer.
Note: If Windows Security Alert dialog window appears, click on <Ask me later> or <Unblock>.
3. Right-click on My Computers and select "Properties."
4. Navigate to the Default Properties tab.
5. Make sure the Default Impersonation Level is "Identify."
6. Click <Apply>.
7. Navigate to the Defualt COM Security tab.
8. Under Access Permissions, click on <Edit Limits>. The Access Permission dialog window appears.
9. Click on <Add>. The Select Users or Groups dialog windows appear.
10. Click on <Advanced>.
11. Click on <Find Now>.
12. Add the following groups and users from the local machine (below is an example screenshot):

Administrator
Administrators
Authenticated User
Anonymous Logon
Everyone
Interactive
Network
System

13. Click <OK>.
14. Add the following groups and users from the domain:

<tdomain user logged into the QTP/WR box>
<domain user logged into the TD client box executing the remote execution>

15. Click <OK>.
16. Give "Local Access" and "Remote Access" permissions to the groups and users.
17. Click <OK>.
18. Under Access Permissions, repeat steps 9-17 for <Edit Default>.
19. Under Launch and Activation Permissions, click on <Edit Limits>. The Launch Permission dialog window appears.
20. Repeat steps 9-15.
21. Enable "Local Launch," "Remote Launch," "Local Activation," and "Remote Activation" permissions to the groups and users.
22. Click <OK>.
23. Repeat steps 20-22 for <Edit Default>.
Part IV: (for QTP only)
1. While still in the Component Services window, navigate to Console Root -> Component Services -> Computers -> My Computer -> DCOM Config.
2. Look for the following.

AQTRmtAgent
QuickTest Professional Automation
TlpRmtServer

3. For each of these DCOM applications, right click and select <Properties>.
4. Under the Identity tab, select <The Interactive User>. This will allow the DCOM application to authenticate the process against the logged in Windows user and run the process in that security context.
5. Next, go to the Security tab.
6. For both the <Launch and Activation Permissions> and <Access Permissions>, select <Use Default>. This will use the Default security settings as we did in Part III.
7. Click Apply, then OK to commit the changes.
8. Now, you are ready to run a remote execution test with QTP.
Example Screenshot of the Security Configuration (see word attachment)
Part V: (for WR only)
1. While still in the Component Services window, navigate to Console Root -> Component Services -> Computers -> My Computer -> DCOM Config.
2. Look for the following:

{0B171F02-F204-11D0-9398-0080C837F11F}
Wrun Document

3. For each of these DCOM applications, right click and select <Properties>.
4. Under the Identity tab, select <The Interactive User>. This will allow the DCOM application to authenticate the process against the logged in Windows user and run the process in that security context.
5. Next, go to the Security tab.
6. For both the <Launch and Activation Permissions> and <Access Permissions>, select <Use Default>. This will use the Default security settings as we did in Part III.
7. Click Apply, then OK to commit the changes.
8. Now, you are ready to run a remote execution test with WR.
Part VI: (For System Test, BPT, and VAPI-XP)
Repeat the procedure outlined in Part V above but replace the WR Application ID in step 2 with the appropriate one for each of the remote agent listed below:

Vapi-XP object
{CD70EDCE-7777-11D2-9509-0080C82DD192}

Business Process Testing object
{6A03829E-EC39-4802-A631-3841484EFBE3}

System Test Remote Agent
{1B78CAE4-A6A8-11D5-9D7A-000102E1A2A2}

Notes:

If you have not configured the Remote Agent to be allowed under "Programs and Services," a Windows Security Alert message will appear while running a test remotely. Click <Unblock> to resolve this problem. The next time you execute an automated scrīpt, the warning will not appear.
If after performing all the described steps and you still receive "The RPC server is unavailable" message, create some shared folder anywhere on the Testing Tool machine.
Below is a list of supported Mercury's Testing Tools on Windows XP SP2:

TestDirector Version Testing Tool Testing tool versions
TestDirector for Quality Center 8.2 QuickTest Professional 8.2
  WinRunner 8.0, 8.2
  Business Process Testing 8.2
TestDirector 8.0 SP2 QuickTest Professional 8.2
  WinRunner 8.0, 8.2