Тестирование производительности SAP: нагрузка, параллельная работа и инструменты

Тестирование производительности SAP доказывает до go-live, что критичные транзакции, фоновые задания и интерфейсы укладываются в согласованное время отклика, когда одновременно работает много пользователей и заданий. По моему опыту, важны именно тесты параллельной работы: на маскированных данных продуктивного объёма и по критериям «пройдено» и «не пройдено», которые бизнес согласовал до первого прогона.

Это руководство для ИТ-директоров, руководителей программ и руководителей тестирования в программах S/4HANA, включая RISE with SAP. В нём: что тестировать, какие данные нужны, как писать критерии приёмки, какие инструменты справляются с задачей и кто за что отвечает. О том, где производительность стоит среди других видов тестирования, лучше начать с моего обзора тестирования SAP.

Проблемы производительности в программах SAP редко бывают неожиданными.

Плитки Fiori падают по тайм-ауту, когда сотни пользователей входят в систему в начале смены. Z-отчёт зависает, потому что кто-то запустил выборку за весь финансовый год без ограничений по очень большой таблице. Фоновые задания пересекаются в конце месяца, и прогон проводок прерывается.

Всё это предсказуемо. Вопрос лишь в том, протестировала ли это программа или бизнес обнаружит это на реальных заказах.

Тестирование производительности по фазам SAP Activate

1. 01

   Explore

   Выявите риски производительности в проекте решения. Архитектура и устройство отчётов определяют результат раньше, чем написан код.

2. 02

   Realize

   Проводите тесты объёма и нагрузки по мере стабилизации настроек. Частичные настройки дают вводящие в заблуждение результаты.

3. 03

   До UAT

   Завершите полный цикл тестирования производительности до UAT, а не в его рамках.

4. 04

   Переход

   Утверждайте переход по заранее согласованным критериям приёмки, а не по мнению.

5. 05

   Гиперподдержка

   Следите за ключевыми показателями в эксплуатации от 30 до 60 дней. Большинство регрессий проявляется в первом цикле закрытия.

В системе ECC на традиционной базе данных тестирование производительности означало нагрузочное тестирование сервера приложений и базы данных: время выполнения ABAP, производительность SQL и планирование заданий. Интерфейсом пользователя был SAP GUI, который редко кого-то удивлял.

В S/4HANA с интерфейсами Fiori, расширениями на SAP BTP и интеграцией через SAP Cloud Integration производительность зависит сразу от нескольких уровней. Медленная плитка Fiori может означать долгий вызов ABAP, тайм-аут шлюза, сервис OData, не рассчитанный на параллельные запросы, или сетевую задержку в гибридной конфигурации. Тестирование одного бэкенда этого не найдёт.

1. 01Запуск плиткиЛавина входов в начале смены
2. 02Вызов ODataТайм-ауты шлюза, сервисы не рассчитаны на параллельную работу
3. 03Обработка ABAPДолгие вызовы ABAP
4. 04Чтение из базы данныхВыборки без ограничений по большим таблицам
5. 05ОтрисовкаПлюс сетевая задержка для удалённых площадок

Одно время отклика, измеренное от начала до конца

У тестирования производительности SAP HANA при конверсии есть своя особенность. Стабильный код ECC ведёт себя иначе на базе данных в оперативной памяти. Многие программы становятся намного быстрее, а некоторые дают неожиданные профили на определённых структурах данных, поэтому регрессия тяжёлого собственного кода, специфичная для конверсии, обязательна.

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

Тестирование производительности должно пройти до go-live. Важными я считаю тесты параллельной работы: много пользователей и заданий одновременно обращаются к одним и тем же транзакциям, таблицам и сервисам.

Один пользователь, создающий заказ клиента за две секунды, почти ничего не доказывает. Тот же заказ, когда 150 человек вводят заказы, в фоне идёт прогон поставок, а интерфейс проводит входящие сообщения, это тест, который предсказывает первый день.

Эта таблица показывает, что доказывает каждый вид теста и когда его проводить:

Тест	Что он доказывает	Когда проводить	Что он обычно находит
Параллельная работа	Много пользователей и заданий могут одновременно работать с одними и теми же объектами	Realize, когда настройки стабильны, и ещё раз до UAT	Ожидания блокировок, лавины входов, узкие места шлюза
Нагрузка	Система укладывается во время отклика при ожидаемом пиковом объёме	Realize, после того как скрипты параллельной работы заработали	Медленные сервисы OData, тяжёлые Z-отчёты
Стресс	Где система ломается выше проектных пределов	До UAT, если ожидается рост	Пробелы в сайзинге, пределы очередей
Длительная нагрузка (soak)	Система часами держит стабильную нагрузку	До UAT, в идеале на смоделированном закрытии	Рост потребления памяти, конфликты цепочек заданий при повторных прогонах
Сквозной тест	Весь путь, который ждёт пользователь, укладывается в целевое значение	Вместе с нагрузочными тестами	Проблемы, невидимые при тестировании каждого уровня по отдельности

Ключевое слово в нагрузочном тестировании: ожидаемый. Нужны реальные объёмы транзакций, числа пользователей и шаблоны сеансов. Нагрузочный тест, построенный на оценках объёма, про которые все и так знали, что они оптимистичны, даёт «пройдено», которое ничего не значит.

Длительную нагрузку пропускают чаще всего. Тестирование на объёмах вообще сокращают чаще всего, когда сроки сжимаются, и жалеют об этом больше всего.

Пропишите их первыми. Они покрывают большую часть сбоев, доходящих до продуктивной системы.

1. Пересменка и пиковый вход в систему. Когда несколько сотен пользователей одновременно открывают Fiori launchpad, аутентификация и отрисовка launchpad дают пик. Система, которая нормально работает вне пика, может стать непригодной в это окно, если одновременные входы никогда не тестировались.
2. Закрытие месяца и года. Большие объёмы проводок, цепочки заданий со строгой последовательностью и финансовая команда, которая работает наперегонки с жёстким сроком. Прогоняйте цепочки заданий закрытия целиком на объёмах закрывающего периода, а не на средних дневных.
3. Пересекающиеся фоновые задания. Пакетные задания обычно тестируют по одному, а это не отражает реальность. Одно плохо оптимизированное задание может заблокировать несколько других, и закрытие выходит за своё окно.
4. Z-отчёты без ограничений выборки. Отчёт, который мгновенно отвечает на тестовых данных, может работать минутами на полном финансовом году. Тестируйте типичные и наихудшие выборки и блокируйте выборки без ограничений.
5. Пользователи в нескольких регионах. Сетевая задержка влияет на каждую транзакцию. RISE переносит хостинг к SAP, но задержка по-прежнему зависит от выбранного региона и маршрута до ваших пользователей, поэтому тестируйте с самых удалённых площадок.

Где тестирование конверсии вписывается в общий план, описано в моём руководстве по миграции ECC в S/4HANA.

Тестовые данные продуктивного уровня

От данных зависит, имеет ли всё это хоть какой-то смысл. Я настаиваю на маскированных данных продуктивного уровня: продуктивный объём и продуктивная реалистичность, с замаскированными персональными и чувствительными полями.

Клиент с 200 000 открытых позиций заказов ведёт себя иначе, чем клиент с 5 000. Фильтры, которые мгновенно отвечают в скудном тестовом манданте, в продуктивной системе падают по тайм-ауту. Наполните объёмом области высокого риска, используйте репрезентативный набор транзакций и делайте реальные вызовы интерфейсов, где это возможно.

Как безопасно получить такие данные, через копии, инструменты выборочного создания тестовых данных и маскирование, описано в моём руководстве по управлению тестовыми данными SAP. Запланируйте обновление до первого цикла тестирования производительности, потому что оно занимает больше времени, чем предполагает большинство планов тестирования.

Согласуйте критерии с бизнесом в фазе Prepare, до любого прогона. Каждый критерий называет транзакцию или задание, нагрузку и порог.

Эти примеры показывают форму. Свои цифры задайте исходя из операционных потребностей:

Объект	Условие нагрузки	Порог прохождения	Ответственный
Создание заказа клиента (VA01 или приложение Fiori)	150 одновременных пользователей, вводящих заказы	Менее 3 секунд для 95% транзакций	Владелец процесса «от заказа до оплаты»
Первая загрузка Fiori launchpad в начале смены	Пиковое число одновременных входов для самой крупной смены	Менее 5 секунд для 95% пользователей	Руководитель ИТ-эксплуатации
Цепочка заданий закрытия месяца	Объёмы закрывающего периода, полная последовательность	Завершается в согласованное окно закрытия без прерываний	Финансовый контролёр
Интерфейс входящих заказов	Пиковый часовой объём сообщений	Нет очереди сообщений старше 15 минут	Руководитель по интеграции
Z-отчёт с большим объёмом	Полный продуктивный объём данных, типичная выборка	Менее 60 секунд; выборки без ограничений заблокированы	Владелец отчёта

Формулировку «система должна быть достаточно быстрой для бизнес-операций» нельзя ни протестировать, ни принять. Изменение критериев после получения результатов лишает их смысла.

Если система прошла проверку, потому что пользователи UAT сказали, что она работает быстро, у вас мнение, а не критерий приёмки. Сделайте результаты формальной контрольной точкой перед переходом, как описано в моём руководстве по quality gates в SAP. Общий план циклов с критериями входа и выхода для каждой фазы тестирования должен быть в вашей стратегии тестирования S/4HANA.

Инструменты тестирования производительности SAP

Тесту производительности нужны три вещи: генератор нагрузки, который умеет работать с протоколами SAP, мониторинг на стороне SAP и место для управления тестовыми сценариями и результатами. LoadRunner это инструмент нагрузки, которым пользовались мои команды в программах SAP. Назовите инструмент в плане тестирования рано, потому что на лицензии, генераторы нагрузки и навыки написания скриптов нужно время.

Основные варианты в 2026 году:

Инструмент	Роль	Что нужно знать
OpenText Professional Performance Engineering	Генерация нагрузки	Продукт, ранее называвшийся LoadRunner Professional. Его пакеты протоколов охватывают SAP, SAP GUI и SAP Web
Tricentis NeoLoad	Генерация нагрузки	Tricentis заявляет поддержку SAP GUI, Fiori, RFC и IDoc, и он может повторно использовать ресурсы Tricentis Tosca
Apache JMeter	Генерация нагрузки	Открытый исходный код. Генерирует HTTP-трафик, например вызовы Fiori и OData
SAP Cloud ALM	Управление тестированием	Готовит и выполняет ручные и автоматические тестовые сценарии и отслеживает дефекты. Сам нагрузку не генерирует
SAP Solution Manager	Управление тестированием	Основная поддержка заканчивается 31 декабря 2027 года, поэтому новую работу планируйте в Cloud ALM

Более широкий обзор функциональных инструментов и средств автоматизации есть в моём сравнении инструментов тестирования и проверки SAP. Инструмент важен меньше, чем скрипты, данные и критерии.

RISE with SAP разделяет ответственность

В RISE with SAP SAP отвечает за инфраструктуру: сайзинг, регион гиперскейлера, сеть и доступность платформы. Клиент и партнёр отвечают за уровень приложений.

Документ SAP о ролях и обязанностях в RISE говорит об этом прямо. Выполнение нагрузочных тестов и настройка дорогих SQL-запросов относятся к SAP Cloud Application Services за дополнительную плату. Если вы их не покупаете, эту работу делает клиент.

Частая ошибка в программах RISE: предположение, что SAP поймает проблемы производительности, потому что управляет инфраструктурой. SAP поймает проблемы инфраструктуры. Пропишите разделение в уставе и в плане тестирования:

1. SAP: доступность инфраструктуры и отклик на уровне платформы
2. Партнёр: производительность приложений при определённой нагрузке, включая расширения и интеграционные потоки
3. Клиент: результаты на уровне процессов, такие как время закрытия и пропускная способность по заказам, и решение о приёмке

Public cloud сужает объём

В public edition облачной ERP от SAP система работает на общей платформе, которой управляет SAP. Прежде чем планировать нагрузочный тест на тенанте, письменно спросите SAP, разрешён ли он и за сколько нужно предупредить.

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

Частые ошибки

1. Считать функциональное тестирование тестированием производительности. Функциональные тесты доказывают, что транзакция даёт правильный результат. Они ничего не говорят о 150 людях, которые выполняют её одновременно.
2. Оставлять производительность команде Basis. Basis отвечает за сайзинг и планирование заданий. Она не отвечает за проектирование отчётов, архитектуру сервисов OData или проектирование интеграционных потоков, а именно они определяют производительность приложений.
3. Отдавать ответственность одному QA. QA проводит тесты и сообщает результаты, но решения, которые вызывают проблемы производительности, принимаются при проектировании. Руководителю тестирования или архитектору уровня программы нужны полномочия оспаривать их рано, а матрица RACI должна указывать, кто может заблокировать go-live из-за производительности.
4. Принимать пробелы как известные проблемы. Большинство программ с проблемами производительности в продуктивной системе не пропускали тестирование. Они тестировали без согласованных критериев или тестировали, а затем принимали сбои под давлением графика.

Напишите пять или шесть критериев приёмки для ваших транзакций и заданий с наибольшим риском, с названным ответственным за каждый. Если вы не можете заполнить таблицу выше, вы не готовы к тестированию, и вы нашли первый пробел.

Затем проверьте две вещи: что в плане есть обновление маскированных данных продуктивного объёма и что цикл тестирования параллельной работы заканчивается до начала UAT.

Если вам нужен независимый взгляд на план тестирования производительности или решение о go-live, я помогаю организациям с этим. Вы можете связаться со мной здесь.

Что такое тестирование производительности SAP?

Оно проверяет, как SAP ведёт себя при реалистичной нагрузке: время отклика пользовательских транзакций, время выполнения фоновых заданий, пропускную способность интерфейсов и использование ресурсов, когда одновременно работает много людей. Его нужно провести до go-live.

Функциональная правильность и производительность это разные свойства. Транзакция, которая правильно работает для одного пользователя, может упасть по тайм-ауту для 200.

Когда начинать тестирование производительности в программе SAP?

Выявление рисков начинается в Explore, потому что архитектурные решения определяют производительность. Активное тестирование начинается в Realize, когда настройки достаточно стабильны, чтобы результаты что-то значили.

Завершите последний цикл до UAT, а не во время него. Дефекты производительности, найденные в UAT, сжимают график и создают давление принять их как известные проблемы.

В чём разница между нагрузочным тестированием и тестированием параллельной работы в SAP?

Нагрузочное тестирование проверяет время отклика при ожидаемом пиковом объёме. Тестирование параллельной работы проверяет, что происходит, когда много пользователей и заданий в один и тот же момент работают с одними и теми же транзакциями, таблицами и сервисами. Именно там проявляются ожидания блокировок, лавины входов и узкие места шлюза.

По моему опыту, важны именно тесты параллельной работы. Проведите их первыми, а затем стройте поверх полный нагрузочный тест.

Какие тестовые данные использовать для тестирования производительности SAP?

Маскированные данные продуктивного уровня. Это означает продуктивный объём и реалистичность, с замаскированными персональными и чувствительными полями. Скудные тестовые данные скрывают медленные фильтры, тяжёлые отчёты и долгие задания, которые появятся в первый же день.

Какие инструменты используются для тестирования производительности SAP?

Нагрузку создают генераторы нагрузки, такие как OpenText Professional Performance Engineering (ранее LoadRunner Professional), Tricentis NeoLoad и Apache JMeter. SAP Cloud ALM или SAP Solution Manager управляют тестовыми сценариями и результатами, а мониторинг на стороне SAP показывает, что делала система под нагрузкой.

Кто отвечает за тестирование производительности в RISE with SAP?

SAP отвечает за инфраструктуру: сайзинг, регион, сеть и доступность платформы. Документ SAP о ролях и обязанностях в RISE оставляет выполнение нагрузочных тестов и настройку дорогих SQL-запросов за клиентом, если только SAP Cloud Application Services не куплены за дополнительную плату.

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