Навантажувальне тестування Web-додатків за допомогою IBM Rational Performance Tester: Частина 1. Огляд функцій, засобів і звітів, Різне, Програмування, статті

Складається враження, що жорстке календарне планування і обмеження в ресурсах вражають процес розробки на різних стадіях. Іноді колективи розробників намагаються зрізати кути, мінімізуючи навантажувальне тестування на кожній ітерації. Найчастіше Навантажувальне тестування проводиться тільки в кінці циклу розробки, як раз перед розгортанням проекту. При цьому неминуче виникає небезпека того, що якість і можливості масштабування додатки не зможуть задовольнити очікування клієнта щодо SLA (угоди про рівень сервісу). IBM ® Rational ® Performance Tester версії 7 пропонує прискорене тестування навантаження, що дозволяє гарантувати продуктивність і якість програмного забезпечення.


Цільова аудиторія:


Ця стаття буде корисна наступним категоріям фахівців:



Введення в серію статей


Програма IBM ® Rational ® Performance Tester являє собою інструмент для тестування продуктивності, який моделює різні рівні користувача навантаження, тим самим, дозволяючи наблизити умови тестування до реальних. За умови правильного планування і реалістичного моделювання реальних сценаріїв, цей інструмент використовує поточні навантаження для оцінки навантажень, можливих у майбутньому. Наприклад, якийсь додаток клієнта може потенційно обслуговувати 5000 користувачів. За допомогою Rational Performance Tester ви можете з легкістю змоделювати навантаження в 1000, 2000, 3000, 4000, 5000 користувачів і навіть більше (для обліку непередбаченого проектом фактичного зростання числа користувачів), що дозволить із більшою точністю визначити в проекті вимоги до сервера, наприклад, оптимальні характеристики процесора і вимоги до пам’яті. Можна виявити і діагностувати вузькі щодо продуктивності місця системи, незалежно від того, де локалізуються проблеми – в мережі, бази даних, сервері додатків або навіть в користувальницькому додатку. Функція аналізу основних причин дозволяє ще глибше проаналізувати рівні додатки, які можуть включати такі компоненти Web-сторінки, як корпоративні bean-компоненти Java ™ (EJBs), сервлети, API Java ™> Database Connectivity (JDBC), Web-сервіси і т. д. Ця функція дозволить легко і ефективно виявити винуватця проблеми за допомогою оперативного або автономного аналізу звітів.


Інструмент Rational Performance Tester також допоможе в створенні, виконанні та аналізі тестів продуктивності, в перевірці масштабованості та надійності ваших Web-додатків до розгортання. Підтримувані за замовчуванням протоколи, такі, як HTTP і HTTPS, дозволяють виконати навантажувальні тести в Web-додатках. Доступні також такі модулі розширення:



Принцип роботи Rational Performance Tester нагадує запис відеокліпів за допомогою відеокамери. Він дозволяє записати стадії виконання навантажувального тесту, а потім відтворити ці стадії з відповідними користувацькими навантаженнями. У частині 1 цієї серії статей (у даній статті) розповідається про функції та інструментах, включених у версію 7.


Зазвичай при навантажувальні тестуванні Web-додатки необхідно ідентифікувати різні сценарії за допомогою добре продуманих планів тестування. Часто в процесі виконання навантажувального тесту бажано, щоб якийсь користувач розподіляв навантаження між кількома тестовими клієнтами. Рівномірно розподіляючи користувача навантаження між декількома машинами, він сприятиме формуванню більш показових звітів. Це хороший спосіб запобігти недостатню завантаження одних машин при надмірній навантаженні інших. У частинах 2 і 3 серії розглядаються питання ефективного розподілу користувальницької навантаження, яке не вплине на раніше записані тестові скрипти. Для цього ми вивчимо спеціальний редактор програми, оснащений засобами візуального управління і має ієрархічну (деревоподібну) структуру, а також дії, які необхідні для створення, редагування та планування імітації, а також для отримання аналітичних звітів.


Навантажувальний тест хороший рівно настільки, наскільки гарні звіти про його результати, тому заключна стаття даної серії, Частину 4, присвячена виключно звітів. Ми розповімо про те, як вивчати, діагностувати, аналізувати та інтерпретувати різні аналітичні звіти, що надаються інструментом Rational Performance Tester. Наприклад, Web-додаток можна для аналізу розбити на різні компоненти, такі, як bean-компоненти EJB, сервлети, API JDBC і Web-сервіси. Ми також розглянемо звіт з настройками за замовчуванням і розповімо про те, як можна змінити його відповідно до власних уподобаннями і потребами.


Мета цієї серії статей – допомогти вам розібратися у функціях, питаннях топології і обмеженнях, щоб ви могли створювати і тестувати Web-додатки та аналізувати звіти по продуктивності. Маючи ці знання, а також простий і зручний інструмент Rational Performance Tester, ви ніколи більше не будете вважати навантажувальне тестування Web-додатків тяжким тягарем і зможете включати його в кожну ітерацію розробки ПЗ.


Короткий опис даної статті


Інструмент IBM Rational Performance Tester надає повнофункціональні засоби, що дозволяють зробити Навантажувальне тестування не тільки ефективним, але і простим. Вам більше не доведеться возитися з складними тестовими скриптами, які доводилося регулярно обслуговувати, причому найчастіше за допомогою напівавтоматизованих інструментів тестування. У будь-якому випадку вам більше не доведеться писати код тестових скриптів, тому що для задач адміністрування передбачений інтерактивний графічний користувальницький інтерфейс (GUI) на базі інфраструктури Eclipse 3.2. Іншими словами, ви можете керувати всім життєвим циклом тестування за допомогою GUI, маючи можливість використовувати і власний код для більш поглибленого тестування. Підхід з використанням GUI охоплює наступні основні категорії:



Далі в статті докладно розглядається кожна з цих категорій.:


Інтерактивні графічні тести


По-перше (і насамперед), IBM Rational Performance Tester створений на базі розширюваної платформи розробки, що використовує інфраструктуру Eclipse версії 3.2. Численні переваги інфраструктури Eclipse для розробки добре відомі, але для фахівців-практиків IBM Rational Performance Tester, крім того, надає комплексні, контекстно-залежні перспективи (елементи графічного інтерфейсу користувача) для створення, управління і планування виконання тестових скриптів. Для будь-яких завдань – від створення тестів і розподілу користувальницької навантаження до збору даних – в графічному інтерфейсі програми є відповідні подання. На малюнку 1 показана перспектива для тестування з настройками за умовчанням.




Ви можете працювати з різними уявленнями в залежності від використовуваної перспективи. Наприклад, за умовчанням перспектива тестування надає консоль з чотирма панелями, яким відповідають такі уявлення: General > Outline, General > Properties, Test > Performance Test Runs в панелі внизу зліва і General > Tasks, Test > Recorder Control, Test > Protocol Data у нижній панелі. Але ви не обмежені тільки цими уявленнями. Будь-коли можна використовувати подання, які підходять для конкретних завдань, наприклад, оглядач баз даних Database Explorer або журнал помилок Error Log. Додавання конкретного уявлення в робочу область не представляє особливих складнощів. Наприклад, щоб вивчити підключення до бази даних за допомогою подання Database Explorer, просто виконайте наступні кроки:



  1. Виберіть з меню команди Windows > Show View > Other. Більш часто використовувані уявлення, наприклад, журнал помилок Error Log, схема Outline і завдання Tasks, перераховані в списку у вигляді підменю, щоб їх було легше знайти (див. малюнок 2). У перспективі за замовчуванням передбачений заздалегідь заданий набір уявлень. Ви можете налаштувати будь-яку перспективу відповідно до власних уподобань, додавши або виключивши окремі подання.


  • Щоб знайти потрібне подання, скористайтеся функцією Type-Forward Filtering (Рисунок 3); часто вам навіть не доведеться вводити рядок пошуку повністю. В даному випадку для подання Database Explorer виявилося достатнім ввести слово data.


  • У програмі є різні перспективи з відповідними поданнями для виконання різних завдань, загальних (General), аналітичних (Analysis), пов’язаних з підключеннями (Connectivity), CBS, налагодженням (Debug), профілюванням (Profiling), веденням журналів (Logging) і розробкою коду SQL (SQL Development). Вам залишається тільки вибрати потрібну перспективу в потрібний момент. Подання можна перетягувати в межах вікна за допомогою миші, змінювати їх розташування відносно один одного; можна також відновити перспективу за замовчуванням, якщо вам потрібно повернутися до оригінального макету вікна. Однак повернення до значень за замовчуванням виконується тільки для відкритої в даний момент перспективи. Наприклад, якщо вибрано подання Database, воно буде відображатися так, як на малюнку 4.



    Про що ще варто згадати:




  • Перспективи можна налаштувати відповідно до своїх вподобань і зберегти (рисунок 6). Настроювані категорії: доступні групи команд, команди меню і кнопки панелі інструментів.


  • Крім того, в програмі є оглядач Web-сервісів Web Services Explorer.


  • Збір даних тестування в реальному часі, уточнення, відтворення і планування тестування


    Збір даних, уточнення, відтворення і планування виконання тесту не представляє ніяких складнощів, тому що Rational Performance Tester спеціально пристосований для того, щоб з ним могли працювати навіть починаючі користувачі. Усі механізми, що забезпечують роботу програми, наприклад, механізм запису і відтворення скриптів, виконуються приховано від середнього користувача. Це зроблено для того, щоб спростити створення і обслуговування тестів. Щоб записати тест, виконайте наступні кроки:



    1. Спочатку створіть тестовий проект. Виберіть з меню команди File > New > Performance Test Project. Після запрошення введіть ім’я для нового проекту.



    1. Виберіть запис. Для Web-додатки виберіть HTTP recording. Натисніть кнопку Next.
    2. На наступній сторінці виберіть тестовий проект для тестового скрипта (по імені, яке ви йому дали).


  • Якщо ви бачите вікно, показане на малюнку 10, то можете зібрати всі URL для тестованого програми. Коли ви будете задоволені отриманою записом, натисніть кнопку Exit Recorder. Тепер можна перейти до уточнення тестового скрипта (просто натискаючи на кнопки) і відтворенню його будь-якими способами.


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



    IBM Rational Performance Tester дозволяє створити будь-яку кількість тестових проектів, записів і планів виконання тестових скриптів. У цьому розділі ми наводимо лише короткий опис, тому що докладні пояснення будуть дані в Частині 2 серії, в якій ми простежимо повний цикл тестування навантаження за допомогою IBM Rational Performance Tester.


    Пули даних


    IBM Rational Performance Tester може підтримувати динамічну завантаження тестових даних різних типів або безпосередньо з CSV-файлу, або через користувальницький код. Використання пулів даних – це спосіб імітації реальних сценаріїв шляхом підстановки даних користувача або дій в тих випадках, коли потрібно користувача введення. Для прикладу уявіть собі, що вам потрібно протестувати додаток ACME Online, яке являє собою корзину інтернет-магазину. Зареєструвавшись у системі, користувачі виконують пошук за певними ключовими словами, переглядають каталог, вибирають сподобалися товари, вводять дані, додають коментарі або оцінюють свої враження, перш ніж підтвердити покупку, вибравши спосіб оплати. Традиційно для введення тестових даних до мінливих значеннями потрібні висококваліфіковані фахівці, здатні писати користувальницький код. Використовуючи пули даних, можна змоделювати кожну сторінку, яка вимагає користувальницького введення, за допомогою настроюваних тестових даних. У сценарії ACME Online пул даних може бути створений для імені входу користувача, ключових слів пошуку та т. д. Ця функція дозволяє створити надійні і гнучкі контрольні приклади.


    На малюнку 11 показаний редактор пулів даних з прикладом імпортованого пулу даних.



    З імпортованим пулом даних можна виконати наступні дії:



    Типовий контрольний приклад порівнює кілька сторінок; в залежності від їх характеру, для кожної з них може знадобитися введення різної інформації. Цей користувальницький введення инкапсулируется в HTML-форму і передається за допомогою методів get або post. Ви можете створити пули даних Datapools для кожної сторінки і дати їм відповідні імена. Наприклад, для ефективного тестування Web-додаток повного циклу пули даних можуть складатися з таких пулів: UserLogin (ІмяВходаПользователя), SearchString (СтрокаПоіска), ItemName (НаіменованіеТовара), PaymentMethod (МетодПлатежа). Для створення пулу даних і асоціювання його з сторінкою потрібно всього лише кілька кроків:



    1. Натисніть правою кнопкою миші на папці Datapools (Непогана ідея помістити все пули даних в одну папку) або в будь-яку іншу папку в панелі Test Navigator (Див. рисунок 12).


  • Потім вкажіть ім’я папки, в якій буде розміщено новий пул даних У нашому прикладі це папка Yahoo Entertainment > Datapools. Дайте новому пулу ім’я, а потім натисніть кнопку Next (Див. рисунок 13).



    1. Для імені пулу даних можна використовувати будь-які стовпці і рядки. Вводити опис не обов’язково.



  • Перейдіть до потрібного файлу CSV (який ви повинні були створити заздалегідь). Щоб завершити створення пулу даних, натисніть кнопку Finish.


  • Асоціюємо сторінку з пулом даних



    1. Асоціювання сторінки з пулом даних не представляє ніяких труднощів. У секції тестових даних вкладки Performance test recording виділіть рядок, який потрібно замінити пулом даних, а потім натисніть кнопку Data Variable (Малюнок 16).

    Порада:
    URL, що містять рядки запиту, будуть визначені автоматично і показані темно-зеленим кольором.



  • Натисніть кнопку Add Datapool, Виділіть пул даних, який потрібно додати, і натисніть кнопку Select (Малюнок 17).

  •  

    Щоб завершити асоціювання пулу даних зі сторінкою, перейдіть до колонки і натисніть кнопку Use Column (Рисунок 18).
     

    Пули даних IBM Rational Performance Tester дозволяють виконати підстановку змінюваних даних для різних сторінок, що переглядаються, завдяки чому не виникає необхідності в більш складних альтернативних способах, таких, як користувальницький код. Ви можете створювати контрольні приклади виходячи з різних комбінацій переходів по сторінках і асоціювати кожну сторінку, яка вимагає користувальницького введення, з одним пулом даних або більше. Проте для дійсно масштабованих контрольних прикладів, які створюються за допомогою величезних наборів тестових даних, підстановка пулів даних може виявитися не кращим рішенням. У таких ситуаціях можна скористатися функцією користувацького коду. Наприклад, Java ™-розробник може підключити користувальницький код для подачі великого набору даних “на льоту” (більше детальну інформацію про це можна знайти на Web-сайті IBM developerWorks в статті під назвою Handling test data with IBM Rational Performance Tester 7.0: Part 2. Using files for very large sets of test data (Обробка тестових даних за допомогою IBM Rational Performance Tester 7.0. Частина 2: Використання файлів для дуже великих наборів тестових даних)).


    Можливість підстановки пулів даних на льоту в поєднанні з можливістю кореляції різних даних дозволяє найбільш реалістично змоделювати тестування багатокористувацької середовища. Кореляція (звана також динамічної параметризацією даних) – це спосіб гарантувати, що запит до поточної сторінці заснований на засланні (значенні) з попередньої сторінки. Часто запит до поточної сторінці заснований на даних відгуку від попередньої сторінки. Rational Performance Tester розпізнає і автоматично корелює ці посилання, щоб по-різному змоделювати дії кожного користувача. Таким чином, система відрізняє одного користувача від іншого по відмінностей у даних, запитуваних з усіх тестових сторінок.


    Існує два способи кореляції даних:




    Розподіл і призначення робочого навантаження


    Для імітації реальних сценаріїв в процесі навантажувального тестування програми Rational Performance Tester надає гнучкі можливості, які дозволяють зробити тестування настільки реалістичним, наскільки це можливо. Ви можете створити стільки тестових скриптів і планів тестування, скільки вам потрібно, і динамічно використовувати будь-яке поєднання навантажень віртуальних користувачів. Часто фахівці цікавляться, чи надає інструмент наступні можливості:



    Оскільки Rational Performance Tester допускає виконання цих опцій в будь-якій послідовності, ми спочатку розглянемо, як можна призначити різні дії разом з приєднаними до них елементами різним групам користувачів і як елементи можуть впливати на поведінку навантажувального тесту. На малюнку 20 показано, як можна легко розподілити робоче навантаження і призначення між різними групами користувачів, в кожну з яких входять різні віртуальні користувачі. Наприклад, для того, щоб додати нову групу, виконайте наступні дії:



    1. Натисніть правою кнопкою миші на групі в плані тестування (нижче Schedule Contents).
    2. Виберіть команди Add > user group.

    Після того, як група створена, можна розподілити робоче навантаження між усіма групами шляхом приєднання тестових скриптів (записів) до цих груп.


    Примітка
    відношення між групою користувачів і тестовими скриптами дорівнює 1: N. Іншими словами, одна група користувачів може виконувати більше одного тестового скрипта. Що стосується розподілу робочого навантаження, то все, що вам потрібно зробити – це поставити абсолютна або відносна (у відсотках) кількість користувачів.



    Однак при імітації реального сценарію тестування, одне лише розподіл робочого навантаження між різними групами не обов’язково відповідає гарному сценарієм тестування. Щоб зробити сценарій більш реалістичним, Rational Performance Tester надає різні елементи, які можна асоціювати з планом тестування. Питання про включення або не включення цих елементів в план залежить від сценарію, який тестується. Елементи асоціюються безпосередньо з планом тестування. На малюнку 21 зображені деякі елементи, які можна включити в план.



    В план тестування можна включити такі елементи:



    Про це докладно розповідається в частині 2 цієї статті.


    Моніторинг системи в реальному часі


    Метою тестування продуктивності є виявлення вузьких місць шляхом збору аналітичних даних для всіх використовуваних компонентів. В рамках цього тестування проводиться моніторинг продуктивності рівня додатків, наприклад, інструментарію рівня сервера додатків для IBM WebSphere Application Servers (Версії 5 або більш пізніх версій) і BEA WebLogic версії 8 або збір даних за допомогою API для кількісної оцінки відгуків додатків (Application Response Measurement, ARM), яке призначене для серверів додатків, не підтримуваних власними засобами, наприклад, JBoss, Apache Tomcat і т. д. Крім того, при моніторингу рівня баз даних можна також використовувати ARM. У цьому сенсі можуть збиратися, а потім відображатися у вигляді UML-діаграми послідовності всі операції бази даних. Включення моніторингу реальних додатків – це всього лише один аспект моніторингу тесту продуктивності. Описані рівні збору даних (рівень програми та рівень бази даних) будуть неповними без можливості збору даних моніторингу на рівні ресурсів на стороні сервера, на якому виконуються компоненти програми.


    IBM Rational Performance Tester за замовчуванням підтримує більше трьох методів моніторингу на рівні реальних ресурсів, у тому числі:



    Приклад. Щоб налаштувати моніторинг за допомогою Windows Performance Monitor, Вам доведеться включити моніторинг ресурсів. Для збору аналітичних даних Windows Performance Monitor виконайте наступні дії:



    1. Виберіть план тестування.
    2. В панелі Schedule Element Details перейдіть на вкладку Resource Monitoring.
    3. Встановіть прапорець Enable resource monitoring (Див. рисунок 22).
    4. Щоб задати нові параметри, спочатку натисніть кнопку New і додайте новий ресурс. Можна також додати моніторинг вже існуючого сервера або вибрати і відредагувати один з тих, що були визначені раніше.

     


    1. Натиснувши кнопку Add New, Ви зможете ввести своє ім’я користувача в полі username і пароль в поле password на вкладці Location.
    2. На вкладці Resource можна вибрати потрібні статистичні показники, А на вкладці Options – Інтервали Полінгом і тайм-аутів.


    Примітка
    Щоб вести моніторинг через інструмент IBM Tivoli Monitoring і демон UNIX (або Linux) rstatd, перед підключенням до них необхідно переконатися в їх готовності. Окремо від моніторингу системи в режимі реального часу можна також імпортувати до звіту про продуктивність архівні аналітичні дані з IBM Tivoli Monitoring. Для прикладу виберіть з меню команди File > Import, А потім Profile і Logging > Resource Monitoring Data. У наступному вікні ви зможете вказати сервер під моніторингом Tivoli. На даний момент можна імпортувати тільки архівні дані інструменту IBM Tivoli Monitoring (див. малюнок 24.)



    Аналіз звітів реального часу


    Одним з кращих переваг Rational Performance Tester є оперативний (і автономний) аналіз звітів, які можуть бути згенеровані для аналізу продуктивності в цілому, і можливості інструменту більш глибоко дослідити основну причину конкретних проблем. Для загальних цілей більш ніж достатньо звітів за замовчуванням. Якщо потрібні більш деталізовані звіти, то можна налаштувати функцію analysis report на генерування більш представницьких, розширений звітів, які дозволять глибше вникнути в проблеми продуктивності. В IBM Rational Performance Tester доступно п’ять категорій HTTP-звітів:



    Примітка
    У частині 3 цієї серії статей ми докладно розповімо про різні види звітів про продуктивність.


    Звіт Performance Report складається з високорівневих звітів, таких, як підсумковий відсоток успішних виконань, зведення, в якій наводиться інформація про всі виконаних віртуальних користувачів, загальне витрачений час, середнє час відгуку для всіх сторінок і т. д. Оперативний звіт Performance Report показаний в різних форматах (9 вкладок) для полегшення навігації. На малюнку 25 показаний формат Response vs. Time (Кількість відгуків стосовно часу виконання) в підсумковому вигляді.



    Звіт Page Element Report складається з п’яти вкладок і містить свій набір аналітичних звітів за замовчуванням, наприклад, звіти Response vs. Time Details (Деталізація відгуків по відношенню до часу виконання) і Page Element Throughput (Пропускна здатність елементів сторінки). На малюнку 26 показаний типовий звіт Page Element Throughput.



    Звіт Percentile Report, 4-а вкладка, показує розподіл процентилей по відношенню до часу відгуку. За умовчанням цей звіт включає зведену інформацію і деталізацію по 85-му, 90-му і 95-му процентиль. Цей тип звіту зазвичай використовується для виявлення аномального поведінки, наприклад, сплеску активності на сторінці. Асоціюючи процентиль зі сторінкою, можна збирати дані на рівні кожної сторінки, щоб визначити поведінка сторінки в кожен з цих ключових процентилей. Такі звіти – єдиний спосіб, що дозволяє стверджувати, наприклад, що 85% сторінок завершуються за X мс, 90% за Y мс і т. д. Ви можете створити асоціацію між процентиль і часом відгуку сторінці, щоб переконатися в тому, що з 85% сторінок відповідь була отримана за певний час. Згодом, візуально порівнюючи звіти, що містять послідовні вкладки Percentile Reports, ви зможете легко визначити, де виникають аномалії.


    На малюнку 27 показаний 85-й процентиль, а більш прості сторінки нерідко мають точний 90-й і 95-й процентиль, і це означає, що все йде цілком прийнятно. Як показано в прикладі, 85% користувачів завершили завантаження сторінки Web-порталу Yahoo! Entertainment за 16,954 мс.


     

    Звіт Verification Report, 3-я вкладка звіту, виводить статус Pass або Fail для сторінок із заданою верифікацією .. Верифікація задається в тестовому скрипті в папці Test Content. Це спосіб перевірити, пройшла сторінка тест або не пройшла. Тестовими показниками можуть бути назва HTML-сторінки, код повернення HTML, і розмір відгуку HTML (для завдання точок верифікації потрібно вибрати з меню команди Windows > references > Performance Test Generation > Verification Points). Точки верифікації можна активувати для кожної сторінки, як показано на малюнку 28.



    У звіті Page Verification Points наводиться список окремих сторінок з відповідним значенням pass або fail, і додатково коефіцієнт проходження тесту сторінками в процентах. Приклад звіту Page Verification Points показує коефіцієнт проходження тесту виконаними сторінками. В даному прикладі на малюнку 29 немає сторінок, які не пройшли тест, тому коефіцієнт проходження склав 100%.



    Крім цих чотирьох звітів ви можете заглибитися до рівня сторінки, щоб краще розібратися з часом відгуку за даними цього рівня.



    1. Щоб перейти на сторінку, виберіть сторінку (вертикальна панель) на вкладці Page Performance звіту за замовчуванням і натисніть на ній правою кнопкою, щоб вибрати команду Display Page Element Responses. У прикладі на малюнку 30 показана сторінка My MTV Movie Awards “07, а для поглибленого вивчення обраний елемент сторінки Breaking News on Yahoo!


     

    Крім того, Rational Performance Tester дозволяє виконати аналіз основних причин. Це здійснюється двома способами: аналіз використання ресурсів (Згадуваний раніше) і аналіз статистичних показників виконання коду. Тут ви можете отримати звіт, що містить схему відгуків, зі звіту про продуктивність. Це дозволить проаналізувати статистику по елементах сторінки, отриману в процесі виконання запланованого тесту, або будь-які імпортовані з зовнішніх інструментів архівні дані. Аналіз часу відгуку показує такі деталі, як тривалість кожного елемента для тестованої системи. Кожен елемент сторінки асоціюється із записом в деталізованої статистиці. Щоб отримати аналіз часу відгуку, необхідно спочатку активувати опцію Response Time Breakdown:



    1. Виберіть план, що містить тестовий скрипт, а потім виберіть команди Schedule Element Details > Response Time Breakdown.
    2. В Quick Links, Встановіть прапорець Enable collection of response time data (Активувати збір даних про час відгуку).
    3. І, нарешті, встановіть прапорець для відповідного запису.



    1. Переконайтеся, що інфраструктура DCI запущена і готова до моніторингу.
    2. Щоб почати моніторинг, в меню Start (Пуск), виберіть All Programs> IBM Software Development Platform> IBM Rational Data Collection Infrastructure> Start Monitoring.

    Звіт Response Time Breakdown надає статистику, що має відношення до виконання коду, яка включає базові компоненти, такі, як JDBC, протокол RMI / IIOP (Remote Method Invocation over Internet InterORB Protocol), Web-сервіси, bean-компоненти і т. д. На малюнку 33 показаний приклад звіту Response Time Breakdown. (Можна також переглянути додаткові деталі в статистиці аналізу часу відгуку (Response Time Breakdown Statistics), хоча ця опція тут не показана.)



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



    Примітка:
    кожен сервер програм необхідно сконфігурувати і забезпечити інструментарієм для роботи з інфраструктурою збору даних.


    Єдина мета запуску монітора інфраструктури збору даних Data Collection Infrastructure (DCI) – збір аналітичних даних. Як уже говорилося раніше, щоб забезпечити збір даних, інфраструктуру DCI необхідно активувати (встановити і запустити) для кожного сервера, на якому виконується програма і потрібно виконати збір даних. Якщо це не буде виконано, то ми отримаємо повідомлення про помилку, показане на малюнку 34.



    Управління версіями


    Rational Performance Tester поставляється в складі пакета програм IBM Rational ClearCase LT для управління вихідними версіями, щоб стимулювати спільну роботу в середовищі розробки. ClearCase LT використовує односерверную модель з невеликою кількістю адміністративних вимог. Хоча цей інструмент насправді адаптований для невеликих середовищ, що складаються з 25-30 розробників і тестувальників, для більш великих середовищ ви можете скористатися ClearCase або IBM Rational ClearCase MultiSite; для обох програм IBM надає шляхи міграції.


    Управління версіями може здійснюватися над такими активами, як проекти, плани, тести, користувальницький код, пули даних, папки і результати. Разом з інструментом для управління вихідним кодом IBM Rational ClearCase LT надає наступні функції:





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


    Гілки (branch) можуть бути абсолютно різними, наприклад, для кожного паралельного проекту на основі функціональних вимог. У роботі з різними гілками застосовуються ті ж принципи. Ви зможете вивчити роботу інших фахівців тільки після того, як синхронізуєте активи на своєму робочому місці з центральним репозиторієм. Для підтримки синхронізації в IBM Rational Performance Tester передбачена перспектива Team Synchronizing з простою навігацією та управлінням. До синхронізації мають відношення чотири моделі:



    Користувальницький код і поглиблене тестування


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


    Функція custom code представлена ​​кнопкою із зеленою літерою C. Користувальницький код можна вставити в будь-якому місці тестового скрипта. На малюнку 36 показані два доданих фрагмента користувацького коду. При першій вставці користувацького коду ім’я класу генерується автоматично. Але ви можете присвоїти класу більш зрозуміле ім’я, якщо хочете.



    Після вставки користувацького коду можна відразу ж перейти до логіки коду, переключившись на представлення вихідного коду Java (натиснувши кнопку View Code). Можна також переключитися на перспективу Java Browsing. Крім того, вбудована інтегрована середа розробки Java (IDE) дозволяє виконати налагодження коду.



    Для виконання поглибленого тестування надається два інтерфейсу, CustomCode2 і ITestExecutionServices (Мається повне керівництво в форматі Javadoc). Нижче наводиться ряд сценаріїв, які зазвичай вимагають виконання поглиблених тестів:



    Масштабування і обслуговування


    Іноді доводиться виконувати дистанційне динамічне тестування користувацьких навантажень для ітерацій тесту, розподілених за територіально розосередженим підрозділам. Традиційні методи тестування, при яких кожен тест обмежується одним місцем виконання, можуть виявитися нездійсненними в територіально розосередженому колективі розробників. У доповненні до можливості спільного використання активів незважаючи на кордони підрозділів, Rational Performance Tester дозволяє виконати навантажувальний тест відразу в декількох підрозділах через регіональну мережу (WAN). Оскільки сервери можуть бути розкидані по всій території, можливість віддаленого виконання в поєднанні з низькими вимогами до апаратного забезпечення, необхідного для виконання тесту, дозволяє вам використовувати віддалені сервери під управлінням операційних систем IBM AIX, Linux, Microsoft Windows і z / OS.


    Наприклад, у вас може бути 5 серверів низької продуктивності, моделюючих 5000 користувачів з Сінгапуру, 3 сервера, що моделюють 3000 користувачів з Гонконгу і т. д. Такий метод тестування не тільки генерує більш реалістичні результати тестів, але і знижує загальні витрати на тестування, тому що результати тестів можна аналізувати і спільно використовувати в декількох робочих групах, а простойний серверів можна знайти хороше застосування.


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


    Після того, як ви записали тестовий скрипт, для збільшення кількості віртуальних користувачів потрібно тільки додати групи користувачів. Rational Performance Tester без проблем справляється з масштабністю, дозволяючи вам додавати додаткові групи користувачів і включати в них або певне число, або певний відсоток користувачів. У нового запису тестового скрипта не виникає необхідності, поки не буде змінений сам контрольний приклад.


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



    Що далі


    У першій частині цієї серії з чотирьох статей ми розглянули різні функції, надані інструментом IBM Rational Performance Tester, в тому числі, просте в застосуванні адміністрування через графічний інтерфейс користувача, функції генерації звітів і масштабованість. Хоча це всього лише загальний опис, і функції та особливості розглянуті з висоти пташиного польоту, ви можете використовувати знання, отримані з цього короткого вступу в тему, для розширення свого уявлення про інструменти навантажувального тестування, які є серед програмних продуктів платформи IBM Software Delivery.


    У Частині 2 і 3 ми ретельно вивчимо повний цикл навантажувального тестування, а в частині 4 ви отримаєте детальне уявлення про безліч звітів, включених в Rational Performance Tester та їх варіаціях, а також навчитеся змінювати їх відповідно зі своїми специфічними потребами.

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *