ПО компании Lawson Software включает приложения класса EPR (enterprise resource planning, управление ресурсами предприятия) и HR (human resources, кадровые ресурсы), которые используются во многих больницах и учреждениях здравоохранения. Эти приложения являются критически важными для бизнеса, поэтому тестирование производительности приобретает особую важность для успешного развертывания и модернизации систем Lawson. В этой статье даются рекомендации и информация (в том числе пошаговые инструкции) по использованию инструмента IBM Rational Performance Tester для тестирования приложений Lawson.
Для выполнения действий, описанных в данной статье, необходимо, чтобы в системе был установлен программный продукт IBM®Rational® Performance Tester версии 7.0.0.2 или более поздней. Для тестирования приложений Lawson не требуется никаких дополнительных модулей расширения или подключаемых модулей. Автор статьи предполагает, что читатель обладает достаточными знаниями и навыками использования Rational Performance Tester, в том числе умеет записывать и редактировать тесты, добавлять точки верификации и ручные корреляции и имеет общее представление о работе с отчетами.
Общее описание приложений Lawson
Компания Lawson Software, партнер IBM, предлагает программное обеспечение для управления эффективностью деятельности в организации, управления цепочками поставок, управления ресурсами организации (EPR), планирования производственных ресурсов, управления информационными активами организации и приложения для производства. На Web-сайте компании Lawson о взаимоотношениях с корпорацией IBM говорится следующим образом:
"Компания Lawson предоставляет соответствующие признанным стандартам решения с открытым исходным кодом, которые фундаментальным образом повышают производительность бизнеса у клиентов. Открытая архитектура решений Lawson обеспечивает клиентам превосходное качество, низкую общую стоимость приобретения и путь к внедрению сервис-ориентированной архитектуры (service-oriented architecture, SOA). Технологическая платформа решений Lawson -- Lawson System Foundation 9 -- объединяет в себе новейшие технологии Lawson и связующее ПО мирового класса от IBM для создания высокопроизводительных, соответствующих стандартам решений, которые обеспечивают весь комплекс преимуществ безопасности, масштабируемости, простоты и удобства в применении. Кроме того, мы не ограничиваем выбор аппаратной платформы клиентом и одновременно создаем базу для следующего поколения приложений Lawson, предназначенных для использования в SOA-средах."
Lawson предлагает информационные решения для здравоохранения уже более десяти лет. Приложения компании можно встретить во многих больницах, учреждениях здравоохранения и вспомогательных учреждениях на всей территории США и во многих других странах.
Общие принципы тестирования производительности приложений Lawson
Платформа Lawson System Foundation выполняет несложное тестирование производительности HTTP с помощью стандартного Web-клиента. Хотя он не особенно отличается от других Web-приложений, все же следует отметить несколько характеристик, имеющих значение для использования Rational Performance Tester:
- Приложение Lawson , как правило, состоит из некоторого количества форм, доступ к которым осуществляется напрямую путем ввода имени или идентификатора формы, например, HR11. Каждый раз, когда пользователь вводит значение в поле (переходя в следующее поле по нажатию клавиши Tab или нажимая в нем левой клавишей мыши), он инициирует процедуру запрос/отклик HTTP, даже если ему самому кажется, что на странице ничего не изменяется. Заполнение одной формы может вызывать множество запросов и передачу множества скрытых полей в каждом отклике. Других коммуникаций, помимо вышеописанных, например, двоичного или иного сетевого трафика, не относящегося к протоколу HTTP, в этом случае очень немного.
- При выполнении теста Rational Performance Tester может группировать несколько полей (шагов) в одну страницу, однако это решение не является идеальным для генерации отчетов или выявления узких мест производительности. Уменьшение порогового значения времени генерации страницы позволяет создавать тесты, которые будут более приемлемыми в смысле генерации отчетов и более простыми для редактирования и понимания (см. раздел "Параметры инструмента" далее по тексту.)
- Lawson использует двойную аутентификацию, хотя она может выполняться автоматически инструментом Rational Performance Tester. В некоторых случаях, возможно, вам придется вручную редактировать параметры аутентификации (см. ниже по тексту раздел "Редактирование тестов вручную") Некоторые поля, в том числе скрытые поля HTTP, не могут быть скоррелированы Rational Performance Tester в автоматическом режиме, поэтому вам придется выполнить корреляцию вручную (см. ниже раздел "Корреляция данных".)
- Многие функции Lawson требуют указания в поле ввода текущей даты. Значение даты должно совпадать с датой выполнения теста. Для этого можно использовать функцию пользовательского кода Rational Performance Tester, о которой рассказывается в разделе "Генерация данных в ходе выполнения теста (пользовательский код)" ниже.
- Точки верификации (VP) контента - важнейшая составляющая для подтверждения работоспособности функций Lawson в процессе выполнения теста. (См. раздел "Активация точек верификации" далее.)
- Одним из самых сложных аспектов разработки тестов для Lawson является то, что приложение может сгенерировать сообщение об успешном выполнении даже в том случае, если транзакция не была успешной. Например, если запрос на изменение имеет некорректное значение в одном из полей, правильная запись не будет изменена, но Lawson сгенерирует уведомление "Change Complete" (Изменение зафиксировано). Один из способов убедиться в успешности транзакции - это просмотреть запись (в ручном или автоматическом режиме) и проверить, внесено ли изменение.
Примеры бланков (форм) Lawson для здравоохранения
Ниже перечислены несколько распространенных форм Lawson, которые, возможно, вам придется тестировать:
- AP20 - Invoice Data (Данные счетов)
- HR11 - Employee Maintenance (Информация о сотрудниках)
- IC21 - Issues (Проблемы)
- PA26 - Employee Review (Список сотрудников)
- PA31 - Applicant (Претенденты)
- PA52 - Individual Action (Индивидуальные действия)
- PO20 - Purchase Order (Заказы на приобретение)
Исходные соображения по разработке тестов
Прежде чем приступить к записи тестовых процедур в Rational Performance Tester, эти тестовые процедуры нужно документировать. Обязательно укажите, какие значения в полях будут включены в пул данных (ввод из таблицы тестовых данных) и будут ли они произвольными или статичными (одинаковыми для всех выполняемых тестов). Учитывая объем работы, который часто необходим для улучшения скриптов для приложений Lawson, важно предварительно проверить и утвердить процедуры.
Кроме того, важно тщательно продумать и отбирать тестовые данные, поскольку это может повлиять на разработку тестов. Например, если вы записываете транзакцию при помощи тестовой записи, не имеющей ни одного поля со значениями <_f93> и <_f94> , а поля являются скрытыми, но при этом остальные тестовые данные имеют значения, то будет трудно скоррелировать их по записанной транзакции. В идеале тестовые данные, используемые для записи, должны иметь максимальное количество доступных значений. То есть формы должны быть заполнены данными настолько плотно, насколько это возможно, но при этом они должны быть реалистичными, чтобы отвечать задачам тестирования.
Большинство параметров Rational Performance Tester по умолчанию прекрасно подходят для работы с системами Lawson, за исключением параметра delay to generate a new page (задержка для генерации новой страницы), значение которого рекомендуется уменьшить. Измените это значение; для этого выберите из меню команды Window > Preferences > Test > Performance Test Generation, а затем перейдите на вкладку Protocol и задайте значение параметра Generate new page if delay between requests равным 1000 мс или меньше. Это гарантирует, что Rational Performance Tester будет генерировать тесты, в которых каждая страница содержит запрос к одному полю, что облегчит редактирование тестов. Затем транзакции можно использовать для своевременной генерации отчетов для целой формы или действий пользователя.
Запись теста производительности в приложении Lawson
Инициализация записи тестов для приложений Lawson не отличается от HTTP-записи.
- Запись можно начать, нажав на панели инструментов кнопку Create New Test From Record или выбрав соответствующую команду из меню Test From Recoding (File > New > Test From Recoding).
- Для записи тестов для Lawson выберите опцию HTTP Recording (см. рисунок 1), а затем нажмите кнопку Next.
Рисунок 1. Create New Test From Recording
- В следующем диалоговом окне выделите соответствующую папку в проекте тестирования производительности, введите имя теста, а затем нажмите Finish, чтобы продолжить работу.
- После запуска записи тестировщик должен выполнить различные действия с приложением Lawson.
- После выполнения сценария тестирования закройте браузер, чтобы остановить запись, и сгенерируйте тест. На рисунке 2 показана запись сценария тестирования для приложения Lawson Requisition Self Service (RSS) (приложение для самозаписи на прием).
Рисунок 2. Записанный сценарий тестирования производительности
После того как вы запишете процедуру тестирования приложения Lawson в тест, этот тест необходимо отредактировать. Некоторые сохраненные в процессе записи значения должны быть уникальными для теста, чтобы при их воспроизведении не возникало ошибок. Эти значения могут поступать с серверов Lawson или вычисляться (например, текущее время), и это необходимо скоррелировать в тесте. Остальные значения не обязательно должны быть разными, но, скорее всего, вы сами захотите изменить их, чтобы создать реалистичный тест. Такие дополнительные значения могут подаваться из таблиц тестовых данных, которые необходимо добавить в пул данных теста. В следующем разделе перечислены значения для Lawson, которые следует изменить, а также рассказывается о том, как изменить другие тестовые данные.
После того как Rational Performance Tester закончит генерацию теста, одним из первых действий, которые вы сможете выполнить, будет переименование страниц. Web-приложение Lawson не генерирует понятных имен, которые Rational Performance Tester мог бы использовать для их обозначения. Например, некоторые страницы вместо реального наименования соответствующей формы могут получить имя servlet_ida. Рекомендуется переименовать такие страницы в соответствии с именами форм, к которым происходит обращение, или конкретных полей, значения в которых изменяются. Это важно потому, что помогает не только "читать" тесты в Rational Performance Tester, но и, что более важно, интерпретировать результаты теста и отчеты.
Адаптация аутентификации в системе
Lawson использует метод базовой аутентификации (Basic Authentication), которая может быть записана в Rational Performance Tester. Это довольно понятно и несложно в обработке, но большинство приложений используют базовую аутентификацию только один раз. В системах Lawson пользователи аутентифицируются и на странице входа, и при обращении к домашней странице. Следовательно, Rational Performance Tester создает две папки базовой аутентификации в каждом тесте (см. рисунок 3). Здесь в пул данных можно добавить значения User ID и Password:
- просто выберите userID или password, нажмите правой кнопкой мыши и выберите команды Substitute From > Datapool Variable (см. рисунок 3).
Рисунок 3. Базовая аутентификация для HTTP-запроса
Первый запрос к домашней странице портала Lawson вместе с информацией для базовой аутентификации будет содержать также значение временной метки. Несмотря на то, что это может не быть обязательным, значение должно отражать текущее время при каждом воспроизведении теста, то есть оно должно быть уникальным.
Рисунок 4. Временная метка в тесте
Чтобы предоставить уникальные значения для временной метки, можно воспользоваться встроенным средством - источником данных Rational Performance Tester:
- Выделите значение временной метки в тестовых данных (см. рисунок 5), а затем нажмите кнопку Substitute From.
- Выберите пункт Built-in Datasources.
- В открывшемся диалоговом окне мастера Built-in Datasource Selection (рисунок 6), выделите элемент Timestamp, а затем нажмите кнопку Finish.
Рисунок 5. Выбор временной метки Timestamp в тестовых данных
Рисунок 6. Мастер Built-in data sources
Можно использовать для данных профиля пользователя пул данных. Однако, поскольку приложения Lawson указывают эти данные в процессе обращения к материалам домашней страницы портала Lawson (см. рисунок 7), то лучше коррелировать информацию по данным отклика. Это гарантирует использование корректной информации и экономит память, которую в противном случае занял бы пул данных.
Рисунок 7. Профиль WebUser в содержимом отклика
Пользователи Lawson вводят в систему много значений, в том числе имена и количества при заполнении форм. Первоначально тест будет содержать только значения, которые вы использовали при его записи. Rational Performance Tester при помощи цветового кодирования (зеленым цветом) покажет значения в тесте, для которых вы, возможно, захотите выполнить подстановку; они обозначаются как Datapool Candidates (претенденты на использование в пуле данных).
Из процедуры тестирования вы должны узнать, какие значения необходимо изменить для каждого пользователя в процессе выполнения теста, и эти значения должны быть указаны в таблице тестовых данных. В Rational Performance Tester можно импортировать тестовые данные из таблицы в пуле данных через текстовый файл с разделителями-запятыми (.csv). Если ваши тестовые данные оформлены в пул данных, то вы можете выполнить для них подстановку значений из пула данных. Для каждого значения формы, которое нужно включить в пул данных, выполните следующие задачи:
- Запустите в рамках теста функцию Test Search (Ctrl+H). Выберите только запросы (HTTP Requests), убедитесь, что установлены флажки URL и POST Data, и выполните поиск значений, которые использовались в процессе записи.
- В панели результатов поиска разверните каждый экземпляр, нажмите на нем правой кнопкой мыши и выберите команду Go To, чтобы выделить значения в панели Test Elements Details.
- Нажав правой кнопкой мыши на значении, выделенном в Test Elements Details, вы сможете выполнить подстановку переменной пула данных.
- Повторите шаги 2 и 3 для каждого результата поиска.
Несмотря на то, что пользователь вводит определенные тестовые данные непосредственно в форму, остальные данные извлекаются из базы данных Lawson, а затем передаются туда и обратно в процессе выполнения тестовой процедуры. Например, вы вводите код компании 123, а Lawson извлекает название компании Acme, Inc., и после этого во всех запросах используются оба значения. Вы вводите только одно значение, а остальные сопутствующие значения могут быть невидимыми.
Транзакции в приложениях Lawson будут выполняться только в том случае, если все связанные значения передаются совместно. Следовательно, если вы выполните подстановку не для всех значений, то транзакция будет некорректной. Необходимо определить, какие данные соответствуют значениям, которые вводятся непосредственно в форму. Вполне может быть, что вы не определите эти значения даже после того, как изучите ошибки, полученные при первичном воспроизведении теста. Иногда может отыскаться специалист, знакомый с формами и использовавшимися в них данными, который скажет вам, какие это значения. В противном случае вы можете просмотреть содержимое данных POST (обычно после таких действий, как Add, Change или Inquiry) и найти в них значения, соответствующие тем, которые вы ввели. Для каждого найденного значения, требующего корреляции вручную, выполните следующие шаги:
- Запишите две совершенно разные транзакции (с разными компаниями, сотрудниками и т. д.).
- Выполните функцию Test Search в рамках теста, выбрав только отклики (HTTP Responses) (не Requests) и установив флажок Content, и выполните поиск по идентифицированным значениям.
- В панели результатов поиска разверните только первый экземпляр, нажмите на нем правой кнопкой мыши и выберите команду Go To, чтобы выделить значения в панели Test Elements Details.
- Нажмите правой кнопкой мыши на выделенном значении в панели Response Content и выберите команду Create Reference.
- Запустите еще один поиск Test Search, выбрав только HTTP Requests, и найдите то же значение.
- В панели результатов поиска разверните каждый экземпляр, нажмите на нем правой кнопкой мыши и выберите команду Go To, чтобы выделить значения в Test Elements Details.
- Вы можете нажать правой кнопкой мыши на выделенном значении в Test Elements Details и выполнить подстановку ссылочного значения (Substitute From > value - Content).
- Повторите шаги 6 и 7 для каждого результата поиска.
- Для всех остальных форм, требующих корреляции вручную, повторите шаг 3.
В некоторых случаях, например, для формы HR11, лучше определить изменяемые данные следующим способом:
- Запишите две совершенно разные транзакции (с разными компаниями, сотрудниками и т. д.).
- Найдите страницу, для которой в тестовой процедуре выполнялись основные операции, такие, как Inquire, Add или Change. Она будет иметь URL вида [server]/servlet/args и передавать значения в данных POST.
Совет: Возможно, вам понадобится для сравнения также просмотреть другие запросы, например, предложение Get перед заключительным предложением POST.
- Выделите данные запроса и скопируйте их в отдельный текстовый файл.
- Можно также использовать файл трассировки полностью (*.rec), но это может оказаться сложнее.
- Повторите эти действия для остальных записанных тестов, в результате вы получите два файла с одним и тем же запросом, но разными данными.
- Сравните запросы при помощи утилиты сравнения файлов (инструмент "diff"). Помимо очевидных значений, которые вы ввели или увидели на экране, инструмент diff покажет также скрытые и затененные значения, которые должны быть уникальными для каждой транзакции.
Генерация данных в ходе выполнения теста (использование пользовательского кода)
Некоторые данные, которые используются в тестах для Lawson, не предоставляются самой системой и, возможно, вам не нужно хранить их в пулах данных. Примеры - текущая дата или поля, требующие ввода произвольной информации. Такие значения в Rational Performance Tester можно сгенерировать в ходе выполнения теста при помощи пользовательского кода следующим образом:
- Выполните функцию Test Search в рамках теста, выбрав только HTTP-запросы (HTTP Requests) и установив флажки URL и POST Data, а затем выполните поиск значений, которые использовались в процессе записи.
- В панели результатов поиска разверните каждый экземпляр, нажмите на нем правой кнопкой мыши и выберите команду Go To, чтобы выделить запрос, в котором значение соответствует критериям поиска.
- В панели Test Contents вставьте (кнопка Insert) или добавьте (кнопка Add) класс пользовательского кода до (выше) первого запроса, использующего это значение (запрос показан в описании шага 2). При необходимости можно переместить класс выше или ниже в иерархии.
- Если класс требует ввода значения (например, если вы выполняете синтаксический анализ или операции с данными из значений теста), то вы должны создать ссылку для этого значения. Это можно сделать до или после создания класса.
- Добавьте ее в пользовательский код, либо из ссылки, либо из пула данных.
- Создайте или скопируйте код внутри класса и передайте нужные данные обратно в тест с возвратом. Пример такого класса - класс
GetDate, который возвратит текущую дату в формате, который используется в формах Lawson (региональный стандарт U.S English). - Вернитесь к результатам поиска, нажмите правой кнопкой мыши на том же значении, которое было выбрано на шаге 2, и выберите команду Go To.
- Для значения, выделенного в панели Test Elements Details, выполните подстановку из возвращаемого пользовательским кодом результата.
- Повторите шаги со 5 по 6 для каждого результата поиска.
Чтобы гарантировать точность выполнения тестов, можно использовать несколько доступных вариантов точек верификации (verification point, VP). Вы можете активировать их для всего теста или для отдельных страниц. Два примера:
- Чаще всего используются точки верификации кода отклика (Response Code VP). Они следят за тем, чтобы код состояния, зафиксированный в ходе записи теста, не изменялся в процессе выполнения теста.
- Точки верификации контента (Content verification points) представляют собой эффективный инструмент, позволяющий проконтролировать, встречается ли в содержимом отклика определенная строка.
Рисунок 8. Активация точек верификации
Всегда включайте в тест хотя бы одну точку верификации контента (Content VP). Это можно сделать, выполнив следующие шаги:
- Найдите страницу, для которой в тестовой процедуре выполнялись основные операции, такие, как Inquire, Add или Change. Она будет иметь URL вида
[server]/servlet/argsи передавать значения в данных POST. - Нажмите правой кнопкой мыши на содержимом отклика (response content) и активируйте точку верификации Content VP.
- Добавьте определяемую пользователем строку:
<MsgNubr>lt;/MsgNbr>. Это нужно будет сделать только один раз для каждого проекта. - Выберите опцию Verification fails if: None of the checked strings are found.
- Если нужно, можете повторить эти действия для других откликов на аналогичные действия в том же тесте.
Воспроизведение теста производительности в приложении Lawson
Rational Performance Tester обеспечивает точное моделирование рабочей нагрузки благодаря использованию планов. Следовательно, после того, как вы отредактируете тест, вам нужно будет создать план.
- Чтобы смоделировать задачу, сначала добавьте в план группы пользователей, а затем - соответствующие тесты для каждой группы.
- Кроме того, вы можете распределить выполнение тестов между несколькими машинами. В данном сценарии мы определили, что группа User Group 4 запускает тесты с тестового агента с именем
TestSrv1(см. рисунок 9).
Рисунок 9. План теста производительности
Выполнение плана тестирования производительности, в соответствии с которым применяется нагрузка к системе Lawson, можно проследить при помощи нескольких отчетов реального времени:
- Отчет Overall (итоговый) (рисунок 10) показывает процент успешной загрузки страниц, элементов страниц и успешных точек верификации.
Рисунок 10. Итоговый отчет о производительности Overall performance report
- Отчет Response vs. Time Summary (Сводный по временам отклика) показывает, как происходили отклики от страниц, когда система находилась под нагрузкой. Стабильное поведение во временном диапазоне от 1500 до 3000 секунд означает, что в среднем отклики от страниц были получены приблизительно за 1,5 секунды, а от элементов страниц - за 0,1 секунды (рисунок 11).
Рисунок 11. Отчет о производительности Response vs. Time Summary
- Отчеты Page Throughput (Пропускная способность страниц) показывают изменение частоты успешных обращений с течением времени и изменением пользовательской нагрузки (диаграмма на рисунке 12 справа). В нашем примере пользовательская нагрузка возросла до 1000 пользователей, а стабильная загрузка продолжалась в диапазоне от 1500 секунд до 3000 секунд затраченного времени.
Рисунок 12. Отчет о производительности Page Throughput
