Leadership nel Test: Test dei Servizi
Nota dell'Editore: Benvenuti nella serie Leadership In Test dal guru e consulente del testing software Paul Gerrard. La serie è pensata per aiutare i tester con qualche anno di esperienza—soprattutto coloro che lavorano in team agili—a eccellere nei loro ruoli di test lead e di gestione.
Nell’articolo precedente, abbiamo esaminato il ruolo in evoluzione dei tester e come favorire una migliore collaborazione con i colleghi. In questo articolo, entreremo nei dettagli del testing delle prestazioni, affidabilità e gestibilità di un’applicazione web. Ovvero il service testing.
Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando saranno pubblicate le nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul, che consigliamo vivamente per un approfondimento su questo e altri temi. Se lo fai, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!
Ciao e benvenuto a un nuovo capitolo della serie Leadership In Test. Questa settimana ci occuperemo del service testing per applicazioni web. Affronteremo:
- Cos'è il Service Testing?
- Cos'è il Performance Testing?
- Test di Affidabilità/Failover
- Test di Gestione del Servizio
Iniziamo.
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
Cos'è il Service Testing?
La qualità del servizio che fornisce un’applicazione web può essere definita includendo tutti i suoi attributi come funzionalità, prestazioni, affidabilità, usabilità, sicurezza e così via.
Tuttavia, ai fini di questa trattazione, isoliamo tre specifici obiettivi di servizio che rientrano nell’ambito di ciò che chiameremo "service testing". Questi obiettivi sono:
- Prestazioni: il servizio deve essere reattivo verso gli utenti supportando al contempo i carichi a cui è sottoposto.
- Affidabilità: se progettato per essere resiliente ai guasti, il servizio deve essere affidabile e/o continuare a fornire il servizio anche in caso di guasto.
- Gestibilità: il servizio deve poter essere gestito, configurato o modificato senza che gli utenti finali notino un degrado del servizio. La gestibilità, ovvero il testing delle operazioni, mira a dimostrare che procedure di amministrazione di sistema, gestione, backup e ripristino siano funzionali ed efficaci.
In tutti e tre i casi, dobbiamo simulare un carico utente per eseguire efficacemente i test. Obiettivi di prestazioni, affidabilità e gestibilità esistono nel contesto di clienti reali che utilizzano il sito per fare business.
La reattività (in questo caso, il tempo che impiega un nodo del sistema a rispondere alla richiesta di un altro) di un sito è direttamente correlata alle risorse disponibili nell’architettura tecnica.
Quando più clienti utilizzano il servizio, meno risorse tecniche sono disponibili per ciascun utente e i tempi di risposta peggiorano.
Ovviamente, un servizio poco caricato ha meno probabilità di fallire. Gran parte della complessità del software e dell’hardware nasce proprio dall’esigenza di sostenere le richieste di risorse all’interno dell’architettura tecnica quando un sito è molto caricato.
Quando un sito è caricato (o sovraccaricato), le richieste concorrenti di risorse devono essere gestite da vari componenti dell’infrastruttura come sistemi operativi server e di rete, database management system, web server, object request broker, middleware e così via.
Questi componenti sono generalmente più affidabili rispetto alle parti applicative personalizzate che richiedono la risorsa, ma i guasti possono verificarsi in entrambi:
- I componenti di infrastruttura falliscono perché il codice applicativo (causa progettazione o implementazione errata) impone richieste eccessive alle risorse.
- Le componenti applicative possono fallire perché le risorse richieste potrebbero non essere sempre disponibili (per tempo).
Simulando carichi produttivi tipici e inusuali per un periodo esteso, i tester possono evidenziare difetti di progettazione o di implementazione del sistema. Quando questi difetti vengono risolti, gli stessi test potranno dimostrare la resilienza del sistema. Gli specialisti QA possono sfruttare strumenti di load testing per eseguire molti dei processi definiti di seguito.
Su tutti i servizi ci sono solitamente alcuni processi critici di gestione che devono essere eseguiti per mantenere fluido il funzionamento del servizio. È possibile sospendere un servizio per effettuare manutenzione ordinaria fuori dall’orario lavorativo, ma la maggior parte dei servizi online è attiva 24 ore su 24.
La giornata lavorativa del servizio non finisce mai. Inevitabilmente, le procedure di gestione devono essere eseguite mentre il servizio è attivo e gli utenti sono collegati. Queste procedure vanno testate mentre il sistema è sotto carico, per assicurarsi che non abbiano un impatto negativo sul servizio attivo, ovvero performance testing.
Che cos'è il test delle prestazioni?
Il test delle prestazioni è una componente fondamentale del test di servizio. Si tratta di un modo per verificare come un sistema si comporta in termini di reattività e stabilità sotto un determinato carico di lavoro. Ecco una panoramica di come funziona:
- Il test delle prestazioni consiste in una serie di test a carichi variabili in cui il sistema raggiunge uno stato stazionario (carichi e tempi di risposta a livelli costanti).
- Misuriamo il carico e i tempi di risposta per ogni carico, simulando per un periodo di 15-30 minuti, al fine di ottenere un numero statisticamente significativo di rilevazioni.
- Monitoriamo e registriamo i parametri vitali per ogni carico simulato. Si tratta delle varie risorse all'interno del nostro sistema, ad esempio utilizzo della CPU e della memoria, larghezza di banda di rete, tassi di I/O e così via.
Tracciamo un grafico di questi carichi variabili rispetto ai tempi di risposta vissuti dai nostri "utenti virtuali". Una volta rappresentato, il nostro grafico appare simile alla figura qui sotto.
A carico zero, quando c'è un solo utente nel sistema, egli ha a disposizione tutte le risorse e i tempi di risposta sono rapidi. Con l'incremento del carico e la relativa misurazione dei tempi di risposta, questi peggiorano progressivamente finché non si raggiunge il punto in cui il sistema opera alla capacità massima.
In questo punto, il tempo di risposta per le nostre transazioni di test è teoricamente infinito perché una delle risorse chiave del sistema è completamente esaurita e non è più possibile processare nuove transazioni.
Man mano che incrementiamo il carico da zero fino al massimo, monitoriamo inoltre l'utilizzo delle varie tipologie di risorse, ad esempio utilizzo del processore del server, utilizzo della memoria, larghezza di banda di rete, blocchi del database e così via.
Al carico massimo, una di queste risorse arriva al 100% della capacità. Questa risorsa rappresenta il "collo di bottiglia" perché si esaurisce per prima. Ovviamente, a questo punto i tempi di risposta sono degradati a tal punto che probabilmente non sarebbero accettabili.
Il grafico sottostante mostra l'uso/disponibilità di diverse risorse tracciato rispetto al carico.
Per aumentare la capacità di throughput e/o ridurre i tempi di risposta di un sistema dobbiamo fare una delle seguenti cose:
- Ridurre la richiesta per la risorsa, tipicamente rendendo più efficiente il software che utilizza detta risorsa (solitamente compito dello sviluppo).
- Ottimizzare l'uso delle risorse hardware all'interno dell'architettura tecnica, ad esempio configurando il DBMS per memorizzare più dati in cache in memoria oppure dando priorità ad alcuni processi rispetto ad altri sul server applicativo.
- Rendere disponibili più risorse. Normalmente aggiungendo processori, memoria o larghezza di banda di rete e così via.
Come avrai già intuito, il test delle prestazioni richiede un team di persone di supporto ai tester. Si tratta di architetti tecnici, amministratori di server, amministratori di rete, sviluppatori e progettisti/amministratori di database. Questi esperti tecnici sono qualificati per analizzare le statistiche generate dagli strumenti di monitoraggio delle risorse e valutare come intervenire sull'applicazione o su una possibile ottimizzazione o potenziamento del sistema.
Se sei il tester, a meno che tu stesso non sia un esperto in questi settori, non cadere nella tentazione di fingere di poter interpretare queste statistiche e prendere decisioni di tuning e ottimizzazione. È necessario coinvolgere questi esperti sin dalle prime fasi del progetto per ottenere i loro consigli e il loro supporto, e poi durante i test, per identificare e risolvere eventuali colli di bottiglia.
Nel prossimo articolo analizzeremo più a fondo come gestire i test delle prestazioni.
Affidabilità/Test di Failover
Garantire la disponibilità continua di un servizio è probabilmente uno degli obiettivi chiave di un progetto. Il test di affidabilità serve a scovare eventuali errori difficilmente rilevabili che provocano guasti inaspettati. Il test di failover serve ad accertarsi che le misure di failover progettate per i guasti previsti funzionino realmente.
Test di Failover
Dove è richiesta resilienza e/o affidabilità, i siti sono generalmente progettati con componenti di sistema affidabili dotati di ridondanza integrata e funzionalità di failover che entrano in funzione in caso di guasti.
Queste funzionalità possono includere instradamento di rete diversificato, numerosi server configurati in cluster, middleware e tecnologie di servizi distribuiti che si occupano del bilanciamento del carico e del reindirizzamento del traffico in caso di scenari di guasto.
Il test di failover ha l'obiettivo di esplorare il comportamento del sistema in specifici scenari di guasto prima della messa in produzione e normalmente comporta le seguenti attività:
- Identificazione dei componenti che potrebbero guastarsi e causare una perdita di servizio (analizzando i guasti dall'interno verso l'esterno).
- Identificazione dei pericoli che potrebbero causare un guasto e portare a una perdita di servizio (analizzando le minacce dall'esterno verso l'interno).
- Un'analisi delle modalità di guasto o degli scenari che potrebbero verificarsi e in cui è necessario essere certi che la misura di ripristino funzioni.
- Un test automatizzato che può essere utilizzato per caricare il sistema ed esplorare il comportamento del sistema su un periodo prolungato.
- Lo stesso test automatizzato può essere anche utilizzato per caricare il sistema sotto test e monitorare il comportamento del sistema in condizioni di guasto.
Una tecnica chiamata Fault Tree Analysis (FTA) può aiutarti a comprendere le dipendenze del servizio dai suoi componenti di base. L'analisi dell'albero dei guasti e i diagrammi ad albero dei guasti rappresentano graficamente e logicamente un sistema o servizio e i modi in cui può fallire.
Lo schema semplice qui di seguito mostra la relazione tra i guasti dei componenti di base, i guasti intermedi dei sottosistemi e il guasto del servizio al livello più alto. Ovviamente, può essere possibile identificare più di tre livelli di eventi di guasto.
Questi test devono essere eseguiti con un carico automatizzato al fine di esplorare il comportamento del sistema in situazioni di produzione e acquisire fiducia nelle misure di recupero progettate. In particolare, si vuole sapere:
- Come si comporta l'architettura in situazioni di guasto?
- Le funzionalità di bilanciamento del carico funzionano correttamente?
- Le capacità di failover assorbono il carico quando un componente si guasta?
- Il recupero automatico funziona? I sistemi riavviati riescono a "recuperare"?
In definitiva, i test si concentrano sulla determinazione se il servizio verso gli utenti finali viene mantenuto e se gli utenti si accorgono effettivamente del guasto in corso.
Test di affidabilità (o soak test)
I test di affidabilità mirano a verificare che non si verifichino guasti sotto carico.
La maggior parte dei componenti hardware è sufficientemente affidabile da avere un tempo medio tra i guasti misurabile in anni. I test di affidabilità richiedono l'uso (o il riutilizzo) dei test automatici in due modi per simulare:
- Carichi estremi su componenti o risorse specifiche nell'architettura tecnica.
- Periodi prolungati di carichi normali (o estremi) sull'intero sistema.
Quando ci si concentra su componenti specifici, si mira a stressare il componente sottoponendolo a un numero eccessivo di richieste per svolgere la sua funzione progettata. Spesso è più semplice effettuare test di stress sugli elementi critici in modo isolato con grandi numeri di richieste semplici, prima di applicare test molto più complessi all’intera infrastruttura. Esistono anche strumenti specifici per lo stress test che rendono più semplice per i QA eseguire il processo.
I soak test sono prove che sottopongono un sistema a un carico prolungato di magari 24, 48 ore o più, per individuare problemi spesso oscuri. Difetti poco evidenti tendono a manifestarsi solo dopo un utilizzo prolungato.
Il test automatizzato non deve necessariamente essere eseguito a carichi estremi (lo stress test copre questo aspetto). Tuttavia, siamo particolarmente interessati alla capacità del sistema di resistere a un funzionamento continuo gestendo una vasta varietà di transazioni di test, per capire se emergono perdite di memoria, blocchi o condizioni di race poco evidenti.
Test di gestione del servizio
Infine, una parola sui test per la gestione del servizio.
Quando il servizio viene distribuito in produzione, deve essere gestito. Mantenere un servizio attivo richiede che venga monitorato, aggiornato, sottoposto a backup e ripristinato rapidamente in caso di problemi.
Le procedure utilizzate dai service manager per eseguire aggiornamenti, backup, rilasci e ripristini da guasti sono fondamentali per garantire un servizio affidabile, quindi devono essere testate, soprattutto se il servizio subirà cambiamenti rapidi dopo la messa in produzione.
I problemi specifici da affrontare sono:
- Le procedure non raggiungono l'effetto desiderato.
- Le procedure sono impraticabili o inutilizzabili.
- Le procedure interrompono il servizio live.
I test dovrebbero, per quanto possibile, essere eseguiti in modo il più realistico possibile.
Qualche spunto di riflessione
Alcuni sistemi sono soggetti a carichi estremi quando si verifica un determinato evento. Ad esempio, un'azienda online può aspettarsi picchi di carico subito dopo aver pubblicizzato offerte in TV, oppure un sito di notizie nazionale può andare in sovraccarico quando si diffonde una notizia importante.
Rifletti su un sistema che conosci bene, che è stato colpito da incidenti imprevisti nella tua azienda o nel panorama nazionale delle notizie.
Quali incidenti o eventi potrebbero causare carichi eccessivi nel tuo sistema?
Puoi (o potresti) raccogliere dati dai log di sistema che ti forniscano il numero di transazioni eseguite? Puoi estrapolare questi dati per prevedere un evento critico che si verifica una volta ogni 100 anni, o ogni 1000 anni?
Quali misure potresti applicare (o hai già applicato) per ridurre la probabilità di picchi, la loro entità, o per eliminarli del tutto?
Iscriviti alla newsletter di The QA Lead per essere avvisato quando saranno pubblicate nuove parti della serie. Questi articoli sono estratti dal corso Leadership In Test di Paul che ti consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di iscriverti, usa il nostro codice sconto esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
Lettura suggerita: 10 MIGLIORI STRUMENTI OPEN SOURCE PER IL TEST MANAGEMENT
