Содержание


Методология тестирования IBM Business Process Manager

Часть 2. Среды и методы тестирования

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

Этот контент является частью # из серии # статей: Методология тестирования IBM Business Process Manager

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

Этот контент является частью серии:Методология тестирования IBM Business Process Manager

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

Это руководство является второй частью серии статей «Методология тестирования IBM Business Process Manager». В первой части обсуждались общие принципы тестирования проектов IBM Business Process Manager (BPM). В данном руководстве более подробно описываются методы тестирования и среды IBM BPM, используемые для выполнения различных тестов.

Среды

IBM BPM — это всеобъемлющая платформа для управления бизнес-процессами, обеспечивающая полную прозрачность и понимание. Она предоставляет инструментарий и среду для проектирования, выполнения, мониторинга и оптимизации процессов, а также базовую поддержку интеграции систем.

IBM BPM включает единый репозиторий, инструменты для разработчиков, администраторов и пользователей, а также платформу для исполнения. IBM BPM можно конфигурировать для поддержки различных уровней сложности бизнес-процессов и участия в управлении ими. На рисунке 1 показана типичная конфигурация IBM Business Process Manager.

Рисунок 1. Типичная конфигурация IBM BPM
Типичная конфигурация IBM BPM
Типичная конфигурация IBM BPM

На рисунке 1 показаны четыре среды IBM BPM — Process Center (разработка) и среды подготовки, тестирования и эксплуатации. Рекомендуется настраивать разные среды для разных пользователей и разных задач. Безусловно, возможны варианты. Например, в связи с ограниченностью ресурсов можно обойтись без среды тестирования, а для функционального, нефункционального и регрессионного тестирования использовать среду подготовки. Или, наоборот, можно настроить несколько сред тестирования, если параллельно выполняются различные проекты IBM BPM.

Таблица 1. Среды IBM BPM
ИдентификаторСреды IBM BPMПредполагаемые пользователиПредполагаемые методы использования
1 Проектирование:
среда разработки в Process Center
Разработчики Централизованный репозиторий и модульное тестирование
2 Исполнение:
среда тестирования на Process Server
Специалисты по тестированию группы обеспечения качества Интеграционное тестирование
3 Исполнение:
среда подготовки на Process Server
Специалисты по приемочным испытаниям и тестированию производительности Приемочные испытания, нефункциональное тестирование, регрессионное тестирование
4 Исполнение:
среда эксплуатации на Process Server
Бизнес-пользователи и другие конечные пользователи Среда исполнения для всех конечных пользователей

Методы тестирования

Тестирование проекта IBM BPM, как и любого другого программного обеспечения, включает применение множества различных методов. Однако IBM BPM имеет свои собственные, специфические методы тестирования. В таблице 2 перечислены методы тестирования в проектах IBM BPM.

Таблица 2. Методы тестирования проектов IBM BPM
Тестирование проектов IBM BPMМетоды тестирования
Функциональное тестирование Модульное тестирование, интеграционное тестирование, приемочные испытания, тестирование миграции экземпляров, тестирование глобализации, тестирование использования мобильных технологий и браузеров
Нефункциональное тестирование Тестирование производительности, тестирование высокой готовности, тестирование аварийного восстановления, тестирование стабильности, стрессовое тестирование, тестирование надежности и тестирование безопасности
Регрессионное тестирование Конкретные методы тестирования зависят от применяемых исправлений. Используются некоторые из перечисленных методов функционального и нефункционального тестирования.

Модульное тестирование

В программном обеспечении модуль является наименьшим конструктивным блоком кода, на основе которого можно создавать другой код. В проектах IBM BPM модульное тестирование — это проверка разработчиком отдельных компонентов конкретного приложения процесса перед созданием снимков. Например, модулем может быть пользовательский интерфейс или общий системный сервис.

