Strumento di test LoadRunner – Componenti e Architectura

Cos'è LoadRunner?

LoadRunner è uno strumento di test delle prestazioni che è stato introdotto da Mercury nel 1999. LoadRunner è stato poi acquisito da HPE nel 2006. Nel 2016, LoadRunner è stato acquisito da MicroFocus.

LoadRunner supporta vari strumenti di sviluppo, tecnologie e protocolli di comunicazione. In effetti, questo è l'unico strumento sul mercato che supporta un numero così elevato di protocolli da condurre Test di Performance. I risultati dei test delle prestazioni prodotti dal software LoadRunner vengono utilizzati come punto di riferimento rispetto ad altri strumenti

Carica video Runner

Perchè LoadRunner?

LoadRunner non è solo uno strumento pioniere nel test delle prestazioni, ma è ancora leader di mercato nel paradigma del test delle prestazioni. In una recente valutazione, LoadRunner detiene una quota di mercato di circa l'85% nel settore dei test delle prestazioni.

In generale, lo strumento LoadRunner supporta RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex e Silverlight ecc.), Mobile, SAP, Oracle, SIGNORINA SQL Server, Citrix, RTE, Mail e soprattutto, Windows PRESA. Non esiste uno strumento concorrente sul mercato in grado di offrire una così ampia varietà di protocolli racchiusi in un unico strumento.

Ciò che è più convincente nel scegliere LoadRunner nei test del software è la credibilità di questo strumento. Lo strumento LoadRunner ha da tempo una reputazione consolidata, come spesso troverai i clienti effettuano la verifica incrociata dei benchmark delle prestazioni utilizzando LoadRunner. Troverai sollievo se stai già utilizzando LoadRunner per le tue esigenze di test delle prestazioni.

Il software LoadRunner è strettamente integrato con altri strumenti HP come Unified Functional Test (QTP) e ALM (Application Lifecycle Management) e consente di eseguire processi di test end-to-end.

LoadRunner funziona in base al principio di simulazione degli utenti virtuali sull'applicazione in questione. Questi utenti virtuali, definiti anche VUser, replicano le richieste del cliente e si aspettano una risposta corrispondente al passaggio di una transazione.

Perché hai bisogno di test delle prestazioni?

Si stima perdita di 4.4 miliardi di fatturato viene registrato ogni anno a causa delle scarse prestazioni web.

Nell'era odierna del Web 2.0, gli utenti se ne vanno se un sito web non risponde entro 8 secondi. Immagina di aspettare 5 secondi mentre cerchi su Google o fai una richiesta di amicizia su Facebook. Le ripercussioni del downtime delle prestazioni sono spesso più devastanti di quanto si possa immaginare. Abbiamo esempi come quelli che hanno recentemente colpito Bank of America Online Banking, Amazon Servizi Web, Intuit o Blackberry.

Secondo Dunn & Bradstreet, il 59% delle aziende Fortune 500 sperimenta circa 1.6 ore di inattività ogni settimana. Considerando che un’azienda media Fortune 500 con un minimo di 10,000 dipendenti paga 56 dollari l’ora, la parte manodopera dei costi di inattività per tale organizzazione sarebbe di 896,000 dollari settimanali, che si traducono in oltre 46 milioni di dollari all’anno.

Si stima che un tempo di inattività di soli 5 minuti di Google.com (19 agosto 13) costerà al gigante della ricerca fino a $ 545,000.

Si stima che le aziende abbiano perso vendite per un valore di 1100 dollari al secondo a causa di un recente incidente Amazon Interruzione del servizio Web.

Quando un sistema software viene distribuito da un'organizzazione, potrebbero verificarsi molti scenari che potrebbero comportare una latenza delle prestazioni. Numerosi fattori causano un rallentamento delle prestazioni, alcuni esempi possono includere:

