Разделы портала

Онлайн-тренинги

.
Преимущества виртуальных машин и работа с UEM в QA
01.09.2022 00:00

Оригинальная публикация
Статья компании SimbirSoft

Всем привет! Сегодня мы рассмотрим основные аспекты UEM (Unified Endpoint Management) технологии, применяемой в сервисах по управлению клиентскими устройствами. Речь пойдет о виртуализации и виртуальных машинах для тестирования и обеспечения качества. Статья будет полезна для QA и DevOps уровней джуниор-мидл.

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

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

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

Как работает виртуализация?

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

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

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

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

Существуют две основные разновидности гипервизоров.



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

Плюсы

Минусы

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

Часто требуется отдельная управляющая машина для администрирования различных ВМ и управления аппаратным обеспечением хоста.

Безопасность — между гипервизором типа 1 и центральным процессором нет ничего, что злоумышленник мог бы взломать.



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

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

Плюсы

Минусы

Быстрый и удобный доступ к альтернативной гостевой ОС, работающей параллельно с основной в системе хоста.

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

Идеальный вариант для конечных пользователей с точки зрения производительности.

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

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

Перейдем к понятию управления клиентскими устройствами. 

UEM (Unified Endpoint Management)

Это унифицированное управление конечными точками. Фактически это стек, соединяющий в себе технологии MDM (Mobile device management), EMM (Enterprise mobility management), MAM (Mobile application management). Единое решение для современного управления настольными компьютерами, мобильными, упрочненными (военными и промышленными) и носимыми устройствами наподобие умных часов с помощью сети Интернет либо Wi-Fi.



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

  1. Унифицированное управление жизненным циклом любых конечных устройств — мобильных (Android, iOS), настольных (Windows, macOS, Chrome OS) с помощью одной консоли управления для поддержки всех сценариев использования.

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

а) объединение единого каталога приложений на основе самообслуживания с системой единого входа;

б) удаленная поддержка администратора;

в) представление фаервола для защиты данных пользователей.

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

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

Компания Apple также внедрила смежную технологию, реализованную на платформе macOS и имеющую привязку к UEM. 

DEP (Device Enrollment Program)

Профили DEP (Device Enrollment Program) и MDM (Mobile Device Management), как правило, устанавливаются на устройства, выданные крупными компаниями или школами и университетами в пользование. Профиль позволяет автоматизировать настройку практически всех программных компонентов. При этом он также позволяет полностью контролировать устройство дистанционно. Возможности ограничены лишь фантазией администратора, который его настраивал.



Смысл Apple Device Enrollment Program — привязка устройств на аккаунт компании для облегчения управления и инвентаризации. 

Внутри системы DEP имеет самый высокий приоритет (после Apple, разумеется).

Mobile Device Management (MDM) системы имеют приоритет ниже, чем Apple ID пользователя устройства. Удалить профиль MDM пользователь может легко, в отличие от DEP. Для этого достаточно быть админом в системе.

В итоге уровень приоритетов выстраивается таким образом:

  1. Apple.

  2. DEP.

  3. User Apple ID.

  4. MDM Profile.

BYOD (Bring Your Own Device)

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

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

BYOD используется путем интеграции ряда политик (Android Device Policy, Google apps Device Policy) с политикой предприятия. Все работает на уровне корпоративной сети. Политики контролируют доступ пользователей в сеть и формируют профили для различных сетевых элементов, чтобы обозначить, какая информация может храниться или передаваться через то или иное устройство. Также определяются точки контроля передаваемых данных до того, как они попадут в сеть или покинут ее. Этот метод дает полный контроль за действиями пользователей и приложениями, которые они используют.

Пример

Когда после окончания рабочего дня сотрудник покидает пространство предприятия и удаляется с устройством BYOD за его пределы на 150 метров, срабатывает кастомно настроенная политика и блокируется инфраструктурная функциональность предприятия (сеть, рабочие программы).



В чем ключевая польза виртуальных машин?

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

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

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

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

