Јединице
1. Увод у вештачку интелигенцију у тестирању софтвера и обезбеђењу квалитета: улоге, границе, ризик од фалсификовања и валидација 2. Тест сценарио и генерисање тест случаја: од захтева до свеобухватне контроле 3. Истраживачко тестирање и генерисање идеја за тестирање: Креативни лов на грешке са вештачком интелигенцијом 4. Аутоматизација УИ теста: генерисање кода за селен, драматург и чемпрес помоћу вештачке интелигенције 5. Аутоматизација АПИ тестова: уговор, шема и свеобухватна валидација са АИ 6. Генерисање јединичних тестова и могућност тестирања: Робусно тестирање са АИ 7. Писање извештаја о грешци и одређивање приоритета: јасни, поновљиви записи са АИ 8. Анализа покривености тестом и тестирање засновано на ризику: Право циљање са АИ 9. Регресионо тестирање, одржавање тестова и борба против осетљивих тестова 10. Тестирање ризика од лажног поверења, квалитета тестова и мутација: тестови тестирања 11. Ток рада од краја до краја, интеграција ЦИ/ЦД, етика и безбедност: одговорно коришћење вештачке интелигенције
Јединица 6 / 11

Генерисање јединичних тестова и могућност тестирања: Робусно тестирање са АИ

Добици:

  • Способност да спречи вештачку интелигенцију да прихвати погрешно понашање као 'исправно' израчунавањем очекиване вредности у јединичним тестовима независно од правила прихватања
  • Могућност штампања брзих, независних и поновљивих тестова применом ААА и ФИРСТ принципа и исмевањем спољних зависности
  • Способност тестирања тестова са мутацијом (разбијање кода) и препознавања кода који се тешко тестира као мирис дизајна

Највећи и најбржи слој пирамиде тестирања је тестирање јединица — тестирање које верификује функцију или мали део кода изоловано од свега осталог. Хиљаде јединичних тестова се покрећу за неколико секунди и откривају грешку док је код још увек на екрану програмера. Вештачка интелигенција (АИ) је можда најискуснија у производњи јединичних тестова: ви јој дате функцију, АИ производи десетине тестова. Али управо ова погодност доводи до највеће замке: АИ лако производи тестове који „светле зелено, али ништа не потврђују“ или прихватају тренутно (можда погрешно) понашање кода као „тачно“. У овој јединици ћете научити како да напишете заиста заштитне тестове јединице са АИ и однос између кода који се може тестирати и АИ.

Квалитети доброг теста јединице: ПРВО

Добри јединични тестови прате ПРВЕ принципе: Брзи, Независни (тестови не би требало да зависе један од другог), Поновљиви (поновљиви — исти резултат у било ком окружењу), Самопотврђујући (јасно прошао/непао), Правовремени (на време). Подсетите се ових принципа када АИ производи тестове; посебно замолите да тест не зависи од спољашњег света (стварне базе података, мреже, сата) да буде „независан“ и „поновљив“.

ААА образац и изражајна тврдња

Чврст јединични тест прати ААА структуру: Распореди (припреми — подеси улазе и зависности), Делуј (изврши — позови функцију која се тестира), потврди (потврди — упореди резултат са очекиваном вредношћу). Критична је тврдња. Најчешћа грешка коју прави вештачка интелигенција је извођење тврдње из излаза кода који се тестира — логика „шта год да код врати је истина“. Ово чини тест бесмисленим. Исправан начин је да се очекивана вредност одреди независно (из критеријума прихватљивости, израчунајте је ручно).

Пажња: Ако АИ кажете да "напише тест за ову функцију", АИ може покренути функцију и написати њен излаз као "очекиван". Овај тест пролази чак и ако је функција лажна. Уместо тога, реците „очекиване резултате израчунавате према овим правилима, не позивајте се на тренутни излаз функције“.

Исмевања, заглавци и зависности

