Как мы упростили подготовку данных для тестирования

Привет, Хабр! Меня зовут Сергей Петровский, я руководитель IT-направления в СберТехе — компании, которая строит цифровой фундамент Сбера.

Мы создаём Platfrom V — облачную платформу с готовой средой разработки, компонентами и инструментами для быстрого создания бизнес-приложений. В этой статье расскажу об одном из сервисов Platform V, который решает проблему подготовки тестовых данных при тестировании сложных интеграционных сервисов.

SyntWork, о котором пойдёт речь, входит в семейство инструментов Platfrom V Works для agile-разработки. Эта статья — первая в цикле материалов о Works. В следующих статьях расскажем про другие инструменты: в Works много сервисов для agile-разработки, и каждый достоин отдельного материала.

Поехали!

В чём проблема с подготовкой тестовых данных

В том, что это долго и трудно.

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

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

А если backend приложения — это десятки автоматизированных систем, каждая из которых является самостоятельным продуктом со своим владельцем? Получается сложная архитектура, которую тем не менее нужно полностью повторить в тестовой среде.

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

Так перед нами встаёт задача подготовки связанных тестовых данных.

Связанные тестовые данные — это не плоская таблица со значениями в ячейках, а состояние целого стенда интеграционно-функционального тестирования (ИФТ) или приёмо-сдаточных испытаний (ПСИ).

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

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

Мобильное приложение и тестовые пользователи в данном случае — только пример. Вместо них могут быть виды услуг или другие сущности, которые нужно протестировать: тарифы, товарные позиции, услуги, учётные записи и сервисы в интеграционных системах.

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

Заранее оговоримся, что существуют разные виды тестирования. Здесь мы рассмотрим случаи, когда данные должны совпадать с имеющимися на проде, то есть относиться к реальным пользователям.

Главный вопрос, который приходится решать продуктовой команде, — как получить реальные данные, если зачастую они относятся к чувствительным и нельзя просто взять и скопировать их в тестовый контур?

Для этого у нас есть два подхода: обезличивание и синтез данных.

Как работаем с обезличиванием: self-service-инструменты

Есть две методики обезличивания:

• необратимое (ISO/IEC 29100 anonymization);

• обратимое (ISO/IEC 29100 pseudo-anonymization).

У каждой есть свои плюсы и минусы:

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

На самом деле в этом процессе много подводных камней, например:

• Как при автоматическом обезличивании понять, какие именно данные относятся к чувствительным?

• Как избежать случайного появления чувствительных данных во всех системах при очередном обновлении одной из баз данных?

• Как предупредить появление чувствительных данных на разных тестовых стендах?

Рассказываем, как мы решаем эти вопросы и проводим обезличивание данных.

Для поддержания целостности данных надо иметь карты взаимосвязей данных для каждой системы. Но в нашем IT-ландшафте создание такой карты — сизифов труд: работа заняла бы больше года, а данные устарели до того, как мы смогли бы воспользоваться картой.

Поэтому решили не делать карту целиком, а вместо неё дать продуктовым командам инструменты самообслуживания (self-service) для получения обезличенных данных.

Такими инструментами стали профилирование, легализация и алгоритмы обезличивания.

Профилирование — определяет, есть ли в базе чувствительные данные и где именно они находятся. Инструмент построен на базе ML-моделей и находит чувствительные данные с вероятностью 97%. При необходимости качество обнаружения можно повысить.

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

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

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

Если тестовые стенды надо регулярно обновлять данными с прома, процедуру легализации и обезличивания можно интегрировать в ETL-процесс.

Для пользователей self-service важно, чтобы после обезличивания не нарушалась связанность данных. На практике это не всегда работает, например, есть риск нарушения, когда связанность обеспечивается по полям типа «логин» или «номер паспорта».

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

Как работаем с синтезом данных: SyntWork

Для некоторых задач обезличивание как метод не подходит. Например, ни один тип анонимизации не решает задач, связанных с подготовкой данных для обучения ML-моделей во внешних средах. Если, скажем, у «Яндекса» есть достаточное количество данных, на которых мы могли бы обучить наши модели, то он всё равно не может ими поделиться из-за наличия чувствительных данных.

Поэтому для обучения используется синтез данных. Данные могут синтезировать ML-модели на базе GAN-сетей, обученных на реальных данных.

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

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

Решить эти вопросы нам помогает SyntWork, который, напомню, входит в состав Platform V Works — семейства инструментов для agile-разработки, командной работы и управления сквозным производственным процессом. Works позволяет выстроить полную архитектуру цикла DevOps, ускорить, упорядочить разработку и заместить зарубежные инструменты производственного процесса.

SyntWork — система генерации и управления синтетическими тестовыми данными. Принцип действия основывается на генерации связанных тестовых данных, описанных как сущности в entity-relationship diagram (ER-диаграмме) или в визуальном интерфейсе. Сущности — это объекты данных в автоматизированных системах. В нашем случае это могут быть: клиент, дебетовая карта, кредит.

У нас больше 3000 продуктовых команд. Продублировать тестовые среды для каждой команды и продукта невозможно, поэтому все пользуются одной большой средой. SyntWork позволяет работать не на уровне операций, а на уровне сущностей, чтобы QA-специалист мог выбрать сущности из набора доступных, выделить их под свой проект и настроить свойства, а всю рутину сделал бы за него «набор скриптов», подготовленных по шаблону.

