Test Engineer Noveo Юлия рассказывает об удобном и достаточно новом способе идентифицировать элементы на веб-странице при тестировании UI, а именно — об атрибуте data-qa
.
Каждый, кто интересуется или непосредственно занимается автоматизацией тестирования UI, знает о том, как порой сложно выбрать подходящий селектор.
Идентификаторы («id»-атрибуты элементов) не всегда присутствуют в коде страницы, а порой бывают сложночитаемыми (т.е. написанными не на «человечески понятном» языке), или даже динамическими, и не пригодными к использованию в качестве селекторов.
Xpath и CSS селекторы используются достаточно часто, но в этом случае при изменении структуры документа или таблицы стилей селектор может стать устаревшим и, соответственно, неработающим. Также такие селекторы порой получаются достаточно длинными, а оптимизировать их длину не всегда возможно.
Как результат, высока вероятность падения тестов: элемент на месте и работает как нужно, но селектор, обозначающий этот элемент в коде теста, устарел.
В HTML5 появилась новая возможность: data-
* атрибуты. Это универсальный атрибут, который можно добавить для любого элемента (тега) на странице. Он позволяет создавать кастомные атрибуты для хранения каких-либо значений. Главные правила: название атрибута всегда должно начинаться с «data-
», а также могут использоваться только латинские буквы, дефис, двоеточие и подчеркивание.
Если такой атрибут используется для автоматизации тестирования, самыми логичными вариантами выглядят «data-qa
» или «data-test
», но можно использовать любые другие наименования. В тексте этой статьи атрибут носит название «data-qa
», но на практике оно может быть любым другим по усмотрению.
Data-qa
-атрибут можно впоследствии использовать в качестве селектора. Для этого нужно, чтобы в коде страницы для каждого элемента/тега, который будет или с большой вероятностью может быть использован в автотестах, был добавлен этот атрибут.
Таким образом специалист по тестированию получает в распоряжение «свой собственный» атрибут, в рамках использования которого становится возможным внедрить легкочитаемые и «человечески понятные» обозначения элементов (селекторы) и в рамках всего веб-приложения сформировать из них четкую структуру.
Кроме того, атрибут data-qa
присваивается элементу один раз и обычно не нуждается в каких-либо модификациях и изменениях. Соответственно, пока элемент находится на веб-странице, атрибут data-qa
этого элемента всегда будет присутствовать в коде страницы, неизменный, а значит, ссылка на элемент тоже будет постоянной. Стабильность!
Безусловно, составление списка этих атрибутов, определение, каким элементам он должен быть присвоен, фиксирование всего в документации — это задача специалиста по тестированию. А добавление этого атрибута в код для всех нужных элементов — задача разработчика. Соответственно, это дополнительная нагрузка для обоих. Поэтому нужно учитывать, насколько широко автоматизация тестирования UI будет использоваться на проекте и будет ли это целесообразно в плане трудозатрат.
Если принято решение внедрить использование атрибутов data-qa
на проекте, то это, конечно, лучше делать как можно раньше. Хороший воркфлоу можно описать таким образом:
- Тестирование документации, исправление ошибок;
- Тестирование файлов дизайна (мокапов), исправление ошибок;
- Определение элементов, которые будут использоваться для последующей автоматизации тестирования;
- Определение наименований атрибутов
data-qa
для этих элементов, фиксирование в документации; - Разработка задачи и добавление атрибутов
data-qa
для элементов в коде страницы; - Тестирование задачи, тестирование наличия атрибутов
data-qa
.
Теперь посмотрим, как могут выглядеть сами атрибуты data-qa
.
На мой взгляд, имеет смысл ввести два базовых правила:
- все атрибуты должны иметь схожую структуру;
- если элементы имеют какие-то общие признаки (например, расположены на одной странице или являются элементами одного типа, как «поле ввода» или «кнопка»), эти признаки должны быть отражены в тексте атрибута
data-qa
.
Например, в общем виде атрибут может выглядеть как:
<название страницы>_<название элемента>
Например:
HOME_TITLE
Где HOME — название страницы («главная страница»), TITLE — заголовок страницы. Или
SETTINGS_PASSWORD_CHANGE_INPUT
Где SETTINGS — название страницы («настройки»), PASSWORD_CHANGE — форма смены пароля, INPUT — указание на поле ввода
Теперь на примере нескольких страниц абстрактного веб-проекта посмотрим, как это будет выглядеть.
Начнем с самого первого и базового, что обычно тестируется, — страницы авторизации.
Здесь:
[0] = LOGIN_FORM_PAGE — сама страница авторизации (LOGIN_FORM) и указание на то, что это целая веб-страница (PAGE).
[1] = LOGIN_FORM_TITLE — заголовок, наследует название страницы, на которой расположен (LOGIN_FORM), и т.к. заголовок на странице один, имеет универсальное обозначение (TITLE).
[2] = LOGIN_FORM_LOGIN_INPUT — текстовое поле ввода логина (LOGIN_INPUT).
[3] = LOGIN_FORM_PASSWORD_INPUT — текстовое поле ввода пароля (PASSWORD_INPUT).
[4] = LOGIN_FORM_LOGIN_INPUT_ALERT_MESSAGE — информационное сообщение (ALERT_MESSAGE), которое содержит информацию о поле ввода логина (LOGIN_INPUT).
[5] = LOGIN_FORM_PASSWORD_INPUT_ALERT_MESSAGE — информационное сообщение (ALERT_MESSAGE), которое содержит информацию о поле ввода логина (LOGIN_PASSWORD).
[6] = LOGIN_FORM_SUBMIT — кнопка подтверждения входа (SUBMIT).
[7] = LOGIN_FORM_BADGE_SCAN_GOTO — переход на страницу сканирования бейджа (BADGE_SCAN). Т.к. после нажатия этой кнопки пользователь попадает на другую страницу/форму, атрибут имеет обозначение GOTO.
Теперь рассмотрим абстрактную страницу корзины интернет-магазина.
Это страница с парой вкладок (товары в наличии и товары не в наличии), строкой поиска, таблицей для отображения данных о товаре и кнопками отмены и оплаты заказа. В данном случае задействована поисковая строка, в которую введен запрос, и подходящих результатов для этого запроса не нашлось.
Data-qa
можно разместить следующим образом:
[0] = BASKET_PAGE — непосредственно страница (PAGE) корзины (BASKET).
[1] = BASKET_RETURN_BACK — кнопка возвращения на предыдущую страницу. Так как предыдущая страница может быть не всегда одной и той же, обозначить эту кнопку имеет смысл просто как RETURN_BACK.
[2] = BASKET_IN_STOCK_GOTO — переход на вкладку (GOTO) с товарами в наличии (IN_STOCK).
[3] = BASKET_OUT_STOCK_GOTO — переход на вкладку (GOTO) с товарами не в наличии (OUT_STOCK).
[4] = BASKET_SEARCH_INPUT — текстовое поле (INPUT) для ввода поискового запроса (SEARCH).
[5] = BASKET_SEARCH_CLEAR_INPUT — кнопка очистки (CLEAR_INPUT) текстового поля поиска (SEARCH).
[6] = BASKET_QUANTITY_TITLE — заголовок (TITLE) столбца, в котором отображается количество товаров одного типа (QUANTITY).
[7] = BASKET_NAME_TITLE — заголовок столбца, в котором отображается название товара (NAME).
[8] = BASKET_DESCRIPTION_TITLE — заголовок столбца, в котором отображается краткое описание товара (DESCRIPTION).
[9] = BASKET_UNIT_PRICE_TITLE — заголовок столбца, в котором отображается цена за единицу товара (UNIT_PRICE).
[10] = BASKET_TOTAL_PRICE_TITLE — заголовок столбца, в котором отображается цена за все товары одного типа (TOTAL_PRICE).
[11] = BASKET_NO_RESULTS_ALERT_MESSAGE — предупреждающее сообщение (ALERT_MESSAGE), содержащее информацию об отсутствии соответствующих поисковому запросу товаров.
[12] = BASKET_TOTAL_PRICE — нередактируемое текстовое поле с общей стоимостью (TOTAL_PRICE) всего заказа.
[13] = BASKET_ORDER_DELETE_SUBMIT — кнопка подтверждения (SUBMIT) удаления заказа (ORDER_DELETE).
[14] = BASKET_ORDER_PAY_SUBMIT — кнопка подтверждения (SUBMIT) оплаты заказа (ORDER_PAY).
И, наконец, рассмотрим ту же страницу, только с пустой поисковой строкой и одним товаром в корзине.
В данном случае многие элементы точно те же, что и на предыдущем изображении, поэтому заново их можно не размечать, data-qa
будут такими же.
Здесь:
[1] = BASKET_PRODUCT_DECREASE_QUANTITY_{ID} — кнопка уменьшения (DECREASE) количества (QUANTITY) конкретного товара (PRODUCT). Идентификатор ID нужен для указания на конкретную строку таблицы (конкретный товар).
[2] = BASKET_PRODUCT_QUANTITY_{ID} — нередактируемое текстовое поле для отображения количества (QUANTITY) конкретного товара (PRODUCT).
[3] = BASKET_PRODUCT_INCREASE_QUANTITY_{ID} — кнопка увеличения (INCREASE) количества конкретного товара.
[4] = BASKET_PRODUCT_NAME_{ID} — нередактируемое текстовое поле для отображения названия товара (NAME).
[5] = BASKET_PRODUCT_DESCRIPTION_{ID} — нередактируемое текстовое поле для отображения краткого описания товара (DESCRIPTION).
[6] = BASKET_PRODUCT_UNIT_PRICE_{ID} — нередактируемое текстовое поле для отображения цены за единицу товара (UNIT_PRICE).
[7] = BASKET_PRODUCT_TOTAL_PRICE_{ID} — нередактируемое текстовое поле для отображения цены за все товары одного типа (TOTAL_PRICE).
[8] = BASKET_PRODUCT_DELETE_{ID} — кнопка удаления товара из корзины (DELETE).
[9] = BASKET_PRODUCT_{ID} — строка товара целиком без указания на конкретный столбец.
Как можно хранить документацию для атрибутов data-qa
? В любом удобном виде. В качестве примера приведем таблицу:
Mockup с размеченными data-qa |
Список data-qa атрибутов |
Ссылки на связанные тикеты | Development status | QA review status |
Макет страницы, на котором указаны номера атрибутов data-qa |
Список атрибутов data-qa с названиями и номерами, соответствующими обозначениям на дизайн-макете |
Список тикетов, которые связаны с веб-страницей, отображенной на макете, и атрибутами data-qa этой страницы |
Статус разработки атрибутов data-qa . Например:
* пустое поле (не сделано) * в процессе * сделано |
Статус тестирования атрибутов data-qa . Например:
* пустое поле (не тестировалось) * есть ошибки (MISSING со списком недостающих атрибутов) * проверено (PASSED) |
На этом всё. Надеемся, что эта информация окажется полезной. Спасибо за прочтение!
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: