Software per schedulazione e simulazione di No Regression Test

Studente proponente

s282318 Olivero Federico

Titolo della proposta

Software per schedulazione e simulazione di No Regression Test

Descrizione del problema proposto

Il software si propone di risolvere un problema reale riscontrato durante lo svolgimento del tirocinio in azienda. L'attività (chiamata Correttiva) prevede l'esecuzione di No Regression Test da lanciare su diverse macchine virtuali, periodicamente (una volta a settimana) in un arco di tempo ben preciso, che hanno come obiettivo il testing funzionale di un applicativo client-server di un'azienda che opera in campo assicurativo. Durante le settimane è stata riscontrata un'elevata instabilità nello svolgimento dei test (dovuta a diversi fattori, quali l'instabilità dell'applicativo, degli script, ed altri) che talvolta ha come conseguenza il mancato svolgimento di tutti i test nell'arco di tempo previsto. Il software propone la risoluzione di questi problemi tramite l'ottimizzazione della schedulazione dei test, e una simulazione di eventi che permette di avere una panoramica generale della Correttiva nei giorni precedenti, per permettere agli sviluppatori/tester di apportare le modifiche necessarie per raggiungere la stabilità richiesta.

Descrizione della rilevanza gestionale del problema

I problemi che il software intende risolvere hanno rilevanza gestionale, in quanto consistono in problemi di ottimizzazione e schedulazione, concetti inerenti alla ricerca operativa e alla progettazione/gestione di sistemi aziendali. Inoltre, la simulazione di eventi che il software andrà a svolgere dipenderà da alcuni parametri in ingresso che un ipotetico Ingegnere Gestionale potrà impostare: al variare dei parametri in ingresso la simulazione produrrà diversi risultati, che potranno essere analizzati per decidere come agire sul progetto per ottimizzarlo.

Descrizione dei data-set per la valutazione

I dati per lo svolgimento del progetto sono stati raccolti nel contesto aziendale, sotto forma di numerosi file csv. Il database utilizzato nel progetto è stato da me costruito, dopo una generale "pulizia" dei file, eliminando eventuali incongruenze e raccogliendo i dati dell'esecuzione dei vari test durante le Correttive degli anni passati.

Il dataset contiene informazioni sui diversi test e le sue esecuzioni nel tempo: ogni test, detto Istanza, appartiene a una specifica compagnia, prevede un determinato scenario assicurativo (ad esempio Emissione o Riscatto di una polizza) ed è eseguito su un determinato prodotto. Per ogni test sono state raccolte tutte le esecuzioni negli anni passati, sulle diverse macchine virtuali.

Il database si suddivide in 3 tabelle:

Tabella 1: Macchine virtuali
- Questa tabella contiene le informazioni sulle specifiche delle diverse macchine virtuali, necessarie allo svolgimento dei test
Tabella 2: Istanze
- Questa tabella contiene le informazioni su oltre 50 istanze. Ogni istanza ha Id, Scenario, Compagnia, Prodotto e talvolta un informazione aggiuntiva per distinguere due istanze con stesso scenario, compagnia e prodotto.
Tabella 3: Esecuzioni
- Questa tabella contiene tutte le informazioni sulle varie esecuzioni di ogni istanza negli ultimi anni. Ogni esecuzione di un'istanza è stata svolta su una determinata macchina virtuale in una certa data e in un preciso orario, ha una durata, uno stato (successo o fallimento) e un numero di errori e warnings.

Nota: per motivi di privacy alcuni dati, come nome delle compagnie e dei prodotti, sono stati cifrati. Questo non impatta in alcun modo la realisticità del progetto.

Descrizione preliminare degli algoritmi coinvolti

Il progetto prevede l'implementazione di 2 principali algoritmi:

Nel primo caso si tratta di un algoritmo ricorsivo, che ha come obiettivo l'ottimizzazione della schedulazione delle varie istanze. Ricordando che uno dei problemi principali che il software mira a risolvere è l'esecuzione di tutti i test all'interno dell'arco di tempo previsto, l'algoritmo prenderà infatti in input una lista contenente tutte le istanze previste (=test da svolgere) e determinerà su quale macchina virtuale il test in questione va lanciato, in modo da minimizzare la massima durata dei test su singola macchina: se infatti la macchina che ci impiegherà più tempo a svolgere tutti i test che le sono stati "assegnati" riesce a rimanere nell'arco di tempo predeterminato, l'obiettivo risulta essere raggiunto. L'algoritmo terrà in considerazione determinati fattori, quali:
- conflitto tra determinate istanze se eseguite in parallelo (sovrapposizione temporale delle esecuzioni) in diversi casi (predeterminati), come istanze con stesso prodotto, istanze con stesso scenario e compagnia, ecc..
- condizioni di stabilità impostate prima di effettuare la simulazione: i parametri impostati dall'utente determineranno una particolare situazione di instabilità, che si può tradurre nell'implementazione di ulteriori specifici vincoli. Esempio: una situazione particolarmente instabile può essere dovuta alle critiche condizioni pre-correttiva; infatti alcune istanze possono essere eseguite soltanto se nella cartella condivisa sono presenti file emessi tramite l'esecuzione di alcune precise istanze (è il caso dei Riscatti che necessitano di file emessi dalle Emissioni).
Nel secondo caso si tratta di un algoritmo di simulazione di eventi, che data la schedulazione fornita dall'algoritmo al punto 1, si occupa di simulare lo svolgimento della correttiva, ritornando tutti gli eventi in ordine temporale dall'orario di inizio della correttiva fino all'orario di fine. Gli eventi principali sono 3:
- Inizio esecuzione: prevede l'inizio dell'esecuzione dell'istanza in questione, determinando in base alle condizioni di stabilità/instabilità impostate dall'utente se il test avrà successo o meno, schedulando l'evento. I parametri impostati dall'utente verranno elaborati e convertiti in probabilità di successo o fallimento del test.
- Successo esecuzione: prevede il caso in cui l'evento al punto 1 abbia previsto il successo del test. In questo caso l'unica cosa da fare è schedulare un nuovo inizio di esecuzione
- Fallimento esecuzione: prevede il caso in cui l'evento al punto 1 abbia previsto il fallimento del test. In questo caso il test in questione va rischedulato.

Descrizione preliminare delle funzionalità previste per l’applicazione software

L'interfaccia grafica dell'applicazione avrà 2 differenti sezioni:

La prima dedicata all'impostazione dei parametri per l'utente: qui chi utilizzerà l'applicazione potrà selezionare i parametri che meglio descrivono la situazione in cui si trova. Per ottimizzare l'esperienza utente verranno proposti degli intervalli che permetteranno all'ingegnere gestionale che effettuerà la simulazione di esprimere le condizioni di partenza.
La seconda dedicata allo svolgimento della simulazione: qui verrà stampata a schermo l'intera simulazione, in modo tale che l'utente possa fare le analisi necessarie e trarre conclusioni, oltre a un resoconto complessivo determinato dall'applicazione stessa (riguardante il raggiungimento dell'obiettivo e alcuni dati importanti come numero di fallimenti e prestazioni di ogni macchina)

TdP-prove-finali / Introduzione