Jenkins Installation for Windows

Visit Jenkins site and download it for Windows. It will be .msi file.

Then, extract the file and it will save itself in Program Filex(x86) under Jenkins folder.

Now open command promt and go to directory where Jenkin folder is present and run below command

D:\>Java –jar Jenkins.war

It should end successfully. However in case you get failure, there can be two main reasons.

a. Incorrect Java version or Java path:

Jenkins requires latest version of Java and you will need to download if from net. Then set the java path as below:

set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_161
set PATH=%JAVA_HOME%\bin;%PATH%;

b. Port 8080 is already in use

Most of the application uses port 8080 as it is a default port. In case you too see similar issue, you can change the port from 8080 to something say 8081.

Below are steps:
If you run Jenkins using the command line, then you can execute a command such as java -jar -httpPort=8081 jenkins.war to change the existing port from 8080 to 8081.

Another way to change the port while Jenkins is installed using the Windows package is as follows:

Go to the Program Files/Jenkins directory where you installed Jenkins
Open the Jenkins.xml in the editor
Find "--httpPort=8080" and replace the port 8080 with the new port number

After you have made any changes, it is better to restart Jenkins. To restart

Press Win + R.

Type "services.msc"
Right click on the "Jenkins" line > Restart.

Then go to URL: http://localhost:8082/

It was ask you to provide passward. Don't worry, it will also show you how to get password.

To create additional user, login with admin account and follow below step:
Manage jenkins → Manage User → Create User.

Hope you enjoy learning Jenkins.

Load Runner Analysis and types of graphs

First let's see what is Loadrunner Analysis and then see some important loadrunner graphs.

Analysis:

• Analysis is the utility or program to analyses the LoadRunner results in a very detailed manner.
• LoadRunner results are saved in .lrr file(lrr stands for Loadrunner Result) and can be viewed using Analysis.
• Analysis gathers the result information from scenario results (lrr file) and stores the information in form of .lra file.
• LoadRunner result has “Log” folder which contains Vuser logs and saves snapshots on error.
• Analysis generates Analysis Summary for the test which gives good idea about the test.
• Analysis generates graphs from the data collected during the test execution.
• Few of the graphs which are important for analysis of the results are Running Vusers, Hit per second, Throughput, Transaction Summary, Average Transaction Response Time, Error per second, etc.
• Analysis provides the raw data from which graphs are created.
• The granularity of graph should be such that it has maximized readability along with accurately represent important events.
• Analysis also provides facility to compare the results for the test.
• Analysis has good reporting mechanism which is helpful in sharing the test results.
• In Analysis, customized templates can be created to generate the same report for other test results.
• Loadrunner provides many formats to save the report. You can save you result in HTML format and share with the clients.

Graphs:

There are many types of graphs in Loadrunner results but you see only the default one when you load the results. Also, not all of them are important and and of course Average Transaction Response time is usually the graph your client always want to see.

Below are few types of graphs that you should know that exists in Loadrunner. I have explained which are important.

Running Vusers Graph
This graph would give the number of Virtual users that were incremented during the course of the load test.

Vuser Summary Graph
Lets you view the number of Vusers that successfully completed the load test scenario run relative to those that did not. Lets you view the number of Vusers that successfully completed the load test scenario run relative to those that did not

Rendezvous Graph
It indicate when vuser were released from rendezvous point and how many vuser are released from each point.it help the transaction performance time

Error Statistics Graph
This graph displays the number of errors that occurred during load test scenario execution, grouped by error code.

Error Statistics (by Description) Graph
This graph displays the number of errors that occurred during load test scenario execution, grouped by error description. The error description is displayed in the legend.This graph can only be viewed as a pie.

Total Errors per Second Graph
This graph displays the average number of errors that occurred during each second of the load test scenario run.

Errors per Second Graph
This graph displays the average number of errors that occurred during each second of the load test scenario run, grouped by error code.

Errors per Second (by Description) Graph 

This graph displays the average number of errors that occurred during each second of the load test scenario run, grouped by error description. The error description is displayed in the legend.

Average Transaction Response Time Graph

This graph gives the average transaction response time for all transactions executed by all users. This is a good graph to get an indication of how the application is performing. There can be a spike during the beginning of the load test in terms of response time, because initially the application needs time to scale its resources as per the load. But you should then start to see a gradual decrease and stabilization of the transaction response time. If you don’t then this can be an indication that there is an issue with the application.

Transactions per Second Graph

