Печалби:
- Способност за разпознаване на трите лица на псевдо-доверието (неасертивно, самоутвърждаващо се, тривиално твърдение) и прилагане на противоотрови
- Възможност за използване на тестване на мутации и резултат на мутации като по-точна мярка за качество от процентно покритие с инструмент или ръка
- Възможност за позициониране на AI като червен отбор срещу тестване и търсене на пропуски в тестването, без да попадате в капана на похвалата
В основата на този модул е едно повтарящо се предупреждение: зеленият светещ тестов панел не е доказателство за качество. Ако вашите тестове ви дават увереност, трябва да знаете дали тази увереност е истинска или фалшива. В ерата на изкуствения интелект (AI) този въпрос е по-критичен от всякога, тъй като AI е умело да произвежда течни, гладко изглеждащи, но кухи тестове. Фалшивата увереност — вярването, че софтуерът е правилен, защото тестовете са зелени, когато всъщност тестовете не потвърждават нищо — е най-опасното нещо, което може да се случи на QA екип; защото скрива не че няма грешки, а че не можете да видите грешките. Този модул обединява философията за валидиране на целия модул в една дисциплина: тестване на вашите тестове.
Златният стандарт за измерване на качеството на тестването: тестване за мутации
Най-мощният начин да разберете дали даден тест действително защитава или не е тестването на мутации (тестване на мутации – техника, която произвежда умишлени малки изкривявания/мутации в изходния код и измерва дали тестовете откриват тези изкривявания). Логиката е проста: ако умишлено нарушите кода (превръщайки + в -, > в >=, вярно в невярно), един добър тестов пакет трябва да улови тази повреда и да стане червен. Ако не стане, това прекъсване е оцелял мутант - така че вашите тестове всъщност не запазват това поведение.
Резултат на мутация = убита мутация / обща мутация. Пакет с 90% покритие на линия може да има мутационен резултат от 40%; Това показва, че линиите работят, но поведението не е проверено. Мутационният резултат е много по-честна мярка за качество от процентното покритие.
Съвет: Има автоматични инструменти за мутация (PIT/Pitest за Java, Stryker за JavaScript/TypeScript, Stryker.NET за .NET, mutmut за Python). Те автоматично генерират и тестват стотици мутации. Ако нямате инструмент, дори ръчният метод "разбийте теста на кода" е безценен за критични функции.
Трите лица на псевдодоверието и неговата противоотрова
Псевдодоверителна форма
симптом
противоотрова
Тест без твърдение
Кодът работи, нищо не е валидирано
Вярно твърдение във всеки тест; тест с мутация
самопотвърждаващ тест
Очаква се = извеждане на код
Изчислете независимо очакваната стойност
Тривиално твърдение
"не е нула", "200 върнати"
Валидирайте бизнес правило/действителен резултат
Заблуда с голям обхват
90% линии, ниска защита
Вижте резултата на мутацията
Чуплив тест толерантност
„Отново заседнал, пас“
Основна причина + детерминистично тестване
Използване на AI като „червен отбор“
AI може едновременно да генерира псевдо доверие и да бъде мощен съюзник в преследването му. Използвайте AI като червен отбор срещу вашите собствени тестове: помолете „напишете код, който преминава тези тестове, но е грешен“ или „намерете подривна дейност, която ще заблуди тези тестове“. Ако AI открие вратички във вашите тестове, тези вратички са реални рискове.
Внимание: Не питайте AI "Добро ли е качеството на моя тест?" и приемете отговора „да, чудесно“ като уверение. AI има склонност да бъде мил. Вместо това предизвикайте AI към конкретна задача: „произведете грешка, която преминава тези тестове“. Ако може да я произведе, вашите тестове са слепи за тази грешка.
Еквивалентни мутации и граници на резултата
Тестването на мутации е мощно, но има уловка: някои мутации изобщо не променят поведението на кода. Те се наричат еквивалентни мутации (еквивалентен мутант — повреден код, мутация, която дава точно същия резултат като оригинала). Например промяната на първоначалната стойност на променлива, която никога не се използва, не влияе на изхода; Никой тест не може и не трябва да хване това. Следователно 100% резултат от мутация често е непостижим на практика и не е целта. Отстраняването на еквивалентни мутации на ръка е трудоемко; Така че не четете резултата за мутация като абсолютен резултат от изпита, а като честен индикатор за това „моите тестове наистина ли защитават?“
Практическият подход е следният: вместо постоянно да провеждате тестове за мутации в цялата кодова база, стартирайте го върху модулите, които съдържат най-висок риск и най-сложни бизнес правила. Разгледайте оцелелите мутации в тези модули една по една; Ако е истинска празнина, добавете тест; ако е еквивалентна мутация, маркирайте я с обосновка и преминете. AI може да извърши първоначален скрининг за оценка дали оцелялата мутация е еквивалентна; но окончателното решение се взема от вас, които знаете какво прави кодът.
Внимание: Тестването на мутации е скъпо от изчислителна гледна точка (всички съответни тестове се провеждат повторно за всяка мутация). Така че обичайна и разумна стратегия е да се планира като седмична или предварителна задълбочена проверка за критични модули, а не всяко сливане.
Слаба подкана / Силна подкана
Слаб: „Моите тестове достатъчни ли са?“
Силно: „Действайте като червен отбор за тази функция и пакет от тестове. (1) Генерирайте 8 мутации в кода, които могат да бъдат унищожени (замяна на оператор, изместване на граница, инверсия на условие, заместване на върната стойност). (2) За всяка мутация посочете кой от съществуващите тестове ще я улови и кой НЕ. (3) За всяка мутация, която оцелее, напишете нов тест, който ще я убие. (4) Покажете също дали можете да създадете код пример, който преминава всички тези тестове, но нарушава бизнес правилото Code+tests: [поставяне]".
Мощна подсказка; Той позиционира изкуствения интелект като проверяващ за пробиване на тестове, а не като машина за похвали.
Четири копируеми шаблона
1) Ръчен контрол на мутациите:
Генерирайте 8 значими мутации (незначителни умишлени прекъсвания) за този код: заместване на аритметичен оператор, ограничение за сравнение (> срещу >=), логическа инверсия, връщане/постоянно заместване, пропускане на условие. За всяка мутация предскажете кой от наличните тестове ще я улови или не. Код+тестове: [поставяне]
2) Унищожаване на оцелялата мутация:
Следният доклад от тест за мутация съдържа оцелели (неуловени) мутации: [списък/отчет]. За всеки напишете минимален тест, който ще убие тази мутация (кодът ще стане червен, когато бъде разбит по този начин). Коментирайте какво поведение потвърждава тестът.
3) Червен отбор - кръвен тест:
Можете ли да напишете код, който ПРЕМИНА ВСИЧКИ от следните тестове, но нарушава следното бизнес правило: [бизнес правило]. Ако е така, каква вратичка в тези тестове позволява това? Добавете теста, който ще затвори тази вратичка. Тестове: [поставете]
4) Проверка на качеството на теста:
Проверете този набор от тестове за качество. Отбележете за всеки тест: - Има ли вярно твърдение или е опора? - Очакваната стойност независима ли е, извлечена от код? - Проверява ли бизнес правилото или нещо тривиално? Накрая дайте приблизителна оценка за "вярно твърдение" и 3-те най-слаби теста. Тестове: [поставете]
три мини калъфа
Случай 1 — Покритие 92%, мутационен резултат 38%. Единият екип разчиташе на високо покритие. Когато тестът за мутации беше проведен със Stryker, резултатът беше 38%: повечето от произведените мутации оцеляха. Това беше доказателство, че тестовете не изпълняват линиите и не проверяват поведението. Екипът инвестира три седмици в тестване на качеството; Резултатът на мутацията се увеличи до 81% и две реални грешки в изчисленията бяха уловени от тези подобрени тестове в следващото издание.
Случай 2 — AI измами теста. С шаблон „червен отбор“ експерт поиска от AI код, който премина съществуващите тестове, но наруши правилото за отстъпка. AI написа код, който винаги връщаше отстъпка от нула - и всички тестове останаха зелени, защото нито един тест не потвърди действителната стойност на отстъпката. Вижда се пропуск, добавени са реални твърдения.
Случай 3 — Капанът на похвалата. Младши тестер попита AI: „Моите тестове добри ли са?“ и с облекчение чу отговора „Много изчерпателно“. Неговият старши колега имаше същите тестове, одитирани с помощта на шаблона „одит на качеството на теста“; Оказа се, че 12 от 20 теста са декор (без assert или junk). Правилният въпрос донесе правилния отговор.
Често срещани грешки
- Погрешно обхват за качество. Разчитайки на високо покритие на редовете и изобщо не гледайки резултата на мутацията.
- Доверявайки се на похвалата на AI. Питане "Добри ли са вашите тестове?" и разглеждане на положителния отговор като уверение.
- Извличане на очакваната стойност от код. Самопроверяващи се тестове, които потвърждават грешен код.
- Задоволете се с тривиални твърдения. Проверки, които не потвърждават действителното правило, като например „not null“, „200 върнати“.
- Игнориране на оцелелите мутации. Игнориране на това, което не е уловено в доклада за мутация.
- Дори не се опитвате ръчно да промените критичния код. Пропускане на стъпката „разбийте кода и тествайте“, ако инструментът не е наличен.
В обобщение
Псевдо-доверието вярва, че софтуерът е правилен, защото тестовете са зелени; като има предвид, че тестовете може да не потвърдят нищо. Златният стандарт за измерване на това е тестване на мутации: умишлено разбиване на кода и измерване дали тестовете го улавят. Мутационният резултат е много по-честна мярка за качество от процентното покритие. AI едновременно произвежда псевдо-доверие и се превръща в мощен червен екип в преследването му – попитайте „произведете грешка, която преминава тези тестове“. Тествайте вашите тестове: вярно твърдение, независима очаквана стойност, валидиране на бизнес правило и убити мутации.
Задача за приложение
Импортирайте функция, съдържаща бизнес правило и неговите тестове от вашия собствен проект. Ако е възможно, стартирайте инструмент за мутация (Stryker/Pitest/mutmut) и измерете резултата за мутация; Ако няма инструмент, генерирайте поне 8 мутации с шаблона „ръчен контрол на мутациите“ и ги опитайте ръчно. За всяка оцеляла мутация напишете нов тест с шаблона „унищожи оцелялата мутация“. И накрая, с модела „червен отбор“, вижте дали AI може да произведе код, който заблуждава вашите тестове. Докладвайте своя начален и краен резултат на мутация (или процент на уловена/обща мутация).
контролен списък
- [ ] Оцених качеството на теста по резултат на мутация, а не по покритие.
- [ ] Проведох тестване на мутации (с инструмент или ръчно) за критичен код.
- [ ] Написах нови тестове за всяка оцеляла мутация.
- [ ] Използвах AI като червен отбор и потърсих вратички в моите тестове.
- [ ] Не приех похвалата на AI „тестовете ви са добри“ като успокоение.
- [ ] Проверих дали всеки тест проверява действителното твърдение, независимата очаквана стойност и бизнес правилото.