Блог

Работа с модальными окнами

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

Так вот, основная трудность заключается в том, 

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

Работа с полем загрузки файлов

Одним из каверзных стандартных элементов управления на веб-страницах с точки зрения работы Selenium-a является поле загрузки файла.

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

Одной из особенностей Selenium, которая отличает его от "традиционных" средств автоматизации функционального тестирования на уровне UI, является то, что Selenium не имеет своей выделенной интегрированной среды разработки. Отчасти это обусловлено тем, что тот же Selenium-RC представляет собой сервер, который выполняет команды + клиентская библиотека, портированная на некоторый язык программирования. Соответственно, тесты уже пишутся в среде, которая определяется языком программирования. Такой разброс в используемых средств влечет за собой отсутствие встроенных в IDE различных генераторов, визардов, которые могли бы упростить написание тестов. Тем не менее, есть ряд задач, которые решать приходится регулярно. Тот же подбор локатора - довольно распространенная задача. Фактически одна из ключевых. Поскольку нет выделенного IDE, то в подобных задачах нам на помощь приходят другие инструменты. Итак, какие же инструменты нам могут упростить жизнь

При работе с Селениумом практически первое, с чем придется столкнуться - это локаторы. Что это такое? Локатор - это строка, уникально идентифицирующая UI-элемент. Когда вы делаете клик мышкой, ввод текста и прочие действия, вы эти действия выполняете над вполне конкретным объектом. Селениум поступает так же. Но поскольку он не умеет читать ваши мысли, то ему надо четко указать объект, для которого надо применить то или иное действие.

Cucumber - это просто тестовый движок на Ruby, который позволяет создавать тесты, используя "human language" инструкции. Но это один из аспектов. Но есть и другой аспект - это такая же вспомогательная утилита на Ruby, как и многие другие. И как многие другие Ruby-компоненты, Cucumber вписывается в определенную инфраструктуру. В частности, можно определить некоторые специфические задачи, которые он может выполнять. Помимо этого, иногда полезно получить информацию о том, собирается ли набор тестов без ошибок, какие тесты относятся к той или иной группе, какие шаги еще не реализованы и т.п. Наличие подобных "фишек" помогает во многом.

Зачастую, когда объем автотестов становится весьма большим, достаточно тяжело уделять внимание запускам тестов. Тесты выполняются долго, часть проблем выявляется только после серии прогонов тестов и т.д. Более того, весьма полезно, чтобы результаты приходили регулярно и изменения, внесенные в код подхватывались по мере их внесения. Да и по сути, запуск тестов - это очередная рутина, которую хорошо бы делать регулярно, но в итоге всё делается, как получится. Соответственно, надо бы это как-то автоматизировать. Тут как раз подходит практика "Чёртового колеса"

Зачастую решение по автоматизированному тестированию становится достаточно сложным, что для написания тестов и всего вспомогательного кода требуются навыки программирования, причем иногда даже не начального уровня, а немного повыше. В то же время, имеет место тенденция к упрощению работы с автотестами. Это достигается путем добавления различных визардов, созданию определенных подходов и движков, реализующих данный подход. В частности популярен т.н. keyword-driven подход, когда тесты представляют собой последовательность ключевых слов, структурированную в таблицах. Но есть еще более заковыристый подход, при котором тесты представляются в виде обычных инструкций, написанных в виде обычного текста, для которых есть определенная реализация на уровне программного кода. Для Ruby есть такой движок, именуемый Cucumber.

Безусловно, XPath-локатор является одним из наиболее универсальных и наиболее точных локаторов. Но к этой универсальности добавляется один из главнейших недостатков данного типа локаторов - низкая скорость обнаружения данного элемента. Это наиболее хорошо проявляется под IE, в то время как тот же Firefox работает нормально. Это связано с внутренними особенностями браузеров, в частности в способе аллоцирования элементов страницы. Но суть не в этом. Суть в том, что Селениум-тесты, которые интенсивно используют XPath работают крайне медленно под IE. И это вызывает ряд проблем как со скоростью выполнения тестов, так и с качеством этих тестов, особенно при работе с динамическим контентом. Как альтернатива XPath могут рассматриваться CSS локаторы. Что с ними можно делать?

При любом виде автоматизированного тестирования неотъемлемой частью является информативный вывод результатов, так как мало просто осуществить прогон, нужно еще и суметь интерпретировать результаты. Рассмотрим решение данной задачи на примере SilkTest.

Кнопка (PushButton), казалось бы, один из самых простых элементов управления, тоже может доставить хлопоты. В этом посте мы рассмотрим случаи, когда не срабатывает метод Click() и способы решения этой проблемы.

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

• на странице есть несколько полей с одинаковым атрибутом Name, но у разных форм и нужно работать с конкретным полем конкретной формы.
• На странице множество объектов сходной структуры и их надо обработать одинаково (например, очистить все текстовые поля)
• Нужно обработать одинаковым образом все объекты, которые характеризуются определенным текстов некоторых дочерних объектов (например, мы знаем заголовки таблицы, а нужно сделать клик на ссылке, которая находится на том же уровне)

Каждый отдельно взятый случай решает данные проблемы своими путями, но более-менее универсальным решением является использование XPath.

В раздел Материалы добавлен Учебник по Borland SilkTest.

Приятного изучения!

Самый простой и очевидный способ закрытия окна в SilkTest – это использование метода Close(). Однако не всегда этот метод сработает. Попробуйте, например, открыть окно Блокнота, написать в нем какой-то текст, а затем выполнить следующий код:
[ ] Notepad.SetActive ()
[ ] Notepad.Close ()

