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