模板
教程
环境
性能
功能
管理
软件测试中Web 测试的创作与调试技术
适用于：
Visual Studio 2005 Team Suite
Visual Studio 2005 Team Edition for Software Testers
摘要：学习有关 Visual Studio 2005 Web 测试的更多知识，包括 Web 测试引擎和记录器如何工作，以及如何创建有效的 Web 测试。
本页内容
.gif){kind=icon}
读者 简介 记录一个 Web 测试 运行并验证 Web 测试 解决常见的 Web 测试问题 深入研究进行编码的 Web 测试 小结
读者
本文面向的测试人员和开发人员，是那些想丰富有关 Microsoft Visual Studio 2005 Team Edition for Software Testers 中 Web 测试功能经验的人员。
.gif){kind=icon}
返回页首简介
Microsoft Visual Studio 2005 Team Edition for Software Testers 引入了一个全新的用于 Web 和负载测试的强大工具集。Web 应用程序的负载测试可跨多个计算机进行并模拟成千上万个用户，但其核心则是一个 Web 测试集合。本文针对的读者是这样一些测试和开发人员，他们想学习更多有关创建有效的 Web 测试并对它们进行调试，以确保按预期方式运行的技术。
返回页首记录一个 Web 测试
了解 Web Test Recorder
Web Test Recorder 挂钩到 Internet Explorer 对象模型，侦听不同的导航事件。该类记录的主要优点是，可以记录安全套接字层 (SSL) 和已验证身份的 Web 站点，而没有任何特殊的配置要求。
该记录方法的另一方面是，Web 测试中不记录诸如图像、级联样式表（cascading style sheet，CSS）文件和 JavaScript 文件这样的依赖请求。相反，这些依赖请求在 Web 测试执行过程中从 HTML 页中被分析出来并进行自动请求。该功能有助于 Web 测试能更好地还原装饰性的 Web 站点更改，使测试更关注于 Web 应用程序的实际使用。如果需要，也可以禁用该功能，方法是将请求的 ParseDependentRequests 属性设置为 false。
该记录方法的一个不足是，它可能无法记录由 JavaScript（例如，在 AJAX 站点上）、ActiveX 控件和某些类型的弹出窗口发出的请求，因为 Internet Explorer 无法始终引发所需的事件。在多数情况下，可手动地将丢失的请求添加回 Web 测试来解决这些问题，稍后将阐述这一点。
插入注释
在记录过程中插入注释有助于创建有效的 Web 测试，特别是当 Web 测试包含很多请求时。您应该使用注释来说明在 Web 测试的不同点应该采用什么逻辑操作，例如，“登录”、“将项 X 添加到购物车”等。当您稍后在 Web 测试编辑器中修改 Web 测试时，这些注释是非常有用的。
您也可以使用注释来说明需要添加什么样的验证规则以确保 Web 测试成功。较之于在 Web 测试编辑器中查看 HTTP 请求列表而言，在记录并查看页面时决定需要对每个请求进行哪些验证更容易进行。
谨记要记录 Think Time
Web 测试请求的 ThinkTime 属性是指用户在发出下一个请求之前花在当前页的“思考”时间。Think time 延迟用于在负载测试过程中估算实际用户的行为。由于 Think time 对 Web 测试可以生成的负载量会产生巨大的影响，因此在负载测试中可全面禁用它，以便将更大的负载应用到目标服务器。禁用 Think time 使您能够尽快发出对服务器的请求，而不会产生请求间的延迟。
Web 测试记录器在针对 Web 应用程序的请求进行记录时自动记录 Think time。在记录过程中，尝试估算用户通常在每个页面上将花费的时间。当记录完成后，查看针对每个请求记录的思考时间尤为重要。无意中造成的较长思考时间会极大地影响 Web 测试生成请求的速率。默认情况下，Think time 在 Web Test Viewer 中是关闭的。因此，较长的思考时间不可能立即体现出来。当 Think time 在 Web Test Viewer 中打开时，您将看到 HTTP 状态栏中显示“Thinking…[n]”，直到下一请求开始。默认情况下，Think time 在负载测试中打开。当暂停记录并输入注释时，Think time 计数器停止。
返回页首运行并验证 Web 测试
了解 Web 测试引擎
有关 Web 测试引擎需要了解的一个关键概念是，Web 测试在 HTTP 层工作。Web 测试包含一个 HTTP 请求列表；这些请求主要都是由查询字符串参数、窗体参数和针对 Web 服务器的 URL 组成的。Web 测试引擎执行这些 HTTP 请求，从服务器（一个或多个）检索响应，以及收集计时数据。
由于 Web 测试引擎在 HTTP 层起作用，因此它并不直接模拟客户端脚本，例如，JavaScript 或 ActiveX 控件。Web 测试关注在服务器上生成负载。因此，只影响 Web 页外观的客户端脚本对 Web 测试而言并不重要。那些在附加 HTTP 请求（例如，AJAX）中设置参数值或结果的客户端脚本影响服务器上的负载，而且可能需要手动修改 Web 测试来模拟该脚本。本文稍后将描述这些修改类型。
一个常见的误解是，由于记录发生在 Internet Explorer 中，因此认为 Web 测试必须使用 Internet Explorer 执行。事实并非如此。所有请求直接使用 Web 测试引擎执行；不发生与 Internet Explorer 或其他任何浏览器的交互。Web 测试引擎使用标准 HTTP 请求/响应消息直接与目标 Web 服务器通讯。
同样，在 Web Test Viewer 的 Web Browser 选项卡上嵌入的 Internet Explorer 控件只显示由 Web 测试引擎接收的响应页。Web 测试引擎将响应写入磁盘的临时位置，然后将临时文件加载到 Web Test Viewer 中的 Internet Explorer 控件。如果用于其他浏览器的页面没有在 Web Browser 选项卡上中正确显示，则使用 Response 选项卡对其进行验证。
另一个容易令人混淆的方面是，运行 Web 负载测试时可以选择不同的浏览器模板。这些浏览器模板只影响随每个请求发送的默认 HTTP 标头集。Web 服务器用于确定浏览器类型的关键标头是 UserAgent 标头。Web 测试引擎直接使用标准 HTTP 协议发出请求，而无论选择哪个浏览器模板。
使用 Web Test Viewer 验证 Web 测试
在将 Web 测试添加到一个负载测试并进行长期运行之前，重要的是确保该测试按预期方式正常工作。这就是引入 Web Test Viewer 的原因。Web Test Viewer 使您能够在运行 Web 测试时对其进行监视，并查看前一测试运行的所有方面。
.gif)
要验证一个新建的 Web 测试是否过载，只需查看该测试运行的结果并查明它是否通过。例如，对于一个不具有验证规则的 Web 测试而言，通过只意味着没有引发异常，没有规则失败，而且没有出现 HTTP 错误。对于验证而言，除了确保无错误执行外，还包括确保 Web 测试在目标 Web 应用程序上表现出正确的行为。重要的是查看每个请求的响应以确保它是正确的。
下表列出验证 Web 测试时需要查看的项，以及有关每种问题类型的附加信息。
|
要检查的问题 |
附加信息/解决方案 |
|---|---|
|
HTTP 请求错误 |
HTTP 错误由 400-599 范围内的一个响应状态代码表示。通常，一个 HTTP 错误包含一个指示该问题原因的响应体。 |
|
未找到依赖请求 |
顶级请求可能由于它其中的一个依赖请求未被发现而导致失败。这可能指示 Web 应用程序的 HTML 有问题。可以通过禁用针对该请求的 ParseDependentRequests 属性避免这些错误。这样就防止依赖请求（例如，图像、CSS 和 javascript）被自动地分析为 HTML 并进行请求。 |
|
提取和验证规则失败 |
提取和验证规则失败在 Details 选项卡中显示。造成失败的原因通常是 Web 服务器返回了包含意外内容的页，例如，重定向到一个登录页或错误的页。 |
|
测试级异常 |
在 Web Test Viewer 中，测试级异常显示为最后一次成功请求后的节点。测试级异常包括 WebTestPlugins、PreWebTest 和 PostWebTest 事件处理程序中的异常，以及非特定于编码 Web 测试中具体请求的异常。 |
|
请求级异常 |
请求级异常导致单个请求失败，但允许 Web 测试继续。这些异常包括从 WebTestRequestPlugins、PreRequest 和 PostRequest 事件处理程序，以及提取和验证规则引发的异常。异常消息以及堆栈跟踪（如果可用）在 Web Test Viewer 中 Details 选项卡的底部显示。 |
|
服务器返回的错误页内容 |
要验证 Web 服务器返回正确的内容，通常在 Web Test Viewer 的 Web Browser 和 Response 选项卡中以可视化方式检查每个页面。 |
返回页首
