Складывается впечатление, что жесткое календарное планирование и ограничения в ресурсах поражают процесс разработки на самых разных стадиях. Иногда коллективы разработчиков пытаются срезать углы, минимизируя нагрузочное тестирование на каждой итерации. Чаще всего нагрузочное тестирование проводится только в конце цикла разработки, как раз перед развертыванием проекта. При этом неизбежно возникает опасность того, что качество и возможности масштабирования приложения не смогут удовлетворить ожидания клиента в отношении 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-приложениях. Доступны также следующие модули расширения:
- IBM® Rational® Performance Tester Extension for Citrix Presentation Server
- IBM® Rational® Performance Tester Extension for SOA Quality
- IBM® Rational® Performance Tester Extension for Siebel Test Automation
- IBM® Rational® Performance Tester Extension for SAP Quality
Принцип работы 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, просто выполните следующие шаги:
- Выберите из меню команды Windows > Show View > Other. Более часто используемые представления, например, журнал ошибок Error Log, схема Outline и задачи Tasks, перечислены в раскрывающемся списке в виде подменю, чтобы их было легче найти (см. рисунок 2). В перспективе по умолчанию предусмотрен предварительно заданный набор представлений. Вы можете настроить любую перспективу в соответствии с собственными предпочтениями, добавив или исключив отдельные представления.
В программе имеются самые разные перспективы с соответствующими представлениями для выполнения различных задач, общих (General), аналитических (Analysis), связанных с подключениями (Connectivity), CBS, отладкой (Debug), профилированием (Profiling), ведением журналов (Logging) и разработкой кода SQL (SQL Development). Вам остается только выбрать нужную перспективу в нужный момент. Представления можно перетаскивать в пределах окна при помощи мыши, изменять их расположение относительно друг друга; можно также восстановить перспективу по умолчанию, если вам нужно вернуться к оригинальному макету окна. Однако возврат к значениям по умолчанию выполняется только для открытой в данный момент перспективы. Например, если выбрано представление Database, оно будет отображаться так, как на рисунке 4.
О чем еще стоит упомянуть:
- Поиск представлений можно осуществлять при помощи меню. В строке меню выберите команды Windows > Navigate > Next View.
- Между представлениями, которые в данный момент открыты в рабочей области, можно переходить при помощи клавиш со стрелками (стрелка вверх или вниз). Так же можно переключаться между перспективами.
- Есть и альтернативный способ навигации - горячие клавиши CTRL-F7 (Следующая) или CTRL-SHIFT-F7 (Предыдущая). Горячие клавиши можно настроить через команды меню Windows > Preferences > Keys (слово для поиска). Настройки на вкладке General > Keys применяются ко всем перспективам.
Сбор данных тестирования в реальном времени, уточнение, воспроизведение и планирование тестирования
Сбор данных, уточнение, воспроизведение и планирование выполнения теста не представляет никаких сложностей, потому что Rational Performance Tester специально приспособлен для того, чтобы с ним могли работать даже начинающие пользователи. Все механизмы, обеспечивающие работу программы, например, механизм записи и воспроизведения скриптов, выполняются скрыто от среднего пользователя. Это сделано для того, чтобы упростить создание и обслуживание тестов. Чтобы записать тест, выполните следующие шаги:
- Сначала создайте тестовый проект. Выберите из меню команды File > New > Performance Test Project. После приглашения введите имя для нового проекта.
- Выберите запись. Для Web-приложения выберите HTTP recording. Нажмите кнопку Next.
- На следующей странице выберите тестовый проект для тестового скрипта (по имени, которое вы ему дали).
После того, как тестовый скрипт будет записан, обычно остается уточнить план тестирования. Например, вы можете изменить скрипт любым из следующих способов:
- Добавить время паузы (в миллисекундах, или мс) между виртуальными пользователями, "время на размышление" пользователя и параметры сбора статистических данных
- Определить свои пулы данных (об этом мы поговорим в следующем разделе)
- Выполнить корреляцию данных (чтобы обеспечить бесперебойную передачу представительных данных от страницы к странице)
- Добавить точки верификации (чтобы проверить коэффициент прохождения теста для каждой тестируемой страницы)
- Добавить элементы, специфичные для протокола, транзакции, циклы, комментарии, условную обработку и пользовательский код
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 (МетодПлатежа). Для создания пула данных и ассоциирования его со страницей требуется всего лишь несколько шагов:
- Нажмите правой кнопкой мыши на папке Datapools (неплохая идея поместить все пулы данных в одну папку) или в любую другую папку в панели Test Navigator (см. рисунок 12).
- Для имени пула данных можно использовать любые столбцы и строки. Вводить описание не обязательно.
Ассоциируем страницу с пулом данных
- Ассоциирование страницы с пулом данных не представляет никаких сложностей. В секции тестовых данных вкладки Performance test recording выделите строку, которую нужно заменить пулом данных, а затем нажмите кнопку Data Variable (Рисунок 16).
Совет:
URL, содержащие строки запроса, будут определены автоматически и показаны темно-зеленым цветом.
Пулы данных 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 распознает и автоматически коррелирует эти ссылки, чтобы по-разному смоделировать действия каждого пользователя. Таким образом, система отличает одного пользователя от другого по различиям в данных, запрашиваемых со всех тестовых страниц.
Существует два способа корреляции данных:
- Автоматический (автоматизированная корреляция данных), при которой генератор тестов автоматически определяет, какое предыдущее значение необходимо заменить в текущем запросе. Как уже говорилось ранее, ссылки (значения из предыдущих ответов) будут использоваться для корреляции значений в следующих запросах. Можно также усовершенствовать корреляцию при помощи пользовательского кода.
- Вручную; выполняется путем удаления имеющейся корреляции и привязки значений из предыдущего ответа к текущему запросу. Хотя автоматизированная корреляция данных выбрана по умолчанию, ее можно отключить. Однако после ее отключения вам придется самому решать, насколько будут связаны между собой поток данных и тестовые страницы. Отключить автоматизированную корреляцию данных несложно (см. рисунок 19):
- Из меню выберите команды Windows > Preferences > Performance Test Generation.
- Перейдите на вкладку Data Correlation.
Распределение и назначение рабочей нагрузки
Для имитации реальных сценариев в процессе нагрузочного тестирования приложения Rational Performance Tester предоставляет гибкие возможности, которые позволяют сделать тестирование настолько реалистичным, насколько это возможно. Вы можете создать столько тестовых скриптов и планов тестирования, сколько вам нужно, и динамически использовать любое сочетание нагрузок виртуальных пользователей. Часто специалисты интересуются, предоставляет ли инструмент следующие возможности:
- Можно ли задать 1000 виртуальных тестировщиков, которые будут работать на трех удаленных машинах с равномерно распределенной пользовательской нагрузкой?
- Можно ли сделать так, чтобы 10% общего количества виртуальных тестировщиков были запущены сначала, а затем стартовали бы еще 10% от оставшегося числа?
- Можно ли, чтобы одна группа виртуальных тестировщиков запускала в тестируемом приложении определенные фрагменты страниц?
- Можно ли определить для пользователя время на размышление?
- Можно ли рандомизировать выполнение последовательности тестов?
- Можно ли запускать нагрузочный тест удаленно, причем так, чтобы у всех виртуальных пользователей были разные IP-адреса?
- Можно ли запускать тесты с заданной скоростью?
Поскольку Rational Performance Tester допускает выполнение этих опций в любой последовательности, мы сначала рассмотрим, как можно назначить различные действия вместе с присоединенными к ним элементами различным группам пользователей и как элементы могут влиять на поведение нагрузочного теста. На рисунке 20 показано, как можно легко распределить рабочую нагрузку и назначения между различными группами пользователей, в каждую из которых входят разные виртуальные пользователи. Например, для того, чтобы добавить новую группу, выполните следующие действия:
- Нажмите правой кнопкой мыши на группе в плане тестирования (ниже Schedule Contents).
- Выберите команды Add > user group.
После того, как группа создана, можно распределить рабочую нагрузку между всеми группами путем присоединения тестовых скриптов (записей) к этим группам.
Примечание
отношение между группой пользователей и тестовыми скриптами равно 1:N. Другими словами, одна группа пользователей может выполнять более одного тестового скрипта. Что касается распределения рабочей нагрузки, то все, что вам нужно сделать - это задать абсолютное или относительное (в процентах) количество пользователей.
Однако при имитации реального сценария тестирования, одно лишь распределение рабочей нагрузки между различными группами не обязательно соответствует хорошему сценарию тестирования. Чтобы сделать сценарий более реалистичным, Rational Performance Tester предоставляет различные элементы, которые можно ассоциировать с планом тестирования. Вопрос о включении или не включении этих элементов в план зависит от сценария, который тестируется. Элементы ассоциируются непосредственно с планом тестирования. На рисунке 21 изображены некоторые элементы, которые можно включить в план.
В план тестирования можно включить следующие элементы:
- Тестовый скрипт (запись): Записав тестовый скрипт, вы можете ассоциировать его с планом. С одним планом можно ассоциировать более одного тестового скрипта (косвенно, через различные группы пользователей, поскольку каждой группе пользователей может быть назначено больше одного тестового скрипта).
- Назначение для групп и процентное распределение пользователей: Речь идет о распределении рабочей нагрузки в группе пользователей. Здесь можно задать количество пользователей, которые начнут выполнение тестового сценария. Например: 50 пользователей начнут выполнение в момент времени T1.
- Время на размышление пользователя: Для имитации времени, обычно затрачиваемого пользователем на размышление, существуют четыре варианта настроек:
- Записанное время на размышление
- Фиксированное время на размышление (по умолчанию 2 секунды)
- Динамическое увеличение или уменьшение времени на размышление в процентах
- Рандомизация времени на размышление в процентах
- Время задержки: Можно добавить задержку (в мс) между запусками тестовых скриптов разными пользователями. Вряд ли в реальном сценарии возможна ситуация по-настоящему высокого уровня синхронности (например, 20 пользователей выполняют сценарий точно в момент времени T1 без малейшей задержки). Обычно задержка в 50-100 мс считается нормальной. Если устанавливается задержка в 100 мс, то это означает, что первый пользователь (виртуальный пользователь) начинает выполнение в 12:00:00:00, а следующий - в 12:00:00:01.
- Цикл: этот элемент предназначен для выполнения теста заданной скоростью. В панели Schedule Element Details можно задать количество итераций и контроль их скорости (например, 2 итерации в секунду). Можно также рандомизировать задержки между итерациями.
- Переключатель рандомизации: В реальной жизни обращение к страницам приложения происходит случайным образом. Этот элемент предназначен для рандомизации порядка выполнения тестов; последовательность выполнения изменяется путем добавления переключателя рандомизации. При настройке переключателя рандомизации необходимо ввести весовой коэффициент. Весовые коэффициенты последовательно ассоциируются с тестовым скриптом.
- Псевдонимы IP-адресов при помощи этого элемента можно смоделировать ситуацию, в которой каждый виртуальный пользователь имеет один выделенный IP-адрес.
Об этом подробно рассказывается в части 2 данной статьи.
Мониторинг системы в реальном времени
Целью тестирования производительности является выявление узких мест путем сбора аналитических данных для всех используемых компонентов. В рамках этого тестирования проводится мониторинг производительности уровня приложений, например, инструментария уровня сервера приложений для 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
- Демон
rstatdUNIX или Linux - Microsoft Windows Performance Monitor (perfmon, системный монитор Windows)
Пример. Чтобы настроить мониторинг при помощи Windows Performance Monitor, вам придется включить мониторинг ресурсов. Для сбора аналитических данных Windows Performance Monitor выполните следующие действия:
- Выберите план тестирования.
- В панели Schedule Element Details перейдите на вкладку Resource Monitoring.
- Установите флажок Enable resource monitoring (см. рисунок 22).
- Чтобы задать новые параметры, сначала нажмите кнопку New и добавьте новый ресурс. Можно также добавить мониторинг уже существующего сервера или выбрать и отредактировать один из тех, что были определены ранее.
- Нажав кнопку Add New, вы сможете ввести свое имя пользователя в поле
usernameи пароль в полеpasswordна вкладке Location. - На вкладке 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-отчетов:
- Performance Report (Отчет о производительности)
- Page Element Report (Отчет по элементам страниц)
- Percentile Report (Отчет по процентилям)
- Verification Report (Верификационный отчет)
Примечание
В части 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%.
Помимо этих четырех отчетов вы можете углубиться до уровня страницы, чтобы лучше разобраться с временем отклика по данным этого уровня.
- Чтобы перейти на страницу, выберите страницу (вертикальная панель) на вкладке Page Performance отчета по умолчанию и нажмите на ней правой кнопкой, чтобы выбрать команду Display Page Element Responses. В примере на рисунке 30 показана страница My MTV Movie Awards '07, а для углубленного изучения выбран элемент страницы Breaking News on Yahoo!
Кроме того, Rational Performance Tester позволяет выполнить анализ основных причин. Это осуществляется двумя способами: анализ использования ресурсов (упоминавшийся ранее) и анализ статистических показателей выполнения кода. Здесь вы можете получить отчет, содержащий схему откликов, из отчета о производительности. Это позволит проанализировать статистику по элементам страницы, полученную в процессе выполнения запланированного теста, или любые импортированные из внешних инструментов архивные данные. Анализ времени отклика показывает такие детали, как длительность каждого элемента для тестируемой системы. Каждый элемент страницы ассоциируется с записью в детализированной статистике. Чтобы получить анализ времени отклика, необходимо сначала активировать опцию Response Time Breakdown:
- Выберите план, содержащий тестовый скрипт, а затем выберите команды Schedule Element Details > Response Time Breakdown.
- В Quick Links, установите флажок Enable collection of response time data (Активировать сбор данных о времени отклика).
- И, наконец, установите флажок для соответствующей записи.
- Убедитесь, что инфраструктура DCI запущена и готова к мониторингу.
- Чтобы начать мониторинг, в меню 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), хотя эта опция здесь не показана.)
Обычно данные для анализа времени отклика собираются в среде разработки. После того, как опция включена и выбран объем собираемых данных (низкий, средний или высокий), а инфраструктура сбора данных установлена и настроена, вы можете получить коллекцию данных несколькими путями:
- Из стандартного теста производительности 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 необходимо активировать (установить и запустить) для каждого сервера, на котором выполняется приложение и требуется выполнить сбор данных. Если это не будет выполнено, то мы получим сообщение об ошибке, показанное на рисунке 34.
Rational Performance Tester поставляется в составе пакета программ IBM Rational ClearCase LT для управления исходными версиями, чтобы стимулировать совместную работу в среде разработки. ClearCase LT использует односерверную модель с небольшим количеством административных требований. Хотя этот инструмент на самом деле адаптирован для небольших сред, состоящих из 25-30 разработчиков и тестировщиков, для более крупных сред вы можете воспользоваться ClearCase или IBM Rational ClearCase MultiSite; для обеих программ IBM предоставляет пути миграции.
Управление версиями может осуществляться над такими активами, как проекты, планы, тесты, пользовательский код, пулы данных, папки и результаты. Вместе с инструментом для управления исходным кодом IBM Rational ClearCase LT предоставляет следующие функции:
- Загрузка и выгрузка: Загрузка активов позволяет другим специалистам включиться в работу над ними. Выгрузка, наоборот, позволяет работать над ними на своем рабочем месте
- Поддержка перспектив: Перспективы обзора центрального репозитория системы управления версиями (CVS Repository Exploring, рисунок 35) и синхронизации коллективной работы Team Synchronizing.
- Множественные представления: CVS Console, CVS History и CVS Repository.
- Синхронизация и слияние:
- Синхронизация - это способ выявить различия между ресурсами на локальном рабочем месте и в центральном репозитории. Эта функция позволяет обновлять ресурсы на локальном рабочем месте и передавать ресурсы с локального рабочего места в центральный репозиторий.
- Слияние позволяет найти компромиссное решение, если возникает конфликт ресурсов.
Интеграция с Rational ClearCase LT добавляет возможность совместного использования рабочих активов в проектных ветках, или параллельную разработку активов. Любой специалист может открыть общий доступ к файлам тестирования путем загрузки и выгрузки их из рабочей области, которая может в любой момент времени обновляться членами коллектива. Обычно отдельные специалисты работают над фрагментами коллективного проекта локально, сверяясь с работой других путем синхронизации всех изменений, сделанных в своих проектных ветках (branch). Короче говоря, вся работа, выполняемая отдельными специалистами, остается локальной и может быть предоставлена в общее пользование только после того, как эти специалисты опубликуют свои файлы, зафиксировав изменения в репозитории. После того, как вы зафиксировали изменения в своей проектной ветке, эти изменения будут скопированы с вашего локального рабочего места в репозиторий ветки.
Ветки (branch) могут быть совершенно разными, например, для каждого параллельного проекта на основе функциональных требований. В работе с различными ветками применяются те же принципы. Вы сможете изучить работу других специалистов только после того, как синхронизируете активы на своем рабочем месте с центральным репозиторием. Для поддержки синхронизации в IBM Rational Performance Tester предусмотрена перспектива Team Synchronizing с простой навигацией и управлением. К синхронизации имеют отношение четыре модели:
- Входящих изменений: Показывает только ресурсы в репозитории CVS (системы управления версиями), которые отличаются от ресурсов на локальном рабочем месте (только входящие изменения)
- Исходящих изменений: Показывает ресурсы, которые изменялись на локальном рабочем месте (только исходящие изменения)
- Входящих/исходящих изменений: Показывает комбинацию как входящих, так и исходящих изменений
- Конфликтов: Показывает конфликтующие ресурсы. Конфликт ресурсов возникает в том случае, когда в репозитории имеется более свежая копия, чем та, над которой вы работаете. Конфликт ресурсов можно разрешить путем их слияния. Вряд ли можно назвать хорошим вариантом ликвидацию работы вашего коллеги.
Пользовательский код и углубленное тестирование
IBM Rational Performance Tester, в основном, представляет собой интерактивный инструмент с графическим интерфейсом пользователя для тестирования программного обеспечения, который позволяет даже начинающему пользователю с легкостью выполнять нагрузочное тестирование. Однако иногда может возникнуть необходимость в более углубленных методах тестирования, которые требуют добавления пользовательского кода.
Функция custom code представлена кнопкой с зеленой буквой C. Пользовательский код можно вставить в любом месте тестового скрипта. На рисунке 36 показаны два добавленных фрагмента пользовательского кода. При первой вставке пользовательского кода имя класса генерируется автоматически. Но вы можете присвоить классу более понятное имя, если хотите.
После вставки пользовательского кода можно сразу же перейти к логике кода, переключившись на представление исходного кода Java (нажав кнопку View Code). Можно также переключиться на перспективу Java Browsing. Кроме того, встроенная интегрированная среда разработки Java (IDE) позволяет выполнить отладку кода.
Для выполнения углубленного тестирования предоставляется два интерфейса, CustomCode2 и ITestExecutionServices (имеется полное руководство в формате Javadoc). Ниже приводится ряд сценариев, которые обычно требуют выполнения углубленных тестов:
- Контроль над поведением циклов
- Выполнение выхода для обращения к внешней программе
- Поиск IP-адреса группы пользователей или отдельного пользователя
- Сохранение и удаление файлов cookie для пользователя
- Получение информации из области данных пользователя
- Корреляция данных одной страницы для другой страницы
Масштабирование и обслуживание
Иногда приходится выполнять дистанционное динамическое тестирование пользовательских нагрузок для итераций теста, распределенных по территориально рассредоточенным подразделениям. Традиционные методы тестирования, при которых каждый тест ограничивается одним местом выполнения, могут оказаться неосуществимыми в территориально рассредоточенном коллективе разработчиков. В дополнении к возможности совместного использования активов невзирая на границы подразделений, 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 и их вариациях, а также научитесь изменять их в соответствии со своими специфическими потребностями.