LoadRunner RDP Protocol Basics

Note: This article was originally posted on Loadtester.com, and has been migrated to the Northway web site to maintain the content online.

When HP released LoadRunner version 9, several new protocols were introduced.  One of these protocols was Microsoft Remote Desktop Protocol (RDP).  It allows the scripting of Terminal Server sessions.  From a scripting standpoint, it looks similar to earlier versions of the Citric ICA LoadRunner protocol.  Many of the same best practices used when recording Citrix can be used when recoding RDP sessions.  Before we go into the specifics of how LoadRunner implements the RDP protocol, let’s talk a little about what RDP actually is.

What is RDP?

Terminal Server is an add-on to Microsoft Windows Server.  It allows you to run sessions on the server from a local computer.  When you log into a terminal server from a local computer, it does all of the processing on the server and presents the client with a GUI that shows what is happing on the server.  RDP is the protocol that is used to connect the local client to the Terminal Server.

Before recording a script, it is important to understand how RDP works.  When a user logs on to a Terminal Server machine, the user is basically seeing a picture of what is happening on the server.  As the user types and clicks, the picture displayed to the user is refreshed.  Because of this, LoadRunner has no idea what is shown on the screen to the user.  All it can see is a picture.  This is important to keep in mind when replaying the script because synchronization points will have to be setup to make sure that the script replays correctly.

Planning

Since RDP is a GUI based script, it is important to plan your businesses processes out well before starting to script.  Before sitting down to script, go through the business processes outside of LoadRunner a few times to avoid mistakes during recording.  After recording, it is possible to go back and edit the script if you make a mistake.  But since an RDP script will contains lots of mouse clicks, windows syncs, and key typing, it will not be overly easy to read.  Planning beforehand can help cut down on the amount of editing that has to be done which will ultimately save on time and help the cleanliness of the script

Recording Levels

When recording RDP scripts, one of the recording options to pay attention to is the recording level.  This setting determines how low-level to record the script.  The default option is ‘High’.  This means that when recording, any typing captured is shown in the script as rdp_type and double mouse clicks are recorded as rdp_mouse_double_click.  Also any modifier keys (control, alt, shift) are recorded into the steps when they occur.  The next recording level down is ‘Low’.  The main difference with this level is that typing is recorded as rdp_key (one key at a time.)  The last recording level is ‘Raw’. This generates the script using key_up, key_down, mouse_up, and mouse_down functions.  Also no modifier keys are available.  When recording, always start recording at the highest level.  This will help make the script more readable and maintainable.  If there are problems encountered when recording the script, then move down a recording level.

Image Synchronization

After the recording, getting RDP scripts to play back successfully can be tricky.  The key is to get synchronization to work properly.  Synchronization in RDP involves basically drawing a box around an area on the screen where you want your script to wait before continuing.  There are a few things to remember when creating synchronization points for the RDP protocol.

Sync points can be created during recording and after.  During recording, they can be created by using the button on the recording toolbar. After recording, they can be created from snapshots in the treeview.
Keep the sync areas small.  Focus only on the specific area that needs to appear before the script can continue.  The smaller the area, the fewer sync problems that will exist.
If a sync fails during playback, a dialog box will appear.  The box will allow you to see the recorded snapshot and the snapshot found during replay.  If the new snapshot is fine, you can append its value to the script.  If not, you can stop the script and debug.
RDP syncing contains a feature called tolerance.  It allows a little leeway in synchronization.  The tolerance can be set at Low, Medium, High, and Exact.  The stricter the tolerance, the more exact the recording snapshot and the playback snapshot have to look like each other.  If the syncs are failing a lot on playback for reasons that aren’t intuitive, try lowering the tolerance.

Shifting Coordinates

One of the most interesting features of the RDP protocol is shifting coordinates.  Sometimes the position of objects moves in an application.  In other protocols, this would require either a lot of script edits or a rewriting of the script.  The RDP protocol tries to automatically fix the problem.  It notices that the coordinates of an object have changed, so it modifies the function associated with the object and any others that depend on that object.  As an example, let’s say a script was recorded against an application that had a pop-up window where the user had to enter a name and then click enter.  If that pop-up window appeared in a different place on playback, not only would it adjust any functions dealing with that window, it would also adjust the functions for typing the name and clicking the enter button.

The Not So Good

There are a couple of problems with the RDP protocol.  The first is that it does not support connecting to Windows XP.  If you try to record a script against XP, LoadRunner won’t error, but it will give you just a blank script.  In order to record correctly, LoadRunner needs to record against a machine that is running Windows Terminal Server.

UPDATE: The current version of RDP DOES support Windows XP and NON-Server versions of Windows.

The second problem is that RDP does not support object recognition.  LoadRunner cannot see any information about the objects being displayed.  This means that the script is going to be totally dependent on bitmap synchronization.  Another downside to this is that the amount of error checking you can do is very limited.  Object recognition is great for error checking because you can grab text from the screen to make sure that the application is displaying what is expected.

Conclusion

The RDP and Citrix protocols are very similar.  Anyone familiar with Citrix should be able to learn this protocol quickly.  It also has some nice features like shifting coordinates and tolerance that other protocols don’t have.  This protocol is new with LoadRunner 9.0, so it is still very immature.  As more people start to use it, I would expect updates to appear in future feature packs.  Hopefully before long they can incorporate a type of object recognition which would really improve the usability of this protocol.