This graph displays, for each transaction, the number of times it passed, failed, and stopped during each second of a load test scenario run.

Transaction Summary Graph

This chart is good in understanding the ratio of passed to failed transactions. The green bar represents the number of passed transactions and the orange one the number of failed transactions. So if you see a larger number of failed transactions, this would give an indication. You can further Drilled Down Transaction Summary by doing right click and choosing Drill option.

Transaction Performance Summary Graph

This gives a summary of the minimum, average and maximum time of transactions in the load test.

The graph will then be displayed as shown below when you add this to the Analysis session.

Transaction Response Time (Under Load) Graph

This graph is a combination of the Running Vusers and Average Transaction Response Time graphs and indicates transaction times relative to the number of Vusers running at any given point during the load test scenario.

Transaction Response Time (Percentile) Graph

This graph helps you understand whether your response time meet the accepted criteria.

The graph will then be displayed as shown below when you add this to the Analysis session.

Transaction Response Time (Distribution) Graph
This graph displays the distribution of the time taken to perform transactions in a load test scenario

Hits per Second Graph

This graph would provide the number of hits by the load test against the application. This graph is good to see if the load test was consistent in hitting the application with requests at the right intervals.

Throughput Graph

This graph would provide the number of bytes that was received by the Web server. This graph gives a good indication of the throughput of the application. If the throughput decreases as the user load increases then that can signal an issue in the application.

HTTP Status Code Summary Graph

This graph shows the number of HTTP status codes returned from the Web server during the load test scenario run, grouped by status code. HTTP status codes indicate the status of HTTP requests, for example, "the request was successful","the page was not found".This graph can only be viewed as a pie.

HTTP Responses per Second Graph

If you want to see the HTTP Responses per second, you need to go to the Summary Screen and click the ‘HTTP 200’ link in the HTTP Response Summary section. The HTTP Responses should be consistent throughout the load test. If the responses starts to decrease even though the number of users is high, that would indicate that there is an issue with the application.

Pages Downloaded per Second Graph

This graph shows the number of Web pages downloaded from the server during each second of the load test scenario run.

Retries per Second Graph

This graph displays the number of attempted server connections during each second of the load test scenario run.

Retries Summary Graph

This graph shows the number of attempted server connections during the load test scenario run, grouped by the cause of the retry.

Connections Graph

This graph gives the number of connections during the elapsed time of the load test. Obviously during the beginning of the load test, it should increase and decrease towards the end of the load test.

The graph will then be displayed as shown below when you add this to the Analysis session.

Connections per Second Graph

This graph gives the number of new connections and the number of connections which were shut down during the course of the load test.

The graph will then be displayed as shown below when you add this to the Analysis session.

Page Component Breakdown Graph

This is a useful graph for finding any response time issues per page. In this the response time for each page over the duration of the load test is provided.

The graph will then be displayed as shown below when you add this to the Analysis session.

Page Component Breakdown (Over Time) Graph

This graph displays the average response time (in seconds) for each Web page and its components during each second of the load test scenario run.

Page Download Time Breakdown (Over Time) Graph

This graph gives the time each page took to download from the server. If the time is high, then this is a cause of concern for the application.

Time to First Buffer Breakdown (Over Time) Graph

This graph displays each Web page component's relative server/network time (in seconds) for the period of time until the first buffer is successfully received back from the Web server.

Downloaded Component Size Graph
This graph displays the size of each Web page component.

Windows Resources Graph

This graph shows the Windows resources measured during the load test scenario. The Windows measurements correspond to the built-in counters available from the Windows Performance Monitor.

UNIX Resources Graph

The UNIX Resources monitor shows the UNIX resources measured during the test run. This graph helps you determine the impact of Vuser load on the various system resources.

SiteScope Graph

The SiteScope Resources monitor graph shows the SiteScope resources measured during the test run. The SiteScope monitor can measure server, network, and processor performance counters.

Merging graphs

Merging graphs can be useful when you want to view the information in 2 graphs at the same time. This can be useful for comparing results. Ensure that when you are merging graphs that at least one graph is open.

Let’s choose the Hits per second graph and then choose the Merge Graphs option from the Context menu.Then choose the option to merge the graph with the Running VUsers and then click the OK button.You will then get the complete picture of the number of hits per second as per the virtual users. The sample result is shown below.

Merging Types Overview
Overlay:
Superimpose the contents of two graphs that share a common x- axis. The left y-axis on the merged graph shows the current graph's values. The right y-axis shows the values of the graph that was merged. There is no limit to the number of graphs that you can overlay. When you overlay two graphs, the y-axis for each graph is displayed separately to the right and left of the graph. When you overlay more than two graphs, Analysis displays a single y-axis, scaling the different measurements accordingly.

Tile:
View contents of two graphs that share a common x-axis in a tiled layout, one above the other

Correlate:
Plot the y-axis of two graphs against each other. The active graph's y-axis becomes the x-axis of the merged graph. The y-axis of the graph that was merged, becomes the merged graph's y-axis.

Loadrunner Details - Recording options, scenario and Parameter

In this Blog, i am trying to clear some basic queries and as well helping to provide some basic information. This may help you in when you are just starting to learn this tool or while preparing yourself for some exams.

Recording Option - HTML based or URL based

HTML based scripting:

It records script from every user action that is performed during recording.

It does recording as you perform clicks and doesn't give you inside information like what is happening behind the recording.

It is smaller and is more intuitive to read as the statements are inside the functions corresponding to the user action performed.

It is recommended for browser application.

The advantages of using the HTML recording mode is that the size is very compact and the customization efforts reduced.

However, with UI changes to the web applications the scripts would require much higher maintenance costs.

URL based scripting:

It records each and every browser requests to the server and resources received  from the server.

It records each and every step and emulate Javascript code.

In this mode all the statements gets recorded into the web_url().

It is recommended for thick client application.

LoadRunner does server side testing.

Transaction Percentile in Loadrunner result

In summary report of Loadrunner result, you might have seen 90 percentile column.

This is usually to check if we have met SLA. We can similarly have other percentile value as well. By default, LoadRunner provides 90 percentile result.

We can change the percentile result as per our need. Click on 'View' in Menu bar. Then Click on summary Filter. A dialog box will open and you will Additional Setting. There you can change the Transaction Percentile value from 90 to whatever you need. Usually, the client requirement is to check 90,95,98 or 99 percentile.

The question is what is this percentile and how do we calculate them manually. In order to calculate the 90 percentile response time for a transaction, sort all the response time values for that transaction in ascending order. Take the first 90 % transactions out of this set. The response time that has the maximum value in this set is the 90 percentile value of the studied transaction. In other words maximum response time for best 90 percentage of the transactions.

Types of Scenario

When we launch controller, we are asked to select the type of scenario that we want during our load test. We have two options for it - Manual or Goal Oriented. Let see them brief...

Manual scenario:

When you choose manual scenario you create it by selecting scripts to run, providing load generators on which we need to run the scripts, and distributing Vusers to run among the scripts. We provide all these details manually and hence the name.

We also have to provide details for Vuser that how we want to distribute them. We have two mode again - Quantity wise or percentage.

Vuser group mode - In this, for each script you assign a number of Vusers. You can instruct all Vusers in a group to run the same script on the same load generator, or you can assign different scripts and load generators to the various Vusers in a group.

Percentage mode - In this, you define a total number of Vusers to be used in the scenario, and assign load generators and a percentage of the total number of Vusers to each script.

Goal-Oriented Scenarios:

In this scenario, you define the goals you want to achieve and LoadRunner automatically creates a scenario for us based on these goals. We usually define our goal based on below types of goals.

Types of Goals:

Virtual Users - This goal tests if your application can run a specified number of Vusers simultaneously. Running this type of goal-oriented scenario is similar to running a manual scenario.

Pages per Minute/Hits per Second/Transactions per Second - These goals test the strength of your server. For each of these goal types, you specify a minimum-maximum range of Vusers for the scenario to run, and in the case of the Transactions per Second goal type, you also specify a transaction name.

Transaction Response Time - This goal tests how many Vusers can be run simultaneously without exceeding a desired transaction response time.

Run as thread or Process

Loadrunner provides as option of Multi-threading. We have two ways to run it - Run Vuser as a thread or Run Vuser as a Process.

When we run Vuser as a process, LoadRunner creates one process called mmdrv.exe per Vuser. So if we have 10 Vusers running, we will have 10 mmdrv.exe processes on our machines.

While when we run Vuser as a thread, LoadRunner creates 1 thread per Vuser. So if we have 10 Vusers, then we will have 1 process with 10 threads running inside it if the limit is 10 threads per process.

Thus from the memory point of view while running a load test, running Vuser as a thread is more memory efficient that running Vuser as a process for obvious reasons that less memory resources are utilized when we run them as thread.

Types of Parameter

We have below list of parameter types when we do parameterization while enhancing our recorded scripts.

Custom

Date/Time

File

Group Name

Iteration Number

Load Generator Name

Random Number

Unique Number

User defined functions

XML

Vuser ID

Functions in Load Runner

Once you record a flow in Load runner, the next step is to enhance the script. Enhancing the script requires all the understanding of Load runner as this is the most critical phase of it.

You need to have understanding about all the functions that are present in your script while recording. To enhance the script for actual performance testing you require debugging the script to make it work for different set of input data.

In this blog, I am listing all the load runner functions which can be used across all the protocols and they start with lr_. I have added explanation for most used functions. Hope this helps you for your scripting or for revision for your test or interview.

1. lr_abort():
Aborts the execution of a script
lr_abort();

2. lr_advance_param
Advances to the next available parameter value.
lr_advance_param("Param1"); //where Param1 is the parameter name

3. lr_continue_on_error
Specifies an error handling method.
lr_continue_on_error(1);
0- LR_ON_ERROR_NO_OPTIONS
1- LR_ON_ERROR_CONTINUE
2- LR_ON_ERROR_SKIP_TO_NEXT_ACTION
3- LR_ON_ERROR_SKIP_TO_NEXT_ITERATION
4- LR_ON_ERROR_END_VUSER

4. lr_convert_string_encoding
Converts a string to a different encoding.
lr_convert_string_encoding("Hello world",LR_ENC_SYSTEM_LOCALE,LR_ENC_UNICODE,"stringInUnicode");
where Hello world - The string to convert
LR_ENC_SYSTEM_LOCALE - The encoding of the sourceString
LR_ENC_UNICODE - The encoding to convert of the string saved in parameter paramName
stringInUnicode -The name of the parameter in which the destination string will be saved

5. lr_convert_double_to_double
It converts the string representation of a double to several other string representations

6. lr_convert_double_to_integer
It converts the string representation of a double to the string representation of an int

7. lr_db_dataset_action
Performs an action on a dataset.
lr_db_dataset_action("StepName=<step_name>", "DatasetName=<dataset_name>", "Action=<action>", LAST );

8. lr_db_connect
Connects to a database.
lr_db_connect("StepName", "ConnectionString=<connection_string>", "ConnectionName=<connection_name>", "ConnectionType=<connection_type>", LAST );

9. lr_db_disconnect
Disconnects from a database.
lr_db_disconnect("StepName=<step_name>", "ConnectionName=<connection_name>", LAST );

10. lr_db_executeSQLStatement
Submits an SQL statement to a database.
lr_db_executeSQLStatement("StepName=<step_name>", "ConnectionName=<connection_name>", "SQLStatement=<statement>", ["DatasetName=<dataset_name>",] LAST );

11. lr_checkpoint
Validates the value of a parameter against an expected value (checkpoint).
lr_checkpoint( "StepName=<step_name>", "ActualValue={<input_param>}", "Compare=<operator>", "ExpectedValue={<checkpoint>}", "StopOnValidationError=<error_code>", LAST );

12.  lr_db_getValue
Retrieves a value from a dataset.
lr_db_getValue( "StepName=<step_name>", "DatasetName=<dataset_name>", "Column=<column>", "Row=<row>", "OutParam=<output_parm>", LAST );

13. lr_debug_message

14. lr_decrypt
Decrypts an encoded string
lr_decrypt("38620da61ca1093e7aa7ec");

15. lr_disable_ip_spoofing

16. lr_enable_ip_spoofing

17. lr_end_cross_vuser_transaction
Marks the completion in this vuser of a transaction started by a different vuser.

18. lr_end_sub_transaction
Marks the end of a sub-transaction.
lr_end_sub_transaction("electrical_purchases", LR_FAIL);
where electrical_purchases is sub transaction name
LR_FAIL is transaction status

19. lr_end_transaction( char *transaction_name, int status)
Marks the end of a transaction.
lr_end_transaction("deposit", LR_FAIL);
where deposit is transaction name
LR_FAIL/LR_PASS are transaction status

20. lr_end_transaction_instance

21. lr_end_timer

22. lr_error_message
This function is used when you want to output an error to different log files in Loadrunner. This function will send to output file even though logging is disabled as this is error log.

23. lr_eval_string
Returns the string argument after evaluating embedded parameters.It evaluates a parameter and after evaluating the parameter it replaces the parameter with its current value.
lr_eval_string("The row count is: {row_cnt}");
where row_cnt is The string to evaluate

