Автоматические приемочные тесты с Selenium »

Главная → Статьи:

Автоматические приемочные тесты с Selenium

Как использовать инструментальные средства теста Selenium для функционального тестирования Ruby на Rails и приложения Ajax

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

Приемочные тесты web приложений обычно включают неавтоматические задачи открытия браузера и выполнение действий, описанных в test case. Вручную выполненные задачи занимает много времени и имеет большую вероятность ошибки оператора. Поэтому, автоматизация этих задач (где это только возможно), поможет исключить человеческий фактор. Именно здесь и появляется необходимость в проверочных инструментальных средствах подобных Selenium. Selenium поможет автоматизировать ваши приемочные тесты и создать лучше испытанное и, следовательно, более надежное и удобное для обслуживания программное обеспечение.

Приемочное тестирование, также известное как тестирование методом черного ящика или функциональное тестирование, это способ проверки и контроля за тем, чтобы работа приложения отвечала функциональным, нефункциональным и другим важным требованиям. Приемочные тесты дополняют блочные и комплексные тесты, которые, как правило, написаны с использованием структуры xUnit. Также, приемочные тесты можно записать, используя язык программирования. Однако, Selenium и похожие инструментальные средства типа Fitnesse, также поддерживают тесты, написанные с использованием формата документа с определенными инструментальными средствами.

Приемочные тесты отличаются от блочного и комплексного тестирования следующим:

Приложение тестируется как целостная система, сквозной логический объект, не как один класс или набор классов, как это в случае с блочным или комплексным тестированием.
Приемочные тесты выполняются, несмотря на использование пользовательского интерфейса, например, браузер, не зависимо от интерфейса web приложения.
Человеку, который составляет test cases, необязательно знать о внутренней части приложения, следовательно, об обозначении тестирования методом черного ящика. Технически неподкованные пользователи могут сами составлять приемочные тесты.

Краткая предварительная информация

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

Непрерывная интеграция (Continuous integration)
Ajax
Ruby/Ruby на Rails

Непрерывная интеграция

Основной задачей непрерывной интеграции является автоматизация процессов разработки и тестирования, с тем, чтобы они могли автоматически запускаться один или несколько раз в день вместо, например, одного раза в месяц ручным способом. Основное преимущество использования непрерывной интеграции заключается в том, что изменение кода интегрируется автоматически и на постоянной основе. Если в системе произошел сбой и ее создание прошло неудачно, инструментальные средства непрерывной интеграции, например, Apache Continuum и Luntbuild могут автоматически сообщить об этом при помощи электронной почти (см. Ресурсы ).

Ajax

Ajax поддерживает Asynchronous JavaScript и XML; это новый термин для относительно старой технологии. Основная идея Ajax заключается в том, что web приложение намного быстрее реагирует на действия пользователя, так как вместо всей страницы обновить нужно только ее часть.

Ajax представляет больше сложностей для web приложений, то есть также отражается в тестировании. Это происходит потому, что Ajax, поскольку название предполагает, использует JavaScript и асинхронные запросы HTTP для того, чтобы обновить содержание страницы. При реализации каждый браузер имеет небольшие различия. Поскольку Selenium запускается в самых популярных браузерах, он создает отличные инструментальные средства для тестирования и определения этих различий.

Ruby/Ruby на Rails

Ruby – открытый исходный интерпретируемый язык сценариев для быстрого и простого объектно-ориентированного программирования; он отличается широким выбором библиотек, простотой, прямой направленностью, расширяемостью и мобильностью. Этот язык создал и разработал Якихито "Matz" Матсумото для того, чтобы программисты могли больше времени заниматься решаемыми задачами, а не синтаксисом.

Rails - это полностью стековая, открытая исходная web структура Ruby, созданная Дэвидом Хейнемейером Хенсоном. Rails была разработана для того, чтобы сделать написанные практические приложения менее кодоинтенсивными и, например, проще чем J2EE и XML. Все уровни созданы так, чтобы они эффективно работали вместе, и вы могли использовать один язык для ввода всей информации с шаблона и контроля потока бизнес-логики. Rails использует YAML вместо конфигурационных файлов XML, отражения и расширяемости время прогона, заменяя их на аннотации. Фазы компиляции нет—вы делаете изменения и наблюдаете за работой.

Что такое Selenium?

Selenium – это инструментальное средство приемочного тестирования созданное ThoughtWorks специально для web приложений. На главной странице Selenium описываются следующие преимущества использования Selenium (в сравнении с другими инструментальными средствами тестирования):

Тесты Selenium выполняются непосредственно в браузере, как делают обычные пользователи. Они выполняются в Internet Explorer, Mozilla и Firefox на Windows, Linux и Macintosh. Ни одно другое средство тестирования не покрывает такой значительный массив платформ.

