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 vindt u onder Klassieke test toevoegen in het deelvenster Beschikbaarheid .
Notitie
Webtests met meerdere stappen worden niet ondersteund in de Azure Government cloud.
Alternatief voor webtest met meerdere drempels
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 momenteel 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 langetermijnoplossing 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 de volgende zaken nodig:
- Visual Studio 2017 Enterprise of hoger.
- Hulpprogramma's voor het testen van webprestaties en belasting van Visual Studio.
Als u de vereiste testhulpprogramma's wilt vinden, selecteert u Visual Studio Installer>Afzonderlijke onderdelen>Foutopsporing en hulpprogramma's voor het testen> vanwebprestaties en belastingstests.
Notitie
Webtests met meerdere stappen hebben extra kosten met zich mee. Zie de officiële prijshandleiding voor meer informatie.
Een webtest met meerdere drempels opnemen
Waarschuwing
We raden het gebruik van de multistaprecorder niet langer aan. De recorder is ontwikkeld voor statische HTML-pagina's met basisinteracties. Het biedt geen functionele ervaring voor moderne webpagina's.
Zie de officiële visual Studio 2019-documentatie voor hulp bij het maken van Visual Studio-webtests.
De webtest uploaden
- Selecteer in de Application Insights-portal in het deelvenster Beschikbaarheid de optie Klassieke test toevoegen. Selecteer vervolgens Meerdere stappen als de SKU.
- Upload uw webtest met meerdere stappen.
- 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 van waaruit onze servers webaanvragen naar uw URL verzenden. Ons minimale aantal aanbevolen testlocaties is vijf om ervoor te zorgen dat u problemen op uw website kunt onderscheiden van netwerkproblemen. U kunt maximaal 16 locaties selecteren. |
Succescriteria
| Instelling | Beschrijving |
|---|---|
| Testtime-out | 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 parseren hebt geselecteerd, moeten alle afbeeldingen, stijlbestanden, scripts en andere afhankelijke resources binnen deze periode zijn ontvangen. |
| HTTP-antwoord | De geretourneerde statuscode die wordt geteld als geslaagd. 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 de inhoud van uw pagina wordt gewijzigd, u deze mogelijk moet bijwerken. Alleen Engelse tekens worden ondersteund met inhoudsovereenkomst. |
Waarschuwingen
| Instelling | Beschrijving |
|---|---|
| Bijna realtime (preview) | We raden u aan waarschuwingen in bijna realtime te gebruiken. Het configureren van dit type waarschuwing wordt uitgevoerd nadat de beschikbaarheidstest is gemaakt. |
| Drempelwaarde voor waarschuwingslocatie | We raden een minimum van 3/5 locaties aan. De optimale relatie tussen de drempelwaarde voor de waarschuwingslocatie en het aantal testlocaties is het aantal = testlocaties voor waarschuwingslocaties- 2, met een minimum van vijf testlocaties. |
Configuratie
Volg deze configuratiestappen.
Tijd en willekeurige getallen in uw test invoegen
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 StartTimeEndTime.
Wanneer u de test uitvoert, wilt EndTime u altijd de huidige tijd zijn. StartTime moet 15 minuten van tevoren zijn.
De invoegtoepassing Web Test Date Time biedt de manier om parametertijden te verwerken.
Voeg een Web Test-invoegtoepassing toe voor elke variabele parameterwaarde die u wilt. Selecteer webtestinvoegtoepassing toevoegen op de werkbalk webtest.
In dit voorbeeld gebruiken we twee exemplaren van de invoegtoepassing Date Time. Het ene exemplaar is voor '15 minuten geleden' en een ander 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 parameters voor de webtest om te verwijzen naar de naam van een invoegtoepassing.
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
| Naam van eigenschap | Description |
|---|---|
| Doelgroep-URI | De doelgroep-URI voor het SAML-token. Deze URI is voor de Access Control service, inclusief 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 persoonlijke sleutel in base64-gecodeerde indeling. |
| Naam-id | De naam-id voor het token. |
| Niet na | De periode waarvoor het token geldig is. De standaardwaarde is 5 minuten. |
| Niet eerder | De periode waarvoor een token dat in het verleden is gemaakt, geldig is (om tijdsverschil op te heffen). 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 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 echte 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 moet worden aangemeld met behulp van OAuth, is de algemene aanpak:
- 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 doorgestuurd van de verificatiesite die na aanmelding wordt doorgegeven aan uw app-server.
- Neem een webtest op met behulp van Visual Studio.
- De tokens parameteriseren. 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 parametriseren, maar de tokens worden niet correct geparametraliseerd.)
Problemen oplossen
Zie het speciale artikel over probleemoplossing voor hulp bij het oplossen van problemen .