При модульном тестировании в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Тестирование выполняется разработчиками в инструменте IBM Process Designer, подключенном к среде Process Center. Разработчики могут изучать результаты в отладчике двумя способами:
    • The с помощью Process Inspector в Process Designer;
    • путем воспроизведения в Process Designer.
  • Для каждого модуля должен существовать модульный тест (или испытательная программа), и каждое тестирование должно включать следующие пути:
    • «хороший», когда все работает так, как ожидалось;
    • «плохой», когда нечто ожидаемым образом не работает;
    • «опасный», путь к системному отказу.
  • Для тестирования пользовательских интерфейсов достаточно создать испытательную программу для их проверки независимо от других модулей.
  • Для тестирования общих системных сервисов разработчики могут создавать автоматизированные тесты, обеспечивающие ожидаемые результаты.
  • По возможности создавайте имитирующие сервисы для тестирования внешних конечных систем.

Интеграционное тестирование

После модульного тестирования и воспроизведения, как правило, выполняются интеграционные тесты. Такие тесты проверяют не только отдельные блоки работы, но и весь процесс, в том числе системы, которые являются внешними для проекта IBM BPM.

При интеграционном тестировании в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Тестируйте пути для всего снимка приложения процесса с использованием согласованных сценариев и наборов данных (good, bad и ugly).
  • Проводите интеграционное тестирование в среде тестирования на Process Server. Некоторые функции, например, запланированные скрытые агенты, могут выполняться только на серверах Process Server. Кроме того, управление некоторыми приложениями процессов и их поведение в Process Center и Process Server различаются между собой. Например, в Process Center снимок приложения процесса по умолчанию предлагается как подсказка по умолчанию, а на сервере Process Server необходимо задать конкретный снимок, который будет снимком по умолчанию. Поэтому не используйте Process Center для выполнения интеграционного тестирования. Обязательно выберите среду Process Server.
  • Многие процессы включают долго выполняемые пути и таймеры. Для тестирования таких процессов необходим специальный подход: используйте в настройках таймера пользовательские даты с переменными для значений, чтобы сделать возможным тестирование с ускоренным таймером. Это позволит в ходе тестирования корректировать таймеры по скользящей шкале, чтобы процесс, который обычно занимает 80 дней, можно было протестировать за 8 дней. При тестировании разделите все значения времени на 10.
  • Не забудьте включить интеграционные тесты для Process Portal и взаимодействий конечных пользователей.
  • Определите, как вы хотите выполнять интеграционные тесты — вручную или с применением инструмента автоматизации.
  • Для ручного тестирования непрерывной интеграции визуально проверяйте пользовательские интерфейсы на соответствие требованиям.
  • Используйте как минимум следующие три набора данных в качестве модульных тестов для интеграционного тестирования:
    • с ожидаемым успешным результатом конкретного сценария процесса (happy path);
    • с ожидаемым результатом в виде исключительной ситуации (unhappy path).
    • с ожидаемым результатом в виде системного отказа (ugly path).

Приемочные испытания

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

Для приемочных испытаний проекта IBM BPM воспользуйтесь следующими рекомендациями:

  • Проводите приемочные испытания в среде подготовки на Process Server. Функциональное приемочное испытание выполняется после развертывания снимка конкретного приложения процесса в среде подготовки на Process Server.
  • Убедитесь в том, что физические пользователи тестируют пути для всего снимка приложения процесса с использованием согласованных сценариев и наборов данных. Обеспечьте выполнение следующих требований:
    • эксперты в предметных областях несут ответственность за качество конкретных областей;
    • учтены потребности в снижении рисков.
  • При необходимости замените физических пользователей инструментом автоматизированного тестирования.
  • Научитесь корректно устанавливать приоритеты дефектов.
  • Попросите спонсора проекта проверить приоритеты дефектов для количественной оценки.

Тестирование миграции экземпляра

При установке снимков на Process Server продумайте, как обрабатывать выполняемые на сервере экземпляры определений бизнес-процессов из предыдущих снимков. Можно перенести работающие экземпляры в новый снимок и предусмотреть обработку потерянных маркеров или оставить эти работающие экземпляры в старом снимке.

