Sap Web Protocol in Load Runner

Things to correlate in a SAP Web LoadRunner Scipt

I have been doing some SAP web scripting this week and although have been using the SAP Web protocol I have noticed that we still need to do manual correlation.
These are the 3 things I need to correlate:

ClientWindowID e.g WID1339591301202

This is not specifically a parameter that needs correlation but it a value generated in client side JavaScript which is basically the Unix time including milliseconds. Lucky there is a LoadRunner function that generates this. web_save_timestamp_param("pWID",LAST);

sap-wd-secure-id e.g. 30b66c21b9fd11e1bd5f000005ee7aaa5408212193

I have noticed that this parameter does change in some scripts I have written so be careful to extract out appropriately. This is the code I used to extract out the parameter:

web_reg_save_param("pSecureID",
"LB/IC=sap-wd-secure-id=",
"RB/IC=&",
"Ord=1",
"Search=Body",
"RelFrameId=1",
LAST);

wi_id e.g. 000003799238

This parameter appears when a window is spawned.
web_reg_save_param("pWi_id",
"LB/IC=wi_id%3D",
"RB/IC=\"",
"Ord=1",
"Search=Body",
"RelFrameId=1",
LAST);

Sap Gui Protocol in loadRunner

Approach to Create SAP GUI script with Load Runner 11.5

Improved VuGen have
Recording 64bit Applications.
Improved Correlations.
Integrating Virtualized Services .
Web Protocol Asynchronous Support.

Planning:

1 Plan the Features that need to be considered under Load Test.
Plan the Protocol that is essential.
3) Plan the statistics of responses.
4) Plan the statistics that need be parameterized and Looping.
5) Take the Bench Marks of the single user request and Responses.
6) Plan about dynamic data that need to seized and correlated for the successful running of VUGEN.




7) Plan for Control , the actual Load Test for VUser


1) Goal Oriented Scenario or a Manual scenario.
2) Select the Ram Up.
3) Execute the Test.
4) Analysis the results.

Scripting:
Scripting:
Record the Script.
Divide the script into Action and Name them.
Ex : Login_Admin , Search_10_Users, Update_5_Users , Logout_Admin.
Enhance the script (Parameterization, Inbuilt Function, Logic)
Correlation if needed. (If it is a SAP WEB script).
Run The Script: Mark the Truncation Times , make sure it not Failing .
Define Run logic (hierarchy of Blocks and Actions and number of interactions for both Actions and Blocks).

Approach to Create SAP GUI script

1) Select the protocol as “SAP GUI”.



2) Hit on Record button to select “Windows”
Now provide the 'SAP Login' exe file path in below 'Application to record' field .
and then just place the cursor at Working Directory Test field and click.

Now you can see the “Start Recording” Button gets enabled.


3) Not hit “Start Recording” and log into the sap GUI and do the required truncations or action.
4) While recording divide the actions based on the functionality.
5) Parameterized the below value Carname as shown.



6) Used below functions to generate the sample script
/* -------------------------------------------------------------------------------
Script Title : SAP GUI sample


Script Description : Record and Play


Recorder Version : 2216


Created By : Saka Amar .
------------------------------------------------------------------------------- */

vuser_init()
{

sapgui_open_connection_ex(" /SAP_CODEPAGE=1100 /FULLMENU /H/ides.consolut.eu/H/n4sexternal 01 /3 /UPDOWNLOAD_CP=2",
"LR",
"con[2]");

sapgui_select_active_connection("con[2]");

sapgui_select_active_session("ses[0]");

sapgui_select_active_window("wnd[0]");

sapgui_window_resize("187",
"25",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui104",
END_OPTIONAL);

/*Before running script, enter password in place of asterisks in logon function*/

lr_think_time(25);

sapgui_logon("DEVELOPER",
"qtbg",
"500",
"EN",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui1015",
END_OPTIONAL);

lr_think_time(8);

sapgui_set_ok_code("/OSE93",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui1016",
END_OPTIONAL);

sapgui_press_button("Enter",
btn1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui1017",
END_OPTIONAL);

sapgui_select_active_session("ses[1]");

sapgui_select_active_window("wnd[0]");

sapgui_window_resize("187",
"25",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui204",
END_OPTIONAL);

sapgui_send_vkey(F4,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui205",
END_OPTIONAL);

sapgui_select_active_window("wnd[1]");

sapgui_window_scroll_to_row("0",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui209",
END_OPTIONAL);

sapgui_set_focus(lbl1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui208",
END_OPTIONAL);

sapgui_send_vkey(F2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2012",
END_OPTIONAL);

sapgui_select_active_window("wnd[0]");

sapgui_press_button(" Display",
btn2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2015",
END_OPTIONAL);

lr_think_time(8);

sapgui_press_button("Test (F8)",
btn3,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2018",
END_OPTIONAL);

sapgui_send_vkey(F4,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2021",
END_OPTIONAL);

sapgui_select_active_window("wnd[1]");

sapgui_window_scroll_to_row("0",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2025",
END_OPTIONAL);

sapgui_set_focus(lbl2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2024",
END_OPTIONAL);

sapgui_send_vkey(F2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2028",
END_OPTIONAL);

sapgui_select_active_window("wnd[0]");

sapgui_press_button(" Display",
btn2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2031",
END_OPTIONAL);

sapgui_status_bar_get_text("paramStatusBarText",
BEGIN_OPTIONAL,
"Recorded status bar text: Fill in all required entry fields",
"AdditionalInfo=sapgui2034",
END_OPTIONAL);

sapgui_send_vkey(F4,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2035",
END_OPTIONAL);

sapgui_select_active_window("wnd[1]");

sapgui_window_close(
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2038",
END_OPTIONAL);

lr_think_time(5);

sapgui_select_active_window("wnd[0]");

sapgui_set_ok_code("/OSE93",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2041",
END_OPTIONAL);

sapgui_press_button(" Display",
btn2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2042",
END_OPTIONAL);

sapgui_status_bar_get_text("paramStatusBarText",
BEGIN_OPTIONAL,
"Recorded status bar text: Fill in all required entry fields",
"AdditionalInfo=sapgui2045",
END_OPTIONAL);

sapgui_set_ok_code("/OSE93",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2046",
END_OPTIONAL);

sapgui_press_button("Enter",
btn1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui2047",
END_OPTIONAL);

sapgui_select_active_session("ses[2]");

sapgui_select_active_window("wnd[0]");

sapgui_window_resize("187",
"25",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui304",
END_OPTIONAL);

lr_think_time(10);

sapgui_set_text("Transaction Code",
"ZALV_REPORT",
ctxtTSTC1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui305",
END_OPTIONAL);

sapgui_press_button(" Display",
btn2,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui307",
END_OPTIONAL);

lr_think_time(4);

sapgui_press_button("Test (F8)",
btn3,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3010",
END_OPTIONAL);

sapgui_grid_select_cell_row("5",
shell1,
"5",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3013",
END_OPTIONAL);

sapgui_grid_select_rows("5",
shell1,
"5",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3014",
END_OPTIONAL);

sapgui_grid_double_click_current_cell("(5, Airline Code)",
shell1,
BEGIN_OPTIONAL,
"CurrentRow=5",
"CurrentCell=CARRID",
"AdditionalInfo=sapgui3015",
END_OPTIONAL);

sapgui_grid_select_cell_row("10",
shell1,
"10",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3018",
END_OPTIONAL);

sapgui_grid_select_rows("10",
shell1,
"10",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3019",
END_OPTIONAL);

sapgui_grid_double_click_current_cell("(10, Airline Code)",
shell1,
BEGIN_OPTIONAL,
"CurrentRow=10",
"CurrentCell=CARRID",
"AdditionalInfo=sapgui3020",
END_OPTIONAL);

sapgui_grid_select_cell_row("16",
shell1,
"16",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3023",
END_OPTIONAL);

sapgui_grid_select_rows("16",
shell1,
"16",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3024",
END_OPTIONAL);

sapgui_grid_double_click_current_cell("(16, Airline Code)",
shell1,
BEGIN_OPTIONAL,
"CurrentRow=16",
"CurrentCell=CARRID",
"AdditionalInfo=sapgui3025",
END_OPTIONAL);

lr_think_time(10);

sapgui_press_button("Sort in Ascending Order (Ctrl+F4)",
btn4,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3028",
END_OPTIONAL);

lr_think_time(9);

sapgui_select_active_window("wnd[1]");

sapgui_press_button("Add Sort Criterion (F7)",
btnAPP_WL_SING1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3031",
END_OPTIONAL);

lr_think_time(4);

sapgui_press_button("Transfer (Enter)",
btn1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3034",
END_OPTIONAL);

lr_think_time(6);

sapgui_select_active_window("wnd[0]");

sapgui_press_button("Sort in Ascending Order (Ctrl+F4)",
btn4,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3037",
END_OPTIONAL);

sapgui_select_active_window("wnd[1]");

sapgui_grid_select_rows("'Column Set', 0",
shell2,
"0",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3040",
END_OPTIONAL);

sapgui_press_button("Add Sort Criterion (F7)",
btnAPP_WL_SING1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3041",
END_OPTIONAL);

sapgui_press_button("Transfer (Enter)",
btn1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3044",
END_OPTIONAL);

lr_think_time(7);

sapgui_select_active_window("wnd[0]");

sapgui_press_button("Sort in Ascending Order (Ctrl+F4)",
btn4,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3047",
END_OPTIONAL);

sapgui_select_active_window("wnd[1]");

sapgui_grid_select_cell("'Sort criteria' (1, @3F@)",
shell3,
"1",
"DOWN",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3050",
END_OPTIONAL);

sapgui_grid_select_rows("'Sort criteria', 1",
shell3,
"1",
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3051",
END_OPTIONAL);

sapgui_grid_click_current_cell("'Sort criteria' (1, @3F@)",
shell3,
BEGIN_OPTIONAL,
"CurrentRow=1",
"CurrentCell=DOWN",
"AdditionalInfo=sapgui3052",
END_OPTIONAL);

sapgui_press_button("Transfer (Enter)",
btn1,
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui3055",
END_OPTIONAL);

return 0;
}


