商务参考体系结构B2C-调试和测试

第 8 章 调试和测试

Microsoft Corporation
2001年5月
摘要：本章简要介绍调试和测试过程，包括有关调试 ConsolidatedRetail.com 应用程序的通用信息、调试 PASP 脚本输出的说明、测试过程简介以及评估结果的步骤。本章采用的一些具体示例来自开发参考应用程序 ConsolidatedRetail.com 时实际执行的测试活动。
在为基于此参考体系结构的自定义软件编写测试计划时，您可以参考本文档。

简介

和开发其他任何应用程序一样，开发人员的任务是要确保企业对消费者 (B2C) 电子商务应用程序：
正确实现业务功能

性能和可伸缩性达到要求
为了确保应用程序实现目标，您必须深入调试并进行性能测试。
本章第一部分说明调试 ConsolidatedRetail.com 站点的步骤，以及如何查看和调试 PASP 脚本的 XML 输出。然后介绍测试的类型和级别、功能测试过程、性能测试，以及关于评估测试结果的一般性指导。

调试 ConsolidatedRetail.com 站点

调试网站给开发人员带来许多挑战，如果站点中包含 ASP 脚本程序之类的服务器端逻辑，这一点就更为突出。在运行 Microsoft® Windows® 的计算机上创建和调试基于 Web 的应用程序时，首选的开发环境是 Microsoft® Visual Studio® 开发系统，该系统包括了网站开发套件 Microsoft® Visual InterDev®。在网站中添加 Microsoft® FrontPage® Server Extensions，并基于该站点创建一个新的 Visual InterDev 工程，您就可以运用上述环境来调试 B2C 参考体系结构应用程序。
有关使用 Visual InterDev 进行调试的详细信息，请参考 Microsoft® MSDN® 开发人员程序库中的 Visual InterDev 文档。

调试 PASP 脚本的 XML 输出

调试 ConsolidatedRetail.com 站点时，要面对的另一个挑战是如何查看 PASP 脚本生成的 XML 输出。来自这些页面的响应数据流被 XSLISAPI 过滤器截取，然后使用指定的样式表显示。然而，有时候您需要在不应用样式表的请况下检查由脚本生成的 XML。
要查看 XML 输出，最简单的方法是为站点中的各个 *.pasp 文件制作 *.asp 副本，然后用 Microsoft Internet Explorer 访问这些 *.asp 文件。由于 *.pasp 文件的 *.asp 版本不会被 XSLISAPI 应用程序截取，所以 XML 响应数据将返回到浏览器，并可以通过显示结果页的源代码来查看。对于许多脚本，只需指定文件的 URL 即可访问，而对于其他一些脚本，必须在附加到 URL 的查询字符串中传递参数才能访问。下表说明了如何查看站点中各 PASP 文件的 XML 结果。注意：[b]  [/b]附录 A 提供了 ConsolidatedRetail.com 站点中 PASP 页的 XML 输出。
Acct.pasp：把该页另存为 Acct.asp，然后导航到 ConsolidatedRetail.com 站点并登录（否则当您尝试查看 Acct.asp 时会被重定向）。这样就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/Acct.asp）来访问 Acct.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

AddressBook.pasp：把该页另存为 AddressBook.asp，然后导航到 ConsolidatedRetail.com 站点并登录（否则当您尝试查看 AddressBook.asp 时会被重定向）。这样就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/AddressBook.asp）来访问 AddressBook.asp。要查看 XML，请单击“查看”菜单上的“源文件”。要获得更有意义的结果，请先使用该站点向您的地址簿中添加至少一个地址。

Basket.pasp：把该页另存为 Basket.asp。然后就可以使用 Internet Explorer，通过指定无参数的 URL（其格式为 http://服务器名称:81/Basket.asp）来访问 Basket.asp。要查看 XML，请单击“查看”菜单上的“源文件”。要获得更有意义的结果，请先使用该站点向您的购物篮中添加一些项目。

Category.pasp：把该页另存为 Category.asp。然后就可以使用 Internet Explorer，通过指定带有两个参数的 URL 来访问 Category.asp。（这两个参数分别是 txtCatalog 和 txtCategory，前者是您要浏览的目录名，后者是可选项，指定目录中的特定类别名。）例如，您可以通过指定以下 URL 来查看 Books 目录的 XML 表示： http://服务器名称:81/Category.asp?txtCatalog=Books要查看 Books 目录中的 Games 类别，可以使用以下 URL：http://localhost/Category.asp?txtCatalog=Books&txtCategory=Games返回相应的页面后，单击“查看”菜单上的“源文件”以查看 XML 代码。
Changepasswd.pasp：把该页另存为 Changepasswd.asp，然后导航到 ConsolidatedRetail.com 站点并登录（否则当您尝试查看 Changepasswd.asp 时会被重定向）。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/Changepasswd.asp）来访问 Changepasswd.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

EditAddressBook.pasp：把该页另存为 EditAddressBook.asp，然后导航到 ConsolidatedRetail.com 站点并登录（否则您将看不到任何地址信息）。查看该页所用的 URL 可以包括以下参数： txtAddressType – 地址类型，例如付款地址或发货地址。如果未提供任何值，则使用发货地址。

txtAddressID – 地址的全局唯一标识符 (GUID)。如果指定一个值，则返回相应的地址。
例如，要查看用户添加新发货地址时生成的 XML，请使用 Internet Explorer 导航至以下 URL：http://服务器名称:81/EditAddressBook.asp要查看用户添加新付款地址时生成的 XML，请使用 Internet Explorer 导航至以下 URL：http://服务器名称:81/EditAddressBook.asp?txtAddressType=Billing要查看用户编辑特定地址时生成的 XML，请使用 Internet Explorer 导航至以下 URL：http://服务器名称:81/EditAddressBook.asp?txtAddressID=地址 GUID完成检索该页后，单击“查看”菜单上的“源文件”以查看 XML 代码。
ForgotPasswd.pasp：把该页另存为 ForgotPasswd.asp，然后导航到 ConsolidatedRetail.com 站点并登录（否则当您尝试查看 ForgotPasswd.asp 时会被重定向）。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/ForgotPasswd.asp）来访问 ForgotPasswd.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

Index.pasp：把该页另存为 Index.asp。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/Index.asp）来访问 Index.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

Login.pasp：把该页另存为 Login.asp。关闭当前使用 ConsolidatedRetail.com 站点的任何会话（否则当您尝试访问 Login.asp 时会被重定向到 Acct.pasp）。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/Login.asp）来访问 Login.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

Multishipping.pasp：把该页另存为 MultiShipping.asp，然后导航至 ConsolidatedRetail.com 站点并登录（否则当您尝试访问 MultiShipping.asp 时会被重定向到 Login.pasp）。请向您的购物篮中添加至少一个项目（否则当您尝试访问 MultiShipping.asp 时会被重定向到 Basket.pasp）。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/MultiShipping.asp）来访问 MultiShipping.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

OrderHistory.pasp：把该页另存为 OrderHistory.asp。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/OrderHistory.asp）来访问 OrderHistory.asp。要查看 XML，请单击“查看”菜单上的“源文件”。您可以在不登录的情况下查看此页，但为了获得更有意义的数据，在查看此页前，您应该登录到该站点并至少提交一个订单。

OrderHistoryDetail.pasp：把该页另存为 OrderHistoryDetail.asp，然后导航至 ConsolidatedRetail.com 站点并登录（否则当您尝试访问 OrderHistoryDetail.asp 时将产生错误）。提交至少一个订单，然后可以使用 Internet Explorer，通过指定有一个参数（即订单，它应该是标识现有订单的 GUID）的 URL 来查看 OrderHistoryDetail.asp（否则将出错）。访问该页所使用的 URL 应该类似于以下示例： http://服务器名称:81/OrderHistoryDetail.asp?order= {0FA626B0-852E-4707-93D5-A00619C6A35B}完成检索该页后，单击“查看”菜单上的“源文件”以查看 XML 代码。
OrderSummary.pasp：把该页另存为 OrderSummary.asp，然后导航至 ConsolidatedRetail.com 站点并登录（否则当您尝试访问 OrderSummary.asp 时将产生错误）。提交一个订单并确认发货地址、发货方式和付费信息。然后导航至 http://服务器名称:81/OrderSummary.asp。单击“查看”菜单上的“源文件”以查看 XML 代码。

Payment.pasp：把该页另存为 Payment.asp，然后导航至 ConsolidatedRetail.com 站点并登录（否则当您尝试访问 Payment.asp 时将产生错误）。向购物篮中添加一个项目（否则当您尝试查看 Payment.asp 时会被重定向到 Basket.pasp）。然后导航至 http://服务器名称:81/Payment.asp 以查看 Payment.asp。单击“查看”菜单上的“源文件”以查看 XML 代码。

Product.pasp：把该页另存为 Product.asp。然后就可以使用 Internet Explorer，通过指定带两个参数的 URL 来访问 Product.asp 页。这两个参数分别是 txtCatalog 和 txtProductID，前者是您要浏览的目录名，后者是您要查看的产品的 ProductID。还有一个可选项 txtVariantID，是产品的变量 ID。例如，您可以通过指定如下 URL 来查看名为 Code 的图书的 XML 表示方法： http://服务器名称:81/Product.asp?txtCatalog=Books&txtProductID=Code单击“查看”菜单上的“源文件”以查看 XML 代码。
Registration.pasp：把该页另存为 Registration.asp。然后就可以使用 Internet Explorer，通过指定无参数的 URL（格式为 http://服务器名称:81/Registration.asp）来访问 Registration.asp。要查看 XML，请单击“查看”菜单上的“源文件”。