Јединично тестирање захтева изолацију. Ако ваша функција зависи од базе података или АПИ-ја, они се замењују лажним објектима (моцк/стуб — контролисана, лажна замена за стварну зависност) у тестирању. Ово чини тест брзим, независним и поновљивим. АИ може произвести лажну инсталацију; Али чувајте се претераног исмевања: ако се све исмејете, тест ће само потврдити „шта се руга враћа“, а не стварну логику. Баланс: опонашајте спољашњи свет, извршите праву логику која се тестира.

Тестабилност и АИ

Постоји занимљива повратна информација: код који је тешко тестирати је често лоше дизајниран код. Ако АИ има проблема са писањем тестова за функцију (превише зависности, скривено глобално стање, нежељени ефекти), то је мирис дизајна. Питајући АИ „како бисте рефакторисали овај код да бисте га могли тестирати“ доводи до бољег тестирања и бољег кода.

Параметризовани тестови и разноликост података

Писање посебног теста сваки пут за верификацију истог правила са различитим улазима је и заморно и тешко за одржавање. Параметризовано тестирање — структура која узастопно покреће исту логику теста на листи улаза и очекиваних резултата — елиминише ово понављање: једно тело теста се напаја са десетинама улазних парова. АИ је веома ефикасна у изради ових табела очекиваних исхода када му дате своја правила прихватања; Конкретно, он систематски приказује граничне вредности и класе еквиваленције.

Али и овде постоји замка: АИ тежи да изведе очекиване резултате у генерисаној табели из кода који се тестира. Ова грешка је још опаснија у параметризованом тестирању, јер једна нетачна логика поништава десетине редова. Стога, увек нека колона очекиваног резултата израчунава независно у складу са правилом прихватања и ручно проверите најмање неколико редова. Такође затражите колону за опис „шта сваки ред представља“; тако да када се ред прекине, одмах видите које је стање прекинуто.

Савет: Намерно додајте „ред за замку“ у параметаризовану тестну табелу – то јест, свесно погрешно откуцајте резултат. Ако та линија не постане црвена када покренете тест, ваш тест заправо не потврђује ту ситуацију. Ово је брза лажна провера пролаза.

Слаби промпт / Јаки промпт

Слабо: „Напишите јединични тест за ову функцију.“
Јака: Напишите [језик/оквир] јединичне тестове за функцију "такЦалцулате(амоунт, рате). Правило прихватања: резултат = износ * стопа, заокружено на 2 децимале; негативан износ или стопа даје грешку; враћа 0 ако је стопа 0. Користите ААА структуру. Ручно израчунајте очекиване вредности у складу са ОВИМ правилима; не позивајте се на негативне случајеве функције, не референцирајте на тренутни велики излаз. Цовер0 заокружити на децимале. Нека назив сваког теста опише правило које верификује.

Снажан промпт; Даје правило прихватања, независна очекивана очекивана вредност, структуру и рубне случајеве. Дакле, тест постаје чувар правила, а не огледало кода.

Табела квалитета јединичног теста

симптом

Лош тест (лажно поверење)

добар тест

тврдити

Ништа или "није нулто"

Очекивана конкретна вредност

Извор очекиване вредности

Излаз функције

Правило прихватања / ручно израчунавање

зависност

Стварни ДБ/мрежа/сат

Изолован са моцк/стуб

рубни случај

Само срећан пут

граница, негативна, грешка

Када разбијете код

остаје зелена

постаје црвен

Име

тест1, тестМетход

описује правило које потврђује

Четири шаблона за копирање

1) Јединично тестирање вођено правилима:

Ваша улога: виши инжењер за тестирање софтвера. Напишите јединични тест на следећој функцији са [језиком/оквиром]: [потписом].Правила прихватања: [правила].- Користите ААА структуру.- Ручно израчунајте очекиване вредности према ОВИМ правилима; НЕМОЈТЕ референцирати тренутни излаз функције. - Покријте границу, негатив, грешку и срећан пут са одвојеним тестовима. - Нека свако име теста опише правило које верификује. - имитирајте спољне зависности; Нека стварна логика функционише.

2) Контрола отпорности на мутације:

Погледајте ове тестове јединица. Наведите 5 мањих подешавања које бих могао да урадим у коду који се тестира (а - уместо а +, а >= уместо а >, померање границе) и реците ми за сваки од њих КОЈИ ће од ових тестова постати црвени? Ако ниједан није враћен, тест је недовољан. Код + тестови: [налепи]

