ИИ в тестировании: ускорение проверки калькулятора с 3 недель до 3 дней

Делимся ещё одним кейсом от нашего ведущего эксперта Олега – на этот раз про тестирование расчётного калькулятора с помощью ИИ. Напомним, в прошлой статье Олег честно рассказал, как ему удалось добиться качества и стабильности системы, которую он навайбкодил без полноценного ТЗ и команды разработки. А сейчас – новый разбор: читайте, где прячутся ошибки в вычислениях и как их ловить с помощью ИИ.

Скажу прямо: я не верил в то, что можно адекватно протестировать расчётную систему с помощью ИИ, потому что на практике нейросеть за минуту выдаёт сотню тест‑кейсов, а толку от этого мало. Но жизнь сама меня подтолкнула к такому эксперименту: нужно было протестировать калькулятор трудозатрат, и когда я прикинул объём задач, то с ужасом понял, что мне придётся неделями делать однообразную работу. Решил рискнуть и попробовать применить ИИ не как волшебную кнопку, а как помощника. Результат оказался настолько интересным, что я решил написать об этом статью.

Если коротко, то примерно 122 часа вручную у меня бы ушло на то, что я сделал за 27 часов с ИИ. Рассказываю, какие инструменты и промпты реально сработали, как я строил матрицу покрытия и, самое важное, как не дать ошибкам просочиться в расчёты.

Постановка задачи

Мне предстояло протестировать калькулятор для оценки трудозатрат и стоимости тестирования. Вот как он работает: вводишь параметры будущего проекта – он выдаёт оценку часов, состав команды, сроки и итоговую стоимость. Это не Excel‑таблица, а полноценный веб‑калькулятор: интерфейс на HTML, математика – в движке на JavaScript. 

Выглядит просто, но «под капотом» всё куда сложнее.

• 6 видов тестирования в отдельных модулях – ручное функциональное, автоматизация, нагрузочное, юзабилити, интеграционное и ИБ. Плюс седьмой собирает всё вместе;
• 79 входных параметров: числа, выпадающие списки с коэффициентами, переключатели, слайдеры рисков;
• 70 расчетных формул, многие из которых ссылаются друг на друга;
• карта из 12 ролевых ставок, из которых собирается смешанная ставка помодульно;
• сквозная зависимость через сводку: подсчёты из модулей собираются в итог с накладными, запасом на риски и НДС. 

Главная опасность: дернул одну вводную, поехало половина калькулятора. Вот несколько примеров логики прямо из движка. Прочувствуйте боль.

Ручное: трудозатраты на прогон — цепочка из пяти множителей
  execMin = кейсы × мин_на_кейс × сложность × прогоны × платформы
 
Автоматизация: точка окупаемости
  окупаемость_мес = (разработка + фреймворк) / (экономия − поддержка)
  // знаменатель ≤ 0  →  «не окупается» (деление на ~ноль)
 
Сводка: накладные и резерв на риски
  деньги:  итог = (база + база×overhead) × (1 + резерв) × (1 + НДС)
  часы:    итог = база + база×overhead + база×резерв

Сложность в том, что при ручном расчёте перемножаются пять коэффициентов: ошибка в одном незаметно меняет весь результат. В автоматизации точка окупаемости считается как «экономия минус поддержка». Но результат может быть нулевым или отрицательным – и получится деление на ноль, спрятанное внутри бизнес‑логики.

Ещё нюанс: в сводке накладные и резерв считаются по‑разному. Для денег – каскадом (резерв берут уже от суммы с накладными), а для часов – линейно от базы. Из‑за этого любая неточность влияет на итоговую стоимость. При этом число выглядит корректным – и ошибку легко не заметить.

Почему тестировать такую систему вручную – это ад?

В тестировании расчётных систем есть понятие «проблема оракула». Чтобы проверить, что калькулятор верно посчитал 1 234,5, нужен эталон – независимо полученное «правильное» число. А чтобы получить такое, придётся вручную пройти всю цепочку формул. И так – для каждого тест‑кейса, пока не покроешь все варианты входных значений, границы, ветвления и взаимодействия параметров.

Я сел и прикинул ручную оценку для такого объема. Вот она по этапам:

Три недели на один калькулятор! При этом 42 часа из 122 – однообразная выматывающая рутина с высокой вероятностью ошибок. Потом поди разберись, кто наврал – калькулятор или уставший тестировщик.

Почему я решил применить ИИ для решения этой задачи?

Смотрите, какая картина получается. Логика калькулятора детерминирована: одинаковые входы дают одинаковый выход. Много однотипных вариаций. Важно сгенерировать массу комбинаций по чётким правилам и аккуратно просчитать арифметику. Именно в таких задачах языковые модели полезны.

Важная оговорка: ИИ склонен к галлюцинациям – и в расчётах это опасно. Модель уверенно выдаёт правдоподобное, но неверное число, и заметить ошибку непросто. Поэтому главный принцип методики такой: не верить одной модели. Истина появляется там, где совпадают несколько независимых способов посчитать одно и то же. 

Алгоритм тестирования калькулятора с помощью ИИ

Прежде чем погружаться в детали, вот общий порядок действий.

1. Выгрузка формул и построение графа зависимостей.
2. Декомпозиция на тестируемые единицы: формула, модуль, сквозной сценарий.
3. ИИ-генерация чек-листа (тест-дизайн): классы эквивалентности, границы, негативные и тд.
4. Матрица покрытия и ревью – ищем дыры.
5. Независимый оракул: считаем эталоны «вслепую» тремя способами.
6. Прогон реального калькулятора и сравнение с эталоном.
7. Триаж расхождений (баг калькулятора, ошибка оракула, галлюцинация).

Стек инструментов

Примеры промптов, которые я использовал

Выгрузка формул и граф зависимостей

Сперва нужно понять, что тестируем, – для этого нужна карта. Поскольку математика лежит в JS‑движке, скрипт на Python проходится по коду и выгружает все формулы: к какому модулю они относятся, какие входные поля читают и в какое выходное значение пишут. Так получется граф зависимостей: он показывает, какие узлы – входные, промежуточные и итоговые, а также как они связаны. Особенно это заметно в сводке – туда стекаются данные из всех шести модулей.

И я подключил модель – не для расчётов, а чтобы она помогала объяснять.

Вот первый промпт:

Роль: старший QA-инженер по тестированию расчетных систем.
На входе — выгрузка формул из кода калькулятора:
  [модуль | входные поля | формула | выходное поле].
Твоя задача — НЕ считать значения, а:
  1) описать простыми словами, что вычисляет каждая формула;
  2) перечислить, от каких ВХОДНЫХ параметров она зависит;
  3) пометить формулы, где возможны граничные эффекты:
     деление, округление, ветвления ЕСЛИ, перемножение коэффициентов.
Формат: таблица [Формула | Назначение | Входы | Тип риска].
Если формула неоднозначна — поставь «????» и НЕ выдумывай смысл.
Данные: <выгрузка>

Обратите внимание на две вещи в промте. Первое – явный запрет считать («НЕ считать значения»): на этом этапе нам нужна семантика, а не арифметика, и любое число от модели здесь было бы лишним поводом для ошибки. Второе – разрешение сказать «не знаю» («поставь ???? и НЕ выдумывай»). Это простое правило, но именно его отсутствие часто приводит к «галлюцинациям»: модель считает, что обязана дать ответ, и начинает его придумывать.

Декомпозиция и генерация чек-листа

Я разбил калькулятор на три уровня тестирования:

• формула – проверяем каждую в изоляции;
• модуль – целый вид тестирования (например, расчёт автоматизации с точкой окупаемости);
• сквозной сценарий – реалистичный проект целиком: заполняем несколько модулей и смотрим, как сводка собирает итог с накладными, резервом и НДС.

Для каждого уровня – свой набор проверок. И вот тут ИИ принёс реальную пользу.

Промт на тест-дизайн:

Роль: ведущий тест-аналитик.
На входе — формула, ее входные параметры, диапазоны и классы значений.
Сгенерируй чек-лист проверок строго по методикам:
  (1) классы эквивалентности;
  (2) анализ граничных значений: min-1, min, min+1, типовое,
      max-1, max, max+1, за границей;
  (3) негативные / невалидные значения.
Для каждой проверки выведи:
  ID | все входные значения | какой класс/границу проверяем |
  ожидаемое ПОВЕДЕНИЕ СЛОВАМИ (НЕ число!) | приоритет П1-П3
