Добивки:
- Способност да се препознаат трите лица на псевдодовербата (ненаметливо, самопотврдено, тривијално тврдење) и примена на противотрови
- Способност да се користат тестови за мутации и резултат на мутации како попрецизна мерка за квалитет отколку процентот на покриеност со алатка или рака
- Способност да се позиционира вештачката интелигенција како црвен тим против тестирањето и да се ловат дупки за тестирање без да паднете во замката за пофалби
Во срцето на овој модул е постојано предупредување: зелениот светлечки тест панел не е доказ за квалитет. Ако вашите тестови ви даваат доверба, треба да знаете дали таа доверба е вистинска или лажна. Во ерата на вештачката интелигенција (ВИ), ова прашање е покритично од кога било, бидејќи вештачката интелигенција е вешта во производството на течни тестови со мазен изглед, но шупливи. Лажна доверба - верувањето дека софтверот е точен бидејќи тестовите се зелени, кога всушност тестовите не потврдуваат ништо - е најопасното нешто што може да му се случи на тимот за QA; затоа што крие не дека нема грешки, туку дека не можете да ги видите грешките. Оваа единица ја обединува филозофијата за валидација на целиот модул во една дисциплина: тестирање на вашите тестови.
Златен стандард за мерење на квалитетот на тестирањето: тестирање на мутации
Најмоќниот начин да се разбере дали тестот навистина штити или не е тестирањето на мутации (тестирање на мутации - техника која произведува намерни мали нарушувања/мутации во изворниот код и мери дали тестовите ги откриваат овие нарушувања). Логиката е едноставна: ако намерно го прекршите кодот (направете + во -, a > во >=, точно во лажно), добар тест пакет треба да ја фати таа корупција и да стане црвено. Ако не е така, тоа нарушување е преживеан мутант - така што вашите тестови всушност не го зачувуваат тоа однесување.
Резултат на мутација = убиена мутација / тотална мутација. Пакет со 90% покриеност на линија може да има резултат на мутација од 40%; Ова покажува дека линиите работат, но однесувањето не е потврдено. Резултатот на мутација е многу поискрено мерило за квалитет отколку процентуалното покривање.
Совет: Постојат алатки за автоматска мутација (PIT/Pitest за Java, Stryker за JavaScript/TypeScript, Stryker.NET за .NET, mutmut за Python). Тие автоматски генерираат и тестираат стотици мутации. Ако немате алатка, дури и рачниот метод за „пробивање на кодот“ е непроценлив за критичните функции.
Трите лица на псевдо-довербата и нејзиниот противотров
Псевдо-труст форма
симптом
противотров
Тест без тврдење
Кодот работи, ништо не е потврдено
Вистинско тврдење во секој тест; тест со мутација
самопотврден тест
Очекувано = излез на код
Пресметајте ја очекуваната вредност независно
Тривијално тврдење
„не е нула“, „вратени 200“
Потврдете го деловното правило/реалниот резултат
Заблуда со висок опсег
90% линии, ниска заштита
Погледнете го резултатот на мутација
Кревка толеранција на тестови
„Повторно заглавен, помине“
Основна причина + детерминистичко тестирање
Користење на вештачката интелигенција како „црвен тим“
Вештачката интелигенција може и да генерира псевдо-доверба и да биде моќен сојузник во нејзиното ловење. Користете вештачка интелигенција како црвен тим против вашите сопствени тестови: прашајте „напишете код што ги поминува овие тестови, но е погрешен“ или „најдете субверзија што ќе ги измами овие тестови“. Ако вештачката интелигенција најде дупки во вашите тестови, тие дупки се реални ризици.
Внимание: Не прашувајте ја вештачката интелигенција „Дали мојот квалитет на тестот е добар? и земете го одговорот „да, одлично“ како уверување. ВИ има тенденција да биде љубезна. Наместо тоа, предизвикајте ја вештачката интелигенција на конкретна задача: „произведете грешка што ги поминува овие тестови“. Ако може да го произведе, вашите тестови се слепи за таа грешка.
Еквивалентни мутации и граници на резултатот
Тестирањето за мутации е моќно, но има улов: некои мутации воопшто не го менуваат однесувањето на кодот. Овие се нарекуваат еквивалентни мутации (еквивалентен мутант - оштетен код, мутација што го произведува точно истиот резултат како оригиналот). На пример, менувањето на почетната вредност на променливата што никогаш не се користи не влијае на излезот; Ниту еден тест не може и не треба да го фати ова. Затоа, резултатот од 100% мутација е често неостварлив во пракса и не е целта. Отстранувањето на еквивалентни мутации со рака е трудоинтензивно; Затоа, немојте да го читате резултатот за мутација како апсолутен резултат на испитот, туку како искрен показател за „дали моите тестови навистина штитат?
Практичниот пристап е следниов: наместо постојано да вршите тестирање на мутации низ целата база на кодови, извршете го на модулите што содржат најголем ризик и најсложени деловни правила. Испитајте ги преживеаните мутации во овие модули еден по еден; Ако е вистинска празнина, додадете тест; ако е еквивалентна мутација, означи ја со оправдување и положи. ВИ може да изврши првичен скрининг при проценка дали преживеаната мутација е еквивалентна; но конечната одлука ја носите вие што знаете што прави кодот.
Внимание: Тестирањето за мутации е пресметковно скапо (сите релевантни тестови се повторуваат за секоја мутација). Значи, вообичаена и разумна стратегија е да се закаже како неделна или длабока проверка пред објавување за критичните модули, наместо секое спојување.
Слаб промпт / Силен промпт
Слаб: "Дали моите тестови се доволни?"
Силно: „Дејствувајте како црвен тим за оваа функција и тест пакет. (1) Генерирајте 8 мутации во кодот што може да се убие (замена на операторот, поместување на границите, инверзија на состојбата, замена на повратната вредност). (2) За секоја мутација, наведете кој од постоечките тестови ќе ја фати и кој НЕ. Пример за код што ги поминува сите овие тестови, но го прекршува деловниот правило Код+тестови: [залепи]“.
Моќен потсетник; Ја позиционира вештачката интелигенција како испитувач кој го пробива тестот, а не како машина за пофалби.
Четири шаблони за копирање
1) Рачна контрола на мутации:
Генерирајте 8 значајни мутации (мали намерни прекини) за овој код: замена на аритметички оператор, граница за споредба (> vs >=), логичка инверзија, враќање/константна замена, прескокнување на услов. За секоја мутација, предвидете кој од достапните тестови ќе ја фати или не. Код + тестови: [залепи]
2) Убивање на преживеаната мутација:
Следниот извештај од тестот за мутација содржи преживеани (нефатени) мутации: [листа/извештај]. За секој, напишете минимален тест кој ќе ја убие таа мутација (кодот ќе стане црвено кога ќе се скрши на тој начин). Коментирајте какво однесување потврдува тестот.
3) Црвен тим - тест на крвта:
Можете ли да напишете код кој ги ПОМИНЕ СИТЕ следни тестови, но го прекршува следното деловно правило: [деловно правило]. Ако е така, која дупка во овие тестови го дозволува тоа? Додадете го тестот што ќе ја затвори таа дупка. Тестови: [залепи]
4) Проверка на квалитетот на тестот:
Проверете го овој тест пакет за квалитет. Штиклирајте за секој тест:- Дали има вистинско тврдење или е реквизит?- Дали очекуваната вредност е независна, изведена од кодот?- Дали го потврдува деловното правило или нешто тривијално? Конечно, дајте проценет „оценка за вистинско тврдење“ и 3 најслаби тестови. Тестови: [залепи]
три мини футроли
Случај 1 - Покриеност 92%, резултат на мутација 38%. Еден тим се потпираше на висока покриеност. Кога беше извршено тестирање на мутации со Stryker, резултатот беше 38%: повеќето од произведените мутации преживеаја. Ова беше доказ дека тестовите не ги извршуваат линиите и не го потврдуваат однесувањето. Тимот инвестираше три недели во тестирање на квалитетот; Резултатот на мутацијата се зголеми на 81%, а овие засилени тестови во следното издание беа фатени две вистински грешки во пресметката.
Случај 2 - вештачката интелигенција го измами тестот. Со шаблон „црвен тим“, експерт побара од вештачката интелигенција код што ги поминал постоечките тестови, но го прекршил правилото за попуст. ВИ напиша код кој секогаш враќаше попуст од нула - и сите тестови останаа зелени бидејќи ниту еден тест не ја потврдуваше вистинската вредност на попустот. Виден е јаз, додадени се вистински тврдења.
Случај 3 - Замката за пофалби. Помлад тестер ја праша вештачката интелигенција: „Дали моите тестови се добри? и беше олеснет кога го слушна одговорот „Многу сеопфатен“. Неговиот постар колега ги ревидираше истите тестови користејќи го шаблонот „ревизија на квалитетот на тестот“; Се испостави дека 12 од 20 тестови биле декор (без тврдење или ѓубре). Вистинското прашање го донесе вистинскиот одговор.
Вообичаени грешки
- Грешка опсегот за квалитет. Потпирајќи се на висока покриеност на редови и воопшто не гледајќи го резултатот на мутација.
- Верување на пофалбите на вештачката интелигенција. Прашувајќи „Дали се вашите тестови добри?“ а позитивниот одговор сметајќи го како уверување.
- Изведување на очекуваната вредност од кодот. Самопроверливи тестови кои потврдуваат погрешен код.
- Бидете задоволни со тривијални тврдења. Проверки што не го потврдуваат вистинското правило, како што се „не е нула“, „вратени 200“.
- Игнорирање на преживеаните мутации. Игнорирање на она што не беше фатено во извештајот за мутација.
- Дури и не се обидува рачно да мутира критичен код. Прескокнување на чекорот „скрши го кодот и тестирај“ ако алатката не е достапна.
Сумирано
Псевдо-довербата е верување дека софтверот е точен бидејќи тестовите се зелени; додека тестовите можеби нема да потврдат ништо. Златниот стандард за мерење на ова е тестирање на мутации: намерно кршење на кодот и мерење дали тестовите го фатат. Резултатот на мутација е многу поискрено мерило за квалитет отколку процентуалното покривање. Вештачката интелигенција произведува псевдо-доверба и станува моќен црвен тим во ловот - прашајте „произведи бубачка што ги поминува овие тестови“. Тестирајте ги вашите тестови: вистинско тврдење, независна очекувана вредност, валидација на деловните правила и убиени мутации.
Задача за апликација
Увезете функција што содржи деловно правило и неговите тестови од вашиот сопствен проект. Ако е можно, активирајте алатка за мутација (Stryker/Pitest/mutmut) и измерете го резултатот на мутација; Ако нема алатка, генерирајте најмалку 8 мутации со шаблонот „мануелна контрола на мутации“ и пробајте ги рачно. За секоја преживеана мутација, напишете нов тест со шаблонот „убиј ја преживеаната мутација“. Конечно, со шемата „црвен тим“, проверете дали вештачката интелигенција може да произведе код што ги измамува вашите тестови. Пријавете го вашиот резултат на почетна и крајна мутација (или фатена/вкупна стапка на мутација).
листа за проверка
- [ ] Го оценив квалитетот на тестот според резултатот на мутација, а не по покриеност.
- [ ] Извршив тестирање на мутации (или со алатка или рачно) за критичниот код.
- [ ] Напишав нови тестови за секоја преживеана мутација.
- [ ] Ја користев вештачката интелигенција како црвен тим и барав дупки во моите тестови.
- [ ] Не ги прифатив пофалбите на вештачката интелигенција „вашите тестови се добри“ како уверување.
- [ ] Проверив дали секој тест ги потврдува вистинското тврдење, независната очекувана вредност и деловното правило.