| || |
README BEFORE POSTING
Welcome to QA Forum's WinRunner Forum!
We invite you to begin your involvement in this forum by reading the text behind the FAQ link: http://www.qaforums.com/faq.html
Once you have completed reading that, continue reading below for information about:
CPS or CPI exam questions - Paragraph 1)
Topic naming - Paragraph 2)
WinRunner Documentation, Training, and
Basic Questions - Paragraph 3)
WinRunner Demos or Eval copies - Paragraph 4)
About Moderators - Paragraph 5)
Searching for Answers - Paragraph 6)
Asking Questions - Paragraph 7)
Versions - Paragraph 8)
If you subscribe to - and practice professionalism, courtesy, patience, and respect; you have come to the right place. As a member or user of this forum, you are expected to uphold and promote those standards.
1) CPS/CPI Exam questions:
This forum subscribes to Mercury-Interactive's (MI) CPS/CPI exam policies. Choosing to bypass those policies is not tolerated in this forum. To the extent possible, moderators and members/users of this forum shall enforce MI's CPS/CPI exam policies in order to preserve the automation test engineering profession. Regarding the expectation that the moderators would notice CPS exam questions: It is an unreasonable expectation to think that moderators watch this site and all posts 7x24 (as previous posts have suggested). Remember, this site is used globally across all time zones. Also, moderators do have full time jobs. Moderating this forum is a collateral task. Also, what if any/all moderators have not taken the CPS or CPI exams? How would the moderator recognize a CPS question?
2) Topic or Question Naming:
It is best to name your topic something meaningful in order to get the right kind of attention in a timely manner. Not every forum member has time to read every word in every topic. Proper naming of a topic makes it easier for a member to understand that they may be able to help you. Below 2.1 and 2.2 are some examples of bad topic names:
2.1) "WinRunner Not Working" (This example is not specific enough and can lead to many time-consuming questions and answers to identify the specifics. Precision naming of topics leads to faster responses.)
2.2) "WinRunner" (This doesn't offer a clue about your issue.)
Below items 2.3 and 2.4 are examples of well-named topics that will quickly attract someone who may help and has experience with that topic:
2.3) "Retrieving CPU usage on remote machine" (This example allows readers to quickly filter and determine if they have experience with this topic or something similar.)
2.4) " Get text > from selection (web test only) not working" (This example also allows readers to quickly filter and determine if they have experience with this topic or something similar.)
3) WinRunner Documentation, Training, and Basic Questions:
WinRunner is packaged with comprehensive documentation, TSL examples, and a tutorial. It is to your advantage to use these to build your basic skills. This forum frowns heavily upon those who do not do the work or do not walk those basic skill-building steps and, will communicate that feeling without reservation. Pride and professional standards dictate that we exercise our common human desire to help. However, we stop short of doing your work for you! Do the work, read the manuals, do the tutorial and take a class. Regardless of how tedious or difficult it may seem, the rewards you reap will far outweigh the pain of having walked these steps. Also, bear in mind that WinRunner is a tool to be applied by an experienced testing professional. It is best to get educated about testing before attempting to use this tool. A poorly educated test engineer attempting to apply this tool will erode the belief by many, that this tool can contribute to the success of quality software development.
4) WinRunner Demo / Eval Copies
"Call Mercury or Mercury partner to get an evaluation version."
Via web: Contact www.merc-int.com
Note that you can get training via: http://www.qatraining.net/
5) About Moderators: Moderators are Volunteers!
When moderating this forum - moderators are required to act in accordance with the specifications of the FAQ.
Regarding tool expertise - moderators of this forum should not be expected to be the top experts for WinRunner. WinRunner, like many development tools is vast and rich in capability and extensibility. Those attributes provide for both a long learning curve and lengthy process for one to become a true expert. True experts are few. In this forum we rely upon the talents of many. Those talents represent a vast knowledge base upon which this forum has built its success. By default, the moderators rely on this vast array of talent to help all who come here in true need of help.
6) Searching for Answers:
Remember to use the extensive Search capabilities of this forum. There is a good chance that what you are looking for has been addressed.
7) Asking questions:
Please give thought to your question before posting. Add context to what you are asking and if necessary - describe what you are trying to accomplish.
8) Versions: (added 2004/01/26 by Charles Reace)
When trying to resolve a problem - especially compatibility problems - it is often useful to know which version of WinRunner is being used. Therefore it is a good idea to include which version of WinRunner you are running along with which add-ins are being used. If performing web-based testing you should also let the reader know which browser(s) and version(s) you are testing against.
Please make it a point to post a followup reply to your post letting the people know, who responded to your post if any of the directions or solutions helped you.
Thank you for being a part of this forum and this global team of solution providers. Let us grow together!
[This message has been edited by jpensyl (edited 05-07-2003).]
[ 01-26-2004, 11:56 AM: Message edited by: Charles Reace ]
Re: README BEFORE POSTING
WinRunner Coding Standards
Here is a link to a WR coding standards document I found....I hope that it is helpful...
Additional coding standard documentation...
Here are some additional coding standards...
Re: README BEFORE POSTING
by devtester: Running TDAPI from WR
After weeks of working with Mercury and finally getting the TDAPI functions in the right order, here's sample code to connect WR 7.5 to TD 7.6 and run a script located on TD:
# code to run the TDAPI functions
ScriptPath1 = "[TD]Subject\\5.10.07\\";
ScriptPath2 = "[TD]Subject\\\\5.10.07\\\\";
ScriptName = "myScript";
m_root = getenv ("M_ROOT");
report_msg("M_ROOT=" & m_root);
load(m_root & "\\lib\\tdapi",0,1);
# Initialize the TestDirector server
if(TdServerInitInstance("apartment", "http://TDServer/tdbin/wcomsrv.dll" ) != TDAPI_NOERROR)
# Connect to TestDirector_Demo project
if(TDAPI_Connect("PRODUCTION.Automation_Developmen t", "5.10.07", "jsmith", "987654") != TDAPI_NOERROR)
# find test
if(TDAPI_FindTestBySubjectPath(ScriptPath1 & ScriptName, TestKey) != TDAPI_NOERROR)
# Create new run
if(rc2 = TDAPI_CreateRun("517", TestKey, "New Run 2", "jsmith", ScriptPath & "AdmitPatient", RunKey) != TDAPI_NOERROR)
# run the script locally, but script resides on TD
e v a l("call \"" & ScriptPath2 & ScriptName & "\"();");
# call will work below, but we want to parameterize the function call as above
rc6 = TDAPI_Disconnect();
rc7 = TdServerRelease();
More on TDAPI http://www.qaforums.com/cgi-bin/foru...c;f=4;t=009371
Re: README BEFORE POSTING
by jpensyl: EXTREME WinRunner Exam
Looking for help using WinRunner? This is a short exam to help you decide if you are ready to use this forum. Some things to ask yourself before asking here at this forum.
1) Have you received training - or substitute in another language or - you are self-trained?
2) Have you completed the tutorial that ships with WinRunner - or have a useful and proven level of understanding?
3) Do you use the TSL Online help available through the Help Menu - and the examples included?
4) Have you searched this forum for answers to your questions?
5) Do you use the User Guide?
6) Did you read the readme.wri file?
7) Do you have a legal copy of WinRunner?
8) Do you know how to manually test without tools such as WinRunner?
9) Did you read the postings at the top of this forum?
10) Did you read the FAQ?
Scoring your answers:
Number of YES answers =
10 = You are ready to use this forum
9 = You have more work to do.
8 = You have more work to do than 9.
7 = You have more work to do than 8.
6 = You are far from being ready to use this forum and WinRunner.
5 = You have much much work to do.
4 = I'm beginning to think you may not be the resourceful type.
3 = Come on, this isn't difficult.
2 = Responsibility is a trait that is yet in your future.
1 = Consider another career.
0 = You are most certainly using an illegal copy of WinRunner. Your questions are most certainly not welcome here.
Re: README BEFORE POSTING
by jgottlieb: Mercury Interactive, WinRunner, and QuickTest Pro
<h1 align="center">Mercury Interactive, WinRunner, and QuickTest Pro</h1><h2>Introduction</h2>This document was created because of the major amount of confusion out there about Mercury's intentions with WinRunner and QuickTest Pro. There have been a lot of questions about whether scripts would have to be converted, thrown away, or be reusable. I talked with Mercury over the span of a couple conference calls to get things cleared up. The content and direction of the this document comes from questions that were offered by QAForums users and questions that I had for my own knowledge.
This thread should not be replied to, please reference it in other threads. Thanks. I will update this thread as needed, with information confirmed by Mercury.
From what I have gathered from questions that I've been asked and the statements that I'm hearing, I think *most* of everyone's fears about this new dynamic can be summed up with what Mercury has been saying all along:
<p align="center">WinRunner and its support are not going away.
Now, the 'how will things be handled in the future' and 'will WR do this and will QTP do that' issues are going to take some discussion. So, here we go.
"Ok, I got QTP and I've got an app that I'm testing with it. What about my WR stuff? Should I just throw those scripts out?" No, no, no. Again, I say, "No." QTP is going to (if not already) have the ability to launch WR and have your scripts run. You're not going to lose all the scripts, etc. that you've built. You've had your WR scripts call other WR scripts before... it's going to be the same concept. And what's coming in the "near future" is a centralized results set. Where you run your WR/QTP scripts and they call QTP/WR scripts and your reported results at the end of your test run are all in one place.
So an environment that has been using WR and need a .NET solution would build .NET app scripts in QTP and:
<font size="2" face="Verdana, Arial, Helvetica">Mercury understands that with some 10,000 WR customers, there's an inordinate amount of architectures, frameworks, harnesses... there's no way to come up with one catch-all that will "convert" WR stuff to QTP stuff. So the idea is to reuse WR stuff via the QTP/WR Integration.
- <font size="2" face="Verdana, Arial, Helvetica">Have your WR scripts call your QTP/.Net tests</font>
- <font size="2" face="Verdana, Arial, Helvetica">Run your QTP/.Net scripts and call your WR scripts as needed.</font>
Let me reiterate this again, so there is no confusion:<ul>[*]WINRUNNER AND WINRUNNER SUPPORT ARE NOT GETTING PHASED OUT.
[*]WinRunner will be able to call QuickTest Pro scripts.
[*]QuickTest Pro will be able to call WinRunner scripts.
[*]What one cannot do, the other will.[/list]<h2>Licensing</h2>To review, there are two ways to licenses a product: node-locked and floating. Node-locked refers to assigning the app to one machine; floating allows a license to be shared between machines at any given point in time (2 floating licenses allow the app to be accessible from an entire lab's worth of PC's but can only have 2 instances running at any given point in time).
Before I continue, I need to state that I cannot tell you exact pricing that MI has set up for the licenses, however, I *can* give you an idea of what costs more one way than the other.
That said, we've got:<table border="1" cellspacing="0"><tr><td width="45">WR</td><td>Node-Locked</td></tr><tr><td width="45">WR</td><td>Floating</td></tr><tr><td width="45">QTP</td><td>Node-Locked</td></tr><tr><td width="45">QTP</td><td>Floating</td></tr><tr><td width="45">OFT</td><td>Node-Locked</td></tr><tr><td width="45">OFT</td><td>Floating</td></tr></table>
OFT? What's that? That is the new "Optane Functional Testing" license (NOTE: This is a working name for the license, it may change). It is WR and QTP with the integration. I'll get to that later....
If you're using WR and now need the ability to test in an environment not supported by WR, you have 3 options:
- Upgrade WR to QTP. You LOSE WinRunner here, trading it in for QTP. If you don't have a whole lot invested into WinRunner yet, and you don't need to test in environments exclusive to WR, this might be a viable option for you. If you have thousands of WinRunner scripts, this probably is not the way to go.
- Add QTP. Given that there will be (is) an integration for WR and QTP, adding a couple QTP licenses may be an option.
- Move to the Optane Functional Testing license. You can either purchase these outright or upgrade your WR license to an OFT license. Upgrading a WR license to an OFT license sounds a lot like adding QTP, right? Sure does. But it’ll costs less.
It's VERY IMPORTANT to consider your node-locked vs. floating schema here. I can't tell you which way to go. You need to look at your lab environment, and how many licenses of which you really need, but there are some caveats to this:
<ul>[*]1 node-locked OFT license allows you to have both WR and QTP installed on ONE MACHINE, and a WR/QTP script can call a QTP/WR script, on the one license.
[*]1 floating OFT license allows you to have ONE INSTANCE of WR or QTP active, accessible from MULTIPLE MACHINES. That means if you are in a floating license schema you CANNOT HAVE ONE APP CALL THE OTHER'S SCRIPTS WITH ONLY ONE FLOATING OFT LICENSE. Those in smaller companies need to take this into consideration.[/list]Big confusion: The original information about Optane Functional Testing licenses did not give the impression that there was a node locked option. It looked like there was going to be "out of reach" costs to get into WR/QTP. Mercury is going back to the wording on how the FT licensing schema is being described and make it less confusing.
There will even be a CD install for OFT: It will have both WR and QTP installs on the disk. Expect to see this at the end of Q2 with the QTP 6.1 release.<h2>WR/QTP Comparisons and "In The Future"</h2>WinRunner 7.6 is scheduled to come out next quarter. WinRunner 8.0 is scheduled to be released at the end of the year. Beyond that, yes, there will be enhancements made to WinRunner.<div align="center"><center><table border="1" cellspacing="0"><tr><td align="center"><h3>WinRunner</h3></td><td align="center"><h3>Both</h3></td><td align="center"><h3>QuickTest Pro</h3></td></tr><tr><td align="center"><h3>Classic</h3></td><td align="center"><h3>Common</h3></td><td align="center"><h3>Emerging</h3></td></tr><tr><td valign="top">Custom C/S<ul>[*]PowerBuilder[*]Forte[*]Delphi[*]Centura[*]Stingray[*]SmallTalk[/list]
ERP/CRM<ul>[*]Baan[*]PeopleSoft Windows[*]Siebel 5, 6 GUI Clients[*]Oracle GUI Forms[/list]</td><td valign="top">Web-Related Environments<ul>[*]IE, Netscape, AOL[*]JDK, Java Foundation Classes, AWT[*]Symantec Visual Café[*]ActiveX Controls[/list]
ERP/CRM<ul>[*]Oracle: Jinitiator, 11i, NCA[*]JD Edwards Web Client[/list]
Custom Client Server<ul>[*]Windows[*]C++/C[*]Visual Basic[/list]
Operating Systems<ul>[*]Win 98, 2000, NT, ME, XP[/list]
Legacy<ul>[*]3270, 5250 Emulators[*]vt100[/list]</td><td valign="top">ERP/CRM<ul>[*]mySAP[*]Siebel 7.x[*]PeopleSoft 8.x.[/list]
.NET<ul>[*]WinForms[*]WebForms[*]NET controls[*]Web Services[*]XML[*]WSDL[*]UDDI[/list]
Multimedia<ul>[*]RealAudio\Video[*]Flash[/list]</td></tr></table></div></center><p align="left">For both WinRunner and QuickTest Professional, Mercury Interactive will support all currently supported environments with market traction. Examining the environments supported by WinRunner and QuickTest, one can classify them into three groups: Classic, Common, and Emerging.
<ul>[*]Classic: environments supported by only WinRunner. Includes client server environments such as PowerBuilder as well as older ERP/CRM applications such as Siebel 5 and 6.
[*]Common: environments supported by both WinRunner and QuickTest. Includes IE, Netscape, Windows, Java, Visual Basic, and terminal emulator (“green screen”) applications.
[*]Emerging: environments supported by only QuickTest. Includes .Net; newer ERP/CRM environments such as mySAP and Siebel 7.x; and Macromedia Flash.[/list]Mercury Interactive is committed to providing ongoing support for WinRunner in all Classic and Common environments, and is committed to ensuring that QuickTest works in all Common and Emerging environments. This means that, for instance, when a new version of PowerBuilder is released and gains market acceptance, Mercury Interactive will build support for that new version of PowerBuilder into WinRunner. When a new version of IE is released, Mercury Interactive will build support for it in both WinRunner and QuickTest. As new versions of .Net, SAP, and Siebel are released, Mercury Interactive will support those environments in QuickTest. This level of environment support will continue through 2003 and beyond. Mercury Interactive’s goal is to ensure that customers can continue to realize the benefits of using our functional testing solutions in their existing environments as these environments evolve.<h2>QuickTest Pro and...</h2><h3>...TestDirector</h3>The integration of QTP and TD is the same as it is for WR and TD. Test Sets, Test Runs, etc. are able to be created using QuickTest Pro scripts. Since TD can handle both WR and QTP scripts in a Test Set, both can be in the same run.
<h3>...MS Excel</h3>Just like you can create data tables using Microsoft Excel for WR scripts, you can do the same thing for the QTP data driven scripts that you will create.
<h3>...Databases</h3>According to Mercury, database testing via QTP is equal or better than via WR. QTP has:
<ul>[*]Enhanced ODBC database import engine.
[*]Provides same DB verification wizard that is in WR
[*]Open extension of VB engine (COM based replay engine: can make direct calls to ODBC db at the object level)[/list]<h2>Conclusion</h2>There was a question about when to use one over the other outside of a scripting preference. QTP has reusable actions, icon based script, active screen, and an integrated data table. It is really up to the individual and how your environment is going to get set up. Those that are new to automated testing may find QTP easier in the long run. According to Mercury, many of the “lessons learned” from WinRunner have been incorporated into QTP.
There are certain environments that WinRunner won't be able to go. This may be a matter of business decision or simply WinRunner's architecture. The impression that I got from my conversations with Mercury was that they have no intention of abandoning WinRunner or its users. Mercury is responding to market conditions where there is a greater focus on QuickTest Pro. So you may have to use a QuickTest Pro solution, but you won't be forced into phasing out WinRunner.
Which way should you go? Again, that depends on your environment. If you have been using WinRunner and now you find you need QuickTest Pro, there are a number of upgrade paths available. You'll be able to trade in licenses, add, convert, etc.
Re: README BEFORE POSTING
by bpolitzer: DB_CONNECT
The steps for connecting to any database are the same.
1) Create an ODBC connection (also called a DSN - data source name) to the database.
For this you will need an ODBC driver. For microsoft databases (Access and SQL Server), the ODBC driver is usually included in the operating system. For other types of databases, you will need to install the client software.
2) Insert the db_connect function from the function generator.
a) Create->Insert Function->From Function Generator
b) Select db_connect
c) Press the Args>> button
d) Next to Connec Str, pres the ... button
e) The select data source dialog appears
f) Select the data source created in step 1
g) enter your username and password
f) the connect string is generated for you!
g) press the paste button to paste the function in your script!
Insanity: doing the same thing over and over again and expecting different results