Every time someone uploads a script to the (web-based version of the) VuGen Validator, I get emailed a copy of the validation report for their script. Needless to say, I see a lot of really bad scripts…and hopefully the script developers learn something from the failing grade their scripts are given by the Validator.
One thing that worries me is that lately I have seen a lot of BPM scripts containing the following code…
Action()
{
web_cache_cleanup();
web_cleanup_cookies();
web_set_sockets_option("CLOSE_KEEPALIVE_CONNECTIONS", "1");
// script body removed from example.
return 0;
}
It seems to be spreading virally between script developers as they cut-and-paste a piece of code they clearly don’t understand at the beginning of all their scripts.
Just in case you are new to all of this, let me give you some background.
- BPM scripts are very similar to LoadRunner scripts, in that they are also developed with VuGen.
- But BPM scripts are used for monitoring an application, rather than load testing.
- Every 15 minutes (or whatever), the BPM script will be invoked on a BPM host. A new mmdrv.exe process is created, and the script runs in this. After the script has run, the mmdrv.exe process terminates. No state is retained between invocations of mmdrv.exe.
- BPM scripts typically run for a single iteration each time they are invoked, and will never have complex run logic (percentage weightings, etc.).
So what does the above code do?
- web_cache_cleanup(): Deletes the client-side cache for the vuser. But, as this function call appears at the beginning of the script and they will only do a single iteration, the vuser will always have an empty cache, so this function does nothing.
- web_cleanup_cookies(): Deletes stored cookies for vuser. But for the same reasons as web_cache_cleanup(), this function does nothing.
- web_set_sockets_option(“CLOSE_KEEPALIVE_CONNECTIONS”, “1”): This function causes the replay engine to close all open TCP connections. But at the start of the script, before any web requests have been made there are no open connections.
- Note complete lack of comments, explaining why they have added the code.
This kind of cut-and-paste programming behaviour worries me because:
- The developer clearly does not understand the code they are using.
- The developer has never bothered to read the documentation for the functions or think about how their tool works.
- The developer has the attitude of “if the code runs, then it must be working”, which is a really bad practice when the code is designed to measure something. Code that runs successfully is not necessarily making an accurate measurement.
The script developer is engaged in “voodoo script development” (similar to Cargo Cult Testing), where they copy code from other scripts, or from the Internet but they don’t understand how it works (and certainly can’t explain the code to others). Rather than establishing a clear relationship between cause and effect, they try things at random until their code appears to work, and then they consider it finished. These people leave messes for other people to clean up, and spread confusion wherever they go.
If you read this, and think “hey, that’s me”, please find another job that is more suited to your technical skills…perhaps basket-weaving.
3 Comments
Comments are closed.
Wikipedia says: “Cargo cult programming is a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. The term cargo cult programmer may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position.”
I call this “Harry Potter programming” because the developers seem to treat programming like magic, rather than as a science. See also: Programming by Coincidence
Maybe you should add a check for this kind of code to your VuGen Validator?
Here is an example of a time that I had to use the web_set_sockets_option(“CLOSE_KEEPALIVE_CONNECTIONS”, “1”); function:
– I had to do a BPM script that simulated a cached, and an un-cached hit to the SAP portal homepage.
– While I could have used web_load_cache and web_dump_cache, I was concerned that with a long-life BPM script, the cache would get out-of-date.
So i wrote my script to do this:
1. Start_transaction (uncached homepage)
2. web_url hompage
3. End_Transaction (uncached homepage)
4. web_set_sockets_option(“CLOSE_KEEPALIVE_CONNECTIONS”, “1”);
5. Start_transaction (cached homepage)
6. web_url hompage
7. End_Transaction (cached homepage)
I found that this was very accurate in recreating what my browser was doing (as seen using httpwatch).
Stuart, I have been guilty of just such the offense that this article addresses. My rationalization is that I probably cut and pasted code from an action.c section that is part of an iterative LR script, and I wanted to be doubly sure that LoadRunner was going to virgin-ize my next vuser’s iteration. And, perhaps if I had any comments in my code, they might have resided in the init.c section instead. But, you are correct in that the code is useless for BAC script.