及早并经常测试

尽可能早地捕获缺陷能够以最小的代价来确保软件质量。 Kent Beck 和 Cynthia Andres 曾写到：“软件开发中有这样一种两难处境：缺陷会带来很大开销，但消除缺陷的开销也很大。 但是，大多数缺陷的成本最终还是要大于预防它们所付出的成本。”(解释的：接受更改) 最优方法和工具可帮助您的团队维护项目的质量将预防和修复缺陷的成本降到在段中。

如果您在开发过程中能够发现缺陷、修复缺陷并验证修复结果，则您的团队随时可以更精确地评估项目的质量。 通过经常进行测试，您的团队和利益干系人可以了解代码的当前状态，并在整个项目中做出合理的决定。 最后，您应能够回答“是否能够发布？”这一问题，并了解这对于软件使用者来说意味着什么。

本主题中推荐了以下做法：

• 为每个类和每个主要组件的 API 创建一组自动单元测试。 编写单元测试所花费的时间约为团队成员工作时间的 40%。 有关更多信息，请参见使用 Microsoft 测试管理器创建自动测试。

• 为每个用户情景创建测试。 这些测试最好是自动测试。 有关更多信息，请参见针对产品积压工作项、用户情景或要求创建测试。

• 创建用于提醒团队成员在签入代码前运行单元测试的签入策略。 有关更多信息，请参见Add Check-in Policies。

• 设置运行整套测试的连续生成或夜间生成。

• 监视测试覆盖率以确保测试所有代码。 目标覆盖率应至少为 70%。 有关更多信息，请参见Excel 格式的“测试缺口”报表 (Agile)。

• 在每个冲刺 (sprint) 临近结束时运行手动测试。

团队可以使用 Microsoft 测试管理器、Visual Studio Application Lifecycle Management (ALM) 和 Visual Studio Team Foundation Server 之间的集成，在项目早期阶段管理和调整这些测试活动。 有关更多信息，请参见测试应用程序。

主题内容

• 测试策略

• 测试规划

• 验收测试

• 单元测试

• 测试驱动的开发和及早测试

• 手动测试和自动测试

• 报告测试结果

测试策略

团队在测试方面的成功取决于多个因素，包括团队的规模、团队的方法和团队的管理工具。 您可以使用敏捷方法持续改进测试结果。 通过应用此方法，您不仅可在资源非常有限的情况下开始测试，还可在整个项目周期内，根据需要调整测试做法。

引入敏捷测试时要考虑的事项

在将敏捷测试引入到现有应用程序中时，团队可以首先考虑冲刺 (sprint) 级别和项目级别的测试策略。 对于冲刺 (sprint) 级别，可以包括一组涵盖当前冲刺 (sprint) 的每个用户情景的验收测试。 在项目级别，可以进行横跨整个项目的测试，如端到端测试。 在需要验证跨两个或更多个冲刺 (sprint) 的功能时，这会非常有用。 当团队在冲刺 (sprint) 过程中生成代码时，您可以创建所有类型的测试。 这些测试包括单元测试、验收测试和非功能性测试（如性能测试、安全测试和可用性测试）。

若要应用敏捷测试方法，您首先应考虑您应用程序的历史记录和团队所使用的系统。 您可将敏捷测试方法应用于新应用程序和现有应用程序。 可以使用 Microsoft 测试管理器为整个项目创建测试计划，并为项目中的每个冲刺 (sprint) 创建测试计划。 通过这些测试计划，团队可以将测试用例组织到测试套件中，这些测试套件可帮助设置运行测试的优先级别，并帮助理解测试结果。 有关更多信息，请参见针对产品积压工作项、用户情景或要求创建测试。 团队可以通过多种方法使用 Visual Studio ALM 将测试用例分成若干个测试套件：

• 创建和管理静态测试用例组。

• 使用查询创建和管理动态测试用例组（也就是说，基于优先级查找测试用例）。

• 向测试计划添加用户情景或要求，测试计划中的测试用例具有指向要求的链接。

• 从其他测试计划复制现有测试套件。

有关更多信息，请参见使用测试套件组织测试用例。

