您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

监视任何网站的可用性和响应能力Monitor availability and responsiveness of any web site

将 Web 应用或网站部署到任何服务器之后,可以设置测试来监视其可用性和响应能力。After you've deployed your web app or web site to any server, you can set up tests to monitor its availability and responsiveness. Azure Application Insights 将来自全球各地的 Web 请求定期发送到应用程序。Azure Application Insights sends web requests to your application at regular intervals from points around the world. 如果应用程序无响应或响应太慢,则会发出警报。It alerts you if your application doesn't respond, or responds slowly.

对于可以从公共 Internet 访问的任何 HTTP 或 HTTPS 终结点,均可设置可用性测试。You can set up availability tests for any HTTP or HTTPS endpoint that is accessible from the public internet. 无需将任何内容添加到要测试的网站。You don't have to add anything to the web site you're testing. 它甚至不一定是站点:可以测试你所依赖的 REST API 服务。It doesn't even have to be your site: you could test a REST API service on which you depend.

有两种类型的可用性测试:There are two types of availability tests:

对于每个应用程序资源,最多可以创建 100 个可用性测试。You can create up to 100 availability tests per application resource.

为可用性测试报告打开资源Open a resource for your availability test reports

如果已配置 Application Insights(针对 Web 应用),请在 Azure 门户中打开 Application Insights 资源。If you have already configured Application Insights for your web app, open its Application Insights resource in the Azure portal.

或者,要在新资源中查看报告,请注册 Microsoft Azure,转到 Azure 门户,并创建 Application Insights 资源。Or, if you want to see your reports in a new resource, sign up to Microsoft Azure, go to the Azure portal, and create an Application Insights resource.

“新建”>“Application Insights”

单击“所有资源”,打开新资源的“概述”边栏选项卡。Click All resources to open the Overview blade for the new resource.

创建 URL ping 测试Create a URL ping test

打开“可用性”边栏选项卡,并添加一个测试。Open the Availability blade and add a test.

至少填写网站的 URL

  • URL 可以是要测试的任何网页,但必须在公共 Internet 中可见。The URL can be any web page you want to test, but it must be visible from the public internet. 该 URL 可以包括查询字符串。The URL can include a query string. 因此,例如,可以稍微训练一下数据库。So, for example, you can exercise your database a little. 如果 URL 解析为重定向,最多可以跟踪 10 个重定向。If the URL resolves to a redirect, we follow it up to 10 redirects.
  • 分析从属请求:如果选中此选项,则测试将请求图像、脚本、样式文件以及其他属于受测网页的文件。Parse dependent requests: If this option is checked, the test requests images, scripts, style files, and other files that are part of the web page under test. 记录的响应时间包括获取这些文件所耗费的时间。The recorded response time includes the time taken to get these files. 如果无法在超时期限内为整个测试成功下载所有这些资源,测试会失败。The test fails if all these resources cannot be successfully downloaded within the timeout for the whole test.

    如果不选中此选项,则测试只请求指定 URL 的文件。If the option is not checked, the test only requests the file at the URL you specified.

  • 启用重试:如果选中此选项,则测试失败时,会在短时间后重试。Enable retries: If this option is checked, when the test fails, it is retried after a short interval. 仅当连续三次尝试失败时,才报告失败。A failure is reported only if three successive attempts fail. 然后,将按照一般的测试频率执行后续测试。Subsequent tests are then performed at the usual test frequency. 重试会暂停,直到下次成功为止。Retry is temporarily suspended until the next success. 可在每个测试位置单独应用此规则。This rule is applied independently at each test location. 建议使用此选项。We recommend this option. 平均大约有 80% 的失败可在重试后消除。On average, about 80% of failures disappear on retry.
  • 测试频率:设置从每个测试位置运行测试的频率。Test frequency: Sets how often the test is run from each test location. 如果有五个测试位置,且频率为五分钟,则平均每隔一分钟测试站点一次。With a frequency of five minutes and five test locations, your site is tested on average every minute.
  • 测试位置 是服务器将 Web 请求发送到的 URL 位置。Test locations are the places from where our servers send web requests to your URL. 请选择多个位置,以便区分网站问题与网络问题。Choose more than one so that you can distinguish problems in your website from network issues. 最多可以选择 16 个位置。You can select up to 16 locations.
  • 成功准则Success criteria:

    测试超时:减少此值可以接收有关响应变慢的警报。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: 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.

  • 警报Alerts are, by default, sent to you if there are failures in three locations over five minutes. 某个位置的失败很可能是网络问题,而不是站点问题。A failure in one location is likely to be a network problem, and not a problem with your site. 但是,可以将阈值更改为更敏感或更不敏感,也可以更改要将电子邮件发送给哪个人。But you can change the threshold to be more or less sensitive, and you can also change who the emails should be sent to.

    可以设置在引发警报时调用的 webhookYou can set up a webhook that is called when an alert is raised. (但请注意,查询参数不会以“属性”的形式传递。)(But note that, at present, query parameters are not passed through as Properties.)

测试其他 URLTest more URLs

添加更多测试。Add more tests. 例如,除了测试主页外,还可以通过测试搜索 URL 来确保数据库正在运行。For example, In addition to testing your home page, you can make sure your database is running by testing the URL for a search.

查看可用性测试结果See your availability test results

几分钟之后,单击“刷新”即可查看测试结果。After a few minutes, click Refresh to see test results.

主页边栏选项卡中的摘要结果

散点图显示其中都诊断测试步骤详细信息的测试结果示例。The scatterplot shows samples of the test results that have diagnostic test-step detail in them. 测试引擎存储已失败的测试的诊断详细信息。The test engine stores diagnostic detail for tests that have failures. 对于成功的测试,将存储执行子集的诊断详细信息。For successful tests, diagnostic details are stored for a subset of the executions. 将鼠标悬停在任何绿点/红点上,可查看测试时间戳、测试持续时间、位置和测试名称。Hover over any of the green/red dots to see the test timestamp, test duration, location, and test name. 单击散点图中的任何点可查看测试结果的详细信息。Click through any dot in the scatter plot to see the details of the test result.

选择特定测试、位置或减少时间段,可查看围绕感兴趣的时间段的更多结果。Select a particular test, location, or reduce the time period to see more results around the time period of interest. 使用搜索资源管理器以查看所有执行结果,或者使用分析查询以针对此数据运行自定义报告。Use Search Explorer to see results from all executions, or use Analytics queries to run custom reports on this data.

除了原始结果外,指标资源管理器中还有两个可用性指标:In addition to the raw results, there are two Availability metrics in Metrics Explorer:

  1. 可用性:已成功的测试占执行的所有测试的百分比。Availability: Percentage of the tests that were successful, across all test executions.
  2. 测试持续时间:执行的所有测试的平均测试持续时间。Test Duration: Average test duration across all test executions.

可以将筛选器应用于测试名称、位置以分析特定测试和/或位置的趋势。You can apply filters on the test name, location to analyze trends of a particular test and/or location.

检查和编辑测试Inspect and edit tests

从摘要页面选择特定的测试。From the summary page, select a specific test. 可以在该处查看具体结果,对其进行编辑或者临时禁用它。There, you can see its specific results, and edit or temporarily disable it.

编辑或禁用 Web 测试

对服务执行维护时,可能需要禁用可用性测试或与这些测试关联的警报规则。You might want to disable availability tests or the alert rules associated with them while you are performing maintenance on your service.

如果看到失败If you see failures

单击红点。Click a red dot.

单击红点

从可用性测试结果,可以:From an availability test result, you can:

  • 检查从服务器收到的响应。Inspect the response received from your server.
  • 使用在处理失败的请求实例时收集的服务器端遥测数据进行故障诊断。Diagnose failure with server side telemetry collected while processing the failed request instance.
  • 在 Git 或 VSTS 中记录问题或工作项以跟踪问题。Log an issue or work item in Git or VSTS to track the problem. Bug 中将包含转至此事件的链接。The bug will contain a link to this event.
  • 在 Visual Studio 中打开 Web 测试结果。Open the web test result in Visual Studio.

看起来正常,但却报告为失败Looks OK but reported as a failure? 请参阅常见问题解答,了解如何减少干扰。See FAQ for ways to reduce noise.

多步骤 Web 测试Multi-step web tests

