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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Есть BPM, сторонники которого отстаивают свои инструменты и технологии, и это все о функциях.

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

В первом случае компания покупает некоторое программное обеспечение.

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

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

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

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