Home

После публикации серии докладов с конференции 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, является наиболее перспективным, потому что он обеспечивает отличную питательную среду для развития как самого фреймворка, так и сопутствующих инструментов. Залог выживания – в сотрудничестве!

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

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

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

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

Оставим на время в стороне тему снятия скриншотов в Selenium, поговорим об ожидании тех или иных событий, то есть о методах, название которых содержит слово wait. В этой заметке мы сделаем расширение стандартного класса DefaultSelenium, которое облегчит работу с классическими (не-AJAX) приложениями, сократив количество рутинного кода, предназначенного для ожидания загрузки страниц.

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

В предыдущей статье я рассказал о том, как автоматизировать снятие скриншотов при неуспешном прохождении теста, используя TestNG и Selenium RC. Для этого был разработан класс ScreenshotListener, который подключался к тестам при помощи аннотации @Listeners. Но реализация этого класса предполагала, что тесты выполняются на локальной машине, и скриншот снимался на ней же. В этой статье будет предложена альтернативная реализация, позволяющая снимать скриншоты как локально, так и удаленно. Кроме того, я расскажу о том, какие могут возникать проблемы при удаленном снятии скриншотов и как с ними бороться.

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

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

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

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