787 нормочасов и 64 дефекта: как мы тестировали ИИ-платформу перед запуском
Реальный кейс: месяц тестирования базовой платформы и архитектурного контура программного комплекса с нейросетевыми модулями. Что проверяли, что нашли и почему семь критичных дефектов лучше найти до продакшена.
Июль 2026 · ~8 мин чтения · Команда TrustShield
Задача
К нам обратился разработчик программного комплекса с нейросетевыми модулями — система обработки голосовых обращений с речевой аналитикой, интеграциями с телефонией, CRM и 1С. Продукт готовился к промышленной эксплуатации, и заказчику требовалась независимая оценка: выдержит ли платформа реальную нагрузку и нет ли в ней критичных дефектов.
Мы предложили не разовую проверку, а годовую программу тестирования из 12 этапов — от базовой платформы до отдельных нейросетевых модулей. Здесь рассказываем про Этап № 1: базовая платформа и архитектурный контур — фундамент, на котором держится всё остальное.
С чего начали: план, а не «потыкать руками»
Тестирование без плана — это не тестирование, а лотерея. Поэтому первым делом мы разработали и согласовали с заказчиком Test Plan этапа: критерии входа и выхода, тестовые среды, порядок регистрации дефектов и их приоритизации.
Дальше — матрица трассировки требований. Каждое требование из технического задания сопоставляется с конкретными тест-кейсами. Это скучная работа, но именно она отвечает на главный вопрос заказчика: «а вы точно проверили всё, что обещали?» По итогам этапа покрытие требований тест-кейсами составило 96 % при целевых 90 %.
Набор тест-кейсов строили не только на «счастливых сценариях»: позитивные и негативные проверки, граничные значения, диаграммы переходов состояний (State Transition). Система ломается на границах, а не в середине.
Что именно проверяли
Этап закрывал семь направлений — каждое отвечает на свой вопрос о продукте.
- Функциональное тестирование ядра — регистрация и маршрутизация обращений, управление сессиями, пользовательские роли, конфигурирование параметров.
- Интеграционный контур — API-шлюзы, обработка webhook-событий, доставка и повторная обработка сообщений в очередях RabbitMQ/Kafka, согласованность состояний при асинхронном обмене.
- Безопасность контура — аутентификация и авторизация, разграничение прав по ролям, корректность TLS-соединений, статический анализ исходного кода (SAST).
- Совместимость — развёртывание на поддерживаемых серверных ОС, работа веб-интерфейса в целевых браузерах, совместимость SIP-стека и аудиокодеков, каналы интеграции с CRM и 1С.
- Нагрузочное тестирование — время отклика RT95, пропускная способность, утилизация CPU/GPU.
- Отказоустойчивость — имитация сетевых сбоев, аварийный перезапуск узлов, проверка сохранения состояния и корректности восстановления.
- Отчётность — Test Report, протоколы дефектов с логами и скриншотами, рекомендации по устранению.
Отдельно про асинхронный обмен: очереди — самое частое место, где «всё работает», пока не начинает теряться. Мы намеренно проверяли повторную обработку сообщений и согласованность состояний, потому что такие дефекты в продакшене выглядят как «иногда заявка не доходит» и ловятся месяцами.
Результаты измерений
Все целевые показатели этапа достигнуты — и это тот случай, когда цифры важнее слов:
| Показатель | Цель | Факт |
|---|---|---|
| RT95 — время отклика базового контура | ≤ 1 с | 0,82 с |
| Пропускная способность | ≥ 600 звонков/час | 640 звонков/час |
| Покрытие требований тест-кейсами | ≥ 90 % | 96 % |
| Доступность сервисов при нагрузке | ≥ 99,5 % | 99,7 % |
| Восстановление после сбоя узла | ≤ 5 мин | 3 мин 10 с |
Главное: 64 дефекта, из них 7 критичных
За этап зарегистрировано 64 дефекта. Распределение по критичности:
| Категория | Найдено | Устранено и проверено | Открыто |
|---|---|---|---|
| Blocker / Critical | 7 | 7 | 0 |
| Major | 19 | 17 | 2 |
| Minor / Trivial | 38 | 26 | 12 |
| Итого | 64 | 50 | 14 |
Все 7 блокирующих и критичных дефектов устранены разработчиком и подтверждены повторным тестированием — то есть мы не просто «завели баг», а проверили исправление. Оставшиеся открытыми Major и Minor не блокируют работу контура и перенесены в регрессионный набор следующего этапа.
⚠️ Семь критичных дефектов, найденных на этапе тестирования, — это семь инцидентов, которые не случились у пользователей после запуска. Стоимость их исправления «на берегу» несопоставима со стоимостью аварии в продакшене и репутационных потерь.
Что получил заказчик
- Test Plan этапа и матрицу трассировки требований — документы, которые можно показать инвестору или корпоративному клиенту.
- Комплект тест-кейсов базовой платформы и архитектурного контура — переиспользуется в регрессе на следующих этапах.
- 64 протокола дефектов с логами и скриншотами — разработчику не нужно догадываться, как воспроизвести проблему.
- Test Report с результатами измерений и рекомендациями.
По итогам этапа базовая платформа и архитектурный контур признаны готовыми к тестированию нейросетевых модулей на следующем этапе программы.
Выводы, применимые к любому продукту
- Тестируйте фундамент раньше «умных» модулей. Точность нейросети не имеет значения, если теряются сообщения в очереди.
- Метрика без целевого значения — не метрика. «Быстро работает» ничего не значит; «RT95 ≤ 1 с» — проверяемо.
- Дефект не закрыт, пока не проверено исправление. Повторное тестирование — обязательная часть цикла.
- Трассировка требований — ваша страховка. Она доказывает, что проверено именно то, что заказано.
- Отказоустойчивость проверяется сбоями, а не предположениями: выключите узел и засеките время восстановления.
Если вы готовите продукт к запуску, проходите сертификацию или вам нужна независимая оценка качества перед сделкой — расскажите о задаче, предложим формат работ и объём тестирования.
Нужно протестировать продукт?
Функциональное, нагрузочное, интеграционное тестирование и проверка безопасности — с документами и метриками.