L’architettura del sistema integrato di acquisizione dati e gestione della rilevazione14
3.6 Test e prestazioni del sistema
3.6 Test e prestazioni del sistema
Lo scopo primario delle attività di test delle applicazioni e dei sistemi è stato di dotare l’Istituto di un supporto specializzato nella revisione qualitativa dell’architettura software per la gestione informatica del Censimento Generale della Popolazione, in particolare prima che esso venisse messo in esercizio e nel supporto evolutivo durante lo svolgimento della rilevazione.
Le attività di test funzionali e la loro automatizzazione hanno avuto come obiettivo il miglioramento della qualità del software sviluppato, tramite un processo continuo di verifica e segnalazione agli sviluppatori di problemi individuati nelle fasi di sviluppo e pre-release del software.
La code review si è occupata della ricerca di possibili criticità e vulnerabilità presenti nel codice e nella verifica del rispetto delle “best practice” internazionali (ad es. Owasp, Nist) in materia di sviluppo ed è stata svolta con il supporto di una società di consulenza esterna all’Istituto.
Il servizio di test di carico per il dimensionamento dell’infrastruttura è servito per verificare che l’infrastruttura, in hosting presso un Isp (Internet Service Provider) all’interno del contratto quadro Spc, fosse adeguatamente dimensionata per gli ingenti carichi di accesso al software censuario. Queste attività di test sono state svolte da una società esterna direttamente presso l’Isp.
La strategia adottata per i test funzionali ha permesso la verifica della correttezza funzionale rispetto ai requisiti del committente e ha contribuito alla realizzazione di controlli mirati alla valutazione di altri fattori di qualità come ad esempio: affidabilità, usabilità (si vuole valutare la facilità d’uso dell’applicazione da parte dell’utente finale), efficienza, sicurezza, interoperabilità, prestazioni, robustezza, in modo da garantire un prefissato livello di qualità del prodotto.
La progettazione dei test per il software a supporto della rilevazione censuaria si riassume nei seguenti punti:
1) analisi dei documenti delle specifiche funzionali, dei requisiti e dei documenti di progetto, 2) individuazione delle criticità per ogni funzionalità prevista;
3) definizione dei test case mirati alla valutazione delle singole funzionalità dell’applicazione.
Per ogni test case, in base alle specifiche di progetto, occorre identificare le pre-condizioni che devono essere soddisfatte prima dell’esecuzione del test, l’insieme di azioni da intraprendere per effettuare il test, e il comportamento atteso dall’applicazione in seguito a tali azioni (risultato atteso);
4) nella definizione dei test case bisogna tener presenti gli opportuni “criteri di copertura”:
ogni funzionalità deve essere eseguita almeno una volta;
definito il dominio dei dati per i campi compilabili dagli utenti si effettuano test case ottenuti selezionando:
– valori in posizione centrale;
– valori di frontiera (tra sottodomini); – valori “speciali”;
– Precondizioni e postcondizioni per test case positivi e negativi (invalid input data, invalid output data);
5) aggregazione di più test case in modo da realizzare un test plan specifico per ciascuna
funzionalità completa;
6) avvio della fase iterativa di test e tracciamento dei test effettuati (test run): occorre tracciare
l’identificativo del test case in esame, e il risultato (positivo o negativo) corredato da alcune informazioni aggiuntive (data, versione del prodotto);
7) implementazione di procedure automatiche per la ripetibilità dei test e la validazione di casi
limite;
8) in caso di riscontro di un’anomalia, segnalazione del bug con tutte le informazioni utili allo
sviluppatore per riprodurre l’anomalia, insieme alla descrizione del comportamento errato (Risultato effettivo). I test, in presenza di eventuali variazioni delle specifiche, vanno rivisti sin dalla definizione dei test case e vanno ripetuti una volta corretta l’anomalia e in generale ad ogni nuovo rilascio parziale o definitivo, in modo da verificare la correzione di errori già segnalati o l’introduzione di nuovi errori (test di regressione);
9) rilascio della documentazione relativa ai risultati delle campagne di test.
A supporto dell’attività di test sono stati utilizzati i seguenti strumenti:
Selenium Software: Framework per il test del software per applicazioni web. Selenium fornisce uno strumento per registrare e riprodurre test, attraverso un add-on di Firefox, senza la necessità di apprendere uno specifico linguaggio di scripting. La riproduzione dei test, al fine di testarne la compatibilità è possibile nella maggior parte dei moderni browser web, in modo semi automatico, tramite l’utilizzo dell’estensione server di Selenium;
Bugzilla è un bugtracker, cioè un applicativo software usato generalmente dai programmatori per tenere traccia delle segnalazioni di bug all'interno del codice, in modo che tali errori siano facilmente tracciabili e controllabili, con una descrizione della riproducibilità e dei dettagli ad essi correlati, e dunque più facilmente risolvibili. Bugzilla inoltre permette agli utenti di riportare direttamente report di errori contribuendo, di fatto, al perfezionamento del prodotto in oggetto. Tale strumento dovrebbe essere auspicabilmente utilizzato anche nella fase di beta testing del progetto.
Vista l’importanza della rilevazione censuaria e data la presenza di società di consulenza esterna, l’attività di test è stata documentata con l’utilizzo di report formali. A tal proposito sono stati presentati tutti i test condotti, sia superati (pass) che falliti (fail), mentre non sono trattati i pretest; questa tipologia di test è stata omessa poiché troppo ridondante e poco interessante ai fini della reportistica. Il vantaggio principale della redazione di un documento di reportistica è stata la descrizione di tutti i test condotti, in contrapposizione al tool Bugzilla in cui sono riportati solamente i test che hanno comportato un fallimento del sistema.
Un test run è stato indicato dal nome del test case di riferimento seguito dalla data di esecuzione; in ciascuna tabella è stata inserita una voce per distinguere agevolmente tra test run e test case. I campi presenti nelle schede sono:
test name – Il nome del test case;
descrizione – Descrizione sintetica dell’obiettivo del test;
tester – Funzione in test e riferimento al caso d’uso (nome+versione) sul sistema di gestione dei documenti di progetto (Rational Composer);
risultato atteso – Specifica da parte del tester del risultato atteso;
risultato effettivo – Se coincide con il risultato atteso si può omettere (Pass) se no si descrive l’errore (Fail + descrizione errore);
criticità – Livello di criticità come indicato su Bugzilla;
precondizioni – Lista di condizioni che devono essere soddisfatte prima dell’esecuzione del test, potrebbero essere dettagliate nella test suite (poiché comuni a differenti test case); testing steps – Dettaglio dei passi per eseguire il test mediante un file del tool scelto per il
test (Selenium) in allegato;
test Case / Test Run – Indica se è un test case o un test run;
test Case di Riferimento – Se è un test run, il nome del test case a cui si riferisce; ruolo – Il ruolo dell’utenza con cui è stato eseguito il test.
Un esempio di reportistica è indicato nella figura 3.7.
Figura 3.7 - Esempio di documentazione per la segnalazione di un test non superato
UseCase: Operatori - Sgr_ASS_Assegnazione Rilevatori ai Coc
Test Name Sgr_ASS_AssegnazioneRilevatoriAiCoc_TastoAnnulla20110523_0521
Data Esecuzione 23-mag-11
Descrizione Funzionamento del tasto Annulla nella ricerca Coc Tester Msp
Risultato Atteso Quando si preme il tasto Annulla ci si aspetta che i campi del form vengano cancellati Risultato Effettivo
(Pass – Fail) Fail: premendo il tasto -Annulla il form non viene cancellato- Criticità Normal
Precondizioni Si fa l-autenticazione-->GestioneOperatori-->Assegnazioni-->Rilevatori ai Coc--> Inserisco -abc- nel campo Id operatore--> inserisco -123- nel campo cognome--> Faccio click sul pulsante -Annulla-.
Testing Steps
TestCase/TestRun TestRun
TestCase di Riferimento Sgr_ASS_AssegnazioneRilevatoriAiCoc_TastoAnnulla
Ruolo ducc respucc
Nel report di documentazione delle attività di test sono stati indicati in modo aggregato le attività di test run con il relativo esito (figure 3.8, 3.9, 3.10).
Figura 3.8 - Esiti delle attività di test run
Figura 3.9 - Test passati
0 5 10 15 20 25 Funzioni comuni ‐ Filtri territoriali Operatori ‐ SGR_ASS_Assegnaz… Operatori ‐ SGR_ASS_Assegnaz… Operatori ‐ SGR_ASS_Assegnaz… Operatori ‐ SGR_OPE_Composi… Operatori ‐ SGR_OPE_Inserime… Operatori ‐ SGR_OPE_Modifica… Operatori ‐ SGR_OPE_Ricerca… Sezione ‐ crea sottosezione Sezione ‐ Visualizzazione… SGR_ASS_Assegnazio ne_COC_ai_DUCC Utilita ‐ RicercaQuestionario TestPassati TestFalliti 0% 10% 20% 30%
Figura 3.10 - Test falliti 0% 10% 20% 30% 40%