هل اختبار الوحدة مناسب لتطوير BPM؟

Question

أنا أعمل حاليًا على مشروع BPM كبير في العمل والذي يستخدم مجموعة أدوات 360 BPM Global التي تسمى Process 360. فقط لإعطاء بعض الخلفية ؛ يعمل هذا المنتج مثل الكثير من حلول BPM الأخرى من حيث تقوم بتصميم "خرائط العملية" المتعددة التي تحدد تدفق عملية تجارية معينة تحاول تصميمها ، وتتكون كل خريطة معالجة من عقد مهمة متعددة متصلة معًا والتي تؤدي وظائف معينة (استدعاء خدمات الويب وما إلى ذلك).

حاليًا نواجه بعض المشكلات الخطيرة خلال مراحل ضمان الجودة من إصداراتنا لأنه لا توجد طريقة يتم توفيرها من قبل مجموعة الأدوات لأتمتة اختبار طرق خريطة العملية. لذلك عندما يتم تطوير عملية كبيرة ومعقدة وتسليمها إلى فريق الاختبار لدينا ، غالبًا ما يكون هناك عدد كبير من المشكلات التي تظهر. بينما من الواضح أنك تتوقع بعض المشكلات التي ستخرج من ضمان الجودة ، لا يمكنني أن أساعد في الشعور بأن الكثير من الأخطاء وما إلى ذلك كان يمكن رصدها أثناء التطوير إذا كان لدينا نوع من إطار الاختبار الآلي والذي يمكننا استخدامه لبناء مجموعة من اختبارات الوحدة التي أثبتت الطرق المختلفة في خريطة (خريطة) العملية.

في الوقت الحالي ، يكون اختبار التطوير الحقيقي الوحيد الذي يحدث أقرب إلى الاختبارات الوظيفية التي يقوم بها المطورين التي تم توثيقها كمجموعة من الخطوات اليدوية لكل حالة اختبار. تكمن المشكلة في هذا النهج في أنه يستغرق وقتًا طويلاً للمطورين في الركض يدويًا ، ولهذا السبب ، هو أيضًا عرضة للخطأ نسبيًا. ايضا؛ نظرًا لأننا عادةً ما يكونون على جدول زمني ضيق للغاية ، فغالبًا ما لا يتم تنفيذ الاختبارات في كثير من الأحيان بما يكفي لتحديد المشكلات في وقت مبكر.

كما ذكرت سابقا؛ لا توجد طريقة توفرها مجموعة الأدوات الحالية لأداء هذا النوع من الاختبارات الآلية. ما الذي جعلني أفكر في الواقع لماذا؟ كونه جديدًا جدًا في مشهد BPM بأكمله ، كان افتراضي هو أن هذه كانت مجرد ميزة تفتقر إلى المنتج ، لكنني أتساءل أيضًا ما إذا كان "اختبار الوحدة" لم يتم في عالم BPM تقليديًا؟ ربما ليس من المناسب جيدًا لهذا النوع من العمل؟

سأكون مهتمًا بمعرفة ما إذا كان أي شخص آخر قد واجه هذه الأنواع من القضايا ، وأيضًا ما - إذا كان هناك أي شيء - يمكن القيام به لتحسين الأشياء.

Answer 1

لقد أجريت اختبار "الوحدة" مع K2.net 2003 ، BPM تجاري أخرى. سأسمي حقًا اختبار التكامل هذا ، لأنه يتطلب خادم اختبار وهو بطيء نسبيًا. ومع ذلك ، فهو آلي.

هناك مناقشة جيدة لهذا في الكتاب احترافية K2 Blackpearl (ينطبق على K2.net 2003 أيضًا).

لتطبيقه على النظام الأساسي الخاص بك ، يجب أن تحتوي مجموعة الأدوات على واجهة برمجة تطبيقات تسمح ببدء مثيلات العملية ، والحصول على عناصر العمل ، واستكمال عناصر العمل ، وما إلى ذلك. تكتب اختبارات باستخدام أي لغة مدعومة (اعتدت C#) وإطار اختبار ( لقد استخدمت نونيت). إذا كانت واجهة برمجة التطبيقات تدعم المكالمات المتزامنة ، فسيكون ذلك أسهل. لكل اختبار:

1. ابدأ العملية قيد الاختبار
2. تقدم عنصر العمل إلى نقطة قرار
3. تعيين بيانات مثيل العملية بشكل مناسب
4. أكمل عنصر العمل
5. تأكد من أن عنصر العمل هو الآن في النشاط المتوقع
6. حذف أو إكمال مثيل العملية

يمكن أن تجعل فئات الاختبار الأساسية أو أساليب المساعد أسهل. يمكنك حتى كتابة أ DSL لاختبار الخرائط.

في الأساس ، تريد "تغطية اختبار كاملة" للعملية/الخريطة - اختبار كل نقطة قرار وتأكد من اتخاذ الفرع الصحيح.

Answer 2

لقد رأيت شيئًا عن ذلك ، على الرغم من عدم وجود 360 عالميًا: باستخدام Bpelunit لعمليات الاختبار

أقوم بتطوير أداة سير العمل وهناك طلب متزايد على فتح أدوات الاختبار المستخدمة لاختبار المحرك للمستخدمين النهائيين.

Answer 3

هناك جانبان من BPM مرتبطان ولكنه غير متطابقان.

هناك BPM التي تدعو BPM وأدوات بائعي التكنولوجيا والتي تدور حول الميزات.

هناك أيضًا BPM الذي يدافع المهندسون المعماريون للمؤسسات التي تدور حول إنشاء مراكز للتميز.

السابق هو المكان الذي تشتري فيه شركة بعض البرامج.

هذا الأخير هو المكان الذي تقوم فيه الشركة بإجراء تغييرات منهجية ومتأصلة في سلوك عمال تكنولوجيا المعلومات.

من المفترض أن يكون الأول في خدمة الأخير ولكن هذا ليس بالضرورة. الحصول على الأول ضروري ولكنه لا يكفي لتحقيق هذا الأخير.

لا أعرف مدى جودة الدعم العالمي 360 ما يُعرف باسم التطوير الذي يحركه الاختبار ، لكن JBoss JBPM يقدم بعضًا دعم الأداة لسهولة كتابة اختبارات Junit.

ومع ذلك ، لا يمكن للأداة ولن تجبر المطورين على كتابتها أو احتضان مبادئ TDD.