Нужно отметить, что инструментальные средства IBM's Rational Functional Tester также выполняют эти тесты, но на более сложном и протяженном уровне и, при поддержке IBM. Selenium, наоборот, сосредоточен на одной задачи-- web приложении—и может выполнятся намного быстрее.

Есть много других преимуществ использования Selenium и выполнения тестов в браузере. Это два основных:

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

Основной элемент Selenium, также известный как основа браузера (browser bot) , написан в JavaScript. Это позволяет сценариям тестов реализоваться в поддерживаемых браузерах. Основа браузера выполняет команды, полученные от сценариев теста, которые написаны или в HTML, с использованием схемы таблицы, или на поддерживаемом языке программирования.

Selenium работает с:

	Internet Explorer	Mozilla	Firefox	Safari
Windows XP	6.0	1.6+, 1.7+	0.8+, 0.9+, 1.0
Red Hat Linux		1.6+, 1.7+	0.8+, 0.9+, 1.0+
Mac OS X 10.3	не поддерживается	1.6+, 1.7+	0.8+, 0.9+, 1.0+	1.3+

Команды Selenium

Вместе с командами Selenium, составитель сценария описывает действия, которые основа браузера выполняет в браузере. Вы можете разделить эти команды на две группы-- действия(actions) и утверждения (assertions) :

Действия имитируют взаимодействие пользователя с web приложением. Щелчок по кнопке и заполнение формы – это примеры действия обычного пользователя, которые вы можете автоматизировать посредством команд Selenium.
Утверждения контролируют ожидаемые результаты команд. Обычные утверждения проверяют правильность содержимого страницы или данное расположение.

Режимы Selenium

Вы можете использовать Selenium в двух режимах: test runner и driven. Эти два режима отличаются по своей сложности и способу создания. Сценарии driven тестов составлять сложнее, поскольку они записаны на языке программирования. По сложности они будут отличаться незначительно, если использовать высокоуровневый динамический язык программирования, например Python или Ruby.

Главное различие этих режимов состоит в том, что тесты частично запускаются вне браузера, если использовать сценарии driven тестов, в которых сценарии test runner полностью запускаются в браузере.

Test cases как test runner, так и driven могут интегрироваться с инструментальными средствами непрерывной интеграции.

Режим test runner

Сценарии Selenium test runner, также известные как test cases , написаны в HTML с использованием простой схемы таблицы показанной в листинге 1 .

Листинг 1. Структура Selenium test case

Сценарии test runner используют те же самые принципы тестового набора (test suite) и test case, что и структуры xUnit. Test cases и команды выполняются в последовательности, в которой они появляются в тестовом наборе и test cases. В листинге 1 :



В первой колонке находится команда или утверждение.
Вторая колонка содержит цель команды или утверждения. Цель задается с одного из поддерживаемых устройств обнаружения элемента. Обычно используется ID или название элемента, также поддерживаются устройства обнаружения XPath и DOM.
В третий колонке находятся значения которые определяют параметры для команд и утверждений. Это может быть требуемое значение для текстового поля при использовании команды вывода на экран.

Сценарии test runner легче читать и составлять даже для людей, не имеющих специальных технических знаний. Например, в листинге 1 при открытии в браузере, они будут выглядеть как эта таблица:
Первая команда	  Цель	Значение

Вторая команда	  Цель	Значение
Далее я расскажу как создать простой но завершенный test case используя как команды так и утверждения.
Пример test case
Сценарий теста в листинге 2 выполняет следующие действия:

Он открывает страницу с измененным адресом, зайдя на /change_address_form.html.
Он вводит государственная тюрьма Betelgeuse в текстовое окно, которое содержит идентификатор поля адреса .
Он щелкает на область ввода, с именем Представить . Нужно отметить, что для нахождения кнопки Представить используется XPath. При помощи этой кнопки данные формуляра отправляются на сервер.
Он следит за тем, чтобы станица содержала текст Переадресация прошла успешно .

Листинг 2. Пример использования команд и утверждений в test case  
Для получения полного тестового покрытия обычно нужен больше чем один test case. Поэтому Selenium использует принцип тестовых наборов. Тестовые наборы используются для того, чтобы объединить test cases с похожими функциональными возможностями, так, чтобы их можно было запустить в определенной последовательности.

Тестовые наборы составлены по тому же принципу что и test cases, то есть, используя простые таблицы HTML. Тестовый набор Selenium использующийся по умолчанию называется TestSuite.html. В листинге 3 показан тестовый набор, который тестирует приложение точно так, как это делает обычный пользователь. Нужно отметить, что тестовые наборы применяют одноколонную таблицу и каждая строка указывает на файл содержащий test case.
Листинг 3. Пример тестового набора
Режим driven

