Не приложение генерит данные а данные позволяют сгенерировать приложение
Хорошие тестовые данные улучшают качество разработки и тестирования приложений.
Но если вы будете вводить данные в тестовую среду вручную, через UI, вы никогда не нарастите столько данных, сколько ваше приложение накопит всего за несколько дней в продакшене. К тому же, данные, которые вы вводите, будут ориентированы на ваши собственные шаблоны поведения, а они, скорее всего, будут отличаться от реальных. В результате некоторые ошибки могут остаться незамеченными.
Некоторые команды разработчиков приложений требуют, чтобы их тестовые базы данных наполнялись из баз данных с продакшена. Но использование реальных данных связано с определенными рисками с точки зрения защиты конфиденциальности.
В этой статье мы собрали десятку самых популярных генераторов тестовых данных.
1. DATPROF Privacy
Этот инструмент маскирует ваши тестовые данные и на их основе генерирует синтетические. Таким образом сведения о ваших пользователях будут защищены, а вы получите репрезентативные тестовые данные.
DATPROF Privacy:
- генерирует синтетические данные
- сохраняет характеристики данных
- отличается высокой производительностью при работе с большими датасетами
- поддерживает XML и CSV файлы.
2. Redgate SQL Data Generator
Этот инструмент способен быстро создавать большие объемы реалистичных данных.
Особенности:
- «умная» генерация данных
- больше 60 встроенных генераторов с опциями тонкой настройки
- можно писать собственные пользовательские генераторы на Python и с их помощью создавать именно те данные, которые вам нужны
- поддержка командной строки для автоматизированной генерации данных
- импорт данных из существующих источников
- поддержка внешних ключей для генерации связанных данных в разных таблицах
3. Test Data Manager
Этот инструмент позволяет быстро находить, защищать, проектировать и создавать подходящие данные для эффективного тестирования приложений.
При помощи Test Data Manager вы получите нужные данные в нужном месте и в нужное время, что существенно ускорит вашу работу.
Test Data Manager не только генерирует синтетические данные. Он еще и анализирует покрытие тестовыми данными, чтобы создавать минимально необходимый для надежного тестирования датасет.
Также реализована функция сохранения созданных датасетов. Сохраненные наборы данных можно использовать повторно, клонировать и подгонять под другие нужды.
4. Solix Test Data Management
Приложение Solix Test Data Management автоматизирует создание поднаборов (не клонов) баз данных с разумным размером, что позволяет сэкономить до 80% места для хранения. При этом копия производственной базы данных будет синтаксически правильной: это важно для достижения наиболее точных результатов тестирования.
Solix Test Data Management также предлагает маскировку данных для защиты от утечек.
5. SAP Test Data Migration Server
SAP Test Data Migration Server позволяет создавать непроизводственную среду, используя выдержки из бизнес-данных. Это помогает снизить расходы на поддержку и инфраструктуру и одновременно повысить эффективность разработки и тестирования.
SAP TDMS обеспечивает связность и целостность данных в ходе миграции проектов из производственных в непроизводственные системы.
С помощью этого инструмента вы сможете быстро заполнять ваши системы разработки и тестирования настоящими SAP бизнес-данными из вашей производственной среды. Данные при этом могут быть зашифрованы.
6. DTM Data Generator
Инструмент для генерации строк данных для целей тестирования: для наполнения тестовой базы данных, анализа производительности и т. д.
Этот генератор позволяет создавать высококачественные и реалистичные тестовые массивы. С его помощью пользователи могут проектировать сложные тестовые данные с зависимостями, внутренней структурой и связями.
DTM Data Generator поддерживает все популярные системы баз данных: Microsoft SQL Server, Oracle, IBM DB2, Sybase, Informix, MySQL, PostgreSQL, Interbase/Firebird.
7. Mockaroo
Mockaroo позволяет бесплатно генерировать до 1000 строк реалистичных тестовых данных (большее количество строк уже платное). Данные выгружаются в форматах CSV, JSON, SQL и Excel.
С помощью Mockaroo вы сможете быстро и легко загружать большие объемы тестовых данных, сгенерированных случайным образом на основе ваших собственных спецификаций.
8. GenerateData
Проект с открытым исходным кодом, хостится на GitHub. Данные можно сгенерировать прямо на сайте. Вам предоставляется простой и понятный пользовательский интрефейс и возможность просматривать, что вы генерируете.
С помощью GenerateData можно создавать больше 30 типов данных (имена, email-адреса, страны и т. д.). При этом данные могут быть связаны между собой (например, страна, область и город).
Данные генерируются в 10+ форматах (JSON, CSV, XML, SQL и т. д.). Если заведете себе аккаунт, можно будет сохранять свои датасеты.
9. ApexSQL Generate
Генерирует случайные тестовые данные для SQL-сервера.
- может генерировать тестовые данные в указанные таблицы
- экспорт в SQL, XML, CSV, JSON, Excel
- способен быстро сгенерировать миллионы строк
- данные можно кастомизировать
- можно выбирать из нескольких генераторов
- создает данные, похожие на настоящие.
10. GenRocket
Сервис для генерации реалистичных тестовых данных. GenRocket позволяет QA-специалистам полностью автоматизировать процесс подготовки тестовых данных и без проблем интегрировать его в автоматизированное тестирование.
В GenRocket есть больше 150 генераторов различных типов данных. Выгружать данные можно в XML, JSON, SQL, CSV, JDBC, REST, SOAP.
Ниже приведен отобранный список инструментов генерации тестовых данных с их популярными функциями и ссылками на веб-сайты. Список содержит как открытое (бесплатное), так и коммерческое (платное) программное обеспечение.
1) DATPROF
DATPROF упрощает получение правильных данных испытаний в нужный момент. С DATPROF Privacy вы можете маскировать свои тестовые данные и генерировать синтетические данные. Ваши данные о клиентах защищены, но команды разработчиков могут по-прежнему использовать репрезентативные тестовые данные.
Особенности:
- Сохранить характеристики данных
- Высокая производительность на больших наборах данных
- Согласованно для нескольких приложений и баз данных
- Встроенные генераторы синтетических данных
- Поддержка интеграции CI / CD (непрерывная интеграция и непрерывная доставка)
- Управляйте своими средами тестовых данных и обновляйте их с одной центральной платформы.
2) Генератор данных Redgate SQL
Redgate SQL Data Generator creates a large volume of data within a couple of clicks. It supports foreign keys for generating consistent data across more than one level.
Features:
- This data generator tool provides flexibility and manual control for creating foreign key data.
- It has more than 60 inbuilt generators with numerous sensible configuration options.
- You can save SQL statements and regexp generators to share with your team.
- This tool provides support for the command line to generate automated data.
- It allows you to import data from existing data sources.
- Redgate SQL data generator automatically converts data when source data is of the different data types.
- It offers flexibility and manual control for creating foreign key data.
3) Informatica Test Data Management
Informatica Test Data management is an application that automated data connectivity and test data-generation capabilities.
Features:
- This tool automatically finds data locations for consistent masking (the process of hiding original data with edited content) across databases.
- Informatica support for packaged applications to make sure application integrity and speed deployments.
- It offers monitoring and compliance reporting.
- Testers can store, share, augment, and Reuse test datasets to increase their efficiency in software testing.
- It provides a comprehensive set of masking techniques that can constantly mask various data across applications.
4) Double
Features:
- Data management options are available for a range of test data, including T-Doble software, SFRA (Sweep Frequency Response Analysis), and DTA (Domestic Tariff Area).
- It allows you to choose which options are needed for your organization
- You can easily manage data management projects tailored to your business practices.
- It allows you to organize data across departments, divisions, and regions.
5) InfoSphere Optim
IBM InfoSphere Optim is a test data creating an application that increases performance, empower collaboration across applications and databases across platforms.
Features:
- You can archive data from historical transaction records and decommissioned applications, decommissioned applications, and historical transaction records.
- Comprehensive test data management capabilities.
- It provides a single scalable archiving solution for the enterprise.
6) CA Test Data Manager
CA Test Data Manager is a tool for generating test data. You can use it to store, manage, find, edit, mask, and subset data. It enables you to centrally store data as a reusable asset.
Привет, Хабр. Меня зовут Дмитрий Гусаков. Я тимлид команды QA в компании Arenadata. Наша команда занимается тестированием компонентов Arenadata Enterprise Data Platform, в том числе тестированием оркестратора гибридного data-ландшафта Arenadata Cluster Manager. Каждый день мы пишем и актуализируем большое количество тестов для API. Поэтому сегодня я хочу обсудить тему автоматической генерации таких тестов и поделиться с сообществом нашими решениями и опытом.
Для начала давайте подумаем, что приходит вам в голову, когда вы слышите слово «автотесты».
Согласно терминологии ISTQB:
«автоматизация тестирования (test automation): использование программного обеспечения для осуществления или помощи в проведении определённых тестовых процессов, например, управление тестированием, проектирование тестов, выполнение тестов и проверка результатов».
Лично для меня автотесты — это классный способ избавиться от ручного регресса и не делать одно и то же по сто раз. Но у всего есть своя цена, даже у классных способов. Для автотестов это их разработка и поддержка. Как минимизировать время разработки и не писать тысячу раз похожие тесты для соседних endpoints в API? И как сделать этот процесс удобным для использования в будущем? Давайте разбираться!
Базовые требования к тестам
Допустим, перед нами новый проект. Нужно написать автотесты для REST API. Условия, в которых придётся работать, следующие:
в первую очередь тестируем базовые свойства REST API, а именно:
допустимость методов для конкретного endpoint;
корректность принимаемых и возвращаемых типов и структур данных;
корректность работы сортировки и фильтрации;
бизнес-логика работы приложения вынесена за рамки REST API и не оказывает значительного влияния на тестирование его базовых свойств;
тесты нужны ASAP;
спецификация методов может и будет меняться;
тесты должны соответствовать концепции Black Box;
количество QA Engineers ограничено.
Теперь надо решить, какими мы хотим видеть автотесты на новом проекте.
Что действительно важно для автотестов?
Мы с командой выделили для себя 3 наиболее важных аспекта хороших автоматизированных тестов.
Автоматизация подготовки тестовых данных
Данный аспект особенно важен в ситуации частых изменений в приложении.
Автоматизация подготовки данных помогает сделать тесты автономными. Не нужно заботиться о том, в каком состоянии находятся данные на тестовом стенде или в тестируемом приложении.
Из минусов: такой подход может потребовать дополнительных усилий со стороны разработки, например для создания инструментов получения этих тестовых данных и для поддержки таких инструментов.
Минимизация дублирований кода автотестов и логики проверок
По мере роста приложения вопрос дублирования в тестовом фреймворке может стать большой проблемой. Актуализация тестов с большим количеством дублирования, скорее всего, будет отнимать значительное время.
Прозрачность как самих проверок, так и их результатов
Пока тесты зелёные, вопрос детальности описания шагов в отчёте и результатов тестов почти никого не волнует, но как только тесты перестают проходить успешно, мы моментально оказываемся в ситуации, когда подробный отчёт критически необходим для разбора проблемы.
В идеальной ситуации из отчёта по тестам мы должны иметь возможность однозначно определить источник проблемы и получить все необходимые для её воспроизведения данные.
Классические подходы
Обратимся для начала к нашему прошлому опыту или к мнению опытных коллег. Что у нас там есть?
Хардкод или предзаполнение БД
Как правило, в автотестах данные для проверок хранятся в статичном виде в теле теста или в виде констант:
А для заполнения приложения данными может использоваться предзаполнение БД или иной скрипт создания данных и объектов в приложении перед началом тестов.
Проблема такого подхода заключается в том, что при любом изменении схемы данных нам с вами придётся шерстить код тестов в поисках затронутых данных и обновлять их.
Такие манипуляции, безусловно, будут отнимать значительное время на поддержку тестов.
Дамп базы данных с «прода»
Альтернативой ручному созданию скриптов заполнения БД может выступать использование обезличенных данных с production-среды.
Такой подход позволяет работать с реальными данными. Однако он не гарантирует наличия всех данных, необходимых для тестов, и сильно завязан на наличие production-среды, которая может использоваться в качестве источника таких данных.
Стоит отметить, что такой подход далеко не всегда возможен. Препятствием могут стать как политики работы с персональными данными, так и невозможность получения доступа к «проду» или его отсутствие (для клиентских приложений).
Про данные понятно. Что насчёт кодовой базы?
Создание отдельных тестов для каждого endpoint
Одним из наиболее часто применяемых подходов к написанию автотестов для API является создание отдельных тестов для каждого endpoint.
Данный подход удобен с точки зрения учёта индивидуальных особенностей конкретного endpoint, но неизбежно влечёт за собой дублирование кода и логики проверок. Также при большом количестве таких наборов на выходе получается весьма тяжёлый фреймворк.
И вот мы с вами плавно приходим к мысли о том, что рассмотренные выше варианты не так уж и хороши, особенно в разрезе озвученных в самом начале тезисов о хороших автотестах. Давайте думать дальше.
Генерация тестов по SWAGGER-описанию
Во многих проектах можно встретить использование такого инструмента, как SWAGGER, для описания REST API.
Если коротко, то SWAGGER и подобные ему решения нацелены на автоматическую генерацию документации к API на основе кода приложения. При правильном использовании разработчику не приходится задумываться о ведении отдельной документации к API, что и делает такие системы крайне популярными.
Кажется, что решение становится очевидным: генерируем тесты и данные для них по SWAGGER-описанию! Если SWAGGER так популярен, то для него должен быть готовый инструмент.
Однако после часов гугления и поисков выясняется ряд обстоятельств.
Первое — инструментов для генерации тестов по SWAGGER-описанию великое множество. Вот несколько наиболее ярких примеров:
Второе — далеко не все из них генерируют именно код автотестов. Некоторые используют свой собственный формат, при котором генерация и выполнение тестов происходят в рамках одного инструмента. Некоторые генерируют скрипты для последующего выполнения. Ряд фреймворков предназначен для автогенерации юнит-тестов для конкретного языка и фреймворка разработки.
Ну и третье, но, пожалуй, самое важное: ни один из таких инструментов не решает вопрос подготовки тестовых данных…
Именно 3-й пункт является основным препятствием для использования готовых инструментов.
А значит, разумно будет создать своё кастомное решение. Именно о таком решении, разработанном в стенах компании Arenadata, я бы и хотел сегодня вам рассказать.
Автоматизируем по максимуму!
Но перед тем как приступить к рассказу о нашем решении для автоматического создания тестов, вспомним основные требования к автотестам, которые мы сформулировали ранее:
автоматическая генерация тестовых данных;
минимальное количество дублирования кода и логики в самих тестах;
детальный и понятный отчёт с результатами тестов.
Автоматическая генерация тестовых данных
Даже если мы располагаем слепком данных с прода, это не даёт нам гарантии наличия в приложении всех необходимых для конкретного теста данных.
Инструментов для решения данной проблемы может быть много. Некоторые из них мы уже описали ранее в обзоре классических подходов.
Посовещавшись с командой, мы выбрали подход, при котором данные для каждого теста генерируются индивидуально. Для задач тестирования базового поведения API этот подход нам показался оптимальным.
Но откуда алгоритм узнает, какие именно данные нужны тесту и, более того, как их создать?
Модели данных
Ответ на этот вопрос, как ни странно, лежит в попытке минимизации дублирования кода и логики. Давайте представим себе типичный набор тестов API. Они все будут очень похожи. Разница будет именно в данных. А значит, при классическом подходе мы будем множество раз описывать похожие методы подготовки данных для разных методов.
Чтобы этого не происходило, алгоритм подготовки данных должен быть универсальным и абстрактным.
В нашем случае мы создали описания моделей данных и их зависимостей для каждого endpoint.
Например, для создания данных для endpoint Backup нам необходимо, чтобы в приложении уже были созданы данные для endpoints Cluster и File System — это пример явной или прямой зависимости. Также для выбранных кластера и файловой системы должен существовать Connection — и это так называемая неявная зависимость.
Рассмотрим на данном примере алгоритм генерации данных.
Итак, мы с вами хотим создать данные для endpoint Backup.
В его модели описана неявная зависимость от endpoint Connection.
Значит, перед созданием данных для endpoint Backup алгоритм должен будет создать данные для endpoint Connection. Для их создания выполняется рекурсивный вызов метода генерации данных для endpoint Connection.
У connection нет неявных зависимостей, но есть явные. Значит, далее следуют рекурсивные вызовы методов генерации данных для endpoint Cluster и File System.
У endpoint Cluster и File System нет зависимостей, значит, они могут быть созданы без дальнейших действий. Создаём их.
Далее происходит сворачивание цепочки рекурсивных вызовов, и на выходе мы имеем возможность создать данные для endpoint Backup, потому что все его зависимости были созданы.
Отдельно стоит отметить, что наличие явных и неявных рекурсивных зависимостей, которые могли бы привести к зацикливанию работы алгоритма, недопустимо и считается ошибкой приложения.
Вот так вкратце и работает автоматическое создание тестовых данных.
Помимо связей и типов данных в модели Endpoint описываются всевозможные характеристики полей, например:
является ли поле обязательным,
можно ли после создания объекта изменить значение этого поля и т. д.
Также важно не забыть про Url данного endpoint и про список допустимых для него методов.
Модели тест кейсов
Описанные модели позволяют решить вопрос генерации данных, но не решают вопроса генерации самих тестов. Для решения этого вопроса нам нужны обобщённые описания тест-кейсов, построенные по следующей логике.
Указывается метод, для которого будет применим данный кейс. Далее ставится опциональная пометка о типе теста (позитивный или негативный). В теле теста описывается действие или последовательность действий. И в завершение перечисляются правила формирования данных для проверок.
Представленный на картинке пример описания тест-кейса может быть применён для любого endpoint, для которого допустим метод POST.
Итоговый алгоритм
В итоге алгоритм тестового фреймворка по очереди выбирает endpoint, определяет по его модели, какие методы для него разрешены, и на выходе получает полный набор тестов для этого endpoint.
Таким образом, единожды описав все необходимые тест-кейсы и модели данных для всех endpoint, мы получаем полноценный набор автотестов.
Если у вас есть желание подробнее погрузиться в тонкости работы описанных сегодня алгоритмов, то добро пожаловать в наш семпл-проект на github, в котором мы с командой разместили для вас пример реализации автотестов в описанной парадигме.
Также вы найдёте там пулл-реквест с описанием изменений в приложении и соответствующими изменениями в тестах. Главной целью этого пулл-реквеста является наглядная иллюстрация объёма изменений в тестах при изменениях в приложении.
Детальный отчет
В качестве отчёта мы с командой использовали Allure Report в связке с продуктом Allure TestOps, позволяющим нам хранить все отчёты в одном месте.
Основной упор был сделан на отображение всех шагов подготовки данных, выполнения теста и сбор логов для упавших тестов.
Достичь такого результата получилось достаточно просто путём упаковки всех основных операций в allure.step и использования allure.attach для прикрепления дополнительной информации, в том числе логов.
Сложности и подводные камни
Как и в любом деле, мы не смогли избежать сложностей и неожиданностей при написании автотестов.
Первое, с чем пришлось столкнуться, — это неявные зависимости между сущностями и объектами в приложении. В примере, рассмотренном ранее, мы уже говорили об этом аспекте. Помните, что для создания бекапа нам нужно было сначала создать connection между кластером и файловой системой? Это, наверное, самый простой пример неявной зависимости, с которой пришлось работать.
Решение в данном случае — это модификация моделей и алгоритма создания данных.
Вторым значительным препятствием стала валидация создаваемых данных на стороне приложения.
Если с числами, строками и внешними ключами всё достаточно очевидно, то, когда дело доходит до полей, значения которых проверяются по референсам из других полей других объектов, всё становится интереснее.
Конкретно в нашем случае мы столкнулись с генерацией конфигураций в формате Json для одного объекта (Connection) по JsonSchema из другого объекта (Connection Type).
Как и в прошлом кейсе, решение состояло в модификации моделей и алгоритма генерации значений для полей типа Json.
Последней трудностью, на которой стоит заострить внимание, является оценка степени покрытия отдельных endpoint тестами.
Основной проблемой здесь являются возможные дефекты самого тестового фреймворка. Возможно, модель описана неточно, или в описании тест-кейса допущена ошибка, которая проявляется только для некоторых endpoint.
Тут ничего не остаётся, кроме ручного анализа результатов прогона после внесения изменений в алгоритм или добавления новых моделей. Но даже при учёте трудозатрат на единоразовую ручную проверку подобных ситуаций общая эффективность подхода и экономия времени остаются значительными по сравнению с классическими подходами, описанными во вводной части.
Границы применимости
На данный момент подход отлично зарекомендовал себя как способ организации детального покрытия автотестами API-методов с простой бизнес-логикой. Есть планы по расширению области его применения на методы с более сложной бизнес-логикой и CRUD-сценарии.
Возможности применения такого подхода для UI-тестов маловероятны, однако попробовать можно. Особенно если UI содержит в себе похожие структуры (однотипные формы, оборачивающие API-методы, страницы с отображением данных из БД или логов)
Также неизученным, но перспективным кажется применение описанного подхода при тестировании схем и структур данных непосредственно в БД. Например, при проектировании сложной системы со связями, процедурами преобразования данных и триггерами.
Чуть менее глобальным, но от того не менее важным является применение описанных алгоритмов для тестирования на безопасность. В таком случае разработчик автотестов делает акцент на генерации невалидных данных с целью «сломать» логику работы сервиса именно в контексте безопасности.
Итоги
Применение описанного подхода при разработке тестов API позволяет:
в разы снизить затраты на обновление тестов и тестовых данных в случае частых изменений в требованиях;
ограничить затраты на правку/доработку автотестов при добавлении или изменении endpoint не более чем 20 % от времени на разработку такого изменения.
Надеюсь, что представленные в статье материалы и идеи помогут вам в оптимизации ваших автотестов и в упрощении процесса их поддержки!
Хочу выразить огромную благодарность всей команде Arenadata QA за помощь в подготовке данной статьи!
Что пишут в блогах
- Что такое тестирование. Курс молодого бойца (моя книга вышла!)
- Расписание на декабрь
- Как вырасти из тестировщика в тест-менеджера
- Организация обучения джуниоров внутри команды. 2 декабря, Кострома
- Автоматизация рутины. Скачиваем файлы через bash
- Панбагон. 12 часов — опасное время
- Оффер сразу после курса для тестировщиков с нуля. Что бывает, если выйти из зоны комфорта
- Мои 12 недель в году. Часть 17 (переезд, ДР и пневмония)
- Как тестировщику с небольшим опытом подготовиться и сдать экзамен ISTQB FL: интервью
- Метрики в тестировании: какие выбрать и что делать, когда они становятся KPI?
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Смирнова Анастасия
Нередко бывают ситуации, когда необходимо быстро получить тестовые данные для проверок. И если таких данных нет под рукой, на помощь приходят они — сервисы генерации.
Представляем вашему вниманию небольшую подборку полезных инструментов, которые мы используем в нашей работе.
Генератор ИНН, ОГРН, КПП, СНИЛС
Тестируете ПО, где необходимо вводить реквизиты физических или юридических лиц? Тогда этот сервис для вас.
Есть возможность генерировать реквизиты поштучно и “пачкой”.
Также при необходимости можно проверить валидность сгенерированного ИНН.
Отличное решение, когда необходимо создать юридическое лицо, например для проверки банковского ПО.
Генератор изображений
Возможность сгенерировать изображение до 1000 px в ширину и высоту.
При необходимости можно выбрать категорию изображения, например “животные” или “люди”, и установить фильтр.
Пригодится для проверки загрузки аватарки или фото определенного размера.
Генераторы временных почтовых ящиков
Наша команда использовала генераторы email, когда необходимо было проверить рассылки и зарегистрировать большое количество пользователей с подтверждением регистрации по почтовому адресу.
Генератор личности
Одна из наших команд использовала данный сервис для создания контрагентов во время тестирования ПО страховой компании.
Задаете страну, национальность, пол и возраст и на выходе получается “личность” со всеми необходимыми данными: ИФ, телефон, дата рождения, email, номер банковской карты.
Генераторы текста и строк
Тут все просто: генератор создает текст без определенного смысла.
Вам остается лишь указать число абзацев и количество слов в абзаце, все остальное сервис сделает за вас.
Похожий с предыдущим сервисом генератор строк. Можно задать количество и длину строк, а также прописать разрешенные символы для генерации. От предыдущего сервиса отличается тем, что генерирует рандомный набор символов.
Подойдет не только для тестировщиков, которым необходимо проверить поля ввода, но и веб-дизайнерам с верстальщиками для генерации “рыбы”.
Генератор UUID
Сервис предназначен для генерирования значения уникального идентификатора GUID (UUID).
GUID (Globally Unique Identifier) или UUID (Universally Unique Identifier) — это уникальный идентификатор, который необходим для обеспечения уникальности создаваемых приложений, библиотек, объектов, компонентов и сервисов.
На одном из наших проектов сервис использовался для генерации уникальных ID для данных БД.
Читайте также: