На первой онлайн-конференции ConfeT&QA 2011 Андрей Дзыня покорил сердца слушателей тем, что не побоялся показывать вживую, "в прямом эфире", как создаются тесты -- от первых шагов (запись действий пользователя в рекордере), через все этапы построения фреймворка с гибкой архитектурой, до запуска тестов в системе непрерывной интеграции. И всё это за каких-то 20 минут! Мы предлагаем вам самим посмотреть, как это происходило.

И, кстати, для построения тестов использовался замечательный инструмент Selenium, так что рекомендуем посмотреть эту запись также тем, кто начинает осваивать этот инструмент.

{tortags,41,1}

На данный момент мир веб-приложений интенсивно развивается и интерфейс становится все более динамичным. Повсеместно используется асинхронное обновление элементов и AJAX. И такие веб-приложения приходится тестировать с помощью Selenium/WebDriver. Автоматизированный тест можно разбить на атомарные фрагменты, которые многократно выполняются в цикле: “найди элемент”, “выполни действие”, “подожди результат”. При автоматизации AJAX-приложений проблемы возникают со всеми тремя видами фрагментов.

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

Ну и самое сложное — это ожидания. Что является признаком того, что некоторое действие выполнилось успешно или неуспешно? Появление или исчезноваение какого-то элемента? Добегание счётчика или прогресс-бара до 100%? А может быть не стоит вообще ждать полного завершения действия, достаточно лишь частичного результата, чтобы уже можно было продолжить выполнение теста?

На конференции Selenium Camp Алексей Баранцев рассказывал о том, как WebDriver решает все эти три задачи, особенно вторую и третью.

Хотите ещё больше узнать про Selenium? Регистрируйтесь на онлайн-тренинг Алексея "Все секреты и тайны Selenium 2.0"

{tortags,16,1}

На встрече московского клуба тестировщиков 11 августа 2011 года, организованной при поддержке компании CustIS, Игорь Варавко рассказал про автоматизацию тестирования веб-приложений, разработанных с использованием нового стандарта HTML5. В качестве инструмента автоматизации выступал WebDriver (он же Selenium 2), а тесты разрабатывались на языке Ruby.

Игорь рассказал и показал на реальных примерах, как при помощи WebDriver можно:

  • перетаскивать объекты на странице;
  • выполнять действия с canvas объектами;
  • перемещаться между окнами браузера с помощью switchTo.

Кроме того, речь шла также об архитектурных и инфраструктурных вопросах:

  • использование готового расширения для реализации шаблона проектирования Page Object;
  • построение собственного DSL языка для решения конкретных задач;
  • автоматизация запуска тестов в Jenkins CI с визуализацией результатов выполнения.

Мы представляем Вам запись этого выступления (съемка и монтаж выполнены Стасом Фоминым):

{tortags,19,1}

Автор: Алексей Баранцев

Это очень короткая и не совсем типичная для меня статья. Меня обычно беспокоит противоположный вопрос – как сделать, чтобы Selenium не тормозил. Но недавно участники тренинга “Программирование для тестировщиков” задали мне вопрос, можно ли замедлить выполнение тестов, потому что они выполняются слишком быстро и поэтому “не видно, что там происходит”. С одной стороны, приятно, что Selenium такой шустрый. Но с другой стороны, раз надо замедлить – почему бы и нет. Поскольку я в последнее время всех агитирую переходить на WebDriver, то есть Selenium 2, здесь я тоже расскажу, как это реализовать на новой версии. А заодно расскажу ещё и о том, как заставить WebDriver подсвечивать элементы перед тем, как кликнуть или ввести какие-нибудь данные, ибо реализуется это с использованием того же самого механизма.

Selenium 2 содержит специальный класс, предназначенный как раз для решения такого рода задач – EventFiringWebDriver. Он представляет собой обертку вокруг “обычного” драйвера, которая используется следующим образом:

Автор: Алексей Баранцев

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

На протяжении предыдущих двух месяцев, когда Selenium 2.0 находился на этапе бета-тестирования, и многие уже начали пробовать новую версию, мне неоднократно приходилось отвечать на вопрос, в чем же состоит кардинальное отличие 2.0 от предыдущей версии, и почему они при переходе на 2.0 никакого отличия не заметили. Мне приходилось объяснять, что для “настоящего” перехода на версию 2.0 недостаточно просто загрузить новый дистрибутив, надо ещё и переписать все свои тесты :) И это не совсем шутка, в ней есть изрядная доля правды.

Заранее предвидя, что с выходом официального релиза количество переходов на новую версию увеличится, и мне придется снова и снова объяснять, чем она отличается от предыдущей и как правильно осуществлять переход, я решил написать эту заметку, дабы впоследствии просто ссылаться на неё.

Автор: Алексей Баранцев

На конференции SeleniumCamp, состоявшейся в Киеве в феврале 2010 года, я проводил мастер-класс по оптимизации скорости выполнения тестов, разработанных с использованием инструмента Selenium. И самый первый совет, который я дал, вовсе не касается оптимизации самих тестов. Я предложил обратить внимание на то, как запускается браузер, потому что при неудачной конфигурации время, которое тратится на запуск и останов браузера может на порядок превышать “полезное” время выполнения тестов.

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

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

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

Как правильно запускать браузер?

Go to top