Remote access from UFT to "system under test"

Hi there,

i want to use UFT in a "system and service test" environment

at the target "system under test" (sut), various applications  will be testest (e.g. MS-Office, Outlook, Adobe, various browser, security stuff, even Citrix stuff to connect from sut to another machine). Mainly existence and configuration, but also some functional parts.

the sut are physical and virtual W7 and W10 machines (i dont know actually what these VDI machines are based on)

The automated UFT test cases are to be controlled from ALM. the sut is controlled from a dedicated "automation" laptop, which then connects to the SUT and executes the varios uft automation scripts


is it mandatory to install (and run) the uft agent on the sut? or is it sufficient for testing to connect to the sut exclusively via remote desktop? What would be the limitations or additional features if the uft agent is/is not installed on the target system?

reason for this:

I want to avoid to install UFT Agent software on the SUT due to various security software, which might conflict wit the uft agent. Thes security products need to be configured specifically for allowing the uft agent to do his work. but this configuration (working uft agent and supressing security tools) wil not match the later production environment (which has NO uft agent installed)

  • I assume the uft agent installation on your 'SUT' host is needed, but it may depend on what exactly kinds of tests you're going to run. Have you consulted UFT team about this? They may know more details about the necessity.

    BTW I will also forward your questions to UFT internally.

  • Sorry, i just have seen that the thread is started in the "wrong" section (alm instead of uft) thanks for forwarding the question to the right direction. 

    concerning your questions: initiially, there will be some smoke tests (each of those shall not fail)

    - connect to SUT
    - check OS version number
    - start application
    - check version number of application
    - end application

    additonally (later), some more detailled tests may follow

    - check name of install package of application
    - check active policies
    - check specific registry values

    - perform some functional tests of the application

  • Hi Martin,

    Did you mean "System Test" or "Service Test"? There’s a remote agent addin for "System Test" for ALM according to here, but it’s not relevant to UFT at all:

    If you did refer to "Service Test", then UFT installation on the machine is mandatory:

  • Hi Lancer Fan,

    thanks for your reply.

    It seems that your answer does not completely match my task (or i have not understood the answer). I will explain more detailled:

    actually, a tester tests manually things at the "System under test" (SUT) 

    a) physically in a specific room  [needed e.g if components have to be attached/detached]
    b) accessing SUT from testers Workstation via IP-KVM switch connected to the SUT
    c)  accessing SUT from testers Workstation via RDP  to the SUT (SUT here are physical and virtual devices = VDI), furtheron referred as "real_target_system"

    in future, these tests should be supported by automatic tasks where possible.

    the "UFT addin for ALM" has been installed at testers workstation, to allow to start UFT automated test cases via ALM.

    further on a "test laptop" has been set up. Access FROM testers workstation TO the "test laptop" occurs via RDP.

    at the "test laptop", the UFT agent has been installed, to enable the execution of UFT scripts on that specific machine. assume UFT automated target applications like:
    a) a web based software (dont care about its name or purpose, this web app connects via web browser to the related "web server" and bowses through this software)
    b) a "fat client" software  (e.g. winzip)

    so we habe 3 different systems, which have to interact:

    a) the tester pC
    b) a "test_laptop", which performs the interaction towards the target system(s), the SUT.
    c) the SUT (real_target_System)  itself. These machine(s) may vary in version of OS, model of hardware etc.

    The "system test" has to validate the correct function of different hardware (or virtual) machines (type x, y, z), running different versions of OS software (e.g. W7, W10-1909 etc), and different versions of APP Software  (e.g. Office version 16.0, 19.0 etc)

    For web based application, there is no direct need for a specific SUT where the browser is running
    For "fat client" software, a dedicated and specific hardware shall be used, as this fat client software has to interact without conflicts to other apps and OS on that specific hardware (lets name it "real_target_system"). 

    from some perspective, this "test laptop" now acts as a "SUT" itself: UFT script running on the test laptop requests to perform some action on the real_target_system, which is in fact the test laptop itself.

    now the next phase shall be started. Normally, i would now install the UFT agent on the real_target_system, and stat the script, which now interacts towards this real_target_hardware.

    This approach has one major impact: the real_target_system (when the UFT agent is installed) is now different from the later production situation, as some intermediate "trojan style" software (the UFT agent)  is replaying keyboard and mouse interactions. on the real_target_system.

    Therefore, this idea came into my mind:

    similar to the web tests running on the "test laptop" via web browser towards the "web server", a connection FROM the test_laptop  via RDP shall be established to the "real_target_system", without any UFT agent on the target. hen, i exectute some tasks towards the "fat client software" (e.g. start winzip etc) running on the  real_target_system in an "RDP window"

    so the question is (from UFT perspective, on the test laptop":

    1. does a RDP session/window at the test_laptop towards the real_target_hardware behave like a web browser window at the test_laptop towards the web_server?

    2. Am i able to performe some actions (and log/analyse the results within UFT) on the test laptop within/from this RDP window?, similar to the web browser window?

  • Hi Martin,

    Not sure I fully understand your scenario, looks like the fat client like winzip is installed on the real_target_hardware, and you want to test it from test_laptop via RDP window, is that correct?

    If so, there's no dedicated RDP addins for UFT GUI testing, we have to use StdWin addin, insight object and device replay combination for a workaround, the recognition results might not be expected, and full UFT package must be installed on the test_laptop not only the ALM plugin.

  • yes, you have summarized the situation correctly. and I suspect that my plan could work

    the long story short is:

    3 "PC" types:

    (a) the tester pc. there  ALM is running, and an ALM UFT plugin is installed to start UFT scripts via ALM. From this tester pc the test chain starts.

    (b) an intermediate "automation pc", There an UFT plugin is installed, to proceed the "capture/replay" actions

    (c) various types of "real target systems", which should be as unmodified as possible (even the installation of the UFT capture/replay addin is not desired)


    unter "manual" conditions, the tester connects via RDP from (a) to (c)  and executes his manual tests.

    in "automatated" tests, the tester shall connect to (b), and an UFT script on (b) connects via RDP to (c). That means in detail: The UFT script on (b) opens a remote desktop connection to (c). Within this remote desktop connection (now on system c), there shall be tasks executed like "start winzip" 

    i am sure that it is possible (on system b) to start an RDP window towards (c), via UFT capture/replay mechanismn. but the question is:

    will UFT also capture/replay _individual_ steps _within_ this RDP window (like starting winzip) ? Will this action be logged and validated (for success) by UFT???

  • In that case, UFT on (b) can only recognize RDP window as a generic window from StdWin addin, then clicking the corresponding cordinates by device replay, or with some kind of image based technology like insight object, text object, AI etc,.

  • So an RDP window behaves (from UFT view) differently than an "web browser" window?

    As i am able, to connect from (b)  via edge browser to a webserver (d) and proceed actions, i.e. browse through the different we sites. this action is possible manual and automatic. (both tested)

  • You are right, an RDP window is recognized as a generic window and the content inside (like Table, Button, Editbox...) cannot be recognized properly, but for a web browser window, it could be recognized by web addin, and all the objects inside(WebTable, WebButton, WebEdit) can be recognizable for sure.