Strumento di test LoadRunner: ArchiSchema della struttura e componenti
Tommaso Hamilton
⚡ Riepilogo intelligente
LoadRunner è lo strumento di test delle prestazioni aziendali, ora venduto da OpenTextche simula migliaia di utenti virtuali su VuGen, Controller, generatori di carico e Analisi per individuare i colli di bottiglia prima che vengano rilevati dal traffico reale.
Cos'è LoadRunner?
LoadRunner è un Test di Performance strumento che è stato ideato da Mercury Interactive nel 1999. LoadRunner è stata successivamente acquisita da HP nel 2006 e la divisione software di HP si è fusa con Micro Focus in un accordo annunciato nel 2016 e completato nel 2017.
Nota del marchio: OpenText ha completato l'acquisizione di Micro Focus nel gennaio 2023. Lo strumento non è più venduto come HP o Micro Focus LoadRunner: LoadRunner Professional è ora OpenText Ingegneria delle prestazioni professionale, LoadRunner Enterprise è OpenText Enterprise Performance Engineering e LoadRunner Cloud è OpenText Ingegneria delle prestazioni di base. I nomi dei componenti seguenti — VuGen, Controller, generatori di carico e Analisi — rimangono invariati.
LoadRunner supporta diversi strumenti di sviluppo, tecnologie e protocolli di comunicazione. Possiede una delle librerie di protocolli più ampie sul mercato per l'esecuzione di test di performance. I risultati dei test di performance prodotti dal software LoadRunner vengono utilizzati come benchmark rispetto ad altri strumenti.
Carica video Runner
Guarda il video qui sotto per una breve introduzione a LoadRunner prima di analizzare i suoi componenti.
Perchè LoadRunner?
LoadRunner non è solo uno strumento pionieristico nel campo dei test di performance, ma rimane uno dei leader di mercato nel paradigma dei test di performance ed è tuttora il punto di riferimento per molte aziende.
La copertura del protocollo è la ragione principale per cui i team lo scelgono, come mostra la mappa dei componenti qui sotto.
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 Socket. Pochi strumenti concorrenti offrono una così ampia varietà di protocolli racchiusi in un unico strumento, come illustra l'elenco di protocolli riportato di seguito.
Ciò che rende LoadRunner uno strumento particolarmente convincente per il testing del software è la sua affidabilità. LoadRunner si è guadagnato da tempo una solida reputazione, tanto che spesso i clienti lo utilizzano per verificare i benchmark di performance. Se già utilizzi LoadRunner per le tue esigenze di test delle prestazioni, la scelta sarà sicuramente più sicura.
Il software LoadRunner è strettamente integrato con gli strumenti fratelli della stessa suite: Unified Functional Testing (l'ex QTP, ora venduto come OpenText Test funzionale) e ALM (Application Lifecycle Management, ora OpenText ALM/Quality Center) — che ti consente di eseguire i tuoi processi di test end-to-end.
LoadRunner funziona simulando utenti virtuali sull'applicazione in questione. Questi utenti virtuali, anche detti VUser, replicano le richieste del client e si aspettano una risposta corrispondente per concludere una transazione.
Perché hai bisogno di test delle prestazioni?
Le stime del settore riportate di seguito sono ampiamente citate e risalgono ai primi anni 2010, ma il modello che descrivono non è cambiato: le pagine lente costano.
Si stima che ogni anno si registri una perdita di fatturato pari a 4.4 miliardi di dollari a causa delle scarse prestazioni del sito web.
Nell'era odierna del Web 2.0, gli utenti abbandonano un sito web se non risponde entro 8 secondi. Immagina di dover aspettare 5 secondi mentre cerchi Google o inviare una richiesta di amicizia su Facebook. Le ripercussioni dei tempi di inattività delle prestazioni sono spesso più devastanti di quanto si possa immaginare. Ci sono esempi ben noti come quelli che hanno colpito Bank of America Online Banking, Amazon Servizi Web, Intuit e Blackberry.
Secondo Dun & Bradstreet, il 59% delle aziende Fortune 500 subisce circa 1.6 ore di inattività a settimana. Considerando che un'azienda Fortune 500 media con almeno 10,000 dipendenti paga 56 dollari l'ora, la componente del costo del lavoro per le interruzioni di servizio di un'organizzazione di questo tipo ammonterebbe a 896,000 dollari a settimana, ovvero oltre 46 milioni di dollari all'anno.
Solo un tempo di inattività di 5 minuti di GoogleSi stima che la cessione del dominio .com nell'agosto del 2013 sia costata al colosso dei motori di ricerca ben 545,000 dollari.
Si stima che le aziende abbiano perso vendite per un valore di 1,100 dollari al secondo durante un passato Amazon Interruzione dei servizi 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 numero maggiore di utenti che accedono al sistema contemporaneamente rispetto al passato
Non tutte le candidature sono però idonee. Caricare i test È pensato per sistemi client-server multiutente, quindi un'utilità desktop per utente singolo come quella riportata di seguito non vale la pena di essere testata in termini di prestazioni.
Cos'è LoadRunner Architecnologia?
In linea generale, l'architettura di LoadRunner è complessa, ma facile da comprendere. Il diagramma dell'architettura di LoadRunner riportato di seguito mostra come i quattro componenti interagiscono tra loro.
Supponiamo che ti venga assegnato il compito di verificare le prestazioni di Amazon.com per 5000 utenti.
Nella realtà, tutti questi 5000 utenti non rimarranno sulla homepage, ma saranno distribuiti in diverse sezioni del sito web. Come possiamo quindi simulare questa differenza?
VuGen
VuGen o Utente Virtuale Generator è un IDE (Integrated Development Environment) o un editor di codice avanzato. VuGen viene utilizzato per replicare il comportamento di System Under Load (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.
Considerando l'esempio precedente, VuGen può registrare simulando i seguenti processi aziendali:
- Navigando nella Pagina Prodotti di Amazon.com
- Concludi ordine
- Processo di pagamento
- Controllo della pagina Il mio account
Una volta che lo script viene riprodotto correttamente, i valori dinamici del server devono essere acquisiti con correlazione prima che possa essere ampliato.
Controller
Una volta finalizzato uno script VUser, il Controller è uno dei componenti principali 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.
Riprendendo l'analogia del nostro esempio, il Controller aggiungerà i seguenti parametri allo script VuGen:
- 3500 utenti stanno navigando nella pagina dei prodotti di Amazon.com
- 750 utenti sono in fase di pagamento
- 500 utenti stanno eseguendo l'elaborazione dei pagamenti
- Solo 250 utenti stanno controllando la pagina del mio account dopo che 500 utenti hanno completato l'elaborazione del pagamento.
Sono possibili scenari ancora più complessi:
- Avvia 5 VUser ogni 2 secondi fino a un carico di 3500 VUser (navigazione Amazon pagina del prodotto) viene raggiunta.
- Ripetere per 30 minuti
- Sospende l'iterazione per 25 VUser
- Riavvia 20 utenti virtuali
- Avvia 2 utenti (in Checkout, Elaborazione pagamenti, Pagina MyAccount) ogni secondo.
- 2500 VUsers verranno generati sulla Macchina A
- 2500 VUser verranno generati sulla Macchina B
Agenti Macchina/Carico Generators/Iniettori
Il Controller di 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 simula. Inoltre, il Controller simula questi VUser dalla stessa macchina (dove risiede il Controller stesso) e quindi i risultati potrebbero non essere precisi. Per ovviare a questo problema, tutti i VUser vengono distribuiti su diverse macchine, chiamate LoadRunner. 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 è costituito da 5000 VUsers suddivisi tra due iniettori: 2500 VUsers generati sulla Macchina A e 2500 sulla Macchina B.
Analisi
Una volta eseguiti gli scenari di carico, il ruolo del Analisi il componente di LoadRunner entra in gioco.
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 di analisi legge questo file di database per eseguire vari tipi di analisi e generare 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, ma che il traffico dati superi tale capacità, causando disagi agli utenti successivi. Per determinare se il sistema soddisfa tali esigenze, l'ingegnere delle prestazioni deve analizzare il comportamento dell'applicazione con un carico anomalo. Di seguito è riportato un grafico generato da LoadRunner per rilevare la larghezza di banda.
Come eseguire i test delle prestazioni
La roadmap per i test di performance può essere suddivisa in 5 fasi principali, riassunte nella roadmap qui di seguito:
- Pianificazione del test di carico
- Creare script VuGen
- Creazione dello scenario
- Esecuzione dello scenario
- Analisi dei risultati (seguita dalla messa a punto del sistema)
Una volta installato LoadRunner, analizziamo nel dettaglio i passaggi del processo.
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 a utilizzare LoadRunner Testing, è consigliabile documentare chi parteciperà all'attività per ciascun team coinvolto nel processo, come illustrato nell'organigramma sottostante.
- Responsabile del progetto: Nominare il project manager che sarà proprietario di questa attività e fungerà da persona di riferimento per l'escalation.
- Esperto di funzione / Analista aziendale: Fornisce analisi sull'utilizzo della SUL e competenze sulle funzionalità aziendali del sito web o della SUL.
- Esperto di test delle prestazioni: Crea i test di performance automatizzati ed esegue scenari di carico.
- Sistema Architettare: Fornisce il progetto del SUL.
- Sviluppatore Web e PMI: Si occupa della manutenzione del sito web, del monitoraggio, dello sviluppo del sito e della correzione dei bug.
- Amministratore di sistema: Gestisce i server coinvolti durante l'intero progetto di test.
Descrivere 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 precedente, le cifre indicano il numero di utenti connessi all'applicazione (SUL) in una data ora. Possiamo esplicaretract indica il numero massimo di utenti connessi a un processo aziendale in qualsiasi ora del giorno, 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 una truffa finanziariatrace lo sottopone a revisione.
- Un altro utente 'B' approva 200 contracè un giorno creato dall'utente 'A'
- Un altro utente 'C' paga circa 150 contracè un giorno approvato dall'utente 'B'
In questa situazione, l'utente B deve avere 200 contracts 'creato' nel sistema. Inoltre, l'utente C ha bisogno di 150 contracts come “approvato” al fine di simulare un carico di 150 utenti.
Ciò significa implicitamente che devi creare almeno 200+150 = 350 contracts.
Dopodiché, approva 150 contracts per servire come dati di test per l'utente C – i restanti 200 contracts servirà come dati di test per l'utente B.
Monitor di contorno
Analizza ogni singolo fattore che potrebbe influenzare le prestazioni di un sistema. Ad esempio, una quantità ridotta di hardware potrebbe avere un impatto sulle prestazioni del sistema sotto carico (SUL).
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)
- Dati flux (Calcola la quantità di dati che vengono trasferiti tra client e server e viceversa, quindi verifica se la capacità della scheda di rete è sufficiente a simulare un numero X di utenti)
Passaggio 2) Creare gli script VuGen
Il passo successivo alla pianificazione è la creazione di script VUser, aggiungendo parametrizzazione, transazioni e impostazioni di runtime man mano che la sceneggiatura matura.
Passaggio 3) Creazione dello scenario
Il passo successivo consiste nel creare lo scenario di carico nel Controller, scegliendo tra uno scenario manuale e uno orientato agli obiettivi.
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 il blocco del server stress e comportandosi in modo anomalo. Questo è proprio lo scopo del Performance Testing. I risultati ottenuti vengono poi utilizzati per un'analisi dettagliata e per l'identificazione delle cause principali.
Passaggio 5) Analisi dei risultati (seguita dalla messa a punto del sistema)
Durante l'esecuzione dello scenario, LoadRunner registra le prestazioni dell'applicazione sotto diversi carichi. Le statistiche ricavate dall'esecuzione del test vengono salvate e viene eseguita un'analisi dettagliata. Lo strumento di analisi (denominato "HP Analysis" nelle versioni per cui è stata scritta questa guida) genera diversi grafici che aiutano a identificare le cause principali di un rallentamento delle prestazioni del sistema, nonché di un errore di 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
