多步骤 Web 测试Multi-step web tests

可通过多步骤 Web 测试来监视录制的 URL 序列和与网站的交互。You can monitor a recorded sequence of URLs and interactions with a website via multi-step web tests. 本文将逐步讲解使用 Visual Studio Enterprise 创建多步骤 Web 测试的过程。This article will walk you through the process of creating a multi-step web test with Visual Studio Enterprise.


多步骤 Web 测试依赖于 Visual Studio WebTest 文件。Multi-step web tests depend on Visual Studio webtest files. 我们已宣布,Visual Studio 2019 将是支持 WebTest 功能的最后一个版本。It was announced that Visual Studio 2019 will be the last version with webtest functionality. 尽管我们不会添加任何新功能,但目前仍支持 Visual Studio 2019 中的 WebTest 功能,并且在该产品的支持生命周期内仍将继续提供支持,了解这一点至关重要。It is important to understand that while no new features will be added, webtest functionality in Visual Studio 2019 is still currently supported and will continue to be supported during the support lifecycle of the product. 有关多步骤可用性测试的未来情况问题,Azure Monitor 产品团队已提供解决方案,请参阅此处The Azure Monitor product team has addressed questions regarding the future of multi-step availability tests here.


  • Visual Studio 2017 Enterprise 或更高版本。Visual Studio 2017 Enterprise or greater.
  • Visual Studio Web 性能和负载测试工具。Visual Studio web performance and load testing tools.

查找测试工具必备组件。To locate the testing tools pre-requisite. 启动“Visual Studio 安装程序” > “单个组件” > “调试和测试” > “Web 性能和负载测试工具” 。Launch the Visual Studio Installer > Individual components > Debugging and testing > Web performance and load testing tools.

Visual Studio 安装程序 UI 的屏幕截图,其中已选择“单个组件”和“Web 性能和负载测试工具”项旁边的复选框。


多步骤 Web 测试具有与之相关的额外成本。Multi-step web tests have additional costs associated with them. 如需了解详细信息,请参阅官方定价指南To learn more consult the official pricing guide.

录制多步骤 Web 测试Record a multi-step web test


我们不再建议使用多步骤记录器。We no longer recommend using the multi-step recorder. 记录器是针对具有基本交互的静态 HTML 页面开发的,不提供新式网页的功能体验。The recorder was developed for static HTML pages with basic interactions, and does not provide a functional experience for modern web pages.

有关创建 Visual Studio Web 测试的指南,请参阅官方 Visual Studio 2019 文档For guidance on creating Visual Studio web tests consult the official Visual Studio 2019 documentation.

上传 Web 测试Upload the web test

  1. 在 Application Insights 门户上的“可用性”窗格中,选择“创建测试” > “测试类型” > “多步骤 Web 测试” 。In the Application Insights portal on the Availability pane select Create Test > Test type > Multi-step web test.

  2. 设置测试位置、频率和警报参数。Set the test locations, frequency, and alert parameters.

频率和位置Frequency & location

设置Setting 说明Explanation
测试频率Test frequency 设置从每个测试位置运行测试的频率。Sets how often the test is run from each test location. 如果有五个测试位置,且默认频率为五分钟,则平均每隔一分钟测试站点一次。With a default frequency of five minutes and five test locations, your site is tested on average every minute.
测试位置Test locations 是服务器将 Web 请求发送到 URL 的位置。Are the places from where our servers send web requests to your URL. 建议最低测试位置数目为 5,以确保可以将网站中的问题与网络问题区分开来。Our minimum number of recommended test locations is five in order to insure that you can distinguish problems in your website from network issues. 最多可以选择 16 个位置。You can select up to 16 locations.

成功条件Success criteria

