Добици:
- Способност израде робусног УИ кода за тестирање са вештачком интелигенцијом, укључујући дата-тестид, отворено чекање и потврду која потврђује прави резултат корисника
- Способност да се избегну крхки тестови (лош селектор, слепо чекање) и да се тестови лако одржавају у структури модела странице
- Могућност тестирања сваког УИ теста произведеног разбијањем кода и откривања и поправљања лажно прошлих тестова
Сваки клик, свако попуњавање обрасца, сваки прелаз на страницу који корисник направи у претраживачу не може се тестирати изнова и изнова ручно — зато постоји аутоматизација УИ теста (кориснички интерфејс; ови тестови опонашају понашање корисника програмским покретањем правог претраживача). Селен, драматург и чемпрес су најчешћи алати за овај посао. Вештачка интелигенција (АИ) је веома вешта у писању кода за ове алате: ви описујете тест случај, АИ вам даје нацрт функционалне скрипте за аутоматизацију. Али овде поново долази у обзир централно упозорење овог модула: код за тестирање корисничког интерфејса који производи вештачка интелигенција често може бити крхки тест који „светли зелено, али потврђује погрешну ствар“ или клапа на ветру. Ваш посао није да покренете овај код, већ да се уверите да он заиста робусно верификује праву ствар.
У овој јединици, циљ нам је да произведемо робусне, одрживе и заиста валидне УИ тестове са АИ; Научићете да избегавате крхке тестове.
Три стуба чврстог УИ тестирања
1. Тачан локатор елемената. Тест користи селектор да пронађе елемент на страници. АИ често производи крхке селекторе: дуге КСПатх путање (адреса превише зависе од структуре странице), селекторе засноване на именима ЦСС класа (прекид када се дизајн промени). Робустан начин су стабилни атрибути као што је дата-тестид које је програмер додао за тестирање. Експлицитно наметните ово АИ.
2. Експлицитно чекање. Извор број један рањивости у тестирању корисничког интерфејса је тајминг. Стално спавање(3) (слепо чекање) је лоша пракса: понекад није довољно, понекад губи време. Исправан начин је коришћење експлицитног чекања, што каже „сачекајте док се овај елемент не појави“. Драмски писац то ради углавном аутоматски; У Селену то морате изричито захтевати.
3. Смислена тврдња. Тест треба да потврди резултат који ће корисник заиста видети – на пример „број поруџбине се појавио на екрану“, а не само „страница је учитана“. Ако тест који је произвела АИ нема тврдњу или је неважан, тај тест производи псеудо пролаз (1. јединица).
Опрез: Када први пут видите тест корисничког интерфејса који је генерисала вештачка интелигенција, проверите највише три ствари: да ли су селектори ангажовани (дата-тестид), да ли су укључени (без слепог спавања) и да ли ассерт потврђује стварни резултат корисника? Ако су ова три у реду, тест је вероватно солидан.
Објектни модел странице
Како тестови постају све већи, писање селектора унутар сваког теста постаје ноћна мора одржавања. Објектни модел странице (ПОМ — образац дизајна који прикупља селекторе и акције за сваку страницу/екран у једну класу) држи селектор на једном месту; Када се интерфејс промени, ажурирате га у једној датотеци. Нека АИ производи тестове у ПОМ структури, а не директно; Ово чини одржавање радикално лакшим.
Слаби промпт / Јаки промпт
Слабо: „Напишите Селенијум тест за страницу за пријаву.“
Јака: „Напишите тест тока пријављивања помоћу Плаивригхт-а (ТипеСцрипт). Селектори користе само дата-тестид; не користе контролу онога што корисник види, а не наслов странице.“
Снажан промпт; Алат даје језик, политику селектора, стратегију чекања, архитектуру (ПОМ) и очекивања експресивног тврдњи.
Тест података и независности околине
Чврсти УИ тест није само исправно написан, већ и гради и чисти сопствене податке теста. Тестови генерисани вештачком интелигенцијом често се повезују са корисником или записом за који се претпоставља да већ постоји у окружењу („пријавите се као корисник администратор“). Ова претпоставка се прекида када се тест покрене у другом окружењу или након другог теста (проблем зависности од редоследа у јединици 9). Истина је да сваки тест креира податке који су му потребни на почетку теста (или их припрема помоћу АПИ позива) и чисти их на крају. Експлицитно упутите АИ да „подеси све податке од којих овај тест зависи у оквиру теста; немојте претпостављати готове податке споља“.
Још једна критична тачка је да се не врши тестирање корисничког интерфејса са стварним корисничким подацима. Ако се у тестном окружењу користи копија производне базе података, ови записи су подаци стварних особа; снимци екрана и тестни снимци могу открити ове податке. Користите синтетичке (измишљене) тест налоге; истовремено штити поверљивост и чини тестове поновљивим. Спровођење теста „отказивање поруџбине“ са стварним корисничким налогом је и етичка и оперативна грешка.
Савет: Одржавајте УИ тестове што је могуће мање; Оставите стварну верификацију АПИ-ју и јединичним тестовима, који су брзи и стабилни. Тестирање корисничког интерфејса је скупо и крхко — користите га само за валидацију стварног тока корисника од краја до краја (логика тест пирамиде).
Поређење возила
карактеристика
селен
драматург
чемпрес
језика
Јава, Ц#, Питхон, ЈС
ЈС/ТС, Питхон, .НЕТ, Јава
ЈаваСцрипт/ТипеСцрипт
ауто стандби
Не (ручно)
да (јако)
Да
Мулти претраживач
широк
Цхромиум/Фирефок/ВебКит
Доминантан хром
склоност крхкости
Висока (ручно стање приправности)
ниско
ниско
Лакоћа учења
средње
лако
лако
паралелни рад
Потребна је мрежа
уграђени
Резидент/плаћено
Када тражите код од АИ, јасно наведите којем возилу припада; У супротном, може произвести збуњујући, нефункционални код.
Четири шаблона за копирање
1) Генерисање солидног УИ теста:
Ваша улога: виши инжењер за аутоматизацију тестирања. Пишите тестове са [алат + језик] за следећи ток: [ток].Правила:- Селектори само за тест података; Коришћење КСПатх/ЦСС класе. - Нема слепог сна; Користите експлицитно/аутоматско чекање. - Примени објектни модел странице. - Нека сваки асерт потврди стварни резултат корисника. Коментирајте на почетку сваког теста које критеријуме прихватања потврђујете.
2) Контрола крхкости:
Испитајте следећи УИ тест за крхкост:- Да ли постоји нестабилан селектор (дуг
3) Конверзија у објекат странице:
Конвертујте следећи обичан тест код у структуру модела странице. Премести селекторе и акције у класе страница; Нека тестна датотека чита само ток сценарија. [Алатка/језик].Код: [налепи код]
4) Доказ псеудо-транзиције:
Докажите да овај УИ тест заправо потврђује: Коју поједину промену да направим у коду апликације која ће овај тест претворити у ЦРВЕНИ? Ако не можете да пронађете промену која ће прекинути тест, тест је неадекватан; додај недостајуће тврдње.Тест: [налепи тест]
три мини кофера
Случај 1 — Ослобођење од крхког селектора. Од 40 тестова који је један тим направио са АИ, 70% је покварено након ажурирања интерфејса; ниједан од њих није био стварне грешке, сви су били крхки КСПатх селектори. Тим је конвертовао тестове у базу података тестида са шаблоном „провера крхкости“. Током наредна три ажурирања интерфејса, број лажних прекида је пао на нулу; време одржавања је смањено са 6 сати на 30 минута недељно.
Случај 2 — Лажни тест корисничког интерфејса. АИ је направио тест „додај у корпу“; тест је био зелен. Када је покренут шаблон „лажни доказ пролаза“, чинило се да тест само проверава клик на дугме и наслов странице, никада не проверавајући да ли се бројач колица повећао или не. Чак и ако је логика колица била потпуно покварена, тест је прошао. Додато истинито потврда (значка колица је "1").
Случај 3 — Слепа замка чекања. У тесту селена који је произвела АИ, било је спавања(2) након сваког корака; 60 тестова трајало је 14 минута и повремено су се прекидали. Након преласка на отворено чекање (сачекајте да се елемент може кликнути) време се смањило на 5 минута и ломљивост је нестала. Слепо чекање је било споро и непоуздано.
Уобичајене грешке
- Пристанак на крхке селекторе. Коришћење дугих КСПатх-ова које генерише АИ као што јесу; Тестови падају при првој промени интерфејса.
- Остављање слепог `спавања`. „Решавање“ времена са фиксним чекањем; и спор и неодлучан.
- Тривијална тврдња. Само проверите да ли се страница учитала; не проверава стварни резултат корисника (лажни пролаз).
- Расте без ПОМ-а. Расподели селекторе сваком тесту; Ручно ажурирање десетина датотека када се промени интерфејс.
- Без навођења алата. Не рећи АИ који алат/језик желите; постаје неуредан, нефункционалан код.
- Поверење када покренете генерисани код и прођете. Не тестирати разбијањем кода.
Укратко
Аутоматизација тестирања корисничког интерфејса потврђује понашање корисника тако што покреће стварни претраживач са програмом. АИ брзо генерише овај код, али постоје две велике замке: крхки тестови (лош селектор, чекање на слепо) и тестови лажног пролаза (непотпуна/тривијална тврдња). Три стуба чврстог УИ тестирања су селектор урезивања (дата-тестид), експлицитно чекање и ассерт који верификује стварни резултат корисника. Имајући тестове генерисане у објектном моделу странице, радикално се поједностављује одржавање. Тестирајте сваки генерисани тест са питањем "која промена ће ово прекинути?"
Задатак апликације
Изаберите ток корисника из сопственог пројекта (нпр. пријављивање или претрага). Нека АИ напише тестове са шаблоном „генерисање робусног УИ теста“. Затим: (1) проверите и поправите селекторе и сачекајте са „провером крхкости“, (2) докажите да сваки тест заиста потврђује са „доказом псеудо пролаза“, (3) разбијте код и приметите да тест постаје црвен. Пријавите број направљених и исправљених тестова, као и број пропуста и псеудо пролаза које сте пронашли.
контролна листа
- [ ] Јасно сам дао АИ алат, језик, политику селектора и архитектуру (ПОМ).
- [ ] Проверио сам да су селектори тестид података.
- [ ] Побринуо сам се да користим експлицитно/аутоматско чекање уместо слепог спавања.
- [ ] Проверио сам да сваки асерт верификује стварни резултат корисника.
- [ ] Тестирао сам сваки тест разбијањем кода; Видео сам да постаје црвено.
- [ ] Сакупио сам тестове у структури Паге Објецт Модел.