测试 XML Web 服务 (基础)

引言

本白皮书旨在介绍 Web 服务测试的挑战。它面向对 Web 服务或其工作方式没有详细技术知识的开发人员、测试人员和项目经理。本白皮书特别强调 Web 服务的负载测试。

什么是 Web 服务？

过去，如果您想在互联网上预订假期，您会浏览旅行社的网站，选择一个假期并进行预订。如果幸运的话，您还可以预订汽车租赁，甚至可能查看天气。在幕后，Web 服务器（网站所在的计算机和软件）会访问某种数据库中的专有格式数据，或者会以专有方式与后端系统通信，以获取有关您假期的信息。

这一切都将随着 Web 服务的概念而改变。Web 服务是一个位于网络某处并仅响应客户端特定请求的系统。这些客户端不是用户从自己的办公桌前浏览互联网的真实用户；它们是其他计算机。当您预订假期时，您仍然会浏览您的旅行社的网站，但在幕后会发生一些不同的事情。为了查找航班信息，Web 服务器将与 Internet 上的某个 Web 服务通信，而不是访问数据库中的专有数据。这个 Web 服务每天所做的就是响应旅行社网站的航班信息请求。更重要的是，这些 Web 服务将能够公开它们的存在，并以开放的、公开的格式与网站和其他 Web 服务进行通信。旅行社网站将访问不同的 Web 服务以获取航班、住宿和天气信息。

由于 Web 服务在 Internet 上，并且由于它以标准、已发布的协议进行通信，这意味着任何人都可以与其通信。如果您正在举办一个会议，并希望人们前来参加，您可以在您的网页上设置一个“飞往此处”页面。只需 5 分钟的编码，您就可以让人们在不离开您网站的情况下，查看飞往您会议的航班可用性并在线预订航班。

图 1 - 旅行社 Web 服务

测试 Web 服务有哪些挑战？
像所有软件一样，Web 服务也需要进行测试。像网站一样，它们通常非常重要，因此需要非常健壮。

Web 服务有两种主要类型：内联网 Web 服务和 Internet Web 服务。内联网 Web 服务是组织内部使用的 Web 服务，不对公众开放。例如，内联网 Web 服务可能负责处理员工的休假请求。然后，公司的内联网网站将访问此 Web 服务，员工可以请求休假。经理可以授权休假，同事可以查看其他员工何时休假。然后，人力资源部门可以编写一个简单的 Visual Basic 应用程序，以确保帮助台员工不会同时休完所有假期，而无需详细了解这些信息是如何或在哪里存储的。上一段中的假期 Web 服务是 Internet Web 服务的一个例子。

测试内联网和 Internet Web 服务会带来细微不同的问题。对于内联网 Web 服务，您作为组织，很可能控制谁访问您的 Web 服务。由于它位于内部网络上，只有内部用户可以访问它，因此您有一个理论上的最大值。同样，您可以对安全性做出某些假设。对于 Internet Web 服务，任何人都可以访问它。这意味着存在额外的可伸缩性和安全考虑。

测试 Web 服务的另一个挑战是它们完全没有用户界面；它们不显示用户界面供测试。这意味着它们很难手动测试，但非常适合自动化测试。因此，需要测试 Web 服务的测试人员几乎肯定需要具备一定的编程技能。Web 服务不是那种可以通过敲键盘来测试的应用程序。

不同类型的测试

与任何其他应用程序一样，您可以对 Web 服务进行不同类型的测试。

概念验证测试

Web 服务是一种新型软件。因此，您需要了解您为 Web 服务选择的架构是否是正确的。需要做出许多不同的选择——例如，使用哪个工具供应商、使用哪种编程语言以及哪个数据库后端。如果您能在开始开发之前或在开发生命周期的早期阶段澄清和解决这些问题，那么您将节省大量时间和金钱。由于您需要解决的大多数问题都与可伸缩性问题有关（我们使用的架构是否真的能应对 1000 个并发用户），因此概念验证测试通常是简化的负载测试（如下文所述）。无需在强大的硬件上运行它，也无需获得精确的答案；您的目标是回答“我走在正确的方向上吗？”这个问题。

功能测试

这是为了确保 Web 服务的功能符合预期。如果有一个 Web 服务用于除法，它是否会得到预期的结果？如果将 0 作为分母传入，它是否能正确处理？您的 Web 服务是否按预期实现了安全性/身份验证？您的 Web 服务是否支持它应支持的所有通信协议？由于您无法控制的客户端可以访问您的 Web 服务，那么当它们发出您意料之外的请求时会发生什么？边界测试和错误检查尤其重要。

回归测试

回归测试通常是功能测试的简化版本。它的目的是确保 Web 服务在构建或发布之间仍然正常工作。它假定某些功能过去是有效的，它的工作是检查它是否仍然有效。如果您的开发团队更改了执行除法的方法，该方法是否仍然有效？执行乘法的方法是否仍然有效？性能是否仍然可接受？由于回归测试本质上是一项重复性任务，因此必须对其进行自动化。这对于传统应用程序和网站来说是真实的；对于没有用户界面的 Web 服务来说更是如此。

负载/压力测试

本白皮书将重点关注负载和压力测试。负载/压力测试的目的是在访问 Web 服务的客户端数量增加时，了解 Web 服务的扩展能力。您已经进行了功能和回归测试，所以您知道您的 Web 服务可以处理单个用户。现在您需要知道的是它是否能处理 10 个、100 个或 1000 个用户，或者它能处理多少用户。如果您将用户数量加倍，响应时间是否保持不变？如果您运行 Web 服务的服务器数量加倍，其容量是否会加倍？本白皮书中接下来的部分将详细介绍这些问题。
监控
一旦您的 Web 服务上线并被真实客户使用，您就需要密切关注它。它是否仍然正常工作？响应时间是否足够？一天中的哪些时间最繁忙？密切监控 Web 服务至关重要。

负载/压力测试

本白皮书侧重于 Web 服务的负载和压力测试。需要注意的是，这几乎是凭定义必须是自动化任务。您无法雇用 1000 人来模拟 1000 个访问您的 Web 服务的客户端。

为了产生客观结果，在受控环境中进行测试很重要。如果您想了解您的 Web 服务在模拟越来越多的用户时是如何响应的，那么这意味着您必须保持所有其他因素（例如硬件和网络）不变。这意味着您不应该在 Internet 上的实时系统上进行负载测试。除了带宽可能带来的问题之外，这不是一个受控的环境。

您可能会决定根本无法在内部进行测试。如果您正在编写一个需要处理每秒 10,000 个请求的大型 Web 服务，那么您很可能没有必要的内部硬件来完成此任务。您可能需要考虑聘请第三方咨询公司，或使用第三方可伸缩性实验室来执行此测试。

负载测试的最终目标是让您放心并确认“我的 Web 服务可以接受地响应多达 x 个客户端每秒 y 个请求”。

在开始之前，您需要决定客户端是谁。它们是其他 Web 服务、其他网站还是其他类型的应用程序？您是否知道您的 Web 服务有多少潜在客户？

回答了这些问题后，您需要确定这些客户端将做什么以及多久一次。您可能有不同类型的客户端做不同的事情；10% 的客户端可能正在预订航班，而 90% 的客户端可能只是在查看航班可用性。

如果您预计有 100,000 个客户端，但这些客户端每天只会发起一个请求，那倒还好（大约每秒 1 个请求）。但是，如果这些请求中有 50% 发生在上午 9 点到 10 点之间，那情况就不同了（大约每秒 15 个请求）。另一种可能性是，您只有 100 个客户端，但这些客户端每秒都会发出 10 个请求，而且是全天候的。总之，了解您的客户很重要。

您可能预计平均可以处理每秒 100 个请求，但在出现大量高峰时会发生什么？您的 Web 服务会应对、减慢还是崩溃？还是它会简单地拒绝处理第 101 个请求？这些都是您在发布 Web 服务之前需要了解和测试的事情。

