Boso Consulting
Transcript
Boso Consulting
Verificare la qualità delle applicazioni Web e Client/Server: i test di carico Cos'è un test di carico È una verifica delle prestazioni di una determinata un'applicazione Web in condizioni di carico. Idealmente, questa verifica dovrebbe essere fatta al momento di andare in produzione, per verificare la effettiva capacità del sistema complessivo (composto dalle applicazioni, dal middleware e dall'hardware su cui queste sono installate) di servire gli utenti previsti. Perché fare un test di carico: le esigenze Molteplici sono le situazioni che richiedono un test di carico: ➢“Sto preparando il nuovo portale, ora gli utenti vorranno usare le nuove funzioni molto più spesso: quanti server devo prevedere?” ➢“I miei clienti potranno vedere le consegne via web, ma l'applicazione di magazzino che le gestisce riuscirà a soddisfare le richieste?” ➢“Come si comporterà il mio gestore documentale con l'introduzione della nuova applicazione intranet?” ➢“La nuova applicazione riuscirà a gestire il traffico previsto?” ➢“Devo verificare che le prestazioni attuali siano costanti nel tempo!” ➢“Riuscirà il mio CRM a gestire i tablet in dotazione alla forza vendita? Si potrebbero aggiungere molti altri casi.... Importanza delle performances applicative Tutti questi scenari hanno in comune l'importanza fondamentale del buon funzionamento e della facilità d'uso dell'applicazione: Load Generator Generatore di traffico Application server DataBase server Sistema sotto test Concretamente, il test si svolge utilizzando appositi software che sono in grado di simulare il comportamento di molti utenti in modo parallelo, raccogliendo i dati sulle risposte ricevute. Chiaramente, l'utilità è massima quando gli utenti sono molti, dispersi e non facilmente coordinabili: in questo caso infatti non è possibile dire semplicemente: ”domani a quest'ora, tutti devono fare delle prove sul nuovo sistema”: generalmente, si ha un'interazione ed un controllo molto “debole” nei confronti degli utenti di applicazioni web, ed ancora meno su quelli che fanno uso di dispositivi mobili (smartphone e tablet). Fortunatamente, esistono strumenti open source potenti ed efficienti per risolvere questo problema: ➢la potenza è necessaria per simulare un numero di utenti molto elevato, senza incorrere in limitazioni pratiche: se necessario, è possibile utilizzare più server per eseguire uno stesso script; ➢l'efficienza invece consente di scrivere e provare velocemente i test in modo rapido, partendo dalla registrazione del comportamento dell'utente “reale”. L'efficienza di questa attività dipende molto dallo strumento utilizzato. I più diffusi pacchetti commerciali hanno costi di licenza molto alti, tipicamente legati al numero di utenti simulati. Inoltre, trattandosi di prodotti di nicchia, il supporto che si riceve è abbastanza lento e tipicamente in lingua inglese. Jmeter invece è un prodotto open source, quindi gratuito, è completamente scritto in Java e riceve supporto da una comunità di utenti molto attiva. Inoltre, sulla base delle esperienze precedenti, si propone una metodologia, una documentazione e dei template che riducono tempi e costi; in questo modo si elimina l'impegno richiesto ai clienti finali per effettuare il test. La soluzione proposta consente di effettuare test si applicazione Web. ➢se l'utente è un cliente esterno, esiste un ampia letteratura1 che dimostra che una lentezza anche minima, si traduce in disaffezione e perdita di fatturato; ➢se l'utente è un dipendente o un interno invece, il danno si misura in termini di perdita di produttività; anche in questo caso esistono studi 2 ben documentati; ➢in tutti i casi, l'introduzione di una nuova applicazione è un momento molto critico: se gli utenti, che hanno sempre una naturale resistenza al cambiamento, incontrano dei problemi tecnici anche marginali, diventa poi molto difficile recuperare la loro fiducia. Per tutti questi motivi, una verifica delle prestazioni preliminare al lancio in produzione costituisce un necessità imprescindibile, esattamente quanto il test funzionale. Scopo e interlocutori L'obbiettivo del test quindi è chiaro: garantire che l'insieme costituito dall'applicazione e dall'infrastruttura) offra le performance corrette. Può essere utile riflettere sui ruoli che hanno maggiormente l'esigenza di effettuare questi test: il primo interlocutore di solito è il responsabile dell'esercizio che usa il test di carico per: ➢validare una nuova infrastruttura/ installazione ➢validare un nuovo rilascio ➢analizzare e ottimizzare l'infrastruttura esistente ➢individuare problemi che si manifestano sotto carico (tipicamente come malfunzionamenti casuali) Dal punto di vista della tipologia di azienda, l'interesse è massimo per i centri servizi (per esempio bancari, o internet service provider), i system integrator, e le software house che rilasciano un nuovo software di base e devono fornire una sizing guide e le indicazioni per il tuning. 1 2 http://glinden.blogspot.it/2006/11/marissa-mayer-at-web-20.html http://www.websiteoptimization.com/speed/tweak/psychology-webperformance/ http://www.vm.ibm.com/devpages/jelliott/evrrt.html Standard di riferimento Non esistono al momento degli standard specifici in questo settore, sia a causa della rapida evoluzione delle tecnologie connesse, che della obbiettiva difficoltà di normare esigenze ed applicazioni molto diverse. Le normative di interesse si esprimono in termini generali e sono raccolte nella seguente tabella. Standard Note ISO 27001 (SGSI), Prescrivono “capacity control and management” e “service validation” ITIL Due aree fanno riferimento ai test di carico: • Capacity management (part of Service Design) • Service validation (part of Service Transition) ll test di carico verifica la rispondenza del servizio implementato rispetto ai requisiti richiesti. ISTQB L'International Software Testing Qualifications Board si occupa delle metodologie di test software, e dedica un breve paragrafo del suo silllabo al “Testing di caratteristiche software non funzionali (testing non funzionale)” Metodologia e contenuti dei test La metodologia ISTQB adottata è relativamente semplice si struttura in 5 punti: 1. Pianificazione e controllo 2. Analisi e progettazione, che comprende: a) Verifica Tecnica e funzionale b) Individuazione delle misure da effettuare c) Definizione degli obbiettivi di prestazione 3. Implementazione ed esecuzione, che comprende: a) Predisposizione dell'infrastruttura necessaria al test b) Preparazione degli script c) Esecuzione baseline (valori di riferimento) d) Esecuzione del test 4. Analisi dei risultati e stesura del report, con feedback e raccomandazioni sull'infrastruttura. 5. Attività di conclusione dei test (verbalizzazione wrap-up) Il seguente diagramma di Gantt presenta una distribuzione “tipica” dei tempi tra le diverse fasi. 1 2 3 4 5 6 7 8 9 10 11 12 Pianificazione e controllo Analisi e progettazione Implementazione script Esecuzione baseline Esecuzione del test Stesura di un rapporto Attività di conclusione Spesso si ripete un ciclo tra le operazioni di test (3D) e l'analisi dei risultati (4), per verificare l'efficacia delle azioni di ottimizzazione, tuning e potenziamento intraprese. Nel dettaglio, le fasi più significative comprendono: 1) Pianificazione e controllo: Garantiscono che le attività di test siano attivate e condotte in modo tempestivo e coerenterispetto al progetto globale. 2) Analisi e progettazione, Anche se l'analisi iniziale talvolta viene trascurata,iI realtà un buon piano di test deve porsi degli obbiettivi significativi (stimando le funzionalità maggiormente utilizzate) e realistici (approssimando al meglio le condizioni reali del carico). Un test di carico ha una copertura molto più ridotta del test funzionale: è comune il caso di testare solo un 20% delle funzioni previste, che spesso rappresentano oltre il 90% delle operazioni effettuate. Di solito, si parte da una valutazione delle statistiche attuali, considerando: • le pagine /funzioni più utilizzate (volume) • le funzioni più “pesanti” o di maggior valore • i momenti di maggior traffico (quarto d'ora di picco) L'individuazione delle funzioni “di valore” è molto importante, e richiede una conoscenza ed una comprensione degli aspetti di business, ma anche degli impatti sull'usabilità: gli utenti sono più disponibili ad un'attesa per ricevere informazioni per loro importanti. Vanno considerate anche le evoluzioni future. La stima di queste variazioni è spesso difficile perché non può basarsi su dati storici e deve essere condivisa con le linee di business. Infine, come sintesi di tutti le considerazioni su riportate, vengono definiti gli obbiettivi: ➢ ➢ ➢ Volumi da erogare (volume target) Mix di operazioni Tempi di risposta richiesti Durante la fase di analisi vengono stesi anche i requisiti materiali per l'esecuzione del test: il numero di macchine per generare il traffico, le utenze necessarie (con le relative credenziali ) ed eventualmente i dati che devono essere pre-caricati. È importante ricordare che lo scopo dei test non è quello di individuare il punto di rottura, ma di verificare che il sistema regga il carico per cui è stato progettato. 3B) Preparazione degli script Spesso questa è la fase temporalmente più lunga e laboriosa. Normalmente, partendo dai percorsi di navigazione definiti nella fase di analisi si registrano le transazioni web e quindi si procede ad una parametrizzazione di questi percorsi, variando i parametri (si pensi alle query, al caricamento di dati e di files, ecc.). 3C) esecuzione della baseline Una volta realizzato lo script, si esegue un primo test, creando il minor impatto possibile sul sistema sotto test. In questo modo si verifica il corretto funzionamento dello script e contemporaneamente si raccolgono i tempi di risposta in una situazione ottimale: si verifica quindi se il sistema è in grado di eseguire il Mix di operazioni previsto con i tempi di risposta richiesti, con carico ridotto. La baseline costituisce il riferimento per tutti i test successivi. 3D) Esecuzione A questo punto si esegue il test vero e proprio, imponendo carichi via via crescenti. Spesso il carico viene espresso in rapporto al volume target: tipicamente si fanno prove al 60%, 80%, 100% e 120% del target, monitorando le prestazioni (tempi di risposta) e lo stato dei sistemi sotto test (CPU, RAM, traffico verso i dischi e verso la LAN). Si ottengono pertanto dei test “a gradini”, con carico crescente. In altri casi si eseguono dei test di endurance, verificando il comportamento sotto carico per periodi prolungati. 5) Analisi dei risultati e stesura del report, Man mano che si eseguono i test, i dati più significativi vengono raccolti ed inseriti nel rapporto finale. Talvolta, nei casi più complessi, può essere necessario eseguire più cicli di analisi-realizzazione-esecuzione, particolarmente in quei casi in cui il contesto non è ancora definito: per esempio se l'applicazione è ancora in sviluppo o il modello di utilizzo non è noto, o l'infrastruttura finale non è disponibile. I dati ottenuti e presentati possono essere di vario tipo: ➢ Analisi dei tempi di risposta al crescere del carico; ➢ Analisi dei tempi di risposta nel tempo ➢ Analisi dei tasso di errore ➢ Analisi per scenario, in cui si analizzano le performance a carico costante, variando alcune caratteristiche del sistema sotto test. ➢ Analisi delle risorse impiegate: la figura seguente evidenzia il carico di CPU rilevato durante un test a gradini 120,00% 800 700 100,00% 600 80,00% 500 60,00% 400 300 40,00% 200 20,00% 100 0,00% 0 Costi Ogni test ha una forte componente progettuale: ogni caso è storia a sé per le esigenze ed i risultati che si pone. La valutazione economica viene definita solo dopo una breve analisi preliminare, che richiede un accesso al sito per una verifica tecnica. Contatti Web Mail Mob www.bosoconsulting.it [email protected] +39 335 7243 445 boso_wload_v1.3.odt