Тестирование и приёмка ПО: как убедиться, что система работает до релиза
Фраза «мы всё проверили» ничего не значит, пока не ответишь на вопрос: что именно проверили и как. Тестирование — последний барьер между разработкой и вашими пользователями, но строить его нужно с первого дня проекта, а не в последнюю неделю. Описываю, как это устроено у меня. Это завершающая часть процесса, о котором я рассказываю в статье Разработка ПО с нуля под ключ: от идеи до релиза.
Зачем нужно тестирование
Ошибка, найденная на этапе разработки, стоит минуты. Найденная после релиза — часов, денег и репутации. В промышленных системах цена ещё выше: например, платформа вроде «Русло»: как строится IIoT-платформа для закрытой сети предприятия не имеет права терять данные или выдавать неверные показания. Поэтому тесты — не формальность, а часть конструкции.
Пирамида тестирования
Проверки бывают разных уровней, и у каждого своя роль:
| Уровень | Что проверяет | Скорость | Количество |
|---|---|---|---|
| Модульные тесты | Отдельные функции и правила | Мгновенно | Много |
| Интеграционные | Связку с базой, очередями, внешними сервисами | Секунды | Умеренно |
| Сквозные (e2e) | Ключевые пользовательские сценарии целиком | Медленно | Мало, но важные |
| Нагрузочные | Поведение при потоке данных и пиках | Отдельный прогон | По необходимости |
| Проверки безопасности | Права доступа, граничные и враждебные случаи | По регламенту | Для критичных мест |
Чем ниже уровень, тем тест быстрее и надёжнее. Поэтому основа — быстрые модульные тесты, а сквозных меньше, но они покрывают то, без чего продукт не имеет смысла.
Как это встроено в разработку
- Тесты пишутся вместе с кодом. Новая функция без теста считается незаконченной.
- Автоматический запуск. Каждое изменение прогоняется через проверки в CI (Качество кода: что оно значит для бизнеса и как его обеспечить). Не прошло — не попадёт в основную ветку.
- Тесты как документация. Хороший тест показывает, как система должна себя вести, и защищает от случайных поломок при развитии.
- Баги получают тест. Найденная ошибка сначала воспроизводится тестом и только потом исправляется, поэтому она не вернётся.
Нагрузочное тестирование
Система может идеально работать на трёх пользователях и разваливаться на трёхстах. Я проверяю, как она ведёт себя на реалистичных объёмах: сколько запросов держит, где появляется задержка, что происходит при перегрузке и как восстанавливается.
Для промышленных систем нужны специальные средства. Поэтому я сделал «Исток» — стенд нагрузочного тестирования однонаправленной передачи данных через аппаратный диод. Отправитель генерирует данные по MQTT, TCP, Modbus TCP, OPC UA и SFTP, получатель проверяет целостность по контрольной сумме SHA-256, измеряет задержку и считает потери, а обратного канала между ними нет. Такой подход показывает реальные цифры, а не предположения.
Тестирование безопасности
Проверка защиты — часть тестов, а не отдельный ритуал. Среди проверок:
- попытки получить чужие данные при неверных правах;
- некорректные, пустые и огромные входные данные;
- поведение при недоступных внешних сервисах;
- проверка зависимостей на известные уязвимости.
Эти проверки следуют из модели угроз, составленной заранее. Подробнее — в статье Безопасная разработка ПО: как защита закладывается с первого дня.
Критерии приёмки
Чтобы приёмка не превратилась в спор «нравится — не нравится», критерии согласуются заранее, на этапе требований. Хороший критерий проверяем и однозначен: «отчёт за месяц формируется не дольше N секунд на таком-то объёме данных», «пользователь с ролью X не видит раздел Y». Для каждого требования есть способ проверки, и приёмка сводится к прохождению списка.
Подготовка и проведение релиза
Релиз — управляемая процедура, а не прыжок в неизвестность. Перед запуском я проверяю:
- сборка воспроизводима, версии зафиксированы;
- конфигурация и секреты вынесены из кода;
- миграции базы данных проверены на копии реальных данных;
- есть план отката и проверенное резервное копирование;
- настроены журналы и мониторинг, чтобы заметить проблему раньше пользователей;
- подготовлены инструкции по развёртыванию и сопровождению.
В пакет передачи входят конфигурации развёртывания (например, docker-compose и nginx), техническая документация и описание архитектурных решений. Если система работает в закрытом контуре, как «Русло», всё это рассчитано на развёртывание без доступа в интернет.
После релиза
Релиз — не конец. Я отслеживаю журналы и поведение системы на реальных данных, исправляю найденное и помогаю развивать продукт дальше. Благодаря тестам и чистой архитектуре новые функции добавляются без страха что-то сломать.
Частые вопросы
Нужно ли тестирование, если проект небольшой? Да, но объём разумный: ключевая логика и главные сценарии. Отсутствие тестов дороже всего обходится именно тогда, когда продукт начинает расти.
Кто пишет тесты? Я, в рамках разработки. Это не отдельная платная опция «на потом».
Можно ли протестировать уже существующую систему? Да. Начинаем с аудита, покрываем тестами самые рискованные места, затем расширяем покрытие по мере доработок.
Поможете с приёмкой на стороне заказчика? Да, я готовлю чек-лист приёмки и участвую в проверке вместе с вашей командой.
Хотите уверенно выпускать релизы?
Если вам нужна разработка с нуля, где тестирование встроено в процесс, или помощь с проверкой существующего продукта, напишите: Telegram @w1shmaster. Начнём с короткого обсуждения задачи и риска, который пугает вас больше всего.