Вот как это выглядит. На этапе подготовки к тестированию QA-специалист готовит в визуальном интерфейсе внешнюю по отношению к его продукту среду. Зная нужный набор тестовых данных и состояний систем, ищет нужный шаблон среди готовых, например, «пользователь с банковскими картами X и услугами Y». Шаблоны предустановлены в системе или созданы другими пользователями.

Тестировщик получает набор артефактов по выбранным сущностям и шаблонам — ФИО, номер карты, логин тестового пользователя, затем отслеживает статусы по всем системам и видит, готовы ли они работать с тестовыми данными, чтобы он мог приступить к тестированию функционала.

Ценность такого подхода в том, что специалист не тратит время на подготовку тестовой среды вручную или самодельными скриптами и видит состояние «здоровья» задействованных систем в его тестовых сценариях.

Как устроен SyntWork

Сервис решает следующие задачи:

• репозиторий бизнес- и тестовых сценариев, связанных с получением тестовых данных;

• переиспользование способов генерации тестовых данных;

• снижение трудоёмкости подготовки связных тестовых данных для проведения ИФТ и ПСИ;

• упрощение работы QA-специалистов: им необязательно знать, как строить полные цепочки связных данных, осваивать технологии и автоматизацию другой команды или общаться с поставщиками данных;

• единый канал обращений пользователей тестовых данных и администраторов тестовых стендов;

• мониторинг «здоровья» тестовых сценариев и систем;

• тиражирование тестовых сценариев;

• подключение модулей обезличивания и синтеза данных по запросу.

Допустим, в компании есть тестовый контур с множеством тестовых АС, имитирующих продуктивную среду. У каждой АС — свой владелец и свои правила взаимодействия со смежными системами.

QA-специалисту регулярно нужны тестовые пользователи с заданным набором метапараметров — подключённые услуги, выданные сертификаты, открытые счета. Все эти услуги и счета создаются в тестовых контурах АС 1 — АС N.

За создание сущностей отвечает архитектор. Он знает, какие вызовы АС 1 — N нужны для создания, например, нового пользователя, и описывает эти действия в виде Job-в в Jenkins. Таким образом сложная последовательность вызовов в тестовом контуре превратилась в запуск Job-а.

Теперь нужно выстроить логику со связанными данными, например, пользователь — счёт 1, счёт N. За формирование этой логики и отвечает SyntWork. Архитектору достаточно занести сущности в модель данных сервиса, и у QA-специалиста будет инструмент для создания связанных тестовых данных в любых объёмах!

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

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

Чтобы подготовить тестовые данные, тестировщику достаточно нажать кнопку в пользовательском интерфейсе и проследить, чтобы процесс подготовки прошёл по плану, а тестовые АС не выдали ошибку. Если что-то пойдёт не так, сбой отобразится в пользовательском интерфейсе, а специалист сможет быстро диагностировать проблему — и это тоже положительно скажется на общем time-to-market.

Наконец, ещё один бонус — тестировщику не нужно придумывать множество фамилий, номеров счетов, телефонов. В SyntWork есть генераторы, которые заполняют поля реалистичными данными, так что в итоговом наборе точно не будет значений вроде «123123» или «qwerty».

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

Есть такой стандарт PCI DSS — Payment Card Industry Data Security Standard. Он касается безопасности индустрии платёжных карт. PCI DSS нужно соблюдать даже по отношению к тестовым пользователям с тестовыми банковскими картами. То есть для того чтобы сгенерить тестовую карту, нужно дать доступ QA-специалисту к защищённому контуру — а это в принципе невозможно.

Тут на помощь приходит SyntWork. Сервис выступает как прокси между системой, соответствующей нормам PCI DSS, и продуктовыми командами. Благодаря инструментарию управления сущностями специалисты, ответственные за безопасность, могут создавать шаблоны и цепочки действий, отвечающие требованиям стандарта. А QA-специалист получает уже артефакты работы этих действий и может оперировать тестовыми банковскими картами, не нарушая защищённого периметра.

Структура сервиса

Давайте разберём, что такое модель данных, которую создаёт архитектор. По сути, это описание последовательности действий АС для создания нужной сущности. Эту последовательность может выполнить любая подходящая среда, например Jenkins, Apache Nifi, Cron или любая другая. Такую среду мы называем executor.

Интересно, что executor может быть и ручным. Это нужно, например, когда специалист что-то выполнил вручную и записал результат в интерфейс пользователя.

В поставку SyntWork входит ядро, в котором есть логика работы с сущностями: возможность создавать модели данных, шаблоны, взаимосвязи данных. Также входит пользовательский интерфейс, executor Apache Nifi и визуальный интерфейс ручного executor-а.

Роли пользователей

QA-специалист/Тестировщик

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

Архитектор

Создаёт и изменяет сущности в SyntWork, а также настраивает способы их генерации. 

Администратор

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

Итоги

При разработке продуктов в сложной интеграционной среде тестирование может существенно влиять на time-to-market. А при наличии множества продуктовых команд, которые хотят одновременно использовать одну и ту же тестовую среду, не обойтись без системы генерации и управления тестовыми данными.

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

Сервис не привязан к сфере бизнеса, так как созданием сущностей для тестирования занимаются архитекторы внутри компании. А основная ценность инструмента — возможность задавать связи этих данных и следить за их консистентностью — содержится в ядре, которое никак не привязано к специфике или отрасли бизнеса.