设置Setting 说明Explanation
测试超时Test timeout 减少此值可以接收有关响应变慢的警报。Decrease this value to be alerted about slow responses. 如果未在这段时间内收到站点的响应,则将测试视为失败。The test is counted as a failure if the responses from your site have not been received within this period. 如果选择了“分析依赖请求”,则必须在这段时间内收到所有图像、样式文件、脚本和其他依赖资源。If you selected Parse dependent requests, then all the images, style files, scripts, and other dependent resources must have been received within this period.
HTTP 响应HTTP response 视为成功的返回状态代码。The returned status code that is counted as a success. 代码 200 指示返回了正常网页。200 is the code that indicates that a normal web page has been returned.
内容匹配Content match 类似于“Welcome!”的字符串。A string, like "Welcome!" 我们测试区分大小写的匹配项是否出现在每个响应中。We test that an exact case-sensitive match occurs in every response. 它必须是不带通配符的纯字符串。It must be a plain string, without wildcards. 别忘了,如果页面内容更改,可能需要更新。Don't forget that if your page content changes you might have to update it. 内容匹配仅支持英文字符Only English characters are supported with content match


设置Setting 说明Explanation
准实时(预览)Near-realtime (Preview) 建议使用准实时警报。We recommend using Near-realtime alerts. 创建可用性测试后,配置此类型的警报。Configuring this type of alert is done after your availability test is created.
经典Classic 我们不再建议对新的可用性测试使用经典警报。We no longer recommended using classic alerts for new availability tests.
警报位置阈值Alert location threshold 建议最少 3/5 个位置。We recommend a minimum of 3/5 locations. 警报位置阈值和测试位置数目之间的最佳关系是,警报位置阈值 = 测试位置数 - 2,至少有 5 个测试位置 。The optimal relationship between alert location threshold and the number of test locations is alert location threshold = number of test locations - 2, with a minimum of five test locations.


在测试中插入时间和随机数字Plugging time and random numbers into your test

假设要测试的工具从外部源获取与时间相关的数据(例如股票)。Suppose you're testing a tool that gets time-dependent data such as stocks from an external feed. 录制 Web 测试时,必须使用具体的时间,但要将它们设置为测试参数:StartTime 和 EndTime。When you record your web test, you have to use specific times, but you set them as parameters of the test, StartTime and EndTime.


运行测试时,EndTime 应该始终为当前时间,StartTime 在 15 分钟前。When you run the test, you'd like EndTime always to be the present time, and StartTime should be 15 minutes ago.

Web 测试日期时间插件提供了处理参数化时间的方法。The Web Test Date Time Plugin provides the way to handle parameterize times.

  1. 针对所需的每个变量参数值添加一个 Web 测试插件。Add a web test plug-in for each variable parameter value you want. 在 Web 测试工具栏中,选择“添加 Web 测试插件”。In the web test toolbar, choose Add Web Test Plugin.

    添加 Web 测试插件

    本示例使用两个日期时间插件实例。In this example, we use two instances of the Date Time Plug-in. 一个实例设置为“15 分钟前”,另一个实例设置为“现在”。One instance is for "15 minutes ago" and another for "now."

  2. 打开每个插件的属性。Open the properties of each plug-in. 为插件命名,然后将它设置为使用当前时间。Give it a name and set it to use the current time. 对于其中一个插件,将“添加分钟”设置为 -15。For one of them, set Add Minutes = -15.


  3. 在 Web 测试参数中,使用 {{plug-in name}} 来引用插件名称。In the web test parameters, use {{plug-in name}} to reference a plug-in name.


现在,将测试上传到门户。Now, upload your test to the portal. 它会在每次运行测试时使用动态值。It will use the dynamic values on every run of the test.

处理登录Dealing with sign-in

如果用户登录应用,可以使用许多选项来模拟登录,以便可以在登录后测试页面。If your users sign in to your app, you have various options for simulating sign-in so that you can test pages behind the sign-in. 使用的方法取决于应用提供的安全性类型。The approach you use depends on the type of security provided by the app.

在所有情况下,应该只针对测试目的在应用程序中创建帐户。In all cases, you should create an account in your application just for the purpose of testing. 如果可能,请限制此测试帐户的权限,以便 Web 测试不会影响实际用户。If possible, restrict the permissions of this test account so that there's no possibility of the web tests affecting real users.

简单的用户名和密码 按常规方式录制 Web 测试。Simple username and password Record a web test in the usual way. 先删除 Cookie。Delete cookies first.

