Test Web a più passaggi

È possibile monitorare una sequenza registrata di URL e interazioni con un sito Web tramite test Web a più passaggi. Questo articolo illustra il processo di creazione di un test Web a più passaggi con Visual Studio Enterprise.

Importante

I test Web a più passaggi sono stati deprecati. È consigliabile usare TrackAvailability per inviare test di disponibilità personalizzati anziché test Web in più passaggi. Con TrackAvailability() e i test di disponibilità personalizzati, è possibile eseguire test in qualsiasi computer desiderato e usare C# per creare facilmente nuovi test.

I test Web a più passaggi sono classificati come test classici e sono disponibili in Aggiungi test classico nel riquadro Disponibilità .

Nota

I test Web a più passaggi non sono supportati nel cloud Azure per enti pubblici.

Alternativa al test Web multistep

I test Web a più passaggi dipendono dai file di test Web di Visual Studio. È stato annunciato che Visual Studio 2019 sarà l'ultima versione con funzionalità di test Web. Anche se non verranno aggiunte nuove funzionalità, la funzionalità di test Web in Visual Studio 2019 è ancora supportata e continuerà a essere supportata durante il ciclo di vita del prodotto.

È consigliabile usare TrackAvailability per inviare test di disponibilità personalizzati anziché test Web a più passaggi. Questa opzione è la soluzione supportata a lungo termine per scenari di test con più richieste o autenticazione. Con TrackAvailability() e i test di disponibilità personalizzati, è possibile eseguire test in qualsiasi computer desiderato e usare C# per creare facilmente nuovi test.

Prerequisiti

È necessario:

• Visual Studio 2017 Enterprise o versioni successive.
• Strumenti per test di carico e delle prestazioni Web di Visual Studio.

Per individuare i prerequisiti degli strumenti di test, selezionare Programma di installazione di Visual Studio>Compensindividuali>Debug e testdelle prestazioni Web e degli> strumenti di test di carico.

Nota

Ai test Web multistep sono associati costi aggiuntivi. Per altre informazioni, vedere la guida ufficiale ai prezzi.

Registrare un test Web a più passaggi

Avviso

Non è più consigliabile usare il registratore multistep. Il registratore è stato sviluppato per le pagine HTML statiche con interazioni di base. Non offre un'esperienza funzionale per le pagine Web moderne.

Per indicazioni su come creare test Web di Visual Studio, vedere la documentazione ufficiale di Visual Studio 2019.

Caricare il test Web

1. Nel portale di Application Insights nel riquadro Disponibilità selezionare Aggiungi test classico. Selezionare quindi Multi-step come SKU.
2. Caricare il test Web a più passaggi.
3. Impostare le posizioni di test, la frequenza e i parametri di avviso.
4. Selezionare Crea.

Frequenza e posizione

Impostazione	Descrizione
Frequenza prova	impostare la frequenza di esecuzione del test da ogni località di test. Con una frequenza predefinita di cinque minuti e cinque località di test, il sito verrà testato in media ogni minuto.
Località di test	I luoghi da cui i server inviano richieste Web all'URL. Il numero minimo di percorsi di test consigliati è cinque per garantire che sia possibile distinguere i problemi nel sito Web dai problemi di rete. È possibile selezionare fino a 16 località.

Criteri di superamento

Impostazione	Descrizione
Timeout test	ridurre questo valore per ricevere avvisi in merito alle risposte lente. Il test viene conteggiato come errore se le risposte del sito non sono state ricevute entro questo periodo. Se è stata selezionata l'opzione Analizza richieste dipendenti, tutte le immagini, i file di stile, gli script e altre risorse dipendenti devono essere state ricevute entro questo periodo.
Risposta HTTP	Codice di stato restituito che viene conteggiato come operazione riuscita. Il codice 200 indica che è stata restituita una normale pagina Web.
Corrispondenza contenuto	Stringa, ad esempio "Welcome!" Si verifica una corrispondenza esatta con distinzione tra maiuscole e minuscole in ogni risposta. Deve trattarsi di una stringa di testo normale, senza caratteri jolly. Non dimenticare che se il contenuto della pagina cambia, potrebbe essere necessario aggiornarlo. Solo i caratteri inglesi sono supportati con la corrispondenza del contenuto.

Avvisi

Impostazione	Descrizione
Quasi in tempo reale (anteprima)	È consigliabile usare avvisi quasi in tempo reale. La configurazione di questo tipo di avviso viene eseguita dopo la creazione del test di disponibilità.
Soglia località di avviso	Si consiglia un minimo di 3-5 posizioni. La relazione ottimale tra la soglia di posizione degli avvisi e il numero di percorsi di test è ilnumero soglia diposizione = degli avvisi - 2, con un minimo di cinque posizioni di test.

