Представьте себе крупный банк, который обслуживает десятки миллионов транзакций частных клиентов ежедневно: поступления зарплат, выдача наличных, платежи за сотовую связь и Интернет, покупки в обычных и интернет-магазинах, бонусные программы и т.д. Обработка таких транзакций осуществляется в автоматическом режиме с минимальным участием человека.
Бизнес банка устойчив, постепенно количество клиентов растет, а количество транзакций растет еще быстрее. Ответственные лица в банке понимают, что старое оборудование и программное обеспечение имеют ограниченные возможности и вскоре наступит момент, когда существующие ресурсы системы будут исчерпаны. Заранее начинается работа по наращиванию возможностей системы. Это может быть закупка более быстро действующего оборудования или замена программного обеспечения, а может быть и то и другое вместе. Прежде чем новая система будет введена в эксплуатацию, нужно убедиться, что она работает. Ибо в случае неудачи это нанесет по репутации организации катастрофический удар.
С этой целью проводится тестирование возможностей системы. Довольно длительное и затратное мероприятие. Проверяются функциональные возможности системы, позволяет ли она выполнять необходимые операции. Но более существенна в данном случае не возможность проведения единичных конкретных транзакций, а способность системы выдерживать поток операций, сопоставимых с тем потоком, который на нее обрушится в процессе эксплуатации.
Для оценки соответствия системы новым требованиям проводится нагрузочное тестирование. С помощью специальных программных и аппаратных средств банковская система нагружается запросами, а специалисты наблюдают за ее поведением. В процессе такого тестирования выявляются специфические ошибки. Их причины могут быть самыми разными: недостаточная пропускная способность каналов связи, несовместимость с другими системами, используемыми банком, несовершенство нового программного обеспечения и т.д. Но ключевыми ошибками, выявляемыми в ходе нагрузочного тестирования, являются ошибки, связанные с базами данных.
От того, как банк хранит информацию о клиентах, зависит быстродействие обработки информации. На небольших объемах это может быть незаметно, но с ростом количества операций сложность обработки растет и несовершенства проявляются в виде неспособности системы обработать запросы пользователей. Понятно, что если дать высокую нагрузку, то любая система сломается. Мастерство нагрузочного тестирования заключается в способности предусмотреть именно ту нагрузку, с которой будет работать система в период ее эксплуатации.
И тут критичным становится вопрос: насколько используемая база данных отражает реальность, с которой система столкнется в процессе эксплуатации. Естественно, тестировать систему на реальной базе данных неприемлемо по соображениям безопасности. К тому же это репутационный риск. Многие клиенты панически боятся, что данные об их банковских операциях могут стать общедоступными.
В таком случае можно создать тестовую базу данных. Пишутся программы, которые создают случайных вымышленных пользователей в отдельной базе данных, по структуре аналогичной базе данных клиентов, используемой банком. Этим вымышленным клиентам заводятся счета, делается история операций – почти все как у реальных клиентов. Но практика показывает, что реальная жизнь гораздо более насыщена случайностями и сложностями, чем может представить фантазия одного или даже команды программистов, создающих тестовую базу данных. Например:
- у одного клиента может быть один счет, а другого – сотни;
- к одному счету может быть привязано более одной банковской карты;
- счета могут быть арестованы;
- может быть разная интенсивность операций;
- могут быть многочисленные переводы между картами внутри банка, которые должны быть синхронизированы.
Попытки сделать тестовые базы данных максимально близкими к реальным связаны с резко увеличивающейся сложностью работ по мере приближения к оригиналу. Это связано с затратами времени и труда высокооплачиваемых специалистов. Но самое главное ограничение по срокам обусловлено планами банка, что, в свою очередь, диктуется конкурентной борьбой на рынке банковских услуг.
В условиях, когда нужно быстро создать нечто подобное базе данных, используемой конкретным банком, с десятками миллионов уникальных пользователей, на помощь приходит обезличивание. Чем пытаться создавать новую тестовую базу данных, похожую на оригинал, проще и гораздо дешевле взять оригинал и изменить его до неузнаваемости владельцев конкретных счетов. Обезличенную базу данных можно использовать в тестировании.
