Подходит ли модульное тестирование для разработки BPM?

Question

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

В настоящее время мы сталкиваемся с некоторыми довольно серьезными проблемами на этапах контроля качества наших выпусков, потому что набор инструментов не предоставляет никакого способа автоматизировать тестирование маршрутов process map.Поэтому, когда разрабатывается большой и сложный процесс и передается нашей команде тестирования, часто возникает большое количество проблем.Хотя, очевидно, вы ожидали бы некоторые проблемы, возникающие в области контроля качества, я не могу избавиться от ощущения, что многие ошибки и т.д. Могли бы быть обнаружены во время разработки, если бы у нас была какая-то платформа автоматизированного тестирования, которую мы могли бы использовать для создания набора модульных тестов, которые подтверждали различные маршруты в карте (картах) процессов.

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

Как я упоминал ранее;текущий набор инструментов не позволяет выполнять такого рода автоматическое тестирование.Что на самом деле заставило меня задуматься, почему?Будучи новичком во всей сфере BPM, я предположил, что это просто функция, которой не хватает в продукте, но мне также интересно, просто ли "модульное тестирование" не проводится в мире BPM традиционно?Может быть, он просто плохо подходит для такого рода работы?

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

Answer 1

Я провел "модульное" тестирование с K2.net 2003, другим коммерческим BPM.Я бы действительно назвал это интеграционным тестированием, потому что для этого требуется тестовый сервер, и оно относительно медленное.Однако это автоматизировано.

В книге есть хорошее обсуждение этого вопроса Профессиональный K2 blackpearl (это относится и к K2.net 2003 году).

Чтобы применить его к вашей платформе, набор инструментов должен иметь API, который позволяет запускать экземпляры процесса, получать рабочие элементы, завершать рабочие элементы и т.д.Вы пишете тесты, используя любой поддерживаемый язык (я использовал C #) и платформу тестирования (я использовал NUnit).Если API поддерживает синхронные вызовы, это сделать проще.Для каждого теста:

1. Запустите тестируемый процесс
2. Продвиньте рабочий элемент к моменту принятия решения
3. Установите данные экземпляра процесса соответствующим образом
4. Завершите рабочий элемент
5. Подтвердите, что рабочий элемент теперь выполняет ожидаемую операцию
6. Удалите или завершите экземпляр процесса

Базовые тестовые классы или вспомогательные методы могут упростить это.Вы могли бы даже написать DSL для тестирования карт.

По сути, вы хотите получить полное "тестовое покрытие" процесса / карты - протестируйте каждую точку принятия решения и убедитесь, что выбрана правильная ветвь.

Answer 2

Я видел кое-что по этому поводу, хотя и не связанное с Global 360 : использование bpelunit для процессов тестирования

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

Answer 3

Есть два аспекта BPM, которые взаимосвязаны, но не идентичны.

Существует BPM, за который выступают поставщики инструментов и технологий, и все дело в функциях.

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

Первый - это когда компания покупает какое-то программное обеспечение.

Последнее - это когда компания вносит системные и неотъемлемые изменения в поведение своих ИТ-работников.

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

Я не знаю, насколько хорошо Global 360 поддерживает так называемую разработку, основанную на тестировании, но JBoss jBPM предоставляет некоторые поддержка инструмента для простого написания тестов JUnit.

Однако инструмент не может и не будет заставлять разработчиков писать их или применять принципы TDD.