Добивки:
- Способност за производство на единица, интеграција и тестови за кориснички интерфејс со вештачка интелигенција во согласност со пирамидата за тестирање и ограничувања и ситуации за грешки, како и среќни сценарија
- Способност да се отстранат празните/бескорисните тестови и надуената покриеност со проверка дали секој генериран тест навистина го потврдува однесувањето
- Обезбедување тестот да ја фати грешката и да го спречи да ја поправи грешката со тоа што ќе и каже на вештачката интелигенција што треба да направи кодот
Пишувањето код е половина од работата; Докажувањето дека кодот работи правилно е другата половина. Мобилните апликации се среќаваат со стотици различни уреди, големини на екран, верзии на оперативниот систем и однесување на корисниците. Невозможно е да се тестираат сите овие рачно; Затоа автоматизираното тестирање (шифра за тестирање на кодот - тестирање што работи без човечки клик) е столбот на квалитетот на мобилниот телефон. Вештачката интелигенција е неверојатно ефикасна во пишувањето тестови бидејќи пишувањето тестови е токму таков вид на работа со шаблони што ѝ се допаѓа: потврдување на специфично однесување за специфични влезови. Во оваа единица, ќе научиме како да го забрзаме тестирањето на единицата, тестирањето на интерфејсот и автоматизацијата со вештачка интелигенција, но да го обезбедиме квалитетот на тестот преку човечки очи.
Пирамида за тестирање: што да се тестира и колку
Здравата стратегија за тестирање наликува на пирамида. Основата вклучува голем број единечни тестови (брзо тестирање кое тестира една функција или класа изолирано); тие се брзи и евтини. Во средината е помалку тестирање за интеграција (тестирање како повеќе делови работат заедно). На врвот има минимално тестирање на UI/од крај до крај (тестирањето се врши со кликнување на екранот како што прави корисникот); тие се реални, но бавни и кревки. Вештачката интелигенција помага во секој слој, но најголемата вредност е во основата: брзо производство на единечни тестови на деловната логика.
Тип на тест
Опсег
брзина
Ефикасност на ВИ
единица тестирање
Единечна функција/класа
многу брзо
многу високо
интеграција
меѓуслојна
средно
високо
UI / од крај до крај
Целиот пренос на екранот
бавно
Средно (кревко)
Совет: Кога ѝ кажувате на вештачката интелигенција да „генерира тестови за оваа функција“, експлицитно побарајте случаи на рабови: празен влез, нула, негативен број, многу голема вредност, мрежна грешка. ВИ лесно создава среќен пат; Вистинските грешки се кријат во границите и скокаат ако не ги сакате таму.
Чекори на пишување тестови со вештачка интелигенција
- Дефинирајте го однесувањето што треба да се тестира. "Оваа функција треба да го даде овој излез на овој влез."
- Наведете ја рамката. JUnit + MockK на Android, XCTest на iOS, Espresso (Android) или XCUITest (iOS) за UI.
- Побарајте гранични состојби. Среќно сценарио + грешка + точки на прекин.
- Управувајте со лажни објекти. Надворешните зависности како што се мрежата и базата на податоци се емулирани за тестирање (mock — контролирано потсмев наместо вистинската услуга).
- Извршете го тестот и потврдете. Дали тестот поминува, дали потврдува нешто навистина значајно?
Петтиот чекор е критичен. ВИ понекогаш произведува бескорисни тестови кои „секогаш поминуваат“; на пример, тест кој не потврдува ништо или ги проверува сопствените лажни податоци. Положен тест и вреден тест се различни работи.
Внимание: Само затоа што вештачката интелигенција може да произведе не значи дека тестот е точен. Понекогаш вештачката интелигенција го прифаќа тековното (можеби погрешно) однесување на кодот како „точно“ и соодветно пишува тестови. Таквото тестирање ја поправа грешката наместо да ја фати. Вие одредувате што очекува тестот; Кажете ѝ на вештачката интелигенција што треба да прави, а не што прави кодот.
Мерка за покривање на тестот и заблуда
Покриеноста на тестот (колкав процент од кодот е воден од тестовите) е корисна, но погрешна метрика. Покриеноста од 90% покажува дека 90% од кодот е извршен; но не е потврдено дека тие линии работат правилно. Тест кој води линија и не го проверува резултатот го надувува опсегот, но не обезбедува сигурност. Целта не се високи бројки, туку значајна валидација. Можете брзо да се зголемите со вештачка интелигенција, но погрижете се секој тест навистина да тестира однесување.
три мини футроли
Случај 1 - Утврдена граничната ситуација. Од вештачката интелигенција беа побарани тестови за функцијата за трансфер на пари во банкарска апликација, а конкретно беа додадени сценаријата „негативен износ“ и „повеќе од салдо“. Тестот покажа дека трансферот не бил блокиран со негативна сума; ова би било голема безбедносна ранливост во производството. Затворено со додавање на контрола од една линија. Лекција: граничните тестови се највредните тестови.
Случај 2 - Лажен тест. Еден тим беше олеснет да ја зголеми покриеноста на 85% со 40 единици тестови произведени од AI. За време на проверката, се виде дека повеќето од тестовите всушност не потврдуваат никаков излез, тие само ја повикаа функцијата и напишаа assertTrue(true). Покриеноста беше висока, но заштитата беше нула. Тестовите беа ремонтирани и препишани со вистински валидации. Лекција: броевите за покриеност може да лажат.
Случај 3 — забрзано тестирање на UI. Тим за е-трговија напиша XCUITtest скрипта за протокот на додавање во количка со вештачка интелигенција за 20 минути; Да се пишуваше на рака, ќе требаше половина ден. Идентификатори на елементи на екранот погодени со вештачка интелигенција; Тимот ги усогласи со вистинската шифра и ги поправи. Брзината на нацртот е реална, но проверката на идентификаторот е човечка работа.
Слаб промпт / Силен промпт
Слаб промпт: „Напишете тест за оваа функција“.
Моќен потсетник: „Произведете тестови за единицата за оваа функција на Kotlin со JUnit5 + MockK. Функција: трансфер на пари (износ, извор, цел). Однесување за тестирање (што треба да прави кодот):- Валиден пренос мора да биде успешен- Негативен или нулта сума мора да се одбие- Износот поголем од салдото треба да се отфрли само една грешка на мрежата треба да биде отфрлена соодветна грешка. описно, исмевајте ја надворешната услуга Не пишувајте празно тврдење.
Шаблони за копирање
Шаблон за тест на единицата: „Генерирајте тестови за единицата [JUnit/XCTest] за оваа функција за [јазик]. Очекувано однесување: [што да се прави]. Вклучете: среќно сценарио, нула влез, точки на прекин, случај на грешка. Дозволете секој тест да потврди едно однесување; користете значајно тврдење; потсмев. [шифра]“.
Шаблон за тестирање на интерфејсот: „Напишете тест за интерфејс за следниов тек со [Espresso/XCUITest]: [проток на корисник чекор по чекор]. Изберете елементи на екранот со идентификатор за пристапност, користете id наместо текст. Додајте стратегија за чекање. Потсетете ме да ги усогласам идентификациите на елементите со вистинскиот код.
Шаблон за ревизија за тестирање:„Испитајте ги овие тестови:1) Дали тие всушност потврдуваат излез/однесување или се нула?2) Дали покриваат гранични случаи?3) Дали го поправаат кодот или очекуваат правилно однесување? Означуваат и зајакнуваат слабите тестови. [тестови]“
Шаблон за оптимизација на покриеност: „Идентификувајте непроверени делови од оваа класа и предложете значајни тестови. Дајте приоритет на патеките со реален ризик, а не само со бројот на покриености. [шифра]“
Вообичаени грешки
- Само тестирање на среќното сценарио. Грешките се чуваат во гранични состојби; Побарајте ги отворено.
- Прифаќање празен/бескорисен тест. Тестовите од типот assertTrue(true) го надувуваат опсегот и не обезбедуваат заштита.
- Имајќи ја вештачката интелигенција да потврди што прави кодот. Тестирањето треба да очекува што треба да направи кодот; инаку ја поправа грешката.
- Грешка на бројот на опсегот за целта. 90% покриеност не значи 90% точност.
- Поврзување со текст при тестирање на UI. Тестот се прекинува кога текстот се менува; Користете стабилен идентификатор (ид).
- Поставување потсмев неправилно. „Тестот на единицата“ што ја повикува вистинската услуга ќе биде бавен и кршлив.
Сумирано
Тестирањето е столбот на квалитетот на мобилниот телефон, а вештачката интелигенција е многу ефикасна во оваа област, особено во тестирањето на единиците. Следете ја пирамидата за тестирање: многу единици, средна интеграција, мало тестирање на UI. Експлицитно прашајте ја вештачката интелигенција за среќното сценарио, како и за ограничување на случаите и патеките за грешки. Осигурајте се дека секој генериран тест навистина потврдува однесување; Празните тестови и надуената покриеност се погрешни. Што е најважно, кажете ѝ на вештачката интелигенција што треба да прави кодот, а не што прави тој, така што тестот ќе ја фати грешката, а не да ја поправи.
Задача за апликација
Побарајте тестови од вештачката интелигенција користејќи го „шаблонот за тестирање единица“ за деловна логичка функција (на пр., пресметка на попуст или валидација на формуларот) и експлицитно наведете гранични случаи (нулти, негативни, премногу големи). Извршете ги генерираните тестови, а потоа проверете ги истите тестови со „шаблонот за тестирање ревизија“. Најдете барем еден слаб тест, зајакнете го и тестирајте дали тестовите фаќаат вистинска грешка на функцијата (со додавање мала грешка).
листа за проверка
- [ ] Го избрав соодветниот слој за тест пирамидата (приоритетна единица)
- [ ] Сакав ограничувања и случаи на грешки покрај среќното сценарио
- [ ] Потврдив дека секој тест содржи значајно тврдење
- [ ] Му кажав на вештачката интелигенција што треба да прави кодот, а не што прави
- [ ] Се фокусирав на вистинските патеки на ризик, а не на бројот на покриености
- [ ] Користев стабилен идентификатор во тестовите за интерфејс, не се врзував за текст