Содержание


Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester

Часть 1. Разработка тестов с помощью Rational Performance Tester

Comments

Серия контента:

Этот контент является частью # из серии # статей: Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester

Следите за выходом новых статей этой серии.

WebSphere Commerce – это разработанное IBM корпоративное решение для электронной коммерции. Постоянную озабоченность вызывают производительность и надежность Web-сайтов. На решение этой проблемы направлены тестирование и мониторинг производительности, выполняемые с помощью таких инструментов, как Rational Performance Tester. Поскольку проблемы производительности сложны и многогранны, решение WebSphere Commerce состоит из нескольких программных приложений и сборок. Используемые аппаратные ресурсы являются еще одним фактором, т.к. они могут ограничивать масштабируемость решения в целом.

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

Написание тестов требует понимания бизнес-транзакций в производственной среде и реалистичного их воссоздания. Информацию о транзакциях можно найти в инструментах Web-аналитики или путем исследования журналов приложения или таблиц базы данных. При определении объема имитируемых транзакций необходимо учитывать обычную и пиковую бизнес-активность. В Rational Performance Tester ее можно имитировать с помощью свойств графика и случайных селекторов.

Тесты производительности должны предоставлять значимые результаты, которые смогут интерпретировать заинтересованные стороны. Основными показателями производительности являются:

  • Пропускная способность заказов
  • Время отклика
  • Просмотры страниц
  • Использование процессора
  • Коэффициент попадания в кэш
  • Коэффициент SQL-активности базы данных

Пропускная способность заказов показывает интенсивность обработки доходных транзакций. Увеличение тестовой рабочей нагрузки позволяет понять, возможно ли увеличение пропускной способности заказов без нарушения ограничений, например времени отклика и ресурсов процессора. Время отклика находится в обратной зависимости от пропускной способности и напрямую влияет на удовлетворенность пользователей. Количество просмотров страниц является показателем популярности Web-сайта независимо от размера приносимого им дохода. Информация о системе, такая как использование процессора, коэффициент попадания в кэш и коэффициент SQL-активности базы данных, нужна архитекторам и разработчикам, которые должны знать, что нужно изменить для достижения лучшей производительности. Rational Performance Tester может взаимодействовать с показателями приложения для предоставления этой информации.

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

Создание тестов

Данная статья предоставляет рекомендации по созданию тестов в Rational Performance Tester. В ней рассматриваются следующие темы:

  • Разделение тостов на модули для повторного их использования.
  • Использование локальных и глобальных переменных.
  • Очистка кэша cookie.
  • Установка точек верификации для ответов.
  • Упорядочение задач в транзакции в плане.
  • Настройка автоматического перенаправления HTTP.

Во всех примерах используется сбалансированный каталог, имеющий три категории первого уровня. Каждая категория имеет две подкатегории, а каждая подкатегория имеет три товара (см. рисунок 1).

Рисунок 1. Структура каталога
Структура каталога
Структура каталога

Разделение на модули и повторное использование

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

Последовательность записываемых действий (путь записи) показана на рисунке 2: Homepage > Login > Перейти к topCat2 через Department button > Перейти к subCat4 > Отобразить Prod10 > Logout.

Рисунок 2. Запись теста
Запись теста

Результатом записи является набор страниц, который можно разделить на четыре повторно используемых теста:

  • Homepage (домашняя страница)
  • Login (вход)
  • Browse (просмотр)
  • Logout (выход)

Группирование набора страниц или тестов в блок транзакции позволяет Rational Performance Tester создать отчет по этой транзакции. Разделение записи на небольшие тесты и использование их внутри транзакций позволяет создать транзакцию просмотра для гостей и зарегистрированных пользователей (см. рисунок 4).

Переменные

Эти тесты обмениваются информацией друг с другом. Данные передаются из одного теста в другой с помощью глобальных переменных.

Большинство глобальных переменных устанавливается в пулах данных. Некоторые из них устанавливаются либо путем прямого назначения, либо в пользовательском коде.

Лучший способ – инициализировать все глобальные переменные пулов данных в отдельном тесте (например, с именем InitVariables) и поместить его в начало плана. При таком подходе не нужно будет модифицировать все тесты в случае изменения пула данных.

