19.08.2016, 15:37:31
Войти Зарегистрироваться
Авторизация на сайте

Ваш логин:

Ваш пароль:

Забыли пароль?

Навигация
Новости
Архив новостей
Реклама
Календарь событий
Right Left

Тестування ПЗ на віртуальних машинах

  1. Інструменти віртуальних машин для тестування і розробки
  2. Інструменти для розробки і тестування при некерованому розгортанні
  3. Інструменти для розробки и тестування при некерованому розгортанні
  4. Тестові лабораторії VMware LabManager
  5. Тестові лабораторії VMLogix LabManager
  6. Висновок

Технології віртуалізації зараз застосовуються в багатьох сферах ІТ, як у виробничому середовищі, так і ентузіастами, і домашніми користувачами для самих різних завдань. Кілька одночасно запущених віртуальних систем на одній фізичній машині істотно підвищують гнучкість ІТ-інфраструктури і збільшують ефективність використання апаратних ресурсів. Тестування програмного забезпечення - один з найпоширеніших варіантів використання для платформ віртуалізації. Не дивно, адже віртуальні машини мають безліч корисних властивостей, завдяки яким значно скорочується час розробки та тестування і підвищується ефективність цих процесів.

У класичній моделі розробки програмного забезпечення програмістам і інженерам по якості більшу частину часу доводилося відчувати програмний продукт на одній платформі протягом практично всього часу розробки, і лише в кінці проводити його тестування в різних ОС і призначених для користувача середовищах (так зване тестування конфігурацій, Configurations Testing ). До того ж, в розпорядженні співробітників відділів тестування і розробників знаходилося не так багато фізичних комп'ютерів, а на одній машині, в одній операційній системі, не можна, наприклад, поставити одночасно кілька версій одного програмного продукту, з яким повинна взаємодіяти розробляється програма. Внаслідок цього, в програмному забезпеченні, особливо невеликих команд розробників, часто зустрічалися помилки, пов'язані з особливостями користувальницьких конфігурацій, оскільки часу і ресурсів на повноцінне конфигурационное тестування не вистачало. Крім того, інженерам за якістю доводилося витрачати багато часу на розгортання комплексу програмних продуктів на тестових стендах і настройку їх роботи в мережевій інфраструктурі.

Безумовно, однією з найсерйозніших проблем при розробці ПЗ є той факт, що на ранніх етапах розробки, збирання програмного продукту в процесі своєї роботи можуть завдати непоправної шкоди системі (наприклад, різні драйвера пристроїв). Тому доводиться планувати відновлення операційних систем та їх налаштувань після збоїв з резервних копій і витрачати чимало часу на їх відновлення.

Треба відзначити ще одну проблему, яка досить часто зустрічається при розробці програмного забезпечення і змушує витратити чимало часу на її рішення. Всім програмістам, які мають досвід взаємодії з командами тестування, відома наступна ситуація: в системі багтрекінга тестувальник фіксує дефект, який програмісту ніяк не вдається повторити. Після того, як програміст ставить статус проблеми як вирішене, тестувальник кличе його до своєї машини і наочно демонструє помилку. У цій ситуації доходить до того, що програмісту доводиться встановити на машину тестувальника безліч отладчиков та іншої непотрібної останньому нісенітниці і «відловлювати» дефект, повністю зупиняючи роботу тестувальника. Якщо до цього додати час на видалення тестувальником програмістів утиліт, виходять серйозні втрати часу команди.

До того ж, особливості роботи деяких програмних продуктів вимагають перевірки їх роботи при певних умовах (різний обсяг оперативної пам'яті, пропускна здатність каналу зв'язку, частота процесора та інше). В цьому випадку в розпорядженні команди тестувальників може не виявитися необхідної апаратної конфігурації (що, якщо нам потрібно десять жорстких дисків?). При з'ясуванні системних вимог продукту до таких факторів ця необхідність може виявитися критичною.