Например, можно создать такую же среду, как на стороне конечного пользователя (клиента) для имитации его работы с приложением. Это удобно, если вы разрабатываете приложение в России, а клиент будет использовать его в Америке. Поведение программы у клиента может измениться, а значит, нужно принимать во внимание все региональные особенности.



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

Как применяются виртуальные машины 

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

Нужно понимать, что для успешного применения виртуальных машин инженеры QA должны уметь их создавать и настраивать. И в зависимости от характера тестируемых приложений использовать методики, подходящие для конкретных случаев.

Основные задачи, для которых QA наиболее полезны виртуальные машины:

Задача 1: Настройка среды окружения.

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

Задача 2: Работа с сервером управления UEM.

Когда в процессе разработки ПО используется периодическая сборка Developer Stage с результатами всех изменений и правок, внесенных в код разработчиками за данный период, инженерам QA удобно иметь быстрый доступ к нескольким ключевым сборкам. Например, к 2-3 последним, если нужно сравнивать изменения функциональности за недавнее время.

На машину с ОС и всеми предварительными настройками ставим native Control AdminService ver.5.0. И до первого запуска тут же делаем снапшот. Так мы получаем в распоряжение установленное приложение до начала выбора пользовательских настроек. К нему всегда можно вернуться, при этом каждый раз не нужно ничего удалять и чистить реестр. Это экономит время и гарантирует точность соответствия первоначальным настройкам ПО, то есть тому, как это будет выглядеть у клиента.

Проходит время, и программисты выдают следующую сборку, native Control AdminService ver.6.0. Она ставится в параллельную ветвь, native Control AdminService ver.5.0 пока что не удаляется. Зачем это нужно? Есть доля вероятности, что native Control AdminService ver.6.0, например, не запустился (релиз-инженерами допущены ошибки и сборка выполнена некорректно, обнаружены сбои работы инсталлятора) или программисты-стажеры модифицировали код так, что возникла ошибка, полностью или частично заблокировав работу с приложением.

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

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

Задача 3: Сравнение с выпущенными ранее версиями тестируемого ПО.

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

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

В качестве ключевых сборок могут выступать финальные сборки ранее вышедших версий тестируемого ПО. Так что потребуется еще несколько снимков. Например, разрабатывается Программа-Х версии 14.5.0, значит, для исследований нужно иметь под рукой финальные сборки версий 14.3.1, 14.0.0.

Задача 4: Обеспечить кроссбраузерность тестирования.

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

Методика настройки и использования виртуальной машины

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

В то же время все снапшоты машин будут одинаковыми для всех разработчиков программного продукта. Любой разработчик может самостоятельно воспроизвести и увидеть ровно ту же ситуацию, какую описал инженер QA в качестве ошибочной. Для этого в соответствующей заявке (тикете) в багтрекере, помимо описания сути проблемы и шагов к воспроизведению, нужно точно указать ту среду, в которой проводилось исследование и зафиксирована та или иная ошибка. Для этого используйте формат «машина/снапшот».

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

Приведем полную модель развертывания сервиса UEM на виртуальных машинах для тестирования.

Нам понадобятся:

  1. Основной сервер управления.

  2. Админская часть (может быть десктоп, веб, в некоторых случаях даже мобайл).

  3. Как минимум по одному клиенту на каждой из возможных ОС.

  4. Сервер с ускорителем, который сможет взять на себя часть нагрузки с основного сервера.

Это примерная модель взаимодействия сервиса. То есть нам нужно очень много физических устройств для проверки и тестирования только базовой работоспособности нашего сервиса с клиентской частью. Найти 10, 20 или 30 машин довольно затратно, намного проще имитировать это на виртуальной или вынести всю тестовую среду на облачный сервис (проверить работу одновременного подключения к сервису 2000 клиентов).


Программное обеспечение

Среди распространенных средств виртуализации, заслуживших признание, стоит назвать VirtualBox (Oracle VM VirtualBox) и продукты семейства VMware (VMware Workstation и VMware Player — но в этой версии не реализована возможность создания снапшотов), а также аппаратную виртуализацию Hyper-V от Microsoft.

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

Заключение

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

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

Обсудить в форуме