Immaginiamo che, dopo aver preparato la prima versione dell’applicazione ed aver eseguito con successo le fasi di alfa e beta test, l’applicazione venga installata in produzione e gli utenti finali inizino ad utilizzarla.
Anche quando la prima versione è completa, il lavoro di sviluppo e quindi di modifica del codice non è terminato. Infatti:
- La correzione degli errori segnalati dai sistemi di rilevazione (Analytics e log strutturato) richiede modifiche del codice.
- Il feedback degli utenti porta ad implementare modifiche o nuove funzionalità.
- La roadmap del progetto prevede versioni successive.
- L’evoluzione dei sistemi operativi cloud e mobile richiede aggiornamenti al framework di base e quindi al codice dell’applicazione.
Ogni modifica al codice, prima di essere installata in produzione, richiede un test parziale o completo perché non è facile tenere conto di tutte le specifiche anche durante la modifica di una singola riga di codice. D’altra parte un test completo può risultare molto oneroso e non proporzionato all’entità della modifica che si sta per portare in produzione.
Il sistema di test automatico di Instant Developer Cloud nasce proprio per minimizzare i rischi legati alle modifiche al codice dell’applicazione senza dover perdere tempo e risorse preziose.
Oltre alla possibilità di implementare test automatici di non regressione, volti ad assicurare il più possibile il comportamento corretto dell’applicazione, il sistema di test di Instant Developer Cloud risolve un ulteriore problema di fondamentale importanza nell’ambito dei servizi cloud: la stima e l’ottimizzazione delle risorse necessarie al funzionamento.
Infatti nel momento in cui l’applicazione è pronta, si deve procedere all’acquisto delle risorse cloud per la gestione del servizio, ed occorre stimarne la quantità in funzione del numero atteso di utenti contemporanei. La supposizione che il cloud presenta elasticità e quindi si adatta in automatico al carico in entrata, da un lato è vera, ma se viene applicata ad un’applicazione non ottimizzata può causare un’impennata imprevista nei costi del cloud, e risolvere questi problemi a posteriori è sempre più difficile ed urgente.
Per questa ragione il sistema di test di Instant Developer Cloud è in grado di simulare un qualunque carico di utenti su un determinato server di test, permettendo così di comprendere quali parti dell’applicazione dovranno essere ottimizzate e quante risorse saranno necessarie per gestire i carichi attesi. Oltre alla modalità di non regressione, è quindi disponibile il test del carico.
Data l’importanza di queste problematiche, il sistema di test automatico di Instant Developer Cloud è incluso nella versione base delle licenze di sviluppo, senza richiedere costi aggiuntivi.
Nota bene: installare in produzione un’applicazione senza aver implementato gli opportuni test di non regressione e di carico è una pratica altamente sconsigliata che scarica i problemi sugli utenti finali e li rende più urgenti. Per questa ragione, il supporto tecnico di Pro Gamma non riconosce automaticamente l’urgenza delle richieste di segnalazione di problemi sulle proprie applicazioni se non è stato implementato un opportuno insieme di test di non regressione o di carico.
Utilizzo del sistema di test automatico #
Il sistema di test automatico di Instant Developer Cloud si basa su tre fasi:
- Registrazione di sessioni campione ed identificazione dei risultati attesi.
- Organizzazione delle sessioni in suite di test.
- Esecuzione automatica delle suite di test in modalità non regressione o di carico.
La registrazione delle sessioni campione avviene usando l’applicazione stessa: vengono simulati gli stessi processi dell’utente e quindi può essere testato globalmente il funzionamento dei componenti applicativi già in forma integrata. Se si desidera implementare test unitari, è possibile realizzare apposite videate che effettuano i test di base. Tali videate saranno disponibili solo nell’ambiente di test e non in produzione.
Per le applicazioni basate su dati, uno dei problemi fondamentali del test sono i dati di partenza, che devono essere sempre coerenti per poter valutare correttamente l’output del test automatico.
Per questa ragione, il sistema di test di Instant Developer Cloud permette di identificare un particolare backup del database come insieme di dati di base da cui iniziare i test. Prima di lanciare una determinata suite di test, il database dell’applicazione potrà essere automaticamente ripristinato in base alle impostazioni fornite.
Vediamo ora nel dettaglio come si svolgono le varie fasi di registrazione e riproduzione dei test di un’applicazione.
Registrazione di una sessione di test #
La registrazione di una sessione di test inizia dal sottomenu test automatici / sessioni del menu di progetto. Per poter effettuare una registrazione è necessario aver installato l’applicazione su un server di produzione nel cloud di Instant Developer e che tale server sia stato marcato come server utilizzabile per il test nelle impostazioni del server.
È infatti importante tenere separati gli ambienti di test da quelli di produzione. Il sistema di test automatico nasce per testare le nuove versioni prima di rilasciarle agli utenti; inoltre le opzioni di ripristino di un backup del database non consentono di utilizzarlo sui server di produzione veri e propri.
Occorre tenere conto, infine, che un test di carico deve avvenire in condizioni standard e che esso carica il server fino alla saturazione e anche oltre, quindi durante il test di carico tale server non può essere utilizzato dagli utenti dell’applicazione.
Dopo aver indicato un titolo per la sessione di test, aver scelto l’applicazione da testare e aver selezionato l’installazione da utilizzare, è possibile cliccare il pulsante Registra per iniziare la registrazione.
Durante la registrazione sarà possibile utilizzare l’applicazione in modo normale, ma la barra laterale destra del browser conterrà i comandi per la gestione della sessione di test. Mettendo in pausa la registrazione, infatti, si potranno identificare eventuali risultati corretti in funzione delle azioni dell’utente.
Al termine della registrazione, cliccare il pulsante stop per concludere la registrazione e registrare i risultati. È possibile verificare la registrazione di una sessione di test tramite la voce replay del menu di riga della sessione di test.
Identificazione dei risultati attesi #
Mentre la registrazione della sessione campione è in pausa, è possibile cliccare su un oggetto visuale e definire quali proprietà dovranno essere verificate durante il test automatico. Vediamo un esempio:
Nell’immagine precedente la registrazione è stata messa in pausa dopo aver cliccato sulla fetta del grafico a torta relativa alla regione Lombardia. Si vuole verificare che la lista venga posizionata esattamente su tale regione e che lo sfondo della riga cambi colore. Per identificare questo risultato è sufficiente cliccare sullo sfondo della riga e poi selezionare nella lista delle proprietà lo style, che, appunto, identifica l’apposizione del colore di background corretto. Cliccando il pulsante Confirm il risultato da controllare verrà effettivamente acquisito. Può essere interessante identificare anche il totale mostrato nel centro del grafico. In tal caso la proprietà da controllare sarà innerHTML. Tutti gli oggetti per i quali è stato definito un risultato atteso verranno bordati in verde quando la registrazione è in pausa. È possibile poi riprendere la registrazione ed eseguire ulteriori azioni dell’utente e identificare altri risultati da controllare.
Esecuzione del test relativo ad una singola sessione #
Cliccando sul pulsante Esegui test relativo ad una sessione registrata, sarà possibile rieseguire il test della singola sessione. Apparirà la seguente videata per la definizione dei parametri del test:
Il tipo di test prevede le opzioni non regressione e passo-passo. Nel primo caso la sessione verrà eseguita senza interfaccia utente e si potranno leggere i risultati al termine del test. Nel secondo caso, invece, la sessione verrà eseguita aprendo un browser e visualizzando i passaggi della sessione e le verifiche effettuate. In questo caso sarà possibile selezionare anche un dispositivo target. I test di carico sono disponibili solo all’interno di una suite di test.
Definizione di una suite di test #
Una suite di test è un insieme di sessioni che vengono riprodotte per testare compiutamente l’applicazione o una parte di essa. La creazione di una suite avviene dalla pagina delle suite di test che appare cliccando sulla voce Test automatici del menu di progetto.
Definire una suite di test richiede i seguenti passaggi:
- Inserire il titolo, scegliere il tipo di test e l’applicazione da testare. I tipi disponibili sono: test di carico o test di non regressione.
- Scegliere l’installazione di default su cui eseguire la suite di test.
- Scegliere quale backup di dati ripristinare prima di eseguire la suite.
- Nel caso di test di carico, inserire il numero di sessioni da simulare e la durata.
- Aggiungere una o più sessioni di test da eseguire.
Tutti i dati della suite, l’elenco e l’ordine delle sessioni sono modificabili direttamente dalla pagina della lista delle suite, anche dopo averle definite.
Esecuzione di una suite di test #
L’esecuzione di una suite avviene cliccando il pulsante Esegui test sulla riga della suite desiderata. Verrà chiesta conferma dell’installazione su cui eseguire il test, poi verrà mostrata la pagina dei risultati in cui apparirà la riga relativa al test in corso. Al termine del test la videata della console mostrerà un toast di notifica e sarà possibile vedere il dettaglio dei risultati.
Per i test di carico, i risultati riportano il grafico di utilizzo della CPU e della memoria in funzione del numero di sessioni utente contemporanee. Sotto al grafico è presente la lista degli errori avvenuti. In caso di test di carico, non verranno effettuati i controlli identificati durante la registrazione, ma verrà verificato che l’esecuzione abbia avuto luogo correttamente, che non ci siano state eccezioni e che le operazioni non abbiano richiesto un tempo significativamente più lungo di quello registrato. In questo caso, infatti, si avrebbe una esperienza utente degradata.
Nell’immagine alla pagina precedente viene mostrato un esempio di risultato. È facile vedere che la riga blu, che rappresenta il carico CPU, cresce molto velocemente rispetto al numero di sessioni, rappresentato dalla riga rossa. Questo significa che il server utilizzato ha troppe poche risorse per permettere al numero di utenti configurato nel test di eseguire l’applicazione contemporaneamente.
Nell’elenco degli errori sotto al grafico è possibile vedere quali azioni sono andate in timeout, cioè hanno richiesto molto più tempo del previsto. In un caso come questo, l’applicazione dovrà essere decisamente ottimizzata, oppure si dovrà ricorrere ad un server con maggiore capacità.
Per quanto riguarda i test di non regressione, la sezione del grafico non sarà presente, ma sarà possibile vedere gli eventuali errori dovuti ai controlli dei risultati identificati durante la registrazione.