CSS локатори або селектори: основні принципи використання в автоматизації тестування

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Всім привіт! Сьогодні я з вами поговорю про локатори CSS та їх використання для автоматизації тестування веб-додатків. Якщо ви займаєтеся тестуванням веб-додатків, то ви точно знаєте, що пошук та ідентифікація конкретних елементів на веб-сторінці може бути досить непростою задачею. Саме тому локатори CSS є таким потужним інструментом для автоматизації тестування.

За допомогою локаторів CSS ви зможете швидко та ефективно ідентифікувати будь-який елемент на веб-сторінці, незалежно від його розташування та структури. Тож, якщо ви хочете покращити ефективність своїх тестів та зекономити час, то локатори CSS — це те, що вам потрібно. Давайте разом розберемось, яким саме локатором можна скористатися для того, щоб знайти потрібний елемент на веб-сторінці.

Нижче наведена табличка з варіантами css селекотрів та їх написання. Як писати css локатори — відео на youtube.

СелекторПрикладРоз’яснення
.class.some_classЗнаходить всі елементів з class="some_class"
.class1.class2.user1.user2Знаходить всі елементи, у яких class містить user1 та user2 наприклад
<div class="user1 user2 user3″>
.class1 .class2.user1 .user2Знаходить всі елементи з класом user2, які знаходяться в будь-якому рівні вкладеності всередині елементів з класом user1″
[class][clas="user1 user 2″]Знаходить всі елементи, у яких class містить виключно user1 та user2 наприклад <div class="user1 user2"></div>
#id#userЗнаходить елемент з id="user". ID зазвичай унікальний на сторінці
**Знаходить всі елементи, також можна скорочувати локатори приклад [name=’name1234′] можливо записати [name*=’name12′]
elementpВибір всіх елементів <p> на сторінці
element.classp.introВибір всіх елементів <p> з class="intro"
element,elementdiv, pВибір всіх елементів <div> та <p>
element elementdiv pВибір всіх елементів <p>, які є нащадком <div>
element>elementdiv > pВибір всіх елементів <p>, де батьківський елемент <div>
element:nth-child(n)ul li:nth-child(2)Вибирає n-ий дочірній елемент. В данному випадку другуй елемент
<ul>
<li>Перший елемент</li>
<li>Другий елемент</li>
<li>Третій елемент</li>
</ul>
element:first-childul li:first-childВибирає перший дочірній елемент
<ul>
<li>Перший елемент</li>
<li>Другий елемент</li>
<li>Третій елемент</li>
</ul>
element:last-childul li:last-childВибирає останній дочірній елемент
<ul>
<li>Перший елемент</li>
<li>Другий елемент</li>
<li>Третій елемент</li>
</ul>
element[attr]input[type="text"]Вибирає елемент з певним атрибутом
element[attr="value"]input[type="text"][name="email«]Вибирає елемент зі співпадаючим значенням атрибута. Тобто елемент має ці два атрибута
:notdiv:not(.example)Вибір всіх елементів div, які не мають класу «example»
:not.content:not(ul li)Вибір всіх елементів із класом «content», які не є елементами списку
:notbutton:not([type])Вибір всіх елементів button, які не мають атрибуту type
:nota:not(.external):not([target="_blank«])Вибір всіх елементів з тегом «a», які не мають класу «external» і не мають атрибуту target="_blank"

Найкраще використовувати чіткі та специфічні локатори, щоб забезпечити стабільність вашого тесту. Наприклад, замість використання локатора div, краще використовувати div зі специфічним класом або ідентифікатором. Також рекомендується використовувати локатори, які не залежать від структури сторінки, наприклад, data-атрибути. Якщо структура сторінки змінюється, то локатор, який залежить від структури, може перестати працювати. Будьте обережні з id атрибутом він може змінюватись. Намагайтесь писати короткі та зрозумілі локатори щоб коли ви повернетесь до проєкту через рік.... ну ви зрозуміли. Дякую за увагу.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Будьте обережні з id атрибутом він може змінюватись

Так може й добре, що тести зламаються? Якщо айді змінений, то суть контролу змінюється, відповідно тест повинен бути щонайменше ревʼювнутий.

Я маю на увазі id які генеруються автоматично.

для автоматизації тестування веб-додатків.

Я сам за цсс локаторы, но тестировщики почему-то любят xpath.

Не то что бы любят, есть случаи, при которых только xpath и работает. Так что это скорее кактус, который приходится есть.

Можу додати також можливість використання :has, який ’дозволяє’ знаходити батьківський html елемент на основі характеристик нащадків

Так як статтю написав QA automation engineer, відразу виникає питання: А навіщо вам заморачуватись такою кількістю локаторів якщо ви можете використовувати кастомні id типа test-id, data-testid або (data-cy or data-test-id) для cypress. В багатьох статтях та відео зустрічав рекомендації що краще використовувати кастомні id замість пошуку по селекторам. Тим більше вірогідність того що class чи id можуть замінити, а ваші test-id ніхто не буде змінювати, якщо ви введете таку практику з дев командою. Ви як автоматизатор можете самі додати той локатор який вам потрібно у код.

Якщо бюджет, строки, рівень доступу це дозволяє то в довгостроковій перспективі тести можуть бути більш стійкі. Але за звичай якщо фронт будуть змінювати то є великий шанс що змінять не сам атребут а елемент в якому він знаходится. Плюс треба розуміти що такий підхід ресурсно затратний...

Але так це дуже гарна практика

Мені подобається, коли автоматизатори додають собі локатори самі в коді фронта. То зовсім не складно, можна створити найбільш зручний локатор в найбільш правильному місці і забути про побудову складних селекторів.

Звісно, додати необхідний атрибут до фронту не складно. Та в довгостроковій перспективі тести будуть більш стійкі. Але,нажаль,не завжди у вас є така можливість. Все залежить від проекту над яким працюєш,команди,рівня доступу, буджету та строків.

Згоден, тільки не зі строками ) За моїм досвідом скоріше самому зробити, ніж казати девам, що, де і як треба. Єдине що, якщо строки не дозволяють взагалі витрачати на це час будь-кому. А взагалі, ці причини дуже рідко насправді заважають. В якому випадку нема доступу? Тільки якщо фронт репозиторій належить іншій компанії чи щось таке.

Дякую за статтю!

Будьте обережні з id атрибутом він може змінюватись.

— отаке стається дуже рідко, особисто я зустрічав тільки на глобальний сайтах (гугл, фб і тд). Пошук по айді якраз таки рекомендують юзати, якщо є можливість, бо він найшвидший.

Від себе хотів би додати, що ще можна робити пошук наступного сусіднього елементу, який є всередині того самого батьківського елементу:

#user + input

в цьому випадку знайдеться елемент з айді юзер і від нього наступний інпут елемент.

Також можна матчити атрибути регулярками:

input[type^="text"]

елемент з префіксом атрибута

input[type$="text"]

елемент з суфіксом атрибута

input[type*="text"]

елемент з сабстрінгом атрибута

Найшвидший пошук це його відсутність)) Ту ж форму можна по імені дістати з колекції і так само всі її елементи, але так напевно ніхто не робить)

не завжди)
мені часто попадались елементи, які мають один однаковий атрибут, як і багато інших, або атрибут, який автогенериться при кожному лоаді сторінки, то там так доступитись напряму не вийде.
приходилось обходити або від парента або шукати перший в списку з таким же атрибутом і проходити по ньому табом або циклом, хоча це костиль, але як тимчасове рішення — ок

Підписатись на коментарі