Forum Discussion

thustead's avatar
thustead
Contributor
15 years ago

Using TestComplete to test a remote application

We have a C# application that works well with TestComplete 8.2 when running the client application on our machines, but we also want to test this app in a remote app setting.  We are logging into a Windows Server 2008 R1 machine where the C# application is running.  I can record and replay logging into the server, but anything that I record in the C# application can’t be recognized when I replay the script.  I get the below error in TC:


An error occurred while calling the "Click" method or property of the "wndRAIL_WINDOW1" object.

The object or one of its parent objects does not exist.


Tested Object














Alias:

Aliases.mstsc.wndRAIL_WINDOW1

Mapping item:

NameMapping.Sys.mstsc.wndRAIL_WINDOW1

Missing Object














Alias:

Aliases.mstsc.wndRAIL_WINDOW1

Mapping item:

NameMapping.Sys.mstsc.wndRAIL_WINDOW1

 


I’ve read some articles and postings that say you have to have TestComplete or TestExecute on the actual machine where the tested app is running, but we need to do a lot of testing by actually logging in remotely, to simulate how the users in the field are using the application.  Does anyone have any suggestions?


Thanks,


Tom Hustead

7 Replies

  • YMinaev's avatar
    YMinaev
    Icon for Staff rankStaff
    15 years ago
    Hi,



    You cannot test applications remotely. TC and the tested application must be installed on the same machine. In your case, you can try using the network suite. For example, install TC on your local machine and TE on your remote machine. Then, let the local machine log into the remote one and start tests in TE there. You can find more information on this in the Distributed Testing help topic.



    Note that you can record actions with your application only on the machine where it is installed.
  • thustead's avatar
    thustead
    Contributor
    15 years ago
    Jared,



    Thanks so much for the quick reply.  I was thinking we wouldn't be able to do this.  Our group will need to think of an alternate solution. 



    Tom
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    15 years ago
    Just to follow up... is there a specific reason why you need to test the application through a remote connection?  It seems that, regardless of whether or not the user is sitting at the workstation wouldn't make any difference on the functionality of the application unless there's an architectural piece that I'm not aware of.  In the absence of the architectural requirement to test through remote connection, I think that such a test case operated in automation would be an unnecessary test case.



    Just my $0.02
  • thustead's avatar
    thustead
    Contributor
    15 years ago
    Jared,



    Also, just to be sure I understand your suggestion, it sounds like you are suggesting running the scripts on the remote machine, where our actual app is installed, but we cannot test by running the scripts on the local machine and having it log into the remote machine, correct?



    Thanks again,

    Tom
  • thustead's avatar
    thustead
    Contributor
    15 years ago
    Hi Robert!  



    Our 64-bit application is deployed to a Terminal Server farm that is accessed via a Remote Desktop Protocol (RDP) connection as an Active Directory user.  This architecture is designed to take advantage of the horsepower of the Terminal Servers.  Our users access the application from their 32-bit workstations via RDP. The hurdle we have with RDP is that some aspects of our application operate differently due to the protocol whereas it wouldn't be an issue as a client-server application. Note, the users accessing the TSs only have access to this application and noting else.  They don't even have a Desktop on the TS.



    Thanks again,

    Tom
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    15 years ago
    Hi, Tom,



    That makes sense, then.  You do have a need to test user access to the TS and to make sure that the environment is performing as it should.



    I think Jared's suggestion is going to be your best bet where you would run one project on the local machine that would execute scripts to open the RDP connection to the remote box and then, using a Network Suite and a Network Job, spin up and run the remote tests via the TestExecute application.  Some good examples in the help docs for this.



    Good luck!
  • thustead's avatar
    thustead
    Contributor
    15 years ago
    Ok, thanks Robert and Jared!



    We will try this out and see how it works for us.



    Tom