In Microsoft Release Management 2013, in the Powershell Executor step we have configured a step to trigger a Windows batch file. This batch file will be executed on a different server, which also happens be our App Server. As an experiment, we have a simple test case to open IE, access the Google homepage URL and close the browser, a screenshot will also be captured. When we run the job from RM, the Selenium logs say that the browser is launched and the test was successful. But when we check the screenshot it is just a black screen. All this runs as the Windows service account user which is the same user that is running RM. This user has no log on privilege.
If I log into the App server with my own ID and execute the batch file manually, the screen shot is captured correctly.
I have read several online posts regarding the black screen. People have said that the screenshot is black because the screen is locked. Does this mean the RM Powershell executor step must be executed with some other credentials instead of service account? If yes, how do we do this? In some suggestions it was mentioned to install VNC. Is that relevant in this situation?
I'm fairly new to Windows. I've mostly been working in Linux systems and I've been requested to debug this issue here. Any pointers/guidance will be appreciated. Thank you!
The deployment agent does not run as an interactive service. You're going to have a lot of trouble getting it to directly invoke Selenium tests. I wrote a blog post a few years ago showing how I accomplished it. Basically, you use Selenium hub to execute the tests interactively from agent machines.
We finally got this to work.
We were invoking the testNG selenium tests within a batch script. This script was specified in RM within the Powershell Executor task. The main point to note is that, in the Powershell executor task, we must first have a cd (change directory) command to change into the directory where the Selenium scripts are. Then specify the complete path to the batch script to be executed in the same Powershell executor task. This cd command is very important. Without this, the batch script would be executed but the selenium step within that wouldn't work. You would just get a vague "configuration errors:1" in the final output.
We took care of website authentication using AutoIT for IE browser.
Related
I created a Windows instance on AWS EC2 with T2 Micro, where I set up a schedule job that calls a .bat file at 6 every morning.
The .bat job invokes a few other scripts that mainly carry out some Internet-related transactions, including launching browsers, call services and perform I/O operations.
The issue is in most of the time the .bat file is not able to complete its job (Sometimes it does, but pretty rare). Later on, if I connect to the EC2 instance via remote desktop with the same username and manually call that .bat file, everything works fine.
Anyone has ever experienced this kind of problem and what is the resolution?
Thank you.
It's a common problem with automation. Some of the things you're doing such as "launching browsers" may not work for unattended execution.
A good example is Selenium, if you want to run web tests unattended then you need the headless version of Selenium, here's how to set it up for Headless:
Running Selenium with Headless Chrome Webdriver
We have a testing framework made in AutoIt for our Windows apps (older legacy apps that we will continue supporting). These have never been run on a schedule or part of CI (always been run manually). I tried to get some kind of auto run (or even just status reporting) out of the tests, with minimal luck.
I have a VM where the tests can run. I experimented with my own web app, which works okay locally for running and status reporting. But when set up on the server, AutoIt reports it cannot open the application. Same thing happens if I try to run the tests from a .bat file.
My current solution is to have AutoIt call my web app to report status (working okay locally, untested on the server), or to see if I can get AutoIt to report results back to TeamCity. I have the agent installed but when I run the build from TeamCity, AutoIt reports it can't launch the application. I tried this while logged into the VM, logged out, with RDS open; no luck.
Is it possible to run the tests manually from the VM and send results back to TeamCity? When I run them from TeamCity it reads the AutoIt output (which is in the expected format), but I need to let TeamCity know to update the results (so we can use TeamCity rather than my web app to show the results).
I may need to find a way to let TeamCity know a build has been started, which might then let it know to keep an eye on the process' output, but I'm not positive. Any ideas?
I solved this so it could be done more traditionally.
If anyone is confused by what "running the agent from the console" meant, it just means installing the agent without selecting the "as a service" checkbox, and then manually starting the agent by cd'ing to the BuildAgent/bin directory and running the command agent start. I also created a batch file that will do this automatically (but you must run it as admin).
Further, I found AutoIt couldn't do anything if the test doesn't run from the right directory, so I had to devise a solution to this.
The only issue now is that I have to have an old laptop always connected to the virtual machine the tests and app run on (since the AutoIt tests won't work without the VM desktop being interactive).
I have written and compiled an AutoIT script ("BiconNET.exe") which interacts with the user when double-clicked. While running, the taskmanager lists the program as an App.
Now, I would like to remotely start BiconNET.exe. So I installed and configured openSSH, Cygwin and Putty. Server and client run on Windows 8.1.
I create the SSH-connection using the windows login credentials from the server. I start BiconNET.exe through the Putty conmmandline and I see instantly BiconNET.exe pop up as a service in the taskmanager of the server. But no user interaction follows. The service remains silent, and BiconNET.exe doesn't do any of the tasks its supposed to do. What is wrong here?
I guess I need to achieve that BiconNET.exe runs as an App, not as a service!?
This is what I tried so far:
I tried a workaround using a batchfile, but same issue here: Doubleclicking the batch-file on the Server works fine (BiconNET.exe interacts with the user as wished), but running it through Putty BiconNET.exe gets listed as a service, not doing anything.
I also tried to auto-elevate the batch file using this code. No luck.
I excluded BiconNET.exe from the "Data Execution Protection" (DEP) in the advanced system properties of the server. Makes no difference
I would like to understand where the problem comes from, and how to solve it. Thanks for helping.
I have an program which I need to run on multiple PCs (>100) all in same domain and share the same user and password.
If I run a program manually, it opens a console windows where I can see the logs running. I can remote desktop and still be able to see the console windows open and logs running. It helps in debugging as I can see whats going on. Issue is I want to avoid running it manually on all PCs.
I have following requirement
a. It should be able to run program on multiple pcs remotely
b. program should open in foreground where console logs can be seen.
c. launching PC should launch program on PC1 and then (without wait for the program to finish on PC1) it should launch the program on PC2 and so on.
I explored STAF it needs to be installed on all stations. Its heavyweight, needs complex configuration.
I explored power shell , it needs to be enabled on all stations and also probably (read somewhere) has issue with running tasks in foreground.
psexec can run the program but it does it in background, if I use -i option I need to give session id so only it will show the console for a specific remote desktop session. Another major issue with -i is that it will interactive so it waits until the program exits.
Looked a paexe, its simillar to psexe and doesn't solve the issue I am facing with psexe.
Any help is greatly appreciated.
If you have a server, you can put the program on the server and create a shortcut to it (assuming the program is small/simple enough to run on a network share).
You can use One-Click to deploy the programs, and give each of your users a link.
You can change the program into a website for central access.
You can use group policy to deploy the program when a user logs in, assuming you can create a .msi file from it.
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.