AsmoconX wrote:
This is a test environment and information is not meant to be added or modified on the remote systems (for validation and testing requirements). The test-process requires us to login to the system using a Remote Desktop Connection and perform a set of tests within that Remote Desktop Environment (Again, the remote system does not have other connection methods such as USB, PS2, VGA, etc..Just a console network line plug). The remote PCs already have the operating system installed, configured, and have specialized test-programs pre-loaded onto them that must be ran for validation purposes.
After we login to the remote system, we perform multiple days worth of tests using the software already on the remote system.
The end-goal was simply to find a way to let individuals know when a test has completed or had an error. The program would be able to detect that completion/error window within the remote desktop window and turn on a light, send an email to the operator, and various other things.
There can be 20 different systems testing like this and each Test-PC must be monitored to see when it is time for a new action. So, the final objective is to reduce the time lost because a person is unable to go turn on each monitor, check the remote display, act if needed or turn display back off and continue check the other displays. If the event could be relayed, like I was saying through a program that was monitoring the remote window, they would not be occupied checking systems that may not even require attention yet.
I honestly do not know how else to explain it. :(
Now, the problem is properly explained, thank you.
Well, the whole testing scenario simple questionable to me, but I can imagine setting where such scenarios have a write to exist. I hoped to find some available products for this kind of testing, but it's going to take a lot of time. Please see:
http://en.wikipedia.org/wiki/Test_automation#Graphical_User_Interface_.28GUI.29_testing[
^].
Review this list of tools:
http://en.wikipedia.org/wiki/List_of_GUI_testing_tools[
^].
Perhaps you may need to test some of them and evaluate.
It's good to get more familiar with many different approaches to testing. See also:
http://en.wikipedia.org/wiki/Software_testing[
^].
Now, as I cannot give you my final verdict on using any of the particular available tools, I'll explain how the tool you need has to work. It will also explain to you how can you develop such tool on your own. It is not going to be easy, but I've done such things, they are doable. I'll start with the simplest scenario.
Here is the idea: as a user, you can connect using RDP (in your case, you should not and need not create anything custom) and do all the testing manually. Then you need to repeat the test many times. The only problem that the human operator cannot repeat it many times, especially if you need to do it consistently (I say, this is still the simplest scenario). Now, imagine that you have some spy application which records all the system-global mouse and keyboard events and can play them back on your whole testing system, to complete all the test cycle from the beginning to the end. Some of those events will go to RDP client window, and RDP will transparently pass them to the computer under the test, and that remote computer will reproduce all the actions of the human operator.
How to implement it? Not very easy, but quite doable. First of all, recording. You will need to use Windows Hooks. Please start here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632589%28v=vs.85%29.aspx[
^].
There are two approaches:
- You can use just the local hooks. This is much simpler than the global hook. You need to set the
dwThreadId
; and this should be the thread of the RDP client. The biggest simplification is: you can do it all in .NET, using P/Invoke:
http://en.wikipedia.org/wiki/P/Invoke[^],
http://msdn.microsoft.com/library/en-us/vcmxspec/html/vcmg_PlatformInvocationServices.asp[^].
One considerable benefit of local hooks is: all the events unrelated to your RDP client go out of equation.
A little problem is: it may require a custom RDP client which can host the hook in its code, which is actually good for development and testing. This is not a biggest problem: you are already familiar with RDP clients, don't you? :-)
- Nothing like that can be done with global hooks. If you specify no thread, the hook will be system-global. They are hard to develop, event harder to test. And you cannot do it all in .NET. You will have to develop some native (unmanaged) DLL setting the hook and doing hook handling. According to Microsoft documentation, such DLL is required if the hook is global. You will need to load this DLL in your .NET code and communicate with the hook functions using some thread synchronization mechanism.
In all cases, the hooks should detect all the mouse and keyboard events (only related to a RDP client, in first approach shown above) and record those events in some form in some file. Testing, essentially, will be playing them back. (Still, we are at the simplest scenario.)
There is only one way of playing those events back: the raw Windows API
SendInput
:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646310%28v=vs.85%29.aspx[
^].
You can use it in your .NET code using P/Invoke, but everything is already done for you:
http://www.pinvoke.net/default.aspx/user32.sendinput[
^].
Now, how about the complex scenario? You may need to create more complex tests, when the user events are not just recorded, but also modified during testing based on some calculation. Also, you may need to modify timing, to improve performance of the test. If can create one very serious problem: you might feed the simulated events to the system faster than they can be handled on a remote computer, with all the time lags, especially network traffic. When it happens, the test is totally broken: you may send events to non-existing controls, or controls not located where you click with the mouse, and so on. Well, the test itself needs to be tested somehow, but the accelerated test may become unreliable, because of some possible traffic gems on the network, and the like.
In essence, you may need to have not a user-mocking machine, but some intellectual testing robot. Well, then you would need to develop some language of testing scenarios based on key/mouse event primitives, combine recorded event sequences using some branching, conditional or not, looping or not, and a lot more. Good work to be done.
So, first of all, review some available UI testing tools.
—SA