发布新日志

  • QTP与QC/TD整合设置host(转载)

    2009-01-08 23:47:02

    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

  • QTP 与QC/TD整合

    2009-01-08 23:42:10

        整合QTP跟QC(quantity center)是一件不错的选择,其会有下面一些好处:1> 如果本身是使用TD来做测试管理工具的话就可以方便测试用例跟测试脚本对应,方便管理.当然也方便Issue了. 2>用来存储并管理脚本.将脚本放在QC上就可以让团队编写使用脚本更为方便有效还可以进行脚本版本控制. 3> 可以方便组织脚本运行.可以方便组织哪些脚本在设定时间内在哪台机子上去跑脚本,跑完脚本后还将测试结果发送到相应负责人手中.

        看起来他们整合好处也不少,但要整合好也不容易,特别是需要费点时间去设置host机(用来跑脚本的机子).废话少说,开始整合工作.

       首先当然是要装个QC(旧版本的叫Merqury Test Direct),怎样安装就是题外话就不说了.安装运行QC后就可以设置QTP连接QC了.这个也简单输入QC的访问URL然后选择相应的Project那些.....

        此时应该就可以将QTP脚本放到QC上去了.接下来就是QTP 与QC/TD整合的最大好处体现了,不过也是最费时间设置的时候了.将脚本就到QC上后就可以在QC的客户端(浏览器)调用QTP并执行脚本.这个时候要设置的主要是两个方面.

        一个是QC客户端如假设机器名称为PC_QC,即是用来访问QC的机器.这里需要安装一个插件,这个一般情况下在你的QTP压缩包中有个"TD plugin"文件夹,里面就是这个插件了,如果没有也不紧要,可以下载. 步骤如下:工a)通过浏览器打开QC后,在主页面中根据链接其他 Mercury Quality Center 加载项---- QuickTest Professional 加载项进入下载页面,单击“下载 Quality Center 8.2 的加载项”进行下载并在您的客户端计算机上安装此加载项。b)下载并安装QC连通性加载项。进入加载项主页面,根据链接Mercury Quality Center连通性进入下载页面,下载并安装。c)它要求新启动,必须重新启动后才可用. d)注意事项:QTP跟QC的版本必须是适用的,插件版本当然也要一致了,在下载处有说明.然后是安装时必须是以管理员身分安装的.

        上面即是服务端(相对于运行脚本时用来调用的机子而言的服务器)的设置.接下来就是设置客户端(用来被调用用于执行脚本的机子).首先这个机子必须已经安装了QTP(没有QTP的话用什么来跑???呵呵),然后设置QTP允许外部程序执行:Tools—Option Run标签页给"Allow other Mercury products to run tests and components"打勾。或许也可以选上"Submit a defect to Qualiyt Center for each failed step".其实你也会奇怪怎么这台机器就允许别的机子来访问(通过qtp remote agent)呢?用什么用户名密码呢?首先你两机子要在同一上局域网内了(不然就太不安全了),然后客户端那些端口必须是打开的,然后放开一些特殊用户的权限.这个设置比较麻烦也是很多搞QTP整合QC不成功的地方.我设置时也试过很多网上的偏方但就是不行,后来才google到了官方处方,虽然有点麻烦,但是可行.由于较长,我将转载到下一篇.

        如果都设置好了的话就可以要服务端即是上面设置好的机器PC_QC上打开QC,然后选择要执行的脚本并为其选择用来执行的机子即客户端,然后在设定的时间上执行脚本了.

     

     

  • 虚拟对象

    2009-01-08 22:57:56

        对测试对象进行识别定位是自动化测试脚本比较麻烦的一点,暂时还没有非常完美的方法.QTP也不例外,其也有不少不能识别的对象.那怎么去操作这个对象呢?QTP其中一个方案则是使用虚拟对象.

        虚拟对象可能根据一定的属性(坐标,类似对象等)来创建一个对象以在回放时进行识别操作.不过它并不完美甚至很多时候会失灵,导致识别不了.所以考虑用虚拟对象时可以先考虑其它方法如使用键盘输入热键等.但不管怎样还是有可能会用到,下面是转摘了别人对使用虚拟对象的经验总结.

    1>虚拟对象不支持用于模拟或低级录制.

    2>仅当录制和运行测试或组件时,才能使用虚拟对象。您不能在虚拟对象上插入任何类型的检查点,也不能使用“对象探测器”来查看其属性. 录制和运行测试或组件时,网页或应用程序窗口的大小和位置必须和定义虚拟对象时的大小和位置相同。

    3>您只能为可以在其上单击或双击并录制 Click 或 DblClick 步骤的对象定义虚拟对象。否则,将忽略虚拟对象。例如,如果您在 WinList 对象上定义一个虚拟对象,录制 Select 操作,则虚拟对象被忽略。 不要使您的应用程序或网页中的虚拟对象相互重叠。如果虚拟对象与另一个虚拟对象重叠, QuickTest 可能无法正确地在虚拟对象上录制或运行测试或组件。

    4>虚拟对象管理器中显示的虚拟对象集合存储在您的计算机中,而不是随包含虚拟对象步骤的测试或组件存储。 这意味着如果您在测试或组件步骤中使用虚拟对象,则仅当在包含正确的虚拟对象定义的计算机中运行时,该对象在运行会话过程中才能被识别。要将您的虚拟对象 集合定义复制到另一个计算机,请将您的 <QTP安装文件夹>\dat\VoTemplate 文件夹的内容(或该文件夹中的单个 .vot 集合文件)复制到目标计算机上的相同文件夹中。

    5>创建虚拟对象时要注意在“标识对象使用”框中,选择您希望 QuickTest 标识和映射虚拟对象的方式. 5.1 如果您想要 QuickTest 标识所有出现的虚拟对象,请选择“仅父类”。QuickTest 仅通过其直接父类标识虚拟对象,而不考虑整个父层次。 例如,如果虚拟对象是使用 Browser("A")。Page("B")。Image("C") 定义的,则即使层次更改为 Browser("X")。Page("Y")。Image("C"), QuickTest 仍将识别该虚拟对象。 5.2如果想要 QuickTest 仅标识一次出现的虚拟对象,请选择“整个父层次”。QuickTest 将仅标识具有准确的父层次的虚拟对象。 例如,如果虚拟对象是使用 Browser("A")。Page("B")。Image("C") 定义的,则如果层次更改为Browser("X")。Page("B")。Image("C"), QuickTest 将无法识别该虚拟对象。

  • QTP 同步等待问题

    2009-01-08 22:31:16

        在自动化测试中,同步等待也是一个很重要的问题,特别是Ajax的出现,使这个问题更为复杂.做过自动化测试的都清楚,要对测试对象操作的前提是对象已存在甚至是可见,否则就可能出错,甚至脚本运行不下去. 这也是自动测试执行中较为常见的脚本错误之一.现在总结下QTP的几个同步等待方法.

        1>对象的默认等待时间. 运行QTP脚本过程中要对某个对象进行操作时, QTP会根据对象库中对象的属性或是对象描述的属性对进行搜索此对象,如果在一段时间内仍未找到相应对象则认为些对象不存在.而这个时间则是对象的默认等待时间.可以在File-->Settings-->Run-->Object synchronization中设置,默认时间是20秒.

        2>对象的Exist属性.每个对象都会有Exist属性以判定些对象是否存在,其可以设置一个参数即是等待时间,在这个时间进行对象搜查. 使用注意1: 这是个对象属性而不是对象方法,其会有个返回值,当然是布尔值了.所以不能将"Browser("百度一下,你就知道").Page("百度一下,你就知道").WebEdit("wd").Exist(5)"作为一个语句,必须接受其返回值,不然会提示引对象不支持此方法. 使用注意2: 其参数是秒而非QTP tutorial上提示的毫秒,别被忽悠了.

        3>对象的waitProperty ("property","expectVaue",timeout)方法.几乎每个对象都有这个方法,此方法是指在timeout时间内等待此对象的某个属性值为期望值.如果在timeout内属性期望值出现则立刻执行下一步否则等待timeout. 注意此也是QTP设置同步点的方法:在录制状态下,选择Insert-->Synchronization Point,选择要同步的对象,设置要同步的属性则可设置一个同步点了.

        4>Synce方法.这个是WEB中专用的,主要用于页面载入时.使用范围较小但简单实用.

        5>wait方法,也被形象戏称为"死等大法".即是执行到这一步时暂停执行脚本,然后等待一段时间,时间满后继续执行下一步.Wati(timeout),此方法的唯一参数当然是等待时间了,它由秒跟毫秒组成.

        大概来说QTP有5种同步等待方法,实际中运用哪个就要看具体情况了,我的建议也是按上面的顺序...

     

Open Toolbar