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

В принципе, локаторы можно расположить по приоритетам использования в следующем порядке:

• link= (только для ссылок, естественно, причем при условии, что данная ссылка одна, а не серия)
• id=
• name=
• dom=
• css=
• xpath=

Соответственно, когда мы подбираем локатор для некоторого элемента, мы смотрим на его HTML-код и ищем реквизиты:

• Текст элемента (для статических ссылок это чуть ли не ключевой элемент, для других элементов это как минимум основа для XPath, но вначале лучше смотреть на что-то другое)
• Атрибут id
• Атрибут name
• Соседние или вышестоящие по иерархии элементы, у которых более-менее четко находится хотя бы один из вышепереисленных атрибутов

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

К этим частным случаям можно отнести следующие:

1. Отдельная ссылка либо с фиксированным текстом, либо с некоторой фиксированной частью
2. Стандартный элемент управления формы
3. Некоторый элемент в таблице, содержащей множество таких же однородных элементов

Теперь можно рассмотреть эти подмножества элементов поотдельности.

Отдельная ссылка либо с фиксированным текстом, либо с некоторой фиксированной частью

Отдельная ссылка с фиксированным текстом

Итак, у нас есть ссылка на странице и мы четко знаем, что она такая одна. Для примера, допустим, у нас есть ссылка

<a href="www.somedomain.com">Sample Link</a> 

Теперь подберем локатор, наиболее подходящий для нее, исходя из приоритетов выбора локаторов выше. Что у нас там? Локатор вида link=.

1. Применяется для ссылок? Да
2. Использует фиксированный текст ссылки? Да
3. Идентифицирует ли он этот объект уникально? Да (по условию, такая ссылка одна на странице).

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

Во-первых, CSS-локаторы тоже позволяют привязаться к иерархии объекта. Например, такой XPath-локатор:

xpath=//div//span/a

может быть описан через CSS вот так:

css=div * span > a

Отсюда четко прослеживается аналогия элементов XPath и CSS, а именно:

1. Знак "/", означающий следующий уровень иерархии объекта, соответствует оператору ">" в CSS.
2. Знак "//", означающий любой элемент, находящийся по иерархии ниже текущего, соответствует оператору "*" в CSS

Во-вторых, как и в XPath, CSS-локаторы могут привязываться к значениям атрибутов. Например, такой XPath-локатор:

xpath=//div[@id="some_id"]

может быть описан через CSS вот так:

css=div[id=some_id]

Также есть возможность проверки на частичное совпадение значения атрибута. Но здесь CSS немного ограничен. Есть возможность проверки, что значение атрибута содержит несколько слов, разделенных пробелами, но одно из них четко соответствует значению. То есть, то, что в XPath может быть выражено вот так:

xpath=//div[contains(@title="title")]

через CSS выражается вот так:

css=div[@title~=title]

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

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

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

1. Во-первых, данный способ задания местоположения объекта оперирует с фактическими HTML-тегами, что дает возможность формировать локаторы исходя из непосредственно HTML-кода страницы, который можно просмотреть.
2. Во-вторых, есть возможность задать некоторую иерархию объектов, при этом пропустить варьируемые элементы (удобно, когда надо вычислить элемент внутри таблицы, не привязываясь к конкретным ячейкам).
3. В-третьих, элемент можно задать используя как теги, так и определенные значения атрибутов, причем можно проверить на частичное соответствие (удобно, когда элемент уникально идентифицируется обработчиком некоторого события). 
4. В-четвертых, в Selenium есть отдельный метод, который позволит нам узнать количество элементов, удовлетворяющих заданному XPath, а такде возможность использовать индексы, что позволяет выделить и перебирать целую коллекцию элементов.

А теперь перейдем к практической составляющей. Допустим, у нас есть набор различных графиков в виде bar-chart или pie-chart, причем при клике на каждый элемент происходит переход на некоторую страницу. Реализация в HTML подобного имеет вид:

<map>
      <area href="ref1">
      <area href="ref2">
      <area href="ref3">
      ...
      <area href="ref1">
      <img src="some_img.gif"> 
</map>

вот таких map-блоков произвольное количество. В каждом из этих блоков произвольное количество элементов area. Но везде есть ссылки и на эти area-объекты мы можем сделать клик. Итак, как можно организовать обработку всех активных областей всех диаграмм. Вначале, мы узнаем, сколько же всего этих диаграмм присутствует. Предположим, что у нас уже есть проинициализированный объект Selenium-a и мы уже на нужной странице. Соответственно, реализация имеет вид (далее все примеры приводятся с использованием синтаксиса Java, но по аналогии переносится на остальные языки, на которых реализован Selenium-клиент):

int chartsCount = selenium.getXPathCount( "//map" ).intValue();

Часть 2

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

Как результат, нужно обеспечить темп работы теста таким образом, чтобы он соответствовал темпу работы тестируемого приложения. Как это сделать?

Наиболее простым вариантом является установка задержек. Практически во всех средствах для автоматизации функционального тестирования есть инструкции, которые просто делают паузу в выполнении. Так, во многих решениях присутствуют функции вида: sleep( nSec ) или wait( nSec ). В TestComplete это делается вызовом BuiltIn.Delay(), в Java для этого есть вызов Process.sleep( ). Все эти решения имеют схожую структуру - единственный параметр, указывающий время, на которое установить паузу.

Преимущества данного решения:

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

Тем не менее, у данного решения есть и недостатки:

1. Нерациональное использование времени выполнения - некоторые операции, особенно, обработка различных клиент-серверных запросов, могут занимать различное время, даже для одной и той же команды. Соответственно, паузу целесообразно делать на интервал времени, покрывающий максимальное время ожидания. В результате, если действие выполнилось раньше, то пауза все равно действует фиксированное время, отчего мы теряем до нескольких минут на одном подобном ожидании. Если подобных действий будет много, то суммарная потеря времени выполнения будет составлять вплоть до нескольких часов.
2. На разных средах тестируемое приложение может работать с разной скоростью, соответственно, нужно во всех вхождениях инструкции для паузы перестраивать время ожидания.
3. Подобные паузы не отражают причин, по которым они проставлены, из-за чего подобный код весьма затруднительно читать. Также в тестовом коде может быть слишком много подобных инструкций, отчего код разрастается весьма ощутимо без видимых на то причин
4. Подобные паузы не гарантируют, что тестируемое приложение достигло нужного состояния

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

• Все тесты (или большинство) начинаются с некоторого фиксированного состояния - это соответствует пользовательскому сценарию по работе с некоторой системой. Зачастую, есть общий набор действий, от которого уже потом отталкивается тест. С точки зрения автоматической реализации, будет написан некоторый метод или другой вид модуля, который приводит систему в исходное состояние и потом возвращает в него (если надо). Во многих решениях автоматизации подобная реализация предусмотрена специальными блоками (setUp, tearDown в JUnit-e, appstate в СилкТесте и т.п.).
• Тесты не зависят друг от друга - это очень болезненный момент. Нехорошо, когда сбой в одном из тестов повлечет за собой ошибки в других тестах. В этом случае непонятна сегментация тестов. Фактически, получаем один длинный workflow-тест, который разбит просто на подпункты и сбой в одном месте влечет за собой "эффект домино". Чтобы избежать подобного эффекта, лучше сразу предусмотреть возможность выполнения теста как в пакете, так и отдельно. Подобное выравнивание достигается фиксацией начального состояния (см. предыдущий пункт), а также определением дополнительных условий, необходимых именно для данного теста. Зачастую, эта проблема соприкасается с проблемой организации внешних данных для тестов.
• Одна функция - один тест - идея заключается в том, чтобы тесты делать не огромными, которые бы охватывали множество разных аспектов или какой-то длинный workflow, а более-менее сосредотачивались на некоторой одной функции. То есть, тест строится на том, что мы перешли в некоторое состояние, из которого доступна тестируемая функция, сделали ввод и проверили результаты заботы функции, а затем вышли. Не больше, не меньше. Если уже затрагивается более одного бизнес-функционала в одном тесте, при этом эти функции не являются взаимо-зависимыми, то в результате наши автоматизированные тесты рискуют пропустить ошибку в одном функционале, если будет выявлена критичная ошибка в другом функционале, который проверялся раньше. С точки зрения дизайна разница в предложенных подходах незначительная, но с точки зрения реализации появляются проблемы с выравниванием состояния приложения, чтобы можно было продолжить тест. Безусловно, глупо плодить тысячи мелких и крайне похожих тестов, но и слишком длинные сценарии вредны. Нужно искать некоторый баланс, удобный и для дизайна и для реализации
• Имеется фиксированный набор выполняемых команд и верификаций - имеется ввиду, что было бы неплохо сформировать достаточно узкий и в то же время покрывающий по максимуму набор выполняемых команд с поправкой на параметры. Например, если мы тестируем Content Management System, то у нас для разного типа содержимого есть фиксированный набор операций: перейти - создать и заполнить - сохранить и проверить - переоткрыть - модифицировать - сохранить и проверить. Вот по такому шаблону можно пройтись по всем типам содержимого, специфику составляют только используемые ресурсы. В этом случае, тест-дизайнер делает много дублирований, которые потом устраняются во время автоматизации, а ведь настоящий джедай знает, что Copy/Paste sucks. Более того, есть различные подходы в автоматизации тестирования, которые эффективны именно при определенном дизайне. Так вот тот же keyword-driven подход как раз наиболее эффективен, когда можно выделить фиксированный набор действий. Поэтому, формирование единого каркаса для группы тестов, резко уменьшает работу тест-дизайнеру, а затем и автоматизатору