Tuesday, September 29, 2015

OkHttp - handy HTTP client for Java

One of my friends who is Java engineer suggested me to use this library. I really liked it, it allows you to implement your HTTP calls smoothly and without extra code :)

Find some examples of usage below (two first are taken from their documentation).

GET request: 
 OkHttpClient client = new OkHttpClient();  
 String run(String url) throws IOException {  
  Request request = new Request.Builder()  
    .url(url)  
    .build();  
  Response response = client.newCall(request).execute();  
  return response.body().string();  
 }  

POST request:
 public static final MediaType JSON  
   = MediaType.parse("application/json; charset=utf-8");  
 OkHttpClient client = new OkHttpClient();  
 String post(String url, String json) throws IOException {  
  RequestBody body = RequestBody.create(JSON, json);  
  Request request = new Request.Builder()  
    .url(url)  
    .post(body)  
    .build();  
  Response response = client.newCall(request).execute();  
  return response.body().string();  
 }  

This is my implementation of methods for HTTP calls.
 private JSONObject request(String path, String method, String body) throws ApiException {  
     Builder builder = new Request.Builder()  
       .url(baseUrl + path.replaceAll("^/", ""));  
     if (method.equals("POST")) {  
       builder.post(RequestBody.create(JSON, body));  
     }  
     else if (method.equals("DELETE")) {  
       builder.delete();  
     }  
     try {  
       Response httpResponse = httpClient.newCall(builder.build()).execute();  
       if (httpResponse.code() != 200) {  
         throw new ApiException(httpResponse.body().string());  
       }  
       String httpResponseBody = httpResponse.body().string();  
       System.out.println("ApiClient.request(" + path + "): " + httpResponseBody);  
       return (JSONObject)JSONValue.parse(httpResponseBody);  
     }  
     catch (IOException e) {  
       throw new ApiException(e.getMessage());  
     }  
   }  
   public JSONObject get(String resource, Map<String, String> params) throws ApiException {  
     return request(resource + "?" + urlEncodeUTF8(params), "GET", "");  
   }  
   public JSONObject post(String path, String body) throws ApiException {  
     return request(path, "POST", body);  
   }  

Monday, September 28, 2015

Charles: usage for native mobile application testing (IOS)

Mobile testing is new for me. I found extremely useful HTTP proxy tool Charles for monitoring traffic, which our mobile app sends/receives. It helped me to investigate bugs more deeply, not just their UI implication.


Set up Charles to see phone’s traffic

  1. Install Charles on your computer.
  2. Start Charles.
  3. Make sure your phone and computer are connected to same WiFi network.
  4. Find your network IP address in System Preferences -> Network.
  5. Open WiFi settings on your phone: Settings -> WiFi -> {your WiFi network name} -> HTTP Proxy. Set proxy to Manual and enter your network IP address and Port (by default it’s 8888). Leave Authentication switched off.
  6. Install root certificate on your IOS device, open following link in your phone browser: http://www.charlesproxy.com/getssl
  7. In Charles add a domain which you want to monitor in Proxy -> SSL Proxying Settings; enable SSl Proxying:
Screen Shot 2015-09-28 at 10.58.42.png
  1. Do any interactions in your app to make any HTTP calls, you should see a popup from Charles to confirm device usage.


Now you should see all calls, which your application makes and what are server responses.


Simulate Internet connection

First of all set up Charles on your computer (see steps above). To change your network connection settings do following steps:
  1. In Charles open Proxy -> Throttle Settings. Enable throttling by checking check box:
Screen Shot 2015-09-28 at 11.25.41.png
  1. Now you can select different throttle presets. You can set your custom network parameters or use ready settings like ‘3G’ throttle preset.
Enjoy your testing :)

Friday, September 4, 2015

Firefox driver - Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms

CASE STUDY
My tests are written with Thucydides + Firefox Driver. Test suite is successfully running on my local machine. My task is to set up tests in CI on remote server. I’m using latest Webdriver and Firefox versions (Selenium documentation says they are compatible). Nevertheless, tests failed with “Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms”.


SOLUTION
I faced this exception several times before. Every time I solved that issue by downgrading Firefox browser on my test environment and turning off automatic updates. This time it didn’t help. I tried several FF & Selenium versions without any success.

Then I found information that Firefox driver runs on 7055 port by default, if the port is busy it tries to run on 7054 or 7056 ports. So when those 3 ports are taken by some process - Webdriver won’t be able to start.

