To test our desktop application we have a Master project that runs the Slave project on different VMs.
We are using TeamCity to start our tests. On a TestManagement machine (VM) we have a Build Agent that is running as Service. This Build Agent starts the Master project with TestExecute.
This project connects with RDP to different VM to run our UI Tests (Slave project) of our App. We are using Network Suite and run our tests on Hosts (VMs) like it is suggest here: Using Network Suite.
But we have an issue with the screen resolution that is used to run our UI Tests. The resolution is too low.
This page Running tests via RDP gives an explanation:
"When running tests on a remote computer that participates in distributed testing, TestComplete creates a Remote Desktop session and automatically sets the master computer's screen resolution on the remote computer. This is done to avoid possible problems with test running."
So TestExecute will use the master computer's screen resolution.
But TeamCity Agent is run as a service on a VM (TestManagement machine) and there is no screen resolution because it's an headless machine and not like a real user that will connect with RDP to this VM and start the Master Project.
I assume TestExecute will then use the default screen resolution (something like 640x480) as the resolution for the RDP connection. But this is too low to run our tests, some object are not on the screen and we have many issues...
Is there a way to change the resolution used by the RDP connection that TestExecute / TestComplete will create ?
The tricky part is that the Master project is started from a service on an headless machine...
Thank you for your answers,
Camille
In the past, we experienced a similar problem as yours and we were unable to solve it by this way. As solution (right now working for us) we installed into our test environments the TightVNC. This able us to forget the screen connection (RDP issues) because you configure the screen resolution by RDP the first time, then access via IP, log in and you will be able to launch whatever you want without open any application.
Maybe its not the best solution but for our testing environments we can launch tests from Jenkins on demand without screen resolution problems.
Related
Context :
I execute automated GUI tests on virtual machines (there are few of them) on running on windows and using UFT/Ranorex, executions are piloted by Jenkins.
Problem:
VM must have an active graphic session, otherwise, UFT won't run GUI tests (unable to launch browser) and Ranorex will run but poorly and without screenshots. i mean that in my tests, the VM is configured not to "sleep" or to have any screen saver, vm is connected with jenkins properly.
The behavior is : i launch via Jenkins the test, one the build done inthe vm, automation tools start running but then finds difficulties to open browser.
I would like to know if there is any workaround to run those tests without being needed to physically open VMware or Remote desktop Connection.
Notice that the VM is running all the time and the session is always open (we are using a server to host the VM).
So the problem is: how to simulate in windows active graphical session. I guess it's like simulating that there is actually a screen connected even though there isn't...
Any suggestions will be welcomed.
Had to go through this many times and you can find a lot of resources related to your issue in the Ranorex Forum. (My username there is Martin for reference).
But to go through the points you need to do quickly:
1) Have an RDP machine to connect to that is used to run your tests
2) You need to disable screen saver for that machine (I had to do it from registry)
3) Then disable the "On Resume, display logon screen" option under Personalize settings for the screen saver
4) And finally create a .bat script with the following content "%windir%\System32\tscon.exe RDP-Tcp#0 /dest:console"
So basically when you have everything set up (required only once) you will run the .bat script. This will close the RDP window BUT the session will be left open with the screen enabled.
Just connect the RDP with Jenkins and you have full functionality that you need to run your tests.
Regards
Martin
In the Tools ⇨ Options menu, select General ⇨ Run Sessions there you will find an option to Enable continued testing on locked/disconnected remote computers.
If this fails, see my other answer.
I had the same problem when I try to run an automate tests on virtual machine and I find this solution to generated a graphical session although you are not connected to the virtual machine. You need to created a task to opend a session on the virtual machine when you disconected or terminated the session , this created a graphical session but will not function when you are connected and you have the screen minimize. Here is the link for the solution and the explanation
http://blogs.microsoft.co.il/arnona/2016/01/03/keeping-an-active-desktop-session/
I am running several automated browser tests with selenium on our build server. There is no problems taking screenshots while running Chrome or Firefox driver, but when running Internet Explorer driver I just get a black screen.
Virtual Machine
Selenium version: 2.53.0
IEDriver: 2.53.0
OS:
Windows Server 2012
Browser:
Internet Explorer 11
I have gone through all the required configuration in the documentation https://github.com/SeleniumHQ/selenium/wiki/InternetExplorerDriver
I have also tried the third option here:
https://lostechies.com/keithdahlby/2011/08/13/allowing-a-windows-service-to-interact-with-desktop-without-localsystem/
I have also enabled service interaction globally:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx
When I remotely access the build server, I can trigger running the tests manually. This works fine. So there must be a problem with our CI(TeamCity) setup interacting with the build server.
I am currently stuck and could need some help ?
This is the default behavior of Windows. since Internet Explorer is tightly coupled with Windows, it behaves this way but other browsers don't.
In order to have better resource utilization, when running on remote, windows detects that since session is running in remote mode and nobody is watching the screen, it takes away the resources required to show the screen and screen goes black. When you log into the machine, resources to show screen UI are deployed again.
Hence, when running in remote mode, since there is no screen being showed, screenshot comes out to be blank.
There are only workarounds, no solution.
Workaround:
Workaround 1: Use VNC server for your remote session instead of RDP since VNC keeps the remote session alive.
Workaround 2: Add this command to batch file : tscon rdp-tcp#1 /dest:console
It will switch the session to "1" which is active mode.
By default it will be running on "0" mode. It will disconnect your session and now you can run your test case.
My Window Tester UI Tests(All the tests which has error dialogs and error messages in in RCP Application) are failing in Jenkins server, but they are passing in my local machine.
Is there anything to do with machine configurations, like based one executors?
if the machine configurations doesn't matter why they are not failing in my local machine?
You are probably not running your Jenkins server in a desktop session, meaning that it does not have access to your GUI (e.g. it can't launch anything that pops-up a window or a dialog).
So you either need to start the Jenkins master manually from the command line or allow it to access the GUI if it's run as a service.
See also these two related topics:
How to run GUI tests on a jenkins windows slave without remote desktop connection?
https://serverfault.com/questions/285065/gui-tests-in-hudson-jenkins-on-windows
I'm trying to run UI-tests (written using white). When I run them using NUnitConsole everything works fine. When I try to run them using TeamCity I get the following exception Test(s) failed. White.Core.UIItems.UIActionException : Couldn't find window with title Form1 in process 4132, after waiting for 5000 ms. What might be wrong? What could I do to make the test pass?
Not only does the build agent need to be set to interact with the desktop, but the desktop must be displayed in order for UI automation to work - desktop cannot be locked and screen saver must not be running. Is your agent on a headless machine? If you are using RDP to connect to the agent to check on things, when you close RDP, it locks the desktop. In this case, the automation will fail. Instead of using RDP, use a VNC viewer to log on to the box, rather than RDP, as VNC will not lock the desktop when you close it.
Another issue to consider is network access. If you are running TC agent as a service with access to desktop, then it will be running under service account which will not have access to network shares, etc... If this is a probelm, then you will not be able to run TC agent as a service, and will instead need to logon with a domain user and kick off the agent.bat file to start the agent.
Spent a lot of time solving this issue.
Main steps:
You need separate computer with teamcity build agend installed on it. Computer should have monitor and mouse.
The agent SHOULD NOT be launched and run as a Windows service (disable it if needed).
You should launch TeamCity build agent from .bat file (as administrator). To do this go to TeamCityBuildAgentfolder\bin and launch agent.bat file with start argument
Disable computer's screen sleep/lock after certain period of time. Your tests will require desktop for UI manipulations.
If you done everything right you should be able to see your build agent active in TeamCity's "Agents" menu.
You can also automate TeamCity agent launch (at selected user's logon):
Automate user's logon. More instructions here
Create task in Task Scheduler which will launch build agent at user's logon with administrative rights (with highest privileges)
Make sure that the user who will logon automatically has all neccessary permissions (run the scripts, perform file operations etc.)
IMPORTANT!
Running UI tests in such way is a potential security hole so make sure that the non-authorized people have no acccess to computer that runs this tests.
Remember that for running your UI test the computer SHOULD NOT be locked or be in sleep mode.
You probably have to make the Teamcity build agent interact with desktop.
Run -> services.msc -> Select TeamCity Build agent and right click -> Properties -> Log On tab -> Check "Allow service to interact with desktop"
Edit:
If that doesn't work, stop the agent service, go to Build Agent folder ( c:\teamcity\buildagent\bin ? ) and issue agent.bat start and then trigger the tests.
There is recommendation to run the UI tests on virtual machines.
Seems as most reliable solution.
I am using Jenkins as my CI build server. After a build of our software is complete it starts up the automated tests on a slave machine. The tests that use a web browser run at a very good pace, the tests that run on two different local applications run very slowly. It takes about 3 seconds between each keystroke.
If I start the tests manually through Visual Studio 2010 on the same slave machine the local application test run just fine (fast keystrokes).
Any idea why the local apps are so slow when run through Jenkins?
I'm not sure if this is the same case, but we had similar issues with an automated UI test, and found that we must have a real session open on the slave running the test. NOT RDP.
We did this by using VNC to login to the slave and leave the session open.
I hope this helps.