SearchResults.pasp：把该页另存为 SearchResults.asp。然后就可以使用 Internet Explorer，通过指定具有四个参数的 URL 来访问 SearchResults.asp。这四个参数分别是：txtSearchPhrase，您要搜索的短语；txtCatalog，您要搜索的目录名；可选项 txtSearchRowsToReturn，您要返回到用户界面 [UI] 上的结果编号；可选项 txtSearchStartPos，您要开始搜索的起始行号。例如，您可以通过指定如下 URL 来在 Books 目录中搜索词语 Age： http://服务器名称:81/SearchResults.asp?txtSearchPhrase=age&txtCatalog=Books Shipping.pasp：把该页另存为 Shipping.asp，然后导航至 ConsolidatedRetail.com 站点并登录（否则当您尝试查看 Shipping.asp 时会被重定向到 Login.pasp）。提交至少一个订单（否则会被重定向到 Basket.pasp），然后就可以使用 Internet Explorer，通过指定如下 URL 来查看 Shipping.asp：http://服务器名称:81/Shipping.asp 完成检索该页后，您可以通过单击“查看”菜单上的“源文件”来查看 XML 代码。
ShippingMethod.pasp：把该页另存为 ShippingMethod.asp，然后导航至 ConsolidatedRetail.com 站点并登录（否则当您尝试访问 ShippingMethod.asp 时会被重定向到 Login.pasp）。提交至少一个订单（否则会被重定向到 Basket.pasp），然后就可以使用 Internet Explorer，通过指定如下 URL 来查看 ShippingMethod.asp： http://服务器名称:81/ShippingMethod.asp完成检索该页后，单击“查看”菜单上的“源文件”以查看 XML 代码。
ThankYou.pasp：把该页另存为 ThankYou.asp，然后导航至 ConsolidatedRetail.com 站点并登录。提交至少一个订单，按照订购程序进行操作，直到显示 OrderSummary.pasp。然后就可以使用 Internet Explorer，通过指定如下 URL 来查看 ThankYou.asp： http://服务器名称:81/ThankYou.asp完成检索该页后，单击“查看”菜单上的“源文件”以查看 XML 代码。
UserProfile.pasp：把该页另存为 UserProfile.asp，然后导航至 ConsolidatedRetail.com 站点并登录。您可以使用 Internet Explorer，通过指定如下 URL 来查看 UserProfile.asp： http://服务器名称:81/UserProfile.asp完成检索该页后，单击“查看”菜单上的“源文件”以查看 XML 代码。

制订测试策略

进行测试要有侧重点，因为可能的测试区域很多，每一个测试区域又有不同的测试类型。由于总是存在资源限制（包括时间、人员或资金限制），所以按重要性划分要完成的测试区域以及测试类型和级别是非常重要的，并且这是初步测试计划的重点。

可能的测试区域

以下是测试时需要注意的可能区域：
用户界面 (UI) 测试：这些测试检查表单和一致性。检查内容包括屏幕显示效果（字体、大小、颜色和总体外观），以及该应用程序的所有表单中所有字段的数据确认。这两种测试都应根据软件规范文档进行。

业务逻辑测试：功能规范文档定义了期望在实际运营中实现的业务逻辑。因此，必须用一套测试案例来检查业务逻辑。对于参考体系结构的实施，这一测试过程可以从 UI 或从 Commerce Server BizDesk 实用程序（一个管理模块）来完成。该测试过程应该包括对不同类型的用户和不同站点进入路径的测试。

后端测试：在理想条件下，后端测试应该在数据库中进行。由于参考体系结构使用与 Microsoft® SQL Server™ 2000 表紧密集成的 Microsoft Commerce Server 2000，因此测试小组可以使用 Commerce Server 对象与这些表交互作用。测试小组可以编写占位程序以隔离方式测试 Commerce Server 对象，然后与代码生成的 XML 输出的占位程序的结果进行比较。您也可以在 UI 层进行比较。

可能的测试类型

测试小组可能会执行以下类型的测试：
功能测试确保该系统提供的功能与功能规范文档所述的相符。

回归测试确认当反复执行一系列相同的操作时，应用程序的响应相同。

安全性测试保证只有具有适当权限的用户才可以使用系统中指定的功能。由系统工程师为测试环境中的每个用户建立不同的安全设置。

性能测试确保应用程序在用户可以接受的时间范围内做出响应。

强度测试确认应用程序能适当地对多个用户和同时发生的活动做出响应。用户的数量必须提前约定，系统测试采用的硬件环境必须符合实际运营条件。

自动测试可用于回归和功能测试。如果系统稳定并且不频繁更改，这种测试就很有用。

平台测试确认应用程序在主测试计划中规定的操作系统和浏览器组合中能正确运行。

Internet 服务提供商 (ISP) 快速测试确认应用程序能对通过 ISP 连接发出的请求做出响应。

端对端界面测试检查所有输入、输出和系统。该测试确保应用程序与功能规范文档中规定的外部系统能够正确地交互作用。