Indeed, I checked if those ports were taken using command:

lsof -i | grep 7055

It turned out that they were busy and this was a cause of the exception. I killed the processes on the named ports and my tests started running successfully.

So as a summary. I was using Thucydides + Firefox driver. In some cases when Thucydides work was interrupted unexpectedly it doesn’t finish it’s processes correctly. So some Firefox processes were hanging on mentioned above 7054-7056 ports and didn’t let driver start over again.

Hope this post will help someone to fix quite popular issue with Webdriver.

Friday, September 20, 2013

Sharing remote screen for Selenium tests monitoring

CASE STUDY
We have a big suite of Selenium tests. It is running on a remote continuous integration server (Jenkins). Some tests are successfully passing on the local machine but are always failing when running on the server. It was really difficult to find a cause of the failure on a remote server using only logs.
Task/goal: Find a way of graphical monitoring of the tests running process on the remote server.


SOLUTION
Short idea & results: We started sharing X display of a remote server over VNC to our local computers. This really helped, because now we can see what is going on with tests when they’re running on the remote machine and it is much easier to fix broken tests.


First of all install:
  • Xvfb (on a remote server) - a server that performs all graphical operations in memory, not showing any screen output. From the point of view of the client, it acts exactly like any other server, serving requests and sending events and errors as appropriate. However, no output is shown.




  • VNC client (on a local machine) - a program that watches, controls, and interacts with a server. The client controls the server.


Follow the steps below:
  1. Open your Jenkins project configuration page and make sure that this check-box is checked.
           Now Xvfb will start every time our project is building. Run a Jenkins project now.


  1. Find a number of display on which your Jenkins job is running.
  • in command prompt launch to your server via SSH and run a command: ps afx | grep vfb
  • you should see something like this (in this case number of display is 2):   
 


  1. Start x11vnc server on a display which you found in a previous step:
                       x11vnc -display :<NUMBER_OF_DISPLAY>


  1. Create an SSH tunnel between your local machine and the server where you tests are running:

  2. Run VNC client on your local machine, create a new connection. With Chicken of the VNC it looks like this:
Now click on Connect, wait for a while…
Woohoo! Now you see what is going on with your tests on a remote machine.

Tuesday, November 27, 2012

Тренинг "Exploratory Testing" (Андрей Дзыня)


Мне посчастливилось побывать на тренинге Андрея Дзыни “Exploratory Testing”. Мероприятие проходило в офисе компании, в которой я работаю (Cogniance). Наверное, всем известно, что тренинг этот проходит не в первый раз. Но! Теперь он обрел новый двухдневный формат. Итак, расскажу вам чем мы занимались.
День первый по большей своей части был теоретическим. Андрей рассказал об exploratory тестировании как таковом, о том чем оно отличается от scripted и ad-hoc тестирования. Также мы узнали много интересного о турах, евристиках, парном тестировании, построении функциональной карты приложения и об оформлении результатов тестирования. Занятие не ограничилось “сухой” теорией, нам дали возможность попрактиковаться в построении функциональной карты приложения, парном тестировании, участии в “дебрифах”, а также в составлении отчета о тестировании. Забыла о самом интересном - мы определяли свой тип тестировщика. Бонус дня: мы узнали много нового о лошадях и калькуляторах :)
День второй. С новыми силами и знаниями, уложившимися в голове, мы приступили ко второй части тренинга. Девиз дня: “Минимум теории - максимум практики”. Андрей рассказал об инструментах, которые могут облегчить жизнь тестировщика (в некоторые из них я влюбилась с первого взгляда). Нас разделили на команды, каждая команда отвечала за маленький кусок функциональности тестируемого приложения, для которого она должна была составить функциональную карту, протестировать его, представить результаты тестирования. Все команды соединили части функциональных карт в одну большую (нашу гордость).


Участники рисуют функциональную карту

Мы попрактиковались работать в стиле сессий, это было очень интересно и ново для меня. Эффект потрясающий, особенно для людей, имеющих проблемы с управлением временем. В ходе тестирования мы использовали инструмент для управления сессиями, который тоже показался довольно удобным.



Участники работают во время сессии

Завершение дня прошло в общении, обмене опытом из своих текущих проектов. Мы задавали вопросы Андрею, который охотно и подробно на них отвечал. Для особо стойких тренинг завершился на кухне за чашкой чая и интересной беседой о тестировании.