3) Преглед тестирања:

Зашто је тешко написати јединични тест за ову функцију? Скривена зависност, глобални статус, нуспојаве, има ли много одговорности? Предложите минимално рефакторисање како бисте га могли тестирати; не мењају понашање. Шифра: [налепи]

4) Непотпун завршетак сценарија:

Дате су следеће функције и доступни тестови. Наведите које понашање/ивични случај НИКАД није тестиран (јаз у обиму) и додајте тест за сваки. Функција+тестови: [налепи]

три мини кофера

Случај 1 — Тестирајте пресликавање кода. Програмер је дао АИ да напише тест за функцију заокруживања; 10 тестова је било зелено. У ствари, функција је заокружила у погрешном смеру, али АИ је узео очекиване вредности из излаза функције, тако да су тестови грешку сматрали „тачном“. Када су очекиване вредности ручно израчунате помоћу шаблона „вођеног правилима“, 4 теста су постала црвена и откривена је права грешка.

Случај 2 — Вредност контроле мутација. Један тим се ослањао на 45 јединичних тестова. Покушао са 20 мањих подешавања кода са "провером робусности мутације"; тестови су ухватили само њих 11. Преосталих 9 сметњи је прошло нечујно. Тим је појачао слабе тестове; Ови побољшани тестови у следећем издању су ухватили стварну грешку у прорачуну.

Случај 3 — Непроверљивост је мирис дизајна. АИ није могао да напише тестове за функцију наручивања, стално му је била потребна права база података. Шаблон „преглед тестирања“ показао је да је функција уграђена у приступ бази података. Када је ињекција зависности уклоњена, тестови су могли бити написани и код је постао чишћи.

Уобичајене грешке

  • Извођење очекиване вредности из кода. АИ прихвата излаз функције као "тачан"; тест који потврђује неисправан код.
  • Тестирајте без тврдње или са тривијалном тврдњом. „Није бацио грешку, прошао” логику; То ништа не потврђује.
  • Екстремно ругање. Ругати се свему и тестирати само оно што се ругањем враћа; права логика се не тестира.
  • Само срећан пут. Заобилажење граничних, негативних и грешака стања.
  • Не тестирати разбијањем кода. Веровати зеленом без провере мутације.
  • Игнорисање непроверљивости. Непрепознавање и поправљање лошег дизајна уместо напорног тестирања.

Укратко

Јединични тестови су најбржи и највећи слој пирамиде тестирања; Ухвати грешку у најјефтинијем тренутку. АИ је веома способан да производи јединичне тестове, али његова највећа замка је писање тестова који претпостављају да је погрешно понашање „исправно“ тако што изводе очекивану вредност из самог кода. Решење: дајте правила прихватања, ручно израчунајте очекиване вредности, примените ААА и ФИРСТ принципе, исмејавајте спољашњи свет и покрените стварну логику и тестирајте сваки тест мутацијом (разбијањем кода). Код који је тешко тестирати је дизајнерски знак који треба поправити.

Задатак апликације

Изаберите функцију која садржи пословно правило из вашег сопственог пројекта. Напишите правила прихватања и нека АИ напише тестове са шаблоном „тестирање јединица вођено правилима“; Нека очекиване вредности израчунате ручно. Затим примените „проверу робусности мутације“: направите најмање 5 малих прекида у коду и измерите колико тестова постаје црвено. Додајте нови тест за неухваћену корупцију. Пријавите колико је поремећаја ухваћено (као што је резултат мутације).

контролна листа

  • [ ] Дао сам правила прихватања и ручно израчунао очекиване вредности.
  • [ ] Уверио сам се да тестови не извуку очекивану вредност из кода.
  • [ ] Успоставио сам независно тестирање према ААА и ФИРСТ смерницама.
  • [ ] Исмевао сам спољне зависности и водио стварну логику.
  • [ ] Покрио сам ограничења, негативне и случајеве грешака.
  • [ ] Разбијањем кода (мутацијом) доказао сам да тестови заиста штите.