Приоритет — по риску искажения итоговой стоимости и срока.
НЕ придумывай параметров, которых нет во вводных.
Формат: CSV.
Параметры: <...>

Ключевой нюанс – «ожидаемое поведение словами, НЕ число». На этапе дизайна мы фиксируем что должно произойти («при росте сложности трудозатраты не уменьшаются», «при количественной юзабилити система не должна молча подменять введенное число респондентов», «при нулевой экономии автоматизация должна честно показать „не окупается“, а не упасть в ошибку»), но не конкретные цифры. 

Цифры оставляем на потом – это задача оракула, их считаем отдельно и независимо. Если смешать дизайн и расчёты в одном промпте, модель начнёт подгонять логику под удобные ей числа. Разделяй и властвуй.

В итоге после нескольких итераций получился чек‑лист на 1 150 проверок. Звучит много, но вручную я бы расписывал их 38 часов. ИИ быстро сгенерировал черновик, а мне осталось только вычитать и убрать дубли.

Поиск дыр в матрице покрытия

Чек‑лист без матрицы покрытия – просто набор строк, в котором не видно пробелов. Поэтому я попросил модель свести всё в матрицу: по строкам – узлы расчёта (из графа зависимостей), по столбцам – виды проверок. 

Вот промпт.

Построй матрицу покрытия.
Строки — узлы расчета (формулы) из графа зависимостей.
Столбцы — виды проверок:
  Классы эквивалентности | Граничные |
  Негативные | Инвариант/свойство | Якорный кейс.
В ячейке — количество проверок данного вида + список их ID.
В конце — строка ИТОГО и ПОДСВЕТИ узлы, где в каком-либо
столбце стоит 0 (это пробел покрытия — туда смотрим в первую очередь).
Формат: Markdown-таблица.
Данные: <чек-лист CSV>

Это фрагмент матрицы покрытия (пример). Видно, на какие узлы приходится больше всего проверок. 

Первая же матрица подсветила три узла, где в столбце «Негативные» стоял ноль: модель просто забыла про невалидные входы. Я вернул их в работу отдельным промтом. Вот почему матрицу строит ИИ, а анализирует человек: модель отлично сводит данные в таблицу, но решение остаётся за инженером.

Независимый оракул

Вот и самое интересное. Эталонное значение для каждого кейса я считал вслепую тремя способами. Подробно об этом – в следующем разделе. Здесь покажу промт, которым модель считает эталон. Важно: нейронка не должна видеть реальный результат калькулятора в момент расчёта – иначе она просто перепишет его и «подтвердит» любую ошибку.

Промпт такой.

Роль: расчетчик-аудитор.
Тебе даны: формула и КОНКРЕТНЫЙ
набор входных значений. Фактический результат калькулятора
тебе НЕ показан и показан не будет.
Посчитай ожидаемый результат ВРУЧНУЮ, показывая КАЖДЫЙ
промежуточный шаг и число.
Запрещено:
  - округлять раньше, чем это указано в формуле;
  - пропускать шаги;
  - подгонять под «красивый» ответ.
Если есть ветвление ЕСЛИ — явно укажи активную ветку и почему.
Выведи:
  - пошаговый расчет (текст);
  - финальное число;
  - отдельным JSON-блоком ВСЕ промежуточные значения
    (для автоматической сверки кодом).
Если данных не хватает — напиши «НЕДОСТАТОЧНО ДАННЫХ», не угадывай.
Формула: <...>   Входы: <...>

Тот самый JSON с промежуточными значениями – не для красоты. Он нужен, чтобы код потом перепроверил не только финальное число, но и каждый шаг вычисления. Если модель «угадывала» правильный итог через неправильные промежуточные шаги (а так бывало), я это видел. А если модель выдавала итог вообще без выкладок – такой ответ я отбраковывал автоматически.

Прогон калькулятора и триаж расхождений

Фактический результат снимался так: headless‑браузер открывал калькулятор, скрипт заполнял поля данными из кейса, дожидался пересчёта и считывал выходные значения – по всем модулям и из сводки.

Получались три эталона (Claude, Gemini, Python‑реализация) и одно фактическое число от калькулятора – дальше шло сравнение. Если что‑то расходилось, я не просил модель «проголосовать» за правильный ответ, так как мне не нужна была уверенная чушь.