Итог. Безусловно, тренинг стоит внимания. Признаться, всегда относилась с опаской ко всем тренингам-семинарам по ручному тестированию (возникает банальный вопрос “да чего я там не знаю?”). Но, я изменила свое мнение за эти два дня. Время было проведено продуктивно, насыщенно новой для меня информацией. Андрей всегда делал акцент на практическом применение всего, о чем шла речь. И самое главное - я получила от тренинга море воодушевления, позитива и новых идей. Теперь не терпится начать использовать все полученные знания на практике и совершенствоваться, совершенстваться и... угадайте что? Творческих вам успехов!

Thursday, August 30, 2012

Google Chrome Remote Debugging для тестирования производительности мобильного веб-приложения

Недавно на проекте возникла интересная задача. Разрабатываем мы мобильное веб-приложение. Нужно было измерить время загрузки отдельных элементов страницы (*.js, *.css, *.png файлы) для разных типов подключений: WiFi, Edge, 3G.

После не очень длительного исследования существующих решений, мой выбор пал на относительно новую возможность Google Chrome - Remote Debugging. Для того чтобы воспользоваться данным решением вам необходимо работать с версией Android 4.0 и выше (мобильная версия Google Chrome доступна только для сэндвича).

Настройте тестовую среду, выполнив следующие шаги:
1. Убедитесь, что у вас установлены: Android SDK и Chrome; ваше мобильное устройство настроено для разработки.

2. Подключите мобильное устройство к компьютеру по USB кабелю. Для коммуникации с устройством нам нужен Android Debug Bridge (adb), который включен в Platform Tools (Android SDK).

3. Для удобства добавьте Platform Tools (<sdk>/platform-tools/) к переменной окружения PATH.

4. В командной строке запустите команду adb devices. После запуска команды убедитесь, что ваше устройство появилось в отображенном списке. Если нет - убедитесь, что на вашем телефоне разрешена USB-отладка. Список выглядит примерно так:


5. На мобильном устройстве запустите браузер Chrome. Откройте Настройки -> Инструменты разработчика и выберите галочку Включить веб-отладку через USB.

6. Запустите в консоли следующую команду для того, чтобы активировать передачу через порт:

adb forward tcp:9222 localabstract:chrome_devtools_remote 

7. Откройте Google Chrome браузер и загрузите страницу: localhost:9222

8. Вы увидите набор эскизов страниц, которые открыты в вашем мобильном браузере в данный момент. Выберите страницу, которую вы собираетесь отлаживать. Вот пример того, что вы должны увидеть в браузере:

  
9.  Теперь вы можете начать отладку мобильного контента на своем рабочем компьютере в Developer Tools. Вы можете измерить время загрузки каждого элемента веб-страницы:



Остается только обратить ваше внимание на то, что при проведении измерений нужно учитывать кеширование страницы. Чтобы полностью исключить кеширование советую:
    - Проводить отладку в инкогнито режиме мобильного браузера;
    - Выключить кеширование в Developer Tools (шестеренка в правом нижнем углу):

Ну вот и все, удачной охоты на багов! :)

Tuesday, August 21, 2012

Ukrainian Testing Days #1, Odessa



Побывала на первой всеукраинской конференции Ukrainian Testing Days. Солнечная Одесса, 200 участников из многих городов Украины, России и Беларуси. Конференция проводилась в гостинице "Бристоль". Что удивило - на всеукраинской конференции половина докладчиков были из других стран СНГ (и даже Германии). В общем-то я и не против, а очень даже за.

К сожалению, поприсутствовать на всех докладах не удалось, так как конференция разделялась на две секции. Из посещенных выступлений очень понравились доклады Артема Кошелева и Николая Алименкова. Николай рассказывал об автоматизации тестирования пользовательского интерфейса веб-приложений. Тема доклада Артема: "Качество кода автотестов". После выступления Артема захотелось встать и пойти рефакторить тесты (кстати, он же и был награжден за лучший доклад).

После конференции все отправились на After Party - берег Черного моря, вечер, закат, вечно голодные чайки и толпа ИТ-шников - что может быть лучше? Но для многих на этом дело не закончилось, и After Party плавно перешла в After ... After  Party =)

Хочется также отметить организацию конференции, все было здорово, особенно понравилась идея препати. Правда, как мне показалось, лед все-таки не треснул...

Одним словом, конференция понравилась, я получила от нее то, что хотела, а именно - энтузиазм и задор на исполнение всех идей.