На закінчення перерахування списку проблем, що виникають в процесі розробки і тестування, потрібно навести ще одну. Найчастіше складається така ситуація, коли потрібна перевірка збирання програмного продукту «на дим» (так зване димове тестування, Smoke Testing), що означає швидкий прогін найбільш важливих тестів. Але що якщо ми розробляємо програму, для якого потрібні різні версії Internet Explorer? У цьому випадку буде витрачатися багато часу на завантаження підходящої системи, де встановлена ​​необхідна версія.

Підсумовуючи описані ситуації, узагальнимо проблеми, що часто зустрічаються в процесі розробки і тестування програмних продуктів:

  • необхідність випробувань програмного забезпечення в кількості користувальницьких конфігурацій більшому, ніж в розпорядженні для тестування фізичних комп'ютерів
  • великі витрати часу на розгортання і налаштування тестових стендів, що містять безліч різних компонентів, між якими забезпечується мережеве взаємодія
  • великі витрати часу на створення резервних копій систем і їх конфігурацій, а також відновлення після збою внаслідок нестабільної роботи збірок програмного продукту
  • неможливість відтворення дефекту, знайденого тестувальником, на машині розробника і втрата часу на його пошук, виправлення
  • необхідність у випробуваннях програми в умовах апаратної середовища, якої немає в розпорядженні команди тестування
  • необхідність тестування програмного продукту в умовах, що вимагають швидкого перемикання між призначеними для користувача конфігураціями

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

Технології віртуалізації, грамотно застосовані в процесі розробки і тестування, можуть істотно знизити трудовитрати і значно підвищити ефективність процесу, що позитивно позначиться на якості випущеного програмного продукту. Так конкретно віртуалізація дозволяє це зробити:

  • тестувальники в процесі роботи з віртуальними машинами можуть створювати необмежену кількість користувальницьких конфігурацій на своїй фізичній машині, запускаючи, в разі потреби, що найкраще підходить даний момент
  • створені одного разу багатомашинні конфігурації можуть бути налаштовані за допомогою інструментів платформ віртуалізації і просто перенесені на інше обладнання, при цьому їх повторна установка не потрібно
  • резервна копія віртуальної машини може бути створена шляхом копіювання папки або створення миттєвого знімка стану ( «снапшотов»)
  • після знаходження помилки тестувальником, віртуальна машина з повторюваним дефектом може бути передана розробнику, при цьому вивільняються ресурси на подальше тестування
  • необхідні умови для тестування можуть бути швидко створені за рахунок гнучкої настройки параметрів апаратної середовища віртуальної машини (об'єм оперативної пам'яті, число віртуальних процесорів, обмеження ресурсів)
  • можливість швидкого відкоту до збереженого стану віртуальної машини з необхідною конфігурацією або перемикання між декількома одночасно працюючими гостьовими системами зменшує час на тестування

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

Інструменти віртуальних машин для тестування і розробки

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

  • Некероване розгортання віртуальних машин на клієнтських машинах або серверах тестування, при якому або самі тестувальники створюють необхідні їм конфігурації, або копіюють шаблони віртуальних систем на свої комп'ютери з центральної бібліотеки віртуальних шаблонів (файлового сервера). Перевага даного підходу - дешевизна рішення, можна скористатися однією з багатьох безкоштовних систем віртуалізації (VMware Server, Virtual PC, VirtualBox та інші). Основні недоліки - стихійне розгортання віртуальних машин породжує конфлікти в мережевій інфраструктурі, відсутність контролю над використанням ліцензій на операційні системи і прикладне ПО, неможливість інтеграції в існуючу ІТ-середовище організації.
  • Кероване розгортання віртуальних систем з централізованих бібліотек віртуальних шаблонів, з повним контролем над використанням віртуальних машин в рамках ІТ-інфраструктури компанії. До переваг даного підходу треба віднести можливість вирішення конфліктів між віртуальними і фізичними системами в мережі, контроль використання ліцензій, можливість моніторингу використання віртуальної інфраструктури і створення загального простору між різними учасниками процесу розробки і тестування, інтеграція в реальну ІТ-інфраструктуру підприємства. Основний недолік даного підходу - висока вартість рішень. Приклади продуктів, що забезпечують кероване розгортання віртуальних машин: VMware LabManager, VMLogix LabManager, Microsoft System Center Virtual Machine Manager.

