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

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

Подготовительные работы

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

ПРОГРАММЫ ДЛЯ РАБОТЫ С ТЕКСТОМ [ТОП 5]

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

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

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

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

Выбор тестовой документации

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

Тестировщик с нуля за 10 часов / Полный курс QA/ Теория и практика

Организация работы с тестовой документацией

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

• платная или бесплатная система управления тестированием (TMS);
• удаленный репозиторий;
• расшаренная сетевая папка;
• расшаренная коллекция тестов в инструментах тестирования (например, Postman);
• общедоступный google doc;
• другие инструменты.

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

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

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

• зафиксируйте назначение документа (можно указать название, краткое описание, целевую аудиторию и т.д.);
• зафиксируйте все необходимые обозначения в легенде документа (например, статусы выполнения теста, названия модулей и т.д.);
• зафиксируйте ссылки на спецификацию функциональности, для которой разрабатывается тестовый документ;
• определите обязательные и необязательные атрибуты;
• определите причины заполнения необязательных атрибутов;
• определите список статусов прохождения тестов;
• при необходимости определите список приоритетов, а также список возможных значений других атрибутов.

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

Теперь, когда команда тестирования приступает к разработке тестовой документации, не забывайте обращать внимание на следующие аспекты:

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

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

Резюме

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

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

• qa
• qa management
• qa strategy
• qa lead
• тестирование
• тестовая документация
• qa process
• testing strategy
• процесс тестирования
• тестирование по

Источник: habr.com

Создайте свои тестовые данные

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

Что такое тестовые данные? Почему это важно?

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

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

В зависимости от среды тестирования вам может потребоваться СОЗДАТЬ тестовые данные (в большинстве случаев) или, по крайней мере, определить подходящие тестовые данные для ваших тестовых случаев (если тестовые данные уже созданы).

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

Тестовые данные могут быть сгенерированы —

• Вручную
• Массовое копирование данных из производства в среду тестирования
• Массовое копирование тестовых данных из устаревших клиентских систем
• Инструменты автоматического создания тестовых данных

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

Ниже описаны несколько типов тестирования, а также некоторые предложения относительно их потребностей в данных тестирования.

Тестовые данные для тестирования белого ящика

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

• Желательно охватить как можно больше веток; данные тестирования могут быть сгенерированы таким образом, что все ветви в исходном коде программы проверяются хотя бы один раз
• Тестирование пути: все пути в исходном коде программы проверяются как минимум один раз — можно подготовить тестовые данные, чтобы охватить как можно больше случаев.
• Отрицательное API-тестирование :

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

Тестовые данные для тестирования производительности

Тестирование производительности — это тип тестирования, который выполняется для определения того, насколько быстро система реагирует на конкретную рабочую нагрузку. Целью этого типа тестирования является не поиск ошибок, а устранение узких мест. Важным аспектом тестирования производительности является то, что набор используемых образцов данных должен быть очень близок к «реальным» или «живым» данным, которые используются в производстве. Возникает следующий вопрос: «Хорошо, хорошо проверять реальные данные, но как мне получить эти данные?» Ответ довольно прост: от людей, которые знают лучше всего — от клиентов . Они могут предоставить некоторые данные, которые у них уже есть, или, если у них нет существующего набора данных, они могут помочь вам, предоставив обратную связь относительно того, как могут выглядеть реальные данные.Если вы находитесь в Проект технического обслуживания вы можете скопировать данные из производственной среды в испытательный стенд. Хорошей практикой является анонимизация (шифрование) конфиденциальных данных клиента, таких как номер социального страхования, номера кредитных карт, банковские реквизиты и т. Д., Пока выполняется копия.

Тестовые данные для тестирования безопасности

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

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

Тестовые данные для тестирования черного ящика

В Black Box Testing код не виден тестеру. Ваши функциональные тесты могут иметь тестовые данные, соответствующие следующим критериям:

• Нет данных : проверка ответа системы при отсутствии данных
• Допустимые данные : проверьте ответ системы при отправке действительных тестовых данных.
• Неверные данные : проверьте ответ системы при отправке тестовых данных InValid
• Недопустимый формат данных : проверьте ответ системы, когда данные теста имеют недопустимый формат.
• Набор данных граничных условий: данные испытаний, соответствующие граничным условиям
• Набор данных эквивалентных разделов: тестовые данные, квалифицирующие ваши эквивалентные разделы.
• Набор данных таблицы решений: тестовые данные, отвечающие вашей стратегии тестирования таблиц решений
• Набор тестовых данных перехода состояний: тестовые данные соответствуют вашей стратегии тестирования перехода состояний
• Use Case Test Data : данные теста синхронизированы с вашими вариантами использования.

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

