È Unit Testing Adatto per BPM sviluppo?

Question

Al momento sto lavorando ad un grande progetto di BPM sul posto di lavoro che utilizza il Global 360 BPM tool-set chiamato Process 360. Giusto per dare qualche sfondo; questo prodotto funziona come un sacco di altre soluzioni BPM a che progettare più "mappe di processo" che definiscono il flusso di un particolare processo di business si sta cercando di modello e ogni mappa del processo è costituito da più nodi di attività collegati tra loro che svolgono funzioni particolari (chiamando servizi web, ecc).

Al momento stiamo sperimentando alcuni piuttosto gravi problemi durante le fasi di QA delle nostre uscite perché non c'è alcun modo fornita dal set di strumenti per automatizzare i test dei percorsi mappa del processo. Così, quando un processo ampio e complesso è sviluppato e consegnato al nostro team di test ci sono spesso un gran numero di problemi che affiorano. Mentre, ovviamente, ci si aspetterebbe alcuni problemi a venire fuori di QA, non posso fare la sensazione che un sacco di bug, ecc potrebbe essere stato avvistato durante lo sviluppo se abbiamo avuto qualche sorta di framework di test automatizzati che potremmo usare per costruire una serie di test di unità che si è rivelata vari percorsi nella mappa di processo (s).

Al momento l'unico test di sviluppo reale che si verifica è più simile a prove funzionali eseguita sviluppatori documentata come un insieme di operazioni manuali per test-case. Il problema con questo approccio è che è molto tempo per gli sviluppatori di eseguire manualmente, e per questo, è anche relativamente soggetto ad errori. Anche; perché siamo di solito su un programma piuttosto stretto, i test spesso non sono eseguiti spesso sufficiente per individuare i problemi in anticipo.

Come ho già detto in precedenza; Non c'è un modo fornita dalla corrente set di strumenti per eseguire questo tipo di test automatizzati. Che in realtà mi ha fatto pensare perché? Essendo molto nuovo per l'intera scena BPM mia ipotesi è stata che questo era solo una mancanza nel prodotto, ma mi chiedo anche se la "unit test" semplicemente non è fatto nel mondo BPM tradizionalmente? Forse semplicemente non è adatto bene a questo tipo di lavoro?

Sarei interessato a sapere se qualcun altro ha mai incontrato questo tipo di problemi, e anche quello che - se non altro -. Si può fare per migliorare le cose

Answer 1

Ho fatto il test "unità" con K2.net del 2003, un'altra BPM commerciale. Mi piacerebbe davvero chiamare questo test di integrazione, perché richiede un server di test ed è relativamente lento. Tuttavia, si è automatizzato.

C'è una buona discussione di questo nel libro professionale K2 blackpearl ( si applica a K2.net 2003 nonché).

Al fine di applicarlo alla vostra piattaforma, il set di strumenti deve avere un'API che permette di iniziare le istanze di processo, ottenendo elementi di lavoro, completando elementi di lavoro, ecc Si scrivono dei test utilizzando qualsiasi lingua supportata (io ho usato C #) e una framework di test (io ho usato NUnit). Se l'API supporta le chiamate sincrone, questo è più facile da fare. Per ogni test:

1. Avviare il processo in prova
2. Il progresso l'elemento di lavoro ad un punto di decisione
3. Imposta dati di istanza di processo in modo appropriato
4. Completare l'elemento di lavoro
5. affermare che l'elemento di lavoro è ora al di attività previsto
6. Elimina o completare l'istanza di processo

classi di test di base o di metodi di supporto possono rendere questo più facile. Si potrebbe anche scrivere un DSL per testare le mappe.

In sostanza si vuole piena "copertura di test" del processo / carta - verificare ogni punto di decisione e di assicurare che il ramo corretto è preso

.

Answer 2

Ho visto qualcosa a tale proposito, anche se non Global 360 associati: usando bpelunit per i processi di test

I sviluppare uno strumento di flusso di lavoro e v'è un aumento della domanda per l'apertura degli strumenti di prova utilizzati per testare il motore agli utenti finali.

Answer 3

Ci sono due aspetti di BPM che sono legati ma non identici.

C'è BPM che produttori di strumenti e la tecnologia sostengono che è tutto funzioni.

C'è anche BPM che Enterprise Architects avvocato per il quale è tutto di stabilire centri di eccellenza.

Il primo è quando una società acquista alcuni software.

Il secondo è quando una società fa i cambiamenti sistemici e inerenti al comportamento dei loro lavoratori IT.

Il primo si doveva essere al servizio di quest'ultimo, ma che non è necessariamente così. Acquisire la ex è necessaria ma non sufficiente per raggiungere quest'ultimo.

Non so quanto bene che Global 360 supporta ciò che è noto come Test Driven Development, ma JBoss jBPM fornisce alcune strumento di supporto per la scrittura facilmente test JUnit.

Tuttavia, lo strumento non può e non costringerà gli sviluppatori a scrivere loro o ad abbracciare i principi di TDD.