Інфраструктура для навантажувального тестування у хмарі

Відвідувачів: 419 Переглядів: 527 (сьогодні 0)Шрифт:

Найскладніше в тестуванні навантаження — почати його робити. Що потрібно, щоб розпочати навантажувальне тестування? У загальному випадку – одна машина та цільовий сервіс. Цей метод хороший до того моменту, поки ресурсів однієї машини перестане вистачати для генерації потрібного навантаження.

Перестало вистачати однієї машини – беремо дві. Три. Десять. Де взяти десять машин? Попросити у ІТ-відділу. Закінчивши тестування навантаження, повідомити про це ІТ-відділ. Через дві години після того, як ІТ-відділ поверне інфраструктуру у своє володіння, виявляється [щось] та інфраструктура потрібна знову. Просимо знову - і час, який ІТ-відділ витратив раніше на розгортання інфраструктури, раптово збільшився (звісно, ​​ніхто не знає, чому).

Звичайна історія. Розробники хочуть швидко отримати та почати використовувати. Навантажувальне тестування – це ітеративний процес, і нарощування інфраструктури – теж. Що, якби розробники мали цю інфраструктуру постійно? Настроєну, на запит? Вимкнену, коли не треба, щоб платити щонайменше? Про те, як розгорнути цю інфраструктуру на основі Visual Studio 2013 йтиметься у цій статті. В результаті у вас буде завжди доступна готова інфраструктура для тестування навантаження, яку достатньо включити - і можна приступати до тестування. У вимкненому стані оплачуватиметься тільки сховище для образів цих машин

Мета : Створити інфраструктуру для тестування навантаження.