• Aumento del numero di record presenti nel database
• Aumento del numero di richieste simultanee effettuate al sistema
• un maggior numero di utenti che accedono contemporaneamente al sistema rispetto al passato

Cos'è LoadRunner Architecnologia?

In generale, l'architettura di HP LoadRunner è complessa, ma facile da comprendere.

Supponiamo che ti venga assegnato il compito di verificare le prestazioni di Amazon.com per 5000 utenti

In una situazione di vita reale, tutti questi 5000 utenti non si troveranno nella home page ma in una sezione diversa dei siti web. Come possiamo simulare diversamente.

VUGen

VUGen o utente virtuale Generator è un IDE (Integrated Development Environment) o un ricco editor di codifica. VUGen viene utilizzato per replicare il comportamento del sistema sotto carico (SUL). VUGen fornisce una funzionalità di "registrazione" che registra la comunicazione da e verso client e server sotto forma di script codificato, chiamato anche script VUser.

Quindi, considerando l'esempio precedente, VUGen può registrare per simulare i seguenti processi aziendali:

1. Navigando nella Pagina Prodotti di Amazon.com
2. Guardare
3. Processo di pagamento
4. Controllo della pagina Il mio account

Controller

Una volta finalizzato uno script VUser, Controller è uno dei principali componenti di LoadRunner che controlla la simulazione del carico gestendo, ad esempio:

• Quanti VUser simulare rispetto a ciascun processo aziendale o gruppo VUser
• Comportamento dei VUser (accelerazione, decelerazione, natura simultanea o concorrente, ecc.)
• Natura dello scenario di carico, ad esempio vita reale o orientamento agli obiettivi o verifica dello SLA
• Quali iniettori utilizzare, quanti VUser a fronte di ciascun iniettore
• Raccogliere periodicamente i risultati
• IP Spoofing
• Errore di comunicazione
• Reporting delle transazioni, ecc.

Prendendo un'analogia dal nostro controller di esempio, aggiungeremo il seguente parametro allo script VUGen

1) 3500 utenti sono Navigando nella Pagina Prodotti di Amazon.com

2) Sono presenti 750 utenti Guardare

3) 500 utenti sono eseguire l'elaborazione dei pagamenti

4) 250 utenti sono Controllo della pagina Il mio account SOLO dopo che 500 utenti hanno eseguito l'elaborazione dei pagamenti

Sono possibili scenari ancora più complessi

1. Avvia 5 VUser ogni 2 secondi fino a un carico di 3500 VUser (navigazione Amazon pagina del prodotto) viene raggiunta.
2. Ripetere per 30 minuti
3. Sospende l'iterazione per 25 VUser
4. Riavvia 20 VUSer
5. Avvia 2 utenti (in Checkout, Elaborazione pagamenti, Pagina MyAccount) ogni secondo.
6. 2500 VUsers verranno generati sulla Macchina A
7. 2500 VUser verranno generati sulla Macchina B

Agenti Macchina/Carico Generators/Iniettori

Il controller HP LoadRunner è responsabile della simulazione di migliaia di VUser: questi VUser consumano risorse hardware, ad esempio processore e memoria, ponendo quindi un limite alla macchina che li sta simulando. Inoltre, il Controller simula questi VUser dalla stessa macchina (dove risiede il Controller) e quindi i risultati potrebbero non essere precisi. Per risolvere questo problema, tutti gli utenti VUser sono distribuiti su varie macchine, chiamate Caricare Generators o Caricare gli iniettori.

Come pratica generale, il Controller risiede su una macchina diversa e il carico viene simulato da altre macchine. A seconda del protocollo degli script VUser e delle specifiche della macchina, potrebbe essere necessario un numero di Load Injector per la simulazione completa. Ad esempio, i VUser per uno script HTTP richiederanno 2-4 MB per VUser per la simulazione, quindi saranno necessarie 4 macchine con 4 GB di RAM ciascuna per simulare un carico di 10,000 VUser.