SAML 身份验证SAML authentication

属性名称Property name 说明Description
受众 URIAudience Uri SAML 令牌的受众 URI。The audience URI for the SAML token. 这是访问控制服务 (ACS) 的 URI - 包括 ACS 命名空间和主机名。This is the URI for the Access Control Service (ACS) - including ACS namespace and host name.
证书密码Certificate Password 将授予对嵌入式私钥的访问权限的客户端证书的密码。The password for the client certificate which will grant access to the embedded private key.
客户端证书Client Certificate 具有 Base64 编码格式的私钥的客户端证书值。The client certificate value with private key in Base64 encoded format.
名称标识符Name Identifier 令牌的名称标识符。The name identifier for the token
不晚于Not After 令牌有效的时间跨度。The timespan for which the token will be valid. 默认为 5 分钟。The default is 5 minutes.
不早于Not Before 过去创建令牌的时间跨度将有效(用于解决时间差异)。The timespan for which a token created in the past will be valid (to address time skews). 默认值为(负)5 分钟。The default is (negative) 5 minutes.
目标上下文参数名称Target Context Parameter Name 将接收生成断言的上下文参数。The context parameter that will receive the generated assertion.

客户端机密 如果应用的某个登录路由涉及到客户端机密,请使用该路由。Client secret If your app has a sign-in route that involves a client secret, use that route. 例如,Azure Active Directory (AAD) 就是提供客户端机密登录的服务。Azure Active Directory (AAD) is an example of a service that provides a client secret sign-in. 在 AAD 中,客户端机密是应用密钥。In AAD, the client secret is the App Key.

下面是使用应用密钥的 Azure Web 应用的 Web 测试示例:Here's a sample web test of an Azure web app using an app key:


使用客户端机密 (AppKey) 从 AAD 获取令牌。Get token from AAD using client secret (AppKey). 从响应中提取持有者令牌。Extract bearer token from response. 使用授权标头中的持有者令牌调用 API。Call API using bearer token in the authorization header. 确保 Web 测试是实际客户端(即在 AAD 中有自身的应用)并使用其 clientId 和 app key。Make sure that the web test is an actual client - that is, it has its own app in AAD - and use its clientId + app key. 测试中的服务在 AAD 中也有自身的应用:此应用的 appID URI 反映在“resource”字段中的 Web 测试内。Your service under test also has its own app in AAD: the appID URI of this app is reflected in the web test in the resource field.

开放身份验证Open Authentication

开放身份验证的示例包括使用 Microsoft 或 Google 帐户登录。An example of open authentication is signing in with your Microsoft or Google account. 许多使用 OAuth 的应用提供替代的客户端机密,因此第一个技巧就是调查这种可能性。Many apps that use OAuth provide the client secret alternative, so your first tactic should be to investigate that possibility.

如果测试必须使用 OAuth 登录,则常规方法是:If your test must sign in using OAuth, the general approach is:

使用 Fiddler 等工具检查 Web 浏览器、身份验证站点与应用之间的流量。Use a tool such as Fiddler to examine the traffic between your web browser, the authentication site, and your app. 使用不同的计算机或浏览器或者以较长的间隔执行两次以上的登录(使令牌过期)。Perform two or more sign-ins using different machines or browsers, or at long intervals (to allow tokens to expire). 通过比较不同的会话,识别从身份验证站点返回的令牌,然后在登录后将此令牌传递给应用服务器。By comparing different sessions, identify the token passed back from the authenticating site, that is then passed to your app server after sign-in. 使用 Visual Studio 录制 Web 测试。Record a web test using Visual Studio. 参数化令牌,设置参数来指定从验证器返回令牌的时间,并在站点查询中使用该参数。Parameterize the tokens, setting the parameter when the token is returned from the authenticator, and using it in the query to the site. (Visual Studio 会尝试参数化测试,但无法正确参数化令牌。)(Visual Studio attempts to parameterize the test, but does not correctly parameterize the tokens.)


请参阅疑难解答文章Dedicated troubleshooting article.

后续步骤Next steps