При тестировании миграции экземпляра в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Выполняйте тестирование миграции экземпляра в средах тестирования и подготовки на Process Server.
  • Получите список изменений в приложении от вашей группы по разработке приложений.
  • Убедитесь в том, что в средах тестирования и подготовки на Process Server есть хорошее представление экземпляров процесса в различных состояниях. Затем можно выполнить миграцию экземпляра и провести тестирование.
  • На случай потери маркеров убедитесь в том, что у вас есть файл действующей политики обработки маркеров, соответствующий требованиям бизнеса.
  • Подготовьте план регрессионного тестирования для приложения, которое предстоит переносить.
  • Если вы решите оставить экземпляры в старом снимке, также убедитесь в том, что есть хорошее представление экземпляров процесса в разных состояниях. Это позволит гарантировать успешное выполнение всех экземпляров в старом снимке после того как новый снимок будет развернут и сделан снимком по умолчанию.

Тестирование производительности

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

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

  • Применяйте общесистемный подход к настройке производительности. Настройка должна охватывать следующие элементы топологии развертывания:
    • выбор топологии физического оборудования;
    • параметры операционной системы;
    • настройки сервера IBM BPM, сервера приложений IBM WebSphere Application Server, базы данных и механизма обработки сообщений.
  • Определите возможные причины снижения производительности и внесите изменения в настройки для их исключения. Не упускайте ранние признаки проблем с производительностью, например, связанных с интеграцией с другими системами, масштабированием репозитория Lightweight Directory Access Protocol (LDAP) и мощностью системы управления базами данных.
  • Выявите проблемы с необходимыми зависимостями и внесите изменения для их устранения, например, настройте сжатие передаваемых по сети данных для предотвращения сетевых задержек.
  • Установите приоритет сетевого трафика Process Server, задав соответствующие правила для маршрутизаторов, балансировщиков нагрузок и межсетевых экранов.
  • Собирайте администраторов базы данных, операционной системы и IBM BPM на одной странице при нагрузочном тестировании и тестировании производительности. Работайте с проектировщиками приложений для понимания потребностей в ресурсах.

Перед началом тестирования производительности примите во внимание следующие советы, основывающиеся на опыте нашей группы:

  • Знайте свои показатели.
  • Установите цели.
  • Будьте в курсе изменений.
  • Выделите достаточное количество времени.
  • Моделируйте реальные сценарии как можно лучше.
  • Можно состарить базу данных для моделирования долго выполняемых сред.
  • Учтите, что при старении базы данных производительность может снизиться.
  • Отслеживайте результаты.

При тестировании производительности в проекте IBM BPM применяйте следующий подход:

  1. Определите четкие цели производительности в соответствии с требованиями бизнеса, например:
    Обновление списка задач в Process Portal должно занимать не более 3 секунд с использованием IE 9 с сетевой задержкой в 100 миллисекунд между Process Portal и Process Server.
  2. После установки уровня продукта и развертывания приложения процесса определите базовые значения, например:

    Обновление списка задач в Process Portal должно занимать 10 секунд с использованием IE 9 с сетевой задержкой в 100 миллисекунд между Process Portal и Process Server.

  3. Выберите приемлемый набор первоначальных настроек параметров.
  4. Настройте среду в соответствии с лучшими методиками.
  5. Отслеживайте работающие системы для поддержки настройки в будущем.
  6. При каждом развертывании нового приложения процесса выполняйте действия 1–5.
  7. Для каждого нового снимка выполняйте действия 4 и 5.
  8. Изолируйте неконтролируемые приложения, выполняя действия 4–5.

Кроме того, при выполнении тестирования производительности пользуйтесь следующими рекомендациями:

  • Выполняйте тестирование производительности в среде подготовки на Process Server, которая является практически клоном рабочей среды, включая использование смоделированных производственных данных и соответствующее конфигурирование безопасности.
  • Не проводите измерения сразу после запуска теста, подождите некоторое время, пока среда «разогреется».
  • Проектируйте надежные, удобные в выполнении рабочие нагрузки, производящие повторяемые результаты.
  • Выполнять тесты производительности вручную нецелесообразно, необходимы инструменты автоматизированного тестирования.
  • Примите во внимание следующие советы в отношении нагрузок для тестирования производительности:
    • Используйте реалистичное время на размышление между запросами.
    • Поддерживайте стабильное поступление работ в систему. Например, не следует помещать 20 тыс. входящих запросов в очередь Java Message Service и затем запускать систему. Реализуйте управлением потоком для входящих запросов.
    • Поддерживайте в базах данных устойчивое состояние — постоянное количество активных и завершенных задач и экземпляров.
    • После выполнения теста производительности очистите среду, в особенности запросы и базы данных.
  • Проверьте наличие сообщений об ошибках, исключительных ситуациях и превышениях времени ожидания в журналах и отчетах.

