I think a positioning of Mercury's product line is in order here. This should roughly parallel the Mercury sales presentation. Let's say your company needs to answer some questions, which tool will fit?
"Will this application work for one person?"
This is primarily a question that WinRunner automated tests, combined with manual tests will answer. The results of the tests are often stored in TestDirector as a repository to manage the testing process and report on progress.
"Will this application scale to my expected load and beyond?"
This is the primary focus of LoadRunner. To complicate matters further, LoadRunner supports two primary types of users. They are a GUI Virtual User (which actually takes advantage of a WinRunner script driving the application) and an API Virtual User. The second type is often referred to as a database virtual user, even though these API types of users could be Web, Sockets, a middleware interface, Java, even MAPI. The primary advantage of the API type of user of the GUI user is the ability to load many more "users" on a box for the generation of load -- It's amazing how small an application can become once you strip the GUI and a fair amount of application processing out of it.
"Why would I run both GUI and API virtual users?"
Consider a client server application like a birthday cake. The topmost layer, the frosting, represents the GUI. Users blow out candles, they press 'OK' buttons. The second layer down, consider this the application processing layer. Depending upon whether the application is "thin" or "thick" this might be visuall represented as either a wafer thin layer of chocolate ganache spread across the cake or a deep dark german rum soaked..... Well, you get the idea. The third layer down is the communication layer/Application protocol layer -- we'll call this layer 'red velvet cake. Once again, this layer could be fairly complex, some of the Java/Corba and COM/DCOM interfaces come to mind. Or, it could be relatively thin, such as running a terminal interface that resides barely above the sockets layer. The goal of running with the virtual users types for a similar transaction is to guage the weight of the GUI and the application processing layers of the client/cake. I have been part of a team that uncovered a GUI performance issue that resulted in high-speed video cards being purchased for a group of users, becuase it was cheaper to buy the cards, support them and deploy the application, than it was to re-engineer the application for better performance. For reference purposes, in the above analogy, the frosting and application procesing layers would classically be represented as the Application Layer in the OSI Model. The Communication Layer would be represented as the Presentation layer of the OSI Model.
So, while you can see that the two products have a seperate engineered focus, the decision to use WinRunner versus LoadRunner is not necessarily a mutually exclusive one because of the issue of the GUI Virtual user. We could even carry the questions forward to "How will I monitor this application for performance after it is deployed?" This would take us into the product definition of Topaz or even TAPM (Tivoli Application Performance Manager), which makes use of Mercury technology for performance sampling.
I hope this helps to clear up some confusion. If you have a chance to observe a Mercury sales presentation (I know, then you have to deal with all those "when are you gonna make a purchasing decision" sales calls) the role of each product should become clearer.
iTest Solutions, Inc