Setting .NET Filters (.NET Protocol,C#) in HP Load Runner

I have struggled a lot to understand how filters in .NET apps work- The below writeup has been adopted from HP Help.I found this write up useful to kick start your recording using .NET protocol. I am including this here for those who have limited access to documentation.This will give you a good idea about setting up filters for .NET protocol in Load Runner before recording- (All credits to HP please!) - AB


When testing your .NET application, your goal is to determine how the server reacts to requests from the client. When load testing, you want to see how the server responds to a load of multiple users.

When recording a .NET application, your script may include calls to methods that do not affect the server, such as calls to a local utility or the GUI interface. These calls are usually not relevant to your testing goals, and it would be correct to filter them out.

The built-in filters, .NET Remoting, ADO.NET, Enterprise Services, and WCF, were designed to record only the server related traffic relevant to your testing goals. In some instances, however, you may need to customize filters to capture your .NET application's calls or exclude unnecessary calls. Using the Filter Manager, you can design custom filters to exclude the irrelevant calls and capture the server related calls.

Before creating a test, i recommend that you become familiar with your application and determine its primary classes and methods, so that you will know which ones to include in your recording.

If you are not familiar with your application's classes, you can use Visual Studio or a Stack Trace to help you determine which methods are being called by your application in order to include them in the filter. VuGen allows you to record with a stack trace that logs all of the methods that were called by your application.

Once you determine the required methods and classes, you include them using the Filter Manager. When preparing a script, you may need to customize the filter several times in order to achieve the optimal filter. An optimal filter records the relevant methods without introducing a large number of irrelevant calls to the script.


PS: Note that if you plan to add manual code to your script such as control flow or message statements, make sure to do so after you have a functional script that runs inside VuGen. The reason for this is that if you re-record a script or regenerate the script, you will lose all of the manual changes.

Determining which Elements to Include or Exclude-
When designing a custom filter, we recommend that you start by choosing the appropriate built-in filter as a base filter. You can then customize the filter using one of the following approaches:

Top Down Approach. An approach in which you include the relevant namespace and exclude specific classes that are not part of the client-server activity. This is recommended if you are familiar with your application and you can identify a well-defined assembly which implements all client-server activity without involving any GUI elements, such as MyDataAccessLayer.dll.

Bottom up Approach. An approach in which you use the default filter and refine it by adding individual methods or classes. Use this approach if you cannot identify a well-defined layer or if you are not familiar with your application. Do not add all AUT assemblies and then try to remove extra component one by one.

The following section provides guidelines on when to include or exclude elements.

If, as a result of your including a class, your script has many unrelated method calls, try modifying the filter to exclude the irrelevant methods.

If you identify a non-client/server call in your script, exclude its method in the filter.

During recording, VuGen may detect an unknown input argument, for example, an argument whose construction it had never encountered before. If this argument supports serialization, VuGen serializes it by saving it to a file in a special format. During replay, VuGen reconstructs the argument by deserializing it.

VuGen serializes objects passed as arguments that were not included by the filter. We recommend that you include this object in the filter in order to track its construction and activity instead of using it in its serialized form. You can identify serialized objects in the script by searching for calls to the LrReplayUtils.GetSerializedObject method or, in WCF environments, LrReplayUtils.GetSerializedDataContract. VuGen stores serialized objects in the script's \data\SerializedObjects folder as XML files with indexes: Serialization_1.xml, Serialization_2.xml and so forth.

When no rules are specified for a method, it is excluded by default. However, when the remoting environment is enabled, all remote calls are included by default, even if they are not explicitly included. To change the default behavior, you can add a custom rule to exclude specific calls which are targeted to the remote server.

Arguments passed in remoting calls whose types are not included by the filter, are handled by the serialization mechanism. To prevent the arguments from being serialized, you can explicitly include such types in order to record the construction and the activity of the arguments.

Exclude all activity which involves GUI elements.

Add assemblies for utilities that may be required for the script to be compiled.

For information on how to include and exclude elements, see Filter Manager [.NET Protocol].

Defining an Effective Filter
When preparing a script, you may need to customize the filter several times in order to achieve the optimal filter. An optimal filter records the relevant methods without introducing a large number of irrelevant calls to the script.

Define an effective filter
Create a new filter based on one of the built-in filters. If you know that the AUT (Application Under Test) does not use ADO.NET, Remoting, WCF, or Enterprise Services, clear that option since unnecessary filters may slow down the recording.

Set the Stack Trace option to true for both recording and code generation. Open the Recording Options ( ctrl+f7) and select the Recording node. Enable Debug Options: Stack Trace and Code Generation: Show Stack Trace.

Record your application. Click Start Record ( ctrl + r) to begin and Stop ( ctrl + f5) to end.

View the script's steps. If you can determine the business logic from the steps and apply correlation, you may not need to create custom filters. If, however, the script is very long or hard to maintain or correlate, you should customize the script's filter.

Try to identify the high-level method in the call that captures or wraps one or more client server calls. You can do this by opening the AUT source files (if they are available) in Visual Studio or by viewing a Stack Trace of the script.

Set the filter to include the relevant methods—you may need to add their assembly beforehand. For tips about including and excluding elements in the filter, see Guidelines for Setting .NET Filters.

Record the application again. You should always rerecord the application after modifying the filter.

Repeat steps 4 through 7 until you get a simple script which can be maintained and correlated.

After creating an optimal script, turn off the Stack Trace options and regenerate the script. Open the Recording Options ( ctrl+f7) and select the Recording node. Disable Debug Options: Stack Trace and Code Generation: Show Stack Trace. This will improve the performance of subsequent recordings.

Correlate the script. In order for your test to run properly, you may need to insert a correlation to capture a value and use it at a later point in the script. For more information, see How to Correlate Scripts - Microsoft .NET.



Cheers-
AB