其次，您必须考虑代码的可测试性。 要了解这一点，需要先弄清您应用程序的体系结构和模式。 如果使用诸如模型视图控制器 (MVC)、模型视图查看模型 (MVVM) 或模型视图表示器 (MVP) 等模式，则可以隔离某些功能并运行功能测试，而不会对用户界面测试造成负面影响。 但是，实际情况并不总是这样。 例如，您不能隔离应用程序重构部分的功能，而且某些代码区域只有通过用户界面或网络事件处理程序才能到达。 如果要显著改善测试质量，则必须提高可测试代码的百分比。 有关这些模式的更多信息，请参见 ASP.NET Model View Controller (MVC)。

第三，在实现敏捷测试之前，必须考虑团队的能力。 某些团队成员应能够在您实现功能时创建单元测试。 某些团队成员应能够创建和定义手动用例和工作流测试（如果这些成员熟悉应用程序的业务规则）。 此外，其他团队成员应能够创建基于这些手动测试的自动测试和更详细的测试（如果这些成员具有必要的技能）。

如何管理测试生命周期

测试是贯穿整个项目的一个迭代过程。 请参考以下步骤：

1. 明确测试目标，并确保整个团队同意这些测试目标。 基于这些目标确定测试策略。 例如，您的策略可能是“在每次签入前运行测试，单元测试将具有 70% 的代码覆盖率，且每个用户情景将具有至少一个自动测试。”

2. 根据当前冲刺 (sprint) 中的项目用户情景、设计的假设条件以及非功能要求定义测试计划。

   1. 可以向积压工作添加用户情景，并针对将来的冲刺 (sprint) 对其进行计划。 您应将每个测试计划与至少一个冲刺 (sprint) 匹配，因此，也就应具有适用于相应冲刺 (sprint) 中所有用户情景的测试用例。

3. 定义和生成测试用例，如验收测试、单元测试、功能测试和性能测试。

4. 将测试用例分成若干个测试套件。 您可以将这些测试套件安排到已定义的测试计划中，从而帮助指导测试工作。

5. 在整个冲刺 (sprint) 过程中，反复运行测试套件和包含的测试用例。 在冲刺 (sprint) 中及早开始运行测试，并持续向测试套件添加测试用例。 如果要识别重要的测试条件和情况，则可以应用探索性测试，并在团队内部展开频繁对话。

6. 确保某个用户情景的所有验收测试已通过，然后再将其状态设置为已完成。

虽然根据软件分解情况的不同，工作流可能要复杂得多，但是上图体现了主要组件中的工作流的精髓。

• 代码产生生成。

• 代码受定义的工作、测试计划和生成的质量所影响。

• 测试计划、测试套件和测试用例受计划的目标所影响，并受此图没有显示的其他项目方面所影响。

• 代码中的更改可能会影响测试用例。

修复 Bug

1. 必须尽可能早地处理 Bug。 严重的 Bug 意味着受其影响的用户情景尚未完成。

2. 为通过测试或其他活动找到的 Bug 创建 Bug 工作项。 设置 Bug 的严重级别以指示 Bug 影响用户情景的程度。 较高的严重级别（如 0 或 1）表示，未实现重要的用户情景或用户必须执行大量的解决方法才能实现该情景。 较低的严重级别（如 3）表示，用户仍可以实现其主要目标而无需执行额外工作。

3. 与团队中的其他人员协同工作，针对每个 Bug 确定一个行动计划。

4. 在修复 Bug 后立即解决 Bug。 应指派另一个人来验证 Bug。 尽快验证并关闭 Bug。

5. 跟踪 Bug 的状态。 在每次迭代结束时举行的追溯会议上，查看“Bug 趋势”报表，并讨论导致出现任何 Bug 异常增长的原因。 有关更多信息，请参见“Bug 趋势”报表。

测试规划

测试规划是帮助团队了解项目的大致情况的过程，也是让团队为所有类型的测试做好准备的过程。 敏捷测试在冲刺 (sprint) 级别开始。 在每个冲刺 (sprint) 中，团队将创建测试以验证该冲刺 (sprint) 中生成的用户情景。 团队将运行在当前冲刺 (sprint) 中和上一个冲刺 (sprint) 中创建的测试。 在整个项目过程中，会生成涵盖所有功能的大量测试。 下图显示了项目中测试计划的模板。

为每个冲刺 (sprint) 和项目创建测试计划

使用 Visual Studio ALM 的测试功能，团队可以通过增量方式计划、组织、执行和报告测试。 团队可以为测试计划创建模板，并且团队成员可以填充测试套件。 在测试计划中，团队可以标识应使用自动或手动测试用例的位置。

可以为项目中的每个冲刺 (sprint) 开始创建测试计划。 使用此计划，团队可将精力集中验证当前冲刺 (sprint) 中的功能。 虽然该计划在开始时是空计划，但是您可将其用作测试套件的占位符。 随后可以将测试用例组织到相应的测试套件中。 如果要从项目利益干系人处获取及时反馈，就应及早并在整个冲刺 (sprint) 过程中创建这些测试用例。

也可以创建涵盖整个项目的测试计划。 可以使用项目测试计划来合并来自以前冲刺 (sprint) 的测试，并对应用于整个项目的测试套件进行组织。 应持续运行回归测试套件，因为在团队生成较大项目时保持稳定性和流动非常重要。 尤其是在您与相互距离较远的较大型分布式团队协同工作时，回归测试套件可以捕获因具有级联影响的更改而产生的错误。 如果不采取正确措施，则难以捕获这些错误，可能会在周期中较晚阶段或在发布之后才捕获。

某些团队可能需要定义横跨整个项目的测试计划。 这种测试计划可能会验证多个冲刺 (sprint) 中的相关功能，并且包含在整个项目过程中运行的测试套件。 例如，对于一个涉及跨冲刺 (sprint) 的用户情景的功能，仅当整个功能完成时，您才能对其进行测试。

在冲刺 (sprint) 之前定义验收测试

在冲刺 (sprint) 之前，应定义验收测试。 这些验收测试可帮助您确定用户情景是否已完成。 如果您在每个冲刺 (sprint) 的测试计划中都创建了一个名为“验收测试”的测试套件，则可以跟踪验收测试用例。 有关更多信息，请参见本主题后面的验收测试。

在冲刺 (sprint) 过程中生成单元测试

在冲刺 (sprint) 过程中，团队应生成单元测试。 单元测试可以验证代码性能，如用于执行代码的时间和资源的成本。 其他类型的测试（如非功能性测试，即性能测试和安全测试）应生成并添加到合适的测试套件中。 应对这些测试套件进行组织，以便可以方便地确定其成本。

对使用率较高的区域进行重点测试

了解软件中变化较大之处可确定作用点的可能位置。 用户输入、运行软件的环境、网络和硬件是使团队可以发现软件中作用点的配置变量示例。 如果某个条件很少出现，或者存在可能在测试过程中出现的多个复杂条件，则测试的价值会降低，除非缺陷的潜在影响非常大。 通常，需要尽可能地隔离功能。 有重大影响的测试情况也十分重要。 有关如何使用 Microsoft 测试管理器管理配置的更多信息，请参见测试配置 - 指定测试平台。

对于现有项目，监视具有最大缺陷数的区域，并确定存在缺陷的原因。 还要监视代码改动，因为此区域可能会忽略基础假设。 代码缺陷的某些原因包括难以管理状态（例如网络和用户界面）以及代码。

验收测试

验收测试可验证用户情景。 这些测试不仅可确保您在项目的整个生命周期内成功生成客户需要的内容，而且还会赢得客户的信任，展示您公认的责任心。 有关更多信息，请参见以下网页：Acceptance Test Engineering Guide（验收测试工程指南）。

如何开始使用验收测试

打开 Microsoft 测试管理器，然后在测试计划中创建一个名为“验收测试”的测试套件。 团队应至少使用一个测试套件每个冲刺 (sprint) 分组验收测试。有关更多信息，请参见定义测试计划。

从手动测试迁移到自动测试

