Home

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

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

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

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

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

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

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

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

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

• отдельный браузер для каждого теста,
• общий браузер для группы тестов,
• общий браузер для всех тестов.

Оригинальная публикация
Автор: Bj Rollison
Перевод: Татьяна Зинченко

В комментариях к одной из заметок в моем блоге Шрини Калкарни (Shrini Kulkarni) предложил: “Наверное, тебе стоит написать о тех багах, которые юнит-тесты (или тестирование разработчиками на любом уровне) не могут поймать. Это будет достойный ответ всем, кто безгранично верит в автоматизацию тестирования на юнит и API уровнях”

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

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

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

В последнее время мне нередко приходится слышать от тестировщиков-автоматизаторов ожидания относительно того, что с выходом Selenium 2.0 выполнение тестов заметно ускорится. Мне тоже хотелось бы на это надеяться. Пока эксперименты показывают обратное -- некоторые операции действительно работают быстрее, но зато другие стали медленнее, так что в среднем ускорения не заметно, а иногда даже наоборот, тесты после перехода на новую версию начинают выполняться дольше. Конечно, может быть чудо случится и Selenium 2.0 действительно будет фантастически быстр, но зачем ждать? Если ваши тесты выполняются слишком долго, можно уже сейчас попытаться предпринять действия по их оптимизации.

Мне приходится время от времени иметь дело с весьма массивными тестовыми наборами, время выполнения которых исчисляется многими часами, а иногда даже сутками. Поэтому я начал постепенно коллекционировать приёмы ускорения тестов. Про некоторые из них я собираюсь рассказать в третьем модуле онлайн-курса "Разработка тестов: Selenium & Java". А ещё я говорил об этом на недавно прошедшей в Киеве конференции SeleniumCamp, и предлагаю посмотреть видеозапись этого выступления, состоящую из двух частей -- теоретической и демонстрационной.

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

В конце 2010 года компания Hewlett-Packard объявила о выпуске пакета для управления жизненным циклом приложений HP Application Lifecycle Management 11.0, в который, среди прочего, вошла обновлённая версия HP Quality Center 11.0. В то время, как большинство производителей инструментов ориентируются главным образом либо на тестировщиков-автоматизаторов, либо на поддержку процессов, компания Hewlett-Packard наряду с этим не забывает также и о тех, кто занимается ручным выполнением тестов. Для них в новой версии появился продукт HP Sprinter, название которого говорит само за себя – он должен позволить выполнять ручные тесты со спринтерской скоростью.

HP Sprinter это не отдельное приложение, он представляет собой новый вариант клиента для HP Quality Center. Соотвественно, подготовка тестов осуществляется примерно так же, как и раньше, изменяется только способ их выполения.  Исключение составляют “неформализованные” тесты, которые сначала выполняются, а потом уже могут быть импортированы в Quality Center. Разумеется, традиционный веб-клиент тоже никуда не исчез, однако Sprinter предоставляет по сравнению с ним множество новых возможностей, повышающих скорость и удобство работы тестировщика.

После публикации серии докладов с конференции SQA Days 8 мы обратим взгляд в Сибирь, где неделю тому назад, 5 февраля 2011 года состоялась первая тематическая встреча сообщества тестировщиков Сибири. На ней прозвучало три интереснейших доклада, так что это получилась не просто встреча, а мини-конференция, первая репетиция перед приближающейся большой конференцией CodeFest, где будет отдельная секция, посвященная тестированию программного обеспечения.

Сегодня мы публикуем первый из этих докладов, выступление Сергея Высоцкого "Автоматизированное тестирование -- сказки и реальность". Действительно, автоматизация окружена огромным количеством мифов, непосвящённым она кажется панацеей от всех проблем ("вкалывают роботы, счастлив человек" :)), но при ближайшем рассмотрении оказывается, что всё не так радужно.

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

На консультации к тренингу "Программирование для тестировщиков" я пообещал записать небольшую демонстрацию того, как можно смотреть в отладчике Eclipse свойства объектов типа WebElement (в виде таких объектов представляются элементы веб-страницы в Selenium 2.0), а когда записал, решил выложить в открытый доступ, вдруг ещё кому-нибудь окажется полезной эта информация.

Для тех, кто не в курсе небольшое пояснение. Selenium 2.0 использует новый механизм доступа к веб-страницам, с использованием "нативных" интерфейсов. Поэтому объект типа WebElement сам не содержит никакой информации, только некий уникальный идентификатор. А при необходимости вся нужная информация извлекается непосредственно из памяти браузера. Это доставляет определённые неудобства при отладке тестов -- трудно понять, что за веб-элемент перед тобой, если видишь только какой-то идентификатор, состоящий из длиннющей последовательности букв и цифр. К счастью, в среде разработки Eclipse имеется специальный механизм для визуализации таких элементов, именно про него я и рассказал в этом небольшом видеоролике.

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

Недавно ученики моего курса Программирование для тестировщиков пришли ко мне с жалобой – тесты, которые у них успешно выполнялись в браузерах FireFox и Internetr Explorer по непонятной причине падали в браузере Google Chrome. Когда я посмотрел, что происходит, мне показалось, что я вернулся лет на пять в прошлое – налицо были все симптомы проявления same origin policy, с которым давно уже все научились бороться при использовании браузеров Internet Explorer и FireFox.

Страшные слова same origin policy знакомы практически каждому тестировщику, который начал использовать Selenium достаточно давно, когда ещё не было режимов запуска *iehta и *chrome. Производители браузеров, заботясь о защищенности пользователей, изобретают различные средства борьбы с уязвимостями в веб-приложениях. И как одно из средств защиты от XSS-уязвимостей, был придуман запрет в JavaScript-коде получать данные с любых сайтов, за исключением того, с которого был первоначально загружен этот самый JavaScript-код. Вот он-то и называется same origin policy.

Мы не будем здесь обсуждать, насколько этот запрет эффективен как средство защиты. Важно то, что его наличие вызывает проблемы при выполнении тестов при помощи Selenium. Дело в том, что ядро Selenium реализовано на языке JavaScript. При запуске теста ядро загружается в браузер, и всё работает хорошо до тех пор, пока в процессе выполнения теста не возникает необходимость перейти на другой сайт – браузер немедленно замечает это "опасное" действие и блокирует его.

Чтобы обойти это ограничение, были реализованы специальные режимы запуска браузеров с отключеной защитой, это режим *chrome для браузера FireFox и режим *iehta для браузера Internet Explorer.

А вот для браузера Google Chrome существует только один единственный режим запуска *googlechrome, и в этом режиме он запускается с включенными средствами защиты.

Но всё-таки способ отключения защиты существует, решение удалось найти, и я хочу поделиться с вами этой информацией. Ключ к решению заключается в использовании опции --disable-web-security. Вопрос лишь в том, как заставить Selenium запустить браузер с этой опцией.

Автор: Виталий Помазенков

В последнее время развелось очень много различных AJAX-приложений. По сути автоматизация тестирования такого приложения не отличается от автоматизации тестирования обычного WEB-приложения, но есть несколько тонкостей. Одна из тонкостей — это как раз ожидание завершения всех AJAX-запросов. Например, если отметка некого checkbox'а на странице вызывает обновление какого-нибудь select'a по AJAX-запросу, то тест, который сразу после отметки выбирает конкретный option, свалится, т.к. этого option'a там не будет. А всё потому, что сам тест выполняется намного быстрее чем AJAX-запрос на обновление списка.

В данном случае у автоматизатора есть несколько выходов.

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

Эта статья завершает серию, посвящённую снятию скриншотов при выполнении автотестов, разработанных с использованием Selenium и TestNG.

Предыдущие статьи:
Selenium+TestNG: Автоматическое снятие скриншотов при неуспешном прохождении теста
Selenium: Снятие скриншотов на удаленной машине

Здесь речь пойдёт о снятии скриншотов страницы целиком -- не только видимой её части, но и тех частей, которые можно увидеть лишь проскроллировав окно браузера. Я расскажу про два способа снятия таких "пейджшотов":

• средствами только Selenium;
• с использованием AutoIt и какой-нибудь внешней утилиты снятия скриншотов, умеющей автоматически скроллировать окна.

Первый способ работает как при локальном, так и при удалённом запуске тестов, но поддерживаются только браузеры Internet Explorer и FireFox. Второй способ пригоден только при локальном запуске тестов, а поддержка браузеров определяется возможностями используемой внешней утилиты-скриншотера.

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

Всё нижеописанное в виде исходного кода на языке Java вы сможете найти в приложенном файле, ссылка на который находится в конце статьи.

2 октября на конференции DevPoint (Новосибирск) Алексей Баранцев выступил с докладом «Selenium 2.0: будущее тестирования веб-приложений».

В конце 2010 года ожидается выход новой версии популярного инструмента автоматизации тестирования веб-приложений Selenium 2.0. Новая версия обещает улученную поддержку современных AJAX-приложений, увеличение скорости выполнения тестов, преодоление имеющихся в Selenium 1.0 ограничений, таких как невозможность работы с “нативными” диалогами.
Однако я собираюсь рассказать не только и не столько про эту новую версию (хотя без этого, конечно, не обойтись), но и вообще про всю ту инфраструктуру, которая сложилась вокруг этого замечательного фреймворка и продложает активно развиваться.
Говоря про “дваноль” я имею в виду совершенно уникальный для инструментов тестирования феномен – перерастание отдельного фреймворка в целое созвездие взаимно поддерживающих друг друга инструментов, появление множества маленьких и средних компаний, предоставляющих платные и бесплатные сервисы с использованием этих инструментов. Модульная расширяемая архитектура Selenium позволяет говорить о нём не как о фреймворке, а как о модульной платформе, на базе которой или из частей которой строятся другие инструменты.
Да, а что там про будущее тестирования веб-приложений? Мне кажется, что именно тот путь развития, по которому движется Selenium, является наиболее перспективным, потому что он обеспечивает отличную питательную среду для развития как самого фреймворка, так и сопутствующих инструментов. Залог выживания – в сотрудничестве!

Запись выступления