Стрессовое тестирование

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

При стрессовом тестировании в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Выполняйте стрессовое тестирование в среде подготовки на Process Server.
  • Измеряйте в стрессовом тесте следующие показатели:
    • количество одновременных пользователей;
    • нагрузка экземпляров;
    • нагрузка задач.
  • Стрессовые тесты призваны оценить производительность системы IBM BPM при текущей конфигурации оборудования и программного обеспечения. Используя результаты тестирования, администраторы приложений и систем могут понять, нужно ли улучшить конфигурацию оборудования и программного обеспечения в соответствии с будущими потребностями.
  • Можно выполнять тестирование с превышением пиковой нагрузки для определения будущих потребностей в случае непредвиденно высокой нагрузки. Изучите узкие места и возможные ограничения в следующих ресурсах: операционной системе, базе данных, виртуальной машине Java или в продукте.

Тестирование надежности

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

При тестировании надежности в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Выполняйте тестирование надежности в среде подготовки на Process Server.
  • Для тестирования надежности проверьте, как работает система после длительного периода использования.
  • Чтобы моделировать месяцы использования, не выполняя тесты в течение месяцев, применяйте следующий подход:
    • Оцените, сколько процессов и задач будут создаваться и закрываться в течение недели. Подсчитайте их количество за месяц и за год. Затем выполните соответствующие действия, но за более короткий период времени.
    • Для исключения сбоев, связанных с нагрузкой, убедитесь в том, что эти операции выполняются аналогичным образом и не превышаются пиковые показатели, использовавшиеся при нагрузочном тестировании.
  • Обратите внимание, не снижается ли производительность базы данных в связи с накоплением данных, нехваткой пространства и любыми проблемами с памятью Java Virtual Machine.
  • Проанализируйте увеличение объемов файловой системы и базы данных, чтобы определить потребности в операциях обслуживания или настройке.
  • Обратите внимание, не повышается ли использование оперативной памяти выше базового уровня, что может приводить к проблемам.
  • Тестирование надежности помогает выявлять области, которые могут требовать регулярного обслуживания.
  • Тестирование надежности позволяет выявлять проблемы с приложением, которые возникают только после работы в течение длительного периода времени.
  • Отслеживание влияния работы в течение месяца, двух месяцев и трех месяцев может быть полезно для прогнозирования последствий работы в течение более длительных периодов времени.
  • Проверьте влияние на среду новых приложений, добавляя новые приложения и внося системные изменения, оказывающие влияние на общую картину.

Тестирование высокой готовности

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

При тестировании высокой готовности в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Выполняйте тестирование высокой готовности в среде подготовки на Process Server.
  • Используйте следующие четыре типа сценариев тестирования:
    • тестирование аварийного восстановления, которое моделирует отказ сервера при выполнении стрессового тестирования;
    • контролируемое отключение сервера (например, с использованием административной консоли);
    • мгновенное отключение элементов кластера (например, путем завершения связанного системного процесса);
    • неконтролируемое отключение всей поддерживающей системы (например, в результате сбоя в энергоснабжении).
  • Рассмотрите следующие категории сценариев тестирования:
    • сценарии тестирования методом белого ящика, которые приостанавливают систему в важной точке и инициируют событие отказа;
    • сценарии тестирования методом черного ящика, которые инициируют событие отказа при выполнении стрессового тестирования.
  • Проверьте:
    • выполняется ли автоматическое восстановление после сбоя в течение заданного периода времени;
    • сохраняется ли целостность транзакций.
  • Клиенты IBM BPM обычно сосредоточивают свои усилия по тестированию высокой готовности на следующих типах тестов:
    • базовое тестирование конфигурации;
    • операционные процедуры, необходимые для аварийного восстановления;
    • ограниченное тестирование методом черного ящика.