虽然手动测试比自动测试更易于定义，但运行开销更大。 因此，一个好的策略就是从手动测试开始，然后逐渐用自动测试替换更重要的手动测试。

首先，开始生成一组手动测试用例，这些测试用例验证为冲刺 (sprint) 定义的每个用户情景。 因为在冲刺 (sprint) 开始时不存在任何代码，所以测试用例应概括映射到用户情景的各个部分的高级操作。 例如，测试用例中的某个步骤可以是“作为已经过身份验证的用户，请…”。团队可以从手动测试用例开始，在冲刺 (sprint) 开始前快速定义理想的验收测试。

其次，当团队具有在冲刺 (sprint) 中实现用户情景的代码时，修改和更新验收测试以反映特定用户体验。 但是，如果团队不想修改现有的验收测试集，则您可以将测试导入到新的测试套件中，并拥有用于更详细测试的起点。 例如，更详细的步骤测试用例可以是“类型名称到用户名"文本框中，然后选择登录"按钮以登录到银行帐户”。

第三，基于验收测试，使用操作录制来创建编码的用户界面 (UI) 测试。 有关更多信息，请参见通过现有操作录制生成编码的 UI 测试。 如果创建隔离功能的步骤，则编码的 UI 测试可以生成更加干净的代码。 如果将编码的 UI 测试附加到手动测试用例，则可以从测试计划运行自动测试（有关更多信息，请参见如何：将自动测试与测试用例关联。）

在冲刺 (sprint) 开始时定义的手动测试可帮助创建自动测试。 手动测试和自动测试都有成本，因为手动测试需要由人员来运行，而自动测试在代码或用户体验更改时需要进行更新。 有关更多信息，请参见本主题后面的手动测试和自动测试。

谁来运行验收测试用例？

团队、产品所有者和客户都可以运行验收测试用例。 团队应尽可能频繁地运行测试用例，以便为需要在冲刺 (sprint) 中通过的测试集提供基线。 产品所有者和客户也可以运行验收测试，并且可能需要进行验证以成功完成冲刺 (sprint)。

团队可以使用 Microsoft 测试管理器来运行每个验收测试用例，并记录测试结果的屏幕捕获。 通过这种方式，您就可以获得测试结果的可视记录，还可以将结果与客户共享。 这在难以创建所需的配置（如多服务器配置）时很有用。

定义验收测试用例与用户情景

在定义了用户情景之后，就可以定义验收条件。 通过定义验收测试，可以帮助团队从产品所有者和客户的角度了解当前冲刺 (sprint) 的验收条件。 因为客户需要同意验收测试，所以最好在冲刺 (sprint) 开始之前创建验收测试用例。

单元测试

单元测试是自动测试，用于验证组件级别、类级别、方法级别或属性级别的功能。 单元测试是自动测试和回归测试的基础，可提供项目的长期稳定性和未来可维护性。

单元测试如何帮助发展应用程序的设计？

生成进行测试的代码时创建单元测试的过程可帮助定义代码的形状。 可以创建可使用单元测试进行测试的代码。 如果为代码创建单元测试时存在困难，则表明应对代码进行重构。

如何组织单元测试？

每个编写代码的团队成员都应为所生成的组件创建单元测试，并将单元测试代码签入到 Visual Studio 项目内的版本控制中。 将测试用例工作项归档到在每次生成过程中通过持续集成而运行的版本测试验证套件中，并归档到验证对应用户情景的测试套件中。

如何在不必更改测试代码的情况下管理单元测试的变体？

测试输入中的变体定义测试之间的相似或差异，因为它将验证项目代码中的功能。 例如，在测试 Web 应用程序的登录组件时，您可以提供多种类型的密码以创建用户帐户。 系统对于所使用的字符类型的顺序与组合，可能具有相应规则。

Visual Studio 专业测试工具版提供了用于编写数据驱动的单元提供功能测试和编码的 UI 测试。 有关更多信息，请参见如何：创建数据驱动的单元测试和如何：创建数据驱动的编码的 UI 测试。

测试驱动的开发和及早测试

测试驱动的开发 (TDD) 是一种设计与编程原理，其中的每行代码都是为响应程序员在编码之前刚刚编写的测试而编写的。 成为要实现的代码的使用方这一想法非常有效，可以对应如何使用和设计代码保持真实预期。

在 TDD 中，开发人员执行很多小的增量任务。 开发每个小的增量任务需要花费几分钟到几小时的时间。 通常，很多此类增量任务构成了一个用户情景。 当用户情景工作时，开发人员将签入测试和代码。 开发人员按以下循环方式进行工作：

1. 在编写增量任务时编写一个应通过的自动测试。

2. 验证新的测试是否会失败以确保该测试可正常工作。

3. 编写将使该测试通过的代码。

4. 运行该测试以验证它是否成功。

5. 此外，运行同一区域中的所有其他测试以确保未引入任何 Bug。

6. 如有必要，重构代码以改进其结构，而不添加行为。 重新运行测试以确保代码仍可正常工作。

7. 重复所有这些步骤，直到实现完整用户情景。 随着将前面的增量任务集成到完整情景中，应添加用于验证整个情景的测试。

8. 签入实现代码和单元测试。

如果您对及早测试方法的优点感兴趣，则可以先从创建手动（或手动验收）测试开始。 可以通过创建编码的 UI 测试来实现这些手动测试的自动化。 （有关更多信息，请参见如何：通过录制受测应用程序来生成编码的 UI 测试。）还可以创建使用 Visual Studio ALM 中的单元测试框架的集成测试，以验证是否正在实现功能。 在迭代中早期创建的测试用例组会在迭代早期运行，以尝试验证功能和查找 Bug。 这些测试套件和测试用例可在项目的整个生命周期内作为回归测试持续运行。 通过持续运行这些测试，可帮助确保所发现的 Bug 以及在迭代早期验证的功能不受项目后期的更改影响。

为持续集成使用单元测试

使用及早测试做法时创建的单元测试应在用于当前冲刺 (sprint) 和用户情景的测试套件内进行组织。 这些单元测试可以提升到项目范围的测试计划，并由团队定期运行或在持续集成周期内运行。 单元测试还可作为集成测试、负载测试和性能测试的基础。

在开始时创建的单元测试可用作持续集成的一部分。 有关如何在生成过程中运行测试的更多信息，请参见 TestToolsTask Task。

使用虚拟化来管理测试配置

若要运行单元测试，您可以创建位于 Microsoft 测试管理器托管 hyper-v 映像的设置环境。使用 Microsoft 测试管理器，有关如何运行测试的更多信息自动从测试计划，请参见 如何：使用 Microsoft 测试管理器在实验室环境中运行自动测试。

手动测试和自动测试

自动和手动测试用例是互补的。 敏捷团队致力于拥有更多的自动测试用例，因为可促进频繁或持续的测试运行。 若要持续运行测试，测试必须快速频繁地执行，这对于手动测试比较困难。

在确定手动和自动测试用例的分配时，有几个注意事项。

组织中的技能如何影响测试类型的分配？

产品所有者可帮助定义项目的用户情景，并且还应参与验收测试的创建。 产品所有者可能不会生成编码的测试，但是拥有业务领域的大量知识。 因此，由产品所有者定义的测试用例会处于业务术语和业务规则级别。 例如，一家运输公司中的产品所有者将指定业务所支持的不同运输方法（如卡车、火车、空运、海运或联合运输）。 随后，产品所有者可以定义体验不同可能的多种测试用例。 对于这些手动测试，务必要指定体验不同选项（在此例中为运输方法）的最小测试数。

生成代码的团队成员可以生成编码的 UI 测试，这些测试可以基于手动测试，或独立于任何其他测试。 有关更多信息，请参见How to: Generate a Coded UI Test by Recording the Application Under Test。 编码的 UI 测试必须获得能够管理和开发项目代码的团队成员的支持。

何时应将手动测试转换为自动测试或从一开始就创建自动测试？

在您期望反复运行测试以保持代码的稳定性时，可以生成自动测试。 因为在自动化方面的投入会影响团队的资源，所以考虑创建自动测试的工作量很重要。 在代码改动很少时创建自动测试会带来较高投资回报 (ROI)，因为测试改动较少。 但是，及早创建自动化也有其价值，因为这可帮助发现逻辑和设计上的问题。 在这两种情况下，需要考虑支持自动测试代码所需的资源。

在决定必须自动完成一组测试之后，请尽快完成自动化工作，因为自动化的优点包括管理代码的稳定性。 稳定性以及编写自动化时发现的缺陷数将影响完成自动化所需的工作量。 最后，手动测试与自动测试之间的平衡与需要在项目生命周期内生成并运行的测试类型的优先级别有关。

自动进行何种类型的测试？

单元测试

单元测试可通过代码或某个过程（如 TDD）来验证功能。 单元测试非常重要，因为这些测试可帮助保持代码内的稳定性和依赖关系。 TDD 往往还生成具有依赖项和良好层定义的更佳设计，因为它可帮助您从代码使用方的角度来理解设计。

负载测试

可以创建基于现有自动测试用例的负载测试，也可以创建针对应用程序或服务生成特定类型的负载的测试。 有关如何使用测试代理控制器和测试代理来生成模拟测试负载的更多信息，请参见如何：使用测试控制器和测试代理运行测试。

有关如何使用 Visual Studio ALM 进行负载测试的更多信息，请参见 Microsoft 网站上的以下页面：Understanding Load Tests（了解负载测试）。

持续集成测试

可以使用与 Visual Studio ALM 的持续集成，以帮助确保无论何时开发和签入代码，该代码都会与现有代码一起正常工作。 随着团队的扩大和基本代码的增加，持续集成变得至关重要。 可以定义一个包含测试参数的生成类型，并指定在完成生成之后要运行哪些测试。 有关如何对运行测试的生成进行定义的更多信息，请参见定义基于默认模板的生成过程。

可以自动进行何种类型的测试？

配置测试

对多个已安装的环境进行测试是一项非常艰苦的任务。 Microsoft 测试管理器提供了使用虚拟机或物理计算机针对不同配置运行测试套件的功能。 有关如何在多个环境中运行测试并收集数据的更多信息，请参见设置测试计算机以运行测试或收集数据。

用户界面测试

Visual Studio ALM 提供了直接为用户界面创建自动测试的功能。 有关如何创建编码的用户界面测试的更多信息，请参见如何：创建编码的 UI 测试。

安装测试

可以使用 Microsoft 测试管理器的实验室功能来设置一组配置，您可以使用这些配置来验证应用程序的安装程序是否按预期方式工作。

自动化的屏障是什么？

团队的能力

创建自动化需要测试团队的一部分成员学习如何编写代码。 进行计划以形成创建自动化的学习曲线以及测试代码的设计。 与生产代码相似，针对所需目标（如可维护性、易于撰写和长期性）设计自动化代码。

有关如何创建自动测试的更多信息使用 Visual Studio 专业测试工具版，请参见 使用 Microsoft 测试管理器创建自动测试。

代码改动

频繁更改的代码是移动目标，会对测试自动化代码产生级联影响，因为也需要对该代码进行更改。 请通过为不太可能更改的组件和界面创建测试自动化代码，来避免这些级联影响。

代码设计

代码框架（如 ASP.NET MVC 和 MVVM）可指导团队成员编写具有验证不同代码部分所需的隔离的代码。 与用户界面紧密绑定的代码很难测试，因为这些代码可能需要用户与用户界面控件交互。

手动测试用例有何优点？

手动测试用例具有以下优点：

• 手动测试可帮助团队通过探索过程来查找 Bug。

• 手动测试用例容易定义，因为可以采用任何抽象程度来定义一组步骤，并使用喜好的任何术语来定义成功和失败。

• 在编写任何代码之前，在项目早期阶段开始编写手动测试用例非常容易。 这在定义验收测试的过程中非常重要。

• 如果使用 Visual Studio 专业测试工具版，则测试用例可由共享步骤组成，帮助节省时间，当定义相似测试，并允许团队重用的测试子集的一个版本。 使用共享步骤还可在更改测试用例时提供帮助，因为对共享步骤进行的更改会自动更改使用共享步骤的所有测试用例。 有关如何创建和使用共享步骤的更多信息，请参见How to: Share Common Test Case Steps Using Shared Steps。

• 手动测试用例可在项目或冲刺 (sprint) 用作早期的通信方式。

• 手动测试用例可用作记录自动测试用例的方法，而无需任何人检查代码。

• 如果使用 Visual Studio ALM，则运行手动测试可以收集代码覆盖率指标。

手动测试用例有何缺点？

手动测试用例具有以下缺点：

• 定义成功标准可能比较复杂，因为这取决于在测试定义中采用的角度和语言。 某种语言可通过不同方式进行解释，这便可能会出错。

• 运行包含手动测试用例的测试套件要求人员实际跟踪测试步骤并报告结果。 此过程可能会消耗大量时间，因此，可能需要增加执行测试的团队成员数，或增加运行测试套件的时间。 使用 Visual Studio test professional，团队可以使用“快进手动测试”，在测试过程中，哪些操作会记录，可在将来的测试运行再运行。

• 根据代码稳定性的不同，运行测试所需的时间和工作量也将不同。 因此，运行手动测试可能会影响团队中的流动。

• 最大的缺点是，手动测试容易在检测 Bug 时出现人为错误。 Bug 可能近在眼前，但是测试人员却无法识别。

自动测试用例有何优点？

自动测试用例具有以下优点：

• 自动测试可帮助保持稳定性，并帮助发现因代码更改而可能发生的回归。

• 自动测试可在无人参与的情况下运行。

• 自动测试是软件，可以进行设计，并由其他可重用的代码组成。 这使得自动测试灵活且可维护。

• 自动测试可使用 Microsoft 测试管理器在多种配置上运行。

• 在自动测试运行时，可以收集代码覆盖率指标。

自动测试用例有何缺点？

自动测试用例具有以下缺点：

• 需要考虑特殊条件并使用代码进行实现。 在创建和运行自动测试时，随着其他条件的发现，会实现这些条件。

• 在更改或重构代码后，可能会存在级联影响，需要进行相应工作来更改受影响的自动测试。

• 当代码更改导致很多测试失败时，可能会对团队产生心理影响。 如果这些测试用作标志，则团队可能不想引发任何标志。

• 当在没有针对正确条件测试测试用例的情况下，所有测试都通过时，可能会有一种虚假的安全感。 请务必维护测试套件，并确保它们验证正确的条件和结果。

报告测试结果

从敏捷的角度来看，基于 Bug 和聚合指标针对当前质量状态报告和查询 Team Foundation Server 是反馈循环的一部分，这允许团队对代码、项目计划和测试计划进行的迭代和更改。 有关更多信息，请参见“测试计划进度”报表。

还可以监视进度测试计划使用 Microsoft 测试管理器的功能的测试计划结果。 测试计划的结果包含图表，并为传递的数字统计信息，失败并激活测试。 此外，测试计划结果中显示失败类型和解决数据的详细图。 测试计划的结果进行筛选包括或排除特定测试计划的测试套件。 还可以查看各个测试人员的结果在测试团队。 有关更多信息，请参见如何：在 Microsoft 测试管理器中查看测试计划结果。

应向团队报告哪些测试级别？

使用 Visual Studio test professional 和 Team Foundation Server，团队可以了解计划和执行测试的状态。 Team Foundation Server 将存储测试计划、测试套件、测试用例、测试结果以及在整个测试过程中生成的所有其他关联数据。 如果要合并 Microsoft 测试管理器 与、报表和工作项查询在 Team Foundation Server，您可直观测试和质量控制过程。可以使用 Microsoft 测试管理器 为多种不同状态的 bug 查询。 已由其他团队成员标记为已修复的 Bug 应处于已解决状态。 可使用后续生成来验证已修复的 Bug。 有关如何验证 Bug 是否已修复的信息，请参见如何：使用 Microsoft 测试管理器验证 Bug 是否已修复。