Управление тестовыми данными SAP: маскированные данные продуктивного масштаба

Управление тестовыми данными SAP означает, что каждая тестовая система получает данные, которые ведут себя как продуктивные, но не раскрывают сведения о реальных людях. Моё правило простое: маскированные данные, но продуктивного уровня, по объёму и по реалистичности.

Скудные данные, созданные вручную, скрывают важные дефекты. Немаскированные продуктивные данные помещают записи о клиентах, поставщиках и сотрудниках в системы с более слабым контролем, чем продуктивная.

Тестовые данные это часть более широкого плана тестирования. Виды тестов, их владельцы и их место в SAP Activate описаны в моём руководстве тестирование SAP простыми словами.

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

Самая частая ошибка тестирования, которую я видел: недостаточно тестирования в системном интеграционном тестировании (SIT) и в приёмочном тестировании (UAT). Слабые тестовые данные один из способов, которыми это тихо происходит. Тестовые сценарии выполняются, результаты зелёные, а сценариям, которые сломались бы, просто не на чем было сломаться.

Поэтому я настаиваю на данных продуктивного уровня. Это означает четыре вещи:

1. Объём. Размеры таблиц близки к продуктивным, чтобы отчёты, задания и поиск работали на реалистичном числе строк.
2. Разнообразие. Необычные записи, которые действительно есть в продуктивной системе: заблокированные поставщики, частичные поставки, кредитовые авизо, иностранные валюты, старые открытые позиции.
3. История. Достаточно закрытых периодов, чтобы анализ по срокам, амортизация и прогоны закрытия года имели смысл.
4. Целостность. Документы по-прежнему правильно связаны между модулями после копирования и после маскирования.

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

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

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

Общий регламент ЕС по защите данных (GDPR) служит ориентиром для большинства организаций, и многие национальные законы следуют похожей логике. Пункт 26 преамбулы GDPR проводит различие, которое должна знать каждая команда SAP.

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

Практическое следствие: большая часть маскирования даёт псевдонимизированные, а не анонимные данные. Маскированной тестовой системе всё равно нужны контроль доступа, цель обработки и правило хранения. Попросите своего специалиста по защите данных (DPO) согласовать правила маскирования до первой копии, а не после вопроса аудитора.

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

Таблица сравнивает их по признакам, которые определяют, подходит ли метод.

Метод	Что вы получаете	Объём	Защита персональных данных	Где подходит лучше всего
Полная копия системы	Точная копия продуктивной системы, все манданты и таблицы	Полный	Маскирование должно пройти после копирования, до того как пользователи получат доступ	Нагрузочные тесты, пробные конверсии, репетиции перехода
Копия манданта	Один мандант, скопированный внутри системы или между системами; профиль копирования определяет, копируются ли основные и транзакционные данные	Полный или только настройки	Как у копии системы, если копируются данные приложений	Новые тестовые или учебные манданты, возврат манданта в известное состояние
SAP Test Data Migration Server (TDMS)	Уменьшенная копия, выбранная по времени или организационной единице, со скремблированием	Уменьшенный	Правила скремблирования внутри инструмента	Существующие ландшафты SAP Business Suite, где он уже лицензирован
Партнёрские инструменты выборочного копирования	Выбранные бизнес-объекты или срезы, копируемые по запросу и маскируемые на лету	Уменьшенный, целевой	Правила маскирования внутри инструмента, применяемые при копировании	Регулярные обновления, данные для регрессии, воспроизведение дефектов
Созданные или мигрированные данные	Данные, созданные скриптами, загрузками миграции или вручную	Сколько создадите	Реальных персональных данных нет, если всё создано с нуля	Ранние модульные тесты, проекты greenfield до go-live

Полные копии системы и копии мандантов

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

Копия манданта это повседневный инструмент для создания и сброса мандантов. Решающее значение имеет профиль копирования, потому что он определяет, переносятся ли только настройки или вместе с ними основные и транзакционные данные.

SAP Test Data Migration Server

SAP Test Data Migration Server (TDMS) создаёт уменьшенные непродуктивные системы из продуктивных данных, со скремблированием чувствительных полей. Он вырос на SAP Business Suite, а текущий комплект документации на SAP Help Portal относится к релизу 4.0 SP14.

Я не нашёл официального заявления SAP о поддержке TDMS в текущих релизах S/4HANA или о названном преемнике. Если вы собираетесь на него опираться, письменно спросите SAP, поддерживает ли он ваш целевой релиз и модель развёртывания, включая RISE with SAP.

SAP Landscape Transformation и shell-копии

SAP Landscape Transformation это набор инструментов анализа и преобразования, которые SAP использует при selective data transition. SAP Learning описывает shell-конверсию как копию продуктивной системы без основных и транзакционных данных, которую затем конвертируют в S/4HANA.

Та же идея помогает и с тестовыми данными. Shell-копия даёт репозиторий и настройки продуктивной системы без бизнес-данных, а затем вы наполняете её только теми данными, которые нужны тесту.

Несколько партнёрских продуктов копируют выбранные бизнес-данные в тестовые системы SAP и маскируют их по пути. Вот те, чьи заявления я смог проверить на собственном сайте поставщика, в произвольном порядке.

1. EPI-USE Labs Data Sync Manager. Набор для копирования и маскирования данных в ландшафтах SAP ABAP, включая облегчённые манданты, копирование на уровне объектов и маскирование по предопределённым правилам. EPI-USE Labs заявляет, что Data Sync Manager сертифицирован для интеграции с SAP S/4HANA и S/4HANA Cloud и работает с RISE with SAP.
2. SNP Kyano Test Data Organizer. Извлекает данные, нужные тесту, а не всю систему, и маскирует чувствительные данные при их предоставлении. SNP описывает Test Data Organizer как совместимый с RISE with SAP Private Cloud Edition.
3. Qlik Gold Client. Копирует и синхронизирует выбранные транзакционные данные из продуктивной системы в непродуктивные, со статическим маскированием для существующих систем и динамическим маскированием данных при передаче.
4. Natuvion DCS Protect. Находит персональные данные и применяет анонимизацию или псевдонимизацию в системах тестирования, качества, разработки и обучения. Natuvion позиционирует его для тестовых миграций и для текущей эксплуатации, но на этой странице не упоминает S/4HANA, поэтому уточните поддержку напрямую.

До покупки попросите каждого поставщика ответить на эти вопросы на ваших собственных системах:

1. Какие релизы S/4HANA и модели развёртывания он поддерживает сегодня?
2. Маскирует ли он данные до того, как они покинут продуктивную систему, или после того, как они попадут в целевую?
3. Остаётся ли маскирование согласованным между связанными системами, чтобы клиент, замаскированный в S/4HANA, совпадал с тем же клиентом в вашей CRM или хранилище данных?
4. Сколько занимает обновление одной балансовой единицы на продуктивных объёмах?
5. Кто сопровождает правила маскирования, когда вы добавляете собственные таблицы или поля?

Каждой фазе тестирования данные нужны по своей причине. С этого я начинаю, когда планирую тестовые данные в программе S/4HANA.

Фаза тестирования	Что должны делать данные	Обычный источник
Модульное тестирование	Позволить разработчику доказать, что один объект работает	Созданные данные или небольшой маскированный срез
Циклы системного интеграционного тестирования	Прогонять полные цепочки процессов через модули и интерфейсы	Маскированная копия продуктивного уровня или выборочная копия
Циклы приёмочного тестирования	Выглядеть как собственные данные бизнес-пользователей, чтобы они узнавали свои случаи	Маскированные данные продуктивного уровня, обновляемые перед каждым циклом
Регрессионное тестирование	Оставаться стабильными, чтобы результаты можно было сравнивать от прогона к прогону	Фиксированный набор данных с возможностью сброса плюс план обновления
Нагрузочное тестирование	Соответствовать продуктивному объёму, чтобы результаты тестов параллельной работы что-то значили	Полная маскированная копия или объём продуктивного масштаба
Пробные конверсии и репетиции перехода	Доказать миграцию на реальной структуре данных	Полные копии продуктивной системы, маскированные там, где есть доступ у людей вне основной команды

