Hi, I really need help to make my virtualized envirronment suitable for TestComplete.I just can't make it running past midnight (No problems for the scheduler).It seems to need a GUI to run. But could I simulate tuhis GUI through VMWare ?Thank you very much for any adviseMehdi

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.

ETS, VMWare and TestExecute | SmartBear Community

17 Replies

m_essaid
Valued Contributor
11 years ago
Hello,
(I don't know why I don't have lines returns here)

I'm still struggling with the VMs and TestExecute.
I understood that I need a GUI. So I made the following thing :
A VM is launching another VM which is launching Test Execute through a Batch file launched by a schedule task manager (not the microsoft one, it doesnt work).
It's quite complicate but I need the first VM look into the second VM to keep the GUI on the second one.

One problem is that when I launch the task within the microsoft task manager, TE is not shown on the residents but it is still launched in memory. I lost a lot of time trying to launch TE. When I kill TE's task, I can launch TE normally.

Is there an issue about this in SmartBear R&D ? Is there a service I can stop&start to make sure that there is no TE still loaded in memory ?

Thank you very much for any help,

Mehdi
mtsmith
Contributor
11 years ago
Mehdi,

Two other options are to put TestExecute in the startup folder on the target machine or use gpedit.msc to add a logon/logoff script that starts TestExecute and runs a script. The second method works well in our situation since, for performance reasons, are test boxes require regular restarts.
mtsmith
Contributor
11 years ago

Hugo,

Your response was interesting and informative and it left me with several questions. First, does the technique in paragraph 4 require administrative rights on the VMWare server? Second, does this prevent the use of TestComplete network suite distributed tests, which appear to rely on RDP?
mtsmith
Contributor
11 years ago
The best laugh I've had all week, thanks all :).
m_essaid
Valued Contributor
11 years ago
I'm really sorry for those who tried to help me. I didn't figured out the licencing system of SmartBear and because I put /silentmode in the .BAT ... I did not seen why it didn't execute itself.
joseph_michaud
Staff
11 years ago
(How many times have we all read a thread describing exactly the same problem that we have and it just ... ends? with no resolution?)

Thanks for letting us know what the resolution was.
AlexKaras
Champion Level 2
11 years ago
Hi Mehdi,

> [...] because I put /silentmode in the .BAT ... I did not seen why it didn't execute itself.

TestExecute handles a log file where it posts the description of problems if any. I don't remember the exact name of the file, sorry, but it has the .log extension, pretty descriptive name and, at least for TE up to version 8, was located in the <TestExecute>\Bin\ folder.

Forum Discussion

ETS, VMWare and TestExecute

17 Replies

Recent Discussions

Firefox support

Running Power shell script through Test Execute is not working.

TestComplete Allure Jenkins Integration

Related Content

Test Log tool bars ettings

VMware vSPhere and default screen resolution for VM's

Stop testrun TestExecute/SessionCreator