Improved VuGen:
The VuGen user interface has been improved and enhanced to provide a more flexible and customizable user experience. An all new IDE makes LoadRunner scripting easier and more productive.
New look and feel – Flexible panes, layouts, and more
Solution Explorer – An easier way to group multiple scripts, access script items, and perform script-related operations.



Snapshots – Multiple views, improved performance, snapshot synchronization, and search functionality.


Improved editor – Context-sensitive support, code completion support, and provides enhanced coloring and formatting.

Debugger – Real C language debugger.

Search and replace – New capabilities include search in log and snapshots.



Step navigator – The new Step Navigator replaces the tree view, providing a single view of the script with easy filtering and search mechanisms.



New panes – Errors, Tasks, and Bookmarks panes display all errors, messages, and tags in simple, easy to locate views.


Join the Community – Community integration provides easy access to conversations and threads in the HP Software Community.

Improved Correlations:
A new response correlation capability has been added so correlation is easier and faster. Correlations can now be found based on server responses during recording, in many cases eliminating the need to replay iteratively to find dynamic values. Coupling this with the new Correlation Studio interface and new APIs for locating parameters based on XPath and Regular Expressions, makes scripting easier and faster
Recording 64bit Applications :
Recording of 64bit applications has been added to the existing support for 64bit operating systems. 64bit applications can usually be recognized when the ‘*32’ suffix is not displayed in the Windows Task Manager for their process. Replay is in 32bit.

Integrating Virtualized Services :
Integrate with HP Service Virtualization, and use simulated services, to facilitate load testing business processes that contain services that are not readily available or too costly. As part of your performance test, you may want to test applications that depend on other services which are a part of your business scenario. Instead of loading actual services, you can use simulated services in your test run. The virtualized services are a simulation of actual services. To facilitate performance testing business processes that contain services that are not available, Performance Center integrates with HP Service Virtualization. Using simulated services in your test is helpful if using actual services involves an additional cost or requires the service of an application that is under development or inaccessible at the time when you run your performance test.

Web Protocol Asynchronous Support :