Prendendo l'analogia dal nostro Amazon Ad esempio, l'output di questo componente sarà

Analisi

Una volta eseguiti gli scenari di carico, il ruolo di “Analisi"I componenti di LoadRunner arrivano.

Durante l'esecuzione, il controller crea un dump dei risultati in forma grezza e contiene informazioni come quale versione di LoadRunner ha creato questo dump dei risultati e quali erano le configurazioni.

Tutti gli errori e le eccezioni vengono registrati in a Microsoft accedere al database, denominato, output.mdb. Il componente "Analisi" legge questo file di database per eseguire vari tipi di analisi e genera grafici.

Questi grafici mostrano varie tendenze per comprendere il motivo degli errori e dei guasti sotto carico; quindi aiuta a capire se è necessaria l'ottimizzazione in SUL, Server (ad esempio JBoss, Oracle) o infrastrutture.

Di seguito è riportato un esempio in cui la larghezza di banda potrebbe creare un collo di bottiglia. Supponiamo che il server Web abbia una capacità di 1 GBps mentre il traffico dati supera questa capacità causando sofferenze agli utenti successivi. Per determinare che il sistema soddisfi tali esigenze, Performance Engineer deve analizzare il comportamento dell'applicazione con un carico anomalo. Di seguito è riportato un grafico generato da LoadRunner per ottenere la larghezza di banda.

Come eseguire i test delle prestazioni

La Roadmap del test delle prestazioni può essere sostanzialmente suddivisa in 5 fasi:

• Pianificazione del test di carico
• Crea script VUGen
• Creazione dello scenario
• Esecuzione dello scenario
• Analisi dei risultati (seguita dalla messa a punto del sistema)

Ora che hai installato LoadRunner, comprendiamo i passaggi coinvolti nel processo uno per uno.

Passaggi coinvolti nel processo di test delle prestazioni

Passaggio 1) Pianificazione del test di carico

