Test Web a più passaggi
È possibile monitorare una sequenza registrata di URL e interazioni con un sito Web tramite test Web con più passaggi. Questo articolo illustra il processo di creazione di un test Web con più passaggi con Visual Studio Enterprise.
Importante
I test Web con 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 con più passaggi sono classificati come test classici e sono disponibili in Aggiungi test classico nel riquadro Disponibilità .
Nota
I test Web con più passaggi non sono supportati nel cloud Azure per enti pubblici.
Alternativa al test Web a più passaggi
I test Web con 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 con 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> Componentividuali>Debug e test>delle prestazioni Web e degli strumenti di test di carico.
Nota
I test Web con più passaggi hanno costi aggiuntivi associati. Per altre informazioni, vedere la guida ufficiale ai prezzi.
Importante
Il test Web in più passaggi si basa sull'infrastruttura DNS della rete Internet pubblica per risolvere i nomi di dominio degli endpoint testati. Se si usa un DNS privato, è necessario assicurarsi che i server dei nomi di dominio pubblici possano risolvere ogni nome di dominio del test. Quando ciò non è possibile, usare i test TrackAvailability personalizzati.
Registrare un test Web a più passaggi
Avviso
Non è più consigliabile usare il registratore a più passaggi. Il registratore è stato sviluppato per 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
- Nel portale di Application Insights nel riquadro Disponibilità selezionare Aggiungi test classico. Selezionare quindi Multi-step come SKU.
- Caricare il test Web a più passaggi.
- Impostare le posizioni di test, la frequenza e i parametri di avviso.
- Seleziona Crea.
Frequenza e posizione
| Impostazione | Descrizione |
|---|---|
| Frequenza test | 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 assicurarsi di poter distinguere i problemi nel sito Web dai problemi di rete. È possibile selezionare fino a 16 località. |
Criteri di successo
| Impostazione | Descrizione |
|---|---|
| Timeout test | ridurre questo valore per ricevere avvisi in merito alle risposte lente. Il test viene conteggiato come errore se le risposte dal 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. |
| Il contenuto corrisponde a | 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. Il rapporto ottimale tra la soglia località di avviso e il numero di località di test è dato da soglia località di avviso = numero di località di test - 2, con un numero minimo pari a cinque località di test. |
Impostazione
Seguire questa procedura di configurazione.
Collegare i numeri casuali e il tempo al test
Si supponga di testare uno strumento che ottiene dati dipendenti dal tempo, ad esempio i prezzi azionari, 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 essere sempre il momento corrente. StartTime deve essere 15 minuti prima.
Il plug-in data/ora test Web consente di gestire i tempi dei parametri.
Aggiungere un plug-in test Web per ogni valore del 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".
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.
Nei parametri di test Web usare
{{plug-in name}}per fare riferimento a un nome 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 i 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.
Autenticazione SAML
| Nome proprietà | Descrizione |
|---|---|
| URI gruppo di destinatari | URI del destinatario per il token SAML. Questo URI è per il servizio Controllo di accesso, inclusi lo spazio dei nomi Controllo di accesso e il nome host. |
| Password certificato | Password per il certificato client, che consentirà 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.
- Ottenere un token da Azure AD usando il segreto client (la chiave dell'app).
- Estrarre un token di connessione dalla risposta.
- Chiamare l'API usando il token di connessione nell'intestazione dell'autorizzazione.
- Assicurarsi che il test Web sia un client effettivo. Vale a dire che ha una propria app in Azure AD. Usa l'ID client e la chiave dell'app. Il servizio sottoposto a test ha anche una propria app in Azure AD. L'URI ID app di questa app si riflette nel test Web nel campo della risorsa.
Aprire l'autenticazione
Un esempio di autenticazione aperta è l'azione di accesso con il proprio 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 eseguire l'accesso con OAuth, l'approccio generale è:
- Usare uno strumento come Fiddler per esaminare il traffico tra il Web browser, il sito di autenticazione e l'app.
- Eseguire due o più accessi usando computer o browser diversi oppure a distanza di tempo, per lasciar scadere i token.
- Confrontando sessioni diverse, identificare il token passato dal sito di autenticazione che viene quindi passato al server app dopo l'accesso.
- Registrare un test Web usando Visual Studio.
- 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 informazioni sulla risoluzione dei problemi, vedere l'articolo dedicato sulla risoluzione dei problemi .