Home

Oracle JDE Enterprise One

Автор: Дмитрий Демченко

В этой статье я продолжу описание инструментов тестирования ERP системы JD Edwards OneWorld. К моменту, когда я заканчивал писать статью, ERP систему успели переименовать несколько раз. Сейчас ее название Oracle JDE Enterprise One (Oracle JDE E1). В дальнейшем для краткости я буду называть ее ERP JD.

В этой статье речь пойдет о следующих инструментах:

• D. Edwards Virtual Script Editor — инструмент создания скриптов для «виртуальных» пользователей (для нагрузочного, стресс и тестирования производительности);
• J. D. Edwards VSMEditor —инструмент создания одного «виртуального» скрипта из нескольких.
• J. D. Edwards Virtual Runner — инструмент запуска скриптов, созданных в Virtual Script Editor(для нагрузочного, стресс- и тестирования производительности).

Virtual Script Editor

Итак, следующим в линейке инструментов тестирования является инструмент Virtual Script Editor или APEditor.

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

Как создается такая нагрузка? С помощью всего того, что делает компьютер, по команде пользователя, а именно запросов к базе данных, вывод результатов запроса в файл или на экран, вызовов и выполнения API функции, выполнении отчетов и пр., пр.

Всю работу пользователя, весь этот поток событий можно сохранить в ERP JD. Я писал в первой части статьи об инструментах, которые помогают сохранить этот поток событий. Это инструменты EventCaputre и AutoPilot.

В Vitrual Script Editor все потоки событий, сохраненные EventCaptureили AutoPilot можно посмотреть в хронологическом порядке.

Рисунок 1. Список потоков событий, на основе которых создаются скипты виртуальных пользователей

[ открыть крупнее ]

В этом списке указывается сквозной номер потока, имя клиента, на котором записывался поток событий, время начала выполнения, продолжительность выполнения скрипта или работы пользователя, окружение, версия ERP JD, имя скрипта AutoPilot, или имя результата записанного EventCaptur e.

В APEditor сохраненный поток событий, есть возможность посмотреть с помощью графа, на котором видна последовательность вызова событий по типам (запросы к БД, работа с контролами, вызов API, и т.д.).

Рисунок 2. Последовательность вызова событий

[ открыть крупнее ]

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

Кроме того, есть возможность посмотреть результат в виде графа идентификаторов потоков.

Рисунок 3. Еще один граф

[ открыть крупнее ]

Список потоков событий, созданных пользователем, можно отфильтровать, выборочно удалить.

Выбрав интересующий поток событий, он импортируется в Virtual Script Editor. Это тот материал, из которого Virtual Script Editor создает скрипты «вирутальных» пользователей.

Рисунок 4. Импортированный в Virtual Script Editor поток событий

[ открыть крупнее ]

Поток событий содержит следующую информацию

• Время начала, завершения и продолжительности события
• Идентификатор потока
• Идентификатор пользователя, вызвавшего событие
• Идентификатор запроса
• Уровень вызова
• Идентификатор сообщения
• Текст сообщение, детально описывающее событие (например, вызов функции открытия таблицы)

Текст сообщения для каждого события включает в себя аббревиатуру, которая определяет тип события. Встречаются следующие аббревиатуры:

JDB — Вызовы API функций обращения к БД (открытие таблицы, получения в курсор выборки данных, извлечение строки из выборки и т.п.)

RTE — Вызов API функций, обращения к объектам (вызов бизнес-функций).

EVR — Event Rule, функции, которые вызываются сразу после наступления определенных событий, например, нажатия кнопки

LOG — Предупреждения ( warning message)

ERR — сообщения об ошибках ( error message)

MSG — сообщения AutoPilot

AUT — действия с контролами (нажатие кнопки, заполнение полей ввода и пр.)

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

Рисунок 5. На правой панели значения параметров, с которыми вызывалась бизнес-функция

[ открыть крупнее ]

Кроме того, есть возможность посмотреть зависимость параметров между API функциями. Зачем?

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

Такое связывание событий гарантирует, что значение необходимого параметра будет передаваться в API функцию при её вызове, во время работы «виртуального» скрипта.

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

Virtual Script Editor позволяет связывать параметры и присваивать им значения как автоматически (то есть, когда значения будут формироваться по определенным правилам и передаваться в API функции, например, даты, номера заказов), так и вручную, когда тестировщик задает явные значения, которые должны передаваться во время работы виртуального скрипта.

В Virtual Script Editor длякакой-либо части потока событий есть возможность создать циклы, чтобы во время работы виртуального скрипта определенные запросы, вызов API-функций выполнялись несколько раз. При этом можно задать количество повторений, а также время, в течение которого определенный поток событий должен повторяться.

После того, как в Virtual ScriptEditor связаны API функции, заданы правила динамического изменения параметров и созданы правила, по которым определенный поток событий выполняется по некоторому циклу, можно создавать «виртуальный» скрипт нажатием кнопки [Generate].

Рисунок 6. Создать «виртуальный» скрипт

[ открыть крупнее ]

Если во время редактирования потоков событий какие-то событие были связаны неверно или были допущены другие ошибки, то после попытки сгенерировать «виртуальный» скрипт Virtual Script Editor выдаст сообщения об ошибках.

Рисунок 7. Ошибки при создании «виртуального» скрипта

[ открыть крупнее ]

Если же редактирование потоков событий было сделано без ошибок, то Virtual Script Editor сгенерирует «виртуальный» скрипт в определенном формате «.vsx». После этого его можно запускать.

Для запуска «виртального» скрипта в JD имеется специальный движок, Virtual Script Player, который можно запускать из командной строки, а также через Virtual Runner. О нем речь пойдет позже. А сейчас следующий инструмент

VSMEditor

Простой инструмент, который из нескольких «виртуальных» скриптов собирает один. Более о нем писать нечего. На рисунках 8 и 9 все видно.

Рисунок 8. VSMEditor - сборка скрипта

[ открыть крупнее ]

Следующий инструмент в линейке инструментов тестирования ERP JD Virtual Runner.

Virtual Runner

Virtual Runner является достаточно простым инструментом. С помощью его мастера задаются параметры для каждого виртуального пользователя — а именно: какое количество «виртуальных» скриптов он будет запускать, сколько раз будет повторяться каждый виртуальный скрипт. Также с помощью мастера можно задать порядок работы виртуальных пользователей, то есть будут они работать параллельно, или последовательно. Этот инструмент напоминает по функциональности Rational TestManager, в котором при создании Test Suite определяется порядок и правила запуска скриптов, или Контроллер в Mercury LoadRuuner. Virtual Runner имеет намного меньше возможностей, но зато он намного проще в работе. Все необходимое для нагрузочного тестирования в нем есть.

Рисунок 9. Virtual Runner

[ открыть крупнее ]

При выполнении скрипов в VirtualRuuner, для каждого вируального пользователя прописывается состояние, например: «начал работу», «инициализация в JD», «в процессе работы», «завершил работу» и т.п.

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

Рисунок 10. Лог-файл работы «виртуального» скрипта

[ открыть крупнее ]

На рисунке 10, видно, что «виртуальный» скрипт «отработал» с ошибками.

Напомню, что для запуска виртуального пользователя есть специальный движок Virtual Script Player. Virtual Runner создает столько экземпляров Virtual Script Player, сколько виртуальных пользователей было указано в мастере LoadRuuner.

Собственный опыт (в качестве завершения)

Передо мной была поставлена задача — провести стресс-тестирование сервера, на котором работала ERP JD. Один из аспектов тестирования — это проверить работу сервера при большом количестве одновременных подключений к базе данных и серверу приложений.

Для этого я создал модель, в которой сымитировал одновременную работу большого количества пользователей, выполняющих различную функциональность. У меня было сильное желание быстрее испытать Virtual Runner и после предварительной проверки на 3-5 виртуальных пользователях, я задал количество виртуальных пользователей 10 тысяч в мастере Virtual Runner. При этом, как выяснилось потом, каждый виртуальный пользователь потреблял около 3О Мб памяти. Поэтому, после того, как я нажал кнопку RUN (запустить тест), на тестовом компьютере мгновенно была занята вся память и активно включилась работа файла подкачки. Но, это не спасло тестовый компьютер. Он заблокировался, и мне пришлось его перегрузить.

После этого я рассчитал потребление ресурсов каждым виртуальным пользователем. Рассчитал потребности в ресурсах тестовой площадки. В итоге я проводил стресс-тестирование на площадке в два-три десятка компьютеров, на каждом из которых «работало» от 5 до 25 виртуальных пользователей. Общее число виртуальных пользователей было около 500. В итоге, с помощью этих инструментов тестирования ERP JD было успешно проведено тестирование – виртуальные скрипты, завершили свою работу, с мониторов сервера БД и сервера приложений были сняты показатели, которые потом анализировались администраторами системы.

На этом я завершаю краткий обзор инструментов тестирования ERP системы Oracle JDE Enterprise One.