Вместо этого – промт на разбор:

Дано: формула, входы и четыре числа:
  - эталон_1 (Claude),
  - эталон_2 (Gemini),
  - эталон_3 (Python-оракул),
  - фактический результат калькулятора.
Они расходятся. НЕ выбирай правильный голосованием.
Вместо этого:
  1) разложи каждый расчет по шагам;
  2) найди ПЕРВЫЙ шаг, на котором числа разошлись;
  3) назови вероятную причину именно этого расхождения:
     ошибка округления / двойной учет коэффициента /
     неверная ветка ЕСЛИ / неверный порядок операций / галлюцинация.
Гипотеза: это баг калькулятора, ошибка оракула или фантазия модели?
Не делай утверждений без указания КОНКРЕТНОГО шага.

Требование «найди первый шаг расхождения» превращает расплывчатое «тут что-то не так» в точную координату: вот здесь, на умножении базы на коэффициент накладных в сводке, два расчета разъехались. Дальше уже дело техники – посмотреть глазами, кто прав.

Как я боролся с галлюционированием ИИ?

Прогнать тесты через ИИ могут все, а вот сделать так, чтобы результатам можно было доверять, – это уже сложнее. Вот что мне помогло.

• Три независимых свидетеля. Эталон считал тремя способами: Claude, Gemini и Python‑оракул. Если все сошлись – результату можно доверять, а если разошлись – кейс разбирал вручную.
• Истину считал код. Python‑оракул – детерминированный код, который не умеет галлюцинировать, – главный арбитр. Модели нужны для тест‑дизайна и понятных выкладок, код – чтобы выносить окончательный вердикт.
• Расчёт «вслепую». Моделям при генерации эталона я не показывал реальный результат калькулятора – иначе они просто подтверждали любую ошибку.
• Пошаговая арифметика и автосверка. Модель была обязана показать каждый промежуточный шаг и выгрузить их в JSON. Код проверяет не только итог, но и все шаги: так я ловил случаи, когда ответ верный, а путь к нему – нет. Ответы без подробных выкладок сразу отбраковывал.
• Инварианты. Проверял свойства, которые должны выполняться при любых входных данных (например, неотрицательность или монотонность) – для этого использовал hypothesis.
• Якорные кейсы. 17 кейсов я заранее посчитал вручную – это «якоря». Если модель или оракул не воспроизводили якорь, останавливался и разбирал, что сломалось в самом конвейере, прежде чем доверять ему остальные кейсы.
• Перепроверки. Ключевые кейсы проверял несколько раз: если ответ менялся от прогона к прогону – значит данные были недостоверны.
• Сверка единиц измерений. Код проверял, чтобы часы не путались с днями, проценты были согласованы. Часть расхождений появлялась именно из‑за разных единиц – эта проверка их ловила.

Результаты тестирования

Из 1150 проверок калькулятор дал сбой в 23 случаях: 5 критичных, 9 средних, 9 косметических дефектов. Самое ценное – что нашлись именно незаметные баги: калькулятор не сбоил масштабно, а слегка неверно считал. Такие дефекты хуже всего ловятся вручную: число выглядит правдоподобно, глаз замыливается – и ты просто идёшь дальше.

По времени вышло так: без ИИ на эту работу ушло бы около 122 часов, с ИИ – примерно 27. Нейросеть оказалась способна забрать большую часть рутины, оставив мне 27 часов интеллектуальной исследовательской работы.

Расчетные системы – отдельная боль тестирования: их страшно трогать, потому что логика в них капризная, а баги очень дорогие. Мы в «Лаборатории качества» часто тестируем биллинги, тарификаторы, скоринг, прогнозные калькуляторы, финансовые и актуарные модели. Обращайтесь за бесплатной консультацией — поделимся опытом поможем решить вашу задачу.

Вывод: ИИ отлично справляется с рутиной: генерирует вариации по методике (классы эквивалентности, границы), расписывает пошаговую арифметику, сводит данные в матрицы и формулирует гипотезы о причинах расхождений. Но ему нельзя доверять как единственному источнику истины в расчётах, поручать оценку покрытия или «голосование» за правильный ответ – это зона ответственности тестировщика. По сути, ИИ – быстрый и талантливый стажёр, которого нужно тщательно контролировать.