Требования к нагрузочному тестированию в ТЗ

Коротко: Чтобы нагрузочное тестирование в ТЗ не превратилось в пустую трату бюджета, необходимо четко прописать профиль нагрузки, объемы данных и допустимые пороги деградации производительности. Важно учитывать актуальные стандарты (ГОСТ 34.602 и 56920-2024) и специфические требования регуляторов, такие как Положение Банка России № 850-П, чтобы избежать отказов системы при пиковых нагрузках.

Кстати, в AmSales мы делаем разработку сайтов под ключ и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Зачем включать нагрузочное тестирование в ТЗ

Многие заказчики ошибочно полагают, что проверка системы на устойчивость - это этап, который можно обсудить "на берегу" в устной форме. Это фатальная ошибка. Если вы не зафиксировали параметры нагрузки в техническом задании, разработчик примет систему как рабочую, если она не падает при 10 одновременных запросах. Но в реальности ваша бизнес-задача может подразумевать тысячи транзакций в секунду. Без четких требований в ТЗ вы не сможете юридически и технически обосновать, что система не соответствует вашим ожиданиям.

Нагрузочное тестирование - это не просто проверка на "не упадет или нет". Это проверка того, как система ведет себя при росте нагрузки. Например, как меняется время отклика базы данных, когда количество активных сессий удваивается? Или как система обрабатывает очередь сообщений в шине данных, когда входящий поток возрастает в три раза? Если в ТЗ не прописаны сценарии деградации, вы получите продукт, который работает идеально в лаборатории, но "ложится" в первый же день реальной эксплуатации.

Риски игнорирования этапа

Основной риск - это неопределенность критериев приемки. Когда наступает этап испытаний, разработчик говорит: "Система работает, нагрузка в 100 пользователей прошла успешно". А ваш бизнес ожидает 1000 пользователей. Итог - бесконечные споры, доработки и перерасход бюджета. Включение нагрузочных испытаний в ТЗ позволяет перевести обсуждение из плоскости "мне кажется, она тормозит" в плоскость "система не соответствует заданным параметрам в ТЗ".

Еще один важный момент - экономия ресурсов. Нагрузочное тестирование требует специфических мощностей. Если вы не указали требования к тестированию, подрядчик может не заложить в бюджет аренда облачных мощностей для имитации нагрузки. В итоге вы получите отчет о тестах, проведенных на "микро-сервере", который не имеет никакого отношения к реальному промышленному контуру. Поэтому требования к нагрузочному тестированию в ТЗ должны быть такими же детальными, как требования к функционалу.

Нормативная база: ГОСТ 34.602 и 56920-2024

При составлении документации нельзя игнорировать стандарты, так как они формируют фундамент для юридической значимости результатов. На текущий момент, 20 октября 2026 года, основным документом для формирования структуры ТЗ остается ГОСТ 34.602-2020. Он определяет состав и порядок подготовки технического задания на создание автоматизированной системы. В рамках этого стандарта важно правильно определить порядок контроля и приёмки. Вы можете зафиксировать, что нагрузочные испытания являются обязательным этапом, и прямо сослаться на отдельную методику их проведения.

Однако для более детального описания процессов тестирования стоит использовать ГОСТ Р 56920-2024 «Системная и программная инженерия. Тестирование программного обеспечения. Общие положения». Этот стандарт дает гораздо больше гибкости. Он позволяет прямо указывать в ТЗ не только сам факт проведения испытаний, но и детализированный профиль нагрузки, объем данных и длительность сценария. Это критически важно для формирования качественного ТЗ, где требования к нагрузочному тестированию будут понятны и заказчику, и исполнителю.

Актуальный контекст и законодательство

Важно помнить, что требования к испытаниям постоянно ужесточаются. Например, для государственных информационных систем (ГИС) обязательным является соблюдение Постановления Правительства РФ № 676 от 06.07.2015 (в актуальной редакции от 18.03.2025). Оно требует проведения предварительных испытаний, опытной эксплуатации и приёмочных испытаний до ввода системы в эксплуатацию. Если ваша система является ГИС, то отсутствие в ТЗ раздела о нагрузочных испытаниях сделает невозможным успешное прохождение приёмочных испытаний.

Также стоит учитывать изменения в законодательстве, вступившие в силу 01.09.2026 (ФЗ № 126-ФЗ). Хотя закон не вводит прямого "обязательного нагрузочного тестирования" для всех без исключения, он меняет порядок подтверждения соответствия объектов. Это означает, что требования к подтверждению характеристик системы становятся более жесткими. Если вы не заложите нагрузочные тесты в ТЗ, вы рискуете не подтвердить соответствие системы новым нормам при её вводе в эксплуатацию.

