Execute DB queries in loadrunner webservices protocol

Loadrunner web-services protocol can be used to execute DB queries

Action()

{

    int retval;

    int NumRows=0;

   retval = lr_db_connect("StepName=DatabaseConnection",

        "ConnectionString=dsn=Test;userid=test; password=Test",

        "ConnectionName=food",

        "ConnectionType=ODBC",

        LAST );

   

     lr_start_transaction("Report");

 

NumRows = lr_db_executeSQLStatement("StepName=PerformQuery",

    "ConnectionName=foodb",

    "SQLStatement="

    "select count(*) indv_knt, count(distinct lbi_hshl_id) hshl_knt,"

    "count(distinct best_dmid_num) dmid_knt \r\nfrom "

     "CDMZDATAVIEW.best_domestic_postal_addr where ctry_cd = 'US';",

    "DatasetName=MyDataset",

    LAST );

 

   lr_end_transaction("Report", LR_AUTO);

    lr_db_dataset_action("StepName=PrintDataset",

        "DatasetName=MyDataset",

        "Action=PRINT",

         LAST );   

     lr_output_message("The query returned %d rows.", NumRows);

        

  

    

    return 0;

}

RESTful Web Services - Test with loadrunner

Sumilating RESTful web Services using LoadRunner


REST Services can be scripted using web_custom_request by adding appropriate headers using web_add_header function before the web_custom_request.

An example for REST services script is given below.


/*********************************

web_add_header ("X-ELS-APIKey","11111");

web_add_header ("X-Forwarded-For","12.5.28.133");

web_add_header ("Accept","text/xml");

web_custom_request("web_custom_request",

"URL=http://host:8080/content/abstract/*********",

"Method=POST",

"TargetFrame=",

"EncType=text/xml; charset=iso-8859-1",

"Resource=0",

"Referer=",

"Mode=HTTP",

"Body=",

LAST);

*****************************/

If you want to verify the response manually, you need to set up the header values first in your browser.

Please find below the steps for setting up the header using mozilla firefox browser.

• Open firefox. Click "Add-ons" from tools menu
• Click "get Add-ons" tab.
• Type "HTTP header" in the text box for search all add-ons and enter.
• In search results, click on "Add to firefox" for "Modify Headers 0.6.6" and install. Now you can see "Modify Headers 0.6.6" in the extension tab.
• Click on "Modify Headers 0.6.6" from the "Extensions" tab and select the check box for "Always on" and "Open modify header in a new tab" and close.
• Now click "Modify headers" from the firefox tools menu and add the appropriate header name and value for your request.

Now launch the URL in the firefox browser and verify the response manually.

Also refer RESTClient  addon available for firefox to test RESTful services

Analyze Performance Results, Report, and Retest

Managers and stakeholders need more than just the results from various tests — they need conclusions, as well as consolidated data that supports those conclusions. Technical team members also need more than just results — they need analysis, comparisons, and details behind how the results were obtained. Team members of all types get value from performance results being shared more frequently. Before results can be reported, the data must be analyzed. Consider the following important points when analyzing the data returned by your performance test:
Analyze the data both individually and as part of a collaborative, cross-functional technical team.
Analyze the captured data and compare the results against the metric’s acceptable or expected level to determine whether the performance of the application being tested shows a trend toward or away from the performance objectives.
If the test fails, a diagnosis and tuning Step are generally warranted.
If you fix any bottlenecks, repeat the test to validate the fix.
Performance-testing results will often enable the team to analyze components at a deep level and correlate the information back to the real world with proper test design and usage analysis.
Performance test results should enable informed architecture and business decisions.
Frequently, the analysis will reveal that, in order to completely understand the results of a particular test, additional metrics will need to be captured during subsequent test-execution cycles.
Immediately share test results and make raw data available to your entire team.
Talk to the consumers of the data to validate that the test achieved the desired results and that the data means what you think it means.
Modify the test to get new, better, or different information if the results do not represent what the test was defined to determine.
Use current results to set priorities for the next test.
Collecting metrics frequently produces very large volumes of data. Although it is tempting to reduce the amount of data, always exercise caution when using data-reduction techniques because valuable data can be lost. Most reports fall into one of the following two categories:
Technical Reports
Description of the test, including workload model and test environment.
Easily digestible data with minimal pre-processing.
Access to the complete data set and test conditions.
Short statements of observations, concerns, questions, and requests for collaboration.
Stakeholder Reports
Criteria to which the results relate.
Intuitive, visual representations of the most relevant data.
Brief verbal summaries of the chart or graph in terms of criteria.
Intuitive, visual representations of the workload model and test environment.
Access to associated technical reports, complete data sets, and test conditions.
Summaries of observations, concerns, and recommendations. The key to effective reporting is to present information of interest to the intended audience in a manner that is quick, simple, and intuitive. The following are some underlying principles for achieving effective reports:
Report early, report often.
Report visually.
Report intuitively.
Use the right statistics.
Consolidate data correctly.
Summarize data effectively.
Customize for the intended audience.
Use concise verbal summaries using strong but factual language.
Make the data available to stakeholders.
Filter out any unnecessary data.
If reporting intermediate results, include the priorities, concerns, and blocks for the next several test-execution cycles.