Тестирование аварийного восстановления

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

При тестировании аварийного восстановления в проекте IBM BPM воспользуйтесь следующими рекомендациями:

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

Тестирование безопасности

Тестирование безопасности следует выполнять в соответствии с основными принципами обеспечения безопасности в вашей организации.

При тестировании безопасности в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Понимайте различия в настройках безопасности в разных средах IBM BPM (тестирование, подготовка и эксплуатация).
  • Убедитесь в том, что конфигурация безопасности в среде подготовки идентична конфигурации безопасности в рабочей среде или очень похожа на нее.
  • Убедитесь в том, что тестирование безопасности охватывает все элементы инфраструктуры, включая защиту систем, защиту IBM WebSphere Application Server и защиту IBM BPM.
  • Проверяйте требования к защите конкретных приложений - например, когда только определенные пользователи могут изменять конкретные задачи в связи с принадлежностью задач.
  • Выполняйте функциональное и нефункциональное тестирование только после конфигурирования всех базовых настроек безопасности, таких как:
    • запрет незащищенного HTTP-доступа;
    • конфигурирование сторонних средств аутентификации для защиты инфраструктуры IBM BPM.
  • Определите небольшой набор функциональных тестов для повторного выполнения после изменений конфигурации безопасности, в особенности для таких регулярных действий, как:
    • изменение пароля администратора;
    • изменение паролей пользователей базы данных.

Эксплуатационное и регрессионное тестирование

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

При регрессионном тестировании в проекте IBM BPM воспользуйтесь следующими рекомендациями:

  • Выполняйте эксплуатационное и регрессионное тестирование во всех четырех средах — в среде разработки в Process Center, в среде тестирования в Process Server, в среде подготовки в Process Server и в рабочей среде в Process Server.
  • Перед тем как применять пакеты исправлений, выясните, какие вносятся исправления.
  • Выполняйте резервное копирование системы (профили, база данных) перед применением пакетов исправлений или промежуточных исправлений.
  • Создайте набор сценариев регрессионного тестирования для приложений и инфраструктуры, чтобы можно было протестировать систему после применения исправлений.

Тестирование с учетом изменений в средах развертывания

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

Перенося приложение в среды развертывания, обращайте внимание на следующее:

  • Понимайте и документируйте различия в средах развертывания.
  • Разные среды могут иметь разные конфигурации безопасности и разные периферийные системы.
    • Среды разработки обычно имеют слабый уровень безопасности.
    • Среды подготовки не полностью моделируют рабочую инфраструктуру.
    • Разные среды имеют разные масштабы и фильтры групп LDAP.
  • Будьте готовы к возникновению проблем при переходе от сред тестирования к средам подготовки и рабочим средам, например, если:
    • специалисты по тестированию забывают изменить привязку ролей;
    • специалисты по тестированию забывают изменить URL WSDL и конечную систему для web-сервиса;
    • специалисты по тестированию забывают изменить временной интервал.
  • Зафиксируйте детальные этапы изменений при переходе от сред тестирования к средам подготовки и рабочим средам.
  • Создайте набор сценариев регрессионного тестирования для проверки применения изменений к приложению IBM BPM после его развертывания в различных средах.

Заключение

Данное руководство является второй частью серии статей «Методология тестирования IBM Business Process Manager». В нем описаны среды и методы тестирования IBM BPM.

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

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

Авторы хотели бы поблагодарить за рецензирование руководства и участие в его подготовке Дона Акуханна (Dawn Akuhanna), Дэвида Буза (David Booz), Тодда Дина (Todd R Deen), Мэттью Лучковяка (Matthew S Luczkowiak), Паскаля Вагнера (Pascal Wagner), Дэна Эйкхолта (Dan Eykholt), Вэймина Гу (Weiming Gu), Криса Ричардсона (Chris Richardson) и Эккехарда Фёша (Ekkehard Voesch).


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


Похожие темы

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=1012327
ArticleTitle=Методология тестирования IBM Business Process Manager: Часть 2. Среды и методы тестирования
publish-date=08032015