Інструменти для розробки і тестування при некерованому розгортанні

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

  1. Створення безлічі користувальницьких конфігурацій.

    При наявності великого обсягу вільного дискового простору на машині тестувальника за допомогою платформи віртуалізації можна створити необмежену кількість віртуальних систем, кожна з яких може бути завантажена на вимогу, без зупинки робочої діяльності працівника в хостовой системі. Віртуальні машини можуть також застосовуватися на спеціалізованих серверах тестування на основі платформ VMware ESX Server, XenEnterprise або Virtual Iron. При цьому можуть бути призначені певні права користувачам віртуальних систем, а також обмежені фізичні ресурси сервера, які можуть бути використані конкретним користувачем. На файловому сервері з віртуальними шаблонами можуть зберігатися встановлені віртуальні машини, які розгортаються на сервера тестування або робочі станції. В цьому випадку потрібно враховувати особливості використання віртуальних машин відповідно до ліцензії. У більшості випадків кожна віртуальна машина вимагає окремої ліцензії, однак є й винятки: наприклад, ліцензія Windows Server 2003 Datacenter Edition дозволяє запускати необмежену кількість віртуальних екземплярів ОС.

    Якщо налаштоване тестове оточення вже розгорнуто на фізичній машині, його можна мігрувати на віртуальну за допомогою продуктів вендорів платформ віртуалізації і сторонніх розробників. До таких рішень відносяться продукти PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit.

  2. Створення багатомашинних конфігурацій на одному фізичному сервері.

    Платформи віртуалізації, орієнтовані на тестування ПО (VMware Workstation, Virtual PC, VirtualBox, Xen), дозволяють створювати цілі віртуальні інфраструктури з різними типами мережевого взаємодії в межах одного фізичного хоста. Наприклад, можна створити кілька «блоків» з віртуальних серверів (сервер баз даних, сервер додатків, оточення клієнта), налаштувати мережеві адаптери віртуальних машин (в однієї машини їх може бути кілька, в VMware Workstation - до десяти), і запустити тестируемую зв'язку серверів . При цьому платформи віртуалізації дозволяють підключати мережеві адаптери віртуальних машин до різних сегментів віртуальної мережі.

    Приклад віртуальної мережі в межах фізичного хоста

    Після того, як тестова віртуальна інфраструктура буде створена, можна налаштувати параметри каналів зв'язку між віртуальними машинами.

    Приклад настройки пропускної здатності сегмента віртуальної мережі в VMware Workstation

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

  3. Резервне копіювання віртуальних машин при тестуванні.

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

    Якщо тестування проводиться на виділених серверах тестування, то для створення резервних копій віртуальних машин можуть застосовуватися спеціалізовані рішення вендорів платформ віртуалізації, такі як vRanger Pro компанії Vizioncore, VMware Consolidated Backup (VCB), або ще не випущене рішення Microsoft Data Protection Manager для Virtual Server 2005 R2, які дозволяють створювати резервні копії віртуальних машин без їх зупинки.

  4. Демонстрація дефектів розробникам.

    При знаходженні дефекту тестувальник може просто зберегти стан системи, в якому проявляється помилка, в снапшотов і продовжити тестування системи. При необхідності демонстрації дефекту, віртуальна машина може бути передана розробнику, який зможе працювати з нею, не боячись пошкодити оточення тестувальника. Крім того, на платформі VMware Workstation віртуальні машини можуть діяти як VNC-сервери, без необхідності установки додаткового ПЗ для віддаленого доступу до робочого столу.

    Налаштування доступу VNC-сервера віртуальної машини VMware Workstation

  5. Гнучка настройка апаратної середовища.

    Найчастіше при тестуванні програмного забезпечення потрібна велика гнучкість щодо настройки апаратних компонентів. Наприклад, при стресовому тестуванні (Stress Testing) потрібна перевірка роботи програмного продукту в екстремальних або обмежених умовах (нестача дискового простору, обрив з'єднання з мережею). У цьому випадку, за допомогою платформи віртуалізації віртуальній машині можна додати нові віртуальні пристрої або обмежити виділяються їй ресурси.

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

    Додавання віртуального диска на платформі Virtual PC 2007

    Що стосується контролю ресурсів, багато платформи віртуалізації дозволяють обмежувати ресурси віртуальної машини або пулу ресурсів віртуальних машин, що дозволяє моделювати реальні умови для користувача оточень.

    Обмеження ресурсів пулу віртуальних машин на платформі VMware ESX Server

    Сучасні платформи віртуалізації підтримують стандарт USB 2.0, велика кількість віртуальних мережевих адаптерів у віртуальній машині, емуляцію SCSI-дисків, а також подання різного числа процесорів в гостьовій системі за допомогою віртуального SMP (Symmetric Multi Processing).

  6. Робота з декількома віртуальними системами одночасно.

    Ця можливість дозволяє тестувальникам не тільки використовувати екземпляри різних гостьових систем при тестуванні, але і здійснювати простий обмін файлами як між хостом і гостьової ОС, так і між гостьовими ОС за допомогою механізму Drag & Drop. При цьому деякі платформи віртуалізації дозволяють виробляти простий обмін файлами або через загальні папки хостовой системи (Shared Folders), або «перетягувати» файли між гостьовими системами (VMware Workstation).

    Багато платформи віртуалізації дозволяють використовувати спільний з хостовой системою буфер обміну, що значно спрощує, зокрема, копіювання повідомлень про помилки програм в систему багтрекінга.

Інструменти для розробки и тестування при некерованому розгортанні

Основою при керованому розгортанні віртуальних машин є спеціалізовані рішення для створення і обслуговування тестових віртуальних лабораторій (Virtual Labs), в межах яких здійснюється контроль над використанням віртуальних систем різними групами користувачів, автоматизоване розгортання віртуальних машин на комп'ютери учасників проекту та створення спільної робочої середовища. Ці рішення досить дорогі (наприклад, інфраструктура VMware LabManager обійдеться не менше ніж в $ 15 000), проте виправдовують себе в великих масштабах використання. Великі компанії, такі як Dell, дуже широко використовують віртуальні машини в межах віртуальних лабораторій для випробувань програмних продуктів. Такі системи використовують мережі зберігання даних SAN, де в загальній бібліотеці віртуальних шаблонів розташовуються шаблони віртуальних машин, які розгортаються на вимогу на вільних серверах тестування на основі платформ віртуалізації. Використання віртуальних лабораторій дає наступні переваги:

  • Робота з багатомашинний конфігураціями як з єдиним модулем, можливість публікації цих модулів
  • Зниження тимчасових витрат на конфігурацію систем
  • Розмежування доступу до віртуальних машин і демонстрація дефектів шляхом передачі посилань на проблемну ситуацію, збережену у вигляді знімка стану гостьової системи
  • Загальна бібліотека шаблонів з можливістю дозволу мережевих конфліктів при розгортанні (ідентифікатори безпеки SID, призначення унікальних MAC-адрес віртуальним мережевим інтерфейсам)
  • Централізоване обслуговування і розгортання оновлень в тестових середовищах
  • Моніторинг завантаження серверів тестування

В даний момент найбільш популярними рішеннями для керованого розгортання віртуальної тестової інфраструктури є продукти VMware LabManager (для платформи ESX Server) і VMLogix LabManager (для платформ Microsoft, VMware і XenSource).

Тестові лабораторії VMware LabManager

Компанія VMware пропонує великим компаніям використовувати віртуальну тестову інфраструктуру на основі рішення LabManager (Колишня розробка поглиненої компанії Akimbi), яке дозволяє максимально швидко розгортати віртуальні машини на серверах тестування і контролювати використання віртуальних систем, при цьому процес виглядає так, ніби користувач працює з фізичним комп'ютером. Модель роботи віртуальної лабораторії представлена ​​далі:

Архітектура рішення VMware LabManager

Крім всіх перерахованих переваг систем управління віртуальними лабораторіями, VMware LabManager надає інтеграцію з популярними засобами тестування Borland SilkCentral Test Manager и HP Quality Center , Має можливості для розгортання шаблонів в кілька кліків миші, підтримує протокол LDAP, легко інтегрується з іншими рішеннями для віртуальної інфраструктури VMware і має можливості для автоматизації операцій за допомогою власного API (Application Program Interface). Основний недолік цього продукту - можливість обслуговування віртуальних серверів тільки на платформах VMware.

Тестові лабораторії VMLogix LabManager

На відміну від рішення компанії VMware, продукт VMLogix LabManager підтримує платформи віртуалізації різних вендорів. В якості основи віртуальної тестової лабораторії можна використовувати платформи Microsoft (Virtual Server), Xen (XenEnterprise) і VMware (ESX Server і Server). Крім того, LabManager компанії VMLogix підтримує обслуговування фізичних серверів організації. Архітектура рішення VMLogix LabManager представлена ​​нижче:

Архітектура рішення VMLogix LabManager

LabManager надає користувачам портал самообслуговування, за допомогою якого користувачі можуть розгортати віртуальні машини з централізованої бібліотеки шаблонів і ISO-образів операційних систем, а також має можливості по управлінню ліцензіями, настройки зон призначаються IP-адрес і можливості аудиту безпеки віртуальної тестової інфраструктури. Крім того, VMLogix LabManager також має засоби автоматизації операцій за допомогою програмного інтерфейсу API, можливості по розгортанню та обслуговування багатомашинних конфігурацій і функції для демонстрації проблемних ситуацій шляхом надання загального доступу до знімків стану віртуальних машин.

Висновок

Модель організації процесу розробки і тестування за допомогою віртуальних машин дозволяє істотно знизити витрати на розгортання тестових призначених для користувача оточень і конфігурацію тестових середовищ. За статистикою, при тестуванні програмних продуктів на фізичних серверах і робочих станціях на ці завдання йде до 50 відсотків часу команди тестування. Віртуальні машини на платформах різних вендорів дозволяють скоротити цей час в кілька разів, до 5% від загальних витрат на тестування. Підвищена гнучкість віртуальних систем і їх незалежність від обладнання дозволяють працювати з ними, як з якимись блоками, з яких будується віртуальна тестову інфраструктуру компанії. Можливість надання загального доступу до знайденим дефектів учасникам команди розробки і користувачам продукту дозволяє істотно прискорити пошук і виправлення помилок. У багатьох компаніях вже стало стандартом де-факто тестування за допомогою віртуальних машин.

Однак процес тестування на віртуальних системах має деякі обмеження: наприклад, віртуальні системи не рекомендується застосовувати при тестуванні продуктивності (Performance Testing), а також тестуванні додатків, що пред'являють високі вимоги до фізичних ресурсів комп'ютера. Для інших видів тестування віртуальна тестову інфраструктуру є одним з кращих рішень для підвищення ефективності процесу розробки, а також спрощення взаємодії між учасниками команди.

О, якщо нам потрібно десять жорстких дисків?
Але що якщо ми розробляємо програму, для якого потрібні різні версії Internet Explorer?