24. lr_eval_string_ext
Creates a buffer and assigns it the input string after evaluating embedded parameters.

25. lr_eval_string_ext_free
Frees the buffer allocated by lr_eval_string_ext.

Note: lr_eval_string allocates memory internally. The memory is freed at the end of each iteration. If you evaluate a parameter or parameters in a loop, conserve memory by not using lr_eval_string. Instead, use lr_eval_string_extand free the memory in each loop iteration with lr_eval_string_ext_free.

26. lr_exit
Exits from the script, action, or iteration.
lr_exit(LR_EXIT_VUSER, LR_FAIL);
where LR_EXIT_VUSER  specifies how the script continues after the call to lr_exit.

27. lr_fail_trans_with_error

28. lr_get_attrib_double

29. lr_get_attrib_long

30. lr_get_attrib_string
It retrieves the name of the host string value from the mdrv command line string that was used to run the script

31. lr_get_debug_message
Returns the current message logging settings.
lr_get_debug_message function retrieves the runtime logging settings, performs a bitwise operation, and sends an appropriate message
msg_level=lr_get_debug_message( );

32.  lr_get_host_name
Returns the name of the host executing the script.
my_host = lr_get_host_name( );

33. lr_get_master_host_name

34. lr_get_transaction_duration

35. lr_get_transaction_status

36. lr_get_trans_instance_duration

37. lr_get_trans_instance_status

38. lr_get_trans_instance_think_time

39. lr_get_trans_instance_wasted_time

40. lr_get_transaction_think_time

41. lr_get_transaction_wasted_time

42. lr_get_vuser_ip

43.  lr_load_dll

44.  lr_log_message

45. lr_message

46. lr_output_message
Sends a message to log files, output windows, and other test report summaries.
lr_output_message( "We are on iteration #%s", lr_eval_string( "{iteration}" ) );

47. lr_next_row

48. lr_param_increment

49. lr_param_sprintf
lr_param_sprintf("variable","%02x",strlen(lr_eval_string("{var}")));
Gets the length of var and converts it into binary and stores in variable

50. lr_param_unique

51. lr_paramarr_idx

52. lr_paramarr_len

53. lr_paramarr_random

54. lr_peek_events

55. lr_rendezvous
Creates a rendezvous point in the Vuser script.
lr_rendezvous("Meeting");
    do_transaction(); /* application dependent transaction */

56. lr_rendezvous_ex
Creates a rendezvous point in the Vuser script.

57. lr_resume_transaction

58. lr_resume_transaction_instance

59. lr_save_datetime
Assigns the current date and time to a parameter.
lr_save_datetime("Tomorrow is %B %d %Y", DATE_NOW + ONE_DAY, "next");
lr_output_message(lr_eval_string("{next}"));
If today is January 7th, 1999, these lines will return the message: Tomorrow is January 08 1999.

60. lr_save_int
Saves an integer to a parameter.
int num;
num = 5;
lr_save_int(num * 2, "param1");
The value of param1 is now "10".

61. lr_save_param_regexp

62. lr_save_searched_string

63. lr_save_string

64. lr_save_timestamp
Saves the current time in a parameter as a time-stamp.
lr_save_timestamp("param", LAST );

65. lr_save_var

66. lr_set_debug_message

67. lr_set_transaction

68. lr_set_transaction_instance_status

69. lr_set_transaction_status

70. lr_set_transaction_status_by_name

71. lr_start_cross_vuser_transaction

72. lr_start_transaction( char *transaction_name );
Marks the beginning of a transaction
lr_start_transaction("deposit");

73. lr_start_transaction_instance

74. lr_start_sub_transaction

75. lr_stop_transaction
Freezes reporting of transaction data.

76. lr_stop_transaction_instance

77. lr_think_time
Pauses execution between commands in a script.
lr_think_time(10);

78. lr_user_data_point

79. lr_user_data_point_ex

80. lr_user_data_point_instance

81. lr_user_data_point_instance_ex

82. lr_vuser_status_message

83. lr_wasted_time

84. lr_whoami

85. lr_xml_get_values

86. lr_xml_set_values

87. lr_xml_extract

88.  lr_xml_delete

89. lr_xml_replace

90. lr_xml_insert

91. lr_xml_find

92. lr_xml_transform

93. lr_unzip

94. lr_zip

Let me know if you want to add something to this blog. Please also share your feedback.