Прибыль:
- Способность распознавать три грани псевдодоверия (ненастойчивое, самоутверждающееся, тривиальное утверждение) и применять противоядия.
- Возможность использовать мутационное тестирование и оценку мутаций в качестве более точного показателя качества, чем процент покрытия с помощью инструмента или вручную.
- Способность позиционировать ИИ как красную команду против тестирования и искать лазейки в тестировании, не попадая в ловушку похвалы.
В основе этого модуля лежит постоянное предупреждение: зеленая светящаяся тестовая панель не является свидетельством качества. Если ваши тесты вселяют в вас уверенность, вам необходимо знать, настоящая эта уверенность или фальшивая. В эпоху искусственного интеллекта (ИИ) этот вопрос становится более важным, чем когда-либо, поскольку ИИ умеет проводить плавные, гладкие, но пустые тесты. Ложная уверенность — вера в то, что программное обеспечение правильное, потому что тесты зеленые, хотя на самом деле тесты ничего не проверяют — это самая опасная вещь, которая может случиться с командой контроля качества; потому что оно скрывает не то, что ошибок нет, а то, что вы не можете увидеть ошибки. Этот модуль объединяет философию проверки всего модуля в одну дисциплину: тестирование тестов.
Золотой стандарт измерения качества тестирования: мутационное тестирование.
Самый мощный способ понять, действительно ли тест защищает или нет, — это мутационное тестирование (мутационное тестирование — метод, который намеренно производит небольшие искажения/мутации в исходном коде и измеряет, обнаруживают ли тесты эти искажения). Логика проста: если вы намеренно нарушаете код (превращая + в -, > в >=, true в false), хороший набор тестов должен обнаружить это повреждение и стать красным. Если это не так, то это разрушение — выживший мутант, поэтому ваши тесты на самом деле не сохраняют это поведение.
Оценка мутации = уничтоженная мутация / полная мутация. Пакет с 90% покрытием линии может иметь показатель мутации 40%; Это указывает на то, что линии работают, но поведение не проверено. Оценка мутаций — гораздо более честная мера качества, чем процентное покрытие.
Совет: Существуют инструменты автоматического изменения (PIT/Pitest для Java, Stryker для JavaScript/TypeScript, Stryker.NET для .NET, mutmut для Python). Они автоматически генерируют и тестируют сотни мутаций. Если у вас нет инструмента, даже ручной метод «прервать проверку кода» неоценим для критически важных функций.
Три лица псевдодоверия и его противоядие
Псевдодоверительная форма
симптом
противоядие
Тест без утверждения
Код работает, ничего не проверяется
Истинное утверждение в каждом тесте; тест с мутацией
самоподтверждающий тест
Ожидаемый = вывод кода
Рассчитайте ожидаемую стоимость самостоятельно
Тривиальное утверждение
«не ноль», «возвращено 200»
Проверка бизнес-правила/фактического результата
Ошибка большого масштаба
90% линий, низкая защита
Посмотрите на оценку мутаций
Хрупкая толерантность к испытаниям
«Опять застрял, пас»
Основная причина + детерминированное тестирование
Использование ИИ в качестве «красной команды»
ИИ может как генерировать псевдодоверие, так и быть мощным союзником в его борьбе. Используйте ИИ в качестве красной команды против собственных тестов: попросите «напишите код, который пройдет эти тесты, но будет неправильным» или «найдите подрывную версию, которая обманет эти тесты». Если ИИ обнаружит лазейки в ваших тестах, эти лазейки представляют собой реальный риск.
Внимание: не спрашивайте ИИ: «Хорошее ли качество моего теста?» и примите ответ «да, отлично» как уверенность. ИИ имеет тенденцию быть добрым. Вместо этого бросьте вызов ИИ конкретной задаче: «создать ошибку, которая пройдет эти тесты». Если он может это выдать, ваши тесты не замечают этой ошибки.
Эквивалентные мутации и пределы оценки
Мутационное тестирование — это мощный инструмент, но у него есть одна загвоздка: некоторые мутации вообще не меняют поведение кода. Их называют эквивалентными мутациями (эквивалентный мутант — поврежденный код, мутация, дающая точно такой же результат, как и оригинал). Например, изменение начального значения переменной, которая никогда не используется, не влияет на выходные данные; Ни один тест не может и не должен это уловить. Таким образом, 100%-ный результат мутации на практике часто недостижим и не является целью. Отсеивание эквивалентных мутаций вручную является трудоемким процессом; Так что не воспринимайте результат мутации как абсолютный балл на экзамене, а как честный индикатор того, «действительно ли мои тесты защищают?»
Практический подход таков: вместо того, чтобы постоянно проводить мутационное тестирование по всей базе кода, запустите его на модулях, которые содержат самый высокий риск и самые сложные бизнес-правила. Изучите оставшиеся мутации в этих модулях одну за другой; Если это реальный пробел, добавьте тест; если это эквивалентная мутация, пометьте ее обоснованием и пропустите. ИИ может провести первоначальный скрининг, чтобы оценить, является ли выжившая мутация эквивалентной; но окончательное решение принимает тот, кто знает, что делает код.
Внимание: тестирование мутаций требует больших вычислительных затрат (все соответствующие тесты выполняются повторно для каждой мутации). Поэтому общепринятая и разумная стратегия — запланировать еженедельную или предварительную глубокую проверку критически важных модулей, а не каждое слияние.
Слабая подсказка / Сильная подсказка
Слабый: «Достаточно ли моих тестов?»
Сильный: «Действовать как красная команда для этой функции и набора тестов. (1) Сгенерировать 8 мутаций в коде, которые можно уничтожить (подстановка операторов, сдвиг границ, инверсия условий, подстановка возвращаемого значения). (2) Для каждой мутации укажите, какой из существующих тестов ее отловит, а какой нет. (3) Для каждой выжившей мутации напишите новый тест, который ее уничтожит. (4) Также покажите, можете ли вы создать пример кода, который пройдет все эти тесты, но нарушит бизнес-правило. Код+тесты: [вставить]"
Мощная подсказка; Он позиционирует ИИ как экзаменатора, сдающего экзамены, а не как машину для похвал.
Четыре копируемых шаблона
1) Ручной контроль мутаций:
Создайте 8 значимых мутаций (незначительные преднамеренные нарушения) для этого кода: замена арифметического оператора, предел сравнения (> vs >=), логическая инверсия, замена возврата/константы, пропуск условия. Для каждой мутации предскажите, какой из доступных тестов ее обнаружит или нет. Код+тесты: [вставить]
2) Уничтожение выжившей мутации:
Следующий отчет о тестировании мутаций содержит сохранившиеся (необнаруженные) мутации: [список/отчет]. Для каждого напишите минимальный тест, который уничтожит эту мутацию (при таком нарушении код станет красным). Прокомментируйте, какое поведение подтверждает тест.
3) Красная команда — анализ крови:
Можете ли вы написать код, который ПРОХОДИТ ВСЕ следующие тесты, но нарушает следующее бизнес-правило: [бизнес-правило]. Если да, то какая лазейка в этих тестах позволяет это сделать? Добавьте тест, который закроет эту лазейку. Тесты: [вставить]
4) Проверка качества испытаний:
Проверьте этот набор тестов на качество. Отметьте галочкой для каждого теста: — Есть ли истинное утверждение или это реквизит? — Является ли ожидаемое значение независимым, полученным из кода? — Проверяется ли оно бизнес-правилом или чем-то тривиальным? Наконец, дайте приблизительную «оценку истинного утверждения» и 3 самых слабых теста. Тесты: [вставить]
три мини-кейса
Случай 1 — Охват 92%, оценка мутаций 38%. Одна команда полагалась на высокий охват. Когда тестирование мутаций было проведено с использованием Stryker, результат составил 38%: большинство возникших мутаций сохранились. Это было доказательством того, что тесты не запускали линии и не проверяли поведение. Команда потратила три недели на тестирование качества; Показатель мутации увеличился до 81%, а в следующем выпуске эти усовершенствованные тесты выявили две реальные ошибки вычислений.
Случай 2 — ИИ обманул тест. В шаблоне «красной команды» эксперт запросил у ИИ код, который прошел существующие тесты, но нарушил правило скидок. ИИ написал код, который всегда возвращал нулевую скидку — и все тесты оставались зелеными, потому что ни один тест не проверял фактическое значение скидки. Пробел замечен, добавлены реальные утверждения.
Случай 3. Ловушка похвалы. Младший тестировщик спросил ИИ: «Хороши ли мои тесты?» и с облегчением услышал ответ: «Очень подробно». Его старший коллега проверял те же тесты с использованием шаблона «аудит качества тестирования»; Оказалось, что 12 тестов из 20 были декором (без ассертов и барахла). Правильный вопрос принес правильный ответ.
Распространенные ошибки
- Принятие возможностей за качество. Опираясь на высокое покрытие строк и вообще не обращая внимания на оценку мутаций.
- Доверять похвале ИИ. Спросить: «Хороши ли ваши анализы?» и рассматривать положительный ответ как гарантию.
- Получение ожидаемого значения из кода. Самопроверяющиеся тесты, подтверждающие ошибочный код.
- Довольствуйтесь тривиальными утверждениями. Проверки, которые не подтверждают фактическое правило, например «не null», «возвращено 200».
- Игнорирование выживших мутаций. Игнорирование того, что не было обнаружено в отчете о мутации.
- Даже не пытаясь вручную изменить критический код. Пропуск шага «взломать код и протестировать», если инструмент недоступен.
В итоге
Псевдодоверие — это вера в то, что программное обеспечение правильное, потому что тесты зеленые; тогда как тесты могут ничего не подтвердить. Золотым стандартом для измерения этого является мутационное тестирование: намеренное взлом кода и определение того, улавливают ли его тесты. Оценка мутаций — гораздо более честная мера качества, чем процентное покрытие. ИИ одновременно создает псевдодоверие и становится мощной красной командой в его поиске — попросите «создать ошибку, которая пройдет эти тесты». Протестируйте свои тесты: истинное утверждение, независимое ожидаемое значение, проверка бизнес-правил и устранение мутаций.
Задача приложения
Импортируйте функцию, содержащую бизнес-правило и его тесты, из собственного проекта. Если возможно, запустите инструмент мутации (Stryker/Pitest/mutmut) и измерьте показатель мутации; Если инструмента нет, сгенерируйте не менее 8 мутаций с помощью шаблона «ручной контроль мутаций» и попробуйте их вручную. Для каждой выжившей мутации напишите новый тест с шаблоном «убить выжившую мутацию». Наконец, с помощью шаблона «красная команда» посмотрите, сможет ли ИИ создать код, который обманет ваши тесты. Сообщите свой начальный и конечный балл мутаций (или обнаруженную/общую частоту мутаций).
контрольный список
- [ ] Я оценивал качество теста по количеству мутаций, а не по охвату.
- [ ] Я провел мутационное тестирование (с помощью инструмента или вручную) для критического кода.
- [ ] Я написал новые тесты для каждой выжившей мутации.
- [ ] Я использовал ИИ в качестве красной команды и искал лазейки в своих тестах.
- [ ] Я не воспринял похвалу ИИ «ваши тесты хорошие» как утешение.
- [ ] Я проверил, что каждый тест проверяет фактическое утверждение, независимое ожидаемое значение и бизнес-правило.