Записки о…

18Май/12Off

Alert’ы – это просто

Разработка автоматизированных тестов состоит из двух видов работ:

-       механическая набивка кода под рутинные задачи;

-       решение мелких, но время-затратных исключений;

Если первая часть работ делается легко и непринужденно, то вторая зачастую требует довольно таки долгих копаний как в Интернете, так и в API используемой библиотеки.

В моем случае таких исключений было несколько. Но сегодня речь пойдет об одном из них.

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

У Watir-Webdriver есть даже специальный модуль для работы с такими диалоговыми окнами. На официально сайте о нем можно почитать тут.

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

Решилось все элементарно просто:

alert

Такой способ был мною поставлен во все тестовые скрипты и еще ни разу не подводил.

Связано с категорией: Новости Нет комментариев
4Апр/12Off

Найди меня

Много воды утекло с последней статьи. Как показала практика, разработка автотестов на Ruby довольно таки многогранна и интересна. Надеюсь, что в будущем будет возможность описать все варианты и средства, которые есть (или будут).

За последние 3-4 месяца пришлось перепробовать многие библиотеки для автотестинга, но последняя задача опять подтолкнула к моей одной из любимых библиотек watir.

Задача: есть список вещей на странице. Каждая вещь это отдельный блок с именем, картинкой и ссылкой на страницу с деталями. Необходимо проверить все вещи вообще. Список вещей разбит на страницы по 6-8 штук на странице.

С прошлых статей мы можем взять простое нахождение того или иного текста на странице. Но что делать, когда у нас 6 кнопок “Далее”? Вот тут нам на помощь приходит очень интересная хитрость: выбрать все элементы (html элементы), в которых присутствует заданный текст. Выглядит это так:

find

Но это не все. Найденный div мы запоминаем в переменной и начиная от него ищем кнопку с ссылкой и нажимаем на нее:

use

Ну а далее делаем уже необходимые проверки на открывшейся странице.

Такую хитрость можно провернуть не только с div’ами, но также таблицами и другими блочными элементами. Список всех методов, которые возвращают коллекции (списки или массивы) можно легко найти в официальной документации watir. Удачи вам

Связано с категорией: Тестирование Нет комментариев
11Окт/11Off

Автотестинг “опасносте”…

«Не все так гладко в Датском королевстве»… Переход от «старой» библиотеке watir к более новой watir-webdriver заставил поволноваться и устроить блиц-гугление. При написании следующего примера скрипта пришлось столкнуться с неожиданными изменениями.

Изменение первое: проверка текста. Ранее, как я уже писал в статьях, проверка текста делалась методом contains_text:1В библиотеке watir-webdriver разработчики убрали этот метод. Теперь, для проверки, а есть ли текст на странице необходимо воспользоваться чуть более стандартными средствами Ruby:2Но и это еще не все. Если помнит дорогой читатель, проверку мы делали с помощью стандартных assert_true из стандартной библотеки test/unit  в Ruby:2С началом использования watir-webdriver уже нельзя будет пользоваться такими assert’ами. Сейчас все еще упростили:

3И напоследок. При повторном прогоне тестов они каждый раз работали по-разному: один раз нормально; второй, третий раз – падают. Поначалу казалось, что новая нотация проверок не разрешает несколько assert’ов подряд. Но все оказалось куда проще:4И проблем больше нет. Метод отвечает за ожидание полной загрузки страницы. Хоть это и небольшой хак, но, надеюсь, он никак не скажется на тестировании веб-приложений.

10Окт/11Off

А туда ли мы пришли?..

Не стоит гнаться за инновациями, все равно не успеешь. Еще полгода назад Firefox  был 3.6.сколько-то-там, а 4 версия была только в планах. На то время в нашей любимой библиотеке Watir отлично работал jSSH плагин, который позволял проводить тестирование в браузере.

С выходом новых версий Firefox тестирование в этом браузере стало немного сложным – jSSH плагин перестал работать. Но на счастье разработчики Watir учли это маленькое несчастье и сделали Watir-webdriver гем.

Установка этого гема такая же:

ins

В итоге, после всех установок немного переписав скрипт получаем такое:

header

Этот скрипт будет отлично работать со всеми версиями Firefox (даже с последней версией на текущий момент - 7).

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

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

all

Связано с категорией: Новости Нет комментариев
15Авг/11Off

Проверка статических страниц – это просто

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

Так как страниц не много, то напишем небольшой скрипт, в котором будут представлены все проверки и все необходимые настройки.

start

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

Самое главное в методе setup – создание нового объекта браузере - запуск браузера в системе, происходит автоматически. При такой записи запускается Internet Explorer, который является дефолтным браузером в системе. Ну и, конечно же, переход на сам сайт в этом браузере. Для сегодняшнего примера я поместил ссылку на сайт в сам скрипт, но ничего не мешает нам вынести ее в конфигурационный файл при большой необходимости.

Второй метод, который присутствует в коде и не является тестом, это метод teardown, который отвечает за выполнение кода ПОСЛЕ завершения всех тестов. В нем мы вынесли закрытие браузере.

Как показала практика эти два метода выполняются каждый раз перед и после вызова одного теста, т.е. если у вас 3 теста, то выполнятся они будут так:

  1. setup -> test_1 -> teardown
  2. setup -> test_2 -> teardown
  3. setup -> test_3 -> teardown

Перейдем непосредственно к самим тестам. Как я уже говорил, мы будет писать тесты в виде стандартных юнит тестов. В Ruby все юнит тесты должны начинаться на «test».

tests

Как видно с кода, у нас есть несколько тестов, которые открывают определенные страницы и проверяют там наличие текста. Переход по ссылкам делается автоматически, при чем нажатие на ссылку подсвечивается в самом браузере. За переход по ссылке отвечает метод link().click, который вызывается у браузера. Методу link передается, по какому признаку искать эту ссылку(text/class/id/name) и идентификатор (имя ссылки/текст/имя класса/имя id).

По умолчанию, watir ждет 30 секунд для полной загрузки страницы. Время ожидания можно выставить вручную, если время ответа или загрузки страницы слишком велико.

И, собственно, сама проверка. Т.к. это статические страницы и на них присутствует только текст, то и проверяем мы только текст. Делаем это стандартными средствами assert_true/assert_false и проверкой наличия текста в браузере contains_text(“some text”)

Ну и самое интересно – результаты. После успешного выполнения всех тестов мы в консоли увидим следующее:

results

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