Данные личности для тестирования — это записи о выдуманных людях: имена, номера документов, даты рождения, адреса, телефоны и почтовые ящики, собранные так, чтобы выглядеть правдоподобно. Такие записи нужны там, где систему надо проверить, а сведения о реальных клиентах или сотрудниках в проверку попадать не должны. Ниже разберём, из чего состоит одна такая запись, в каких ситуациях без неё не обойтись и как получить готовый набор, не собирая значения по частям вручную.
Что входит в тестовую запись о человеке
Полноценная запись описывает человека целиком, а не одним полем. Обычно в ней четыре смысловые группы. Первая отвечает на вопрос «кто это»: полное имя, дата рождения, пол. Вторая описывает документ: его тип и номер, причём номер построен по правилам конкретной страны. Третья — контакты: телефон с кодом страны и адрес электронной почты. Четвёртая — местоположение: улица, город, административная единица и почтовый индекс.
Группы связаны между собой, и это важнее, чем кажется на первый взгляд. Номер документа следует формату страны, которую выбрал пользователь. Телефон несёт код той же страны. Адрес и индекс принадлежат ей же, а не соседней. Дата рождения определяет возраст, который увидит проверяющий. Если собрать поля из разных стран, запись получится правдоподобной на вид и бессмысленной по сути, и об этом стоит помнить при подготовке любых наборов.
Почему настоящие сведения портят тестовую среду
Соблазн понятен: если в рабочей базе уже лежат заполненные профили, быстрее скопировать их часть, чем что-то придумывать. Проблема в том, что создаёт такая копия.
Тестовый контур обычно защищён слабее рабочего: больше людей имеют доступ, меньше внимания к тому, кто и зачем смотрел запись, а сроки хранения почти никогда не соблюдаются. Копия, оставленная на машине разработчика, переживёт любую политику удаления, потому что о ней просто забудут. Такие записи всплывают на скриншотах, в отчётах об ошибках и в примерах, которыми команды обмениваются между собой.
Есть и вторая, менее очевидная цена. Когда тестовая база собрана из рабочих записей, никто точно не знает, что в ней лежит: какие поля заполнены, какие значения считаются нормальными, что произойдёт после очередной выгрузки. Синтетический набор можно описать полностью, и это делает результаты проверок сравнимыми между запусками.
И главное: имя, номер документа, дата рождения, адрес и телефон остаются персональными данными независимо от того, принимает ли кто-то по ним решение. Вред от утечки связан с конкретным человеком, а не с количеством строк, поэтому даже несколько настоящих записей в тестовой среде — это уже инцидент.
Когда без таких записей не обойтись?
Есть несколько типовых ситуаций, где выдуманные люди решают задачу целиком.
- Проверка форм. Поля нужно испытать на форматах разных стран, а просить документы у живых людей ради теста никто не станет.
- Демонстрации и обучение. Показывать заполненный интерфейс удобнее, чем пустые поля, но демонстрация на профиле настоящего клиента — это утечка.
- Нагрузочные проверки. Заполнить базу тысячами согласованных записей реальными сведениями невозможно, а сгенерированными — легко.
- Проверка отображения. Длинные имена, диакритика, нелатинские символы и составные фамилии ломают вёрстку, о которой никто не подумал.
Отдельно стоит упомянуть сценарии регистрации: если вы проверяете, как ведёт себя форма создания аккаунта, полезно посмотреть разбор тестирования регистрации с почтой — там речь о том же подходе, но со стороны адреса электронной почты. Во всех перечисленных случаях цель — испытать программу, а не человека, поэтому запись должна быть похожей на настоящую, но не быть ею.
Чем синтетическая запись отличается от настоящей?
Разница не в том, как запись выглядит, а в том, что с ней можно делать.
| Свойство | Запись о реальном человеке | Синтетическая запись |
|---|---|---|
| Есть владелец | да | нет |
| Можно хранить в репозитории | нет | да |
| Подходит для проверки формата | да | да |
| Подходит для демонстрации | не должна | да |
| Требует срока хранения и удаления | да | нет |
| Переживает смену команды | да, и это проблема | да |
Из таблицы видно главное: синтетическая запись существует только как данные, у неё нет человека за спиной. Сгенерированные значения предназначены исключительно для тестирования, и их нельзя использовать, чтобы выдать себя за реального человека: они не проходят проверку личности, не открывают счета и не заменяют документы.
Как получить такие записи в браузере
В генераторе данных личности выбирают страну или регион, при необходимости административную единицу и пол, и получают полную запись: имя, дату рождения, номер документа, адрес, телефон и онлайн-профиль. Поля выходят согласованными, потому что берутся из одной записи, а не набираются по отдельности.
Второй полезный механизм — ключ личности. Это строка, которая определяет все случайные значения: один и тот же ключ, страна и пол всегда дают в точности одну и ту же запись. Это позволяет закрепить образец в автоматическом тесте и назвать конкретную запись в отчёте об ошибке, вместо того чтобы описывать её словами. Для больших наборов есть пакетная генерация с выгрузкой в таблицу или текстовый файл.
Что важно разработчику: поля и их зависимости
Первое решение — заранее разметить, какие поля ваша система действительно читает. Внутренние группы записи почти всегда шире, чем то, что показывает интерфейс, и лишние поля только создают ложное чувство полноты.
Второе — определиться, что тест ожидает от записи. Если он сравнивает результат с эталоном, запись должна быть одинаковой при каждом запуске, иначе проверка будет падать через раз без внятной причины. Если тест спрашивает, принимает ли система любые правдоподобные данные, разумнее каждый раз брать новую запись: так находятся дефекты, которых фиксированный образец не покажет. Смешивать эти два режима в одном наборе — самая частая ошибка, и о том, как её избежать, подробно рассказано в статье про данные личности в тестовых наборах.
Отдельно стоит сказать про контрольные цифры. Во многих системах нумерации последний знак или два вычисляются по опубликованному правилу — как правило, это взвешенная сумма с остатком от деления. Такая цифра помогает поймать опечатку и перестановку соседних знаков, но ничего не говорит о том, существует ли человек с этим номером. Проверка контрольной цифры подтверждает форму записи, а не личность, и путать эти вещи в формулировках интерфейса не стоит.
Третье — помнить о зависимостях между полями. Возраст выводится из даты рождения, формат телефона — из страны, адрес должен принадлежать той же стране, что и документ. Если генератор или ручная правка нарушает эти связи, тест может пройти на записи, которой не бывает в действительности, и пропустить настоящий дефект. Проверка таких сочетаний разобрана в материале про согласованность полей.
Что делать дальше
Возьмите один сценарий, который сейчас проверяется на копии рабочей базы, и замените копию на синтетические записи: сгенерируйте несколько записей в генераторе, зафиксируйте ключ для автоматического теста и отметьте в самом тесте, ждёт он стабильную запись или новую. Такой порядок снимает две проблемы сразу: настоящие сведения перестают попадать в тестовый контур, а упавшая проверка снова становится воспроизводимой.