Error No match found for the requested parameter 'ParameterName'

When replaying Web script with a correlation statement, the user receives the following error:

"No match found for the requested parameter 'ParameterName'. If the data you want to save exceeds xx bytes, use web_set_max_html_param_len to increase the parameter size."

Even though the user tries to increase the size for web_set_max_html_param_len, it does not help. What will be a good number for this parameter, and what is the maximum value?

Diagnosis:

When replaying a script with a correlated value, the replay engine will return the above error when there is no match found for the predefined boundaries on the correlation statement. The following information from the error message: If the data you want to save exceeds xx bytes, use web_set_max_html_param_len to increase the parameter size

The above is just a suggestion to try, it may not be a solution. This suggestion should be taken, only if the expected data is over xx bytes.


Solution:

Dealing with web_set_max_html_param_len

1. Find out the size of the data you are trying to retrieve. If it is over 256 bytes, increase this value. Correlation will fail if you try to retrieve a string whose length exceeds the maximum length specify by web_set_max_html_param_len.

Note:
The maximum length for web_set_max_html_param_len is maximum value of unsigned int, which is equal to 4294967295 bytes. If the data you want to save exceed this boundary, you will need to create multiple correlation statements for retrieving the entire dataset.However it is not recommended that such a big value be used and that a value closer to the maximum paramter length expected should be used.

2. If the data you want to save do not exceed the bytes specify in the function, you should focus on finding the correct boundaries or placing the correlation function on the correct place. 

Tracking Login Attempts and Logged In Users in HP BSM/BAC

We can always track the user activity in HP BSM/BAC very easily and it is very important too. Follow the below process for doing the same:

There are lots of log file in BSM root folder but below are the stuffs we are concerned here;

See \log\EJBContainer\UserActions.servlets.log.

The appender for this file is located in \conf\core\Tools\log4j\EJB\topaz.properties.

It can also be done by the JMX console as stated below;

To display a list of users currently logged in to the system:
1 Open the JMX console on this machine. For detailed instructions, see
"Using the JMX Console" in the Platform Administration guide.
2 Under the Topaz section, select service=Active Topaz Sessions.
3 Invoke the java.lang.String showActiveSessions() operation.

Load Runner 12 features

The roadmap for LoadRunner 12 was presented at HP Discover Barcelona in December last year. Since that time, I've been lucky enough to have a beta copy of LR12 for evaluation purposes. Now that the product has been released, I'm able to share some of the new features that I've found to a wider audience.


Key observations / new features are:
Cloud-based load generators. HP describes this feature as "cloud bursting". Users now have the ability to provision load generators on AWS(Amazon Web Service) cloud servers from within LoadRunner or Performance Center. As well as this, the ports used to communicate between LoadRunner components such as Load Generators, Controllers, MI Listeners are user configurable through the new "network security manager" tool. This simplifies the setup process and allows more flexibility in distributed test networks or cloud-based test environments. It is even possible to configure different ports/proxies for each Load Generator.

Licensing - 50 VUsers free

We in the user community have been asking for this for a long time. Providing fully-functional applications that allow small-scale testing allow prolonged evaluations and proof-of-concept exercises. This is great, because it allows more people e.g. developers to get hands-on experience and see the potential benefits of using LoadRunner.

This is likely to improve the adoption rate for LoadRunner and prevent the erosion of market share to low-cost / no-cost providers of performance testing software.

All protocols are included in the "community edition" license, with the exception of GUI (UFT) and COM/DCOM protocols as well as those protocols in the "template" bundle (i.e. those vUser types whose scripts are manually created (rather than record/replay) such as C# .Net, VB .Net vUsers).

VUGEN improvements:
There are a variety of improvements as you would expect. Key ones are:
The ability to review replay statistics for tests after each run.
Including details on total connections, disconnections and bytes downloaded.
The ability to edit common file types in the editor.
Support for recording in the Internet Explorer 11, Chrome v30 and Firefox v23 browsers.
The ability to create scripts from Wireshark or Fiddler files.
The ability to record HTML5 or SPDY protocols.

TruClient improvementsTruClient script converter. This basically replays your TruClient scripts and records the HTTP/HTML traffic allowing you to create these script typers from TruClient recordings. This is similar to recording GUI scripts and then converting to other script types.

The addition of support for Rendezvous points, IP spoofing, VTS2 and Shunra network virtualisation in TruClient scripts.

Linux Load Generator improvements
Building on the increased support for Linux Load Generators in 11.5x, LDAP, DNS, FTP, IMAP, ODBC, POP3, SMTP and Windows Sockets scripts can now be replayed through UNIX load generators.

CI/CD support
Better integration with Jenkins etc.

Platform support
Support for installation on Windows Server 2012.
(LoadRunner 11.x and PC 11.x only supported up to W2K8 which was a barrier to enterprise adoption).
LoadRunner components can now run in a "non-admin" user account with UAC and DEP enabled.

There are numerous other improvements which are well documented in the "About LoadRunner" section in LoadRunner help. Now that the community license is available, there's nothing stopping you from downloading it and giving it a go.

To get your own copy, navigate to www.hp.com/go/loadrunner and follow thre links to download LoadRunner.

Type of Logs in Load Runner Runtime settings

While creating and debugging the script which generated in LoadRunner always create various types of logs which appear in Virtual user generator screen. These logs are very useful when it’s come to debugging your script.

There are four types of log available in LoadRunner:
Recording Log
Generation Log
Replay Log
Co-relations Results



1. Recording Log: This log is generated when user records any script. This log mainly contains client server communication information which is nearly non-readable format. This is not very useful for us since we cannot map many things of this log with our script. This log contains all protocol communication information which used by application on which we are recording.
This Log is useful when we re-generate the script using “Regenerate Script” option of Vugen. Recording log is traces created during the recording Vugen
User cannot re-generate script if this log is not available.


2. Generation Log: The time user stop recording, recording log traces converts into readable format and create a log which is known as “Generation Log”. This log is very useful to see request and response captured by LoadRunner during recording. This log can be refer in script folder by accessing the file “CodeGenerationLog.txt “


3.Replay Log: Now this is the log which helps us a lot while modifying the script. This log generated when user replay the recorded script. In this log we can see what request has been sent to server and which kind response we have received during replay. It’s become very handy when we need to find the problem where script is getting fail during replay. We can increase/decrease the reply log contents by changing the settings in “Run time setting” by selecting standard log or extended log section.


4.Co-relations Results: This log is an interesting log as correlation is very import part of performance testing. This log represents a form of auto correlation. This compares “recording log” and “reply log” and finds dynamic values received any server. We can directly correlate the values from this log. It works like F9 function. Make sure “Data” folder exists in “Script” path.

Sitescope Unix CPU script monitor

CPU script monitor created after building a script and deploying the same in scripts.remote folder.

Script used:

Idle=`mpstat -P ALL 2 3 | grep ^Average | awk '{print $11}' | head -n 2 | tail -n 1`

Wait=`mpstat -P ALL 2 3 | grep ^Average | awk '{print $6}' | head -n 2 | tail -n 1`

echo "scale=2; 100-"${Idle}+${Wait}"" |  bc –l

Note : Here print $ value positions may change

Logic:

Here the 1^st command fetches the 11^th value in the average row say “A”

Second command fetches the 6^th value in the average row say “B”

Third command adds the above two values (A+B) and subtracts the results from 100 to give the %utilization.

Formula:

%Utilization = 100 – (%Idle + %Wait)

Difference between socketlevel and WinInet modes in load runner

WinINet uses the Microsoft interface to the internet.
Starting with version 7, Load Runner uses Sockets mode replay by default.This was also known as Turbo replay. Socket/Turbo replay utilizes its own interface to the network card. This proprietary replay engine is a lighter engine that is scalable for load testing.

The older WinInet replay, which can be enabled in Load Runner by selecting "WinInet replay instead of Sockets (Windows only)", uses the Microsoft WinInet DLL to talk to the network card. The limitations of the WinInet replay engine are that it is not scalable, nor does it support UNIX. In
addition, when working with threads, the WinInet engine does not accurately emulate the modem speed and number of connections. However, The WinInet is the engine used by Internet Explorer. It supports all of the features incorporated into the Internet Explorer, and thus, WinInet replay can
resolve some replay errors.

 attribute :
1) Additional attribute will be read from the run time settings of controller or VuGen.
2) We can pass the values to VuGen test script from the run time settings.
3) When you you change the value of the additional attribute, you do not have recompile or restore the test script in controller.

variable :
1) Variable will be defined in VuGen, based on the C data type.
2) Variable will be used for capturing any run time values or function return values.
3) When you change the value of the variable in the script, you have to recompile or restore the test script in controller.

parameter :
1) Parameter will be defined in VuGen to store parsed response results for server dynamic values like user session id, item id which are automatically generated by the server .
2) Parameter will be used in the subsequent requests to successfully play back the script with captured dynamic server values .
3) When you change the parameter settings, you have to recompile or restore the test script in controller

WinInet “weighs” more in terms of over all system resources as it is integrated with the Microsoft security APIs. The sockets option, what used to be known as Turbo load  was developed to allow for lighter weight virtual users to exist in larger quantities on a given reference hardware definition (Load Generator). The core change is on playback, if you need integration with the Microsoft security infrastructure, i.e. using web_set_user() you will need to use WinInet and you will need to use Windows Load Generators. And yes, these users will use more system resources.

The default is sockets. Unless you need to integrate directly with a security infrastructure for user authentication you will likely not need WinInet. You use this mostly when you have recording issues related to security, consider the use wininet as a workaround since the sockets mode with the required port mappings is the correct solution.

Note:When an application fail in recording, you can try by switching between the two modes. Whereas when the application fails in replay, try switching the modes also.

What is Think Time in a script?

Using think times within a LoadRunner script is the method for providing emulation of a realistic business process, running at a realistic speed.

During script recording, the recording setting must include think times as recorded. If for whatever reason, the think times that are recorded are not realistic, then the times scripted must be adjusted to reflect testing objectives.

If transactions are inserted during recording, be aware that this will distorting the think times. In this case, manual correction will be required.

During execution, to introduce the random element that would be present in any business environment, standard runtime settings are to be set for between 80% and 120% of recorded think time. This will ensure a 20% deviation, and ensure a complete mix of business processes during execution. This runtime setting can be amended if required by the project, but this amendment must be detailed in the test plan.