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 .
Kommentar
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. Även om inga nya funktioner kommer att läggas till stöds fortfarande webbtestfunktioner i Visual Studio 2019 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 måste:
- 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öka och testa>verktyg för webbprestanda och belastningstestning.
Kommentar
Webbtester med flera steg har extra kostnader kopplade till dem. Mer information finns i den officiella prisguiden.
Viktigt!
Webbtest i flera steg förlitar sig på DNS-infrastrukturen för det offentliga Internet för att matcha domännamnen för de testade slutpunkterna. Om du använder privat DNS måste du se till att de offentliga domännamnsservrarna kan matcha alla domännamn i testet. Om det inte är möjligt kan du använda anpassade TrackAvailability-tester i stället.
Registrera ett webbtest med flera steg
Varning
Vi rekommenderar inte längre att du använder inspelaren med flera steg. Inspelaren utvecklades 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 webbbegäranden till din URL. Vårt minsta antal rekommenderade testplatser är fem för att se till att du kan skilja problem på din webbplats från nätverksproblem. Du kan välja upp till 16 platser. |
Framgångskriterier
| Inställning | beskrivning |
|---|---|
| Tidsgräns för test | Minska det här värdet för att få aviseringar om långsamma svar. Testet räknas som ett fel om svaren från webbplatsen inte har tagits emot under 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ällning | 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ör aviseringsplats för testplatser – 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 StartTime och EndTime.
När du kör testet vill EndTime du alltid vara den aktuella tiden. StartTime ska vara 15 minuter före.
Plugin-programmet för webbtestdatum är ett sätt att 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 att logga in
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 | beskrivning |
|---|---|
| Målgrupps-URI | Målgrupps-URI:n för SAML-token. Den här URI:n gäller för åtkomstkontrolltjänsten, inklusive namnområdet för åtkomstkontroll och värdnamnet. |
| Certifiera lö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 som token ska vara giltig för. Standardvärdet är 5 minuter. |
| Inte tidigare | Tidsintervallet för vilken en token som skapats tidigare är giltig (för att hantera tidsförskjutningar). Standardvärdet är (negativ) 5 minuter. |
| Målkontextparameternamn | 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 inloggning med klienthemligheter. 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: 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 autentiseringen och använd den i frågan till platsen. (Visual Studio försöker parametrisera testet, men parameteriserar inte token korrekt.)
Felsökning
Felsökningshjälp finns i artikeln om dedikerad felsökning .