Браузери для навантажувального тестування

    Після написання всіх тестів постало питання, на яких браузерах його запускати. У разі функціонального тестування тут все просто - потрібно запускати тести на тих браузерах, на яких працюватимуть користувачі. Для нас це IE 9. Тому спробуємо запустити тести на IE з декількома екземплярами браузера на машину, що б один комп'ютер зміг емулювати роботу декількох користувачів (В Selenium один WebDriver - це один примірник браузера). В результаті на моїй машині (4Гб ОЗУ, 2.3 Core 2 Duo) нормально працювало тільки 4 примірники IE. Що не дуже добре - для емуляції двохсот користувачів потрібно 50 машин. Потрібно було шукати альтернативу. А це: а) інші desktop браузери б) headless браузери.

З desktop браузерів протестовані були FF і Chrome. З Chrome ситуація була аналогічна, плюс він для своєї роботи вимагав запуску в окремому процесі WebDriver'а на кожен екземпляр Chrome. Що підвищувало вимоги до ресурсів. З FF ситуація була трохи краще - нормально працювало 5 браузерів без додаткового запуску WebDriver'ов. Але ситуацію це не сильно поліпшило.

    Тоді довелося тестувати headless браузери - браузери, які повністю працюють з сайтом (будують DOM виконують JS), але не відображають його. По ідеї вони повинні працювати швидше. З усіх headless браузерів зупинився на 2 - PhantomJS і HttpUnit. Перспективно виглядав PhantomJS, заснований на Webkit. Але по факту він ні чим не відрізнявся від FF по споживанню ресурсів, але мав наступні мінуси - іноді не знаходив елементи на сторінці і не коректно відображав сайт на скріншотах. Так що не вдавалося зрозуміти, чому сталася помилка. З HtmlUnit все набагато простіше - його webdriver не підтримував alert, а це для нашого web додатка було критично.

    У підсумку повернулися до використання FF в нагрузочному тестуванні. Хоча в ньому теж виникли проблеми з alert'амі - іноді виникали помилки java.lang.Boolean can not be cast to java.lang.String (java.lang.ClassCastException) (ось посилання на помилку в Google Code code.google.com/p / selenium / issues / detail? id = 3565 ). Виправити цю помилку не вийшло, але зате вийшло відмовитися зовсім від alert'ов. Так що надалі можна спробувати знову використовувати HtmlUnit. Хоча у всіх headless браузерів є одна спільна незручність, пов'язана з їх специфікою, - вони не відображають сторінки і так просто не можна зрозуміти, через що сталася помилка. Можливість зняття скріншота не сильно допомагає - іноді він не інформативний.

 

Конфігурація Selenium'а

    Сервер Selenium'а підтримує запуск в двох режимах - як standalone сервер (режим запуску за замовчуванням) і як частина загальної мережі з Selenium серверів - Selenium Grid (режими запуску з -role hub та -role node). Так як нам потрібно було використовувати велику кількість комп'ютерів, то перший режим не дуже підходить - в цьому випадку потрібно буде управляти кожним сервером окремо. Тобто, по суті, писати свій менеджер серверів. Хоча, на початку, мені це варіант імпонував - в такому разі у нас буде повний контроль над тим, на якій машині який браузер запускати. Але надалі я від нього відмовився - повний контроль над запуском браузерів виявився не потрібен, плюс Selenium Grid підкупив своєю простотою у використанні. (Посилання на сторінку конфігурації Selenium Grid code.google.com/p/selenium/wiki/Grid2 )

У підсумку прийшли до наступної конфігурації: На одному комп'ютері запускався Selenium в режимі hub з додатковим параметром -timeout 0. Це потрібно було тому, що іноді сесії закривалися по timeout із-за тривалої бездіяльності тестів. На інших комп'ютерах запускався Selenium в режимі node. Для потужних комп'ютерів, здатних забезпечити роботу 15 браузерів, node Selenium'а запускався з додатковим налаштуванням, що дозволяє запускати 15 копій FF і вказує, що одночасно можна працювати з 15 сесіями.

 

Проведення тестів

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

    Пару слів потрібно сказати про тестові сценарії і підрахунок часу їх виконання. Кожен сценарій включав в себе відкриття документів кожного типу. Тобто спочатку відкривався вхідний документ, потім вихідний документ і т.д. Ось тут потрібно врахувати наступну ситуацію - якщо потрібно зняти час відкриття тільки вхідного документа, і при цьому запустити на всіх машинах виконання тільки по сценарію, то час буде істотно менший (на 50%) ніж, якби знімати час при одночасному виконанні всіх сценаріїв. У моєму випадку, швидше за все це було пов'язано з кешуванням на рівнях web програми та СУБД. І тим, що відкривалося мало унікальних документів. Можливо, при великій кількості різних документів відмінності будуть не настільки істотні.

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

 

Підведення підсумків

    В результаті тестів для 1-го, 16-ти, 26-ти і 70 користувачів було складено графік по кожних сценаріях. Поки ще кількість користувачів не занадто велике, що б зробити точні висновки, але вже зараз можна простежити темпи зростання часу.
    Залежність часу відкриття документів від кількості працюючих користувачів:

 

 

Залежність часу списку документів від кількості працюючих користувачів:

 

 

    Далі тести будуть продовжуватися, щоб побудувати графік для 200 користувачів. В результаті повинен вийти графік, схожий на цей (узятий з msdn.microsoft.com/en-us/library/bb924375.aspx ):

 

 

По ньому вже можна буде точно визначити можливості системи і знайти її вузькі місця.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: