2.3 Завдання на лабораторну роботу

2.3.1 Ознайомитися з теоретичними відомостями (пункт 2.2) та довідковою інформацією, наданою IBM Rational Functional Tester.

2.3.2 Змінити згідно з пунктом 2.2 тестовий скрипт з додатком «ClassicsJavaA».

2.3.3 Перевірити власний сайт за допомогою вивчених функцій:

− створити умову на властивість .text у діалоговому вікні. Додати натискання кнопки «ОК», якщо текст задовольняє вказаній умові, або кнопки «Cancel» у іншому випадку;

− створити масив кнопок проекту та обрати необхідний.

2.3.4 Запустити створений скрипт.

2.3.5 Виконати аналіз отриманих результатів.

2.4 Зміст звіту

2.4.1 Тема та мета роботи.

2.4.2 Тексти створених скриптів тестування з коментарями.

2.4.3 Обґрунтовано обрані HTML-лінки.

2.4.4 Результати роботи скриптів тестування (історія роботи).

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

2.4.6 Висновки, що містять відповіді на контрольні запитання, а також відображують результати виконання роботи та їх критичний аналіз.

2.5 Контрольні запитання

2.5.1 На якій мові програмування створюються скрипти тестування IBM Rational Functional Tester? Як отримати зображення екрану тестує мого обьекту?

2.5.2 Які можливості надає використання методу getProperty?

2.5.3 Як організувати пошук необхідних елементів?

2.5.4 Як обрати необхідний додаток?

2.5.5  Як організувати очікування при тестуванні?

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

Лабораторна робота №3 Навантажувальне тестування Web-додатків з використанням ibm Rational Performance Tester

3.1 Мета роботи

Навчитися створювати, виконувати та аналізувати тести продуктивності web-додатків.

3.2 Основні теоретичні відомості

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 напоминает запись видеоклипов при помощи видеокамеры. Он позволяет записать стадии выполнения нагрузочного теста, а затем воспроизвести эти стадии с соответствующими пользовательскими нагрузками.

Обычно при нагрузочном тестировании Web-приложения необходимо идентифицировать различные сценарии при помощи хорошо продуманных планов тестирования. Часто в процессе выполнения нагрузочного теста желательно, чтобы некий пользователь распределял нагрузку между несколькими тестовыми клиентами. Равномерно распределяя пользовательскую нагрузку между несколькими машинами, он будет содействовать формированию более показательных отчетов. Это хороший способ предотвратить недостаточную загрузку одних машин при избыточной нагрузке других.

IBM Rational Performance Tester предоставляет полнофункциональные средства, позволяющие сделать нагрузочное тестирование не только эффективным, но и простым. Отсуствует необходимость написания кода тестовых скриптов, потому что для задач администрирования предусмотрен интерактивный графический пользовательский интерфейс (GUI) на базе инфраструктуры Eclipse 3.2. Другими словами, можно управлять всем жизненным циклом тестирования при помощи GUI, имея возможность использовать и собственный код для более углубленного тестирования. Подход с использованием GUI охватывает следующие основные категории:

− интерактивные графические тесты;

− создание, уточнение, воспроизведение тестов и создание планов тестов;

− работа с пулами данных и корреляциями;

− распределение и назначение рабочей нагрузки;

− мониторинг системы в реальном времени;

− анализ отчетов реального времени;

− управление версиями;

− пользовательский код и углубленное тестирование;

− масштабирование и обслуживание.

Интерактивные графические тесты. Во-первых, IBM Rational Performance Tester создан на базе расширяемой платформы разработки, использующей инфраструктуру Eclipse версии 3.2. Многочисленные преимущества инфраструктуры Eclipse для разработки хорошо известны, но для специалистов-практиков IBM Rational Performance Tester, кроме того, предоставляет комплексные, контекстно-зависимые перспективы (элементы графического интерфейса пользователя) для создания, управления и планирования выполнения тестовых скриптов. Для любых задач − от создания тестов и распределения пользовательской нагрузки до сбора данных − в графическом интерфейсе программы имеются соответствующие представления. На рис.3.1 показана перспектива для тестирования с настройками по умолчанию.

Рисунок 3.1 − GUI для тестирования на базе Eclipse

Можно работать с различными представлениями в зависимости от используемой перспективы. Например, по умолчанию перспектива тестирования предоставляет консоль с четырьмя панелями, которым соответствуют следующие представления: 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, перечислены в раскрывающемся списке в виде подменю, чтобы их было легче найти (рис.3.2). В перспективе по умолчанию предусмотрен предварительно заданный набор представлений. Можно настроить любую перспективу в соответствии с собственными предпочтениями, добавив или исключив отдельные представления.

Рисунок 3.2 − Диалоговое окно Show View

2. Чтобы найти нужное представление, воспользуйтесь функцией Type-Forward Filtering (рис.3.3); часто вам даже не придется вводить строку поиска полностью. В данном случае для представления Database Explorer оказалось достаточным ввести слово data.

Рисунок 3.3 − Опережающая фильтрация результатов поиска

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

Рисунок 3.4 − Представление Database Explorer

Поиск представлений можно осуществлять при помощи меню. В строке меню выберите команды Windows  Navigate  Next View. Между представлениями, которые в данный момент открыты в рабочей области, можно переходить при помощи клавиш со стрелками (стрелка вверх или вниз). Так же можно переключаться между перспективами. Есть и альтернативный способ навигации − горячие клавиши CTRL-F7 (Следующая) или CTRL-SHIFT-F7 (Предыдущая). Горячие клавиши можно настроить через команды меню Windows  Preferences  Keys (слово для поиска). Настройки на вкладке General  Keys применяются ко всем перспективам (рис.3.5).

Рисунок 3.5 − Переключение между представлениями

Перспективы можно настроить соответственно своим предпочтениям и сохранить (рис.3.6). Настраиваемые категории: доступные группы команд, команды меню и кнопки панели инструментов.

Рисунок 3.6 − Настройка перспектив

Кроме того, в программе имеется обозреватель Web-сервисов Web Services Explorer.

Рисунок 3.7 − Обозреватель Web-сервисов Web Services Explorer

Сбор данных тестирования в реальном времени, уточнение, воспроизведение и планирование тестирования. Сбор данных, уточнение, воспроизведение и планирование выполнения теста не представляет никаких сложностей, потому что Rational Performance Tester специально приспособлен для того, чтобы с ним могли работать даже начинающие пользователи. Все механизмы, обеспечивающие работу программы, например, механизм записи и воспроизведения скриптов, выполняются скрыто от среднего пользователя. Это сделано для того, чтобы упростить создание и обслуживание тестов. Чтобы записать тест, выполните следующие шаги:

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

Рисунок 3.8 − Создание тестового проекта

2. Выберите запись. Для Web-приложения выберите HTTP recording(рис.3.9). Нажмите кнопку Next.

3. На следующей странице выберите тестовый проект для тестового скрипта (по имени, которое вы ему дали).

Рисунок 3.9 − Выбор протокола

Если вы видите окно, показанное на рис.3.10, то можете собрать все URL для тестируемого приложения. Когда вы будете удовлетворены полученной записью, нажмите кнопку Exit Recorder. Теперь можно перейти к уточнению тестового скрипта (просто нажимая на кнопки) и воспроизведению его любыми способами.

Рисунок 3.10 − Запись

После того, как тестовый скрипт будет записан, обычно остается уточнить план тестирования. Например, можно изменить скрипт любым из следующих способов:

− добавить время паузы (в миллисекундах, или мс) между виртуальными пользователями, "время на размышление" пользователя и параметры сбора статистических данных;

− определить свои пулы данных;

− выполнить корреляцию данных (чтобы обеспечить бесперебойную передачу представительных данных от страницы к странице);

− добавить точки верификации (чтобы проверить коэффициент прохождения теста для каждой тестируемой страницы);

− добавить элементы, специфичные для протокола, транзакции, циклы, комментарии, условную обработку и пользовательский код.

Rational Performance Tester позволяет создать любое количество тестовых проектов, записей и планов выполнения тестовых скриптов.

Пулы данных. IBM Rational Performance Tester может поддерживать динамическую загрузку тестовых данных разных типов либо напрямую из CSV-файла, либо через пользовательский код. Использование пулов данных − это способ имитации реальных сценариев путем подстановки пользовательских данных или действий в тех случаях, когда требуется пользовательский ввод. Для примера представьте себе, что необходимо протестировать приложение ACME Online, которое представляет собой корзину интернет-магазина. Зарегистрировавшись в системе, пользователи выполняют поиск по определенным ключевым словам, просматривают каталог, выбирают приглянувшиеся товары, вводят данные, добавляют комментарии или оценивают свои впечатления, прежде чем подтвердить покупку, выбрав способ оплаты. Традиционно для ввода тестовых данных с изменяющимися значениями требуются высококвалифицированные специалисты, способные писать пользовательский код. Используя пулы данных, можно смоделировать каждую страницу, требующую пользовательского ввода, при помощи настраиваемых тестовых данных. В сценарии ACME Online пул данных может быть создан для имени входа пользователя, ключевых слов поиска и т. д. Эта функция позволяет создать надежные и гибкие контрольные примеры.

На рис.3.11 показан редактор пулов данных с примером импортированного пула данных.

Рисунок 3.11 − Пулы данных

С импортированным пулом данных можно выполнить следующие действия: добавить запись; удалить запись; добавить переменную; изменить переменную; удалить переменную.

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

1. Нажмите правой кнопкой мыши на папке Datapools (неплохая идея поместить все пулы данных в одну папку) или в любую другую папку в панели Test Navigator (рис.3.12).

Рисунок 3.12 − Добавление пула данных (шаг 1)

2. Затем укажите имя папки, в которой будет размещен новый пул данных. В нашем примере это папка Yahoo Entertainment  Datapools. Дайте новому пулу имя, а затем нажмите кнопку Next (рис.3.13).

Рисунок 3.13 − Добавление пула данных (шаг 2)

3. Для имени пула данных можно использовать любые столбцы и строки. Вводить описание не обязательно (рис.3.14).

Рисунок 3.14 − Добавление пула данных (шаг 3)

4. Перейдите к нужному файлу CSV (который необходимо было создать заранее). Чтобы завершить создание пула данных, нажмите кнопку Finish(рис.3.15).

Рисунок 3.15 − Добавление пула данных (шаг 4)

Ассоциируем страницу с пулом данных. Ассоциирование страницы с пулом данных не представляет никаких сложностей. Для этого необходимо выполнить следующие действия:

1. В секции тестовых данных вкладки Performance test recording выделите строку, которую нужно заменить пулом данных, а затем нажмите кнопку Data Variable (рис.3.16).

Рисунок 3.16 − Ассоциирование пула данных со страницей(шаг 1)

2. Нажмите кнопку Add Datapool, выделите пул данных, который нужно добавить, и нажмите кнопку Select (рис.3.17).

Рисунок 3.17 − Ассоциирование пула данных со страницей (шаг 2)

3. Чтобы завершить ассоциирование пула данных со страницей, перейдите к столбцу и нажмите кнопку Use Column (рис.3.18).

 

Рисунок 3.18 − Ассоциирование пула данных со страницей (шаг 3)

Пулы данных IBM Rational Performance Tester позволяют выполнить подстановку изменяемых данных для различных просматриваемых страниц, благодаря чему не возникает необходимости в более сложных альтернативных способах, таких, как пользовательский код. Можно создавать контрольные примеры исходя из различных комбинаций переходов по страницам и ассоциировать каждую страницу, требующую пользовательского ввода, с одним пулом данных или более. Однако для действительно масштабируемых контрольных примеров, которые создаются при помощи огромных наборов тестовых данных, подстановка пулов данных может оказаться не лучшим решением. В таких ситуациях можно воспользоваться функцией пользовательского кода. Например, Java™-разработчик может подключить пользовательский код для подачи большого набора данных "на лету". Возможность подстановки пулов данных на лету в сочетании с возможностью корреляции различных данных позволяет наиболее реалистично смоделировать тестирование многопользовательской среды. Корреляция (называемая также динамической параметризацией данных) − это способ гарантировать, что запрос к текущей странице основан на ссылке (значении) с предыдущей страницы. Часто запрос к текущей странице основан на данных отклика от предыдущей страницы. Rational Performance Tester распознает и автоматически коррелирует эти ссылки, чтобы по-разному смоделировать действия каждого пользователя. Таким образом, система отличает одного пользователя от другого по различиям в данных, запрашиваемых со всех тестовых страниц.

Существует два способа корреляции данных:

− автоматический (автоматизированная корреляция данных), при которой генератор тестов автоматически определяет, какое предыдущее значение необходимо заменить в текущем запросе. Как уже говорилось ранее, ссылки (значения из предыдущих ответов) будут использоваться для корреляции значений в следующих запросах. Можно также усовершенствовать корреляцию при помощи пользовательского кода;

− вручную; выполняется путем удаления имеющейся корреляции и привязки значений из предыдущего ответа к текущему запросу. Хотя автоматизированная корреляция данных выбрана по умолчанию, ее можно отключить. Однако после ее отключения вам придется самому решать, насколько будут связаны между собой поток данных и тестовые страницы. Отключить автоматизированную корреляцию данных несложно (рис.3.19):

1. Из меню выберите команды Windows  Preferences  Performance Test Generation.

2. Перейдите на вкладку Data Correlation.

Рисунок 3.19 − Отключение корреляции данных

Распределение и назначение рабочей нагрузки. Для имитации реальных сценариев в процессе нагрузочного тестирования приложения Rational Performance Tester предоставляет гибкие возможности, которые позволяют сделать тестирование настолько реалистичным, насколько это возможно. Можно создать столько тестовых скриптов и планов тестирования, сколько необходимо, и динамически использовать любое сочетание нагрузок виртуальных пользователей. Часто специалисты интересуются, предоставляет ли инструмент следующие возможности:

− можно ли задать 1000 виртуальных тестировщиков, которые будут работать на трех удаленных машинах с равномерно распределенной пользовательской нагрузкой?

− можно ли сделать так, чтобы 10% общего количества виртуальных тестировщиков были запущены сначала, а затем стартовали бы еще 10% от оставшегося числа?

− можно ли, чтобы одна группа виртуальных тестировщиков запускала в тестируемом приложении определенные фрагменты страниц?

− можно ли определить для пользователя время на размышление?

− можно ли рандомизировать выполнение последовательности тестов?

− можно ли запускать нагрузочный тест удаленно, причем так, чтобы у всех виртуальных пользователей были разные IP-адреса?

− можно ли запускать тесты с заданной скоростью?

Поскольку Rational Performance Tester допускает выполнение этих опций в любой последовательности, сначала рассмотрим, как можно назначить различные действия вместе с присоединенными к ним элементами различным группам пользователей и как элементы могут влиять на поведение нагрузочного теста. На рис.3.20 показано, как можно легко распределить рабочую нагрузку и назначения между различными группами пользователей, в каждую из которых входят разные виртуальные пользователи. Например, для того, чтобы добавить новую группу, выполните следующие действия:

1. Нажмите правой кнопкой мыши на группе в плане тестирования (ниже Schedule Contents).

2. Выберите команды Add  user group.

После того, как группа создана, можно распределить рабочую нагрузку между всеми группами путем присоединения тестовых скриптов (записей) к этим группам. Отношение между группой пользователей и тестовыми скриптами равно 1:N. Другими словами, одна группа пользователей может выполнять более одного тестового скрипта. Что касается распределения рабочей нагрузки, то все, что вам нужно сделать − это задать абсолютное или относительное (в процентах) количество пользователей.

Рисунок 3.20 − Распределение рабочей нагрузки

Однако при имитации реального сценария тестирования, одно лишь распределение рабочей нагрузки между различными группами не обязательно соответствует хорошему сценарию тестирования. Чтобы сделать сценарий более реалистичным, Rational Performance Tester предоставляет различные элементы, которые можно ассоциировать с планом тестирования. Вопрос о включении или не включении этих элементов в план зависит от сценария, который тестируется. Элементы ассоциируются непосредственно с планом тестирования. На рис.3.21 изображены некоторые элементы, которые можно включить в план.

Рисунок 3.21 − План с включенными элементами

В план тестирования можно включить следующие элементы:

− тестовый скрипт (запись). Записав тестовый скрипт, можно ассоциировать его с планом. С одним планом можно ассоциировать более одного тестового скрипта (косвенно, через различные группы пользователей, поскольку каждой группе пользователей может быть назначено больше одного тестового скрипта);

− назначение для групп и процентное распределение пользователей. Речь идет о распределении рабочей нагрузки в группе пользователей. Здесь можно задать количество пользователей, которые начнут выполнение тестового сценария. Например: 50 пользователей начнут выполнение в момент времени T1;

− время на размышление пользователя. Для имитации времени, обычно затрачиваемого пользователем на размышление, существуют четыре варианта настроек: записанное время на размышление; фиксированное время на размышление (по умолчанию 2 секунды); динамическое увеличение или уменьшение времени на размышление в процентах; рандомизация времени на размышление в процентах;

− время задержки. Можно добавить задержку (в мс) между запусками тестовых скриптов разными пользователями. Вряд ли в реальном сценарии возможна ситуация по-настоящему высокого уровня синхронности (например, 20 пользователей выполняют сценарий точно в момент времени T1 без малейшей задержки). Обычно задержка в 50-100 мс считается нормальной. Если устанавливается задержка в 100 мс, то это означает, что первый пользователь (виртуальный пользователь) начинает выполнение в 12:00:00:00, а следующий - в 12:00:00:01;

− цикл. Этот элемент предназначен для выполнения теста заданной скоростью. В панели Schedule Element Details можно задать количество итераций и контроль их скорости (например, 2 итерации в секунду). Можно также рандомизировать задержки между итерациями;

− переключатель рандомизации. В реальной жизни обращение к страницам приложения происходит случайным образом. Этот элемент предназначен для рандомизации порядка выполнения тестов; последовательность выполнения изменяется путем добавления переключателя рандомизации. При настройке переключателя рандомизации необходимо ввести весовой коэффициент. Весовые коэффициенты последовательно ассоциируются с тестовым скриптом;

− псевдонимы IP-адресов при помощи этого элемента можно смоделировать ситуацию, в которой каждый виртуальный пользователь имеет один выделенный IP-адрес.

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

Включение мониторинга реальных приложений − это всего лишь один аспект мониторинга теста производительности. Описанные уровни сбора данных (уровень приложения и уровень базы данных) будут неполными без возможности сбора данных мониторинга на уровне ресурсов на стороне сервера, на котором выполняются компоненты приложения.

IBM Rational Performance Tester по умолчанию поддерживает более трех методов мониторинга на уровне реальных ресурсов, в том числе: IBM Tivoli Monitoring, Демон rstatd UNIX или Linux, Microsoft Windows Performance Monitor (perfmon, системный монитор Windows)

Для того чтобы настроить мониторинг при помощи Windows Performance Monitor, необходимо включить мониторинг ресурсов. Для сбора аналитических данных Windows Performance Monitor выполните следующие действия:

1. Выберите план тестирования.

2. В панели Schedule Element Details перейдите на вкладку Resource Monitoring.

3. Установите флажок Enable resource monitoring (рис.3.22).

4. Чтобы задать новые параметры, сначала нажмите кнопку New и добавьте новый ресурс. Можно также добавить мониторинг уже существующего сервера или выбрать и отредактировать один из тех, что были определены ранее.

5. Нажав кнопку Add New, можно ввести свое имя пользователя в поле username и пароль в поле password на вкладке Location.

6. На вкладке Resource можно выбрать нужные статистические показатели, а на вкладке Options − интервалы полингов и тайм-аутов (рис.3.23).

Рисунок 3.22 − Активация мониторинга ресурсов (шаг 1)

Рисунок 3.23 − Активация мониторинга ресурсов (шаг 2)

Чтобы вести мониторинг через инструмент IBM Tivoli Monitoring и демон UNIX (или Linux) rstatd, перед подключением к ним необходимо убедиться в их готовности. Отдельно от мониторинга системы в режиме реального времени можно также импортировать в отчет о производительности архивные аналитические данные из IBM Tivoli Monitoring. Для примера выберите из меню команды File  Import, а затем Profile и Logging  Resource Monitoring Data. В следующем окне вы сможете указать сервер под мониторингом Tivoli. На данный момент можно импортировать только архивные данные инструмента IBM Tivoli Monitoring (рис.3.24.)

Рисунок 3.24 − Импортирование архивных данных из Tivoli

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

− Performance Report (Отчет о производительности);

− Page Element Report (Отчет по элементам страниц);

− Percentile Report (Отчет по процентилям);

− Verification Report (Верификационный отчет);

− Response Time Breakdown.

Отчет Performance Report состоит из высокоуровневых отчетов, таких, как итоговый процент успешных выполнений, сводки, в которой приводится информация обо всех выполненных виртуальных пользователях, общее затраченное время, среднее время отклика для всех страниц и т. д.

Отчет Page Element Report состоит из пяти вкладок и содержит свой набор аналитических отчетов по умолчанию, например, отчеты Response vs. Time Details (Детализация откликов по отношению к времени выполнения) и Page Element Throughput (Пропускная способность элементов страницы).

Отчет Percentile Report показывает распределение процентилей по отношению к времени отклика. По умолчанию этот отчет включает сводную информацию и детализацию по 85-му, 90-му и 95-му процентилям. Этот тип отчета обычно используется для выявления аномального поведения, например, всплеска активности на странице. Ассоциируя процентиль со страницей, можно собирать данные на уровне каждой страницы, чтобы определить поведение страницы в каждый из этих ключевых процентилей. Такие отчеты − единственный способ, позволяющий утверждать, например, что 85% страниц завершаются за X мс, 90% за Y мс и т. д. Можно создавать ассоциацию между процентилями и временем отклика страницы, чтобы убедиться в том, что с 85% страниц ответ был получен за определенное время. Впоследствии, визуально сравнивая отчеты, содержащие последовательные вкладки Percentile Reports, можно легко определить, где возникают аномалии.

Отчет Verification Report выводит статус Pass или Fail для страниц с заданной верификацией.. Верификация задается в тестовом скрипте в папке Test Content. Это способ проверить, прошла страница тест или не прошла. Тестовыми показателями могут быть название HTML -страницы, код возврата HTML, и размер отклика HTML (для задания точек верификации нужно выбрать из меню команды Windows  References  Performance Test Generation  Verification Points).

В отчете Page Verification Points приводится список отдельных страниц с соответствующим значением pass или fail, и дополнительно коэффициент прохождения теста страницами в процентах.

Помимо этих четырех отчетов можно углубиться до уровня страницы, чтобы лучше разобраться с временем отклика по данным этого уровня. Чтобы перейти на страницу, выберите страницу (вертикальная панель) на вкладке Page Performance отчета по умолчанию и нажмите на ней правой кнопкой, чтобы выбрать команду Display Page Element Responses.

Кроме того, Rational Performance Tester позволяет выполнить анализ основных причин. Это осуществляется двумя способами: анализ использования ресурсов (упоминавшийся ранее) и анализ статистических показателей выполнения кода. Здесь можно получить отчет, содержащий схему откликов, из отчета о производительности. Это позволит проанализировать статистику по элементам страницы, полученную в процессе выполнения запланированного теста, или любые импортированные из внешних инструментов архивные данные. Анализ времени отклика показывает такие детали, как длительность каждого элемента для тестируемой системы. Каждый элемент страницы ассоциируется с записью в детализированной статистике. Чтобы получить анализ времени отклика, необходимо сначала активировать опцию Response Time Breakdown:

1. Выберите план, содержащий тестовый скрипт, а затем выберите команды Schedule Element Details  Response Time Breakdown.

2. В Quick Links, установите флажок Enable collection of response time data (Активировать сбор данных о времени отклика).

3. И, наконец, установите флажок для соответствующей записи.

4. Убедитесь, что инфраструктура DCI запущена и готова к мониторингу.

5. Чтобы начать мониторинг, в меню 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-компоненты и т. д. Обычно данные для анализа времени отклика собираются в среде разработки. После того, как опция включена и выбран объем собираемых данных (низкий, средний или высокий), а инфраструктура сбора данных установлена и настроена, можно получить коллекцию данных несколькими путями:

− из стандартного теста производительности Web-приложения;

− из инструментов мониторинга производительности: IBM Tivoli Monitoring for Transaction Performance, IBM® Tivoli® Composite Application Manager for Response Time Tracking, или IBM Tivoli Composite Application Manager for WebSphere;

− из сервера приложений Java™ 2 Platform, Enterprise Edition (J2EE) через функцию Application Response Measurement (ARM). Поддерживаются серверы приложений IBM WebSphere Application Server версий 5 и 6 и BEA WebLogic версии 8;

− Web-сервисов;

− из оснащенного инструментом ARM приложения. Этот режим предусмотрен для серверов приложений, не поддерживаемых J2EE. Данные можно собирать путем вставки вызовов API ARM вручную. По результатам измерений ARM сгенерирует диаграмму последовательности транзакций путем углубленного изучения исследуемого приложения;

− из журналов приложений, генерируемых приложениями, Web-серверами и серверами баз данных. Эти данные можно импортировать, анализировать и коррелировать.

Каждый сервер приложений необходимо сконфигурировать и снабдить инструментарием для работы с инфраструктурой сбора данных.

Единственная цель запуска монитора инфраструктуры сбора данных Data Collection Infrastructure (DCI) − сбор аналитических данных. Как уже говорилось ранее, чтобы обеспечить сбор данных, инфраструктуру DCI необходимо активировать (установить и запустить) для каждого сервера, на котором выполняется приложение и требуется выполнить сбор данных. Если это не будет выполнено, то будет получено сообщение об ошибке.

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

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

• Загрузка и выгрузка: Загрузка активов позволяет другим специалистам включиться в работу над ними. Выгрузка, наоборот, позволяет работать над ними на своем рабочем месте

• Поддержка перспектив: Перспективы обзора центрального репозитория системы управления версиями (CVS Repository Exploring) и синхронизации коллективной работы Team Synchronizing.

• Множественные представления: CVS Console, CVS History и CVS Repository.

• Синхронизация и слияние:

  • Синхронизация - это способ выявить различия между ресурсами на локальном рабочем месте и в центральном репозитории. Эта функция позволяет обновлять ресурсы на локальном рабочем месте и передавать ресурсы с локального рабочего места в центральный репозиторий.

  • Слияние позволяет найти компромиссное решение, если возникает конфликт ресурсов.

Интеграция с Rational ClearCase LT добавляет возможность совместного использования рабочих активов в проектных ветках, или параллельную разработку активов. Любой специалист может открыть общий доступ к файлам тестирования путем загрузки и выгрузки их из рабочей области, которая может в любой момент времени обновляться членами коллектива. Обычно отдельные специалисты работают над фрагментами коллективного проекта локально, сверяясь с работой других путем синхронизации всех изменений, сделанных в своих проектных ветках (branch). Короче говоря, вся работа, выполняемая отдельными специалистами, остается локальной и может быть предоставлена в общее пользование только после того, как эти специалисты опубликуют свои файлы, зафиксировав изменения в репозитории. После того, как вы зафиксировали изменения в своей проектной ветке, эти изменения будут скопированы с вашего локального рабочего места в репозиторий ветки.

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

• Входящих изменений: Показывает только ресурсы в репозитории CVS (системы управления версиями), которые отличаются от ресурсов на локальном рабочем месте (только входящие изменения)

• Исходящих изменений: Показывает ресурсы, которые изменялись на локальном рабочем месте (только исходящие изменения)

• Входящих/исходящих изменений: Показывает комбинацию как входящих, так и исходящих изменений

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

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

Масштабирование и обслуживание. Иногда приходится выполнять дистанционное динамическое тестирование пользовательских нагрузок для итераций теста, распределенных по территориально рассредоточенным подразделениям. Традиционные методы тестирования, при которых каждый тест ограничивается одним местом выполнения, могут оказаться неосуществимыми в территориально рассредоточенном коллективе разработчиков. В дополнении к возможности совместного использования активов невзирая на границы подразделений, Rational Performance Tester позволяет выполнить нагрузочный тест сразу в нескольких подразделениях через региональную сеть (WAN). Поскольку серверы могут быть разбросаны по всей территории, возможность удаленного выполнения в сочетании с низкими требованиями к аппаратному обеспечению, необходимому для выполнения теста, позволяет вам использовать удаленные серверы под управлением операционных систем IBM AIX, Linux, Microsoft Windows и z/OS.

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

Минимальные требования, такие, как один ЦПУ (как правило) и 1 Мбайт памяти на одного виртуального пользователя зависят, главным образом, от сложности тестовых страниц. Существуют факторы, которые могут увеличить требуемый объем памяти на одного виртуального пользователя. Вы можете добиться более высокой масштабируемости путем моделирования реальных сценариев, таких, как использование времени на размышление и пауз перед каждым последующим пользователем. Обычно рекомендуется не размещать дополнительную нагрузку на административном сервере, на котором выполняются операции централизованного администрирования, поскольку деятельность на рабочем месте потребляет ресурсы сервера.

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

Центральное администрирование обеспечивает централизованное представление и управление с небольшими системными издержками на администрирование удаленных тестовых систем. Объемы работ по администрированию локальных и удаленных тестовых серверов идентичны, потому что администрирование удаленных серверов не более сложно, чем локальных.