微软测试过程

Microsoft 测试

各种测试的简要说明：

• 字段编辑测试。字段编辑检查要查看格式编排、边界以及计算错误。如果日期需要限制在特定的时间范围内，该软件是否允许输入该时间范围外的日期？是否要求数字字段只包含数字？如果输入了字母会出现什么情况？如果包含计算，计算执行是否正确？字段输入框对请求的输入来说，是否足够大？如果有下拉框，其值否正确？
• 流控制和状态测试。在用户填写完表单中的字段并按下按钮后，逻辑是否会到达期望的进程？下一次显示同一页面时，其中的值是否正确？有时页面第一次显示了正确的值，而以后不再显示；或者情况相反。
• 配置测试。在可行的情况下，会用尽可能多的“受支持服务器”和客户程序配置对应用程序进行测试。
• 负载测试。在将页面或 Web 应用程序作为整体进行测试之前，应首先在组件级别进行负载和性能测试，以确保应用程序的每一部分能够在适当的指标下运行。这种隔离测试使测试小组能够更迅速地发现使用特定技术的问题。如果一个执行数据库查询功能的小脚本太慢，进行组件级别的测试比进行整个页面或应用程序测试更容易发现它。
• 回归测试。开发部门修复了代码中的错误后，我们会重新进行测试，以检查错误是否被修复并确保所做的修复不会引起其它问题。

一个典型的计划包括：

• 环境模拟信息。该文档指定设置服务器和客户机测试站所需的硬件和软件。这包括操作系统版本、应用的服务包或修补程序、其它所需软件（如 SQL Server）的版本以及所有受支持浏览器的列表。测试小组有一个实验室，配备的计算机运行标准的浏览器和操作系统与不甚标准的浏览器和操作系统的组合。
• “基本测试”标准。这是在进行深入测试之前应该能够执行的一些基本功能。如果代码不能满足这些最低标准，进行测试就是浪费时间。开发成员和测试小组的成员会在项目的规划阶段对基本测试标准的定义形成一致意见。
• 要测试的组件和页面的列表。该列表详细列出了每个 DLL、小脚本、过滤器和页面。从而允许对每个组件进行系统测试，并随后对页面进行测试。
• 测试方案。这些开发的方案用来模仿用户在使用工具或页面时通常会采取的步骤。
• 测试案例。根据测试方案，每个案例都包含一系列设计好的步骤来测试页面或 Web 应用程序的功能、流、状态、用户界面以及负载能力。案例中可以包含一些说明，如在数字字段中键入字母字符、从下拉菜单中选择一个特定的值或者让几个用户同时进行复杂的表查询。

测试 Microsoft Communities
要了解测试计划如何运行，请看我们的测试小组如何评估最近的 Microsoft Communities 项目。

首先，在接受项目进行测试之前，该项目必须符合一系列的最低标准。对 Communities 来说，这意味着开发人员自己必须先对要提交进行测试的内部版本代码进行一些预先的测试。在提交代码之前必须修正所有已知的错误。然后只须将该站点必需的代码与发布说明（列出了每个内部版本中比以前内部版本新增的功能）、说明如何安装并配置所有代码和脚本的安装指导以及此次提交的所有文件的明细元素列表一同提交到特定的收集位置。

   我们的测试小组首先要做的是确保提供的所有信息正确，并且所有必需的文件存在。然后，将软件安装在专门设计的系统上，该系统非常接近实际的环境 - 工具或页面最终要发布的 Web 服务器环境。之后，假定一切按照预期的情况运行，进行一系列验证基本功能的基本测试。

   项目通过基本测试后，就开始执行测试计划中的内容。对于 Communities，这意味着要执行 22 个步骤以验证其功能。我们将测试消息推放到新闻组，验证窗格是否可以调整大小，并将基于 Web 的工具中的实际文章与用另一新闻组客户程序拉取的同一新闻组进行比较，以确保在两种情况下显示的文章相同。请参阅辅助说明 2 中关于功能测试案例的完整列表。

   最后一步是进行性能测试，以确保工具或页面能够完全承受我们繁忙的 Web 站点上的各种通信量。我们通过有限几台计算机利用 Microsoft Web Application Stress Tool 来模拟大量的 Web 浏览器请求。

错误筛余
当开发人员提交了代码后，测试小组会检查其功能、性能以及与现有软件的兼容性。发现的所有错误都将记录在我们的内部错误跟踪系统中。

在测试周期结束时，开发部门和测试小组将一起讨论这些错误，给每个错误编上优先序号和严重等级。开发者会解决错误列表上的问题并将修订后的代码返回给测试小组进行回归测试。此不断反复的过程将持续进行，直到系统就绪，交给发布小组进行发布。

在交付给发布小组的产品中，测试人员要提供测试摘要文档，该文档包括：

• 关键代码的复本
• 与性能数据等有关的记录和信息，让发布小组可以了解他们启动工具或服务后应看到什么样的性能。如果感觉应用程序运行缓慢，他们可以检查此信息以了解其是否在预定的标准下运行。
• 环境的设置说明，包括自最初进行测试以来所做的任何配置变更。
• 所测试的浏览器的列表等
• 已修复的所有错误的列表
• 风险和重要事项列表，其中包含测试小组由于无法模拟特定的过程而未能测试的任何方面以及对任何未能修正的错误的描述
• 该应用程序的产品安装及使用建议

运作监控
在发布一个复杂的新 Web 工具前，我们可能将其放在并行服务器上投入运营并请一些 Microsoft 员工协助进行重负载测试和集成性测试。当认为其适于在运营服务器上发布时，我们会继续在其运行过程中监控并跟踪其中的错误。

发布后，外部用户可以用 Microsoft 的联系页记录任何关于我们的活动工具和页面的问题并提出建议。测试小组成员会监控这些报告，并协助调试和监控活动服务器。这种协作实现了基于实际应用中的服务器上实际通信量的精确测试。

多数此类监测都包括检查 IIS 和事件日志，还要检查 Performance Monitor（该程序是跟踪各种 IIS 统计数据的应用程序）提供的信息。请参阅辅助说明 4 中应查看的主要 Performance Monitor 计数器。有关 Performance Monitor 的更多信息，请参阅 TechNet 文章 Monitoring and Optimizing Internet Information Server。

重新使用和自动操作

    重新使用适用于代码，也同样适用于测试计划和方案。每个新计划都以以前的计划为参考。当测试案例可以重新使用时，便会直接拿来使用。

要取得最佳效果，请记住以下经验：

• 在开发过程一开始就让测试小组参与进去。
• 在测试整个工具或页面之前分别测试每个组件。
• 充分利用大有裨益的工具，如 IIS Performance Monitor 和 Web Application Stress Tool。

辅助说明 1：
Microsoft Communities
基本测试

---

下列每一项都应该用每个受支持的 Web 浏览器执行：
左侧导航窗格：
		是否能够在左侧的导航窗格中来回移动，该窗格显示是否正确？
		是否能够在左侧的导航窗格中来回移动，该窗格显示是否正确？
		是否能够在大于屏幕的区域内滚动？
		是否能够选择不同的新闻组，文章列表是否显示在右上窗格中？
		是否能够调整左侧导航窗格以及右上和右下窗格的大小？
右上窗格：
		右上窗格是否正确地显示文章，是否保持了每篇文章的连载状况？
		是否可以遍历连载文章？
		读过一篇文章后，它是否被标记为红色？
		如果文章列表大于一个页面，是否能够遍历右上窗格中的各个页面？
右下窗格：
		是否可以选择一篇文章并显示在该页面的右下窗格中？
		是否能够发布新消息，回复组，回复个人或转发文章？
		在回复个人或转发消息时，默认的邮件客户程序是否启动并显示新消息？
		是否能够伴随文章发送附件？
		是否可以查看附件？
	辅助说明 2： Microsoft Communities 功能测试 案例

 

工具栏：
	验证工具栏适合其所在的页面并能够根据浏览器窗口调整大小。
	验证本地菜单能够正常运行。
	验证本地菜单中的链接。
	验证全局菜单能够正常运行。
	验证全局菜单中的链接。
	验证工具栏上的所有图形。
	验证工具栏框架大小不可调整。
左侧导航窗格：
	验证左侧窗格可以调整大小。
	验证各个组是根据新闻组名称来区分的。
	验证各个组是按照字母顺序排序的。
	验证您可以在各组之间来回移动。
	验证当单击某个组时，它将在文章窗格中列表显示。
	将该列表与 Outlook Express 5 中列出的组进行比较。
右上部的文章列表窗格：
	检查 Outlook Express 5 和 Communities 以验证能够正确列出所需组的组列表。
	当有不止一个页面时，列出该列表中的每个页面。
	尝试打开会话的所有连载以确保其包含消息并且与正确的上级消息相关。
右下部文章查看窗格：
	执行发布和回复组的操作，按照以下每一项进行回复和转发：
	在每个字段中使用最小的字符数。 在每个字段中使用最大的字符数。 在每个字段中使用无效字符。
	验证所读的文章与 Outlook Express 5 中同一文章一致。
小脚本：
	通过用测试脚本调用每个函数来验证以下函数：
	GetMessage、GetMessageList、GetMessageAttachment 和 PostMessage。
Microsoft SQL Server Backend：
	验证报头与 NNTP (Usenet) 服务器中的报头一致。
	验证没有丢失报头。
	验证报头正在服务器之间复制。

 

辅助说明 3： Microsoft Communities 性能测试 案例 用最小受支持同步连接数 (1,000) 进行测试。 测试每个小脚本函数的性能： GetMessage - 基于大小、有附件、无附件、有效消息、无效消息（不存在的消息）进行测试。 GetMessageList - 基于列表大小、现有列表进行测试。 GetMessageAttachment - 基于小型附件、中型附件和大型附件进行测试。 PostMessage - 基于消息大小和附件大小进行测试。 测试在 SQL Server 之间传送的报头的性能。 测试从从属机到主控机再到其它从属机进行发布的性能。

 

辅助说明 4： 进行性能测试时要 查看的计数器 以下是在进行性能测试时应查看的主要 IIS Performance Monitor 计数器： 活动服务器页 -> 每秒请求数。 告诉您服务器当前每秒处理的 ASP 请求数。 活动服务器页 -> 请求排队。 当服务器开始接收超过其处理能力的负载时，会将请求排队。 活动服务器页 -> 请求/被拒绝。 当服务器正在接收的负载超过其处理能力时，请求将被拒绝。 内存 ->可用字节数。 如果该值持续下降，并且任何时刻都不能达到稳定，则可能是发生内存泄露。在高速缓存新页面时，可用内存将被耗尽，但下降速率应在某些时刻达到稳定状态。如果怀疑发生内存泄露，应检查每个进程的专用字节数，看其是否在不断地占用更多的内存。 网络接口 -> 每秒总字节数。 该值可以使您了解您正在使用的带宽。 网络接口 -> 当前带宽。 该值告诉您当前最大的可用带宽。 物理磁盘 ->当前 磁盘队列长度。 如果磁盘是瓶颈，便会发生磁盘访问排队的情形。优化应用程序以使用高速缓存功能会有帮助。 进程 ->专用 字节 ->inetinfo 或 dllhost 或（任何进程）。 注意内存占用量持续增长的进程。该值持续增长表明发生内存泄露。 进程 ->处理器 时间占用率 ->inetinfo 或 dllhost 或（任何进程）。 该值可以显示哪个进程占用处理器的时间最多。有助于找出瓶颈。 进程 ->线程 计数 ->inetinfo 或 dllhost 或（任何进程）。 如果线程太多，系统在进程之间来回切换所占用的时间可能比实际处理有用数据占用的时间多。这种情况被称为环境切换，是线程性能差的标志。 处理器 -> 处理器时间占用率。 在高负荷的情况下，我们认为 75% 的处理器占用率已经接近顶点。如果要在大大高于该值的占用率上运行，那么将没有空间来处理峰值通信量或将来的通信量增长。 系统 ->处理器 队列长度。 该值保持在 3 或 3 以上时，则可说明处理器落后。如果在达到峰值负载之前就开始排队，则应进行优化，或者需要增加处理器功率。 Web 服务 -> 当前连接。 该值显示 Web 服务的当前连接数。 Web 服务 -> 每秒方法请求总数。 该服务告诉您服务器当前每秒钟处理的 HTTP 请求总数。由于一个页面中的所有对象（如图形以及任何独立的脚本或样式表文件）都创建独立的 HTTP 请求，因而一个 HTML 页可能有多个请求。在测试一个单独的页面时，可以用此计数器的总值除以每页的对象数得到每秒的页数。