Блокнот выдаст сообщение о том, что в документ были внесены изменения и будет ждать действий пользователя, а SilkTest выдаст в логе сообщение об ошибке

*** Error: Window cannot be closed

Безусловно, подобные ситуации обычно должны обрабатываться, однако что если нам надо закрыть окно в любом случае? В этом случае нам на помощь приходит метод Kill(), который попросту уничтожит окно. По какой-то причине этот метод не описан нигде в справочной системе SilkTest'a, однако его можно найти в файле winclass.inc.

[ ] Notepad.SetActive ()
[ ] Notepad.Kill ()

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

Отдельно хочется выразить благодарность автору проекта OpenQuality.ru за то, что добровольно согласился осуществить вычитку материала и исправление различных ошибок.

Приближается новый 2009-й год и команда Automated Testing Service Group поздравляет всех с Новым Годом. Пусть новый год принесет больше возможностей и больше достижений. Успехов всем и процветания!

Проект it4business - один из лучших порталов в рунете, посвященный тестированию, управлению и качеству.

Если вы еще не знакомы с ним — сейчас самое время!

На сайте можно найти множество статей от ведущих специалистов, подписаться на еженедельную рассылку новостей.

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

На форуме сайта можно найти ответы на многие вопросы, связанные с тематикой сайта, задать свой вопрос или делиться своим опытом с другими.

Иногда записанный TestComplete'ом код не воспроивзодится так, как хотелось бы. Один из "проблемных" методов - метод Drag(), который позволяет перетащить объект на другое место. В этом случае можно воспользоваться методами MouseDown() и MouseUp() объекта Sys.Desktop для создания собственной функции перетаскивания.

function DragDrop(obj, deltaX, deltaY)
{
  var iX = obj.ScreenLeft + obj.Width/2;
  var iY = obj.ScreenTop + obj.Height/2;
  Log.Picture(obj.Picture(), "Object to be moved");
  obj = Sys.Desktop.ObjectFromPoint(iX + deltaX, iY + deltaY);
  Sys.Desktop.MouseDown(VK_LBUTTON, iX, iY);
  obj.HoverMouse(obj.Width/2, obj.Height/2);
  Sys.Desktop.MouseUp(VK_LBUTTON, iX + deltaX, iY + deltaY); 
}

Эта функция нажимает левую кнопку мыши в центре объекта, который надо перетащить, а затем отпускает кнопку в новом месте. Пример использования функции для перемещения иконок на панели инструментов Быстрый запуск:

function Test3()
{
  var w1 = Sys.Process("Explorer").Window("Shell_TrayWnd").Window("ToolbarWindow32", "Quick Launch");
  DragDrop(w1, -30, -20);
}

Часто при работе автотестов возникают ситуации, когда приложение может вести себя по-разному и в зависимости от полученной реакции приложения нужно выполнить определенные действия. Наиболее четко это выражено в тестировании GUI, когда после выполнения некоторых операций мы ожидаем один из возможных вариантов реакции системы. Самый простой пример: у нас есть окно Notepad и нам надо реализовать функционал по его закрытию. То есть, нужно нажать на крестик в правом верхнем углу. Но если уже был введен некоторый текст, то вначале появится сообщение о подтверждении сохранения изменений. В этом случае нам дополнительно надо еще обработать диалог закрытия окна. Если подобную задачу реализовывать в виде некоторой вспомогательной функции, то обе ситуации надо обрабатывать.

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

Веб-сервисы - достаточно распространенный вид компонент распределенных систем. Фактически это один из интерфейсов удаленного вызова процедур. То есть, из некоторой программы мы можем отправить запрос на выполнение некоторой операции на стороне сервера и получить результат выполнения операции, при этом графический интерфейс не задействован. Подобные компоненты позволяют реализовать интеграцию между различными системами, которые изначально между собой не связаны. Отчасти это делает веб-сервисы достаточно популярными, как результат - они используются в достаточно большом количестве приложений, а это в свою очередь влечет необходимость их тестировать, в том числе и автоматически. Для этой задачи есть и специальные средства, наподобие soapUI, но помимо этого возможность тестирования веб-сервисов имеется и в более полновесных средствах, в т.ч. и в TestComplete. В TestComplete, начиная с 6-й версии как раз была добавлена возможность тестирования веб-сервисов. Рассмотрим, как это реализуется и каким образом можно проверить веб-сервисы.

Автоматизированное тестирование на уровне GUI содержит в себе много сюрпризов, связанных с работой с оконными объектами. Причем сюрприз заключается в том, что наиболее изящное решение проблемы с поддержкой описаний оконных объектов в актуальном состоянии для каждого отдельно взятого средства может быть свое. Но это наиболее удачное решение. Тем не менее, есть ряд механизмов, имеющих аналоги в различных средствах. Одним из примеров является Mapping оконных деклараций, позволяющий некоторым оконным объектам ставить в соответствие некоторый псевдоним. Подобное решение в TestComplete обладает одним ключевым недостатком: при изменении иерархии оконного объекта приходится переделывать маппинг всех дочерних объектов. Альтернативой этому стало введение с 6-й версии TestComplete такой функциональности как Alias, которая позволяла регулировать иерархию псевдонимов. Но у такого решения есть другой недостаток: низкая скорость. Соответственно, нужны механизмы, позволяющие оперативно реагировать на изменение GUI, при этом корректировки желательно минимизировать. Давайте рассмотрим конкретный пример.

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

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