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
Related
i'm having issues to get a permanent active user-session on my virtual machine to execute gui tests developed with the functional testing tool Ranorex Studio via GitLab-Runner (Windows / Shell). The testsuite is based on a .NET solution which is built via MSBuild.exe and the output (bin/debug/*.exe) will be executed with some parameters via command line.
Procedure:
Start gitlab-runner via PowerShell as administrator with "gitlab-runner run" command
Make some changes in GitLab-Repository to start the pipeline via .yml-File
Ranorex test-project is built successfully and is starting the GUI-tests
In the first run the user session is active and the tests are going to be executed and interacting with the GUI, but when i try to trigger the pipeline again for further runs, the user-session turns to false and there is no interaction with the GUI (black sceenshots in test-report).
Already did:
Screensaver disabled
StandBy-Mode disabled
User-Access-Control on lowest setting
Lock-Screen disabled
Secure-Login disabeld
Remote connections enabeld
Ports openend
Keep Session open via .batch-File, when closing RDP-connection
GitLab-Runner Service => Log on with respective AD-User (equipped with admin-rights)
AD-User is alway logged in on virtual machine
With Jenkins (Master / Slave configuration) everything works fine
Would be grateful for any help!
Does your Ranorex process close down properly with an exit code? Does the Application Under Test also close down properly at the end? I am assuming something has locked - you could try a bit of Powershell to close the processes before a test run. One thing I had to do was keep the screen on - using a utility like 'Caffeine'.
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.
Background:
With TestComplete 6 we have created a project which clicks few buttons in our application and performs few tasks. To automate it we have created a .bat file which installs our application (desktop) executes testexecute.exe in silentmode and uninstalls the application. This .bat file works fine when we execute it locally.
But when we execute this .bat file on a remote machine (teamcity agent) through teamcity I get "The 'My application' window is invisible and cannot be activated" error. Any UI action I try to execute fails because my application window in visible. It works fine till installing and starting my application, but once the application is started it can't execute any GUI task.
This weird behavior raised few doubts.
Why testexecute is unable to interact with the GUI?
Does the user account which teamcity uses to run testexecute.exe need special privileges on that machine?
How to execute TestExecute.exe on a remote machine and what things I need to take care of while doing it?
The TeamCity agent works as a system service which does not have access to GUI. This means that all processes invoked by it do not have access to GUI as well.
You can check the 'Run interactive' box for the agent service in the Services snap-in. However, you will still have to login to the machine in order to make the system to draw GUI and this will not guarantee that TestExecute will have enough permissions to access this GUI without any problems.
You need to find a way to run TeamCity build agent as an interactive app, not as a service.
You can also find more information on this topic here.
Im working with VS2010 and TFS and the Coded UI tests (CUIT).
I created some CUIT and added them to several Test Cases in Microsoft Test Manager 2010.
These tests are executed in our build-deploy-test steps.
This looks as follows (simplified):
Build application
Deploy
2a. Set snapshot of the Virtual Machine to which the application will be deployed to the snapshot in which the application is not installed
2b. Install application
Run tests
Step 3 contains Coded UI tests, but they cannot be executed (will fail), since there is no active remote desktop connection, which they need to be executed.
Now I would like to add a build step 2c. That automatically connects to the Remote Desktop so that the Coded UI Tests kan be executed.
How should I create this step in the Process Template?
I attempted this myself by running a PowerShell script to connect to a machine via Remote Desktop (see here to see how to use the Remote Desktop command-line utility).
This didn't really work for me personally because I was running this script from the build machine - which I could only connect to via Remote Desktop - and so when I close Remote Desktop it would close the session on the build machine and thus I would not be able to obtain a remote desktop connection with my test environment (plus it wasn't ideal to have to launch Remote Desktop from the build machine).
Therefore, the solution I went with instead was to enable auto-logon on the test environment (there are various ways to do this, I can't remember how I did it, but it's easily Googled).
So in my PowerShell script, which launched from our build machine, I used a command to remotely restart the test environment. With auto-logon enabled, the test environment would start back up with an active session, then I could carry on with Visual Studio Coded UI testing. This worked for me without any issues.
The command I used was something like this:
Shutdown.exe /r \\mytestenvironment
Here is some documentation for it.. If you intend on using this command to remotely restart a computer, don't forget to give your machine permissions on the test environment, otherwise this command won't work.
I then launched a command to sleep for a few minutes, to give time for the remote test environment to start back up again (with an active session), then I launched the tests.
Personally, I used a PowerShell script but you could also use a DOS/Batch script if you are more familiar with that.
Also, are you trying to run the automated tests as part of a build process template?
Let me know if you need any further help.
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.