应用程序重复实例测试确定当客户端运行相同程序的多个副本时是否会导致阻塞或其他问题。

输入和边界测试保证该系统只接受正确的输入。该测试确保输入的字符数不超过字段规定的最大字符数，以及在边界条件下工作正常（例如有效范围和 1 超界、空值、最大值、最小值、屏幕上字段的 Tab 键切换顺序等等）。

Windows/Internet GUI 标准测试验证应用程序具有标准的观感。

本地化测试保证应用程序可在不同的语言环境中运行。

欧元兼容性测试保证正确显示欧元。如果应用程序要接收来自欧洲经济与货币联盟 (EMU) 的货币值就要进行该测试。

转换测试检测需要经过转换，应用程序才能正常运行的所有数据。这些转换可能来自于旧系统或新架构所需的变更。

安装/升级测试检测安装/升级程序以确保该产品可以在现有版本的基础上进行安装。测试小组可以决定只测试完整版本，还是同时测试升级安装版本。

易用性测试确保应用程序易于使用，没有过多击键，并且易于理解。执行该测试的最好方法是找一些高级、中级和初级用户，然后听取他们对该应用程序可用性的意见。

随意测试用非结构化的场景来测试系统，确保它能正确做出响应。要实现这一目的，您必须请其他人在不知道操作步骤的情况下执行某一功能。

环境安全测试保证该应用程序能在实际运营环境中安装和运行。进行此测试时，SQL Server 和 Internet Information Services (IIS) 的安全设置必须与实际运营时的设置相同。

网络测试确定不同网络条件对应用程序的影响。例如，通过这种测试，能够发现使用低速网络连接时可能出现的问题。

灾难恢复（备份/恢复）测试确保万一出现灾难性事件，用户能够按照一定步骤恢复应用程序及其数据存储区。该测试应由运营支持部门负责。

基于应用程序的故障转移功能测试确保出现已有文档记录的故障情况时，基于应用程序的故障转移功能起作用。

用户接受性测试通常由那些具有与目标用户相似的技能和背景的用户来执行。目的是为了确定该应用程序满足用户要求和期望的程度（即面向用户要求的测试）。注意，测试小组并不实际执行该测试，但可能要监督或设计该测试。

内存溢出和内存泄漏测试确保应用程序可在技术文档指定的内存容量下运行。该测试还通过多次启动和关闭应用程序来检测相关的内存泄漏问题。

旧版本操作系统移植测试确保应用程序在安装更新版本的操作系统后仍能运行。

帮助测试确保联机帮助提供的内容与当前问题相关，并提供了解决办法。验证联机帮助内容时，测试小组并不检查业务规则的正确性。
在上述每个测试区域中，测试小组都必须决定所需完成的测试等级。如下所示：
高 - 非常重要，需彻底测试此区域。

中 - 执行标准测试

低 - 如果时间允许则测试
下一部分着重讨论功能测试。

功能测试

在开发电子商务解决方案的过程中，您应该仔细测试每个内部版本，确保应用程序具有功能规范文档所述的功能。这涉及到保证当出现应用程序设计中确定的各个用户场景时，应用程序按照设计期望的方式运行。

测试方法

在多数大中型项目中，将指定一个测试小组来执行功能测试。应用程序生成和测试交替进行，最终获得软件的发行版本。
图 8-1 显示了典型的应用程序开发和测试周期。有关测试周期中各阶段的详细信息，请参阅本章中相应的小节。

请单击此处，查看完整的图片。 图 8-1：典型的测试周期

阶段 1 - 编写测试目标和主计划文档

测试过程的第一步，是以文档形式明确测试目标，以及如何实现这些目标。确定测试的所有相关因素并形成文档是非常重要的，这包括测试假定、时间表、测试优先级、测试级别、职责、预期效果和决定因素、风险及其规避等等。完成计划后，将得到主测试计划文档，它在整个测试生命周期中是一个动态的文档。
在这一阶段需要的源文档是功能规范文档和代码的高级版本发布时间表。
请参阅本章前面“制订测试策略”中，测试小组在编制主测试计划时应考虑的测试区域和测试类型。

阶段 2 - 编写详细测试计划

详细测试计划描述所有用户或帐号的各种不同使用场景和进入路径。这些测试使用场景以应用程序设计过程中确定的使用场景为基础。详细测试计划还确定要测试的每个场景的优先级。
这一阶段需要的源文档是功能规范文档和高级应用程序和体系结构设计。

阶段 3 - 审核详细测试计划

开发小组必须审核详细测试计划，确保它符合应用程序的测试要求。测试计划获得批准后，才可以开始测试。

阶段 4 - 定义测试案例

应根据已批准的详细测试计划来产生详细测试案例，定义要在应用程序上执行的操作、输入的数据和预期的结果，以及记录结果时应采用的预定格式。在这个阶段，应按照要测试的功能的重要性来确定测试案例的优先级。（有时需要将详细测试计划中的每个场景都扩充成详细测试案例文档中的一个或多个案例。）另外，您可能需要制作一个测试案例执行顺序文档，从而节省执行时间。

