Winrunner/Xrunner Slave awaits commands.
Commands via files arriving in $HOME
Processed upon custom protocol language.
Drive software events via command language.
command could look like this.
Commands arrive via TCL based manager/director solution.
A director stages the test and sends and controls the commands to the computers under test. The TCL manager residing on the test computer receives the commands and places the files in the $HOME folder.
The test language can be crafted using TCL code that is sourced into the director. This allows for a rich development of test data to drive the slaves.
Yeah. I was 10 years ago with a tool called Automated Test Facility (ATF) from Softbridge. It ran on OS/2 and Windows. It was a true Client/Server test tool. A controller machine (Executive) talked to the workstations (Agents) on the LAN. From a central controller you could send tests to multiple machines in the network. It was a cool tool. Unfortunately they died. Didn't make the transition of the Executive machine to Windows NT fast enough and Segue & Mercury ate their lunch.
You can find the same type of functionality in Segue Silk when you implement a Master and Agent scenario. You have to create the Master script (machine) and have it talk to the Agent machines on the network and send the test scripts (jobs) to them. I have not seen this done for a while.
This is nothing new. Just that a lot of the tool vendors will push you to do functional testing on a one to one setup and if you need to simulate load they push you to the load test tool.
I know a couple of other people here are ex-ATF (not Arms, Tabacco and FireArms) users. Wanna chime in guys?
we are implementing this type of scenarion into our functional testing. We have built a controller ourselves using perl script and have set up several machines with different software configurations as a test bed. We have also created a web based portal were QA Analysts can schedule and run tests for different products. The controller/portal will then find the machine which fits the request and run it on that machine. If the machine is already in use, the controller will queue all other requests for that machine untill it is available. The results are automatically publish to the controller/portal for the QA Analysts to review upon completion.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by jimhazen: Yeah. I was 10 years ago with a tool called Automated Test Facility (ATF) from Softbridge. It ran on OS/2 and Windows. It was a true Client/Server test tool. A controller machine (Executive) talked to the workstations (Agents) on the LAN. From a central controller you could send tests to multiple machines in the network. It was a cool tool. Unfortunately they died. Didn't make the transition of the Executive machine to Windows NT fast enough and Segue & Mercury ate their lunch. <HR></BLOCKQUOTE>
(sigh) Unfortunately, we couldn't get the money required to transition to Windows fast enough (technically, as well as from a marketing and sales standpoint).
Mercury, Segue, and Rational ate our lunch! (Coulda been a contenda!)
It was a good setup, but not enough of a differentiator to make up for the lack of investment in the company.
As stated before, you can certainly simulate the Executive/Agent (or Master/Slave if you prefer) setup with other test automation tools. While it will not be a true client/server situation, and could miss some of the power of ATF, it can save license costs, as well as running around to manually run many machines.