Инструменты автоматического создания тестовых данных

Чтобы генерировать различные наборы данных, вы можете использовать гамму инструментов автоматического создания тестовых данных. Ниже приведены некоторые примеры таких инструментов:

1) Генератор тестовых данных GSApps можно использовать для создания интеллектуальных данных практически в любой базе данных или текстовом файле. Это позволяет пользователям:

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

2) Генератор тестовых данных DTM — это полностью настраиваемая утилита, которая генерирует данные, таблицы (представления, процедуры и т. Д.) Для тестирования базы данных (тестирование производительности, тестирование качества, нагрузочное тестирование или тестирование удобства использования).
Datatect является генератором данных SQL от Banner Software, генерирует различные реалистичные тестовые данные в плоских файлах ASCII или напрямую генерирует тестовые данные для СУБД, включая Oracle, Sybase, SQL Server и Informix.

Вывод

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

Источник: coderlessons.com

13.3. Технологические этапы и стратегии систематического тестирования программ

Задача тестирования спецификаций состоит в проверке полноты и взаимного соответствия функций, предписываемых программным и информационным компонентам требованиями разных иерархических уровней (см. п. 13.1). Кроме того, задачи тестирования включают проверку соответствия описаний информации на входах и выходах взаимодействующих программных модулей и групп программ, а также с описаниями информационных модулей в базе данных.

В результате тестирования спецификаций должна быть обеспечена их корректность и согласованность в пределах обобщенного описания требований к функциям всего ПС и взаимодействия всех его составных частей. Тестирование взаимосвязей целесообразно проводить, начиная от спецификации требований комплекса или группы программ. Последовательно по иерархическим уровням должно прослеживаться обеспечение программ верхнего уровня реализованными функциями программ нижних уровней, предписанными программными спецификациями. Одновременно проверяется полнота выполнения этих функций спецификациями информационных модулей (см. рис. 13.2).

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

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

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

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

При этом значительно возрастает сложность тестируемых объектов и соответственно — размеры и сложность тестов. Вследствие этого возрастают требования к автоматизации тестирования и затраты на его выполнение. Детерминированным тестированием должны проверяться структура группы программ и основные маршруты обработки информации. В ряде случаев результаты следует получать методами стохастического тестирования.

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

Тестирование функциональных компонентов в составе программных средств в процессе разработки комплексов программ и оценки полноты тестирования осуществляются преимущественно по степени выполнения требуемых функций и по характеристикам достигаемой корректности и качества функционирования ПС в целом (см. рис. 13.2).

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

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

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

Основные этапы систематического тестирования и испытаний крупного комплекса программ реального времени и его компонентов представлены на рис. 13.6. При тестировании и испытаниях корректности функциональных компонентов комплексов программ выделены этапы:

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

• тестирование функциональных групп программ в статике с учетом взаимодействия с некоторыми другими важнейшими компонентами и с базой данных;
• тестирование отдельных программных компонентов в реальном времени во взаимодействии с другими функциональными компонентами и с основными компонентами операционной системы и базы данных.

Рис. 13.6

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

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

После комплексирования основных, функциональных компонентов начинаются их тестирование и испытания в составе ПС в целом. Для них наиболее характерны следующие этапы квалификационного тестирования и испытаний ПС в реальном времени (см. рис. 13.6):

• по данным моделирующего стенда или генераторов тестов, имитирующих отдельные объекты внешней среды;
• с имитаторами отдельных объектов внешней среды и с реальными воздействиями от операторов-пользователей;
• в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов-пользователей (см. лекцию 14).

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

Средства генерации тестов и обработки результатов тестирования можно разделить на три вида (см. рис. 13.6). Одни и те же средства автоматизации тестирования в статике обычно обеспечивают отладку групп программ как автономно, так и во взаимодействии с другими компонентами.

Средства, имитирующие внешнюю среду в реальном времени, чаще всего ориентированы на тестирование как функциональных компонентов, так и ПС в целом. Еще один вид генераторов тестов в той или иной степени использует реальные объекты внешней среды. Первоначально такими объектами являются имитирующие стенды с участием реального функционирования операторов-пользователей (см. лекцию 14). Затем источниками тестов могут быть комплексы реальной аппаратуры внешних объектов или их аппаратурные аналоги.

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

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

Вау!! Ты еще не читал? Это зря!

• верификация программ ,
• 13.2. Процессы и средства тестирования программных компонентов
• тестирование программных компонент ,
• оценка сложности тестирования ,
• тестирование потоков данных ,

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

Источник: intellect.icu