UAT заслуживает особого внимания. Приёмочное тестирование должно принадлежать бизнесу, и, на мой взгляд, на него нужно минимум от 6 до 8 недель.

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

С пробными конверсиями та же логика. При конверсии brownfield я планирую три пробные конверсии, и каждая должна идти на свежей копии продуктивной системы.

По моему опыту, миграция данных занимает от 30 до 40 процентов трудозатрат программы, поэтому планируйте доступ к данным для этих прогонов вместе с командой миграции. Как сочетаются пробные загрузки, объясняет моя статья о том, почему миграция данных SAP терпит неудачу.

Два ландшафта, два плана обновления

Во время программы я держу два отдельных ландшафта: один для проекта и один для текущей деятельности (BAU). Тогда изменения сопровождения и изменения проекта тестируются раздельно.

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

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

Тестирование занимает около 35 процентов трудозатрат программы. Планируйте тестовые данные внутри этих трудозатрат, а не за неделю до SIT.

Вот порядок, которому я бы следовал:

1. Согласуйте принцип письменно. Маскированные данные продуктивного уровня, подписанные спонсором программы, специалистом по защите данных и владельцами бизнеса.
2. Найдите персональные и чувствительные данные. Клиенты, поставщики, сотрудники, банковские реквизиты, контакты, поля свободного текста, вложения и любые собственные таблицы, которые их содержат.
3. Напишите правила маскирования. Решите по каждому полю, что заменяется, сохраняется или удаляется, и держите замены согласованными между связанными системами.
4. Сопоставьте данные с каждой фазой тестирования. Возьмите таблицу выше как отправную точку и сначала определите объём для нагрузочных тестов и тестов параллельной работы.
5. Выберите методы копирования и инструменты. Полные копии там, где важен объём, выборочные копии там, где важны скорость и частота, и проверьте поддержку инструментом вашего релиза.
6. Задайте календарь обновлений. Один план на ландшафт, с обновлениями перед каждым циклом SIT и UAT и перед каждой пробной конверсией.
7. Закройте доступ, пока маскирование не проверено. Никто вне основной технической команды не входит в свежую копию, пока проверка маскирования не пройдена.

Затем сделайте из этого контрольную точку. Стратегия, критерии входа и критерии выхода для каждого цикла описаны в моём руководстве по стратегии тестирования S/4HANA, и готовность тестовых данных должна входить в критерии входа каждого цикла.

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

Если вам нужен независимый взгляд на подход к тестовым данным или план тестирования программы S/4HANA, вы можете связаться со мной здесь.

Что такое управление тестовыми данными SAP?

Это то, как вы планируете, создаёте, копируете, маскируете и обновляете данные в тестовых системах SAP. Цель: данные, которые ведут себя как продуктивные по объёму и реалистичности, не раскрывая реальные персональные данные людям, которые не должны их видеть.

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

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

Доступен ли SAP TDMS для S/4HANA?

Текущая документация TDMS на SAP Help Portal относится к релизу 4.0 SP14, а сам TDMS вырос на SAP Business Suite. Я не нашёл официального заявления SAP о его поддержке текущих релизов S/4HANA. Спросите SAP письменно, прежде чем строить на нём планы.

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

SAP Test Data Migration Server, а также партнёрские продукты, такие как EPI-USE Labs Data Sync Manager, SNP Kyano Test Data Organizer и Qlik Gold Client. Natuvion DCS Protect сосредоточен на анонимизации и псевдонимизации данных в тестовых системах. Проверьте каждый на соответствие вашему релизу S/4HANA и модели развёртывания.

Сколько тестовых данных нужно для тестирования производительности SAP?

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