ETS, VMWare and TestExecute

If you have the correct licensing then you can run TestExecute on your virtual machine/s.

This is a perfectly normal way to run and distribute automated tests. For GUI testing on Windows you need to ensure a couple of things on your virtual machine.



1. The desktop is not configured in Windows settings to lock after a period of time.

2. A connection, be it RDP or other remote connection protocol needs to be kept open to the machine. Otherwise Windows will not render a desktop and you cannot run GUI tests. This is common to all GUI testing in Windows and not just TC. A popular method to do this is to run a tool like VNC server (or equivalent) on your testing machine. Configure the software to keep the connection open after you disconnect. This tricks the testing machine into thinking a monitor is attached.



Note, there is also documentation in the SmartBear docs about how to keep a desktop connection open to your testing machine. IMO, this isn't a practical approach and takes as much if not longer time than setting up a tool like VNC server.



http://support.smartbear.com/viewarticle/56549/





If you are lucky enough to be running an enterprise version of VMware you can probably just connect through a console session to the machine using the VMware tools and no other software is required.

Couple of small innaccuracies in the answer above:



2. A connection, be it RDP or other remote connection protocol needs to be kept open to the machine. Otherwise Windows will not render a desktop and you cannot run GUI tests. This is common to all GUI testing in Windows and not just TC. A popular method to do this is to run a tool like VNC server (or equivalent) on your testing machine. Configure the software to keep the connection open after you disconnect. This tricks the testing machine into thinking a monitor is attached.



Windows will always render to a framebuffer, no matter what. Whether that famebuffer is connected or nor to a screen is another matter completely. You do NOT need to keep a connection open all day long to the machine. The hypervisor (be it VMWare or Hyper-V or whatever else) provides a virtual monitor anyways. The problem with RDP is specific to RDP. When you establish a connection to a RDP server you are establishing a connection to a new or existing session. Locally your session is called the console session. The console session is normally only ever tied to the physical (or virtual) screen. When you connect remotely, a new session is created for you to work in. The problem is that when you log off, by default Terminal Services disconnects the remote session and connects back to the console session and then locks it. So, any other remote access service that runs as a service and does not lock the session on logoff will work fine, with or without you ever connecting to it.



If you are lucky enough to be running an enterprise version of VMware you can probably just connect through a console session to the machine using the VMware tools and no other software is required.



As noted, VMWare offers its own tokenized remote access protocol, and it is recommended you use it instead of RDP or anything else, as it works directly through the VMWare hardware abstraction and introduces no incompatibility whatsoever. However that is not only available with an enterprise license. Most people forget about the free ESXi! This is what I would recommend getting here, it's 100% free, the same solution as enteprise users, and the only real limitation of the free license is no remote management API (as in VMWare VCenter to administrate multiple servers). Each VM is still reachable with the remote console, and you can still use local APIs (the Guest API for example to control VM state from within the VM...).

@Hugo Good recommendation on the free version of ESX server. I used this at a previous company to run our QA virtual machines and it worked just fine.

Hello,

The problem has been solved for me. It wasn't a GUI issue. I simply put the licence manager on my physical machine. When I was running TE through a VMWare, during the day the tests was working and the night not, because of the fact that I was turning my computer off.

I finaly put my TE licence on a physical server, and now everything is ok.

Access to the remote VMWare console requires rights to access the VSphere client for the server but it does not necessarily require admin access. I do not believe it will cause any issues, since a VMWare remote console is essentially the same thing as a physical screen connected to the virtual machine. As for the Network Suite I do not know since I do not use it.

Hi Mehdi,

hi Tanya, 



I may not understand, but here we bought a Test Complete node locked licence to built tests in a physical machine.

And we bought a floating licence of test Execute to make it run all night long on a virtual server.

I'm quite afraid that is not possible after your answer.



Regards,



Mehdi

Hi Mehdi,

Tanya,

I have this envirronement, thank you for your confirmation.

Chris,

wow thank you for your long reply, I will test this tomorrow.

Best Regards,

Mehdi