Сценарии driven Selenium написаны на одном из поддерживаемых языках программирования – на данный момент существуют драйвера с Java, Ruby и Python. Эти сценарии запускаются отдельно вне браузера. Задача драйверов заключается в выполнении сценария тестов и управлении браузером посредством соединения с основой браузера, которая запускается в браузере. Для соединения между драйвером и основой браузера используется простой, специальный для Selenium проводной язык, который называется Selenese.
Сценарии driven более мощные и гибкие чем сценарии test runner, вы также можете объединять их со структурами xUnit. Недостаток сценариев driven (если сравнивать со сценариями test runner) состоит в том, что их сложнее использовать и составлять. Причиной тому являются следующие задачи, которые должен выполнять драйвер:

Запуск сервера.
Применение приложения под тестом (AUT).
Использование сценария теста.
Запуск браузера.
Передача команд основе браузера.
Проверка результатов команд выполненных основой браузера.

Кроме того сценарии driven больше зависят от условий прогона приложения. Например, драйвер Java использует вложенный экземпляр Jetty или Tomcat для размещения приложения под тестом. На данный момент делаются попытки объединить Selenium с Ruby на Rails, однако на момент создания его еще не выпустили.
Листинг 4 это часть сценария driven теста, который использует драйвер Ruby. Обратите внимание на то, что я пропустил этап реализации сервера и браузера, а также на то, что код сценария теста почти такой же простой, как и сценарий test runner.
Листинг 4. Пример использования драйвера Ruby   
. . puts selenium.open('/logout.html') puts selenium.verify_location('/index.html') . .
Реальные требования
В следующих двух основных разделах ( Реальный требования и Реальные требования ), я расскажу, как использовать Selenium в реальных сценариях и создавать Selenium test cases для простого приложения просмотра биржевых цен, используя Ruby на Rails и немного технологий Ajax. Несмотря на то, что приложение написано с использованием Ruby на Rails, вы можете применять этот пример к любому web приложению, поскольку сценарии тестов написаны в HTML для режима test runner. Пример приложения вероятнее всего будет работать как со старыми, так и с более новыми версиями, однако он тестировался с Ruby 1.8.3 и Ruby на Rails 0.14.2.
Ruby, как правило распространяется при наличии Linux. Запустите ruby -v с приглашения на ввод команды для того, чтобы проверить какая у вас версия. Вы можете найти распространение Ruby для всех платформ на http://www.ruby-lang.org/ .
После этого вы должны установить Ruby на Rails через систему компоновки RubyGems. Для того чтобы это сделать, просто выполните gem install rails --include-dependencies .На некоторых платформах вам придется выполнить несколько дополнительных действий, так что проверьте Ruby на Rails web-сайт где вы можете получить больше информации.
Доступная версия Selenium, в момент создания, это 0.6. Я уже интегрировал ее в пример приложения (см. Загрузить ) загрузив пакет Selenium Core с http://selenium.thoughtworks.com/ и скопировав папку с именем selenium в папку, которая содержит неизменное содержание. В приложениях Ruby на Rails, название этой общедоступной папки. В web приложении J2EE, вы размещаете ее в корневой части web приложения или архивного файла WAR.
Последним вашим действием будет загрузка примера приложения; получите пакет с раздела Загрузить . Извлеките приложение и откройте приглашение на ввод команды. После этого поменяйте каталог, где вы доставали приложение. Чтобы начать приложение, запустите ruby сценарий/сервер . Вы должны увидеть, что Rails запустился без ошибок, как это показано на рисунке 1 .
Рисунок 1. Запуск Ruby на Rails с приглашения на ввод команд


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

Регистрация
Просмотр биржевых данных
Детальный просмотр биржевых данных
Выход из системы

Код обеспечивающий выполнение этих сценариев использования уже написан; вы можете найти его в каталоге приложения и в test cases в общедоступной/selenium/тестовой папке.
Сценарий использования регистрации 
Большинство людей знают, как работает страница регистрации – вы вводите имя пользователя, пароль и передаете данные на сервер. Если данные правильные вас регистрируют, и вы получаете доступ к защищенным данным. В примере приложения, этот test case включает следующие действия и утверждения пользователя, которые вы должны осуществить в Selenium test case:
Щелкните на ссылку регистрации.
Убедитесь, что система просит пользователя зарегистрироваться.
Введите имя пользователя.
Введите пароль.
Нажмите кнопку регистрации.
Убедитесь, что регистрация прошла успешно.
На рисунке 2 показан Selenium test case отвечающий этим требованиям. Обратите внимание на то, что я использовал снимок экрана после запуска теста. Зеленые строчки обозначают отображения, которые были успешно проверены.
Рисунок 2. Регистрация и просмотр test case биржевых бумаг


