3. Особенности автоматизации Web и мобильных приложений

Назад Содержание Дальше

Веб-приложения стали очень популярными в последние годы и по сложности не уступают настольным приложениям. В книге мы чаще всего приводим примеры скриптов для настольных приложений (Блокнот, Калькулятор и т.п.), однако все подходы, описываемые при этом, в равной степени относятся и к веб-приложениям. В этой главе мы рассмотрим некоторые особенности автоматизации тестирования веб-приложений, с которыми вы можете столкнуться в работе.

3.1 Тестирование в разных браузерах

Зачастую одним из требований к программе является совместимость со всеми браузерами. На данный момент существует пять браузеров (в скобках указан процент использования каждого браузера на конец 2011 года, согласно сайту http://www.w3schools.com):

  • Mozilla Firefox (38,7%)
  • Google Chrome (32,3%)
  • Internet Explorer (21,7%)
  • Safari (4,2%)
  • Opera (2,4%)

Существует как минимум три уровня сложностями, с которыми придется столкнуться, пытаясь создать универсальные скрипты, которые будут работать в любом браузере:

  • Каждый браузер использует собственную архитектуру и, следовательно, имеет свои особенности работы с веб-страницами. Например, один и тот же тест, обращающийся к элементам страницы по xpath, в Internet Explorer будет работать в несколько раз медленнее, чем в Mozilla Firefox, из-за некоторых особенностей собственно Internet Explorer’а.
  • Каждый браузер регулярно обновляется и обычно существует несколько актуальных версий, широко используемых пользователями.
  • Некоторые браузеры являются кроссплатформенными, т.е. существуют их версии для Windows, Linux и MacOS.

Кроме этого всего, существуют 32-х и 64-х битные операционные системы и приложения, что ещё больше увеличивает сложность тестирования.

Естественно, невозможно протестировать приложение для всех комбинаций упомянутых случаев, но зачастую это и не нужно. Лучше всего автоматизировать тесты под один браузер (например, самый популярный в данный момент или тот, с которым будут работать пользователи тестируемого приложения), а тонкости поведения приложения в разных браузерах оставить для ручного тестирования.

Некоторые инструменты работают с несколькими браузерами. Например, Selenium может работать с любым браузером и на любой системе, а TestComplete поддерживает два браузера (Internet Explorer и Firefox). Однако это вовсе не значит, что вы сможете написать и отладить скрипты под Firefox, а затем просто поменять браузер на другой и безболезненно запустить там все тесты. Скорее всего, для портирования скриптов под другой браузер вам придётся потратить столько же времени, сколько вы потратили на их создание. Другими словами, если вы оцениваете разработку скриптов под один браузер в 100 часов, значит под 2 браузера вам понадобится 200 часов, под 3 браузера – 300 и т.д. Также имейте ввиду, что в дальнейшем вам придётся запускать и поддерживать все эти скрипты, на что также будет уходить гораздо больше времени, чем в случае работы с одним браузером.

В качестве примера приведём класс Browser, который запускает один из браузеров, поддерживаемых TestComplete’ом, и скрипт, который выполняет простые действия в разных браузерах (открывает страничку http://ya.ru/, выполняет поиск текста и дожидается, пока страница с результатами загрузится).

// Browser Class
function Browser(browserName)
{
  while(Sys.WaitProcess(browserName, 1).Exists)
  {
    Sys.Process(browserName).Page("*").Keys("~[F4]");
    aqUtils.Delay(3000);
  }
  TestedApps.Items(browserName).Run();
  return Sys.Process(browserName);
}


function TestInTwoBrowsers()
{
  var browsers = ["iexplore", "firefox"];

  for(var i in browsers)
  {
    var br = new Browser(browsers[i]);
    var page = br.Page("*").ToUrl("http://ya.ru");
    page.Wait();
    page.INPUT.Item("text").Keys("Search string");
    page.INPUT.Item("INPUT").Click();
    page.Wait();
  }
}

Этот пример корректно отработает для Internet Explorer и Firefox, но пусть вас не расслабляет эта кажущаяся простота: это очень простой скрипт, выполняющий всего несколько действий; чем больше действий надо будет выполнить – тем сложнее будут тестовые скрипты.

3.2 Загрузка страниц и AJAX-компоненты

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

Когда мы работаем с настольными приложениями, их код обычно уже загружен в память компьютера, поэтому открытие новых окно происходит практически мгновенно. В случае же веб-приложений, скорость загрузки каждой страницы зависит от её размера и от текущей скорости подключения, поэтому одна и та же страница может загружаться в разное время с разной скоростью.

Чтобы решить эту проблему, в большинстве инструментов для автоматизации тестирования предусмотрены механизмы ожидания загрузки страницы. Например, в TestComplete для этого используется метод Wait:

var ff = Sys.Process("firefox");
var page = ff.ToURL("http://vkontakte.ru/search");
page.Wait();

В этом примере скрипт не продолжит работу до тех пор, пока страница поиска не загрузится полностью.

Если вы пользуетесь инструментом, в котором нет подобного механизма, вам придется самостоятельно его разработать. Самый простой способ – это ожидание появления на экране какого-либо элемента или же ожидание свойства элемента. Иногда это может быть самый последний элемент на странице (например, футер), а иногда и элемент из середины, который сначала появляется на экране, а затем подгружает динамические данные с сервера. В каждом случае это будет свой уникальный элемент. Поэтому можно написать функцию, которая будет принимать два параметра: адрес, на который необходимо перейти, и элемент, которого нужно дождаться.

При ожидании элемента имейте ввиду, что необходимо предусмотреть возможность выхода из бесконечного цикла в том случае, если ожидание затянулось слишком долго (например, если элемент не появляется в течение пяти минут, это, скорее всего, говорит о том, что страница по какой-то причине «зависла»).

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

Например, на странице поиска сайта Вконтакте есть выпадающий список, в котором можно выбрать страну, после чего появляется новый элемент управления со списком городов этой страны. Более того, сами списки по умолчанию не видны на экране и появляются только после нажатия на соответствующий элемент страницы.

Вот пример записанного и слегка упрощенного скрипта, который выбирает сначала страну, а затем город.

function Test1()
{
  var ff = Sys.Process("firefox");
  var page = ff.ToURL("http://vkontakte.ru/search");
  page.Wait();
  // Log.Message(page.LI.Item("LI_3").innerHTML);
  // Log.Message(page.LI.Item("LI_235").innerHTML);
  page.TD.Item("dropdown2").Click();
  page.LI.Item("LI_3").Click();
  // page.Refresh();
  page.TD.Item("dropdown1").Click();
  page.LI.Item("LI_235").Click();
}

Обратите внимание на две закомментированных строки вызова метода Log.Message(): если их раскомментировать, мы получим в логе ошибки о том, что элементы не найдены, так как ни выпадающего списка со странами, ни списка с городами еще нет на странице.

Следующая закомментированная строка – это команда обновления элементов дерева страницы (page.Refresh()). Если не обновить содержимое страницы после выбора страны, TestComplete может «не увидеть» элементы, которых не существовало в момент создания страницы и которые были добавлены динамически.

Во всем остальном работа с AJAX-компонентами не представляет особых трудностей и выглядит так же, как и работа с другими элементами управления.

3.3 Снимки экрана и страницы (скриншоты)

Одной из особенностей веб-приложений является то, что в отличие от настольных приложений, размер веб-страниц по вертикали может быть больше размера экрана и пользователю приходится прокручивать содержимое с помощью скроллера.

Если при этом необходимо сделать снимок экрана (например, в случае возникновения ошибки), на снимок может не попасть важная информация со страницы, которая в данный момент скрыта от пользователя.

Решение этой проблемы – создание снимка страницы вместо снимка экрана. При этом необходимо сделать снимок видимой области страницы, затем прокрутить страницу вниз, снова сделать снимок и т.д., после чего «склеить» полученные снимки в одну картинку.

Многие инструменты позволяют это делать автоматически. Например, в TestComplete есть отдельный метод Picture(), который позволяет сделать снимок любого объекта (будь то окно, элемент управления или Рабочий стол), а для объектов Page есть дополнительный метод PagePicture(), который делает снимок всей веб-страницы, прокручивая ее в случае необходимости.

В следующем примере мы выводи в лог две разных картинки: снимок экрана и снимок страницы.

function TestScreenshots()
{
  var ff = Sys.Process("firefox");
  var page = ff.ToURL("http://smartbear.com");
  page.Wait();
  Log.Picture(Sys.Desktop.Picture());
  Log.Picture(page.PagePicture());
}

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

Поэтому при работе с веб-приложениями имеет смысл делать 2 различных снимка: страницы и экрана. Однако стоит иметь ввиду, что при этом объем занимаемого снимками места на диске увеличится как минимум вдвое.

Одно из решений этой проблемы – делать два типа ошибок (критичные и некритичные, Error и Warning). Некритичными можно считать ошибки браузера и в случае возникновения таких ошибок делать снимок страницы; в случае же возникновения критичной ошибки делать снимок всего экрана.

3.4 Работа с мобильными приложениями

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

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

Эмулятор или устройство?

Мы можем тестировать мобильные приложения двумя основными способами: на реальных устройствах или на эмуляторах, которые устанавливаются на компьютер. У каждого подхода есть свои достоинства и недостатки.

При тестировании на реальном устройстве:

  • вы приближаетесь к реальным условиям эксплуатации приложения, что, безусловно, хорошо (так как поведение эмулятора может существенно отличаться от поведения устройства)
  • скорость работы приложения на реальном устройстве обычно выше, чем на эмуляторе.

В случае использования эмулятора, однако, можно тестировать сценарии, которые невозможно протестировать на реальном устройстве (при условии, что эмулятор позволяет эмулировать такие действия):

  • поведение приложения при входящем телефонном звонке или СМС
  • поведение в случае разряженной батареи
  • работа в вертикальном и горизонтальном режимах

Какой же способ выбрать? Как всегда, ответ лежит где-то посредине: использовать оба подхода в зависимости от задачи. Например, большую часть тестов можно писать для выполнения на устройстве, а на эмуляторе тестировать только те сценарии, которые невозможно протестировать на телефоне.

Если речь идет о веб-приложении, заточенном под мобильные устройства, возможно их можно тестировать на обычном компьютере с аналогичным браузером (например, в устройствах Apple используется браузер Safari, который также доступен для обычных компьютеров, то же самое касается Google Chrome для Android). В этом случае нужно также учитывать, что возможности мобильной и десктопной версий браузеров отличаются.

Кроме того, следует учесть, что некоторые вещи все равно не удастся автоматизировать (например, работа с GPS или акселерометром). Также для работы автоматических тестов на реальном устройстве зачастую приходится вносить изменения в само устройство (например, взлом — jailbreak – устройств Apple), что может противоречить условиям тестирования конкретного приложения.

Использование сторонних сервисов

В случае, когда необходимо протестировать приложение на множестве различных устройств, на помощь приходят сервисы типа Device Anywhere, которые имеют в своем распоряжении большой парк устройств и предоставляют платный доступ к ним через Интернет. В некоторых случаях такие сервисы даже позволяют запускать автоматизированные тесты на своих устройствах.

Однако для автоматизированного тестирования подобные сервисы дороговаты (по крайней мере на момент написания этой книги, начало 2012 года), так как тесты необходимо запускать регулярно и в итоге автоматизация в таком виде становится невыгодной. Поэтому использование подобных сервисов лучше оставить для единичных ручных проверок.

Ещё одной сложностью тестирования мобильных приложений является тот факт, что на данный момент нет универсальных инструментов, позволяющих использовать один и тот же скрипт для тестирования одного приложения под разными платформами, поэтому если тестируемое приложение разрабатывается под несколько платформ одновременно (например, iOS и Android), то вам придется поддерживать разные версии одних и тех же тестов для каждой платформы (это не касается веб-приложений, их как раз можно разрабатывать так, чтобы запускать на всех устройствах).

Например, выбранный нами для примеров в этом разделе TestComplete поддерживает тестирование только Windows Mobile приложений, а что делать, если нам нужно протестировать iOS, Android или Blackberry приложение? Мы можем воспользоваться инструментом компании Experitest – SeeTest Studio, который позволяет записать действия на любом мобильном устройстве (как реальном, так и эмуляторе), а затем экспортировать скрипт в VBScript для TestComplete. Вот, например, как выглядит простой скрипт для TestComplete, записанный с помощью SeeTest на эмуляторе Android.

Sub Run()
  Set client = dotNET.experitestClient.Client.zctor()
  client.Connect "127.0.0.1", 8888
  client.SetProjectBaseDirectory "C:\\Users\\genka\\workspace\\project2"
  client.SetApplicationTitle "desktop"
  Report client
  client.Click "default", "element 5", 0, 1
  Report client
  client.Click "default", "element 6", 0, 1
  Report client
  client.SetApplicationTitle "5554:TestComplete"
  Report client
  client.Click "default", "element 3", 0, 1
  Report client
  client.Click "default", "element 1", 0, 1
  Report client
  client.Click "default", "element 7", 0, 1
  Report client
  client.SetApplicationTitle "desktop"
  Report client
  client.Click "default", "element 4", 0, 1
  Report client
End Sub

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

Назад Содержание Дальше