Win Runner

One of many regression testing tools that automate testing by feeding gui events into the program. These programs have proven their value over and over, but still may not be robust enough to meet xp's acceptance testing demands.

What demands, exactly? That a rapidly-changing code base not break scripts? Please clarify.

Does a free implementation exist? Nothing fancy - just some way to express this: Click x1@y1, wait .5 sec, click x2@y2... etc. How would one research the Win32 API to figure out how to do this?

There are currently no free implementations. To be useful, an implementation needs to be able to recognize window controls and allow gui events to be sent to particular controls. Also, you don't want to have to use hard-coded waits ("wait .5 sec"). They easily allow tests to fail semi-randomly, which will drive everyone nuts. Instead, you need to have your tests synchronize themselves to the gui.

I must admit, I've not used windows seriously since Windows 3.1, but back then it came with "WindowsRecorder?" whereby you could run it, do something and "record all your actions", and play them back later. I'm not sure if this helps, but just something I remembered. :) -- PerryLorier

Unfortunately, that one is gone since Windows 95, I think.

Yeah, WinRunner is really good. We use it at Siemens Medical Solutions to run automated tests.

I just started with WinRunner, googled for WinRunner and perl(PerlLanguage) (just to see if there was anything interesting combining the two), and found this page. When we record events with WinRunner, it inserts some inappropriate commands/events, and misses others (we are using it with Gupta/Centura SqlWindows). So I wrote a PerlLanguage "fix-up" script to correct those things. Otherwise, yes, WinRunner is impressive.

Okay I've been using WinRunner for awhile now, and although it's still impressive, it's not the panacea that our company would like it to be. Part of it is our fault (in application design), and some is due to the limitations of WinRunner. As far as the 'our fault' part, it would have been a lot better if we had designed the application from the ground up in a way that separated the application/business/presentation logic. As far as limitations, we have to hack the automatically generated GUI maps for objects so that they are correctly identified. Windows has id's which will uniquely identify widgets, but you can't rely on them to stay the same when you recompile your app, so you have to identify them by other means, sometimes using regular expressions on the data in the title bar for form widgets (in our app, the title bar can changed based on what 'mode' you are in or what 'database' you are using. Maybe that's another 'our fault' part :). Coming from a PerlLanguage background, I'm glad that the WinRunner programming language has certain features, like multi-dimensional associative arrays, but I'm less than happy with the way they are implemented. You must always specify all dimensions, and can not, e.g., use the first three dimensions of a four dimensional array to assign to a temporary variable.

Another useful page is WinRunnerFaq.

WinRunner was distributed by Mercury Interactive at http://www.mercury.com and has ben sold to HP.

https://h10078.www1.hp.com/cda/hpdc/fetchPDF.do

Find out more about Mercury WinRunner at http://www.mercury.com/us/products/quality-center/functional-testing/winrunner/.

There is an unofficial mailing list for users at Yahoo Groups: http://groups.yahoo.com/group/winrunner

Another site for related articles is http://www.qaforums.com/.

Alternatives - Commercial

RationalRobot
Silktest
Compuware QARun or TestPartner

Alternatives - No cost

AutoIt: http://www.hiddensoft.com/AutoIt/ (primarily geared towards GUI automation rather than testing, but still useful)
Perl GUI test engine, http://groups.yahoo.com/group/perlguitest, also http://search.cpan.org/src/CTRONDLP/Win32-GuiTest-1.50.3-ad/readme.html

Test Frameworks

Robot DDE, keyword/data-driven engine, can now use WinRunner, at http://safsdev.sourceforge.net

Cut and pasting advertising material isn't really the WikiWay ,but makes the understanding to the problems in testing more sensibel!

EMOS FRM framework, keyword/data-driven engine using excel spreadsheets

http://www.emos.de

Yahoo group for users of EMOS framework with good support from Autor and more nice things. Information and help in developing automated keyword and datadriven modular block structured tests with Winrunner, using the EMOS framework which is totaly integratet and written in "TSL", available under the Lesser General Public Licence (LGPL)!

"Join This Group" and "Sign in" for download the Framework at "Links"!!!

Welcome to EMOS_Frame group - the forum for users of EMOS Framework.

http://groups.yahoo.com/group/EMOS_framework/

Welcome to EMOS_Frame Yahoo! group - the forum for users of EMOS Framework! EMOS Framework is an advanced technique for development of automated regression tests with WinRunner. Through its holistic approach EMOS Framework is suitable for rapid creation of new WinRunner projects. Through its open API and 100% TSL implementation it is well suited for integration into existing WinRunner projects, too.

The philosophy of EMOS Framework is based on an optimal balance between test tool (i.e. WinRunner) expertise and generic testing expertise. We presume that very good tool expertise is always seldom in real projects. EMOS Framework was designed to make the experienced WinRunner specialists more productive. This may significantly change the way you perform automated testing with WR in future.

Novices to WinRunner may still find EMOS Framework interesting as it contains plenty of useful routines and code examples. It may prove helpful in justifying the limitations of capture & reply technique and, so to say, speed up the maturing process.

The most effective way to start with EMOS Framework is by doing a pilot project accompanied with some good consulting/training. There are, of course, plenty of reasons not to do it this way. :(

The second best way to learn about EMOS Framework requires lots of reading and experimenting on your own:

download & install the base software

download EMOS Framework v1.4.1.3 http://groups.yahoo.com/group/EMOS_framework/files/EMOS_Framework_1_4_1_3.ZIP

Note The installation procedure has changed! Unzip the file under your current winrunner lib folder (e.g. c:/program files/mercury interactive/winrunner/lib) or anywhere else you like.Then modify your statrup test to call emosinit directly (see modified startup script in EMOS_GPL\FRM\TPL directory).

download EMOS Framework API Documentation v1.4.1.3 http://groups.yahoo.com/group/EMOS_framework/files/EMOS_Framework_api-doc_1_4_1_3.zip

read some backgrounds http://groups.yahoo.com/group/EMOS_framework/files/EMOS Framework Article.doc

read more backgrounds EMOS Framework article

http://www.cbueche.de/persnlich.htm#EMOS download slides(in particular "Introduction", "Basics1" & "Basics2 download, install AND analyse the FlightDemo? and/or MercToursWebDemo?

download FlightDemo? v1.6

http://groups.yahoo.com/group/EMOS_framework/files/FlightDemo_1_6.zip

download MercToursWebDemo?

http://www.cbueche.de/persnlich.htm#EMOS

start with "Readme.html"

read FAQs

http://groups.yahoo.com/group/EMOS_framework/files/FAQ/

copy template project TPL, run, analyse & make your own project with it(<wr_install_dir>/lib/EMOS_GPL/FRM/TPL)analyse EMOS Framework code (again)

  (<wr_install_dir>/lib/EMOS_GPL/*.*)

download & experiment with EMOS Framework Wizard http://groups.yahoo.com/group/EMOS_framework/files/emos_frm_wizard.zip