Creating your First Test Plan

Page Contents

• Using the HTTP Proxy to record actions
  • Adding and Using an HTTP Proxy
• Organizing samplers within logic controllers
• Customizing for Dynamic Data
• Executing the Test Plan
• Results Analysis

Using the HTTP Proxy to record actions

The HTTP Proxy allows you to route a browser, such as Internet Explorer, Firefox, or Chrome, through JMeter before accessing the entered URL. It behaves in similar fashion to HTTP proxies such as Fiddler and HTTP Watch in that it stores a copy of each request and the corresponding headers, cookies, and web form values passed along with the request.

By using this component we can record entire BI workflows and use the individual requests to quickly build comprehensive test plans or regression tests. The HTTP Proxy setup in JMeter is described below.

Adding and Using an HTTP Proxy

Adding an HTTP Proxy

1. Launch JMeter
2. Right-click the WorkBench icon
3. Select Add > Non-Test Elements > HTTP Proxy Server 
   
   
4. Configure the proxy for use: 
   
   • Define a port for the proxy server to listen on. Typically the default (8080) is acceptable but if you want to run JMeter on the same machine where you have Tomcat running you may need to change this setting to a free port.
   • Set the Target Controller to tell the proxy where you want recorded requests to be stored. 
     
     I prefer to use the HTTP Proxy Server to store my requests to make it easier to transfer only the relevant items to my test plan. Feel free to store them directly inside of the test plan if desired.
   • Specify whether requests should be grouped. When using this option JMeter will attempt to identify similar requests and group them together based on your selection. Since BI4 is a complex application it is typically better to apply seperators and do the grouping yourself.
   • If you intend to capture static content make sure you check the box Retrieve All Embedded Resources from HTML Files
   • Once you are comfortable with the settings click Start at the bottom of the screen to launch the proxy 
     
     

Using the HTTP Proxy

1. Launch your browser of choice. This example uses Internet Explorer
2. Select Tools > Internet Options > Connections > Local Area Connection (LAN) Settings
3. Check the box, "Use a proxy server for your LAN"
4. Enter localhost in the address field
5. Enter 8080 (or whatever port you configured the HTTP Proxy to listen on) in the port field
6. Uncheck the box, "Bypass proxy server for local addresses" and click Ok to exit all open menus 
   
   
7. Access the BI Launch Pad at a URL like http://servername:8080/BOE/BI
8. Login and once the BI Launch Pad is rendered click the Log Off button
9. Return to JMeter and click the Stop button in the proxy server
10. A series of transactions should now be present under the proxy 
    
    
    
    A technical paper on configuring the entire JMeter process with XI 3.1 can be found here and a video blog on creating a login/logout test plan can be found here  
11. 
    
12. Organizing samplers within logic controllers
13. Once the samplers have been collected we can organize them using logic controllers. While this isn't strictly necessary, it makes individual samplers easier to find and enables meaningful results analysis.
    Using Logic Controllers

    
    

    1. Consider the number of transactions in the test plan. For this workflow there are 3 transactions: 
       
       
       • Login
       • Load BI Launch Pad main page
       • Log Off 
         
         This is important to note because even though only 2 actions (Login/Log Off) were performed, there is an automatic transaction taking place in the background. This might be a critical factor in determining the performance of a "Login" as a possible bottleneck could occur in either the actual login or rendering of the BI Launch Pad main page.
    2. Before creating the logic controllers, it is necessary to create the first element of any test plan, a thread group. Thread groups define the number of users for the test plan and are the top level component all samplers are stored in. 
       
       
       • Right-click the Test Plan icon and select Add > Threads (Users) > Thread Group 
         
         
    3. Now create 3 transaction controllers under the thread group to store the samplers we recorded previously. Transaction controllers are useful in that they report on the aggregate time all samplers included as children took to execute. 
       
       
       
       
       • Right-click the Thread Group icon and select Add > Logic Controller > Transaction Controller. Change the name to Loginand enable the checkbox Generate parent sample. This configures the behavior mentioned above where a summary of all samplers is added to the results listener. Disable the checkbox Include duration of timer and pre-post processors in generated sample. Since we are only interested in the response time of the HTTP samples themselves this would only add unecessary time to the results. 
         
         
       • Repeat the steps to create transaction controllers for Load BI Launch Pad main page and Log Off. 
         
         
    4. The next step involves cutting requests from the Workbench and pasting them into the appropriate logic controllers. JMeter attempts to "group" samplers, that is, requests that occur from a single click and don't have a significant time delay between them, and in this case it does a pretty good job. 
       
       
       • Select the first sampler in the list /BOE/BI, hold down the Shift key on your keyboard, and click logon.object which is the last sampler in the Logon transaction. JMeter adds a seperator here because it took us a couple seconds to type in the username and password to the BI Launch Pad login screen. However, actually passing credentials into the form is the last sampler we want to measure as far as a login is concerned. The seperator has no functional use and you can leave it or delete it as desired. 
         
         Right-click on the group of samplers and select Cut 
         
         
       • Select the Login transaction controller, right-click and select Paste 
         
         
       • Note the series of requests that now appears under the expanded transaction controller. These HTTP samplers contain all needed requests to perform a login to BI4. 
         
         
    5. Repeat Step 4 to populate the Load BI Launch Pad main page transaction controller 
       
       
       • Select the next sampler under the proxy server which should be main.do. Shift-click to select the last transactionspecial_tooltip.gif way down the page. You may find a slightly different order to your samplers so just make sure the last one you select immediately precedes logoff.do which starts the Log Off transaction.
       • Cut and paste these samplers into the corresponding transaction controller above.
    6. Repeat the previous steps to cut and paste the remaining samplers to the Log Off transaction controller 
       
       
       
       You should now have all the necessary samplers grouped into transaction controllers for executing a login/log off test plan in BI4.

    Customizing for Dynamic Data

    
    
    The samplers grouped above represent a workflow where a user performs a login to the BI4 system and then logs off again. That workflow was recorded with a specific user account (such as the administrator) and received a unique session identifier (identified by the stringbttoken). The BI4 user experience is customized for individual users by leveraging this type of dynamic data. 
    
    In order to properly emulate distinct users and sessions we must extract user specific data from the HTTP responses provided by the BI4 web applications such as BI Launch Pad.

    Dynamic Data Extraction

    
    

    1. If you haven't already done so save your test plan now by selecting File > Save Test Plan as and setting a name like BI4 Login Logoff
    2. If you are using BI 4.1, you must first extract the com.sun.faces.VIEW parameter from the 1st logon.faces or the logon page will not be submitted and it will simply re-post the same page content. Add a regular expression extractor as below and configure the request like this:
       
        
    3. Attach the ${COM} variable to the 2nd logon.faces request, where you will extract the bttoken value as well in BI 4.1:
       
       
        
    4. Expand the Login controller and locate the logon.object sampler for BI 4.0, and the 2nd instance of logon.faces for BI 4.1. This request is executed when you click Log On from the BI Launch Pad screen. It includes the username and password submitted to BI Launch Pad as form data. To emulate dynamic users you would customize this field with a CSV Data Set Config. In this simple plan we will stick with a single user account though. 
       
       
       BI 4.0:
       BI 4.1:
       
       
        
    5. The response body of a successful login request will contain a unique bttoken which is an alpha-numeric string representing a distinct user session, and used to prevent cross-site scripting attacks, within BI4. We need to extract this value and pass it to the remaining calls in the test plan in order to make the Log On and Log Off process work properly. 
       
       
       
       To extract this value, use a regular expression extractor. Perform the following steps to add and configure one on thelogon.object sampler: 
       
       • Right-click the logon.object sampler and select Add > Post Processors > Regular Expression Extractor
       • Change the name of the post processor to bttoken extractor
       • Configure the properties as below

         Reference Name: bttoken Regular Expression: bttoken=(.+?)& Template: $1$ Match No. (0 for random): 1 Default value: null

    This creates a JMeter variable called ${bttoken} that can be referenced in place of the previously recorded string valueMDAwRDIxMmlTZWFZMThmR1dUYTg9WmxcO2Q1PWJANTAEQ.

    Note: The detailed steps on this wiki page were created using BI 4.0. In BI 4.1 SP3 and earlier releases of BI 4.1, the regular expression has been modified slightly.  You will need to use a regex of:
    
    Regular Expression: bttoken=(.+?)"
    Note: In BI 4.1 SP4/SP5 the bttoken is now returned as part of a hidden input so the regex looks like this:
    

    Regular Expression: name="bttoken" value="(.+?)"

    
    The regular expression tells JMeter to look for a string in the response body of logon.object that matches the format: 
    
    bttoken=<Some Characters Here>& 
    
    The string (.+?) tells JMeter to store every character until it encounters an & symbol. 
    
    An overview of regular expressions can be found in Apache's mod_rewrite documentation 
    
    The template value tells JMeter how to construct the value you want the variable to contain. It is possible for a regular expression to match multiple times in a single response. For example:

    name=John
    name=Doe

    In this case, a template value of:

    $1$ $2$

    would create a variable value John Doe

    Match No. tells JMeter which match to use for the variable. In the case of multiple matches you may want to use the 2nd or 3rd instance of a match in your test plan.

    

    For this simple test plan we have but a single piece of dynamic data, the bttoken value extracted in the previous section. The fact that JMeter stores test plans in the plain text JMX format means that we can use a text editor such as Notepad to apply variables wherever they are required without a significant amount of manual effort.

    Applying Dynamic Data to a Variable

    1. Expand the Load BI Launch Pad main page transaction controller and select the first sampler, main.do.
    2. On the right-hand pane, under the Parameters section, locate the bttoken value and highlight the value currently listed there. The format should be something like: 
       
       MDAwRD07U0FTTl49UVptbF5sVlRNW2c3NV1NZWBcNTAEQ 
       
       Copy the value to the clipboard.
    3. Update the field to contain the value ${bttoken} which will apply the extracted variable to this parameter when executing the test plan. 
       
       
    4. Save the test plan and close JMeter.
    5. Locate the BI4 Login Log Off.jmx file in the bin directory of the JMeter installation, double-click it and specify Notepad (or another text editor) as the program to open it with.
    6. Once open, select Edit > Replace (or press CTRL+H) and enter the bttoken string in the Find what box.
    7. Enter the string ${bttoken} in the Replace with box and select Replace all. 
       
       
    8. Once it finishes, save the file and close Notepad.
    9. Launch JMeter again and open the test plan BI4 Login Log Off.jmx.
    10. Expand the transaction controller Log Off and note the bttoken parameter has been updated to reflect the JMeter variable with the same name. This indicates that dynamic data has been correctly applied to each component.

    Use this process whenever possible to update all of your dynamic data in a single iteration. It will save significant time in the design of future test plans.

    
    

    Executing the Test Plan

    
    
    We are almost ready to run the test plan for the first time. Before we do so, it is necessary to add a few more components to facilitate the use of cookies, and to enable collection of results.

    Adding Additional Test Components

    
    
    Add the following items to the thread group:

    1. Right-click Thread Group > Add > Config Element > HTTP Cookie Manager 
       
       
       • Check the box Clear cookies each iteration to ensure each successive thread/user stores unique cookies. 
         
         
    2. Right-click Thread Group > Add > Config Element > HTTP Request Defaults 
       We won't configure this component explicitly but it is good practice to add it to every test plan. I will demonstrate it's use in more detailed test plans
    3. Right-click Thread Group > Add > Listener > Graph Results 
       
       This listener generates a visual representation of performance.
    4. Right-click Thread Group > Add > Listener > Summary Report 
       
       This listener generates a tabular representation of performance.
    5. Right-click Thread Group > Add > Listener > View Results Tree 
       
       This sampler should not be used in high volume test executions (i.e. hundreds of users) as it is very resource intensive. However, it is useful to leverage this for the 1st test execution to ensure the test returns the expected responses.
    6. Right-click Thread Group > Add > Sampler > Debug Sampler 
       
       

    Now we will execute the test and ensure it is functioning properly.

    Running the Test Plan

    By default, the thread group will be configured for a single user. This is an excellent way to ensure the test plan runs the way you want it to before scaling out the number of users.

    1. Click Run > Start in the JMeter console
    2. Watch the thread counter in the top right increment to 1/1 and when it returns to 0/1 you will know the test plan is complete.
    3. Click the View Results Tree component and ensure the test executed properly without errors. Each transaction controller should be prefaced with a green checkbox as below.
    4. Click on the Debug Sampler entry within the View Results Tree window and note that the bttoken value was successfully retrieved by our regular expression extractor. 
       
       

    
    

    Results Analysis

    The final step in this workflow is to execute the test for a large number of users and evaluate the performance of the test. This represents the most important part of any performance test and will be covered in each of the test plans on this wiki.

    For our immediate purposes we will not cover server resource consumption, but that process is documented in an existing SCN Blog Post.

    Reviewing Results

    
    

    1. Delete the Debug Sampler and View Results Tree components as they are no longer required now that we have a functioning test plan
    2. Right-click the Graph Results component and select Duplicate. Delete the original Graph Results component.
    3. Right-click the Summary Report component and select Duplicate. Delete the original Summary Report component.
    4. Click the Thread Group and modify the settings as follows:

       Number of threads (users): 50 Ramp-Up Period (seconds): 60 Loop Count: 5

    5. Click Run > Start
    6. Wait for the test plan to finish. You may click on the Graph Results and Summary Report components to watch the test update in real-time.
    7. Select the Graph Results component and deselect the Data and Deviation boxes. This leaves Average, Median, andThroughput items enabled. 
       
       In my iteration of the test, an average transaction took 5 seconds, while we achieved throughput of ~315 transactions per minute. In this case a transaction is equal to any of logging in, rendering the main page of BI Launch Pad, or logging out. 
       
       You can also see that around the halfway point of the test, the average response time skyrocketed and throughput dropped significantly. I was able to correlate this with my single machine being fully saturated causing the processes to start swapping to disk. 
       
       
    8. Next, click on the Summary Report component and review the data listed there. In my test iteration, an average transaction took ~5 seconds. Note that to get the average execution time of the entire test it is necessary to sum the average columns. In this example, an average thread took ~15 seconds to complete the entire transaction. 
       
       Additionally, the maximum amount of time for both the Login and Load BI Launch Pad main page transactions was around 80 seconds! This occurred when the server was fully saturated and began swapping to disk. 
       
       This type of behavior can often be identified by a very large value in the Standard Deviation (Std. Dev.) column. 
       
       

    
    
    You have now successfully created your first test plan! This plan provides a foundation for many other test plans involving the BI Launch Pad and should prove useful as you continue leveraging JMeter for your SAP BusinessObjects BI Platform performance testing needs.