阶段 5 - 测试应用程序

在实际测试阶段，您应该以端对端的方式测试所有应用程序路径，以确保它们符合功能规范。测试小组使用缺陷跟踪工具向项目管理人员报告测试过程中发现的所有缺陷。另外，测试小组可能要隔离这些缺陷。
此阶段需要的文档是详细测试案例。

阶段 6 - 确定生成/测试周期是否完成

仅在一轮测试过后便准备发布应用程序是不太可能的。是否重复执行另一轮生成和测试取决于很多因素，包括现存错误的严重性、预算限制和时间期限等。您的项目计划应该允许在发布前重复进行若干次生成/测试。

阶段 7 - 举行鉴定会议

测试小组、项目管理小组和开发小组将在鉴定会议中讨论缺陷的状况，以及哪个缺陷指定给哪个开发人员去解决。

阶段 8 - 消除错误

开发小组必须协同工作，消除鉴定会议上确定的所有错误。完成之后，将每个错误返回给相应的负责人（提交该错误的测试工程师）进行验证，如果验证合格就结束这个错误。错误消除之后，将每个错误返回给相应的负责人（验证该错误的测试工程师），如果该错误已修正就结束，否则就采取进一步行动。

阶段 9 - 编写测试报告

测试报告包含测试计划中列出的具体项目的状态信息，以及按严重程度分类的缺陷说明信息。
该报告对于发布决策会议（将在以下小节讨论）非常重要。

阶段 10 - 发布决策会议

测试完成后，程序管理小组举行发布决策会议，确定是否可以发布该应用程序。除了项目管理小组外，测试小组和开发小组都应参加此会议。
此会议要用到的文件主要是发布标准（在主测试计划阶段确定）和测试报告。

性能测试

在运营环境中部署电子商务解决方案之前，必须彻底测试应用程序，确保其满足性能和可伸缩性方面的要求。总的来说，应该以响应时间和吞吐量来测试应用程序，验证在预期数量的用户使用它时是否能提供可接受的性能水平。

响应时间

响应时间是从单个用户的角度来衡量应用程序性能的一项指标。它衡量从用户发出请求到应用程序做出响应所需的时间。可接受响应时间随站点的不同而有所不同，甚至与网页有关。例如，在进行身份验证时用户预期等待的时间，可能要比显示指定类别的产品时所能等待的时间要长一些。虽然“越快越好”的准则看起来是首选的设计模式，但是您应该清楚在某些情况下，响应时间应该为提供足够的安全性和可伸缩性而做出让步。
在电子商务应用程序中，影响响应时间的两个主要因素是网络延迟和应用程序处理时间。网络延迟可以用各种方法缩短。例如：
使用合理的基础设施体系结构来部署应用程序。例如，使用比集线器更快的交换机，并选择高性能的网络硬件。

缩短应用层之间的物理距离。

减少组件之间在网络上的功能调用。

缓存数据以避免不必要的数据库访问调用。
应用程序处理时间是应用程序执行特定任务需要的计算时间。您可以通过改善代码编写，并确保该应用程序使用解析脚本和编译代码的适当组合，来减少处理时间。另外，如果可能，使用异步编程模型可以大大优化响应时间。
响应时间通常随应用程序负荷的增加而增加。另外，某些程序错误（例如那些导致内存泄漏的错误）只在大负荷条件下才能检测出来。因此，执行响应时间测试时必须合理地模拟预期负荷。

吞吐量

吞吐量是对应用程序性能更整体的评价。它衡量应用程序处理多个并行用户带来的负荷的能力。吞吐量通常按每秒页数或每秒请求数来衡量。它是在大量用户访问应用程序时，该应用程序可伸缩性的指标。
提高吞吐量的策略包括：向外扩展（使用负载平衡群集中配置的多台服务器来分担用户负载），使用随机值作为分配关键字在多台数据库服务器上分配数据，利用缓冲技术（例如数据库连接缓冲和 COM+ 对象缓冲）减少资源抢用，以及向上扩展（增加服务器的硬件资源以处理更多负荷）。
要在电子商务站点上准确测试吞吐量，您必须归纳用户将会执行的活动类型。特别地，您必须确定期望的“购买/浏览”比率（预期的执行网上购物的用户百分比与仅仅浏览目录的用户的百分比）。该比率可能随不同类型的站点而变化很大（例如，在 B2C 零售站点，可能只有百分之二十左右的用户会有购买行为，而在 Internet 银行解决方案中，绝大多数用户都将进行某种交易）。很大程度上，此信息只有在站点投入运营后才能准确确定，但您可以使用根据类似站点的指标获得的最准确估算来进行测试。为了进行测试而模拟用户负载时，您应该反映出尽可能多的预期使用模式，以便更准确地掌握该应用程序在实际运营中的运行情况。
测试应该基于现实状况来执行。测试的基础设施体系结构应该尽可能接近您要用来部署应用程序的运营环境。例如，您应该使用配置了某种基于 IP 的负载平衡机制的多个 Web 服务器。不能相信仅从一台计算机上测试获得的性能指标！请记住，防火墙和加密设置等安全措施都会影响性能，测试环境应包含这些措施。

