Guida completa al test di carico per principianti

load testing complete guide

Una guida completa al test di carico per principianti:

In questo tutorial, impareremo perché eseguiamo il test di carico, cosa ne viene ottenuto, architettura, qual è l'approccio da seguire per eseguire con successo un test di carico, come impostare un ambiente di test di carico, best practice, insieme a i migliori strumenti di test di carico disponibili sul mercato.

Abbiamo sentito parlare di test sia funzionali che non funzionali. Nei test non funzionali, abbiamo diversi tipi di test come test delle prestazioni, test di sicurezza, test dell'interfaccia utente ecc.

Quindi, il test di carico è un tipo di test non funzionale che è un sottoinsieme del test delle prestazioni.

Quindi, quando diciamo che stiamo testando un'applicazione per le prestazioni, cosa stiamo testando qui? Stiamo testando l'applicazione per carico, volume, capacità, stress ecc.

Cosa imparerai:

• Cos'è il test di carico?
• Architettura del test di carico
• Perché il test di carico?
• Ambiente
• Approccio
• Migliori pratiche
• Conclusione
• Lettura consigliata

Cos'è il test di carico?

Il test di carico è un sottoinsieme del test delle prestazioni, in cui testiamo la risposta del sistema in condizioni di carico variabili simulando più utenti che accedono contemporaneamente all'applicazione. Questo test di solito misura la velocità e la capacità dell'applicazione.

Pertanto, ogni volta che modifichiamo il carico, monitoriamo il comportamento del sistema in varie condizioni.

Esempio :Supponiamo che il requisito del nostro cliente per una pagina di accesso sia di 2-5 secondi e che questo 2-5 secondi dovrebbe essere costante fino a quando il caricamento non è di 5000 utenti. Allora cosa dovremmo osservare sentire? È solo la capacità di movimentazione del carico del sistema o è solo il requisito del tempo di risposta?

La risposta è entrambe. Vogliamo il sistema in grado di gestire un carico di 5000 utenti con un tempo di risposta di 2-5 secondi per tutti gli utenti simultanei.

Allora cosa si intende per utente simultaneo e utente virtuale?

Gli utenti simultanei sono coloro che accedono all'applicazione e, allo stesso tempo, eseguono una serie di attività insieme e si disconnettono dall'applicazione allo stesso tempo. D'altra parte, gli utenti virtuali semplicemente saltano dentro e fuori dal sistema indipendentemente dalle attività degli altri utenti.

Architettura del test di carico

Nel diagramma sottostante possiamo vedere come i diversi utenti accedono all'applicazione. Qui ogni utente effettua una richiesta su Internet, che viene successivamente passata attraverso un firewall.

Dopo il firewall, abbiamo un bilanciatore del carico che distribuisce il carico a uno qualsiasi dei server Web, quindi passa al server delle applicazioni e successivamente al server del database dove recupera le informazioni necessarie in base alla richiesta dell'utente.

Il test di carico può essere eseguito sia manualmente che utilizzando uno strumento. Tuttavia, il test di carico manuale non è consigliato poiché non testiamo l'applicazione per un carico inferiore.

Esempio: Supponiamo di voler testare un'applicazione di shopping online per vedere il tempo di risposta dell'applicazione per ogni clic dell'utente, ad es. Passaggio 1: URL di avvio, tempo di risposta, Accedi all'applicazione e annota il tempo di risposta e così via come selezionando un prodotto, aggiungendo al carrello, effettuando il pagamento e disconnettendosi. Tutto questo deve essere fatto per 10 utenti.

Quindi, ora quando abbiamo bisogno di testare il carico dell'applicazione per 10 utenti, possiamo ottenerlo inserendo manualmente il carico di 10 utenti fisici da macchine diverse invece di utilizzare uno strumento. In questo scenario, è consigliabile eseguire un test di carico manuale piuttosto che investire in uno strumento e configurare un ambiente per lo strumento.

Considerando che se abbiamo bisogno di test di carico per 1500 utenti, dobbiamo automatizzare il test di carico utilizzando uno qualsiasi degli strumenti disponibili in base alle tecnologie in cui è costruita l'applicazione e anche in base al budget che abbiamo per il progetto.

Se abbiamo un budget, possiamo optare per strumenti commerciali come Load runner, ma se non disponiamo di molto budget, possiamo optare per strumenti open source come JMeter, ecc.

cosa non riesce a trovare l'analisi statica

Che si tratti di uno strumento commerciale o di uno strumento open source, i dettagli devono essere condivisi con il cliente prima di finalizzare lo strumento. Di solito, viene preparata una prova di concetto, in cui generiamo uno script di esempio utilizzando lo strumento e mostriamo i rapporti di esempio al cliente per l'approvazione dello strumento prima di finalizzarlo.

Nel test di carico automatizzato, sostituiamo gli utenti con l'aiuto di uno strumento di automazione, che imita le azioni dell'utente in tempo reale. Automatizzando il carico possiamo risparmiare risorse e tempo.

Di seguito è riportato il diagramma che mostra come gli utenti vengono sostituiti utilizzando uno strumento.

Perché il test di carico?

Supponiamo che esista un sito Web per lo shopping online che funziona abbastanza bene durante i normali giorni lavorativi, ovvero gli utenti sono in grado di accedere all'applicazione, navigare tra le diverse categorie di prodotti, selezionare i prodotti, aggiungere articoli al carrello, effettuare il check-out e disconnettersi all'interno un intervallo accettabile e non ci sono errori di pagina o tempi di risposta enormi.

Nel frattempo, arriva un giorno di punta, ad esempio il giorno del Ringraziamento e ci sono migliaia di utenti che hanno effettuato l'accesso al sistema, il sistema si è bloccato all'improvviso e gli utenti sperimentano una risposta molto lenta, alcuni non potrebbero nemmeno accedere al sito, alcuni non sono riusciti ad aggiungere al carrello e alcuni non sono riusciti a effettuare il check-out.

Quindi, in questo grande giorno, l'azienda ha dovuto affrontare una perdita enorme poiché ha perso molti clienti e anche molti affari. Tutto questo è accaduto solo perché non hanno previsto il carico dell'utente per i giorni di punta, anche se avrebbero previsto che non sarebbe stato eseguito alcun test di carico sul sito Web dell'azienda, quindi non sanno quanto carico sarà in grado di gestire l'applicazione nei giorni di punta.

Pertanto, per gestire tali situazioni e al fine di superare enormi entrate, è consigliabile condurre test di carico per questo tipo di applicazioni.

• Il test di carico aiuta a costruire sistemi robusti e affidabili.
• Il collo di bottiglia nel sistema viene identificato con largo anticipo prima che l'applicazione venga pubblicata.
• Aiuta a identificare la capacità dell'applicazione.

Cosa si ottiene durante un test di carico?

Con un test di carico adeguato, possiamo avere una comprensione esatta di quanto segue:

1. Il numero di utenti che il sistema è in grado di gestire o è in grado di scalare.
2. Il tempo di risposta di ogni transazione.
3. Come si comporta ciascun componente dell'intero sistema in Carica, ad esempio componenti del server delle applicazioni, componenti del server Web, componenti del database, ecc.
4. Quale configurazione del server è la migliore per gestire il carico?
5. Se l'hardware esistente è sufficiente o se c'è bisogno di hardware aggiuntivo.
6. Vengono identificati colli di bottiglia come l'utilizzo della CPU, l'utilizzo della memoria, i ritardi di rete, ecc.

Ambiente

Abbiamo bisogno di un ambiente di test di carico dedicato per condurre i nostri test. Perché la maggior parte delle volte l'ambiente di test di carico sarà lo stesso dell'ambiente di produzione e anche i dati disponibili nell'ambiente di test di carico saranno gli stessi della produzione sebbene non siano gli stessi dati.

Ci saranno più ambienti di test come l'ambiente SIT, l'ambiente QA ecc., Questi ambienti non sono la stessa produzione, perché a differenza dei test di carico non hanno bisogno di molti server o di tanti dati di test per condurre test funzionali o test di integrazione.

Esempio:

In un ambiente di produzione, abbiamo 3 server applicazioni, 2 server Web e 2 server database. In QA, abbiamo solo 1 server applicazioni, 1 server Web e 1 server database. Quindi, se conduciamo un test di carico sull'ambiente QA che non è uguale alla produzione, i nostri test non sono validi e sono anch'essi errati e quindi non possiamo andare da questi risultati.

Quindi cerca sempre di avere un ambiente dedicato per il test di carico simile a quello di un ambiente di produzione.

Inoltre, a volte abbiamo applicazioni di terze parti che il nostro sistema chiamerà, quindi in questi casi, possiamo utilizzare gli stub poiché non possiamo sempre lavorare con i fornitori di terze parti per l'aggiornamento dei dati o qualsiasi altro problema o supporto.

Prova a scattare un'istantanea dell'ambiente una volta che è pronto in modo che, ogni volta che desideri ricostruire l'ambiente, puoi utilizzare questa istantanea, che aiuterebbe con la gestione del tempo. Ci sono alcuni strumenti disponibili sul mercato per configurare l'ambiente come Puppet, Docker ecc.

Approccio

Prima di iniziare il test di carico, dobbiamo capire se sul sistema è già stato eseguito un test di carico o meno. Se è stato eseguito un test di carico in precedenza, è necessario sapere qual è stato il tempo di risposta, le metriche di client e server raccolte, qual è stata la capacità di carico dell'utente, ecc.