Нужно создать еще один тест для установки регистрационных имен виртуальных пользователей в каждой итерации. Если регистрационные имена пользователей находятся в диапазоне от sadmin1 до sadmin300, пользовательский код может случайным образом генерировать имя из этого диапазона. Этот пользовательский код можно поместить либо в тот же тест InitVariables, либо в новый тест. В нашем случае был выбран второй вариант – создание нового теста InitUser. Кроме того, в Rational Performance Tester есть встроенный генератор случайных чисел для замены значений в источниках данных.

Во всех тестах для инициализации переменных используется пул данных с одной строкой значений. Для каждого теста нужны имя хоста (Hostname), идентификатор каталога (CatalogID), идентификатор языка (LangID) и идентификатор хранилища (StoreID). Для генерирования регистрационного имени используются значения UsedIdPrefix и MaxRegisteredUsers. Rational Performance Tester также позволяет инициализировать в плане глобальные переменные из файла и создавать таблицу инициализации переменных для группы пользователей. В приведенных ниже примерах используется пул данных.

Рисунок 3. Пул данных Constants
Пул данных Constants
Пул данных Constants

Пример плана теста производительности показан на рисунке 4.

Рисунок 4. План теста
План теста
План теста

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

Обратите внимание, что тесты Login и Logout располагаются за пределами блоков Transaction. В реальном плане зарегистрированные пользователи не только выполняют транзакции просмотра, но и добавляют товары в корзину, заказывают товары, добавляют товары в перечень пожеланий или проверяют заказы. Каждый такой тест может иметь свою собственную транзакцию.

Если время отклика тестов Login и Logout должно быть частью транзакции, их необходимо переместить в соответствующий блок Transaction.

Тест InitVariables использует пул данных Constants. Метка OUTPUT для контейнера переменных указывает, что эти переменные являются выходными данными теста, т.е. были установлены этим тестом, а используются другими тестами. Видимость этих глобальных переменных должна иметь значение All tests for this user (см. рисунок 6).

Рисунок 5. Тест InitVariables
Тест InitVariables
Тест InitVariables
Рисунок 6. Видимость переменных
Видимость переменных

В тестах, использующих переменные теста InitVariables, необходимо установить контейнер переменных с меткой INPUT и объявить те же переменные. Эти переменные должны иметь те же имена и видимость All tests for this user, чтобы их можно было использовать во всех тестах.

Например, в тесте Homepage глобальная переменная StoreId устанавливается из теста InitVariables. Она используется для замены жестко закодированных значений StoreId в Homepage.

Рисунок 7. Переменная StoreId и ее замена
Переменная StoreId и ее замена
Переменная StoreId и ее замена

Управление кэшем cookie

Первый тест плана должен очистить кэш cookie, чтобы имитировать новый сеанс Web-браузера. Если для воспроизведения тестов в плане используется цикл, очень важно настроить поведение кэша cookie. Очистка кэша cookie показана на рисунке 8.

Рисунок 8. Очистка кэша cookie
Очистка кэша cookie
Очистка кэша cookie

Точки верификации

Чтобы проверить тесты на корректность, нужно создать точки верификации. Они используются для определения проблем в ответах. Причинами плохой производительности являются ошибки в контенте страниц или непредвиденный контент. Есть три типа точек верификации: размер ответа, код ответа и контент ответа. Их можно создать для ответа, выбрав Add в контекстном меню. Также их можно создать для всего теста, выбрав тест в дереве тестов и нажав Add. Точки верификации типов "код ответа" и "размер ответа" можно включить автоматически в предпочтениях теста. На рисунке 9 показано добавление точки верификации.

Рисунок 9. Добавление точки верификации
Добавление точки верификации
Добавление точки верификации

На рисунке 10 показано диалоговое окно создания точки верификации контента. Здесь можно задать верификацию, основанную на наличии или отсутствии в контенте ответа определенных строк.

Рисунок 10. Создание точки верификации контента
Создание точки верификации контента
Создание точки верификации контента

После ввода строки можно указать действие в случае ошибки в точке верификации, например, останов текущей транзакции или выход из текущей итерации цикла (см. рисунок 11).

Рисунок 11. Действие в точке верификации
Действие в точке верификации
Действие в точке верификации

Во время воспроизведения теста или плана можно контролировать точки верификации, используя отчет о точках верификации. Он содержит информацию реального времени о правильности выполнения теста. На рисунке 12 показан отчет о точках верификации.

Рисунок 12. Отчет о точках верификации
Отчет о точках верификации
Отчет о точках верификации

