Прибуток:
- Здатність розпізнавати три обличчя псевдодовіри (ненапористість, самоствердження, тривіальне твердження) і застосовувати протиотрути
- Можливість використовувати тестування на мутації та оцінку мутацій як більш точний показник якості, ніж відсоток охоплення інструментом або рукою
- Можливість позиціонувати ШІ як червону команду проти тестування та шукати лазівки в тестуванні, не потрапляючи в пастку похвал
В основі цього модуля лежить повторюване попередження: зелена тестова панель, що світиться, не є доказом якості. Якщо ваші тести дають вам впевненість, вам потрібно знати, справжня ця впевненість чи фальшива. В епоху штучного інтелекту (ШІ) це питання є більш критичним, ніж будь-коли, оскільки ШІ вміє створювати плавні, плавні на вигляд, але порожні тести. Хибна впевненість — вірити, що програмне забезпечення правильне, тому що тести зелені, хоча насправді тести нічого не перевіряють — це найнебезпечніша річ, яка може статися з командою контролю якості; оскільки він приховує не те, що помилок немає, а те, що ви не бачите їх. Цей розділ об’єднує філософію валідації всього модуля в одну дисципліну: тестування ваших тестів.
Золотий стандарт для вимірювання якості тестування: тест на мутації
Найпотужніший спосіб зрозуміти, чи дійсно тест захищає чи ні, — це тестування на мутації (тестування на мутації — техніка, яка створює навмисні невеликі спотворення/мутації у вихідному коді та визначає, чи виявляють тести ці спотворення). Логіка проста: якщо ви навмисно порушуєте код (перетворюєте + на -, > на >=, істинне на хибне), хороший набір тестів має виявити це пошкодження та стати червоним. Якщо цього не відбувається, це порушення є вижилим мутантом, тому ваші тести насправді не зберігають цю поведінку.
Оцінка мутації = мутація знищена / загальна мутація. Пакет із покриттям лінії 90% може мати показник мутації 40%; Це означає, що лінії працюють, але поведінка не перевірена. Оцінка мутації є набагато більш чесним показником якості, ніж відсоток покриття.
Порада. Існують інструменти для автоматичної мутації (PIT/Pitest для Java, Stryker для JavaScript/TypeScript, Stryker.NET для .NET, mutmut для Python). Вони автоматично генерують і перевіряють сотні мутацій. Якщо у вас немає інструменту, навіть ручний метод «розбити код перевірки» є безцінним для критичних функцій.
Три обличчя псевдодовіри та її протиотрута
Форма псевдодовіри
симптом
протиотрута
Тест без твердження
Код працює, нічого не перевірено
Вірне твердження в кожному тесті; тест з мутацією
самопідтверджувальний тест
Очікується = вихід коду
Розрахуйте очікувану вартість самостійно
Тривіальне твердження
"не нуль", "повернуто 200"
Перевірте бізнес-правило/фактичний результат
Помилка високого масштабу
90% ліній, низький захист
Подивіться на оцінку мутації
Толерантність до крихких випробувань
"Знову застряг, пропусти"
Основна причина + детерміноване тестування
Використання ШІ як «червона команда»
ШІ може створювати псевдодовіру та бути потужним союзником у полюванні на неї. Використовуйте штучний інтелект як червону команду проти власних тестів: попросіть «написати код, який проходить ці тести, але є неправильним» або «знайдіть підривну роботу, яка обдурить ці тести». Якщо ШІ знаходить лазівки у ваших тестах, ці лазівки становлять реальний ризик.
Застереження: не запитуйте ШІ «Чи хороша якість мого тесту?» і прийміть відповідь «так, чудово» як гарантію. AI має тенденцію бути добрим. Замість цього поставте перед ШІ конкретне завдання: «створити помилку, яка пройшла б ці тести». Якщо він може її створити, ваші тести не бачать цієї помилки.
Еквівалентні мутації та межі оцінки
Тестування на мутації є потужним, але в ньому є заковика: деякі мутації взагалі не змінюють поведінку коду. Вони називаються еквівалентними мутаціями (еквівалентний мутант — пошкоджений код, мутація, яка дає точно такий же результат, як і оригінал). Наприклад, зміна початкового значення змінної, яка ніколи не використовується, не впливає на результат; Жоден тест не може і не повинен виявити це. Тому 100% оцінка мутації часто недосяжна на практиці і не є метою. Відсівання еквівалентних мутацій вручну є трудомістким; Тому не сприймайте оцінку мутації як абсолютну оцінку іспиту, а як чесний показник того, «чи справді мої тести захищають?»
Практичний підхід полягає в наступному: замість постійного тестування на мутації по всій базі коду, запустіть його на модулях, які містять найвищий ризик і найскладніші бізнес-правила. Перегляньте вцілілі мутації в цих модулях одну за одною; Якщо це реальний розрив, додайте тест; якщо це еквівалентна мутація, позначте її з обґрунтуванням і пропустіть. ШІ може виконати початковий скринінг для оцінки того, чи мутація, що вижила, є еквівалентною; але остаточне рішення приймаєте ви, хто знає, що робить код.
Застереження: тестування на мутації є дорогим з обчислювальної точки зору (усі відповідні тести проводяться повторно для кожної мутації). Тому поширеною та розумною стратегією є планувати це як щотижневу або передвипускну глибоку перевірку критичних модулів, а не кожне злиття.
Слабка підказка / Сильна підказка
Слабкий: "Чи достатньо моїх тестів?"
Сильно: «Діяйте як червона команда для цієї функції та набору тестів. (1) Згенеруйте 8 мутацій у коді, які можна знищити (підстановка оператора, зсув межі, інверсія умови, заміна поверненого значення). (2) Для кожної мутації вкажіть, який із наявних тестів її вловить, а який НІ. (3) Для кожної мутації, яка виживе, напишіть новий тест, який її знищить. (4) Також покажіть, чи можете ви створити код приклад, який проходить усі ці тести, але порушує бізнес-правило Code+tests: [вставити]".
Потужна підказка; Він позиціонує штучний інтелект як екзаменатора, що ламає тести, а не як машину для похвали.
Чотири шаблони, які можна копіювати
1) Ручний контроль мутації:
Згенеруйте 8 значущих мутацій (незначні навмисні порушення) для цього коду: підстановка арифметичного оператора, межа порівняння (> проти >=), логічна інверсія, повернення/постійна підстановка, пропуск умови. Для кожної мутації передбачте, який із доступних тестів її виявить чи ні. Код+тести: [вставити]
2) Знищення вцілілої мутації:
Наступний звіт про тестування мутацій містить уцілілі (невиявлені) мутації: [список/звіт]. Для кожного напишіть мінімальний тест, який знищить цю мутацію (код стане червоним, якщо його зламати таким чином). Прокоментуйте, яку поведінку підтверджує тест.
3) Червона команда — аналіз крові:
Чи можете ви написати код, який ПРОЙДЕ ВСІ наведені нижче тести, але порушить таке бізнес-правило: [бізнес-правило]. Якщо так, то яка лазівка в цих тестах це дозволяє? Додайте тест, який закриє цю лазівку. Тести: [вставити]
4) Перевірка якості тесту:
Перевірте цей набір тестів на якість. Поставте прапорці для кожного тесту: - Чи існує правдиве твердження чи це підтвердження? - Чи очікуване значення не залежить від коду? - Чи перевіряє воно бізнес-правило чи щось тривіальне? Нарешті дайте приблизну оцінку «правдивого твердження» та 3 найслабші тести. Тести: [вставити]
три міні-чохла
Випадок 1 — охоплення 92%, показник мутації 38%. Одна команда покладалася на високе покриття. Коли тест на мутації проводився за допомогою Stryker, результат становив 38%: більшість вироблених мутацій вижили. Це було доказом того, що тести не запускали лінії та не перевіряли поведінку. Команда витратила три тижні на тестування якості; Оцінка мутації зросла до 81%, і ці посилені тести в наступному випуску виявили дві реальні помилки в обчисленнях.
Випадок 2 — штучний інтелект обманув тест. За допомогою шаблону «червоної команди» експерт попросив ШІ код, який пройшов існуючі тести, але порушив правило знижки. ШІ написав код, який завжди повертав нульову знижку — і всі тести залишалися зеленими, оскільки жодні тести не перевіряли фактичне значення знижки. Помічено розрив, додано реальні твердження.
Випадок 3 — Пастка для похвал. Молодший тестувальник запитав ШІ: «Чи хороші мої тести?» і з полегшенням почув відповідь: «Дуже вичерпно». Його старший колега перевірив ті самі тести за шаблоном «аудит якості тесту»; Виявилося, що 12 з 20 тестів були декором (без assert або junk). Правильне запитання принесло правильну відповідь.
Поширені помилки
- Помилка з якістю. Покладаючись на високе покриття рядків і взагалі не дивлячись на показник мутації.
- Довіряючи похвалі ШІ. Питання "Чи хороші ваші тести?" і вважаючи позитивну відповідь гарантією.
- Отримання очікуваного значення з коду. Тести самоперевірки, які підтверджують помилковий код.
- Задовольняйтеся тривіальними твердженнями. Перевірки, які не перевіряють фактичне правило, наприклад «not null», «200 повернуто».
- Ігнорування вцілілих мутацій. Ігнорування того, що не було зафіксовано у звіті про мутації.
- Навіть не намагаючись вручну змінити критичний код. Пропуск кроку «зламати код і перевірити», якщо інструмент недоступний.
Підсумовуючи
Псевдовіра вірить, що програмне забезпечення правильне, тому що тести зелені; тоді як тести можуть нічого не підтвердити. Золотим стандартом для вимірювання цього є тестування на мутації: навмисне зламування коду та вимірювання того, чи вловлюють його тести. Оцінка мутації є набагато більш чесним показником якості, ніж відсоток покриття. Штучний інтелект створює псевдодовіру та стає потужною червоною командою в полюванні за нею — попросіть «створити помилку, яка пройшла ці тести». Перевірте свої тести: правдиве твердження, незалежне очікуване значення, перевірка бізнес-правил і знищені мутації.
Аплікаційне завдання
Імпортуйте функцію, що містить бізнес-правило та його тести, із вашого власного проекту. Якщо можливо, запустіть інструмент мутації (Stryker/Pitest/mutmut) і виміряйте оцінку мутації; Якщо інструменту немає, згенеруйте принаймні 8 мутацій за допомогою шаблону «ручний контроль мутацій» і спробуйте їх вручну. Для кожної вцілілої мутації напишіть новий тест із шаблоном «знищити вцілілу мутацію». Нарешті, за допомогою шаблону «червона команда» перевірте, чи може штучний інтелект створити код, який обдурить ваші тести. Повідомте свій початковий і кінцевий показник мутації (або спійманий/загальний коефіцієнт мутації).
контрольний список
- [ ] Я оцінив якість тесту за показником мутації, а не за охопленням.
- [ ] Я провів тестування на мутації (інструментально або вручну) для критичного коду.
- [ ] Я написав нові тести для кожної вцілілої мутації.
- [ ] Я використовував ШІ як червону команду та шукав лазівки у своїх тестах.
- [ ] Я не сприйняв похвалу ШІ «ваші тести хороші» як запевнення.
- [ ] Я перевірив, чи кожен тест перевіряє фактичне твердження, незалежне очікуване значення та бізнес-правило.