Анна Сергеева. Виртуальные машины в тестировании. На примере Alloy Navigator // Системный администратор. 2014. № 10. C. 68-73.
В статье приводится методика настройки виртуальных машин для их применения в тестировании разрабатываемых современных сложных программных приложений, таких как профессиональный инструмент для управления ИТ-структурой предприятий Alloy Navigator.
Опубликовано в разделе "Разработка / Тестирование"
Эта же статья на сайте журнала
Как я ранее рассказывала в предыдущей статье «Инструменты тестировщика, или С чего начать новичку» [1], одним из важных инструментов тестировщика являются виртуальные машины.
И это не стоит расценивать, как только лишь частное мнение отдельно взятого (пусть и опытного) специалиста в области обеспечения качества. Давайте смотреть в лицо фактам. Подавляющее большинство уважаемых и зарекомендовавших себя на рынке компаний, которые ведут разработку и обслуживание программных приложений, в вакансиях тестировщиков и специалистов по качеству указывают обязательное владение навыками применения виртуальных машин. И со временем эти требования встречаются все чаще и чаще.
И, если читатели заботятся о своем профессиональном будущем и ориентированы на стабильный доход, душевное спокойствие и не рассматривают предложения от фирм-однодневок, следует понимать, что умение работать со средствами виртуализации становится «де-факто» обязательным для данной специальности.
Почему необходимо применять средства виртуализации
Средства виртуализации позволяют решать самые разные задачи, в том числе возникающие перед специалистами по тестированию и обеспечению качества разрабатываемых программных приложений.
Кроме того, применение виртуальных машин вместо физических дает компаниям-разработчикам ряд существенных преимуществ.
Во-первых, с помощью виртуальных машин можно выполнять сравнительное тестирование разрабатываемых программных приложений на разных машинах с разными аппаратными конфигурациями. Например, управлять размером дискового пространства или оперативной памяти, ограничивать доступ к конкретным сетевым ресурсам.
При этом материальные затраты на приобретение, обслуживание и обновление компьютерного «железа» фактически исключаются.
С другой стороны, сразу несколько тестировщиков могут получить в распоряжение уже заранее подготовленную тестовую машину, с установленной ОС и настроенной программной средой (включая, например, локальный SQL-сервер для построения и обслуживания баз данных, которые используются в работе тестируемого ПО).
Кроме того, виртуальные машины предоставляют удобные возможности по созданию конкретного специфического окружения, необходимого для исследования разрабатываемого ПО. Можно свободно варьировать специфичные региональные настройки и настраивать локализацию пользователей. И при этом исследователь может легко экспериментировать с настройками среды, без влияния на конфигурацию и работоспособность собственной физической машины.
Например, можно создать такую же среду, какая настроена и на стороне конечного пользователя (клиента), для имитации его работы с приложением. Допустим, вы разрабатываете приложение в России, а клиент будет использовать его в другой стране. Зачастую это оказывает влияние на поведение приложения, а значит, просто необходимо принимать во внимание все «национальные особенности».
Наконец, при таком подходе один исполнитель имеет удобную возможность запускать параллельное автоматизированное тестирование сразу на нескольких виртуальных машинах, имеющихся в распоряжении. Это позволяет выполнять сравнение результатов тестов, пройденных на машинах с разной конфигурацией и с разными настройками окружения, а также экономить на времени выполнения тестов за счет автоматизации и распараллеливания обрабатываемых задач.
Что и говорить, пользу от применения виртуальных машин, пожалуй, трудно переоценить. Ведь любого, кто по незнанию или в силу собственной лени и неаккуратности устанавливает тестируемые приложения прямо на свою рабочую машину, неминуемо преследует «злой рок»: ему необходимо все время что-то постоянно деинсталлировать, а также чистить реестр, временные файлы, системные логи и так далее, вплоть до регулярной (в некоторых случаях даже несколько раз в месяц) полной переустановки системы. А как-то раз автору вообще довелось столкнуться с ситуацией, когда очередная временная непроверенная сборка разрабатываемого продукта в результате инсталляции полностью убивала рабочую машину...
Незавидная перспектива. А вот с виртуальными машинами такого не бывает. И с помощью нескольких умело сделанных снимков состояний можно всегда иметь настроенную и подготовленную к работе машину, без ненужных следов «старых» инсталляций и вмешательства в настройки системы.
При этом нужно понимать, что для успешного применения виртуальных машин тестировщики должны обладать умением грамотного их создания и настройки. И в зависимости от характера тестируемых приложений использовать различные, подходящие к конкретным случаям, методики.
ПО глазами маркетологов vs технических специалистов Перейдем от общих рассуждений к частной практике и рассмотрим вполне конкретный пример – внушительный программный пакет, тестированием которого автор в настоящее время непоредственно занимается. Alloy Navigator – это профессиональный инструмент для автоматизации бизнес-процессов предприятий, позволяющий управлять ими как внутри организации так и извне. Включает функциональные возможности службы технической поддержки пользователей (SericeDesk, рис. 1) (содержит средства управления инцидентами и проблемами, изменениями, уровнем сервиса и знаниями), поддерживает веб-интерфейсы для клиентского портала самообслуживания и портала доступа технических специалистов (рис. 2), а также средства управления ИТ-активами предприятий (включает инструменты инвентаризации компьютеров и ПО, контроля ПО на соответствие лицензиям). [2]
Рис. 1. Внешний вид консоли Alloy Navigator
Рис. 2. Веб-портал доступа технических специалистов
Но это с точки зрения менеджмента проекта, отдела продаж и существующих и будущих клиентов.
А вот с технической точки зрения, Alloy Navigator — это комплексный программный пакет, хранящий большие объемы данных в БД, при этом эти данные достаточно часто обновляются и дополняются большим числом пользователей.
Пользователи организованы в группы и имеют различные уровни доступа к данным в БД и к функциям приложения. Также агенты приложения, собирающие данные о компьютерной сети предприятия, обладают привелегиями на обращение к удаленным машинам для их инвентаризации. Само приложение имеет достаточно обширный набор функциональных возможностей, предоставляемых через разные типы интерфейсов: консольный, запускаемый под всеми распространенными версиями Windows, плюс два веб-интерфейса с разными наборами функций, доступные из всех распространенных вэб-браузеров, плюс мобильный портал для быстрого доступа клиентов к приложению со смартфонов и планшетов.
Как видим, здесь для тестировщиков есть масса технических нюансов, которые как раз и нужно учесть при создании и настройке тестовых виртуальных машин.
Основная идея
Среди распространенных средств виртуализации, заслуживших признание специалистов, стоит назвать VirtualBox (Oracle VM VirtualBox) и продукты семейства VMware (такие как VMware Workstation и VMware Player). [1]
Данные инструменты позволяют поддерживать на одном компьютере процесс разработки, отладки, тестирования, запуска многоуровневых приложений; вводить в эксплуатацию новые типы и версии операционных систем и исследовать на них поведение тестируемых программных приложений, а также инсталлировать новые или обновлять имеющиеся ОС без необходимости в модификации разделов дисков и перезагрузки компьютера.
В данной статье речь пойдет о возможностях инструмента виртуализации VMware Workstation, на примере его использования для тестирования продуктов, разрабатываемых в Alloy Software.
Используется следующая методика настройки и использования ВМ.
Общая идея базируется на том, что инструменты виртуализации позволяют сохранять и оперативно возобновлять необходимые состояния виртуальных машин. Плюс несколько пользователей могут клонировать одну и ту же заранее подготовленную и размещенную в общем доступе виртуальную машину. Таким образом, тестировщики имеют в своем распоряжении набор виртуальных машин с такими сохраненными состояниями, которые позволят быстро разворачивать то или иное окружение и иметь доступ к разным вариантам работы с исследуемым ПО.
И в то же время, все сохраненные состояния машин будут одинаковыми для всех разработчиков программного продукта. Другими словами, любой программист может самостоятельно воспроизвести и увидеть ровно ту же ситуацию, какую описал тестировщик в качестве ошибочной. Для этого в соответствующей заявке (тикете) в системе отслеживания ошибок (багтрекере), помимо описания сути проблемы и шагов к воспроизведению, нужно точно указать ту среду (в формате «машина/снимок_состояния»), в которой проводилось исследование и зафиксирована та или иная ошибка. Это помогает программисту достаточно просто сориентироваться в условиях поставленной перед ним задачи, самостоятельно просмотреть интересующие текущие настройки разрабатываемой программы и среды. Кроме того, это позволяет значительно экономить время разработки, поскольку снижается необходимость в непосредственном очном контакте конкретного программиста и конкретного тестировщика, не нужно зависеть от их личного рабочего расписания и отрываться от исполнения текущих рабочих обязанностей.
Этап установки инструмента VMware Workstation, создания с его помощью нового экземпляра виртуальной машины и установки сопроводительного VMware Tools в данной статье не описывается, поскольку не составляет особой сложности и лежит за пределами заявленной темы. Ознакомиться с процедурой установки и заказать дистрибутив инструмента подробнее можно на сайте производителя [3].
Перейдем сразу к настройке машины и инсталляции необходимых программ.
Задача #1: Выбор ОС для тестовой виртуальной машины
Одной из важных задач, стоящих перед службой тестирования и обеспечения качества ПО, является исследование поведения разрабатываемого приложения при его запуске из-под различных типов/версий ОС. Поэтому изначально так важно определиться, какую ОС установить на тестовую виртуальную машину.
В нашем случае, приложение Alloy Navigator поддерживает запуск из-под Windows. Заявлена поддержка следующих версий Windows: XP Professional SP3, Vista, W7, W8, Server 2003, Server 2003 R2, Server 2008, Server 2008 R2, Server 2012. При этом, поддерживаются как 32-битные, так и 64-битные версии.
Разумеется, для каждодневого тестирования работа со всеми этими вариантами без исключения нецелесообразна, и следует провести значительное сокращение списка. Достаточно ограничиться небольшим набором принципиально различающихся ОС. Например, выбрать W8 (наиболее новая и перспективная), W7 (достаточно распространена среди существующих клиентов) и XP (принципиально различающаяся и используемая для совместимости с прежними версиями тестируемого Alloy Navigator).
В таком случае, уже требуется три разные тестовые машины, а ведь нужно еще учесть и разрядность ОС, поскольку часть функциональных возможностей тестируемого приложения зависит от этого системного параметра.
Тут можно отслеживать такие вещи как:
- поведение инсталлятора приложения,
- обработка системных настроек, характерных для той или иной версии ОС,
- обработка контроля пользовательских учетных записей (User Account Control, UAC). Ведь в XP этого и в помине не было, а вот начиная с Vista уже есть, и нужно удостовериться, не блокирует ли он те или иные действия в приложении, как выглядят различные консольные формы, как они отображают данные, и т.д.
Так что первый снимок состояния — это чистая машина с установленной ОС. В дальнейшем к ней всегда можно будет вернуться и все настроить заново.
А еще, к слову, сюда можно будет поставить очередной ServicePack от операционной системы.
Задача #2: Настройка среды окружения
Современное ПО разрабатывается в соответствии с актуальными (и постоянно растущими) запросами потребителей IT-услуг. Время не стоит на месте, и появляются все новые и новые функциональные требования к ПО, применяемому для поддержания работы IT-служб. Также значительно повышаются требования к производительности, скорости работы и другим важным характеристикам программных приложений. Применяя использованные ранее среды и инструменты разработки программного кода, таких показателей уже зачастую не добиться [4].
Поэтому для инсталляции и успешной работы Alloy Navigator нужно выполнить несколько дополнительных установок и настроек.
Стоит отметить, что инсталлятор Alloy Navigator поддерживает предварительную проверку наличия и состояния всех нужных компонентов и способен, в случае необходимости, выполнить их инсталляцию и настройку до начала установки самого приложения Alloy Navigator. Однако, это занимает некоторое время, а его можно значительно сэкономить, если установить эти компоненты однократно, сохранить такое состояние виртуальной машины и не повторять одни и те же рутинные действия с каждой новой сборкой.
Итак, что же это за компоненты. Здесь поможет внимательное изучение технических требований к инсталляции продукта и сопоставление их с ОС, установленной на конкретной тестовой машине.
В частности, для машины, на которую установлена ОС Windows XP Professional, требуется установить:
- Windows Installer (MSI) version 3.1
- Microsoft Core XML Services (MSXML) 6.0 SP1
- Microsoft Data Access Components (MDAC) 2.8 SP1
Для доступа к приложению через мобильный портал и оба веб-портала, веб-сервер которых выполняется из-под Windows Server 2003 или Server 2003 R2, требуется установка Windows Imaging Component.
Для работы с сервером баз данных Microsoft SQL Server 2008 R2 Express SP2 (об установке SQL-сервера речь пойдет в следующем разделе) и для успешной работы мобильных и веб-порталов, требуется установка Microsoft .NET Framework 4. Однако, W8 и Windows Server 2012 уже содержат .NET Framework 4.5, который является обновлением версии 4, поэтому для этих ОС его ставить не нужно.
Если для работы приложения используется MS SQL Server 2012, то для возможности просмотра и печати отчетов, генерируемых приложением, требуется установка Microsoft System CLR Types.
Для возможности удаленного аудита компьютеров в сети предприятия требуется установка Windows Remote Management (WinRM) 2.0. Cледует учесть, что для W7, W8, Windows Server 2008 R2 и Server 2012 этот компонент уже установлен.
Если веб-сервер будет запускаться из-под ОС Windows версий, более ранних чем W8 или Server 2012 (то есть, для Windows XP Professional SP3, Vista, W7, Server 2003 SP2, Server 2003 R2 SP2, Server 2008 или Server 2008 R2), то для поддержки работоспособности веб-браузера Microsoft Internet Explorer версий 10 и 11, необходимо установить Microsoft hotfix для ASP.NET Browser Definition Files в .NET 4.0. В противном случае, на веб-порталах Alloy Navigator не будет доступна часть функциональных возможностей, начиная с возможности входа в систему. Что же касается W8 и Windows Server 2012, то, поскольку они уже содержат .NET Framework 4.5, для них инсталляция этого hotfix не требуется.
Также, для корректной работы веб-сервера, который поддерживает доступ через веб-порал клиентского самообслуживания, веб-портал доступа технических специалистов и мобильный портал быстрого доступа, требуется установка и настройка служб IIS (Internet Information Services).
В зависимости от версии ОС, требуется своя версия служб IIS:
- IIS 5.1 для XP Professional.
- IIS 6.0 для XP Professional x64, Server 2003, Server 2003 R2.
- IIS 7.0 для Vista, Server 2008.
- IIS 7.5 для W7, Server 2008 R2.
- IIS 8 для W8, Server 2012.
Вот, пожалуй, пока можно остановиться и сделать второй снимок — это настройка окружения.
Задача #3: Обеспечение кроссбраузерного тестирования
Поскольку разработчики Alloy Navigator заявляют поддержку большинства распространенных веб-браузеров, то следует проводить и кроссбраузерное тестирование (для сравнения поведения веб-интерфейсов приложения при запуске из-под различных браузеров).
Так, для веб-порталов Alloy Navigator 7 заявлена поддержка следующих версий веб-браузеров:
- для клиентского портала самообслуживания: Microsoft Internet Explorer 8.0 и выше, Mozilla Firefox 10 и выше, Google Chrome 16 и выше, Apple Safari 4 и выше;
- для портала доступа технических специалистов: Microsoft Internet Explorer 10 и выше, Mozilla Firefox 16 и выше, Google Chrome 16 и выше, Apple Safari 5 и выше.
Поскольку для службы тестирования предусмотрена проверка работоспособности обоих порталов, то следует устанавливать браузеры из второго списка: IE 10, Firefox 16, Chrome 16.
Также, на этом этапе следует задуматься, будет ли проводиться автоматизированное тестирование работы веб-браузеров, и, если да,то самое время установить и настроить продукты автоматизации семейства Selenium.
Задача #4: Работа с SQL-сервером
Как упоминалось ранее, тестируемое приложение Alloy Navigator работает с базами данных. А значит, чаще всего удобно иметь на тестовой машине установленный и настроеный локальный SQL-сервер.
Так что еще один снимок — это установленный и сконфигурированный SQL-сервер.
Например, тот MS SQL Server 2008 R2 Express SP2, который входит в комплект поставки Alloy Navigator и является свободно распространяемой версией SQL-сервера, подходящего для работы как настольных, так и веб-, а также небольших серверных приложений. Или напротив, можно поставить совершенно другой удобный SQL-сервер и работать с ним. Именно поэтому этап установки SQL-сервера вынесен в отдельный снимок состояния от предыдущих настроек других компонентов. Здесь можно создавать ветвление структуры виртуальной машины и, если нужно, иметь доступ к нескольким разным локальным серверам баз данных.
Задача #5: Сравнение разных сборок разрабатываемого ПО
Когда в процессе разработки ПО используется периодическя сборка «Developer Stage» (с результатами всех изменений и правок, внесенных в код разработчиками за данный период), то тестировщикам бывает удобно иметь быстрый доступ к нескольким ключевым сборкам (например, к 2-3 последним, если нужно сравнивать, как изменилась та или иная функциональность за последнее время).
Приведем пример. На машину с ОС и всеми предварительными настройками ставим, например, AN700_Stage05. И до первого запуска тут же делаем снимок состояния. Так мы получаем в распоряжение установленное приложение до начала пользовательских настроек. И к нему всегда можно вернуться, при этом каждый раз не нужно ничего удалять и чистить реестр. Это экономит время и гарантирует точность соответствия первоначальным настройкам ПО, то есть тому, как это будет выглядеть у клиента.
Проходит время, и программисты выдают следующую сборку, AN700_Stage06. Она ставится в параллельную ветвь, AN700_Stage05 пока что не удаляется. Зачем это нужно? Есть доля вероятности, что AN700_Stage06, например, не запустился (релиз-инженерами допущены ошибки и сборка выполнена некорректно, обнаружены сбои работы инсталлятора) или программисты-стажеры модифицировали код так, что возникла ошибка, полностью или частично блокирующая работу с приложением. Тогда руководитель группы тестирования срочно ставит об этом в известность соответствующих исполнителей и принимает решение об «откате» к предыдущей сборке и ее временном использовании для тестирования. Так, в тестировании не теряется время на ожидание исправлений блокирующих ошибок.
Соответственно, время от времени придется удалять такие вот устаревшие и ставшие ненужными снимки (Чтобы не забивать дисковое пространство и ориентироваться в дереве структуры тестовой машины.)
Задача #6: Сравнение с выпущенными ранее версиями тестируемого ПО
Также тестировщики сравнивают поведение приложения с предыдущими выпущенными версиями. Плюс выполняют тестирование апгрейда приложения и миграции данных из БД прежних версий (имитация обновления ПО у клиентов, которые раньше пользовались прежней версией, добавили в БД большой объем важной информации и настроили приложение в соответствии с потребностями своего конкретного бизнеса).
Было бы очень печально, если клиент потеряет все свои данные, скажем, за последний месяц ведения и учета бизнеса и не сможет их восстановить. Или его работники, которые только привыкли к интерфейсу приложения, увидят не дополнительный набор новых настроек и кнопок, которые удачно впишутся в уже привычный их глазу интерфейс, а полностью новые необычные для них формы (это может ввести их в заблуждение, создать путаницу и застопорить рабочий процесс, а простой критичен для потребителя IT-услуг). Такого допускать нельзя.
Здесь, в качестве ключевых сборок могут выступать финальные сборки предыдущих выпущенных версий тестируемого ПО. Так что потребуется еще несколько снимков (например, разрабатывается Alloy Navigator версии 700, значит, для исследований нужно иметь под рукой финальные сборки версий 651, 600, 53).
В завершение, автор приводит примеры созданных виртуальных машин с разветвленной структурой сохраненных снимков состояний (рис. 3, 4, 5). Эти машины созданы в соответствии с приведенной здесь методикой.
Рис. 3. Пример структуры тестовой виртуальной машины
Рис. 4. Сравнение с выпущенными ранее версиями
Рис. 5. Работа с различными локальными серверами
Подобное применение виртуальных машин в тестировании дает целый ряд преимуществ. Нет расходов на аппаратные средства. Возможно имитировать окружение, развернутое на оборудовании клиентов и подстраиваться под их локализацию и кастомизацию. Нет необходимости постоянно избавляться от следов предыдущих ненужных установок и настроек. Грамотно подобранный набор машин с нужными сохраненными состояниями позволяет тестировщикам быстро разворачивать нужное окружение и иметь оперативный доступ к разнообразным вариантам работы с исследуемым ПО.
Литература
1 Анна Сергеева. Инструменты тестировщика или с чего начать новичку // Системный администратор. 2014. № 7-8.
2 О программном пакете Alloy Navigator - http://www.alloysoftware.ru/an6/
3 Об инструменте виртуализации VMware Workstation - http://www.vmware.com/products/workstation
4 Анна Сергеева. Применение реинжиниринга при проектировании встраиваемых систем// Компоненты и технологии. 2014. № 9.