La pianificazione dei test delle prestazioni è diversa dalla pianificazione a SIT (Test di integrazione del sistema) or UAT (test di accettazione dell'utente). La pianificazione può essere ulteriormente suddivisa in piccole fasi come descritto di seguito:

Assembla la tua squadra

Quando si inizia con LoadRunner Testing, è meglio documentare chi parteciperà all'attività di ciascun team coinvolto durante il processo.

Responsabile del progetto:

Nominare il project manager che sarà proprietario di questa attività e fungerà da persona di riferimento per l'escalation.

Esperto di funzioni/Analista aziendale:

Fornire analisi sull'utilizzo di SUL e fornire competenze sulle funzionalità aziendali del sito Web/SUL

Esperto di test delle prestazioni:

Crea i test delle prestazioni automatizzati ed esegue scenari di carico

Sistema Architettare:

Fornisce il progetto del SUL

Sviluppatore Web e PMI:

• Mantiene il sito Web e fornisce aspetti di monitoraggio
• Sviluppa il sito web e corregge i bug

Amministratore di sistema:

• Mantiene i server coinvolti durante un progetto di test

Delineare le applicazioni e i Processi Aziendali coinvolti:

di risposte positive Caricare i test richiede che si pianifichi di eseguire determinati processi aziendali. Un processo aziendale è costituito da passaggi chiaramente definiti in conformità con le transazioni aziendali desiderate, in modo da raggiungere gli obiettivi del test di carico.

È possibile preparare una metrica dei requisiti per sollecitare il carico dell'utente sul sistema. Di seguito è riportato un esempio di sistema di presenze in un’azienda:

Nell'esempio sopra, le cifre indicano il numero di utenti connessi all'applicazione (SUL) in una determinata ora. Possiamo estrarre il numero massimo di utenti collegati a un processo aziendale a qualsiasi ora del giorno che viene calcolato nelle colonne più a destra.

Allo stesso modo possiamo risalire al numero totale degli utenti collegati all'applicazione (SUL) a qualsiasi ora del giorno. Questo viene calcolato nell'ultima riga.

La combinazione dei due fatti precedenti ci fornisce il numero totale di utenti con cui dobbiamo testare le prestazioni del sistema.

Definire le procedure di gestione dei dati di test

Le statistiche e le osservazioni tratte dai test delle prestazioni sono fortemente influenzate da numerosi fattori, come spiegato in precedenza. È di fondamentale importanza preparare i dati di test per i test delle prestazioni. A volte, un particolare processo aziendale consuma un set di dati e produce un set di dati diverso. Prendi l'esempio seguente:

• Un utente "A" crea un contratto finanziario e lo invia per la revisione.
• Un altro utente "B" approva 200 contratti al giorno creati dall'utente "A"
• Un altro utente "C" paga circa 150 contratti al giorno approvati dall'utente "B"

In questa situazione, l'utente B deve avere 200 contratti "creati" nel sistema. Inoltre, l'utente C necessita di 150 contratti come “approvati” per simulare un carico di 150 utenti.

Ciò significa implicitamente che devi creare almeno 200+150= 350 contratti.

Successivamente, approva 150 contratti che fungeranno da dati di test per l'utente C; i restanti 200 contratti fungeranno da dati di test per l'utente B.

Monitor di contorno

Specula su ogni singolo fattore che potrebbe influenzare le prestazioni di un sistema. Ad esempio, la riduzione dell'hardware avrà un potenziale impatto sulle prestazioni SUL (System Under Load).

Elenca tutti i fattori e imposta i monitor in modo da poterli valutare. Ecco alcuni esempi:

• Processore (per server Web, server applicazioni, server database e iniettori)
• RAM (per server Web, server applicazioni, server database e iniettori)
• Server Web/App (ad esempio IIS, JBoss, Jaguar Server, Tomcat ecc.)
• DB Server (dimensioni PGA e SGA in caso di Oracle e MSSQL Server, SP ecc.)
• Utilizzo della larghezza di banda della rete
• NIC interna ed esterna in caso di clustering
• Load Balancer (e che distribuisca il carico uniformemente su tutti i nodi dei cluster)
• Flusso di dati (calcola la quantità di dati spostati da e verso client e server, quindi calcola se una capacità della NIC è sufficiente per simulare un numero X di utenti)

Passaggio 2) Crea script VUGen

Il passo successivo dopo la pianificazione è creare Script VUser.

Passaggio 3) Creazione dello scenario

Il passaggio successivo è creare il tuo scenario di caricamento

Passaggio 4) Esecuzione dello scenario

L'esecuzione dello scenario consiste nell'emulare il carico utente sul server istruendo più VUser a eseguire attività contemporaneamente.

È possibile impostare il livello di carico aumentando e diminuendo il numero di VUser che eseguono attività contemporaneamente.

Questa esecuzione potrebbe causare stress al server e comportarsi in modo anomalo. Questo è lo scopo stesso del test delle prestazioni. I risultati ottenuti vengono quindi utilizzati per un'analisi dettagliata e l'identificazione della causa principale.

Passaggio 5) Analisi dei risultati (seguita dalla messa a punto del sistema)

Durante l'esecuzione dello scenario, LoadRunner registra le prestazioni dell'applicazione sotto carichi diversi. Le statistiche ricavate dall'esecuzione del test vengono salvate e viene eseguita un'analisi dettagliata. Lo strumento "HP Analysis" genera vari grafici che aiutano a identificare le cause principali dietro un ritardo delle prestazioni del sistema, nonché un guasto del sistema.

Alcuni dei grafici ottenuti includono:

• Tempo per il primo buffer
• Tempo di risposta alla transazione
• Tempo medio di risposta alla transazione
• Colpi al secondo
• Windows Risorse
• Statistiche degli errori
• Riepilogo delle transazioni

FAQ