可以监视涉及一连串 URL 的方案。You can monitor a scenario that involves a sequence of URLs. 例如,如果正在监视销售网站,可以测试是否能够正常地将商品添加购物车。For example, if you are monitoring a sales website, you can test that adding items to the shopping cart works correctly.

备注

对多步骤 Web 测试要收取费用。There is a charge for multi-step web tests. 定价方案Pricing scheme.

若要创建多步骤测试,可以使用 Visual Studio Enterprise 来录制方案,然后将录制内容上传到 Application Insights。To create a multi-step test, you record the scenario by using Visual Studio Enterprise, and then upload the recording to Application Insights. Application Insights 将按特定间隔重放该方案,并验证响应。Application Insights replays the scenario at intervals and verifies the responses.

备注

不能在测试中使用编码的函数或循环。You can't use coded functions or loops in your tests. 测试必须完全包含在 .webtest 脚本中。The test must be contained completely in the .webtest script. 但是,可以使用标准插件。However, you can use standard plugins.

1.录制方案1. Record a scenario

使用 Visual Studio Enterprise 录制 Web 会话。Use Visual Studio Enterprise to record a web session.

  1. 创建 Web 性能测试项目。Create a Web performance test project.

    在 Visual Studio Enterprise 版中,基于“Web 性能测试和负载测试”模板创建项目。

    • 看不到 Web 性能与负载测试模板?Don't see the Web Performance and Load Test template? - 关闭 Visual Studio Enterprise。- Close Visual Studio Enterprise. 打开 Visual Studio 安装程序,修改 Visual Studio Enterprise 安装。Open Visual Studio Installer to modify your Visual Studio Enterprise installation. 在“各个组件”下,选择“Web 性能和负载测试工具”。Under Individual Components, select Web Performance and load testing tools.
  2. 打开 .webtest 文件并开始录制。Open the .webtest file and start recording.

    打开 .webtest 文件并单击“录制”。

  3. 执行要在测试中模拟的用户操作:打开网站、将产品加入购物车,等等。Do the user actions you want to simulate in your test: open your website, add a product to the cart, and so on. 然后停止测试。Then stop your test.

    Web 测试录制程序在 Internet Explorer 中运行。

    不要录制太长的方案。Don't make a long scenario. 以 100 个步骤和 2 分钟为限。There's a limit of 100 steps and 2 minutes.

  4. 编辑测试:Edit the test to:

    • 添加验证,检查收到的文本和响应代码。Add validations to check the received text and response codes.
    • 删除所有多余的交互。Remove any superfluous interactions. 也可以删除图片、广告或跟踪站点的依赖请求。You could also remove dependent requests for pictures or to ad or tracking sites.

      请记住,只能编辑测试脚本 - 不能添加自定义代码或调用其他 Web 测试。Remember that you can only edit the test script - you can't add custom code or call other web tests. 不要在测试中插入循环。Don't insert loops in the test. 可以使用标准 Web 测试插件。You can use standard web test plug-ins.

  5. 在 Visual Studio 中运行测试,确保它可以正常工作。Run the test in Visual Studio to make sure it works.

    Web 测试运行器将打开 Web 浏览器,并重复录制的操作。The web test runner opens a web browser and repeats the actions you recorded. 请确保它按预期工作。Make sure it works as you expect.

    在 Visual Studio 中,打开 .webtest 文件并单击“运行”。

2.将 Web 测试上传到 Application Insights2. Upload the web test to Application Insights

  1. 在 Application Insights 门户中创建 Web 测试。In the Application Insights portal, create a web test.

    在 Web 测试边栏选项卡中选择“添加”。

  2. 选择多步骤测试并上传 .webtest 文件。Select multi-step test, and upload the .webtest file.

    选择多步骤 Web 测试。

    像设置 ping 测试一样设置测试位置、频率和警报参数。Set the test locations, frequency, and alert parameters in the same way as for ping tests.

3.查看结果3. See the results

像单 url 测试一样查看测试结果和所有失败。View your test results and any failures in the same way as single-url tests.

此外,还可以下载测试结果,在 Visual Studio 中查看。In addition, you can download the test results to view them in Visual Studio.