Support for asynchronous behavior has been added. This new capability enables recording of Poll, Long Poll, and Push interactions.
Advanced Web applications contain a lot of asynchronous communication designed to keep information current and up to date. Applications such as chat, messaging, stock tickers, and news updates all use various asynchronous mechanisms such Poll, Long Poll, and Push to maintain data. Support for these mechanisms has been added to Web (HTTP/HTML) Vuser scripts, and web-based functions inside Flex, Silverlight, and Web Services Vuser scripts. These unique communication patterns are recognized automatically and the recorded script is updated accordingly.

Volume Testing

Volume test shall check if there are any problems when running the system under test with realistic amounts of data, or even maximum or more. Volume test is necessary as ordinary function testing normally does not use large amounts of data, rather the opposite.

A special task is to check out real maximum amounts of data which are possible in extreme situations, for example on days with extremely large amounts of processing to be done (new year, campaigns, tax deadlines, disasters, etc.) Typical problems are full or nearly full disks, databases, files, buffers, counters which may lead to overflow. Maximal data amounts in communications may also be a concern.

Part of the test is to run the system over a certain time with a lot of data. This is in order to check what happens to temporary buffers and to timeouts due to long times for access. One variant of this test is using especially low volumes, such as empty databases or files, empty mails, no links etc. Some programs cannot handle this either.

One last variant is measuring how much space is needed by a program. This is important if a program is sharing resources with other ones. All programs taken together must not use more resources than available.

So we can summarize Volume Testing as follows:

Objective:

Find problems with max. amounts of data.
System performance or usability often degrades when large amounts ofdata must be searched, ordered etc.

Test Procedure:

The system is run with maximum amounts of data.
Internal tables, databases, files, disks etc. are loaded with a maximum of data.
Maximal length of external input.
Important functions where data volume may lead to trouble.Result wanted:

No problems, no significant performance degradation, and no lost data.Considerations:

Data generation may need analysis of a usage profile and may not be trivial. (Same as in stress testing.)
Copy of production data or random generation.
Use data generation or extraction tools.
Data variation is important!
Memory fragmentation important!Examples:

Online system: Input fast, but not necessarily fastest possible, from different input channels. This is done for some time in order to check if temporary buffers tend to overflow or fill up, if execution time goes down. Use a blend of create, update, read and delete operations.

Database system: The data base should be very large. Every object occurs with maximum number of instances. Batch jobs are run with large numbers of transactions, for example where something must be done for ALL objects in the data base. Complex searches with sorting through many tables. Many or all objects linked to other objects, and to the maximum number of such objects. Large or largest possible numbers on sum fields.

Do's and Dont's Of Testing

Actually , a good tester should focus on breaking the product and reporting the bugs right from the first release to the final release of the product. Now that is what is called killer attitude !!
However to achieve one's target as a tester, there are Do's and Dont's, which if followed properly can lead to a better testing result.

the Do's:

Do a sanity testing for every new release.
Ensure if all testing activities are in synchro with the test plans and strategy.
Strictly adhere to the input and exit criteria for all testing activities.
Update the test results for the test cases whenever it is run.
Identify areas where you might need technical assistance or trainings during testing. Plan and arrange for these technical trainings to solve this issue.
Strictly follow the test strategies as given in the test plan.
Try getting a release notes from the development team which contains the details of that release that was made to QA for testing. This should normally contain the following
The version label of code under configuration management.
Features part of a release.
Features not part of a release.
Fixed bugs/defects.
New Functionalities/Changes in the release.
Known problems.
Make sure the code is version controlled for each release.
Classify defects (Critical/ High/Medium/Low) in a mutual agreement with the Development team so that defects are fixed within the specified timelines.

the Dont's:

Dont update the test cases while execution of the same is going on. Normally people tend to update the test case based on the look and feel of the application.
Dont spend time in testing the features that are not part of this release.
Dont focus your testing on the non critical areas (from the customers perspective).
Even if the defect identified is of low priority, do not fail to document it.
Never make assumptions while verifying the fixed defects.
Dont update the test cases without running them actually, assuming that it worked in earlier releases. Remember, haste is waste.
Dont focus on many negative paths, which are going to consume lots of time but will be least used by customer.

Does LoadRunner transaction response time include the rendering time of the browser?

NO, because LoadRunner is not designed for client-side activities.


Rendering time includes the time taken for the display of the web components, JavaScript or applet to load in the browser that is being activated after the HTML page is being received.