Inoltre, abbiamo bisogno di informazioni su quanto è l'attuale capacità di gestione delle applicazioni. Se si tratta di una nuova applicazione, dobbiamo comprendere i requisiti, qual è il carico mirato, qual è il tempo di risposta previsto e se è realmente realizzabile o meno.

Se si tratta di un'applicazione esistente, è possibile ottenere i requisiti di carico e i modelli di accesso utente dai log del server. Ma se si tratta di una nuova applicazione, è necessario contattare il team aziendale per ottenere tutte le informazioni.

Una volta che abbiamo i requisiti, dobbiamo identificare come eseguiremo il test di carico. È fatto manualmente o utilizzando strumenti? L'esecuzione manuale di un test di carico richiede molte risorse ed è anche molto costosa. Anche ripetere il test, ancora e ancora, sarà dura.

Quindi, per ovviare a questo, possiamo utilizzare strumenti open source o strumenti commerciali. Gli strumenti open source sono disponibili gratuitamente, questi strumenti potrebbero non avere tutte le funzionalità come gli altri strumenti commerciali ma se il progetto ha un vincolo di budget, allora possiamo optare per strumenti open source.

Mentre gli strumenti commerciali hanno molte funzionalità, supportano molti protocolli e sono molto facili da usare.

Il nostro approccio al test di carico sarà il seguente:

# 1) Identificare i criteri di accettazione del test di carico

Per esempio:

1. Il tempo di risposta della pagina di accesso non dovrebbe essere superiore a 5 secondi anche durante le condizioni di carico massimo.
2. L'utilizzo della CPU non dovrebbe essere superiore all'80%.
3. La velocità effettiva del sistema dovrebbe essere di 100 transazioni al secondo.

# 2) Identifica gli scenari di business che devono essere testati.

Non testare tutti i flussi, cerca di capire i principali flussi aziendali che dovrebbero verificarsi nella produzione. Se si tratta di un'applicazione esistente, possiamo ottenere le sue informazioni dai log del server dell'ambiente di produzione.

Se si tratta di un'applicazione di nuova generazione, è necessario collaborare con i team aziendali per comprendere i modelli di flusso, l'utilizzo dell'applicazione, ecc. A volte il team di progetto condurrà workshop per fornire una panoramica o dettagli su ciascun componente dell'applicazione.

Dobbiamo partecipare al workshop sull'applicazione e annotare tutte le informazioni richieste per condurre il nostro test di carico.

# 3) Modellazione del carico di lavoro

Una volta che abbiamo i dettagli sui flussi aziendali, i modelli di accesso degli utenti e il numero di utenti, dobbiamo progettare il carico di lavoro in modo tale che imiti la navigazione dell'utente effettiva in produzione o come previsto in futuro una volta che l'applicazione sarà in produzione.

I punti chiave da ricordare durante la progettazione di un modello di carico di lavoro è vedere quanto tempo richiederà il completamento di un determinato flusso aziendale. Qui dobbiamo assegnare il tempo di riflessione in modo tale che l'utente navighi all'interno dell'applicazione in modo più realistico.

Il modello di carico di lavoro sarà solitamente con una rampa su, una rampa di discesa e uno stato stabile. Dobbiamo caricare lentamente il sistema e quindi utilizzare ramp up e ramp down. Lo stato stazionario di solito è un test di carico di un'ora con Rampa su di 15 min e Ram giù di 15 min.

Facciamo un esempio del modello del carico di lavoro:

Panoramica dell'applicazione: ipotizziamo uno shopping online, in cui gli utenti accederanno all'applicazione e avranno un'ampia varietà di vestiti da acquistare e potranno navigare attraverso ogni prodotto.

Per visualizzare i dettagli su ogni prodotto, devono fare clic sul prodotto. Se a loro piace il costo e la marca del prodotto, possono aggiungere al carrello e acquistare il prodotto effettuando il check-out ed effettuando il pagamento.

Di seguito è riportato un elenco di scenari:

1. Navigare - Qui, l'utente avvia l'applicazione, accede all'applicazione, esplora le diverse categorie e si disconnette dall'applicazione.
2. Sfoglia, Visualizzazione prodotto, Aggiungi al carrello - Qui, l'utente accede all'applicazione, esplora diverse categorie, visualizza i dettagli del prodotto, aggiunge il prodotto al carrello e si disconnette.
3. Sfoglia, Visualizzazione prodotto, Aggiungi al carrello e Check out - In questo scenario, l'utente accede all'applicazione, esplora diverse categorie, visualizza i dettagli del prodotto, aggiunge il prodotto al carrello, esegue il check out e si disconnette.
4. Sfoglia, Visualizzazione prodotto, Aggiungi al carrello Check out ed effettua il pagamento - Qui, l'utente accede all'applicazione, esplora diverse categorie, visualizza i dettagli del prodotto, aggiunge il prodotto al carrello, effettua il check out, effettua il pagamento e si disconnette.