Использования плана тестирования

После описанного выше разделения теста на модули можно создать из них план в контейнере транзакции. В зависимости от имитируемого сценария можно создавать различные последовательности или транзакции. Например, план на рисунке 13 содержит транзакцию RegisteredShopper_CompleteOrder и тесты выполнения заказа.

Рисунок 13. План для транзакции зарегистрированного покупателя
План для транзакции зарегистрированного покупателя
План для транзакции зарегистрированного покупателя

На базе версии для зарегистрированного покупателя можно создать новый план для покупателя-гостя (см. рисунок 14). Для этого определяется новая транзакция GuestShopper_CompleteOrder и последовательность тестов выполнения этой транзакции. Обратите внимание, что общие для зарегистрированного покупателя и покупателя-гостя тесты были использованы повторно, а другие тесты были добавлены или удалены, поскольку они специфичны для конкретной транзакции.

Рисунок 14. План для транзакции покупателя-гостя
План для транзакции покупателя-гостя
План для транзакции покупателя-гостя

Виртуальные пользователи в плане Rational Performance Tester делятся на группы, а план предоставляет случайные селекторы для выбора различных транзакций. Виртуальные пользователи назначаются группе в процентах или в абсолютных величинах. В плане на рисунке 15 показаны группы зарегистрированных покупателей и покупателей-гостей, каждая из которых содержит по 50% от общего числа виртуальных пользователей. Пользователи-гости выполняют транзакции заказа или просмотра в соответствии с их весами в случайном селекторе. Транзакции GuestShopper_CompleteOrder и GuestShopper_Browse имеют вес 1, т.е. вероятность выполнения каждой из них одинакова и равна 50%.

Рисунок 15. Полный план
Полный план
Полный план

Автоматическое перенаправление HTTP

Rational Performance Tester V8.3 (и старше) обеспечивает автоматическое перенаправление HTTP без явного указания в тесте запросов на перенаправление. Перенаправление HTTP означает, что запрос возвращается с запросом другого URL-адреса. Примером перенаправления HTTP является запрос Login. Запрос Login возвращается с кодом состояния HTTP 302, который означает перенаправление и выполнение нового запроса OrderItemMove. OrderItemMove перенаправляется в OrderCalculate. OrderCalculate перенаправляется в последний запрос AjaxLogonForm.

Для успешного выполнения теста Login без автоматического перенаправления HTTP в него должны входить все три приведенных выше запроса. Последовательность запросов на перенаправление жестко кодируется. В случае новой последовательности перенаправлений тест Login необходимо перезаписать.

Рисунок 16. Перенаправление в тесте Login
Перенаправление в тесте Login
Перенаправление в тесте Login

Наиболее надежный подход – следовать переправлениям по мере их возникновения. Это – автоматическое перенаправление HTTP, осуществляемое путем изменения ожидаемого кода состояния ответа для теста Login с [302 – Found] на [200 – OK]. Оно указывает Rational Performance Tester выполнять все перенаправления до кода состояния [200 – OK], которому в тесте Login соответствует страница AjaxLogonForm.

Как показано на рисунках 17 и 18, тест Login использует автоматическое перенаправление путем изменения ожидаемого кода состояния ответа и отключения запросов на перенаправление. Воспроизведение показывает, что все перенаправления выполнены правильно.

Рисунок 17. Автоматическое перенаправление в тесте Login
Автоматическое перенаправление в тесте Login
Автоматическое перенаправление в тесте Login
Рисунок 18. Воспроизведение автоматического перенаправления в тесте Login
Воспроизведение автоматического перенаправления в тесте Login
Воспроизведение автоматического перенаправления в тесте Login

Заключение

Первая часть этой серии посвящена созданию тестов с помощью Rational Performance Tester и передовым методикам реализации плана тестирования. Во второй части с помощью некоторых из этих методик реализован пример просмотра каталога WebSphere Commerce.

Благодарности

Значительный вклад в написание и рецензирование статьи внесли следующие члены группы Rational Performance Tester:

  • Кент Сифкес (Kent Siefkes) – ведущий архитектор Rational Performance Tester.
  • Дон Питерс (Dawn Peters) – разработчик ПО Rational Quality and Requirements Management.

Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational, WebSphere
ArticleID=986661
ArticleTitle=Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester: Часть 1. Разработка тестов с помощью Rational Performance Tester
publish-date=05072014