You might have already heard that it will be possible to add your own features to VuGen when version 11.5 is released mid-year. I will be talking about this in more detail in my “Extending VuGen 11.5 with Custom Add-ins” talk at HP Discover 2012 in June.
In the meantime, I have decided to share some of my add-in ideas. Please feel free to develop these add-ins yourself. After all, ideas can’t be copyrighted, and I would prefer to buy or download someone else’s add-in rather than spend time developing them myself.
Here are my ideas…
The most obvious idea, when talking about add-ins, is to create an add-in that will bring back the Add-in Manager that has been hidden in VuGen 11.5. This will make it painless to add/remove/enable/disable all the other add-ins that people are sure to create.
Update: I am working on this, and it will be available for download here.
Version Control Integration
One of the most frequently requested LoadRunner features is version control for scripts (although I would argue that what LoadRunner really needs is audit logging instead). VuGen currently has integration with Quality Center/Performance Center/ALM, which allows you to use it as a script repository, but this is storage, not versioning, and it can be slooooow when the scripts contain a lot of files.
I think that it would be good to have a simple check-in/check-out button on the toolbar that would allow you to store your scripts in the same version control system the development team uses (Git, Subversion, Visual SourceSafe, etc). HP should not be re-inventing the wheel for source code version control.
Purge Saved Cookies from Internet Explorer
When you record a web-based VuGen script and the first thing you see in the script is web_add_cookie() functions, then this means that you already had persistent cookies for that site stored in Internet Explorer. This means that your VuGen script is emulating a returning visitor (with an empty cache), rather than a new visitor. One solution is to just delete all web_add_cookie() functions, but it can be difficult to differentiate between cookies that were stored in your browser, and cookies that were set using client-side code (which might be needed for replay).
It would be much easier if VuGen made it simple and painless to remove all cookies from IE before recording, either with a toolbar button, or with a recording option.
Remove Used Data
Imagine that you need to run a load test with a script containing a file-based parameter that can only be used once (e.g. loyalty card ids for a “register loyalty card” business process). If you make the file parameter “unique”, LoadRunner will ensure that it is only used once across all of your virtual users, but the next time you run your test, LoadRunner will re-use your data unless you manually remove the parameter values from the file.
A work-around for this problem is to write the used data to a file and then, after the test, find a way to remove the used data from the parameter file (maybe using Excel or a shell script). This add-in would make removing the used data painless.
The suggestion in the official LoadRunner training that you just refresh/rollback the database every time you run a test is not worthy of discussion.
LoadRunner Data Pools
LoadRunner has no way for virtual users to share information. This becomes a problem when you have business processes that have dependencies between different vusers, such as “worker submits timesheet”, “manager approves timesheet”. A bad solution to this problem would be to have each script log in as a worker, submit a timesheet, log out, log in as a manager, approve the timesheet, log out, repeat. This will create an unrealistic number of manager logins during the test.
A better way to handle it would be to have separate scripts for workers and managers, and to share the timesheet ids between the scripts with a database table (tricky code) or with VTS2 (tricky code, poor performance).
I would like to see a VuGen Add-in that changed parameters from being read-only, visible to a single vuser, non-unique between tests to being:
- Shared between all vusers.
- Consumable, so they are only ever used once (this solves the same problem as the “Remove Used Data” add-in, but in a better way).
- Dynamic so that a list of parameter values can be added to, not just read from.
I think that this could be implemented as an add-in fairly easily by combining a real database (MySQL, PostgreSQL, etc.) with the VuGen “User Defined Function” parameter type.
Convert Web vusers to Java
There are situations where it is necessary to convert your C-based Web (HTTP/HTML) scripts to Java. Sometime there is difficult string manipulation that is much simpler in Java than in C, or you need to use a particular library/class, or maybe the app you must record with the Java Record/Replay vuser type also makes HTTP requests.
VuGen already ships with a command-line program that will convert your C-based web script to Java, but this is a bit painful to use. It would be great if a “convert web script to Java” function was incorporated into the VuGen menu options.
LoadRunner Add-in for SAP
I dread having to create scripts for SAP Portal because, to do them properly, there is so much boring and repetitive manual labour. I would pay real money for a VuGen add-in that would:
- Encode my SAPEVENTQUEUEs
- Do more correlation automatically
- Add checks for all web requests (and fix the checks that are generated incorrectly)
- Remove any background polling requests
Web Performance Analysis
LoadRunner mainly aims to find load-related performance problems, but there are plenty of problems you can find with just a single user. I always like to check whether the web servers have been configured to gzip all the files that they should, and make static files cacheable by setting expires headers, etc. It would be great to have a VuGen add-in that checks the replay log and does this analysis for me. Yes, this is basically YSlow for VuGen.
Enhanced support for HTTP-based Applications
I recently tested a system that had a Java client that communicated with the server using HTTP. An initial recording showed that every second character in the HTTP requests was a null character that had been encoded as “\x00” in the web_custom_request body. The Java client was sending XML, but using a double-byte character encoding (e.g. UTF-16), which was not handled well by VuGen.
An add-in could have made dealing with these request/responses a lot less painful by hiding the fact that they contained double-byte characters.
Add-ins will give us the ability to create our own VuGen scripting enhancements for any HTTP-based app. For example, if you wanted to support Web Services better than the Web Services vuser, you could write your own extension that worked with the Web (HTTP/HTML) vuser type. If HP is a little slow to support the latest version of Flex (which sends binary data over HTTP), you could write your own Flex add-in for the Web (HTTP/HTML) vuser. Want better support for XML or JSON? Pretty printing? Write an add-in.
…so, if you want to develop any of these ideas into VuGen Add-ins yourself, please let me know (leave a comment) and I will link to it when your are finished.