Dopo la puntata uno sul monitoraggio delle performance delle applicazioni web e la puntata due sugli strumenti che utilizziamo in smeup LAB per eseguire dei test di performance su Web.UP, ecco alla terza ed ultima puntata che riguarda il nostro processo di qualità.
Il processo di qualità
Per i test di non regressione di Web.UP è stato definito un processo di qualità, ovvero una procedura che dovrà essere seguita dagli sviluppatori in caso di modifica del codice, per controllare la copertura dei test, aggiungere eventualmente nuovi test e controllarne l’esito.
L’idea di base è quella di coprire con i test di non regressione delle performance tutti i componenti grafici di Web.UP (con almeno un test per componente) più le funzionalità generali di base (ad esempio modifica del setup). Il tempo per ogni test case di performance è infatti molto più alto di quello di un singolo test di unità o integrazione in quanto viene girato su n utenti per m volte. Un numero troppo elevato di test case potrebbe portare la suite di test a durare ore. L’aggiunta di un nuovo test, in caso di mancanza della copertura definita, avviene inserendo e configurando un nuovo frammento di script selenium allo script dei test di performance che sarà lanciato da JMeter.
Lo script JMeter
Gli script di selenium sono stati impostati in maniera modulare. Lo script girato da jenkins è in particolare uno script composito. Al suo interno ogni singolo test è scomposto in sotto frammenti, importati da altri file. Ad esempio lo script che definisce la parte di Login è gestito in un frammento esterno. Per aggiungere un nuovo test basta quindi comporlo con frammenti già scritti o scrivendo nuovi frammenti. I frammenti sono parametrizzabili e ciò permette di evitare di riscrivere lo stesso codice più volte.
Struttura dello script jmeter
La definizione delle soglie
Esempio di configurazione delle
soglie su Jenkins
In base ai primi esiti del nuovo test inserito lo sviluppatore definirà delle soglie di tempi massimi che non dovranno essere superati.
Inserendo tali soglie in jenkins si ha la possibilità di ricevere alert automatici nel caso di regressione delle performance. Sempre in questo caso all’esito dei test su jenkins è assegnato un pallino rosso, per distinguerli dagli esiti positivi associati invece ad un pallino blu (come mostrato nella puntata precedente). Tramite il log di console della build di jenkins è inoltre possibile individuare facilmente quali delle soglie sono state superate.
Strumenti per l’analisi delle cause dei problemi di performance
Esempio di console di log di test falliti per superamento delle soglie
E una volta che si sono riscontrate regressioni nei tempi di esecuzione o lentezza nelle prestazioni come si possono indagare le cause e correggerle? Esistono degli strumenti o delle tecniche che ci possono aiutare nell’analisi e nella risoluzione dei casi critici? Approfondiremo queste domande nei prossimi articoli, in cui parleremo di APM, di profilazione, di dump della memoria e dei thread e vedremo il loro utilizzo da parte del laboratorio di smeup.
Chiara Zambelli
Responsabile CI/CD – smeup
My LinkedIn Profile
Naviga per categoria:
Seleziona una categoria d’interesse dal nostro magazine