Сценарий использования просмотра биржевых бумаг
Страница просмотра биржевых бумаг отображает список компаний. В этом случаи test case такой простой, что он был включен в конце предыдущего test case. Это подтверждает, что данное расположение имеет место/главный /перечень биржевых бумаг и, что страница содержит текст. Щелкните на название компании, чтобы получить более детальную информацию .
Сценарий использования просмотра детальной информации биржевых бумаг
Сценарий использования просмотра детальной информации биржевых бумаг запускается на странице просмотра биржевых бумаг. Щелчок пользователя на название компании запускает запрос Ajax на сервер. Ответ сервера содержит детальную информацию о компании. Он будет помещаться на данную страницу без полного обновления страницы. Test case для этого сценария использования выполняет следующие действия пользователя:

Щелкните на название компании Acme Oil .
Проверьте чтобы подробная информация о компании отобразилась на странице.
Щелкните на название компании Acme Automotive .
Проверьте чтобы подробная информация о компании отобразилась на странице.

Запрос происходит асинхронно, поскольку используется Ajax. Это влечет за собой определенные сложности, которых нет у обычных web приложений, где все, как правило, происходит одновременно. Вы можете проверить функциональные возможности Ajax точно так же как и другие возможности. Единственное исключение состоит в том, что вы должны сообщить Selenium о том, что он должен сделать паузу и подождать завершения команды Ajax. Для этого вы можете использовать команду приостановки (pause command) и дождаться завершения команды Ajax. Недавно в сетевом журнале Джозеф Мор вместо “приостановки” предложил использовать команды waitForValue и waitForCondition (см. Ресурсы ).
На рисунке 3 показаны требования, реализованные в сценарии использования Selenium.
Рисунок 3. Test case просмотра биржевых бумаг



Обратите внимание на команды приостановки : Они предусматривают возможность для асинхронного запроса закончить команду и обновить содержание страницы. Без 500 миллисекундных (мс) приостановок, тест не получится (это показано на рисунке 4 ).
Рисунок 4. Неудачный test case просмотра биржевых бумаг


Команда приостановки также тестирует нефункциональные требования для функциональных возможностей Ajax. 500мс является подходящей величиной для команды приостановки, поскольку запросы Ajax должны быстро выполняться и завершаться. Вы можете попробовать убрать команду приостановки и посмотреть, что произойдет. Если ваш тест прошел неудачно, попробуйте увеличить величину до 1000мс.
Сценарий использования выхода из системы 
Сценарий использования выхода из системы выполняется очень просто и состоит из следующих двух действий:

Щелкните на ссылку выхода из системы.
Проверьте, что выход из системы был выполнен удачно.

На рисунке 5 показан заключительный test case.
Рисунок 5. Test case выхода из системы


Все тести включены в тестовый набор по умолчанию, который показан слева от рисунка 6 .
Рисунок 6. Тестовый набор для примера приложения


Выполнение тестового набора
Последнее что вы должны сделать, это выполнить весь тестовый набор в Mozilla Firefox и Microsoft Internet Explorer. Для этого откройте http://localhost:3000/selenium/TestRunner.html в браузере и щелкните на все кнопки изображенные на рисунке 6 . Tests cases и утверждения, которые прошли неудачно, будут обозначены красным цветом, однако в вашем случае они полностью должны быть выполнены удачно на обоих браузерах (как показано на рисунке 6 ). Помните о том, что я использовал Mozilla Firefox 1.0.7 и Internet Explorer 6.0.
Вы также можете пройти или прогнать весь тестовый набор, это означает, что Selenium выполнит тестовый набор достаточно медленно, чтобы вы могли увидеть каждый этап тестового набора так, как он осуществляется в браузере.
Краткие выводы
Selenium – это полезное и важное дополнение к инструментарию специалистов по программному обеспечению, разработчиков и тестировщиков. Вместе со средствами непрерывной интеграции он дает возможность группе специалистов автоматизировать приемочные тесты и создавать более качественное программное обеспечение, поскольку теперь им будет проще и быстрее находить ошибки. Еще одно преимущество Selenium заключается в том, что с его помощью можно сэкономить время и сделать работу разработчиков и тестировщиков более эффективной. Теперь они смогут сосредоточиться на действительно важных задачах и не тратить время на выполнение вручную действий, которые должны и могут быть автоматизированы.
Автор: Крестьян Хелстен.