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