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

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

Составьте задание на данные до выгрузки

Попросите тестировщика назвать действие, которое он собирается проверить, и ожидаемый результат. «Нужна база, как на рабочем сервере» слишком неопределённо. Для ошибки в распределении оплаты могут понадобиться несколько связанных документов; для проверки большого каталога — другой объём и другое распределение записей. Это разные наборы и разные способы подготовки.

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

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

Сохраните смысл связей, создавая сами записи заново

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

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

В учебной строке оплаты арифметика проста: 2400 − 900 = 1500. Если после операции система показывает нулевой долг по двум заказам, проблема воспроизведена без настоящих покупателей. Сохраните исходный набор и ожидание рядом с описанием теста: следующему исполнителю не придётся угадывать, что именно было подготовлено.

Различайте синтез, замену значений и скрытие на экране

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

В документации Pangolin об обфускации описана специальная функциональность маскирования. Название функции не заменяет проверку выбранного режима, прав и доступных каналов чтения. Перед использованием конкретного инструмента выясните, что он меняет, для какого пользователя и в каком результате запроса.

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

Проверьте места, которые не попадают в удобный список колонок

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

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

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

Отделите испытания от настоящей отправки

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

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

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

Принимайте набор по воспроизводимому сценарию

1. Запишите цель теста, нужные состояния и ожидаемые результаты, включая отрицательные случаи.
2. Составьте схему родительских и дочерних записей, выберите условные идентификаторы.
3. Создайте минимальный набор и проверьте связи, суммы, обязательность и допустимые значения.
4. Подготовьте безопасные файлы и тексты; проверьте остальные представления, нужные этому сценарию.
5. Подтвердите границы внешних действий и только затем передайте набор уполномоченному тестировщику.

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

При проверке безопасности разработки отдельно оцените основание работы с реальными сведениями, если без них действительно не обойтись. Техническое маскирование само по себе не доказывает выполнение всех требований к персональным данным. Для задачи, описанной здесь, предпочтителен набор, который изначально не содержит сведений настоящих клиентов.

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