In questo articolo affrontiamo due argomenti particolarmente significativi nell’ingegneria del software e quindi rilevanti per chi ne controlla i prodotti prima del rilascio al mercato. Per un approccio sintetico ma completo allo stesso tempo, definiamo innanzitutto i due contesti:
– la performance è l’attitudine di una funzione a svolgere una azione (un elaborazione, il caricamento di una griglia, una stampa) in un lasso di tempo misurabile e oggettivamente contenuto;
– il carico è la propensione di una funzionalità a sopportare un numero definito e via via crescente di dati semplici o aggregati che dovranno essere visualizzati oppure elaborati al fine di un output numerico singolo oppure tabellare.
Risulta naturale che questi due elementi, negli ambiti tecnologici moderni caratterizzati da un time to market brevissimo, siano particolarmente importanti nel testing in quanto agli occhi dell’utente finale rappresentano le migliori credenziali per giudicare l’affidabilità del proprio committente. Per questo quindi la preparazione del test delle performance e dei test di carico deve essere
sempre molto accurata, descriviamoli separatamente.
Il test delle performance
La preparazione ed esecuzione del test si basa essenzialmente sui seguenti punti di rilievo:
– contestualizzare la performance ossia definire un ambito temporale minimo e massimo di applicazione e, soprattutto, un margine temporale di tolleranza verso l’alto adeguatamente coerente;
– capire se i requisiti funzionali o tecnici rispettivamente previsti sono rispettati o rispettano le specifiche per poter implementare la funzione;
– nel caso in cui il punto precedente risulti essere negativo, sollevare le relative anomalie agli enti aziendali preposti;
– dopo che eventuali problematiche siano state adeguatamente risolte, occorre applicare alla funzionalità un numero alternativamente crescenti di dati oppure valori prossimi o superiori a quelli limite previsti dai requisiti di test;
– misurare il tempo impiegato e ponderarlo adeguatamente. Ad esempio se la funzionalità è rappresentata da una griglia tabellare o da una stampa, l’obiettivo sarà quello di garantirne comunque il caricamento completo.
Per verificare che il test sia effettivamente superato occorre controllare che nel tempo di caricamento stimato al punto A (poniamo 20 secondi) siano elaborate ad esempio almeno 2000 righe cioè 100 righe al secondo o superiori. Tempistiche simili a quelle indicate si riferiscono a funzioni in cui tutto il codice sorgente è contenuto nell’eseguibile stesso e rappresentano oramai casi scuola. Nei moderni approcci agile che si adducono a funzionalità evolute (pensiamo al mondo bancario, a siti web con annesso e commerce, a programmi di amministrazione e controllo o di trading, al farmaceutico sanitario, al vasto settore del life critical) le performance devono essere istantanee.
Di conseguenza i programmi utilizzati in questi comparti devono poter elaborare milioni di righe salvate su database e visualizzarli su griglia tabellare o grafici o stampe di varia natura in un tempo che non ecceda mai tipicamente i 3 minuti per elaborazione e i 5-8 secondi per il caricamento dei dati. Una volta valutata correttamente la performance di n righe in un tempo x, occorrerà forzare la mano arrivando a verificare l’attitudine al carico procedendo ai test appositi.
Il test di carico
Per rendere facilmente l’idea di cosa rappresenti il carico pensiamo a una cosa nota a tutti: il motore di un’auto. Cosa fanno i progettisti? Dapprima studiano il massimo rendimento per raggiungere muscolarità e velocità da 0 a 100 km, poi devono affrontare lo scoglio più importante: l’affidabilità. Devono garantire cioè che il motore renda nel tempo in tutte le condizioni e climi.
Il parallelo con il software è intuitivo: la velocità è la performance, l’affidabilità è il carico. Il test di carico quindi deve garantire una perfetta tenuta di performance nel tempo soprattutto in condizioni estreme. Come raggiungere questi obiettivi?
Coniugando due aspetti, uno tecnico e uno più concettuale:
– da una parte, tenendo in considerazione il valore limite superiore, aggiungere gradualmente dati da elaborare (di una griglia o di una stampa) oppure richieste di accesso alla base dati (pensiamo in questo caso alle centinaia di migliaia di accessi effettuati su un sito di acquisti on line oppure a un server specifico di una azienda di distribuzione internazionale), in modo da valutare il punto critico ossia il punto in cui la funzione si blocca totalmente. Una volta appurato questo, il carico ottimale è valore critico -1;
– dall’altra, tenere presente che per raggiungere il massimo carico possibile senza che la funzione sia instabile, occorre accettare una adeguata e limitata perdita di performance tendenziale, un modo che la funzione o sotto funzione in test sia sempre e comunque fruibile.
Un sapiente dosaggio delle tecniche che abbiamo descritto è una delle armi più preziose di un tester software soprattutto in tempi moderni e soprattutto (ma non solo) su prodotti nuovi in fase di lancio.
Si innesca qui poi un altro argomento principe dell’ingegneria del software che tratteremo ampiamente nel prossimo articolo: la non regressione.
Volete saperne tutti i dettagli?
Continuate a seguirci e lo scoprirete.
Articoli correlati
Leggi l’articolo successivo sul test di non regressione.