Как описать профиль нагрузки и объем данных

Самая частая ошибка при попытке составить требования к нагрузочному тестированию - это использование размытых формулировок типа "система должна выдерживать высокую нагрузку". Для инженера это означает "ноль". Вам нужно составить профиль нагрузки в техническом задании, который будет содержать конкретные метрики. Профиль нагрузки - это математическая модель поведения пользователей системы в разные периоды времени.

Чтобы правильно описать профиль, вам нужно разделить его на несколько составляющих. Во-первых, это интенсивность запросов. Не пишите "много запросов", пишите "количество транзакций в секунду (TPS) или запросов в секунду (RPS)". Во-вторых, это структура нагрузки. Не все пользователи делают одно и то же. Одни просто смотрят каталог, другие инициируют сложные расчеты, третьи загружают файлы. В ТЗ нужно указать пропорцию этих действий. Например: 70% - чтение данных, 20% - создание заказов, 10% - генерация сложных отчетов.

Параметры объема данных

Второй важный аспект - объем данных. Тестировать систему на базе, где всего 100 строк, бессмысленно. Реальная нагрузка проявляется тогда, когда индексы в базе данных разрастаются, а время поиска по таблицам увеличивается. В ТЗ необходимо указать объем данных, который должен присутствовать в системе на момент проведения испытаний. Это может быть объем основной базы данных и объем логов или архивов.

Пример из практики: если вы планируете систему с миллионами транзакций, в ТЗ должно быть прописано: "Испытания проводятся на массиве данных, объем которого составляет не менее 50% от прогнозируемого объема за первый год эксплуатации". Это гарантирует, что тесты будут репрезентативными. Без учета объема данных вы получите ложные результаты: система "летает" на пустой базе, но "умирает" при реальном масштабировании.

Критерии эффективности и допустимая деградация

Вы определили нагрузку, объем данных и сценарии. Что дальше? Теперь нужно понять, когда система считается работающей, а когда - нет. Для этого в ТЗ вводятся критерии эффективности. Обычно они делятся на временные (время отклика) и количественные (процент успешных запросов). Например, "время отклика 95-го процента запросов (p95) не должно превышать 500 мс при нагрузке 500 RPS".

Важнейшим параметром является процент ошибок. Допустимо ли, что 1% запросов вернет ошибку 500 при пиковой нагрузке? В ТЗ это должно быть зафиксировано. Обычно устанавливается порог, например, не более 0.1% ошибок. Если процент ошибок выше - это признак нестабильности системы, даже если время отклика в норме. Это критично для финтеха и высоконагруженных систем, где потеря даже одного пакета данных может стоить компании репутации или огромных штрафов.

Понятие допустимой деградации

Существует такое понятие, как деградация производительности. Это ситуация, когда при росте нагрузки время отклика растет не линейно, а экспоненциально. Например, при увеличении нагрузки в 2 раза, время отклика увеличивается в 4 раза. В ТЗ нужно прописать допустимую степень такой деградации. Это позволяет отличить естественное замедление системы от критической ошибки архитектуры.

Пример: "При увеличении количества одновременных сессий с 1000 до 1500 (рост в 1.5 раза), время отклика p95 не должно превышать 800 мс (рост в 1.6 раза)". Такой подход позволяет инженерам понимать, насколько система склонна к дезорганизации ресурсов. Если деградация слишком резкая, это сигнал о необходимости оптимизации архитектуры или масштабирования ресурсов еще на этапе разработки.

Специфика требований для ГИС и финтеха

Требования к нагрузочному тестированию в ТЗ для государственных систем (ГИС) и банковского сектора (финтех) имеют свою специфику. Для ГИС на первый план выходит соответствие требованиям безопасности и отказоустойчивости. Согласно Постановлению Правительства № 676, системы должны проходить не только нагрузочные, но и комплексные испытания, включая проверку на устойчивость к DoS-атакам. В ТЗ для ГИС обязательно нужно прописывать сценарии "нагрузочного тестирования под воздействием угроз безопасности".

Для финтеха ситуация иная. Здесь ключевым фактором является непрерывность технологического процесса. Согласно Положению Банка России № 850-П (действует с 01.10.2025), банки обязаны обосновывать допустимую долю деградации технологического процесса. Это означает, что в ТЗ для банковских систем требования к нагрузке должны опираться на статистику минимум за последние 12 календарных месяцев. Вы должны понимать, какой пик нагрузки был в прошлом году, и закладывать в ТЗ запас прочности на этот пик плюс 20-30%.

При разработке ТЗ для финтеха крайне важно разделять "нагрузочное тестирование" и "тестирование на отказоустойчивость" (Chaos Engineering). В банковских системах важно знать, что произойдет, если один из узлов кластера упадет прямо в момент обработки платежа под высокой нагрузкой. В ТЗ это должно быть выделено в отдельный подраздел "Тестирование устойчивости при отказах под нагрузкой". Это критически важно для обеспечения целостности данных.

Типичные ошибки при постановке задач тестировщикам

Ошибки в ТЗ стоят дорого. Самая распространенная ошибка - это отсутствие привязки к реальным бизнес-процессам. Заказчик пишет: "Система должна работать быстро". Тестировщик делает тест на "тяжелых" запросах, система проходит. А в реальности пользователи делают простые запросы, но их настолько много, что забивается сетевой канал. Всегда требуйте, чтобы методика нагрузочных испытаний базировалась на реальных сценариях использования (User Journeys).

Вторая ошибка - игнорирование "холодного старта" и прогрева системы. Часто тесты проводят на уже "разогретой" базе и кэшированных данных. В итоге результаты выглядят великолепно. Но в реальности первый пользователь в понедельник утром может столкнуться с тем, что система тормозит, пока кэши не заполнятся. В ТЗ нужно указывать, должны ли тесты проводиться на "холодной" системе, чтобы учесть время на прогрев кэшей и инициализацию соединений.

Другие промахи заказчиков

К другим типичным ошибкам относятся:

• Несоответствие окружений: тестирование проводится на конфигурации, которая в 10 раз слабее промышленной. Это делает результаты бесполезными.
• Отсутствие требований к мониторингу: если в ТЗ не указано, какие именно метрики (CPU, RAM, Disk IO, Network) должны собираться во время теста, вы получите только сухую цифру "все работает".
• Использование устаревших норм: использование требований, опирающихся на отмененные документы (например, старое Положение № 787-П), что ведет к несоответствию современным стандартам регуляторов.

Если вы не заложили в ТЗ требования к инструментарию, вы рискуете получить отчеты, которые невозможно сопоставить. Например, если один тест проводился в JMeter, а другой в Locust, и у них разные подходы к замеру времени отклика, вы не сможете построить корректную динамику. Все инструменты и форматы отчетов должны быть согласованы в ТЗ.

Чек-лист для проверки раздела испытаний

Перед тем как подписать ТЗ, пройдитесь по этому списку. Если хотя бы один пункт не раскрыт - документ нужно дорабатывать. Помните, что методика нагрузочных испытаний - это не просто формальность, а ваш страховой полис при приемке продукта.

1. Определены ли типы нагрузки? (Стресс-тестирование, нагрузочное тестирование, тестирование стабильности, тестирование на отказоустойчивость).
2. Описан ли профиль нагрузки? (Количество RPS/TPS, распределение типов запросов, пропорция чтение/запись).
3. Указан ли объем данных? (Объем базы данных, количество записей в ключевых таблицах, объем логов).
4. Зафиксированы ли критерии успеха? (Максимальное время отклика p95/p99, допустимый процент ошибок, допустимая деградация производительности).
5. Указаны ли требования к инфраструктуре? (Соответствие тестового стенда промышленному контуру, требования к инструментарию).
6. Учтены ли требования регуляторов? (Для ГИС - требования безопасности, для финтеха - статистика за 12 месяцев и требования ЦБ).

Использование этого чек-листа поможет вам избежать ситуации, когда на этапе внедрения системы выясняется, что она "не тянет" реальные задачи бизнеса. Качественное нагрузочное тестирование в ТЗ - это инвестиция, которая окупается отсутствием аварий в промышленной эксплуатации.

Что запомнить:

• Всегда используйте актуальные ГОСТ (34.602-2020 и 56920-2024) и учитывайте свежие изменения в законодательстве (ФЗ № 126-ФЗ).
• Избегайте общих слов: заменяйте "высокая нагрузка" на конкретные значения RPS/TPS и сценарии поведения пользователей.
• Для финтеха и ГИС требования в ТЗ диктуются жесткими нормами регуляторов (ЦБ РФ и требования к ГИС), а не вашим желанием.
• Тестирование должно проводиться на объемах данных, максимально приближенных к реальным, иначе результаты будут ложными.