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