Quando ha mantenuto il suo Oracle BRM (Billing and Revenue Management) per qualche tempo, inizia a rendersi conto che la quantità di entità configurate continua a crescere. A questo punto, è molto probabile che abbia anche sviluppato alcune personalizzazioni e si sia integrato con altre soluzioni. L'evoluzione del suo ambiente porta a un complesso cluster di oggetti intrecciati. Arriva il momento in cui lei, o il suo cliente, decide di cambiare qualcosa. La nuova funzionalità potrebbe sembrare facile da sviluppare all'inizio. La verità, tuttavia, è che molto probabilmente si scontrerà con una funzionalità esistente, o richiederà anche l'aggiornamento della configurazione esistente. Quello che sembrava un semplice cambiamento, si ripercuote poi sull'intero sistema. Questi eventi sono talvolta difficili da evitare, ma essere preparati può risparmiare molti problemi. Gli scenari di test funzionali e la versatilità dei test possono cambiare le carte in tavola.
Indice dei contenuti
Flusso di sviluppo continuo
Qui in Tridens, abbiamo stabilito un flusso di sviluppo continuo. Tutte le nostre configurazioni BRM, le personalizzazioni e gli altri componenti integrati sono adeguatamente versionati e tracciati su un sistema di controllo di versione distribuito (Git). Questa pratica consente ai nostri sviluppatori di controllare le versioni dei componenti necessari in qualsiasi momento e di iniziare il loro lavoro. Tutto va bene fino a questo punto, ma come possiamo affrontare la possibilità che nuove funzionalità interrompano la build attuale?
Abbiamo impostato un flusso di distribuzione e di test, che tiene traccia dei repository remoti delle nostre fonti. Di conseguenza, ogni volta che uno sviluppatore effettua un commit e spinge alcune modifiche al controllo di versione, questo avvia il processo di test. Il flusso di distribuzione costruisce immagini docker per tutti i componenti rilevanti con le loro ultime versioni su un ambiente locale (o remoto), e vengono eseguiti test automatizzati per garantire che la build sia stabile. Solo quando i test hanno successo, possiamo rilasciare le nuove versioni in produzione. Questo processo ci aiuta a garantire che le nuove funzionalità funzionino perfettamente con quelle esistenti. I test eseguiti fanno parte dell'Oracle BRM TestToolkit, che abbiamo sviluppato. Il BRM TestToolkit ha fasi e scenari predefiniti con codice di background glue. Le fasi sono molto descrittive e facili da usare, consentendo ai nostri sviluppatori o a qualsiasi altro utente di scrivere rapidamente nuovi scenari di test. Trovi un esempio di scenari di test nell'immagine sottostante.
TestToolkit BRM per i test automatizzati
Ciò che è iniziato come semplici scenari di test per la creazione di un conto e l'acquisto di un prodotto, rappresenta oggi il mainframe del nostro test BRM TestToolkit. Per chiarire, ora abbiamo diversi casi di test e scenari marginali per garantire la massima copertura delle funzionalità implementate. I test automatizzati consentono ai nostri sviluppatori di concentrarsi sul compito da svolgere e di non spendere grandi quantità di tempo per i test manuali. Naturalmente, a volte ci troviamo a sviluppare una nuova funzionalità non ancora coperta dagli scenari di test. In questi casi, le definizioni delle fasi di test e il relativo codice di base vengono implementati come parte di quella funzionalità - per essere utilizzati anche in futuro.
Il TestToolkit può comunicare con diversi componenti, consentendo la possibilità di regolazioni rapide anche per altri sistemi. Utilizziamo anche versioni ridisegnate del TestToolkit BRM per gli altri componenti. Una delle ultime caratteristiche che abbiamo aggiunto è la modularità, dove gli sviluppatori possono etichettare diversi scenari di test come parti di un gruppo. Ogni gruppo ha poi i suoi script e la sua logica separata, consentendo, se lo si desidera, di eseguire solo un numero specifico di test alla volta e in parallelo. Inoltre, la modularità ci permette di separare i test di valutazione prepagata da quelli di valutazione postpagata o i test di acquisto di addon da quelli di acquisti vari. Può vedere il flusso di test nell'immagine sottostante.
Copertura dello scenario di test
Il TestToolkit BRM comunica con la nostra API, che abbiamo integrato con Oracle BRM per semplificare le operazioni più complesse. Il TestToolkit può anche interagire con l'API di BRM RestBridgeLa nostra soluzione wrapper BRM, che facilita la comunicazione con BRM consentendo l'uso del formato JSON o XML tramite un'API REST. Le definizioni delle fasi di test supportano, tra le tante, le seguenti operazioni:
- Creazione e gestione dell'account
- Acquisto di transazioni e altre operazioni di transazione
- Recupero e controllo della bilancia
- Generazione di traffico - Eventi di utilizzo
- Chiamate API
- Caduta del CDR
- strumenti di traffico in tempo reale (protocollo diameter)
- Controlli di valutazione
- Il TestToolkit BRM confronta i diversi eventi di utilizzo e gli acquisti con i valori previsti
- ogni piano o prodotto diverso può avere il proprio set di file di valutazione, assicurando la versatilità in configurazioni di prodotto complesse
Componendo le fasi di test facili da usare, ogni sviluppatore può scrivere gli scenari per la funzionalità in fase di sviluppo. In molti casi, i nostri sviluppatori scelgono di impostare gli scenari di test in anticipo, prima di sviluppare la funzione. La preparazione degli scenari in anticipo segue il modello Behaviour Driven Development (BDD). BDD significa essenzialmente che gli scenari dettano il flusso di sviluppo e devono esistere in anticipo. Questi scenari descrivono il comportamento del sistema e gli sviluppatori devono sviluppare nuove funzionalità in modo da adattarle a questi scenari. Possiamo eseguire ogni test-scenario separatamente, ottenendo un report in un formato specifico. Di seguito è riportato un esempio di rapporto HTML.
Segnalazione
Quando il sistema esegue i test-scenari come parte di una nuova build di sviluppo, di solito li esegue nel loro pieno potenziale, compresi tutti i test. Da un ambiente all'altro, questo può richiedere un po' di tempo, ma fornisce un quadro generale di come la nuova funzionalità possa aver influenzato le altre implementazioni esistenti. Possiamo valutare la stabilità della build dal rapporto di test, che il TestToolkit BRM genera al termine di un'esecuzione di test. I rapporti di prova contengono dettagli per ogni scenario di prova, ma forniscono anche alcune statistiche e analisi su tutti i test in generale. Possiamo utilizzare questa analisi per trovare le differenze tra le build e per assicurarci che una build funzioni correttamente. Veda un esempio di report qui sotto.
Conclusione
La giusta soluzione di test può far risparmiare moltissimo tempo ed evitare che si verifichino bug inutili. Pertanto, se sta lottando con le difficoltà menzionate in questo articolo, o se è interessato al nostro Toolkit BRM di test, non esiti a contattarci. Saremo lieti di illustrarle la nostra soluzione e di elaborare un piano ottimale per migliorare il suo flusso di distribuzione e di test.
