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