Tag Archives: Test
ALM DOs and DON’Ts – Unit test
A unit test is a runnable piece of code that verifies that another piece of code (called production code) does what it is supposed to do. A unit test has many characteristics and one of the most important is that a single unit test must verify one and only one thing. If a unit test specifies more […]
Pillole di TFS/VSTS: pubblicazione risultati test in una build
Dall’introduzione del Visual Studio Test Runner, estendibile con plugin, non si ha più la difficoltà di eseguire Unit Test differenti da MSTest durante una build. Tradizionalmente le difficoltà incontrate erano due -) Eseguire i test a riga di comando con una personalizzazione della build -) Convertire il risultato dei test nel formato MSTest affinché potesse […]
Comments Off on Pillole di TFS/VSTS: pubblicazione risultati test in una build 
Cloud Load Test con Visual Studio Online – parte 2: Visual Studio
Questo articolo è il secondo di una serie di 3 in cui parlo del Cloud Load Testing con Visual Studio Online.
Nella prima parte abbiamo visto come eseguire dei semplici test di carico usando solamente il portale di VSO.
In questo articolo invece vedremo un soluzione più complessa (ma più completa), l’integrazione tra Visual Studio e Visual Studio Online.
Remainder
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante ricordare alcuni aspetti:
- Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
- L’applicazione da testare deve essere esposta sul web (visto che i test agent sono nel cloud e devono poter raggiungere l’applicazione)
- Gratuitamente si possono utilizzare fino a 20.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuti con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.
Inoltre, la funzionalità di Load test è disponibile solamente su Visual Studio Ultimate/Enterprise.
Fatte queste precisazioni, vediamo come si possono creare ed eseguire i test di carico con Visual Studio e Visual Studio Online.
Introduzione
Facendo un Load test con Visual Studio, avremo un sacco di impostazioni che potremo configurare. Si tratta quindi della soluzione più personalizzabile e configurabile per eseguire questo tipo di test.
Inoltre, dopo l’esecuzione avremo a disposizione molte informazioni, dati e grafici che ci permetterranno di capire come la nostra applicazione si comporta in uno scenario di carico.
Ultimo ma non per importanza, utilizzando VS possiamo fare un test multi step (multi pagina), anche con pagine sottoposte ad autenticazione, e possiamo registrare tutti i passaggi che vogliamo fare nell’applicazione allo stesso modo di come li farebbe l’utente (quindi non è richiesta configurazione manuale!).
Iniziamo
Prima di tutto dobbiamo creare un test project in Visual Studio. Il project template da usare è “Web Performance and Load Test Project”.
Quando clicchiamo sul bottone “Ok”, VS crea per noi una soluzione (come sempre) con all’iterno un progetto “WebTest1.webtest”. Non si tratta di un progetto di “Cloud Test”, bensì di un progetto “Web Performance”. Avremo bisogno di questo progetto per “istruire” il load test su cosa e come testare.
In alto a sinistra della schermata c’è un piccolo bottone con un grosso punto rosso: è il bottone che ci permette di resgistrare tutti gli step che faremo nella nostra applicazione.
Se clicchiamo su questo bottone, verrà aperto il browser (tipicamente IE) che avrà un piccolo pannello sulla sinistra. Si tratta del pannello che “fa il lavoro per noi”; è generato dal plugin “Web Test Recorder helper” che VS installa sulla nostra macchina.
Come nota a margine, ricordate di verificare che quel plugin sia abilitato sul browser altrimenti non verrà visualizzato nulla.
Ok, ora che la registrazione è attiva possiamo visitare ed usare l’applicazione che vogliamo testare esattamente come farebbe un normale utente. Possiamo anche eseguire azioni particolari se vogliamo testare qualche funzionalità o pagina specifica.
Per far iniziare la registrazione è sufficiente scrivere l’indirizzo dell’applicazione nella barra del browser ed iniziare ad usarla: il web recorder plugin farà tutto il resto.
Quando abbiamo finito, abbiamo cioè effettuato tutti gli step e le navigazioni che vogliamo testare, basta clicare sul bottone “Stop”. Abbiamo anche la possibilità di mettere in pausa la registrazione se magari non vogliamo registrare qualche step.
Mentre navighiamo la nostra applicazione, un sacco di “roba” viene aggiunta nel pannello di registrazione. Si tratta di tutte le richieste che la nostra applicazione fa.
Se ne selezioniamo una e clicchiamo sul bottone “comment” possiamo aggiungere un commento alla stessa che sarà possibile recuperare in un secondo momento.
Quando clicchiamo sul bottone “Stop”, succede “la magia”. Dapprima Visual Studio prende tutte le richieste e le informazioni dal web recorder plugin, le elabora e le inserisce nella finestra del webtest. Poi cerca di identificare se ci sono dei “parametri dinamici” nel nostro test.
I dynamic parameters sono tutti quei valori che possono cambiare se le richieste vengono fatte in momenti temporali differenti: user token, ricerche, autenticazioni, ecc. Se VS ne rileva qualcuno ci mostrerà una finestra in cui potremo decidere come e se utilizzarli. Possiamo selezionare di utilizzare per ogni iterazione di test esattamente quelli che sono stati registrati oppure se associare quei parametri ad una sorta di dizionario (che andremo a creare) da cui VS sceglierà di volta in volta valori differenti.
Un altro aspetto interessante che possiamo personalizzare riguarda i “Request details”. In questa finestra possiamo decidere se inserire dei “think time” tra le richieste (sostanzialmente dei ritardi) e, più importante, qual’è per noi il tempo “target” per le response. Se durante il test quella specifica richiesta avrà una response in un tempo maggiore di quello impostato come soglia, VS considererà il test come fallito.
Ora che abbiamo il webtest con tutti gli step ed i parametri impostati, possiamo finalmente aggiungere il progetto di Load Test alla nostra solution.
Il progetto di Load Test
Per aggiungere il test di carico ad un web performance test è sufficiente cliccare con il testo destro del mouse sul nome del progetto, scegliere “Add” e poi “Load test”.
Quest’azione farà comparire il “Load test wizard” che ci guiderà nel setup del test di carico.
Nel primo step dobbiamo scegliere se e come gestire i “think times” (i ritardi tra le request): possiamo usare gli stessi think time acquisiti durante la registrazione (attenzione che se mentre registravamo, tra un click e l’altro abbiamo fatto una pausa di ad esempio 5 minuti, durante il test quei 5 minuti saranno settati come delay tra quelle due richieste), possiamo scegliere “normal distribution” (che fa una sorta di media tra i tempi di delay registrati) oppure proprio di non usarne. Possiamo anche inserire un tempo di attesa tra iterazioni diverse dello stesso test.
Nel secondo step dobbiamo decidere quanto carico vogliamo generare verso la nostra applicazione e le modalità di generazione.
Possiamo selezionare di avere un carico costante (il test inizierà cioè con N utenti e continuerà con lo stesso numero di utenti fino alla fine) o di effetturare un test con “step load”.
Nell’immagine, ad esempio, ho deciso di utilizzare lo step load e di iniziare il test con 10 utenti aggiungendo ulteriori 10 utenti ogni 10 secondi, fino al raggiungimento di un massimo di 200 utenti.
Lo step load può essere molto interessante in quanto possiamo scoprire come (e se) la nostra applicazione scala in base all’incremento del carico applicativo.
Nello step successivo dobbiamo istruire il test di carico sul “cosa” fare. Per questa ragione inseriremo in questa schermata il web performance test che abbiamo creato precedentemente.
Cliccare su “Add”, selezionare il performance test che vogliamo, cliccare su “Ok” ed il test sarà aggiunto nella finestra “test mix”. Si chiama “Test Mix” perchè è possibile aggiungere quanti test vogliamo e se ne mettiamo più di uno possiamo definire la distribuzione percentuale di ognuno. In questo esempio abbiamo un solo test quindi la distribuzione sarà del 100%.
Possiamo anche decidere, negli step successivi, se e come utilizzare diversi tipi di connettività verso la nostra applicazione (attenzione: nel momento in cui scrivo VSO supporta solamente reti di tipo “LAN”) e che tipo di browser engine vogliamo che siano utilizzati dai test agent per effettuare le richieste.
Come potete vedere nell’immagine, possiamo scegliere da un elenco di molti browser ed anche in questo caso possiamo definire la distribuzione percentuale.
Nell’ultimo step possiamo personalizzare la durata dell’esecuzione del test.
Possiamo scegliere tra un tempo fisso oppure un numero di iterazioni di test. Se selezioniamo un tempo fisso (nel mio esempio 2 minuti), possiamo anche impostare un “Warm-up time” (10 secondi nell’esempio). Durante questo tempo verranno inviate alcune richieste all’applicazione per “risvegliarla” e non saranno collezionati dati. Questo comportamento è estremamente utile se dobbiamo testare applicazioni che necessitano di un cold start (come ad esempio webapp hostate su IIS che magari non sono state usate per un periodo di tempo e per le quali quindi IIS ha “disattivato” l’AppPool) per non avere dei falsi positivi nel risultato del test.
Cliccando su “Finish”, Visual Studio genererà il progetto di load test e lo salverà nella nostra soluzione.
Esecuzione del test
Ora che abbiamo tutto pronto possiamo eseguire il test. Ma prima, ancora un piccola impostazione. Noi vogliamo, infatti, che il test di carico sia eseguito attraverso la funzionalità Visual Studio Online Cloud Load Test ma nessuno l’ha detto al nostro Load Test project locale.
Per farlo bisogna aprire (doppo clic) il file “Local.testsettings” e cambiare il puntamento di “Test run location” su Visual Studio Online.
È da notare comunque che se abbiamo effettuato il login in Visual Studio con un account che ha una sottoscrizione a VSO questo step non sarà necessario in quanto VS seleziona direttamente questo valore per noi.
Ok, iniziamo il test cliccando sul bottone di start in alto a sinistra.
Ma cosa succede quando facciamo partire il test?
Visual Studio si connette a Visual Studio Online ed accoda il test. VSO poi crea on demand un lab virtual di test da qualche parte in un datacenter di Azure e configura i test agent sulle VM con i parametri settati.
Non appena il lab è pronto e configurato, il test parte. Se abbiamo configurato un periodo di warm up esso inizierà e potete vedere che non vengono collezionati dati.
Poi, finito il warm up, gli agenti iniziano a generare il traffico verso le pagine della nostra applicazione (così come utilizzate nella nostra registrazione) ed i risultati sono mandati al nostro Visual Studio quasi in tempo reale in modo da poter avere una preview del risultato finale del test.
Aspettiamo la fine del test per avere un resultset completo.
Risultati
Quando il test giunge al termine, verranno visualizzati tutti i risultati e le performance raggiunte. Le informazioni disponibili sono veramente moltissime.
Abbiamo i tempi di risposta medi, con anche il minimo ed il massimo, assieme ai tempi di test medi, i tempi di pagina medi ed il carico utente.
Possiamo vedere dal grafico e dalle info visualizzate che il numero di utenti virtuali è cresciuto nel tempo da 10 a 120 (avevo impostato un max di 200 ma non ha avuto tempo di raggiungere il massimo in quanto il test era limitato a soli 2 minuti con incrementi ogni 10 secondi) e come l’applicazione ha scalato al crescere del carico.
Anche nella sezione “Throughput” possiamo vedere molte informazioni utili.
In questo esempio non abbiamo avuto errori o parametri fuori soglia, ma se ci fossero stati avremmo visto un report degli stessi con le cause ed i messaggi di errore.
Questi sono però solo una piccola parte dei dati che abbiamo a disposizione. Se infatti clicchiamo sul link “download report” in alto, Visual Studio scaricherà l’intero resulset da Visual Studio Online rendendo disponibile, in questo modo, un report con una miriade di dati e grafici su ogni aspetto del test che ci aiuteranno a capire meglio come la nostra applicazione si comporta in uno scenario di carico.
Conclusioni
Questo tipo di Load test è il più completo che possiamo fare. Come potete vedere ci restituisce tantissime informazioni, metriche e grafici che ci permettono di analizzare il comportamento della nostra applicazione.
Inoltre, il setup di questi test è abbastanza semplice ma soprattutto è completamente personalizzabile ed in un poco tempo possiamo ottenere un gran numero di dati da poter consultare.
Il prossimo ed ultimo articolo di questa serie sarà sull’utilizzo delle Load Test APIs. Stay tuned! 
Cloud Load Test con Visual Studio Online – parte 2: Visual Studio
Questo articolo è il secondo di una serie di 3 in cui parlo del Cloud Load Testing con Visual Studio Online.
Nella prima parte abbiamo visto come eseguire dei semplici test di carico usando solamente il portale di VSO.
In questo articolo invece vedremo un soluzione più complessa (ma più completa), l’integrazione tra Visual Studio e Visual Studio Online.
Remainder
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante ricordare alcuni aspetti:
- Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
- L’applicazione da testare deve essere esposta sul web (visto che i test agent sono nel cloud e devono poter raggiungere l’applicazione)
- Gratuitamente si possono utilizzare fino a 20.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuti con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.
Inoltre, la funzionalità di Load test è disponibile solamente su Visual Studio Ultimate/Enterprise.
Fatte queste precisazioni, vediamo come si possono creare ed eseguire i test di carico con Visual Studio e Visual Studio Online.
Introduzione
Facendo un Load test con Visual Studio, avremo un sacco di impostazioni che potremo configurare. Si tratta quindi della soluzione più personalizzabile e configurabile per eseguire questo tipo di test.
Inoltre, dopo l’esecuzione avremo a disposizione molte informazioni, dati e grafici che ci permetterranno di capire come la nostra applicazione si comporta in uno scenario di carico.
Ultimo ma non per importanza, utilizzando VS possiamo fare un test multi step (multi pagina), anche con pagine sottoposte ad autenticazione, e possiamo registrare tutti i passaggi che vogliamo fare nell’applicazione allo stesso modo di come li farebbe l’utente (quindi non è richiesta configurazione manuale!).
Iniziamo
Prima di tutto dobbiamo creare un test project in Visual Studio. Il project template da usare è “Web Performance and Load Test Project”.
Quando clicchiamo sul bottone “Ok”, VS crea per noi una soluzione (come sempre) con all’iterno un progetto “WebTest1.webtest”. Non si tratta di un progetto di “Cloud Test”, bensì di un progetto “Web Performance”. Avremo bisogno di questo progetto per “istruire” il load test su cosa e come testare.
In alto a sinistra della schermata c’è un piccolo bottone con un grosso punto rosso: è il bottone che ci permette di resgistrare tutti gli step che faremo nella nostra applicazione.
Se clicchiamo su questo bottone, verrà aperto il browser (tipicamente IE) che avrà un piccolo pannello sulla sinistra. Si tratta del pannello che “fa il lavoro per noi”; è generato dal plugin “Web Test Recorder helper” che VS installa sulla nostra macchina.
Come nota a margine, ricordate di verificare che quel plugin sia abilitato sul browser altrimenti non verrà visualizzato nulla.
Ok, ora che la registrazione è attiva possiamo visitare ed usare l’applicazione che vogliamo testare esattamente come farebbe un normale utente. Possiamo anche eseguire azioni particolari se vogliamo testare qualche funzionalità o pagina specifica.
Per far iniziare la registrazione è sufficiente scrivere l’indirizzo dell’applicazione nella barra del browser ed iniziare ad usarla: il web recorder plugin farà tutto il resto.
Quando abbiamo finito, abbiamo cioè effettuato tutti gli step e le navigazioni che vogliamo testare, basta clicare sul bottone “Stop”. Abbiamo anche la possibilità di mettere in pausa la registrazione se magari non vogliamo registrare qualche step.
Mentre navighiamo la nostra applicazione, un sacco di “roba” viene aggiunta nel pannello di registrazione. Si tratta di tutte le richieste che la nostra applicazione fa.
Se ne selezioniamo una e clicchiamo sul bottone “comment” possiamo aggiungere un commento alla stessa che sarà possibile recuperare in un secondo momento.
Quando clicchiamo sul bottone “Stop”, succede “la magia”. Dapprima Visual Studio prende tutte le richieste e le informazioni dal web recorder plugin, le elabora e le inserisce nella finestra del webtest. Poi cerca di identificare se ci sono dei “parametri dinamici” nel nostro test.
I dynamic parameters sono tutti quei valori che possono cambiare se le richieste vengono fatte in momenti temporali differenti: user token, ricerche, autenticazioni, ecc. Se VS ne rileva qualcuno ci mostrerà una finestra in cui potremo decidere come e se utilizzarli. Possiamo selezionare di utilizzare per ogni iterazione di test esattamente quelli che sono stati registrati oppure se associare quei parametri ad una sorta di dizionario (che andremo a creare) da cui VS sceglierà di volta in volta valori differenti.
Un altro aspetto interessante che possiamo personalizzare riguarda i “Request details”. In questa finestra possiamo decidere se inserire dei “think time” tra le richieste (sostanzialmente dei ritardi) e, più importante, qual’è per noi il tempo “target” per le response. Se durante il test quella specifica richiesta avrà una response in un tempo maggiore di quello impostato come soglia, VS considererà il test come fallito.
Ora che abbiamo il webtest con tutti gli step ed i parametri impostati, possiamo finalmente aggiungere il progetto di Load Test alla nostra solution.
Il progetto di Load Test
Per aggiungere il test di carico ad un web performance test è sufficiente cliccare con il testo destro del mouse sul nome del progetto, scegliere “Add” e poi “Load test”.
Quest’azione farà comparire il “Load test wizard” che ci guiderà nel setup del test di carico.
Nel primo step dobbiamo scegliere se e come gestire i “think times” (i ritardi tra le request): possiamo usare gli stessi think time acquisiti durante la registrazione (attenzione che se mentre registravamo, tra un click e l’altro abbiamo fatto una pausa di ad esempio 5 minuti, durante il test quei 5 minuti saranno settati come delay tra quelle due richieste), possiamo scegliere “normal distribution” (che fa una sorta di media tra i tempi di delay registrati) oppure proprio di non usarne. Possiamo anche inserire un tempo di attesa tra iterazioni diverse dello stesso test.
Nel secondo step dobbiamo decidere quanto carico vogliamo generare verso la nostra applicazione e le modalità di generazione.
Possiamo selezionare di avere un carico costante (il test inizierà cioè con N utenti e continuerà con lo stesso numero di utenti fino alla fine) o di effetturare un test con “step load”.
Nell’immagine, ad esempio, ho deciso di utilizzare lo step load e di iniziare il test con 10 utenti aggiungendo ulteriori 10 utenti ogni 10 secondi, fino al raggiungimento di un massimo di 200 utenti.
Lo step load può essere molto interessante in quanto possiamo scoprire come (e se) la nostra applicazione scala in base all’incremento del carico applicativo.
Nello step successivo dobbiamo istruire il test di carico sul “cosa” fare. Per questa ragione inseriremo in questa schermata il web performance test che abbiamo creato precedentemente.
Cliccare su “Add”, selezionare il performance test che vogliamo, cliccare su “Ok” ed il test sarà aggiunto nella finestra “test mix”. Si chiama “Test Mix” perchè è possibile aggiungere quanti test vogliamo e se ne mettiamo più di uno possiamo definire la distribuzione percentuale di ognuno. In questo esempio abbiamo un solo test quindi la distribuzione sarà del 100%.
Possiamo anche decidere, negli step successivi, se e come utilizzare diversi tipi di connettività verso la nostra applicazione (attenzione: nel momento in cui scrivo VSO supporta solamente reti di tipo “LAN”) e che tipo di browser engine vogliamo che siano utilizzati dai test agent per effettuare le richieste.
Come potete vedere nell’immagine, possiamo scegliere da un elenco di molti browser ed anche in questo caso possiamo definire la distribuzione percentuale.
Nell’ultimo step possiamo personalizzare la durata dell’esecuzione del test.
Possiamo scegliere tra un tempo fisso oppure un numero di iterazioni di test. Se selezioniamo un tempo fisso (nel mio esempio 2 minuti), possiamo anche impostare un “Warm-up time” (10 secondi nell’esempio). Durante questo tempo verranno inviate alcune richieste all’applicazione per “risvegliarla” e non saranno collezionati dati. Questo comportamento è estremamente utile se dobbiamo testare applicazioni che necessitano di un cold start (come ad esempio webapp hostate su IIS che magari non sono state usate per un periodo di tempo e per le quali quindi IIS ha “disattivato” l’AppPool) per non avere dei falsi positivi nel risultato del test.
Cliccando su “Finish”, Visual Studio genererà il progetto di load test e lo salverà nella nostra soluzione.
Esecuzione del test
Ora che abbiamo tutto pronto possiamo eseguire il test. Ma prima, ancora un piccola impostazione. Noi vogliamo, infatti, che il test di carico sia eseguito attraverso la funzionalità Visual Studio Online Cloud Load Test ma nessuno l’ha detto al nostro Load Test project locale.
Per farlo bisogna aprire (doppo clic) il file “Local.testsettings” e cambiare il puntamento di “Test run location” su Visual Studio Online.
È da notare comunque che se abbiamo effettuato il login in Visual Studio con un account che ha una sottoscrizione a VSO questo step non sarà necessario in quanto VS seleziona direttamente questo valore per noi.
Ok, iniziamo il test cliccando sul bottone di start in alto a sinistra.
Ma cosa succede quando facciamo partire il test?
Visual Studio si connette a Visual Studio Online ed accoda il test. VSO poi crea on demand un lab virtual di test da qualche parte in un datacenter di Azure e configura i test agent sulle VM con i parametri settati.
Non appena il lab è pronto e configurato, il test parte. Se abbiamo configurato un periodo di warm up esso inizierà e potete vedere che non vengono collezionati dati.
Poi, finito il warm up, gli agenti iniziano a generare il traffico verso le pagine della nostra applicazione (così come utilizzate nella nostra registrazione) ed i risultati sono mandati al nostro Visual Studio quasi in tempo reale in modo da poter avere una preview del risultato finale del test.
Aspettiamo la fine del test per avere un resultset completo.
Risultati
Quando il test giunge al termine, verranno visualizzati tutti i risultati e le performance raggiunte. Le informazioni disponibili sono veramente moltissime.
Abbiamo i tempi di risposta medi, con anche il minimo ed il massimo, assieme ai tempi di test medi, i tempi di pagina medi ed il carico utente.
Possiamo vedere dal grafico e dalle info visualizzate che il numero di utenti virtuali è cresciuto nel tempo da 10 a 120 (avevo impostato un max di 200 ma non ha avuto tempo di raggiungere il massimo in quanto il test era limitato a soli 2 minuti con incrementi ogni 10 secondi) e come l’applicazione ha scalato al crescere del carico.
Anche nella sezione “Throughput” possiamo vedere molte informazioni utili.
In questo esempio non abbiamo avuto errori o parametri fuori soglia, ma se ci fossero stati avremmo visto un report degli stessi con le cause ed i messaggi di errore.
Questi sono però solo una piccola parte dei dati che abbiamo a disposizione. Se infatti clicchiamo sul link “download report” in alto, Visual Studio scaricherà l’intero resulset da Visual Studio Online rendendo disponibile, in questo modo, un report con una miriade di dati e grafici su ogni aspetto del test che ci aiuteranno a capire meglio come la nostra applicazione si comporta in uno scenario di carico.
Conclusioni
Questo tipo di Load test è il più completo che possiamo fare. Come potete vedere ci restituisce tantissime informazioni, metriche e grafici che ci permettono di analizzare il comportamento della nostra applicazione.
Inoltre, il setup di questi test è abbastanza semplice ma soprattutto è completamente personalizzabile ed in un poco tempo possiamo ottenere un gran numero di dati da poter consultare.
Il prossimo ed ultimo articolo di questa serie sarà sull’utilizzo delle Load Test APIs. Stay tuned!
Cloud Load Test con Visual Studio Online – parte 1: Web panel
Questo articolo è il primo di una serie di 3 in cui parlerò di Cloud Load Testing con Visual Studio Online.
In questa prima parte affronterò l’esecuzione di test di carico semplici su applicazioni web, utilizzando direttamente le funzionalità messe a disposizione dal portale di VSO.
Introduzione
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante soffermarsi su alcuni aspetti.
- Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
- L’applicazione da testare deve essere esposta sul web (al tool va indicato l’url da testare)
- Gratuitamente si possono utilizzare fino a 15.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuto con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.
Fatte queste precisazioni, vediamo come si possono eseguire i test di carico utilizzando l’iterfaccia presente sul portale di Visual Studio Online.
Iniziamo
Innanzitutto è necessario fare login al portale web di VSO e, dalla dashboard iniziale scegliere “Load test”.
Fatto questo viene proposta la finestra di impostazione delle variabili del test. Come vedete si tratta di un unica schermata, quindi le impostazioni possibili sono abbastanza limitate, ma comunque sufficienti a fare un test di carico generico sulla nostra applicazione.
Come prima cosa viene chiesto l’url su cui eseguire il test di carico: si tratta di un solo url (quindi non è possibile eseguire da qui un test di carico a step consecutivi o a navigazione pseudo-reale) che può corrispondere all’home page del sito o, come nell’esempio, ad una qualsiasi pagina della web application. L’unico vincolo presente è che la pagina deve essere visibile pubblicamente senza necessità di inserire delle credenziali, visto che al momento non è possibile impostarle.
Il secondo parametro da inserire è il nome del test: si tratta di una stringa libera, che servirà a noi solo come reminder.
Sotto questi due parametri ce ne sono altri 4, indicati proprio come “Test settings”, che servono per poter meglio definire gli aspetti chiave del carico che si vuole applicare.
- User Load: permette di definire il numero di utenti virtuali che contemporaneamente si collegheranno all’url fornito. I valori possibili sono 25, 50, 100 e 200
- Run duration: è la durata complessiva del test. I valori selezionabili sono da 1 a 5 minuti
- Think-time: si tratta del tempo di attesa tra una richiesta e l’altra. Serve per evitare che i sistemi di anti-hammering e anti DoS entrino in funzione. È possibile indicare tempi di attesa di 1 secondo (default) o 5 secondi
- Browser distribution: questa impostazione indica la percentuale di utilizzo di browser che si vuole simulare. Scegliendo ad esempio “IE 80%, Chrome 20%” il test verrà eseguito con agenti useranno gli engine di Internet Explorer e di Chrome nelle percentuali selezionate
Settate queste impostazioni, cliccando sul bottone “Test now” si da inizio al test.
Esecuzione del Test
Ma cosa avviene, nel concreto quando si avvia il test?
Visual Studio Online crea per noi on demand un lab virtuale in un datacenter su Azure e configura gli agenti sulle vm con i parametri indicati:
Non appena il lab è pronto e configurato, inizia il vero e proprio test di carico. Gli agenti iniziano a generare traffico verso l’url indicato e i risultati sono inviati, quasi in real time, al nostro browser. In questo modo possiamo avere un’anteprima dell’esito del test.
In questa immagine vediamo, ad esempio, che intorno ai 50 secondi si è verificato “un buco” nelle richieste al secondo che il sito è risucito a gestire, testimoniato anche dal notevole incremento del tempo di risposta. Utilizzando questi dati potremmo avviare un’attività di analisi sulla nostra applicazione o sulla nostra infrastruttura per capire come mai si sia verificata un’anomalia del genere.
Risultati
Al completamento del test, ci vengono indicati gli esiti e le performance raggiunte.
Oltre al grafico che avevamo anche durante l’esecuzione ci vengono date altre informazioni.
Innanzitutto ci viene data l’indicazione tel tempo di risposta medio. Un tempo medio inferiore a 0,1 secondi è considerato buono. tra 1 secondo e 0,1 secondi è considerato “non molto buono”, sopra il secondo è considerato negativo.
Dopo il tempo di risposta, è indicato il numero di richieste che in totale sono state fatte alla web app.
Infine, c’è l’indicazione delle eventuali richieste che non sono andate a buon fine o che hanno generato un errore sull’applicazione.
Sotto questi valori viene indicato anche quali errori sono stati riscontrati.
In questo caso non ve ne sono, se si fossero verificati degli errori nella tabella troveremmo la causa generica dell’errore, il suo tipo specifico ed il messaggio di errore.
Conclusioni
Questo tipo di Load test non è sicuramente il più completo che si possa ottenere, ma va comunque bene se ci interessa avere delle indicazioni di massima sulle prestazioni e sul carico supportato dalla nostra applicazione.
Inoltre il setup di questi test è estremamente semplice e in pochissimi minuti si è in grado di avere un gran numero di informazioni utili.
Se quello di cui avete bisogno, invece, è un test approfondito, eseguibile simulando un flusso reale di navigazione… non perdetevi il mio prossimo articolo di questa serie.
Cloud Load Test con Visual Studio Online – parte 1: Web panel
Questo articolo è il primo di una serie di 3 in cui parlerò di Cloud Load Testing con Visual Studio Online.
In questa prima parte affronterò l’esecuzione di test di carico semplici su applicazioni web, utilizzando direttamente le funzionalità messe a disposizione dal portale di VSO.
Introduzione
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante soffermarsi su alcuni aspetti.
- Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
- L’applicazione da testare deve essere esposta sul web (al tool va indicato l’url da testare)
- Gratuitamente si possono utilizzare fino a 15.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuto con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.
Fatte queste precisazioni, vediamo come si possono eseguire i test di carico utilizzando l’iterfaccia presente sul portale di Visual Studio Online.
Iniziamo
Innanzitutto è necessario fare login al portale web di VSO e, dalla dashboard iniziale scegliere “Load test”.
Fatto questo viene proposta la finestra di impostazione delle variabili del test. Come vedete si tratta di un unica schermata, quindi le impostazioni possibili sono abbastanza limitate, ma comunque sufficienti a fare un test di carico generico sulla nostra applicazione.
Come prima cosa viene chiesto l’url su cui eseguire il test di carico: si tratta di un solo url (quindi non è possibile eseguire da qui un test di carico a step consecutivi o a navigazione pseudo-reale) che può corrispondere all’home page del sito o, come nell’esempio, ad una qualsiasi pagina della web application. L’unico vincolo presente è che la pagina deve essere visibile pubblicamente senza necessità di inserire delle credenziali, visto che al momento non è possibile impostarle.
Il secondo parametro da inserire è il nome del test: si tratta di una stringa libera, che servirà a noi solo come reminder.
Sotto questi due parametri ce ne sono altri 4, indicati proprio come “Test settings”, che servono per poter meglio definire gli aspetti chiave del carico che si vuole applicare.
- User Load: permette di definire il numero di utenti virtuali che contemporaneamente si collegheranno all’url fornito. I valori possibili sono 25, 50, 100 e 200
- Run duration: è la durata complessiva del test. I valori selezionabili sono da 1 a 5 minuti
- Think-time: si tratta del tempo di attesa tra una richiesta e l’altra. Serve per evitare che i sistemi di anti-hammering e anti DoS entrino in funzione. È possibile indicare tempi di attesa di 1 secondo (default) o 5 secondi
- Browser distribution: questa impostazione indica la percentuale di utilizzo di browser che si vuole simulare. Scegliendo ad esempio “IE 80%, Chrome 20%” il test verrà eseguito con agenti useranno gli engine di Internet Explorer e di Chrome nelle percentuali selezionate
Settate queste impostazioni, cliccando sul bottone “Test now” si da inizio al test.
Esecuzione del Test
Ma cosa avviene, nel concreto quando si avvia il test?
Visual Studio Online crea per noi on demand un lab virtuale in un datacenter su Azure e configura gli agenti sulle vm con i parametri indicati:
Non appena il lab è pronto e configurato, inizia il vero e proprio test di carico. Gli agenti iniziano a generare traffico verso l’url indicato e i risultati sono inviati, quasi in real time, al nostro browser. In questo modo possiamo avere un’anteprima dell’esito del test.
In questa immagine vediamo, ad esempio, che intorno ai 50 secondi si è verificato “un buco” nelle richieste al secondo che il sito è risucito a gestire, testimoniato anche dal notevole incremento del tempo di risposta. Utilizzando questi dati potremmo avviare un’attività di analisi sulla nostra applicazione o sulla nostra infrastruttura per capire come mai si sia verificata un’anomalia del genere.
Risultati
Al completamento del test, ci vengono indicati gli esiti e le performance raggiunte.
Oltre al grafico che avevamo anche durante l’esecuzione ci vengono date altre informazioni.
Innanzitutto ci viene data l’indicazione tel tempo di risposta medio. Un tempo medio inferiore a 0,1 secondi è considerato buono. tra 1 secondo e 0,1 secondi è considerato “non molto buono”, sopra il secondo è considerato negativo.
Dopo il tempo di risposta, è indicato il numero di richieste che in totale sono state fatte alla web app.
Infine, c’è l’indicazione delle eventuali richieste che non sono andate a buon fine o che hanno generato un errore sull’applicazione.
Sotto questi valori viene indicato anche quali errori sono stati riscontrati.
In questo caso non ve ne sono, se si fossero verificati degli errori nella tabella troveremmo la causa generica dell’errore, il suo tipo specifico ed il messaggio di errore.
Conclusioni
Questo tipo di Load test non è sicuramente il più completo che si possa ottenere, ma va comunque bene se ci interessa avere delle indicazioni di massima sulle prestazioni e sul carico supportato dalla nostra applicazione.
Inoltre il setup di questi test è estremamente semplice e in pochissimi minuti si è in grado di avere un gran numero di informazioni utili.
Se quello di cui avete bisogno, invece, è un test approfondito, eseguibile simulando un flusso reale di navigazione… non perdetevi il mio prossimo articolo di questa serie.
Perché non posso cancellare un Test Plan con TFS2013 Update 3
Se avete aggiornato TFS 2013 con update 3 o successivi ed usate Microsoft Test Manager, probabilmente vi sarete accorti che non più possibile cancellare un Test Plan da MTM. La ragione è da ricercarsi nella modifica introdotta con Update 3, che trasforma i Test Plan in Work Item veri e propri. In TFS non è […]
Comments Off on Perché non posso cancellare un Test Plan con TFS2013 Update 3
Eseguire il code coverage dei test durante una build di TFS 2012
Una domanda abbastanza comune che viene spesso fatta è: Come abilito il code coverage durante una bulid di TFS 2012? In realtà l’opzione di code coverage fa parte dei Run Settings dei test, che di base nella build sono configurati come “default”. Non esiste quindi un settaggio esplicito del tipo “analyze code coverage”, ma è […]
Cross browser testing con Coded UI Test
I Coded UI Test, conosciuti anche come CUIT sono una tecnologia di Visual Studio che permette di registrare l’interazione Uomo Macchina al fine di effettuare il replay delle azioni su di un software, e creare quindi un test di integrazione che interagisca con il proprio software e ne verifichi il funzionamento. La parte interessante di […]
Login