http://perftesting.codeplex.com/Wiki/View.aspx?title=How%20To%3A%20Conduct%20Performance%20Testing%20Core%20Steps%20for%20a%20Web%20Application

Source - Microsoft book

Execute the Performance Test

Executing tests is what most people envision when they think about performance testing. It makes sense that the process, flow, and technical details of test execution are extremely dependent on your tools, environment, and project context. Even so, there are some fairly universal tasks and considerations that need to be kept in mind when executing tests.Much of the performance testing–related training available today treats test execution as little more than starting a test and monitoring it to ensure that the test appears to be running as expected. In reality, this Step is significantly more complex than just clicking a button and monitoring machines. Test execution can be viewed as a combination of the following sub-tasks:
Coordinate test execution and monitoring with the team.
Validate tests, configurations, and the state of the environments and data.
Begin test execution.
While the test is running, monitor and validate scripts, systems, and data.
Upon test completion, quickly review the results for obvious indications that the test was flawed.
Archive the tests, test data, results, and other information necessary to repeat the test later if needed.
Log start and end times, the name of the result data, and so on. This will allow you to identify your data sequentially after your test is done. As you prepare to begin test execution, it is worth taking the time to double-check the following items:
Validate that the test environment matches the configuration that you were expecting and/or designed your test for.
Ensure that both the test and the test environment are correctly configured for metrics collection.
Before running the real test, execute a quick smoke test to make sure that the test script and remote performance counters are working correctly. In the context of performance testing, a smoke test is designed to determine if your application can successfully perform all of its operations under a normal load condition for a short time.
Reset the system (unless your scenario calls for doing otherwise) and start a formal test execution.
Make sure that the test scripts’ execution represents the workload model you want to simulate.
Make sure that the test is configured to collect the key performance and business indicators of interest at this time.
Source - Microsoft book

Implement the Performance Test Design

The details of creating an executable performance test are extremely tool-specific. Regardless of the tool that you are using, creating a performance test typically involves scripting a single usage scenario and then enhancing that scenario and combining it with other scenarios to ultimately represent a complete workload model. Load-generation tools inevitably lag behind evolving technologies and practices. Tool creators can only build in support for the most prominent technologies and, even then, these have to become prominent before the support can be built. This often means that the biggest challenge involved in a performance-testing project is getting your first relatively realistic test implemented with users generally being simulated in such a way that the application under test cannot legitimately tell the difference between the simulated users and real users. Plan for this and do not be surprised when it takes significantly longer than expected to get it all working smoothly.
Source - Microsoft books

Configure the Performance Test Environment

Preparing the test environment, tools, and resources for test design implementation and test execution prior to features and components becoming available for test can significantly increase the amount of testing that can be accomplished during the time those features and components are available.Load-generation and application-monitoring tools are almost never as easy to get up and running as one expects. Whether issues arise from setting up isolated network environments, procuring hardware, coordinating a dedicated bank of IP addresses for IP spoofing, or version compatibility between monitoring software and server operating systems, issues always seem to arise from somewhere. Start early, to ensure that issues are resolved before you begin testing.Additionally, plan to periodically reconfigure, update, add to, or otherwise enhance your load-generation environment and associated tools throughout the project. Even if the application under test stays the same and the load-generation tool is working properly, it is likely that the metrics you want to collect will change. This frequently implies some degree of change to, or addition of, monitoring tools.
Source - Microsoft books

Plan and Design Tests

Planning and designing performance tests involves identifying key usage scenarios, determining appropriate variability across users, identifying and generating test data, and specifying the metrics to be collected. Ultimately, these items will provide the foundation for workloads and workload profiles. When designing and planning tests with the intention of characterizing production performance, your goal should be to create real-world simulations in order to provide reliable data that will enable your organization to make informed business decisions. Real-world test designs will significantly increase the relevancy and usefulness of results data. Key usage scenarios for the application typically surface during the process of identifying the desired performance characteristics of the application. If this is not the case for your test project, you will need to explicitly determine the usage scenarios that are the most valuable to script. Consider the following when identifying key usage scenarios:
Contractually obligated usage scenario(s)
Usage scenarios implied or mandated by performance-testing goals and objectives
Most common usage scenario(s)
Business-critical usage scenario(s)
Performance-intensive usage scenario(s)
Usage scenarios of technical concern
Usage scenarios of stakeholder concern
High-visibility usage scenarios When identified, captured, and reported correctly, metrics provide information about how your application’s performance compares to your desired performance characteristics. In addition, metrics can help you identify problem areas and bottlenecks within your application. It is useful to identify the metrics related to the performance acceptance criteria during test design so that the method of collecting those metrics can be integrated into the tests when implementing the test design. When identifying metrics, use either specific desired characteristics or indicators that are directly or indirectly related to those characteristics.

Source - Microsoft book