失败太多?Too many failures?

  • 失败的常见原因是测试运行时间太久。A common reason for failure is that the test runs too long. 运行时间不能超过两分钟。It mustn't run longer than two minutes.

  • 别忘了,必须正确加载页面的所有资源,测试才能成功(包括脚本、样式表、图像,等等)。Don't forget that all the resources of a page must load correctly for the test to succeed, including scripts, style sheets, images, and so forth.

  • Web 测试必须完全包含在 .webtest 脚本中:不能在测试中使用编码的函数。The web test must be entirely contained in the .webtest script: you can't use coded functions in the test.

将时间和随机数插入多步骤测试Plugging time and random numbers into your multi-step 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.

带参数的 Web 测试。

运行测试时,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 测试插件提供时间参数化方式。Web Test Plug-ins provide the way to do 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.

    在测试参数中使用 {{plug-in name}}。

现在,将测试上传到门户。Now, upload your test to the portal. 每次运行测试时,将使用动态值。It uses 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.

简单的用户名和密码Simple username and password

以普通方式录制 Web 测试。Record a web test in the usual way. 先删除 Cookie。Delete cookies first.

SAML 身份验证SAML authentication

使用可用于 Web 测试的 SAML 插件。Use the SAML plugin that is available for web tests.

客户端机密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:

客户端机密示例

  1. 使用客户端机密 (AppKey) 从 AAD 获取令牌。Get token from AAD using client secret (AppKey).
  2. 从响应中提取持有者令牌。Extract bearer token from response.
  3. 使用授权标头中的持有者令牌调用 API。Call API using bearer token in the authorization header.

确保 Web 测试是实际客户端 - 即,在 AAD 中有自身的应用 - 并使用其 clientId 和 appkey。Make sure that the web test is an actual client - that is, it has its own app in AAD - and use its clientId + appkey. 测试中的服务在 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.)

性能测试Performance tests

可以在网站上运行负载测试。You can run a load test on your website. 与可用性测试一样,可以从全球各地的站点发送简单请求或多步骤请求。Like the availability test, you can send either simple requests or multi-step requests from our points around the world. 与可用性测试不同的是,发送的许多请求可以模拟多个并发用户。Unlike an availability test, many requests are sent, simulating multiple simultaneous users.

在“概述”边栏选项卡中,打开“设置”、“性能测试”。From the Overview blade, open Settings, Performance Tests. 创建测试时,系统会邀请你连接或创建 Visual Studio Team Services 帐户。When you create a test, you are invited to connect to or create a Visual Studio Team Services account.

测试完成时,会显示响应时间和成功率。When the test is complete, you are shown response times and success rates.

性能测试

提示

若要观察性能测试的效果,请使用实时流探查器To observe the effects of a performance test, use Live Stream and Profiler.

自动化Automation

