Webtests met meerdere stappen
U kunt een vastgelegde reeks URL's en interacties met een website bewaken via webtests met meerdere stappen. Dit artikel begeleidt u bij het maken van een webtest met meerdere stappen met Visual Studio Enterprise.
Belangrijk
Webtests met meerdere stappen zijn afgeschaft. Het wordt aanbevolen TrackAvailability() te gebruiken om aangepaste beschikbaarheidstests uit te voeren in plaats van webtests met meerdere stappen. Met TrackAvailability() en aangepaste beschikbaarheidstests kunt u tests uitvoeren op elke computer die u wilt en eenvoudig nieuwe tests maken.
Webtests met meerdere stappen worden gecategoriseerd als klassieke tests en zijn te vinden onder Klassieke test toevoegen in het deelvenster Beschikbaarheid .
Notitie
Webtests met meerdere stappen worden niet ondersteund in de Azure Government-cloud .
Alternatief voor multistep-webtest
Webtests met meerdere stappen zijn afhankelijk van Visual Studio-webtestbestanden. Er is aangekondigd dat Visual Studio 2019 de laatste versie is met webtestfunctionaliteit. Hoewel er geen nieuwe functies worden toegevoegd, wordt de functionaliteit voor webtests in Visual Studio 2019 nog steeds ondersteund en wordt deze nog steeds ondersteund tijdens de ondersteuningslevenscyclus van het product.
We raden u aan TrackAvailability te gebruiken om aangepaste beschikbaarheidstests in te dienen in plaats van webtests met meerdere stappen. Deze optie is de langdurige ondersteunde oplossing voor testscenario's met meerdere aanvragen of verificatie. Met TrackAvailability() en aangepaste beschikbaarheidstests kunt u tests uitvoeren op elke computer die u wilt en eenvoudig nieuwe tests maken.
Vereisten
U hebt het volgende nodig:
- Visual Studio 2017 Enterprise of hoger.
- Visual Studio-hulpprogramma's voor webprestaties en belastingtests.
Als u de vereiste testhulpprogramma's wilt vinden, selecteert u Afzonderlijke onderdelen>van Visual Studio Installer>: foutopsporing en het testen>van webprestaties en hulpprogramma's voor belastingtests.
Notitie
Voor webtests met meerdere stappen zijn extra kosten verbonden. Zie de officiële prijshandleiding voor meer informatie.
Belangrijk
Webtest met meerdere stappen is afhankelijk van de DNS-infrastructuur van het openbare internet om de domeinnamen van de geteste eindpunten op te lossen. Als u privé-DNS gebruikt, moet u ervoor zorgen dat de openbare domeinnaamservers elke domeinnaam van uw test kunnen omzetten. Als dat niet mogelijk is, kunt u in plaats daarvan aangepaste TrackAvailability-tests gebruiken.
Een multistep-webtest opnemen
Waarschuwing
We raden u niet meer aan de multistep-recorder te gebruiken. De recorder is ontwikkeld voor statische HTML-pagina's met basisinteracties. Het biedt geen functionele ervaring voor moderne webpagina's.
Zie de officiële documentatie van Visual Studio 2019 voor hulp bij het maken van Visual Studio-webtests.
De webtest uploaden
- Selecteer klassieke test toevoegen in de Application Insights-portal in het deelvenster Beschikbaarheid. Selecteer vervolgens Meerdere stappen als de SKU.
- Upload uw multistep-webtest.
- Stel de testlocaties, frequentie en waarschuwingsparameters in.
- Selecteer Maken.
Frequentie en locatie
| Instelling | Beschrijving |
|---|---|
| Testfrequentie | Hiermee stelt u in hoe vaak de test wordt uitgevoerd vanaf elke testlocatie. Met een standaardfrequentie van vijf minuten en vijf testlocaties wordt uw site gemiddeld per minuut getest. |
| Testlocaties | De plaatsen waar onze servers webaanvragen naar uw URL verzenden. Ons minimum aantal aanbevolen testlocaties is vijf om ervoor te zorgen dat u problemen op uw website van netwerkproblemen kunt onderscheiden. U kunt maximaal 16 locaties selecteren. |
Slagingscriteria
| Instelling | Beschrijving |
|---|---|
| Time-out testen | Verlaag deze waarde om te worden gewaarschuwd voor trage reacties. De test wordt geteld als een fout als de antwoorden van uw site niet binnen deze periode zijn ontvangen. Als u afhankelijke aanvragen parseert, moeten alle afbeeldingen, stijlbestanden, scripts en andere afhankelijke resources binnen deze periode zijn ontvangen. |
| HTTP-antwoord | De geretourneerde statuscode die wordt geteld als een succes. De code 200 geeft aan dat er een normale webpagina is geretourneerd. |
| Inhoudsovereenkomst | Een tekenreeks, zoals 'Welkom!' We testen of er in elk antwoord een exacte hoofdlettergevoelige overeenkomst optreedt. Het moet een eenvoudige tekenreeks zijn, zonder jokertekens. Vergeet niet dat als uw pagina-inhoud verandert, u deze mogelijk moet bijwerken. Alleen Engelse tekens worden ondersteund met inhoudsovereenkomst. |
Waarschuwingen
| Instelling | Beschrijving |
|---|---|
| Bijna realtime (preview) | We raden u aan bijna realtime waarschuwingen te gebruiken. Het configureren van dit type waarschuwing wordt uitgevoerd nadat uw beschikbaarheidstest is gemaakt. |
| Drempelwaarde voor waarschuwingslocatie | We raden minimaal 3/5 locaties aan. De optimale relatie tussen de drempelwaarde voor waarschuwingslocatie en het aantal testlocaties is de drempelwaarde = voor de waarschuwingslocatie van testlocaties - 2, met minimaal vijf testlocaties. |
Configuratie
Volg deze configuratiestappen.
Tijd en willekeurige getallen aan uw test koppelen
Stel dat u een hulpprogramma test waarmee tijdafhankelijke gegevens, zoals aandelenkoersen, worden opgehaald uit een externe feed. Wanneer u uw webtest opneemt, moet u specifieke tijden gebruiken, maar u stelt deze in als parameters van de test en StartTime EndTime.
Wanneer u de test uitvoert, wilt EndTime u altijd de huidige tijd zijn. StartTime moet 15 minuten eerder zijn.
De invoegtoepassing Datum/tijd voor webtest biedt de manier om parametertijden te verwerken.
Voeg een invoegtoepassing webtest toe voor elke gewenste variabeleparameterwaarde. Selecteer Op de werkbalk webtest de optie Invoegtoepassing Webtest toevoegen.
In dit voorbeeld gebruiken we twee exemplaren van de invoegtoepassing Date Time. Eén exemplaar is voor '15 minuten geleden' en een ander exemplaar is voor 'nu'.
Open de eigenschappen van elke invoegtoepassing. Geef de invoegtoepassing een naam en stel deze zodanig in dat de huidige tijd wordt gebruikt. Voor een van deze opties stelt u Minuten toevoegen = -15 in.
Gebruik
{{plug-in name}}in de webtestparameters om te verwijzen naar een invoegtoepassingsnaam.
Upload uw test nu naar de portal. Bij elke uitvoering van de test worden dynamische waarden gebruikt.
Overweeg om u aan te melden
Als uw gebruikers zich aanmelden bij uw app, hebt u verschillende functies om de aanmelding te simuleren, zodat u pagina’s na het aanmelden kunt testen. Welke aanpak u gebruikt, hangt af van het type beveiliging van de app.
Maak in alle gevallen alleen een account in uw toepassing om te testen. Beperk indien mogelijk de machtigingen voor dit testaccount, zodat webtests echte gebruikers niet beïnvloeden.
Eenvoudige gebruikersnaam en wachtwoord
Een webtest op de gebruikelijke manier registreren. Verwijder eerst de cookies.
SAML-verificatie
| Eigenschapsnaam | Beschrijving |
|---|---|
| Doelgroep-URI | De doelgroep-URI voor het SAML-token. Deze URI is bedoeld voor de Access Control-service, met inbegrip van de Access Control-naamruimte en hostnaam. |
| Certificaatwachtwoord | Het wachtwoord voor het clientcertificaat, dat toegang verleent tot de ingesloten persoonlijke sleutel. |
| Clientcertificaat | De waarde van het clientcertificaat met een persoonlijke sleutel in de met Base64 gecodeerde indeling. |
| Naam-id | De naam-id voor het token. |
| Niet na | De periode waarvoor het token geldig is. De standaardwaarde is vijf minuten. |
| Niet eerder | De periode waarvoor een token in het verleden is gemaakt, is geldig (om de tijd scheeftrekken aan te pakken). De standaardwaarde is (negatief) 5 minuten. |
| Naam van doelcontextparameter | De contextparameter die de gegenereerde assertie ontvangt. |
Clientgeheim
Als uw app een aanmeldroute heeft die een klantgeheim omvat, gebruik dan deze route. Azure Active Directory (Azure AD) is een voorbeeld van een service die een aanmelding met een clientgeheim biedt. In Azure AD is het clientgeheim de app-sleutel.
Hier volgt een voorbeeld van een webtest van een Azure-web-app met behulp van een app-sleutel.
- Haal een token op uit Azure AD met behulp van het clientgeheim (de app-sleutel).
- Pak een bearer-token uit het antwoord.
- Roep de API aan met behulp van het bearer-token in de autorisatieheader.
- Zorg ervoor dat de webtest een werkelijke client is. Dat wil zeggen dat het een eigen app heeft in Azure AD. Gebruik de client-id en app-sleutel. Uw service die wordt getest, heeft ook een eigen app in Azure AD. De app-id-URI van deze app wordt weergegeven in de webtest in het resourceveld.
Verificatie openen
Een voorbeeld van open verificatie is het aanmelden met uw Microsoft- of Google-account. Veel apps die OAuth gebruiken, bieden een alternatief met clientgeheim, zodat uw eerste tactiek moet zijn deze mogelijkheid te onderzoeken.
Als uw test zich moet aanmelden met behulp van OAuth, is de algemene benadering:
- Gebruik een hulpprogramma zoals Fiddler om het verkeer tussen de webbrowser, de verificatiesite en uw app te onderzoeken.
- Voer twee of meer aanmeldingen uit via verschillende apparaten en browsers, of met lange periodes ertussen (zodat de tokens verlopen).
- Door verschillende sessies te vergelijken, identificeert u het token dat is doorgegeven vanaf de verificatiesite die vervolgens na aanmelding wordt doorgegeven aan uw app-server.
- Noteer een webtest met Visual Studio.
- Parameters voor de tokens. Stel de parameter in wanneer het token wordt geretourneerd door de verificator en gebruik deze in de query naar de site. (Visual Studio probeert de test te parameteriseren, maar de tokens worden niet correct geparameteraliseerd.)
Probleemoplossing
Zie het speciale artikel over probleemoplossing voor hulp bij het oplossen van problemen .