Опис: Вся інфраструктура буде розгортатися у віртуальних машинах Microsoft Azure. Навантажувальнийтестування в Microsoft Azure може бути виконане у трьох варіантах:

  1. Visual Studio Online (http://www.visualstudio.com/en-us/get-started/load-test-your-app-vs).
  2. Microsoft Azure Cloud Services
  3. Virtual Machines

Об'єкт тестування

Сервіс WCF, який надає SOAP один синхронний метод (калькулятор). Рішення можна використовувати для тестування проектів будь-якої складності. Розміщуватиметься сервіс може і як Cloud Service, і як звичайний сервіс на окремій віртуальній машині. Якщо сервіс буде розміщуватись на віртуальній машині, то в процесі навантаження ми зможемо збирати з машини будь-які потрібні (налаштовані) лічильники продуктивності. Однак буде відсутня можливість автоматичного масштабування, яка є у Cloud Service. Наш сервіс буде надавати одну кінцеву точку для підключення, basicHttpBinding.

Послідовність дій:

У процесі лабораторної роботи буде розгорнуто 4 віртуальні машини на Microsoft Azure:

  • Контролер тестування та SQL 2012 Express Server
  • Агент тестування
  • Тестовий сервіс (SUT – System under the testing)
  • Visual Studio 2013, в якій буде розроблено тест навантаження

Контролер

Створіть контролер — під час вибору образу Microsoft Azure виберіть образ Windows 2012 Server R2. У налаштуваннях віртуальної машини під час створення відкрийте такі порти:

  • TCP порт 445 для віддаленого складання лічильників продуктивності
  • UDP порт 1434 для SQL Browser та TCP 1433 для підключення до SQL сервера
  • TCP порт 6901 для підключення до Test Controller`y
  • Remote Destop, він потрібний на всіх створюваних віртуальних машинах.

Підключіться до віртуальної машини через RDP (натиснувши кнопку Connect/Підключення на порталі керування Microsoft Azure) і завантажте Agents для Microsoft Visual Studio 2013. Встановіть TestController (vstf_testcontroller.exe)

навантажувального

На вкладці SQL Server Services увімкніть та запустіть служби SQL Server Browser та SQL Server.

У налаштуваннях Firewall`a дозвольте підключення на такі порти:

  • вихідні підключення на агент (порт 6910)
  • вхідні підключення до служби контролера 6901
  • вхідні підключення до служби RPC для збору лічильників продуктивності – порт 445
  • підключення до студії (фреймворку LoadTest), вихідний порт 6915
  • вхідні підключення на TCP порт 1433 та UDP 1434

Для простоти можна написати та виконати bat-файл:

netsh advfirewall firewall add rule name=«Test Agent Out» dir=out action=allow protocol=TCP localport=6910 netsh advfirewall firewall add rule name=«Test Controller In» dir=in action=allow protocol=TCP localport= 6901 netsh advfirewall firewall add rule name=RPC In dir=in action=allow protocol=TCP localport=445 netsh advfirewall firewall add rule name=VS Studio Out dir=out action=allow protocol= TCP localport = 6915 netsh advfirewall firewall add rule name = "SQL Express" dir = in action = allow protocol = TCP localport = 1433 netsh advfirewall add rule name = SQL Browser dir = in action = allow protocol=UDP localport=1434

Відкрийте гілку реєстру HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa і додайте туди DWODR параметр DisableLoopBackCheck (значення 1). Це вирішує проблему із підключенням до SQL серверу із зовнішнього домену. Щоб агент тестування зміг підключитися до контролера, треба в налаштуваннях IPv4 (мережевого адаптера)прописати DNS-суфікс:

Перейдіть до Test Controller Configuration Tools. У рядку підключення до SQL-бази пропишіть замість localhost повне DNS-ім'я віртуальної машини та натисніть Apply settings.

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

Створіть нову віртуальну машину. Під час створення відкрийте такі порти:

  • TCP-порт 445 для віддаленого складання лічильників продуктивності
  • TCP-порт 6910 для підключення до Test Agent`y
  • TCP-порт Remote Desktop

Підключіться до створеної машини по RDP (натиснувши кнопку Connect/Підключення) і завантажте дистрибутив Test Agent. Встановіть Test Agent.

У налаштуваннях Firewall`a слід дозволити підключення на такі порти:

  • вхідні підключення до служби контролера 6910,
  • вихідні підключення до контролера тестування 6901,
  • вхідні підключення до служби RPC для збору лічильників продуктивності – порт 445,
  • вихідне TCP-підключення на порт, який прослуховує тестовий сервіс, у нашому випадку це 9117.

bat-файл: netsh advfirewall firewall add rule name=«Test Agent In» dir=in action=allow protocol=TCP localport=6910 netsh advfirewall firewall add rule name=«Test Controller Out» dir=out action =allow protocol=TCP localport=6901 netsh advfirewall firewall add rule name=«RPC In» dir=in action=allow protocol=TCP localport=445 netsh advfirewall firewall add rule name=«Test service OUT» dir =out action=allow protocol=TCP localport=9117

Пропишіть у налаштуваннях DNS мережного адаптера суфікс cloudapp.net.

Пропишіть рядок підключення до контролера тестування (DNS + порт) та натиснітьApply.

Якщо під час конфігурування Test Agent видасть помилку, що не вдається встановити зв'язок контролера з агентом, але журнал буде видно, що агент зміг підключитися до контролера, то в цьому випадку в конфігурації контролера (на відповідній машині) в розділі appsettings слід прописати налаштування: />

На цьому кроці має бути встановлений зв'язок між агентом та контролером.

Віртуальна машина із тестовим сервісом

В якості об'єкта тестування було обрано WCF-службу. 10>>

Вихідний код разом з бінарними файлами, що виконуються, можна взяти тут (проект CalculatorService). Створіть нову віртуальну машину. Під час створення відкрийте порти:

9117 (даний порт прослуховує наш тестовий сервіс)

Після створення відкрийте ці порти в Firewall операційної системи.

Далі, за допомогою команди sc create NewService binpath = ". \ Debug \ CalculatorService.exe створіть і запустіть тестовий сервіс з оснащення сервісів (services.msc).

Створіть нову віртуальну машину (Windows 8, Visual Studio 2013 Ultimate). У консолі відкрийте порт 6915. Цей порт потрібен контролеру тестування для взаємодії зі студією.

Підключіться до віртуальної машини RDP.

У налаштуваннях Firewall:

  • відкрийте порт 6915 для вхідних з'єднань,
  • відкрийте порт 6901 для вихідних на контролер,
  • вихідні порти UDP 1434 та TCP 1433 для підключення до бази SQL,
  • вихідний 445 для підключення до RPC (збір лічильників продуктивності).

Так само, як і скрізь, пропишіть DNS-суфікс cloudapp.net у налаштуваннях IPv4.

Після цього слід отримати доступ до віддаленого збору лічильників продуктивності.

Як machineName можна перерахувати всі віртуальні машини: контролер, агент, машина з встановленим тестовим сервісом.

Запустіть Visual Studio 2013. Відкрийте Solution із пакета з рішенням. Створіть нове рішення Web Performance And Load Test Project. Додайте до нього UnitTestProject1 (в ньому міститься простий тестовий метод разом із обгорткою для виклику тестового сервісу Calculator) В SolutionItems додайте новий файл типу TestSettings і відкрийте його. На вкладці Roles встановіть RemoteExecution та пропишіть вручну DNS-ім'я віртуальної машини контролера.

У меню Load Test виберіть вкладку Manage Test Controller та переконайтеся, що студія може підключитися до контролера:

Повинні бути видно рядок підключення до бази та найменування агента (якщо він активний).

У меню Load Test виберіть Select active test settings => Remote.testsettings. Створіть новий LoadTest. У Load Test Wizard на вкладці Test Mix додайте юніт-тест TestMethod1 із проекту UnitTestProject. Якщо він не відображається, треба закрити Wizard і перекомпілювати рішення.

На вкладці Counter Set додайте машину, на якій встановлений тестовий сервіс (якщо ми хочемо в процесі тестування збиратися з нього лічильники), і вибрати для неї хоча б один із наборів лічильників, що доступні за замовчуванням.

Збережіть тест. Додайте WCF-лічильники продуктивності для машини із тестовим сервісом.

Для цього треба двічі натиснути на створений навантажувальний тест. Використовуючи праву кнопку миші створити новий Counter Set. Натиснути правою кнопкою миші на створений Counter Set та вибрати Add counters. Вибрати потрібний комп'ютер (з якого треба прочитати доступні лічильники) та потрібний лічильник.

Натиснути OK, після чого можна додати створений Counter Set до Counter Set Mapping, щоб система збирала лічильники в процесі проходження тесту.

Тепер тест можна запустити. Результати тестування кожного прогону тесту зберігатимуться в автоматично створеній на контролері базі LoadTest.

Використовуючи плагіни MS Office, можна побудувати дуже докладний звіт з навантажувального тестування (докладніше на http://msdn.microsoft.com/en-us/library/ee923686.aspx) – порівняти два запуски відносного будь-якого лічильника (час відгуку, помилки, пам'ять) , процесорний час і т.п.), або побудувати динаміку зміни кожного лічильника по діапазону прогонів тесту. Агенти тестування можна масштабувати горизонтально. Тобто. Використовуючи консоль керування Microsoft Azure, можна зберегти образ віртуальної машини з агентом тестування та створити його клон. Після запуску він автоматично підключиться до контролера.

Завдяки цьому підходу навантаження можна генерувати відразу з кількох агентів. Це потрібно, коли один агент не впорається.