您还必须了解客户端将如何访问 Web 服务。很可能他们会发送 SOAP 请求。在这种情况下，您应该确保您的 Web 测试工具支持此协议。市场上的一些测试工具通过浏览代表 Web 服务的网页来记录脚本，然后记录浏览器发出的 HTTP GET 和 POST 请求。虽然相似，但这与您客户几乎肯定会使用的 SOAP 请求不同。

下一个需要回答的问题是“什么是可接受的？”您的服务级别协议可能规定您需要在 1 秒内响应 95% 的请求；在这种情况下，您就知道什么是可接受的。无论如何，重要的是要意识到 Web 服务与网站不同，因此可接受的响应时间也会不同。虽然网站的响应时间保持在 10 秒以下是可以接受的，但一个网站可能会对不同的 Web 服务发出 10 次调用，因此网站希望每个 Web 服务在 1 秒内返回信息。

在进行测试时，您使用的工具应该能够识别这些值在您增加客户端数量时如何变化。这些都是对客户端如何体验您的 Web 服务的衡量标准。

• 连接时间：这是从客户端到 Web 服务建立连接所需的时间。这应该尽可能低。
• 第一字节时间：这是客户端开始从 Web 服务接收数据所需的时间。如果 Web 服务需要为每个请求进行大量计算，那么这个时间可能会很长。
• 最后一个字节时间：这是客户端接收服务返回的最后字节信息所需的时间。如果服务需要返回大量数据（例如，如果它返回地图或图像），那么这可能会很长。

尽管这些指标的绝对值很重要（您希望将这些数字保持在尽可能低），但它们在您增加 Web 服务负载时如何变化更为重要。理想情况下，您希望这些指标保持不变。如果它们线性增加，那么您将大吃一惊。假设对于 1 个用户，最后一个字节时间是惊人的 10 毫秒，对于 10 个用户是 1/10 秒，对于 100 个用户是 1 秒。这仍然是合理的。对于 1000 个用户来说，这将是 10 秒，这可能无法接受。如果您的 Web 服务需要处理 10,000 个用户，那么请求将花费超过一分钟。这显然是不可接受的。

更有可能的是，您会发现您的 Web 服务可以扩展（即请求的响应时间保持不变），直到达到一定数量的虚拟用户，然后它就停止扩展了。要解决这个问题，您需要密切关注服务运行所在服务器上的性能。您需要知道是什么导致了这种行为的变化；是 CPU 过载、磁盘颠簸还是网络卡导致了瓶颈？这些都是导致性能问题的可能原因。此详细分析超出了本白皮书的范围。

一旦您的系统达到瓶颈，您就需要知道是否有办法解决这个问题。如果您在服务器上添加另一个处理器，它的容量会翻倍吗？如果您添加另一个服务器，它的容量会翻倍吗？如果您的 Web 服务可以以这种方式扩展，那么您就知道可以通过在问题上投入越来越多的硬件来应对额外需求。如果您的 Web 服务不能以这种方式扩展，那么无论您在昂贵的硬件上花费多少钱，您的 Web 服务都不会有好的表现。

图 2 - 具有不同可伸缩性属性的 Web 服务

在上图所示的示例中，Web 服务 1 在大约 120 个请求/秒时扩展良好（最后一个字节时间恒定），然后停止扩展。Web 服务 2 扩展效果不佳——随着请求/秒数量的增加，响应能力呈线性下降。

结论

测试 Web 服务带来了许多独特的挑战，只有通过使用自动化测试工具才能克服。在设计阶段检查 Web 服务的容量和可伸缩性，以及在发布前进行全面的负载测试，这一点很重要。

本白皮书仅触及了 Web 服务测试的表面，但希望已为您提供了一些关于其中涉及内容的有用想法。

作者简介

本白皮书由 Red Gate Software Ltd. 的技术总监 Neil Davidson 撰写。Red Gate 的最新产品是 Advanced .NET Testing System (ANTS)，这是一款用于 .NET 网站和服务的概念验证和负载测试工具。有关更多详细信息，请访问 www.red-gate.com/ants.htm。