Прибуток:
- Можливість створювати надійний тестовий код інтерфейсу користувача зі штучним інтелектом, включаючи data-testid, open wait і assert, який перевіряє реальний результат користувача
- Можливість уникати крихких тестів (поганий селектор, сліпе очікування) і полегшувати підтримку тестів у структурі Page Object Model
- Можливість тестувати кожен тест інтерфейсу користувача, створений шляхом злому коду, а також виявляти та виправляти помилково пройдені тести
Кожне клацання, кожне заповнення форми, кожен перехід сторінки, який виконує користувач у браузері, не можна тестувати знову і знову вручну — ось чому існує автоматизація тестування інтерфейсу користувача (інтерфейс користувача; ці тести імітують поведінку користувача шляхом програмного керування справжнім браузером). Selenium, Playwright і Cypress є найпоширенішими інструментами для цієї роботи. Штучний інтелект (ШІ) має високі навички написання коду для цих інструментів: ви описуєте тестовий приклад, ШІ дає вам чернетку працездатного сценарію автоматизації. Але тут знову вступає в дію головне попередження цього модуля: тестовий код інтерфейсу користувача, створений штучним інтелектом, часто може бути крихким тестом, який «світиться зеленим, але перевіряє неправильну річ» або махає на вітрі. Ваше завдання полягає не в тому, щоб запустити цей код, а в тому, щоб переконатися, що він дійсно надійно перевіряє правильну річ.
У цьому підрозділі ми прагнемо створювати надійні, зручні в обслуговуванні та справді перевіряючі тести інтерфейсу користувача за допомогою ШІ; Ви навчитеся уникати крихких тестів.
Три стовпи надійного тестування інтерфейсу користувача
1. Правильний локатор елементів. Тест використовує селектор для пошуку елемента на сторінці. Штучний інтелект часто створює крихкі селектори: довгі шляхи XPath (адреса надмірно залежить від структури сторінки), селектори на основі імен класів CSS (розриваються при зміні дизайну). Надійний спосіб — це стабільні атрибути, такі як data-testid, які розробник додав для тестування. Явно нав’яжіть це ШІ.
2. Явне очікування. Джерелом уразливості номер один у тестуванні інтерфейсу користувача є час. Постійний сон(3) (сліпе очікування) — це погана практика: іноді цього недостатньо, іноді це витрачає час. Правильний спосіб - використовувати явне очікування, яке говорить "зачекайте, поки цей елемент не з'явиться". Драматург робить це значною мірою автоматично; У Selenium ви повинні явно запитати це.
3. Змістовне твердження. Тест повинен підтвердити результат, який користувач дійсно побачить, наприклад «номер замовлення з’явився на екрані», а не просто «сторінку завантажено». Якщо тест, створений штучним інтелектом, не містить твердження або неважливий, цей тест створює псевдопрохід (1-й блок).
Застереження: коли ви вперше бачите тест інтерфейсу користувача, створений штучним інтелектом, перевірте щонайбільше три речі: чи зафіксовано селектори (data-testid), чи включено очікування (без сліпого сну) і чи перевіряє assert фактичний результат користувача? Якщо ці три в порядку, тест, ймовірно, надійний.
Об'єктна модель сторінки
Оскільки тести стають більшими, написання селекторів у кожному тесті стає кошмаром обслуговування. Page Object Model (POM — шаблон проектування, який збирає селектори та дії для кожної сторінки/екрана в один клас) зберігає селектор в одному місці; Коли інтерфейс змінюється, ви оновлюєте його в одному файлі. Нехай AI виробляє тести в структурі POM, а не безпосередньо; Це значно спрощує обслуговування.
Слабка підказка / Сильна підказка
Слабко: «Напишіть тест Selenium для сторінки входу».
Сильно: «Напишіть тест входу в систему за допомогою Playwright (TypeScript). Селектори використовують лише data-testid; не використовуйте керування тим, що бачить користувач, а не заголовок сторінки».
Потужна підказка; Інструмент надає мову, політику вибору, стратегію очікування, архітектуру (POM) і виразне очікування підтвердження.
Тестові дані та незалежність середовища
Надійний тест інтерфейсу користувача не тільки написаний правильно, але також створює та очищає власні тестові дані. Тести, згенеровані штучним інтелектом, часто посилаються на користувача або запис, які, як передбачається, уже існують у середовищі («увійдіть як адміністратор»). Це припущення руйнується, коли тест виконується в іншому середовищі або після іншого тесту (проблема залежності порядку в блоці 9). Правда полягає в тому, що кожен тест створює необхідні дані на початку тесту (або готує їх за допомогою виклику API) і очищає їх наприкінці. Чітко вказуйте штучному інтелекту «налаштувати будь-які дані, від яких залежить цей тест, у межах тесту; не припускайте готові дані ззовні».
Ще один важливий момент — не проводити тестування інтерфейсу користувача з реальними даними користувача. Якщо в тестовому середовищі використовується робоча копія бази даних, ці записи є даними реальних осіб; скріншоти та тестові записи можуть виявити ці дані. Використовуйте синтетичні (вигадані) тестові облікові записи; це одночасно захищає конфіденційність і робить тести відтворюваними. Проведення тесту «скасування замовлення» з реальним обліковим записом клієнта є як етичною, так і операційною помилкою.
Порада: зберігайте якомога менше тестів інтерфейсу користувача; Залиште фактичну перевірку API та модульним тестам, які є швидкими та стабільними. Тестування інтерфейсу користувача є дорогим і крихким — використовуйте його лише для перевірки дійсно наскрізного потоку користувачів (перевірте логіку піраміди).
Порівняння транспортних засобів
функція
селен
драматург
кипарис
мови
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
автоматичний режим очікування
Ні (вручну)
Так (сильний)
так
Мультибраузер
широкий
Chromium/Firefox/WebKit
Хромодомінантний
схильність до ламкості
Високий (ручний режим очікування)
низький
низький
Легкість навчання
середній
легко
легко
паралельна робота
Необхідна сітка
вбудований
Резидент/платний
Запитуючи код від AI, чітко вкажіть, якому транспортному засобу він належить; Інакше може виникнути заплутаний, непрацюючий код.
Чотири шаблони, які можна копіювати
1) Генерація надійного тесту інтерфейсу користувача:
Ваша роль: старший інженер з автоматизації тестування. Напишіть тести за допомогою [інструмент + мова] для наступного потоку: [потік]. Правила: - Лише селектори data-testid; Використання XPath/CSS-класу. - Ніякого сліпого сну; Використовуйте явне/автоматичне очікування. - Застосувати об'єктну модель сторінки. - Нехай кожне твердження перевіряє фактичний результат користувача. Прокоментуйте на початку кожного тесту, які критерії прийнятності ви підтверджуєте.
2) Контроль крихкості:
Вивчіть наступний тест інтерфейсу користувача на крихкість: - Чи є нестабільний селектор (довгий
3) Перетворення на об’єкт сторінки:
Перетворіть наведений нижче простий тестовий код у структуру об’єктної моделі сторінки. Перемістити селектори та дії до класів сторінок; Нехай тестовий файл читає лише потік сценарію. [Інструмент/мова].Код: [вставити код]
4) Доказ псевдопереходу:
Доведіть, що цей тест інтерфейсу користувача дійсно перевіряє: яку єдину зміну я можу зробити в коді програми, щоб зробити цей тест ЧЕРВОНИМ? Якщо ви не можете знайти зміну, яка порушить тест, тест неадекватний; додати відсутні твердження. Тест: [вставити тест]
три міні-чохла
Випадок 1 — Звільнення від крихкого селектора. З 40 тестів, проведених однією командою за допомогою ШІ, 70% були зламані після оновлення інтерфейсу; жодна з них не була справжньою помилкою, усі вони були крихкими селекторами XPath. Команда перетворила тести на базу даних тестування за допомогою шаблону «перевірка крихкості». Протягом наступних трьох оновлень інтерфейсу кількість помилкових зламів знизилася до нуля; час обслуговування зменшено з 6 годин до 30 хвилин на тиждень.
Випадок 2 — Тест інтерфейсу користувача на підроблене проходження. AI створив тест «додати в кошик»; тест був зелений. Під час запуску шаблону підробленого підтвердження проходження виявилося, що тест перевіряє лише натискання кнопки та назву сторінки, не перевіряючи, чи збільшився лічильник кошика чи ні. Навіть якщо логіка візка була повністю зламана, тест пройшов. Додано справжнє твердження (значок кошика має значення «1»).
Випадок 3 — Пастка для сліпого очікування. У тесті Selenium, створеному штучним інтелектом, був сон (2) після кожного кроку; 60 тестів зайняли 14 хвилин і все одно іноді виходили з ладу. Після переходу на відкрите очікування (дочекайтеся, поки елемент стане клацабельним) час зменшився до 5 хвилин і крихкість зникла. Сліпе очікування було повільним і ненадійним.
Поширені помилки
- Погоджуючись на тендітні селектори. Використання довгих XPaths, згенерованих AI як є; Тести падають при першій зміні інтерфейсу.
- Залишаючи сліпий `сон`. «Вирішення» таймінгу з фіксованим очікуванням; і повільно, і нерішуче.
- Тривіальне твердження. Просто переконайтеся, що сторінка завантажилася; неперевірка фактичного результату користувача (фальшивий пропуск).
- Рости без POM. Роздайте селектори для кожного тесту; Ручне оновлення десятків файлів при зміні інтерфейсу.
- Не вказуючи інструмент. Не повідомляючи ШІ, який інструмент/мову ви хочете; отримання брудного, неробочого коду.
- Довіра, коли ви запускаєте згенерований код і проходите. Не тестування шляхом зламу коду.
Підсумовуючи
Автоматизація тестування інтерфейсу користувача перевіряє поведінку користувача, керуючи фактичним браузером за допомогою програми. ШІ швидко генерує цей код, але є дві великі підводні камені: крихкі тести (поганий селектор, сліпе очікування) і фальшиві тести (неповне/тривіальне твердження). Трьома стовпами надійного тестування інтерфейсу користувача є селектор фіксації (data-testid), явне очікування та підтвердження, яке перевіряє фактичний результат користувача. Наявність тестів, згенерованих у моделі Page Object Model, радикально спрощує обслуговування. Перевірте кожен згенерований тест із запитанням "яка зміна порушить це?"
Аплікаційне завдання
Виберіть потік користувача зі свого власного проекту (наприклад, вхід або пошук). Попросіть ШІ написати тести за допомогою шаблону «генерація надійного тесту інтерфейсу користувача». Потім: (1) перевірте та виправте селектори та чекайте за допомогою «перевірки крихкості», (2) доведіть, що кожен тест дійсно підтверджується за допомогою «псевдоперевірки», (3) зламайте код і спостерігайте, що тест стає червоним. Повідомте кількість створених і виправлених тестів, а також кількість знайдених вразливостей і псевдопроходів.
контрольний список
- [ ] Я чітко дав ШІ інструмент, мову, політику вибору та архітектуру (POM).
- [ ] Я переконався, що селектори перевірені на дані.
- [ ] Я переконався, що використовував явне/автоматичне очікування замість сліпого сну.
- [ ] Я перевірив, чи кожне твердження підтверджує фактичний результат користувача.
- [ ] Я тестував кожен тест, зламавши код; Я бачив, як воно почервоніло.
- [ ] Я зібрав тести в структурі Page Object Model.