{"id":3675,"date":"2012-08-22T10:51:56","date_gmt":"2012-08-22T14:51:56","guid":{"rendered":"http:\/\/www.webperformance.com\/load-testing-tools\/blog\/?p=3675"},"modified":"2017-05-25T15:55:46","modified_gmt":"2017-05-25T19:55:46","slug":"load-testing-mobile-websites-for-android","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2012\/08\/load-testing-mobile-websites-for-android\/","title":{"rendered":"Load Testing Mobile Websites for Android"},"content":{"rendered":"

Load Testing a mobile website has a few key differences from testing the full desktop-oriented version of a website. In this article, I will review those differences and show you how to use Load Tester to create testcases using the stock browser on Android 4 \/ ICS (the Ice-Cream Sandwich release).<\/p>\n

This article does not cover the entire load testing process – I recommend checking out our videos<\/a> and tutorials<\/a> for more information on using Load Tester to run and analyze load tests.<\/p>\n

Before I jump in, I want to give a quick introduction on how a load test is created in Load Tester (and most other load-testing tools). If you have already used a record-and-replay load testing tool, feel free to skip the rest of this paragraph. A load test models one or more usage scenarios, which we call testcases, that will be executed by virtual\u00a0 users during a load test. Testcases are created by performing those actions during a recording session and then customizing the resulting testcase as necessary. When you start a recording, Load Tester changes the proxy settings for the browser and launches it. The browser will then use Load Tester as a proxy server during the recording – thus allowing Load Tester to capture all of the messages exchanged between your browser and the web server(s). This series of HTTP requests and responses is what we call a recording. A testcase is created, from the recording, that can be replayed by a virtual user to simulate the actions of a real user. During a load test, one or more testcases are executed simultaneously by many virtual users – thus placing realistic load on your system.<\/p>\n

Recording a testcase<\/h2>\n

When recording with a desktop browser, Load Tester can automatically configure the browser’s proxy settings and launch it for you. But when dealing with mobile devices, this is not possible – as the device is either physically separate or is running inside an emulator which does not provide outside controls. But not to worry – the configuration for Android 4 is easy.<\/p>\n

Step 1 – Configure Load Tester<\/h3>\n

When recording from a phone or tablet, we need to make two changes to the recording settings in Load Tester. The settings are located in the Recording preferences page<\/a>, which is accessed from the Window<\/em> menu > Preferences<\/em>, then expand the Web Performance<\/em> node and select the Recording<\/em> node.<\/p>\n

    \n
  1. Turn on the Manually select recording ports<\/em> option. Note the default ports, or change as needed to any open ports on your system. This will set the recorder ports to known ports (otherwise Load Tester may pick different ports when a recording is started).<\/li>\n
  2. Turn off the Launch default browser when recording<\/em> option – this will prevent launching the desktop browser during recording.<\/li>\n<\/ol>\n

    \"\"<\/a><\/p>\n

     <\/p>\n

    Step 2 – Configure Android 4 Phone \/ Tablet<\/h3>\n

    One of the welcome additions to Android 4 is the ability to set the proxy settings (in previous versions, this could not be changed without root access). Open the Settings<\/em> application, then under Wireless & Networks<\/em> choose More…<\/em>, then Mobile Networks<\/em> > Access Point Names<\/em> > TelKila<\/em>. That last one, TelKila<\/em>, may be different on your phone – I’ve listed the settings as they appear in the Android 4 emulator in the Android SDK. Fill in the Proxy field with the IP address of the computer running Load Tester (see screenshot below). Do not use localhost<\/em>, even if you are running in the emulator, as this will resolve to the Android device and the recording will fail. Next, fill in the Port field with the SSL port number configured for the recorder in the previous step (this port works for both HTTP and SSL traffic). After this change is made, all HTTP requests from the phone will be directed through the proxy – Load Tester’s recorder. If Load Tester is not running or not reachable, the browser will be unable to communicate, so be sure to change this setting back when the recording is complete if the Android device is to be used for other tasks.<\/p>\n

    \"\"<\/a>

    Configure Android proxy setting<\/p><\/div>\n

    There is one more configuration change that we recommend if any SSL is in use – turn off security warnings. To do this, first open the Android browser and choose Settings<\/em> from the menu. Go to Privacy and Security<\/em> and turn off the Show security warnings<\/em> option (see screenshot below). This will suppress the warnings the browser will show each time Load Tester presents it’s SSL certificate during the recording process – this is necessary for Load Tester to record and analyze the traffic on SSL connections. While not as serious, we also recommend reverting this setting before using the device for other purposes.<\/p>\n

    \"\"<\/a>

    Turn off security warnings<\/p><\/div>\n

     <\/p>\n

    Record a Testcase<\/h3>\n

    With those settings adjusted, you can start the recording. Return to Load Tester and press the Record button on the toolbar. It will open a new testcase editor which will be populated with pages and transactions as you browse the site.<\/p>\n

    \"\"<\/a>

    The record button and the testcase editor<\/p><\/div>\n

    Navigate to the first page of your site in the Android browser.\u00a0 Then return to Load Tester and confirm the page is listed in the testcase editor. If it does not, then the browser is not correctly configured to use Load Tester’s recorder as its proxy. Double-check the host and port settings. If they are correct, then raise an issue in our technical support system<\/a> and we’ll help you get it working.<\/p>\n

    If you want to simulate new<\/em> users (users coming to your site for the first time) then before you browse to the first page of the site, you must clear the browser cache. You can do this on the browser Privacy & Security page (see the screenshot earlier in this post).<\/p>\n

    Once you have confirmed the recording is working, continue browsing the site to complete the scenario you want to test. I recommend starting with the simplest possible testcase at first – preferably one with a few pages but without a login or any user input.<\/p>\n

    Run a load test<\/h2>\n

    After creating a testcases, add it to a load configuration (by choosing New Load Configuration<\/em> from the pop-up menu for the testcase in the Navigator<\/em> view) and run quick load test to get a feel for the entire process. This 30-minute Introduction<\/a> video will give you a good overview. After completing a basic load test, you can move on to more complex testcases – these tutorials on Unique User Identities<\/a> and Customizing User Input<\/a> will help get you going.<\/p>\n

    Chris Merrill, Chief Engineer<\/p>\n","protected":false},"excerpt":{"rendered":"

    Load Testing a mobile website has a few key differences from testing the full desktop-oriented version of a website. In this article, I will review those differences and show you how to use Load Tester to create testcases using the stock browser on Android 4 \/ ICS (the Ice-Cream Sandwich release).
    \nThis article does not cover the entire load testing process – I recommend checking out our     videos<\/a> and tutorials<\/a> for more information on using Load Tester to run and analyze load tests.
    \nBefore I jump in, I want to give a quick introduction on how a load test is …     Continue reading »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,136],"tags":[],"class_list":["post-3675","post","type-post","status-publish","format-standard","hentry","category-load-testing","category-mobile"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/3675","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/comments?post=3675"}],"version-history":[{"count":76,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/3675\/revisions"}],"predecessor-version":[{"id":5843,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/3675\/revisions\/5843"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=3675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=3675"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=3675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}