I valori di cui sopra sono stati derivati ​​sulla base dei seguenti calcoli:

• Transazioni all'ora = Numero di utenti * Transazioni effettuate da un singolo utente in un'ora.
• Il numero di utenti = 1600.
• Il numero totale di transazioni nello scenario Browse = 17.
• Tempo di risposta per ogni transazione = 3.
• Tempo totale impiegato da un singolo utente per completare 17 transazioni = 17 * 3 = 51 arrotondato a 60 sec (1 min).
• Transazioni all'ora = 1600 * 60 = 96000 Transazioni.

# 4) Progettare i test di carico- Il test di carico dovrebbe essere progettato con i dati raccolti fino ad ora, ovvero flussi aziendali, numero di utenti, modelli di utenti, metriche da raccogliere e analizzare. Inoltre, i test dovrebbero essere progettati in modo molto realistico.

# 5) Esegui il test di carico - Prima di eseguire il test di carico, assicurati che l'applicazione sia attiva e in esecuzione. L'ambiente di prova di carico è pronto. L'applicazione è funzionalmente testata ed è stabile.

Verificare le impostazioni di configurazione dell'ambiente Load test. Dovrebbe essere lo stesso dell'ambiente di produzione. Assicurati che tutti i dati del test siano disponibili. Assicurati di aggiungere i contatori necessari per monitorare le prestazioni del sistema durante l'esecuzione del test.

Inizia sempre con un carico basso e aumenta gradualmente il carico. Non iniziare mai a pieno carico e rompere il sistema.

# 6) Analizza i risultati del test di carico - Avere un test di base da confrontare sempre con le altre esecuzioni di test. Raccogli le metriche ei log del server dopo l'esecuzione del test per trovare i colli di bottiglia.

Alcuni progetti utilizzano gli strumenti di monitoraggio delle prestazioni delle applicazioni per monitorare il sistema durante l'esecuzione del test, questi strumenti APM aiutano a identificare la causa principale più facilmente e fanno risparmiare molto tempo. Questi strumenti sono molto facili da trovare la causa principale del collo di bottiglia in quanto hanno una visione ampia per individuare dove si trova il problema.

Alcuni degli strumenti APM sul mercato includono DynaTrace, Wily Introscope, App Dynamics ecc.

# 7) Rapporti - Una volta completato il test, raccogli tutte le metriche e invia il rapporto di riepilogo del test al team interessato con le tue osservazioni e raccomandazioni.

Migliori pratiche

Di seguito sono elencate alcune delle migliori pratiche di test di carico:

# 1) Verificare sempre la stabilità dell'applicazione prima di avviare un test di carico. L'applicazione deve essere firmata funzionalmente stabile dal team di test funzionale e tutti i principali difetti devono essere corretti e testati prima che la build venga copiata nell'ambiente Load Test.

#Due) Verificare che l'ambiente del test di carico sia una replica o vicino all'ambiente di produzione, incluso il numero di server, bilanciatori del carico, configurazioni dei server e firewall.

# 3) Controlla se i dati del test sono univoci e abbiamo tutti i dati del test copiati nell'ambiente di carico prima di eseguire un test di carico.

# 4) Progettare gli scenari di test in modo tale che imitino l'azione dell'utente in tempo reale che si verifica nella produzione.

# 5) Progettare il carico di lavoro in base ai carichi utente di produzione e ai flussi aziendali e, nel caso di una vecchia applicazione, vedere se si tratta di un nuovo discorso al team aziendale riguardo ai flussi aziendali e al carico utente.

# 6) Raccogli tutte le metriche importanti come tempo di risposta, hit al secondo, velocità effettiva, CPU, memoria, rete e utenti virtuali in esecuzione.

Lettura consigliata => Elenco degli strumenti di test delle prestazioni disponibili sul mercato per l'esecuzione di test di carico esclusivi.

Conclusione

In questo tutorial, abbiamo imparato come il test di carico gioca un ruolo importante nel test delle prestazioni di un'applicazione, come aiuta a comprendere l'efficienza e la capacità dell'applicazione, ecc.

Siamo anche venuti a sapere come aiuta a prevedere se è necessario hardware, software o messa a punto aggiuntivi su un'applicazione.

Buona lettura!!

Lettura consigliata

• Test di carico con HP LoadRunner Tutorial
• Alpha test e beta test (una guida completa)
• Guida al test di sicurezza delle applicazioni Web
• Guida allo stress test per principianti
• Guida per principianti ai test di penetrazione delle applicazioni Web
• Una guida completa ai test non funzionali per principianti
• Guida completa al test di verifica della costruzione (test BVT)
• Test delle prestazioni vs test di carico vs stress test (differenza)