有疑问?Questions? 遇到问题?Problems?

  • 出现间歇性测试失败和违反协议错误?Intermittent test failure with a protocol violation error?

    错误(“违反协议: CR 必须后跟 LF”)表明服务器(或依赖项)存在问题。The error ("protocol violation..CR must be followed by LF") indicates an issue with the server (or dependencies). 在响应中设置的标头格式错误时,会发生这种情况。This happens when malformed headers are set in the response. 可能是负载均衡器或 CDN 引发的。It can be caused by load balancers or CDNs. 具体说来,某些标头可能没有使用 CRLF 来指示行结束,这违反了 HTTP 规范,因此无法通过 .NET WebRequest 级别的验证。Specifically, some headers might not be using CRLF to indicate end-of-line, which violates the HTTP specification and therefore fail validation at the .NET WebRequest level. 请检查响应,找出可能违反规范的标头。Inspect the response to spot headers which might be in violation.

    注意:URL 可能不会在对 HTTP 标头的验证比较宽松的浏览器上发生故障。Note: The URL may not fail on browsers that have a relaxed validation of HTTP headers. 请查看以下博客文章,详细了解此问题:http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/See this blog post for a detailed explanation of this issue: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/

  • 站点看上去正常,但测试却失败?Site looks okay but I see test failures?

    • 检查所有图像、脚本、样式表和页面加载的任何其他文件。Check all the images, scripts, style sheets, and any other files loaded by the page. 如果其中有任何一个失败,即使 html 主页加载正常,测试也仍会报告为失败。If any of them fails, the test is reported as failed, even if the main html page loads OK. 若要使测试对此类资源故障不再敏感,只需在测试配置中取消选中“分析从属请求”即可。To desensitize the test to such resource failures, simply uncheck the "Parse Dependent Requests" from the test configuration.

    • 若要降低包括网络在内的各方面因素的干扰影响,请确保选中“测试故障时允许重试”配置。To reduce odds of noise from transient network blips etc., ensure "Enable retries for test failures" configuration is checked. 也可从多个位置进行测试并对警报规则阈值进行相应的管理,防止在出现特定于位置的问题时引发不必要的警报。You can also test from more locations and manage alert rule threshold accordingly to prevent location specific issues causing undue alerts.

  • 看不到任何相关的、用于诊断测试失败的服务器端遥测数据?I don't see any related server side telemetry to diagnose test failures?

    如果已为服务器端应用程序设置 Application Insights,则可能是因为采样正在进行。If you have Application Insights set up for your server-side application, that may be because sampling is in operation.

  • 是否可以从 Web 测试调用代码?Can I call code from my web test?

    不可以。No. 测试步骤必须在 .webtest 文件中指定。The steps of the test must be in the .webtest file. 此外,不能调用其他 Web 测试或使用循环。And you can't call other web tests or use loops. 但是可以借助一些有用的插件。But there are several plug-ins that you might find helpful.

  • 是否支持 HTTPS?Is HTTPS supported?

    支持 TLS 1.1 和 TLS 1.2。We support TLS 1.1 and TLS 1.2.

  • “Web 测试”与“可用性测试”之间是否有差异?Is there a difference between "web tests" and "availability tests"?

    这两个术语可以互换引用。The two terms may be referenced interchangeably. 可用性测试是更通用的术语,其中除了包含多步骤 Web 测试外,还包含单 URL ping 测试。Availability tests is a more generic term that includes the single URL ping tests in addition to the multi-step web tests.

  • 如何在防火墙后面运行的内部服务器上使用可用性测试?I'd like to use availability tests on our internal server that runs behind a firewall.

    有两个可能的解决方案:There are two possible solutions:

    • 请将防火墙配置为允许从我们的 Web 测试代理 IP 地址发出的传入请求。Configure your firewall to permit incoming requests from the IP addresses of our web test agents.
    • 编写自己的代码,定期测试内部服务器。Write your own code to periodically test your internal server. 在防火墙后的测试服务器上以后台进程的方式运行该代码。Run the code as a background process on a test server behind your firewall. 测试进程可以通过核心 SDK 包中的 TrackAvailability() API 将其结果发送到 Application Insights。Your test process can send its results to Application Insights by using TrackAvailability() API in the core SDK package. 这要求测试服务器能够以传出访问的方式访问 Application Insights 引入终结点,但与允许传入请求相比,这种方式的安全风险要小得多。This requires your test server to have outgoing access to the Application Insights ingestion endpoint, but that is a much smaller security risk than the alternative of permitting incoming requests. 结果不会显示在可用性 Web 测试边栏选项卡中,但会作为可用性结果显示在分析、搜索和指标资源管理器中。The results will not appear in the availability web tests blades, but appears as availability results in Analytics, Search, and Metric Explorer.
  • 上传多步骤 Web 测试失败Uploading a multi-step web test fails

    存在 300 K 大小限制。There's a size limit of 300 K.

    不支持循环。Loops aren't supported.

    不支持对其他 Web 测试的引用。References to other web tests aren't supported.

    不支持数据源。Data sources aren't supported.

  • 多步骤测试无法完成My multi-step test doesn't complete

    存在每个测试 100 个请求的限制。There's a limit of 100 requests per test.

    如果运行时间超过两分钟,测试会停止。The test is stopped if it runs longer than two minutes.

  • 如何使用客户端证书运行测试?How can I run a test with client certificates?

    抱歉,不支持这种测试。We don't support that, sorry.

后续步骤Next steps

搜索诊断日志Search diagnostic logs

故障排除Troubleshooting

Web 测试代理 IP 地址IP addresses of web test agents