性能测试工具和实用程序

有很多用于收集性能统计信息的工具。这些工具包括：监视工具（例如 Microsoft Windows 2000 系统监视器和 Netmon、SQL Server Profiler），系统日志文件（例如 IIS 生成的文件），专用测试工具（例如 Microsoft Web Application Stress [WAS] 工具），以及其他一些第三方提供的强度测试工具。每个工具都有自己的优点和缺点，因此，要准确掌握应用程序的性能，不能只依靠一个工具。相反，应该使用多种工具测试应用程序。
Web Application Stress (WAS) 工具可用于模拟大量并行用户负载加到应用程序的情形。要应用它，您可以记录站点的一系列 HTTP 请求，然后让 WAS 工具按照指定的并行用户数量发出请求。该工具收集响应时间和吞吐量统计信息，可用于评估应用程序的性能。WAS 工具可以从 http://Webtool.rte.microsoft.com/default.htm（英文）免费下载，在此站点中您还可以获得有关使用此工具测试 Web 应用程序的更多信息。
当使用类似 WAS 的强度测试工具时，应创建若干个脚本（而不是一个脚本）来模拟不同的用户场景。这样，需要确定具体的性能瓶颈时，您可以运行一个脚本；在应用程序上模拟实际负载时，则可以同时运行多个脚本。多数强度测试工具允许您将各个脚本按相对强度比例加到系统上，这样可以使您更准确地反映预期在运营中出现的使用场景。

性能测试方法

B2C 站点的用户希望该站点始终运行良好。应用程序的性能、可伸缩性和整体可靠性是 Web 应用程序设计的要素。
性能分析方法包括以下不同的步骤：
准备分析

创建强度脚本

执行测试

分析结果

记录和提交结果
上述每个步骤将在以下各节中讨论。

准备分析

分析的第一个步骤涉及到收集信息。此信息应该提供复制应用程序环境和理解应用程序使用方式所必要的详细资料，并应该告知您全部现有性能问题。这些信息的来源包括市场预测、运营 IIS 日志、性能日志和应用程序的功能规范。当然，很多这些信息只在现在已投入运营的站点上才可能获得。对于新站点来说，您可以借助市场预测和类似站点的数据。您所收集的信息对于成功地进行性能分析至关重要。它有助于确定对测试环境的要求，并在从模拟环境到分析测试结果的整个分析阶段得到运用。
在开始分析之前，您还应该确定性能分析应交付哪些内容。应将性能分析的交付内容看作测试小组和应用程序所有者之间的合同要求。通常情况下，执行性能分析时，应用程序所有者可能不知道他们到底要从分析中获得什么。创建性能分析的交付内容清单可以为他们回答这个问题。
创建运营环境的副本
要获得最准确的测试结果，测试设备应该模拟当前或预期的运营环境，包括硬件和软件配置。如果实际运营中部署了负载平衡解决方案（例如 Microsoft 网络负载平衡或 Microsoft Windows NT® 负载平衡服务 [NLB/WLBS]），则测试环境应该反映出这一点。
测试设施也应该反映在运营中分配的服务器角色和服务器数量。例如，如果您在运营中使用具有三个 IIS 服务器的群集，请在强度测试实验室中使用与此匹配的配置。每个 IIS 服务器的 CPU、RAM 和磁盘配置也应该符合实际运营条件。Service Pack、驱动器和硬件的 BIOS 版本也必须匹配。匹配硬件和软件可以使您获得更准确的测试数据，从而无需进行推断。
由于预算或其他方面的限制，您可能无法创建与运营环境完全相同的测试环境。在这种情况下，进行数据分析时请务必注意不同之处。
要测试 ConsolidatedRetail.com 站点，请按图 8-2 所示将应用程序部署在用于测试的设施中。