When we replay the scripts in LoadRunner, network traffic are being generated by the APIs (functions) and are expected to receive before the subsequent step can be executed. All this are taken place in memory and what LoadRunner does is to generate the traffic and receive the responses in memory. No user interface (UI) is launched in the process of replay for the purpose of rendering the pages received. Having no UI launched, rendering is omitted.


In a real user environment, the entire time for response in user perspective includes the request sending time, request processed time, response time and the browser loading (rendering time). However, in the context of LoadRunner, UI is not part of this entire request and response cycle.

For an end-to-end response time testing that includes the rendering of the UI, we can use the GUI VUser protocol.

General Guidelines for Scripting

These are the general guidelines to be followed while creating LoadRunner scripts for performance testing:

Load testing is intended for assessing the behavior of the application when multiple users are accessing the application. Hence the purpose of testing and performance requirements should be clearly defined before start of creation of scripts. This includes figuring out the various business processes, transactions that are widely used by end users, the business critical transactions and transactions that include pages, which will take large amount of time for load testing.
Do not create one script for each transaction or functionality. Group the transactions into multiple sets (different actions) and create minimum number of scripts covering all the transactions. During actual test, the actions, which are not required for that specific test, can be removed from the running list of actions.
Give meaningful names for scripts, transactions and actions in the scripts. Do not leave the default names for actions.
Create separate actions for Login to the application and Log out of the application and keep them in ‘vuser_init’ and ‘vuser_end’ sections.
In the beginning of the script, provide a brief description regarding the script flow. Add appropriate comments for all transactions and major steps.
Insert rendezvous statements when a particular page is to be tested when multiple users are simultaneously accessing it.
If a portion of script is to be executed multiple times in each iteration, include this portion in a ‘for’ loop and indicate through a parameter for how many times this portion is to run rather than putting it in a block (in ‘Pacing’ tab of runtime settings) and specifying how many times to run.By doing this the behavior of script can be better controlled by changing the value in a data file rather than every time going and changing runtime settings.
Add ‘lr_vuser_status_message’ functions at appropriate places with information such as which iteration is being executed. These types of message functions are very useful to find out status of vusers and how the testing is going on.

Tips for Scenario Building

The following steps can be used for performance test execution:

1. Add load generators and connect.

2. Add scenario groups: Add one or more scripts to the list of scenarios.

3. Create run-time settings: Pace users based on feedback from business analysts or users.
a. Disable Logging
b. Determine where to put think time in the script from business analysts or users. Think time can be randomized when a non-random value is in the script.

4. Simulate browser cache: This option instructs the Vuser to simulate a browser with a cache. A cache is used to keep local copies of frequently accessed documents and thereby reduces the time connected to the network. By default, cache simulation is enabled. If you disable this option, all Vusers emulate a browser with no cache available.

Note: Unlike a regular browser cache, the cache assigned to a Vuser simulates storage of graphic files only. The cache does not store text or other page contents associated with the webpage. Every Vuser has its own cache—every Vuser must save and retrieve images from the cache. When the cache is disabled, LoadRunner still downloads each page image only once.

5. Simulate a new user for each iteration: Instructs VuGen to reset all HTTP contexts between iterations to their states at the end of the init section. This setting allows the Vuser to more accurately emulate a new user beginning a browsing session. It resets all cookies, closes all keep-alive connections, clears the cache, and resets the user names and passwords (enabled by default).

6. Schedule by scenario: As the number of users increases, there may be a need to adjust the rampup. Duration should be for one hour on most tests with the exception of stress tests.

7. Schedule by group: Allows testers to stagger the scenarios by group, meaning scenario B can start 10 minutes after scenario A. Ramp-up is how frequently a number of Vusers will log into the system per scenario. Duration is how long a particular scenario group will execute after ramp-up. Testers may manipulate duration to cease testing at a similar time.

Why are my scripts/vusers failing?

What are the possibilities in Vugen?

1. The application that you are replaying against is not running.
Simple? But it does happen, as such, when it fails on replay, take some time and try logging into the application manually and perform the business processes.

2. There were changes to the application.
There were changes to the application in aspect that had affected the script. For a 3-tier architecture, anything could have changed such as the following:

a. Presentation layer: where links or buttons are removed,
b. Application layer: where methods are changed or removed,
c. Database layer: where calls or tables are changed or removed.
d. Architecture level: where proxies or load balancers are changed or removed.

As such, verify with the application and infrastructure team if there were any changes made. You may have to re-script or amend the script accordingly to the changes.

3. There are dynamic values that need to be correlated.
This is common in applications. They are usually in the form of Session IDs or returned values based on parameterization. You have two options here:

a. Use the auto-correlation feature to detect any dynamic values (which I don’t usually use) or,
b. Perform manual correlation by recording two scripts of the same business process. From the two scripts, compare the recording logs and the APIs that had been generated for the differences.

4. The parameterization may be causing the problem.
The parameterization may be causing the problem in the following manner:

a. Insufficient records: ensure that you have sufficient records for the replay, especially in iterations.
b. Incorrect records: verify with the application or database team that you are holding on the valid values to be passed in as parameters. Parameterization may also result in different set of data being returned by the server as mentioned previously in (3). If that happens, correlate the value accordingly.
For (1) to (4), it’s recommended to turn on Full Extended Log (all options enabled: Advanced Trace, Parameter Substitution, Data Returned From Server) in the Runtime Settings (Vugen) to verify the data that is been transmitted between the server and the client (script). Through this, you can find out what and where that could have gone wrong in the replay.

What are the possibilities in Controller?

5. Does it happen at the start of the scenario execution?
We are focusing on the script only and leaving out the load testing setups. If the script/vuser fail at the start of the execution, verify the script again in Vugen, and if it still fails; it’s a script problem where you have to re-work from the previous point (1) to (4).

6. Does it fail on a particular Load Generator (LG)?
This may be caused by inconsistent LG across the load testing environment. As such, ensure the following in order for the script to run properly (but not limited to the list):

a. Folder directories that the script may be accessing to (particularly for file upload and download business processes).
b. Java settings like JVM and CLASSPATHs that can affect Java LoadRunner scripts.
c. All LGs have the same version as the Controller (e.g. LR9.0 across all LGs in the load testing environment).

7. Does it happen at the middle of the scenario execution?

If it is the case, it may be caused by anything but unlikely script problems (since the script/vuser have already started running successfully at the start of the run in (5). When this happens, the Application under Test (AUT) maybe under load and unable to process all requests from the scripts/vusers and therefore returning errors to them. You can verify this with the following.

a. Manually log into your AUT again and verify if it is still running or experiencing any lags.
b. Reduce the amount of vusers being generated in the scenario and re-run the test. If a reduced amount results in an error-free or non-script related errors, you are sure that the AUT is under load.

The above should be sufficient for you to troubleshoot script/vuser problems in Vugen and Controller. However, take note that it may not be limited to those and it will be advisable to carefully work the problem step-by-step to eliminate and possibilities

Difference between HTML, URL and GUI Mode Recording

HTML Mode:

Default and recommended recording mode.

Records HTML action in the context of the current Web page so that all we see on a web page will be recorded in a single function which makes it easier to read.

Advantage of this mode is that it generates a script that is intuitive to the reader in terms of what is the form requesting (in a form of entire web page).

Best for browser applications.

URL Mode:
Instructs VuGen to record all requests and resources from the server. It automatically records every HTTP resource as URL steps.

Generates a script that has all known resources downloaded for your viewing which works good with non-HTML applications such as applets and non-browser applications (e.g. Win32 executables).

Having everything together creates another problem of overwhelming low-level information and making the script unintuitive. Difficult to read.

When there are unrecognizable requests made to the server in Web (HTTP/HTML) protocol, they are recorded as web_custom_request. However, in URL-mode, this can be selected to allow recording to default to web_custom_request.

GUI Mode:

Introduced with Web (Click & Script) protocol.

GUI-mode option instructs VuGen to record all editable fields in an object or non-browser applications. What it does is to detect the fields that have been edited and generate the scripts accordingly.

Concept similar to functional testing when objects are detected at theGUI-level. When reading the script, it allows easier reading as the script is based on the GUI presented to the real user. Easier to read in context of the object.

Best for applets and non-browser applications.