Flerstegstest för webbplatser
Du kan övervaka en inspelad sekvens med URL:er och interaktioner med en webbplats via webbtester med flera steg. Den här artikeln beskriver hur du skapar ett webbtest med flera steg med Visual Studio Enterprise.
Viktigt
Webbtester med flera steg har blivit inaktuella. V rekommenderar att du använder TrackAvailability() för att skicka anpassade tillgänglighetstest i stället för flerstegstest för webbplatser. Med TrackAvailability() och anpassade tillgänglighetstest kan du köra test på valfri beräkning och använda C# för att enkelt skapa nya test.
Webbtester med flera steg kategoriseras som klassiska tester och finns under Lägg till klassiskt test i fönstret Tillgänglighet .
Anteckning
Webbtester med flera steg stöds inte i Azure Government molnet.
Flerstegswebbtestalternativ
Webbtester med flera steg är beroende av Visual Studio-webbtestfiler. Det meddelades att Visual Studio 2019 blir den sista versionen med webbtestfunktioner. Inga nya funktioner kommer att läggas till, men webbtestfunktionerna i Visual Studio 2019 stöds fortfarande och kommer att fortsätta att stödjas under produktens supportlivscykel.
Vi rekommenderar att du använder TrackAvailability för att skicka anpassade tillgänglighetstester i stället för webbtester med flera steg. Det här alternativet är den långsiktiga lösningen för testscenarier med flera begäranden eller autentisering. Med TrackAvailability() och anpassade tillgänglighetstest kan du köra test på valfri beräkning och använda C# för att enkelt skapa nya test.
Förutsättningar
Du behöver:
- Visual Studio 2017 Enterprise eller senare.
- Visual Studio-verktyg för webbprestanda och belastningstestning.
Om du vill hitta de nödvändiga testverktygen väljer du Visual Studio Installer>Enskilda komponenter>Felsökning och testning>av webbprestanda- och belastningstestverktyg.
Anteckning
Webbtester med flera steg har extra kostnader kopplade till dem. Mer information finns i den officiella prisguiden.
Registrera ett webbtest med flera steg
Varning
Vi rekommenderar inte längre att du använder inspelaren med flera steg. Inspelaren har utvecklats för statiska HTML-sidor med grundläggande interaktioner. Det ger inte en funktionell upplevelse för moderna webbsidor.
Vägledning om hur du skapar Visual Studio-webbtester finns i den officiella Visual Studio 2019-dokumentationen.
Ladda upp webbtestet
- I Application Insights-portalen i fönstret Tillgänglighet väljer du Lägg till klassiskt test. Välj sedan Flera steg som SKU.
- Ladda upp ditt webbtest med flera steg.
- Ange testplatser, frekvens och aviseringsparametrar.
- Välj Skapa.
Frekvens och plats
| Inställning | Beskrivning |
|---|---|
| Testfrekvens | Anger hur ofta testet körs från varje testplats. Med en standardfrekvens på fem minuter och fem testplatser testas din webbplats i genomsnitt varje minut. |
| Testplatser | De platser där våra servrar skickar webbförfrågningar till din URL. Vårt minsta antal rekommenderade testplatser är fem för att säkerställa att du kan skilja problem på din webbplats från nätverksproblem. Du kan välja upp till 16 platser. |
Framgångskriterier
| Inställningen | Beskrivning |
|---|---|
| Tidsgräns för test | Minska det här värdet om du vill få aviseringar om långsamma svar. Testet räknas som ett fel om svaren från webbplatsen inte har tagits emot inom den här perioden. Om du har valt Parsa beroende begäranden måste alla bilder, formatfiler, skript och andra beroende resurser ha tagits emot inom den här perioden. |
| HTTP-svar | Den returnerade statuskoden som räknas som en framgång. Koden 200 anger att en normal webbsida har returnerats. |
| Innehållsmatchning | En sträng, som "Välkommen!" Vi testar att en exakt skiftlägeskänslig matchning sker i varje svar. Den måste vara en enkel sträng utan jokertecken. Glöm inte att om sidinnehållet ändras kan du behöva uppdatera det. Endast engelska tecken stöds med innehållsmatchning. |
Aviseringar
| Inställningen | Beskrivning |
|---|---|
| Nära realtid (förhandsversion) | Vi rekommenderar att du använder aviseringar i nära realtid. Du konfigurerar den här typen av avisering när tillgänglighetstestet har skapats. |
| Tröskelvärde för aviseringsplats | Vi rekommenderar minst 3/5 platser. Den optimala relationen mellan tröskelvärdet för aviseringsplatser och antalet testplatser är tröskelvärdet = föraviseringsplatser – 2, med minst fem testplatser. |
Konfiguration
Följ de här konfigurationsstegen.
Koppla tid och slumptal till testet
Anta att du testar ett verktyg som hämtar tidsberoende data, till exempel aktiekurser, från ett externt flöde. När du registrerar webbtestet måste du använda specifika tider, men du anger dem som parametrar för testet och StartTimeEndTime.
När du kör testet vill EndTime du alltid vara aktuell. StartTime ska vara 15 minuter före.
Med plugin-programmet För webbtestdatum kan du hantera parametertider.
Lägg till ett plugin-program för webbtest för varje variabelparametervärde som du vill använda. I verktygsfältet för webbtest väljer du Lägg till plugin-program för webbtest.
I det här exemplet ska vi använda två instanser av plugin-programmet för datum och tid. En instans är för "15 minuter sedan" och en annan är för "nu".
Öppna egenskaperna för varje plugin-program. Lägg till ett namn och ange att den aktuella tiden ska användas. För en av dem anger du Lägg till minuter = -15.
I webbtestparametrarna använder du
{{plug-in name}}för att referera till ett plugin-namn.
Ladda upp testet till portalen. Den använder dynamiska värden vid varje körning av testet.
Överväg inloggning
Om användarna måste logga in i din app kan du välja mellan olika alternativ för att simulera inloggningen, så att du kan testa sidorna bakom inloggningen. Vilken metod du använder beror på vilken typ av säkerhet som tillhandahålls av appen.
I samtliga fall skapar du ett konto i ditt program endast för testning. Om möjligt begränsar du behörigheterna för det här testkontot så att webbtestningen inte påverkar riktiga användare.
Enkelt användarnamn och lösenord
Spela in ett webbtest som vanligt. Ta bort cookies först.
SAML-autentisering
| Egenskapsnamn | Description |
|---|---|
| Målgrupps-URI | Målgrupps-URI för SAML-token. Den här URI:n är för Access Control-tjänsten, inklusive Access Control namnområde och värdnamn. |
| Certifikatlösenord | Lösenordet för klientcertifikatet, som ger åtkomst till den inbäddade privata nyckeln. |
| Klientcertifikat | Klientcertifikatvärdet med privat nyckel i Base64-kodat format. |
| Namnidentifierare | Namnidentifieraren för token. |
| Inte efter | Tidsintervallet för vilket token ska vara giltig. Standardvärdet är 5 minuter. |
| Inte tidigare | Det tidsintervall för vilket en token som skapats tidigare är giltig (för att åtgärda tidsförskjutningar). Standardvärdet är (negativt) 5 minuter. |
| Parameternamn för målkontext | Kontextparametern som ska ta emot den genererade försäkran. |
Klienthemlighet
Om din app kräver inloggning med en klienthemlighet använder du det. Azure Active Directory (Azure AD) är ett exempel på en tjänst som tillhandahåller en klienthemlig inloggning. I Azure AD är klienthemligheten appnyckeln.
Här är ett exempel på ett webbtest av en Azure-webbapp med hjälp av en appnyckel.
- Hämta en token från Azure AD med hjälp av klienthemligheten (appnyckeln).
- Extrahera en ägartoken från svaret.
- Anropa API:et med hjälp av ägartoken i auktoriseringshuvudet.
- Kontrollera att webbtestet är en faktisk klient. Det vill sa att den har en egen app i Azure AD. Använd dess klient-ID och appnyckel. Din tjänst som testas har också en egen app i Azure AD. Appens app-ID-URI återspeglas i webbtestet i resursfältet.
Öppna autentisering
Ett exempel på öppen autentisering är att logga in med ditt Microsoft- eller Google-konto. Många appar som använder OAuth erbjuder möjligheten att använda en klienthemlighet, så det första du bör göra är att ta reda på detta.
Om testet måste logga in med OAuth är den allmänna metoden:
- Använda ett verktyg som Fiddler för att undersöka trafiken mellan webbläsaren, autentiseringswebbplatsen och din app.
- Utföra två eller flera inloggningar med olika datorer eller webbläsare, eller med långa intervall (så att token upphör att gälla).
- Genom att jämföra olika sessioner identifierar du den token som skickades tillbaka från den autentiseringswebbplats som sedan skickas till appservern efter inloggningen.
- Registrera ett webbtest med hjälp av Visual Studio.
- Parametrisera token. Ange parametern när token returneras från autentiseringsdatorn och använd den i frågan till webbplatsen. (Visual Studio försöker parametrisera testet, men parameteriserar inte token korrekt.)
Felsökning
Felsökningshjälp finns i den dedikerade felsökningsartikeln .