请单击此处，查看完整的图片。 图 8-2：测试设施
工作站用于模拟 Internet 客户端（其中一台计算机运行 Windows 2000 Professional，另外两台运行 Windows 98），通过一个三级交换机访问站点。Web 层上的 IIS 服务器通过一个二级交换机与数据库服务器传输数据。所有 Commerce Server 对象和管道均部署在 IIS 服务器上（即，不存在单独的应用服务器的物理层），并且所有的站点数据（除了直接邮件数据库）都存储在位于二级交换机之后的 SQL Server 数据库服务器上。直接邮件数据库部署在 IIS 服务器上。
以上设施的设计目的是模拟应用程序的部署环境。
应用程序所有者的参与
很多时候，应用程序所有者已经自己进行了一些调查研究。与应用程序所有者讨论性能问题可以节约您的时间。他们可以帮助您更深入敏锐地观察其应用程序的性能。尤其是应用程序开发人员可能具有管理员无法提供的特定考虑和知识。如果他们的研究已经发现了瓶颈，那您的任务只是验证这些有问题的区域，并为开发人员提供更详细的信息。
理解应用程序背后的技术
在继续进行前先理解应用程序背后的技术是很有必要的。对应用程序理解得越深，则您的性能/强度分析将越透彻。例如，如果您知道某个应用程序大量使用 XML，那么您应该掌握 XML 的性能调试方法。
对于 ConsolidatedRetail.com 应用程序，测试小组必须非常熟悉 Commerce Server 2000 的部署和使用以及 XML 和 XSLISAPI 过滤器。
定义交易/用户场景
要成功地完成性能/强度分析，您必须清楚最终用户使用应用程序的日常情况。您会发现某项任务往往比其他任务执行得多。您的性能/强度脚本应该反映出这种使用模式。确定使用模式时，请务必与市场和产品支持人员进行交流。通常他们与用户接触更多，并对这些统计信息有更深刻的理解。IIS 日志文件也是很好的资源，有助于掌握应用程序组件或网页的访问频率。日志非常有用，不仅可以用于在脚本中定义用户场景，还可用于比较验证强度测试分布和运营中的实际页面浏览量分布。
对于 ConsolidatedRetail.com 站点，预期的使用模式是百分之八十仅浏览，百分之二十进行购买。另外，在那百分之二十执行购买的用户中，期望其中一半是已经注册过的回头用户，另一半是在付款前需要先注册的新用户。
定义目标
务必定义清楚分析的目标，并将这些目标包含在测试计划中，使大家对要提交哪些分析内容达成共识。这可以减少被迫重新运行测试脚本的风险。重新运行脚本将浪费时间和资源，并对分析产生不良影响，因为测试小组往往会因为缺乏时间而赶工。

创建强度脚本

收集完所需信息并准备好测试环境后，性能/强度分析的下一步是创建能准确模拟预期站点流量的强度脚本。这可以使用从当前版本站点获取的历史数据或市场和业务分析家的预期数据来完成。要生成高度可靠的强度脚本，请考虑以下各小节所讨论的因素：
创建多个脚本
处理多个场景时，应该避免用单个脚本来包含所有场景。使用单个巨大的脚本将导致很难隔离出使整个脚本运行缓慢的特定场景。例如，要模拟普通电子商务站点，您可能需要一个用户浏览目录和产品的场景，一个用户将产品添加到购物篮然后付款的场景，还有一个用户搜索产品的场景。如果测试小组创建三个独立的脚本，就可以分别执行强度测试，确定每种用户场景的瓶颈，也可以同时按预期情况模拟混合流量。
避免记录和播放
静态网站早已成为过去。如今的多数站点（尤其是那些用于电子商务目的的站点）都具有完全动态的内容。正是由于这一原因，您不能简单地通过记录和播放基本的 get 和 post 命令来准确地模拟站点。您可能需要自定义是否让站点自动生成一些项目，如购物者 ID、购物篮 ID、订单 ID 和 GUID 等。很多测试工具具有捕获各线程（虚拟用户）的动态变化变量的功能，但您需要验证脚本结果以确保正确生成变量。
很多测试工具还具有从 .csv 或 .txt 文件导入数据的能力。该功能允许您从 SQL 数据库中导出产品和目录列表，然后用此文件包含的数据提高脚本的动态性（从而避免脚本反复使用相同的产品）。WAS 工具可以创建一系列变量用于您的脚本，例如，用户名、密码、产品和类别都可以通过变量来生成。
验证强度工具的操作
在进行大范围测试之前，您应该先验证强度工具是否作为真实用户准确地使用该站点。为此，您必须理解在 IIS 服务器和 SQL Server 上，各 ASP 页访问和执行的内容。在跟踪 ASP 页的运行时，IIS 服务器日志文件和 SQL Profiler/Trace 文件是可供利用的极好资源。更准确的方法是使用浏览器浏览整个站点，并记录所有的 SQL 命令和为每个页面调用的存储过程。另外，请注意所有显示在强度脚本所包含页面的 Web 内容（例如 GIF、XML、ASP 和 HTML 文件）都会出现在 IIS 日志中。然后，您可以对一个用户播放脚本并仅运行一次此场景，同时验证 SQL 跟踪文件和 IIS 日志是否记录了相应的服务器端活动。

执行性能/强度测试

在这一步，您应该事先准备好用于运行该应用程序的服务器环境和模拟客户端负载的脚本。性能/强度分析的第三步是运行脚本，执行强度测试。以下各小节概述了执行性能/强度测试的一些要点。
快速测试站点
快速测试可以确定发现应用程序系统瓶颈所需要的客户端数量和线程数量。Microsoft 建议使用多个客户端运行较少量的线程，而不是使用单个客户端运行多个线程。这里的快速测试是指运行若干个简短的强度测试，从而找到客户端和虚拟用户线程之间的优化比率。优化的意思是该比率在服务器上，而不是在强度客户端上，造成性能下降或瓶颈。
开始收集性能数据
当您获得客户端和线程之间的正确比率后，请启动所有服务器的系统监视器，打开每个计数器，开始进行测试。对于持续 30 分钟左右的测试，您可以以 15 秒或 30 秒为间隔。对于更长时间的测试，则以 60 秒到 300 秒的间隔使日志文件大小保持最小。
在开始测试前重置 IIS 日志
清除 IIS 日志可使数据分析过程更容易一些。您可以通过使用 iisreset 命令或 net stop iisadmin /y 命令来关闭 IIS Administrator Service (iisadmin)，从而重置日志。然后，删除 C:/Winnt/System32/Logs 中的 IIS 日志文件, 使用 net start w3svc 命令重新启动 w3svc 服务。
清除 Windows 事件系统、安全和应用程序日志
清除 Windows 事件日志可让您确定在强度测试过程中，站点所产生的任何异常错误消息。
配置和启动 SQL Profiler
在 SQL Server 上，启动 SQL Profiler/Trace 并只添加 T-SQL 和 Locks 事件。这将显示所有 SQL 命令和存储过程、读取、写入及命令周期和任何发生的死锁。注意，SQL 跟踪文件的大小将随测试的进行而快速增大。因此，只有不超过 30 分钟的测试，才可以一次收集整个测试的信息。而对于更长时间的测试，Microsoft 建议在测试的开始、中间和结束分别按 30 分钟间隔运行 SQL Profiler。如果还有其他的 SQL Server，您可以将跟踪设置为将信息记录到数据库（而不是文件）中。
创建受控环境
如果可能，尽量在 IIS 群集或 SQL Server 上没有其他活动时执行强度测试。使用受控环境，您可以确保不存在来源于您的强度客户端之外的异常错误消息、页面浏览、网络通信或负载。
分析结果
在运行测试并生成测试数据之后，就进入分析阶段。首先，您应该验证强度测试成功进行了模拟，然后再进行完整的数据分析。此过程将在以下各节中简单说明。
停止模拟和暂停数据采集
停止运行强度脚本、系统监视器和测试环境中所有客户端和服务器上的 SQL Profiler/Trace。确保系统监视器、SQL Trace/Profiler、IIS 日志和 Windows 事件日志已经保存在单独的目录中，这样您可以归档和组织测试数据。
检查 Windows 事件日志
浏览 Windows 事件日志并确保其中没有您的强度脚本产生的异常消息。作为强度测试结果的错误是可以接受的。
分析性能监视器数据
系统监视器数据有助于确定系统 CPU 使用、内存使用、磁盘队列和 w3svc 计数器等指标。
分析 SQL 跟踪文件
在分析 SQL 跟踪文件时，请搜索具有较长周期（一秒以上）的 SQL 命令和存储过程、以及大量的 SQL 读或写操作。如果不熟悉 SQL Server 的性能调试，请将您的跟踪结果转交给 SQL 设计者进行更深入的分析。调试 SQL Server 可能需要添加一些索引并在存储过程中更改代码，甚至可能会涉及改变数据库设计的体系结构。
验证访问的页面
IIS 日志可以帮助识别在强度测试期间被访问的所有页面。另外，Commerce Server 2000 统计信息和 IIS 日志文件可以导入到数据仓库，并可以使用 Commerce Server Business Desk 的报表模块进行检查。这可以进一步揭示测试期间站点活动的情况。
测量站点的吞吐量
吞吐量是根据已成功完成的用户场景来计算的。例如，成功创建购物篮、处理订单和执行搜索都被视为电子商务站点上的成功完成的场景。不仅开发人员，其他大多数人也都能够理解这些指标。要定义吞吐量，一个最简单最准确的方法是使用数据库中的表，然后计算测试前后的改变量。然后使用 IIS 日志合并处理这些数据，并计算实际页面浏览次数。
SQL 表和吞吐量分析
正如上面提到的，SQL 数据库中的表还可用于计算成功交易的数量。例如，如果有一个购物篮表，请在强度测试前后计算行数。两者之差便是强度测试期间创建的购物篮数量。查询的结果以及测试的开始和结束时间记录，有助于确定交易/时间吞吐量比率。
验证吞吐量
在此验证过程中要回答的关键问题是，IIS 日志指示的交易数目与数据库条目表明的全新交易数目是否相符，如果不相符，原因何在。用于验证吞吐量的另一个潜在信息来源是强度工具报告，尽管这些报告与服务器端数据相比总体上会高估了实际情况。因此，如果存在差异，您可能要采用服务器端的数据。通过两个或更多信息来源验证吞吐量，可以使您的结果更可信。