Сразу честно, чтобы вы понимали, с кем имеете дело: я из тех душнил, которые закатывают глаза, когда в сотый раз слышат «а давайте это все сделает нейросеть». Я видел слишком много красивых демок, где ИИ за минуту генерит сотню тест-кейсов – из которых добрая половина про кнопки, которых в продукте нет, а вторая половина дублирует друг друга разными словами, не говоря уже о глубине тестирования бизнес-логики.
Поэтому когда у нас возникла задача как следует протестировать внутренний калькулятор трудозатрат, и я взялся ее решать, то открыл инструмент, проскроллил его вниз… и понял, что мне предстоит либо несколько недель монотонного ада, либо надо что-то придумывать.
Спойлер: придумал. ИИ реально помог, но не так, как обещают на конференциях. Ниже – подробный разбор: какие инструменты и модели я использовал, какие промпты сработали, как рисовалась матрица покрытия и, самое главное, как побороть галлюцинации в расчётах. Ведь в калькуляторе это не смешная оплошность, а неправильное число, на котором кто‑то потом посчитает стоимость проекта.
Да, порой я использовал избыточные методы – тратил больше времени и сил, чем требовалось. Однако, задумав эту статью, я решил сохранить эти примеры: они наглядно показывают, какой подход необходим для работы с критически важными и сложными продуктами.
Знакомьтесь, монстр
Калькулятор – наш инструмент для оценки трудозатрат и стоимости тестирования. Вы вводите параметры будущего проекта – а он выдаёт оценку часов, рекомендуемый состав команды, сроки и итоговую стоимость. Это не таблица в Excel, а полноценный веб‑калькулятор: интерфейс на HTML, а вся математика – в движке на JavaScript. Выглядит он безобидно – ровно до того момента, пока не заглянешь «под капот».
А под капотом, если измерять в цифрах:
6 видов тестирования в отдельных модулях – ручное функциональное, автоматизация, нагрузочное, юзабилити, интеграционное и ИБ. Плюс седьмой модуль – сводка, который собирает их все вместе;
79 входных параметров – то, что заполняет человек: числа, выпадающие списки с коэффициентами, переключатели, слайдеры рисков;
около 70 расчетных формул, многие из которых ссылаются друг на друга;
карта из 12 ролевых ставок, из которых в каждом модуле собирается своя смешанная ставка;
сквозная зависимость через сводку: каждый модуль считается сам, а потом итог снова собирается с накладными, запасом на риски и НДС – дернул одну вводную, поехало половина калькулятора.
Чтобы вы прочувствовали боль, вот несколько живых примеров логики прямо из движка.
Ручное: трудозатраты на прогон – цепочка из пяти множителей
execMin = кейсы × мин_на_кейс × сложность × прогоны × платформы
Автоматизация: точка окупаемости
окупаемость_мес = (разработка + фреймворк) / (экономия − поддержка)
// знаменатель ≤ 0 → «не окупается» (деление на ~ноль)
Сводка: накладные и резерв на риски
деньги: итог = (база + база×overhead) × (1 + резерв) × (1 + НДС)
часы: итог = база + база×overhead + база×резерв
Видите, в чем засада? При ручном расчёте перемножаются пять коэффициентов: ошибешься в одном – и порядок величины незаметно изменится. В автоматизации точка окупаемости рассчитывается как «экономия минус поддержка». Но это значение может оказаться нулевым или отрицательным – получается классическое деление на ноль, которое скрыто за бизнес‑логикой. А в сводке накладные и резерв в деньгах накручиваются каскадом (резерв считается уже от суммы с накладными), а в часах – линейно от базы. То есть для денег и часов используются разные формулы. Любая такая неточность незаметно влияет на итоговую стоимость – и никто этого не заметит, потому что число выглядит вполне корректным.
Почему вручную это ад?
У тестирования расчетных систем есть фундаментальная проблема, ее красиво называют – проблема оракула. Чтобы проверить, что калькулятор посчитал 1 234,5 правильно, мне нужен эталон – независимо посчитанное «правильное» число. А чтобы его получить, надо… самому пройти всю цепочку формул руками. Для каждого тест-кейса. И так – пока не покроешь все классы входных значений, все границы, все ветвления и все взаимодействия параметров.
Я прикинул ручную оценку для такого объема – вот она по этапам:
Этап | Часы | Почему так долго? |
Разбор формул и граф зависимостей | 12 | ~70 формул в шести модулях, у каждой надо понять на какие другие формулы или результаты она влияет |
Тест-дизайн (чек-лист) | 38 | Классы эквивалентности, границы, попарное тестирование по 79 параметрам, да еще и ветвления методов – это больше тысячи проверок |
Расчет эталонов (оракул) | 42 | Самое дорогое: вручную рассчитать ожидаемое число для каждого кейса |
Прогон и сравнение | 18 | Заполнить поля, снять результат, сравнить с эталоном – и так по всем модулям и сводке |
Триаж и документация | 3-12 | Разобрать расхождения, оформить отчет |
Итого | ≈ 122 | Примерно 3 рабочие недели одного инженера |
Три недели. На один калькулятор. При этом 42 часа из 122 – это тупая, выматывающая арифметика, на которой живой человек к концу дня начинает ошибаться сам, и тогда уже непонятно, кто наврал – калькулятор или уставший тестировщик. Такая задача запросто может вызвать выгорание, желание бросить IT, уехать в далёкую деревню разводить хозяйство и меланхолично пить чай на веранде под Radiohead.
Почему эта задача неожиданно подошла для ИИ, но с одним жирным нюансом?
А теперь смотрите, что получается. Логика калькулятора формализуема и детерминирована: одни и те же входы всегда дают один и тот же выход. Вариаций много, но они однотипные. Нужно генерить кучу комбинаций по понятным правилам и аккуратно считать арифметику с выкладками. Это ровно те задачи, где языковые модели сильны: размножить вариации по методике, расписать пошаговый расчет, разложить формулу на шаги.
Оговорка, ради которой написана половина этой статьи: ИИ галлюцинирует, как вы уже все знаете. И если в генерации текста галлюцинация бросается в глаза, то в расчетах она – самый опасный класс ошибки. Модель уверенно выдает правдоподобное, но неверное число. Никаких красных флагов. Поэтому вся методика ниже построена вокруг одного железобетонного принципа:
Одна модель – не источник истины. Никогда не верьте одной модели на слово. Истина рождается там, где сходятся несколько независимых способов посчитать одно и то же.
Алгоритм тестирования калькулятора с помощью ИИ
Прежде чем погружаться в детали, вот общая схема – чтобы у вас перед глазами был пол порядок действий:
Выгрузка формул и построение графа зависимостей.
Декомпозиция на тестируемые единицы: формула, модуль, сквозной сценарий.
ИИ-генерация чек-листа (тест-дизайн): классы эквивалентности, границы, негативные и тд.
Матрица покрытия и ревью ее инженером – ищем дыры.
Независимый оракул: считаем эталоны «вслепую» тремя способами.
Прогон реального калькулятора и сравнение с эталоном.
Триаж расхождений: баг калькулятора / ошибка оракула / галлюцинация.
Стек инструментов
Инструмент/модель | Роль в процессе |
Claude (старшая модель, Opus Х.Х) | Основной «рассуждающий» движок: разбор формул, генерация чек-листа, расчет эталонов с пошаговой арифметикой |
Модель другого вендора (у меня был Gemini) | Перекрестный расчет эталонов – второй независимый «свидетель» |
Python | Независимая референс-реализация формул на коде – третий «свидетель» и главный барьер от галлюцинаций |
Playwright (headless-браузер) | Прогон самого калькулятора: заполняем поля вводными из кейса, снимаем фактические выходные значения. Для эффективности можно было все прогнать на уровне unit-тестов, но как выше говорил, мне хотелось написать статью, потому я применил порой избыточные методы |
Pytest + git | Сборка всего в регрессионный набор, который гоняется по кнопке |
Pairwise-инструмент | Старая добрая комбинаторика |
Шаг 0. Выгрузка формул и граф зависимостей
Сначала надо понять, что мы тестируем, а для этого нужна карта. Поскольку вся математика лежит в JS-движке, скрипт на Python прошелся по коду и выгрузил каждую формулу: какому модулю она принадлежит, какие входные поля читает и в какое выходное значение пишет. На основе этих связей получился граф зависимостей. Он показывает, какие узлы – входные, какие – промежуточные, а какие – итоговые, а также как они связаны между собой. Особенно заметно это в сводке: туда стекаются данные из всех шести модулей.
После этого я подключил модель – не для расчётов, а чтобы она помогала объяснять. Вот первый промпт:
Роль: старший QA-инженер по тестированию расчетных систем.
На входе – выгрузка формул из кода калькулятора:
[модуль | входные поля | формула | выходное поле].
Твоя задача – НЕ считать значения, а:
1) описать простыми словами, что вычисляет каждая формула;
2) перечислить, от каких ВХОДНЫХ параметров она зависит;
3) пометить формулы, где возможны граничные эффекты:
деление, округление, ветвления ЕСЛИ, перемножение коэффициентов.
Формат: таблица [Формула | Назначение | Входы | Тип риска].
Если формула неоднозначна – поставь «????» и НЕ выдумывай смысл.
Данные: <выгрузка>
Обратите внимание на две вещи в промте. Первое – явный запрет считать («НЕ считать значения»): на этом этапе нам нужна семантика, а не арифметика, и любое число от модели здесь было бы лишним поводом для ошибки. Второе – разрешение сказать «не знаю» («поставь ???? и НЕ выдумывай»). Это простое правило, но именно его отсутствие часто приводит к «галлюцинациям»: модель считает, что обязана дать ответ, и начинает его придумывать.
Шаг 1–3. Декомпозиция и генерация чек-листа
Дальше я разбил калькулятор на три уровня тестирования: формула (проверяем каждую в изоляции), модуль (целый вид тестирования – например, весь расчет автоматизации с его точкой окупаемости), и сквозной сценарий (реалистичный проект целиком: заполняем несколько модулей и смотрим, как сводка собирает итог с накладными, резервом и НДС). На каждый уровень – своя пачка проверок.
И вот тут ИИ впервые делает много пользы. Промт на тест-дизайн:
Роль: ведущий тест-аналитик.
На входе – формула, ее входные параметры, диапазоны и классы значений.
Сгенерируй чек-лист проверок строго по методикам:
(1) классы эквивалентности;
(2) анализ граничных значений: min-1, min, min+1, типовое,
max-1, max, max+1, за границей;
(3) негативные / невалидные значения.
Для каждой проверки выведи:
ID | все входные значения | какой класс/границу проверяем |
ожидаемое ПОВЕДЕНИЕ СЛОВАМИ (НЕ число!) | приоритет П1-П3
Приоритет – по риску искажения итоговой стоимости и срока.
НЕ придумывай параметров, которых нет во вводных.
Формат: CSV.
Параметры: <...>
Ключевой нюанс – «ожидаемое поведение словами, НЕ число». На этапе дизайна мы фиксируем что должно произойти («при росте сложности трудозатраты не уменьшаются», «при количественной юзабилити система не должна молча подменять введенное число респондентов», «при нулевой экономии автоматизация должна честно показать „не окупается“, а не упасть в ошибку»), но не конкретные цифры. Цифры – это работа оракула, и считать их будем отдельно и независимо. Если смешать дизайн и расчет в одном промте, модель начнет «подгонять» дизайн под удобные ей числа. Разделяй и властвуй.
На выходе после нескольких итераций и моего ревью получился чек-лист на 1 150 проверок. Звучит много, но это ровно тот объем, который вручную я бы расписывал те самые 38 часов. ИИ сгенерил черновик быстро, а мои руки понадобились на вычитку и выкидывание дублей.
Шаг 4. Матрица покрытия – и где в ней дыры
Чек-лист без матрицы покрытия – это просто куча строк, в которой невозможно увидеть пробелы. Поэтому следующим промтом я попросил модель свести все в матрицу: по строкам – узлы расчета (из графа зависимостей), по столбцам – виды проверок.
Построй матрицу покрытия.
Строки – узлы расчета (формулы) из графа зависимостей.
Столбцы – виды проверок:
Классы эквивалентности | Граничные |
Негативные | Инвариант/свойство | Якорный кейс.
В ячейке – количество проверок данного вида + список их ID.
В конце – строка ИТОГО и ПОДСВЕТИ узлы, где в каком-либо
столбце стоит 0 (это пробел покрытия – туда смотрим в первую очередь).
Формат: Markdown-таблица.
Данные: <чек-лист CSV>
Первая же матрица подсветила три узла, где в столбце «Негативные» стоял ноль – модель банально забыла про невалидные входы для них. Я вернул их в работу отдельным промтом. Вот, кстати, почему матрицу строит ИИ, а читает человек: модель отлично сводит данные в таблицу, но решение «вот это дыра, ее закрываем» – это инженерное суждение, и оно остается за мной.
Шаг 5. Независимый оракул
Вот мы и подошли к самому интересному. Эталонное значение для каждого кейса я считал вслепую и тремя способами – об этом подробно в следующем разделе. Здесь покажу промт, которым модель считает эталон. Модель не видит фактический результат калькулятора в момент расчета. Иначе она просто перепишет его и «подтвердит» любую ошибку.
Роль: расчетчик-аудитор.
Тебе даны: формула и КОНКРЕТНЫЙ
набор входных значений. Фактический результат калькулятора
тебе НЕ показан и показан не будет.
Посчитай ожидаемый результат ВРУЧНУЮ, показывая КАЖДЫЙ
промежуточный шаг и число.
Запрещено:
- округлять раньше, чем это указано в формуле;
- пропускать шаги;
- подгонять под «красивый» ответ.
Если есть ветвление ЕСЛИ – явно укажи активную ветку и почему.
Выведи:
- пошаговый расчет (текст);
- финальное число;
- отдельным JSON-блоком ВСЕ промежуточные значения
(для автоматической сверки кодом).
Если данных не хватает – напиши «НЕДОСТАТОЧНО ДАННЫХ», не угадывай.
Формула: <...> Входы: <...>
Тот самый JSON с промежуточными значениями – не для красоты. Он нужен, чтобы код потом перепроверил не только финальное число, но и каждый шаг вычисления. Если модель «угадала» правильный итог через неправильные промежуточные шаги (а так бывает), мы это поймаем. И наоборот: если модель выдала итог вообще без выкладок – такой ответ я отбраковывал автоматически. Нет выкладок – нет доверия.
Шаг 6-7. Прогон калькулятора и триаж расхождений
Фактический результат снимался так: headless-браузер открывал калькулятор, скрипт заполнял поля вводными из кейса, дожидался пересчета и считывал значения выходных полей – по всем модулям и из сводки. Получалось три эталона (Claude, Gemini, Python-реализация) и одно фактическое число от калькулятора. Дальше – сравнение.
Когда что-то расходилось, я не давал модели «проголосовать» за правильный ответ – голосование плодит уверенную чушь. Вместо этого – промт на разбор:
Дано: формула, входы и четыре числа:
Дано: формула, входы и четыре числа:
- эталон_1 (Claude),
- эталон_2 (Gemini),
- эталон_3 (Python-оракул),
- фактический результат калькулятора.
Они расходятся. НЕ выбирай правильный голосованием.
Вместо этого:
1) разложи каждый расчет по шагам;
2) найди ПЕРВЫЙ шаг, на котором числа разошлись;
3) назови вероятную причину именно этого расхождения:
ошибка округления / двойной учет коэффициента /
неверная ветка ЕСЛИ / неверный порядок операций / галлюцинация.
Гипотеза: это баг калькулятора, ошибка оракула или фантазия модели?
Не делай утверждений без указания КОНКРЕТНОГО шага.
Требование «найди первый шаг расхождения» превращает расплывчатое «тут что-то не так» в точную координату: вот здесь, на умножении базы на коэффициент накладных в сводке, два расчета разъехались. Дальше уже дело техники – посмотреть глазами, кто прав.
Как я справился с ИИ-галлюцинациями?
Это раздел, ради которого, если честно, и стоило писать статью. Потому что «прогнать тесты через ИИ» умеют все. А вот сделать так, чтобы результатам можно было доверять, – это и есть инженерия. Вот вся моя оборона от галлюцинаций, по слоям.
1. Три независимых свидетеля
Каждый эталон считается тремя независимыми способами: Claude, Gemini и Python-оракул. Если все три сошлись – эталону можно верить (вероятность, что три разных механизма совершат одну и ту же ошибку, мала). Если разошлись – кейс уходит в ручной разбор. Я зову это «правилом трех свидетелей»: одному свидетелю в суде не верят, а трое независимых, давших одинаковые показания, – это уже доказательство. На всякий случай оговорюсь, что если вы считаете данные от которых зависят жизни, то здесь справедливо стоит отметить, что несмотря на то что модели разные, обучались они на терабайтах тех же данных, поэтому в глубокой теории и с массой оговорок, но у разных моделей может случиться коррелированная ошибка. Но мы здесь никого в космос не запускаем, потому не уходим в дебри.
2. Истину считает код, а не модель
Третий свидетель – особенный. Python-оракул – это обычный детерминированный код, который физически не умеет галлюцинировать. Именно он, а не ИИ, является главным барьером. Роль моделей – генерировать тест-дизайн и гипотезы и давать человекочитаемые выкладки; роль кода – быть неподкупным арбитром.
3. Расчет «вслепую»
Ни одна модель при генерации эталона не видит фактического результата калькулятора – это принципиально важно. Если показать модели «правильный ответ», она с лёгкостью его подтвердит, даже если он ошибочен.
4. Обязательная пошаговая арифметика и ее автосверка
Модель должна показывать каждый промежуточный шаг и выгружать их в JSON. Затем код проверяет не только итоговый результат, но и все промежуточные вычисления. Так удаётся выявить ситуации, когда итоговый ответ верный, а путь к нему – ошибочный.
Ответы без подробных выкладок автоматически отбраковываются: галлюцинации моделей обычно выглядят гладко – они выдают итог, но не могут внятно объяснить, как его получили.
5. Инварианты
Есть свойства, которые должны выполняться при любых входных числах. Их я проверял через hypothesis (например, неотрицательность или монотонность).
6. Якорные кейсы
17 кейсов я посчитал заранее сам, руками, еще до того, как подпускал к делу ИИ. Это «якоря»: если модель или оракул не воспроизводят якорь – стоп, разбираемся, что сломалось в самом конвейере проверки, прежде чем доверять ему остальные примерно 1 150 кейсов. Своего рода калибровка по эталонному образцу.
7. Температура 0
Расчетные промты гонялись при температуре 0. Кроме того, ключевые кейсы я проверял несколько раз: если ответ модели меняется от прогона к прогону – это явный признак того, что она выдаёт недостоверные данные, а не проводит корректные вычисления.
8. Сверка размерностей
Скучный, но полезный слой: код проверял единицы измерения – часы не путаются с днями, проценты лежат в [0; 1] или [0; 100] согласованно. Часть «расхождений» оказались именно такими: эталон и калькулятор считали правильно, но в разных единицах.
Суть всей обороны в одном предложении: ИИ имеет право предлагать ответ, но не имеет права быть его единственным подтверждением.
Что в итоге нашлось?
Из примерно 1 150 проверок калькулятор споткнулся на 23 дефектах: из которых 5 критичных, 9 средних и 9 косметических. Критичные – те, что тихо искажали итоговую стоимость или срок. Самое ценное, что нашлись именно тихие дефекты. Калькулятор не падал, не выдавал ошибок, он просто считал чуть-чуть не то. Такое вручную ловится хуже всего: глаз замыливается, число «правдоподобное», идешь дальше.
Сколько времени сэкономил?
Если коротко: примерно 122 часа вручную против около 27 часов с ИИ.
ИИ не заменил инженера. Он забрал у инженера бОльшую часть рутины и оставил ему 27 часов работы, ради которой инженера, собственно, и нанимают.
В каких задачах ИИ оказался полезен, а в каких только мешал?
По итогам – карта сильных и слабых сторон, без розовых очков.
ИИ можно доверить:
генерить вариации по методике – классы эквивалентности, границы (это его стихия, хотя в случае последнего для пущей надежности можно использовать профильные инструменты);
расписывать пошаговую арифметику с выкладками;
сводить данные в матрицы и таблицы;
формулировать гипотезы о причине расхождения.
ИИ нельзя доверять:
быть единственным источником истины в расчетах (он уверенно врет);
решать, что является дырой в покрытии, а что нет (это инженерное суждение);
«голосовать» за правильный ответ при расхождении;
работать без независимой проверки.
Грубо говоря, ИИ – это гениальный, очень быстрый, но порой склонный привирать стажёр. Доверь ему рутинные задачи и проверяй результаты – будет золото. Оставь без присмотра принимать решения – жди проблем: он с невероятной уверенностью будет преподносить свои решения как единственно верные.
Если у вас тоже живет такой монстр
Расчетные системы – отдельная боль тестирования: их страшно трогать, потому что все связано со всем, и баги в них тихие и дорогие. Мы часто такое тестируем: биллинги, тарификаторы, скоринг, прогнозные калькуляторы, финансовые и актуарные модели и тд. Вот такая связка позволяет получать точный результат, а не ощущение, что вроде протестировали и как-бы все должно быть правильно:
Строгая методика тест-дизайна + аккуратное применение ИИ + независимая проверка кодом
Если вы интересуетесь темой тестирования, управления, разработки и улучшения качества IT‑продуктов – у нас есть телеграм‑канал с полезным контентом. Там мы публикуем разные гайды, чек‑листы, экспертные статьи. Заходите, если для вас это актуально. И пишите в комментариях о своём опыте в тестировании с помощью ИИ. Очень интересно.