Configurazione

Seguire questa procedura di configurazione.

Inserire i numeri casuali e il tempo nel test

Si supponga di testare uno strumento che ottiene dati dipendenti dal tempo, ad esempio i prezzi delle azioni, da un feed esterno. Quando si registra il test Web, è necessario usare orari specifici, ma è necessario impostarli come parametri del test StartTime e EndTime.

Quando si esegue il test, si vuole EndTime sempre essere l'ora corrente. StartTime deve essere 15 minuti prima.

Il plug-in Data e ora test Web consente di gestire i tempi dei parametri.

1. Aggiungere un plug-in test Web per ogni valore di parametro di variabile desiderato. Sulla barra degli strumenti del test Web selezionare Aggiungi plug-in test Web.

   

   In questo esempio vengono usate due istanze di Plug-in data e ora, Un'istanza è per "15 minuti fa" e un'altra è per "ora".

2. Aprire le proprietà di ciascun plug-in. Assegnare un nome al plug-in e impostarlo in modo che usi l'ora corrente. Per uno di essi, impostare Aggiungi minuti = -15.

   

3. Nei parametri di test Web usare {{plug-in name}} per fare riferimento a un nome di plug-in.

   

Caricare quindi il test nel portale. Userà valori dinamici in ogni esecuzione del test.

Prendere in considerazione l'accesso

Se gli utenti accedono all'app, è possibile simulare l'accesso in vari modi per testare le pagine usate per l'accesso. L'approccio da preferire dipende dal tipo di sicurezza fornito dall'app.

In tutti i casi, creare un account nell'applicazione solo per il test. Se possibile, limitare le autorizzazioni dell'account di test in modo che i test Web non possano influire in alcun modo sugli utenti reali.

Nome utente e password semplici

Registrare un test Web nel modo consueto. Eliminare prima di tutto i cookie.

SAML Authentication

Nome proprietà	Descrizione
URI del pubblico	URI del destinatario per il token SAML. Questo URI è per il servizio Controllo di accesso, incluso lo spazio dei nomi Controllo di accesso e il nome host.
Password certificato	Password per il certificato client, che concederà l'accesso alla chiave privata incorporata.
Certificato client	Valore del certificato client con chiave privata in formato con codifica Base64.
Identificatore del nome	Identificatore del nome per il token.
Non dopo	Periodo di validità del token. Il valore predefinito è 5 minuti.
Non prima	Periodo di validità di un token creato nel passato (per risolvere gli sfasamenti dell'ora). Il valore predefinito è (negativo) 5 minuti.
Nome del parametro di contesto di destinazione	Parametro di contesto che riceverà l'asserzione generata.

Segreto client

Se l'app ha un percorso di accesso che prevede un segreto client, usare tale percorso. Azure Active Directory (Azure AD) è un esempio di servizio che fornisce un accesso segreto client. In Azure AD il segreto client è la chiave dell'app.

Ecco un test Web di esempio di un'app Web di Azure usando una chiave dell'app.

1. Ottenere un token da Azure AD usando il segreto client (chiave dell'app).
2. Estrarre un token di connessione dalla risposta.
3. Chiamare l'API usando il token di connessione nell'intestazione di autorizzazione.
4. Assicurarsi che il test Web sia un client effettivo. Vale a dire che ha la propria app in Azure AD. Usare l'ID client e la chiave dell'app. Il servizio sottoposto a test dispone anche di una propria app in Azure AD. L'URI ID app di questa app viene riflesso nel test Web nel campo risorsa.

Aprire l'autenticazione

Un esempio di autenticazione aperta è l'atto di accedere con l'account Microsoft o Google. Molte app che usano OAuth offrono l'alternativa del segreto client ed è quindi consigliabile ricercare prima di tutto tale possibilità.

Se il test deve accedere usando OAuth, l'approccio generale è:

1. Usare uno strumento come Fiddler per esaminare il traffico tra il Web browser, il sito di autenticazione e l'app.
2. Eseguire due o più accessi usando computer o browser diversi oppure a distanza di tempo, per lasciar scadere i token.
3. Confrontando diverse sessioni, identificare il token passato di nuovo dal sito di autenticazione passato al server app dopo l'accesso.
4. Registrare un test Web usando Visual Studio.
5. Parametrizzare i token. Impostare il parametro quando il token viene restituito dall'autenticatore e usarlo nella query sul sito. Visual Studio tenta di parametrizzare il test, ma non parametrizza correttamente i token.

Risoluzione dei problemi

Per la guida alla risoluzione dei problemi, vedere l'articolo sulla risoluzione dei problemi dedicato.

Passaggi successivi

• Panoramica della disponibilità
• Avvisi di disponibilità