11 Answers, 1 is accepted
The Test Studio license is associated with a single machine, so that said you can use it on only one machine.
However, if you intend to use a machine for Execution server only, the minimum requirement as of Test Studio perspective is to install Test Studio Run-time. What is the difference between the Run-time edition and the complete standalone application can be read here.
I also reviewed your account information and noticed you have DevCraft Ultimate license along with the Test Studio one. Since the Test Studio plugin for Visual Studio is part of the DevCraft bundle, you can also install and activate this component on the remote machine, which you intend to use for test execution.
If you decide to go for this approach, you will need to configure the Execution server component, which also comes with the Test Studio Dev installation, to point to the Scheduler on your local machine. This will allow you to run tests on the remote machine.
I hope this information will be sufficient for you to find the best solution to cover your needs. Of course, if you have any further questions, please let me know.
Thank you for your understanding.
Thanks for that tip! So I've got the Test Runner on VM #2 installed, running, browsers calibrated, and connected to the Scheduling Server on VM #1. On VM #1 when I select Run List Remotely I can choose between the Test Runner on either machine. However I'm unable to run tests on the remote VM #2 machine. During this time the scheduled tests I have continue to run without any problem on VM #1.
On VM#1, Remote Execution Status shows Scheduling/Storage Alive and both Execution Servers Alive/Active.
On VM#2, the only "activity" I see when trying to run a test remotely is this...
[11/10 21:34:17,Telerik.TestStudio.Scheduling.Client.exe(7880:48),Framework] FireFoxInstallation.EnumFireFoxInstallations() : Valid Firefox 188.8.131.52 (x64) installation found at "C:\Program Files\Mozilla Firefox\firefox.exe".
The specific test list is configured to use Firefox. So VM #1 is talking to the TR on VM #2, but the test just does not run.
Thanks very much for the prompt reply about the current state of the setup.
I am not sure what could be behind the current inconsistent behavior you encountered, so I will need some additional details from your end.
First thing will be to check if there is a firewall active on any of the two machines. For testing purposes you can check what the remote execution behavior will be, if you disable the firewall. Or, directly include in- and out-bound rules for the following ports:
Scheduling Service: 8009
Storage Service: 8492
Execution Machine(s): 55555
If this still doesn't allow the remote execution, or is not applicable, please, clear the log files on the two machines, trigger a remote run on the second machine and give it some time. In a few minutes, you can collect the application logs of both machines and send them zipped for further inspection. The logs of both machines can be accessed through the execution machine details - double click a machine listed in the Execution status view, or open the Test Runner on the particular machine and use the logging buttons.
As a side note I would like to mention something in regards the message you noticed in the log of the remote machine - this is a standard message that a Firefox installation is detected and it is actually not related to the remote run. However, the logging may include any other details that will help me understand what the issue could be.
I am looking forward to hearing back from you.
Ok, I did have to open some ports that I found referenced here and in the docs. Once I did that, then the two machines were able to SEE on another and "connect". But then remote test just don't run.
So I turned off the firewall completely on both machines for all 3 profiles and ran the same test. Logs attached.
AHHH. I'm still curious what the logs above might reveal, but I need to update the host. When I downloaded the Dev edition, I failed to notice the late October release of Ultimate too. So my host doesn't have SP1 and is still on 1002.1.
Since the host itself has been running tests so smoothly - I'll snapshot it then install the upgrade - just in case :-)
After I've done that I suspect/hope the remote test might start working.
I reviewed the shared logs and I suspect that the mismatching versions are not the only possible issue. It seems that the database may be somehow corrupted and here is what you can do about it.
- If you have no other GUI tool to maintain the MongoDB, you can download and install their official one - MongoDB Compass.
- Open the Compass and connect to the default host listed in the Connect dialog.
- If there are any results, you need to keep, please drop the following collections - tests and testlists. If you do not need the results, you can drop the whole database.
Once this is ready, you can start Test Studio again and try to run a test list remotely on the remote machine. If this is again not successful, please, generate the logs for both machines again and send them for analysis.
Thank you once again for your time and cooperation.
Success. I took the easy route - for me. Stopped Mongo, wiped the entire db folder, started. Then started TS, picked the test list, run remotely, switched over, it ran. Well, after failing and then me installing the extensions and running again :-)
So, version mismatch is OK. But, given that the Mongo that TS installed earlier is old and an unexpected corruption caused scheduled test to stop running recently, I think I'll follow the steps you gave me earlier to remove it and let the SP1 update install a current version of Mongo. I noticed on a different machine that the current version seems to install a Mongo database tool as well.
Duh, forgot one of the secret steps. Re-uploading scheduled tests from the Results view after a database wipe #facepalm
Scheduled test kicked off right away - seemingly trying to "catch up" - running one right after the other, instead of in the 5 minute intervals. I've seen this before after restarting. Not sure what the logic is, maybe catch up to what should have run in the past hour?
Tomorrow I'll see if remote execution still works :-)
At least I'm on SP1 now with up to date MongoDB and a better db browser util.
Thanks for sharing details on all performed actions. It looks like all our previous discussions were useful and helped you find the solution to fix the remote runs. I suppose that these are still running smoothly, but if there is anything else you need to share along, please, do not hesitate to get back to me.
Thank you once again for your cooperation.