Тестирование производительности SAP: что должны знать ИТ-руководители

Тестирование производительности SAP доказывает до go-live, что критичные транзакции, фоновые задания и интерфейсы укладываются в согласованное время отклика на производственных объёмах. Начинайте его на этапе проектирования, запускайте тесты на объёмах и нагрузочные тесты в Realize, как только конфигурация стабилизируется, завершайте цикл до приёмочного тестирования (UAT) и сделайте результаты барьером перед cutover. Руководство адресовано CIO, директорам программ и руководителям тестирования в программах S/4HANA, включая RISE with SAP. В нём: что тестировать, кто за это отвечает, как писать критерии приёмки и что меняется в облаке. Начните с таблицы критериев приёмки: если вы не можете её заполнить, вы не готовы к тестированию.

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

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

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

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

1. 01

   Explore

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

2. 02

   Realize

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

3. 03

   До UAT

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

4. 04

   Cutover

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

5. 05

   Hypercare

   Наблюдайте за KPI в работающей системе от 30 до 60 дней. Большинство регрессий проявляется в первом цикле закрытия.

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

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

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

Одно время отклика, измеренное сквозным образом

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

1. Нагрузочное тестирование проверяет поведение при ожидаемом объёме. Ключевое слово: ожидаемом. Нужны реальные объёмы транзакций, число пользователей и параллельных сессий. Многие нагрузочные тесты проваливаются, потому что в них использовали оценки объёмов, про которые все и так знали, что они оптимистичны.
2. Стресс-тестирование выходит за проектные пределы, чтобы найти, где система ломается. Если объёмы удвоятся через восемнадцать месяцев, оно покажет, справится ли архитектура и не станет ли расчёт мощностей проблемой раньше следующего пересмотра инфраструктуры.
3. Тестирование на длительной нагрузке (soak-тест) держит стабильную нагрузку в течение долгого времени, чтобы выявить проблемы, которые накапливаются со временем: утечки памяти, фрагментацию и конкуренцию цепочек заданий при повторных прогонах. Этот тест пропускают чаще других, и именно он обнаружил бы сбой при закрытии месяца, описанный ниже.
4. Сквозное тестирование проходит весь путь пользователя: запуск плитки, вызов OData, обработка ABAP, чтение из базы данных, отрисовка. Только так можно найти проблемы, которых не видно, когда каждый слой тестируется отдельно.

Пересменка и пиковые входы. Когда 200 пользователей открывают Fiori launchpad в 8 утра, нагрузка на аутентификацию и отрисовку launchpad резко растёт. Система, которая нормально работает вне пика, в это окно может стать непригодной, если параллельные входы никогда не тестировали. В производстве, ритейле и финансовых услугах именно шквал входов даёт самые заметные жалобы в первый день.

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

Фоновые задания обычно тестируют изолированно, и это не отражает реальность. В конце месяца фоновая обработка достигает пика, и много программ работают параллельно на одних и тех же ресурсах. Одно плохо оптимизированное задание может заблокировать пять других, и закрытие выходит за своё окно.

Конвертация с ECC на S/4HANA. Стабильный код ECC на HANA ведёт себя иначе. Многие ABAP-программы становятся намного быстрее; некоторые дают неожиданные профили на отдельных паттернах данных. Регрессионное тестирование, специфичное для конвертации, не опционально. В моём руководстве по миграции с ECC на S/4HANA описано, где оно вписывается в план конвертации.

Пользователи из разных регионов. Сетевая задержка влияет на каждую транзакцию. Заказ клиента, который занимает две секунды в стране размещения, может казаться сломанным в 3000 милях оттуда, если никто не тестировал из этой точки. RISE переносит хостинг к SAP, но задержка по-прежнему зависит от выбранного региона и маршрутизации до ваших пользователей.

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

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

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

Запрашивайте каждый из этих пунктов по названию:

Ожидание	Что должно быть поставлено	Почему это важно
Уровни обслуживания по производительности	Пороги для каждой транзакции, интерфейса и задания, с критериями прохождения и провала	Не даёт мнению на UAT перевесить факты
Объём на основе рисков	Приоритизация по числу пользователей, точкам интеграции и зависимости от данных	Направляет циклы тестирования на значимые нагрузки
Участие разных команд	Basis, инфраструктура, функциональные команды, безопасность и интеграция присутствуют на прогонах	Не даёт перекладывать вину, когда обнаруживаются пробелы
Готовые инструменты и среды	Генераторы нагрузки (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), мониторинг и обновления данных готовы до начала циклов	Делает имитацию реалистичной
Реалистичные тестовые данные	Основные данные в производственном объёме, реальные вызовы интерфейсов, репрезентативный состав транзакций	Делает результаты прогнозом поведения при go-live
Отчётность по производительности	Состав нагрузки, время отклика, CPU и память, длительность заданий, доля ошибок	Даёт одобрению cutover доказательную базу
План мониторинга после go-live	KPI для наблюдения в течение первых 30–60 дней	Подтверждает, что работающая система остаётся в протестированных пределах

Четыре ошибки встречаются чаще всего, даже в крупных корпорациях со зрелыми моделями поставки.

Функциональное тестирование принимают за тестирование производительности. Функциональные тесты доказывают, что транзакция даёт верный результат. О том, как её запускают одновременно 150 человек, они ничего не говорят.

Тестирование на малых объёмах данных. Клиент с 200 000 открытых строк заказов ведёт себя иначе, чем клиент с 5000. Фильтры, которые мгновенно возвращают результат в тесте, в промышленной среде отваливаются по тайм-ауту. Заложите объёмы для областей высокого риска.

Оставлять производительность на Basis. Basis отвечает за sizing и планирование заданий. Он не отвечает за проектирование отчётов, архитектуру сервисов OData и проектирование интеграционных потоков, а именно они определяют производительность приложений.

Отдавать ответственность только QA. QA запускает тесты и сообщает результаты. Решения, из-за которых возникают проблемы с производительностью, принимают функциональные, технические команды и Basis на этапе проектирования. Руководителю тестирования программы или архитектору нужны полномочия оспаривать эти решения рано, а в RACI должно быть написано, кто может заблокировать go-live по причинам производительности.

RISE делит ответственность

В RISE with SAP компания SAP отвечает за инфраструктуру: sizing, регион гиперскейлера, сеть и доступность платформы. Клиент и партнёр отвечают за прикладной уровень. Документ SAP о ролях и ответственности в RISE говорит об этом прямо: поиск и настройка дорогих SQL-запросов остаются на стороне клиента, если вы не покупаете дополнительные прикладные сервисы SAP.

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

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

Public Edition и GROW сужают объём

В S/4HANA Cloud Public Edition, которую обычно покупают через GROW with SAP, SAP проводит тестирование производительности на своей мультитенантной платформе в рамках собственного стандарта продукта и не ожидает, что клиенты будут нагружать общую систему. Ваше тестирование смещается на то, что принадлежит вам: кастомные интеграции, расширения, высоконагруженные отчёты и аналитика, последовательность закрытия и консолидации и сетевой путь с ваших площадок. Проблемы производительности самой платформы передаются в поддержку SAP.

ИИ помогает со скриптами, но не с архитектурой

Поставщики инструментов нагрузочного тестирования добавляют ИИ для сопровождения скриптов и анализа результатов, и это помогает в программах, где приложение меняется между циклами. Проверяйте заявления на собственном ландшафте, прежде чем за них платить. SAP Cloud ALM может помочь генерировать тестовые случаи и требования, а ИИ-ассистенты могут набрасывать черновики сценариев по описаниям процессов.

Ничто из этого не исправляет архитектуру. ИИ не скажет вам, что сервис OData следовало спроектировать иначе или что отчёт слишком тяжёл для своих объёмов. Эти решения по-прежнему принимают люди, на этапе проектирования, до любого теста.

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

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

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

Функциональная корректность и производительность относятся к разным свойствам. Транзакция, которая корректна для одного пользователя, может отвалиться по тайм-ауту для 200. Задание, которое на тестовых данных выполняется десять минут, на производственных объёмах может идти часами. Если обнаружить это после go-live, это нарушает операции, вынуждает к срочным изменениям и подрывает доверие пользователей именно тогда, когда внедрение наиболее хрупко.

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

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

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

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

Программа, а не только QA. QA выполняет тесты и сообщает результаты, но решения, определяющие производительность, принимаются на этапе проектирования функциональными, техническими командами и Basis. Центральному архитектору или руководителю тестирования программы нужны полномочия оспаривать эти решения рано.

Зафиксируйте это явно в RACI: кто утверждает критерии приёмки, кто отвечает за устранение, если критерии не выполнены, и кто может заблокировать go-live по причинам производительности.

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

SAP отвечает за инфраструктуру: sizing, регион, сеть и доступность платформы. Клиент и партнёр отвечают за производительность приложений: конфигурацию, расширения, проектирование OData и Fiori, интеграционные потоки и KPI процессов. Документ SAP о ролях и ответственности в RISE оставляет настройку SQL на стороне клиента, если не покупаются дополнительные услуги SAP.

Запишите это разделение в критерии приёмки, чтобы у каждого порога был владелец.

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

Четыре паттерна покрывают большинство случаев. Шквал входов в начале смены, когда резко растёт нагрузка на аутентификацию и отрисовку launchpad. Сервисы OData, которые возвращают большие наборы результатов или делают несколько обращений к бэкенду на одно действие. Слой шлюза, который сам становится узким местом, поэтому его нужно мониторить во время тестов. И кастомные или сильно изменённые приложения, к которым стандартные допущения о производительности не применимы.

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

Назовите транзакцию, нагрузку и порог. Например: «Создание заказа завершается менее чем за 3 секунды для 95 % транзакций при 150 одновременных пользователях в роли ввода заказов». Это можно протестировать.

«Система должна быть достаточно быстрой» нельзя. Согласуйте критерии с бизнесом на фазе Prepare, исходя из реальных эксплуатационных потребностей, и не меняйте их после получения результатов.

Что произойдёт, если тестирование производительности пропустить или сжать?

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

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