使用 Visual Studio 2010 进行软件测试
0/5 (0投票)
规划测试的章节摘录。
|
|
Jeff Levinson 由 Addison-Wesley Professional 出版 ISBN-10: 0-321-73448-3 ISBN-13: 978-0-321-73448-8 |
首先，你需要一个计划。这个计划不需要是500页的文档或庞大的甘特图。本章将介绍如何使用 Microsoft Test Manager (MTM) 创建测试计划以及测试计划提供的各种选项。更重要的是，本章将介绍要测试什么以及测试人员如何尽早参与到开发过程中。此外，Microsoft 提供了一个鲜为人知的测试计划 Word 模板，可以帮助解答一些关于测试过程初期的问题。
这里涵盖的另一个关键项是如何计划和测试多个迭代。你可以重用你的测试用例吗？这样做有意义吗？在计划整个发布版的测试与计划单个迭代的测试时，有很多因素需要考虑。在本章结束时，你将了解如何使用 MTM 的“计划”选项卡，创建新计划，并为测试人员在给定时间内工作创建一个框架。
如第一章“测试现状”所述，测试人员理想情况下应在需求收集过程中参与。在瀑布周期中，这发生在分析阶段。在敏捷周期中，这是业务分析师或产品负责人填写产品待办事项列表项的详细信息，但在此之前将该项引入迭代待办事项列表的这段时间。本章将介绍测试人员的职责以及他们可以采取哪些措施来帮助减少引入到
软件的潜在错误。
测试方法
在开始任何测试工作时，你需要一种测试方法。考虑什么可以接受，什么可以发布，如何执行每种类型的测试，以及形成方法框架的其他信息。如果你使用 MSF for Agile v5.0 进程模板，则在 SharePoint 网站的示例文档中有一个测试方法 Word 模板。（文档路径为 Documents/Samples/
Templates/Test/Document Template - Test Approach.dotx。）你还可以找到一个显示填写完成的测试方法的示例文档。
Microsoft Test Manager
Microsoft 为测试人员提供了一个单独的工具：Microsoft Test Manager (MTM)，你可以在其中创建测试计划，添加和更新测试用例，并从该工具执行手动和自动化测试。在深入介绍创建测试计划的细节之前，你需要了解如何在 MTM 中进行导航。图 3-1 显示了导航控件。
MTM 组织为中心 (Centers)、选项卡 (Tabs) 和页面 (Pages)，如图 3-2 所示。
表 3-1 简要描述了每个部分。这些页面及其启用的选项将在本书中进行介绍。
表 3-1：MTM 页面描述
| 中心 | 选项卡 | 页面 | 描述 |
| 测试 | 计划 | 目录 | 包含给定测试计划的设置，包括手动和自动化测试设置、测试配置以及正在使用的生成。 |
| 属性 | 包含要为选定计划测试的套件和测试用例。 | ||
| 测试 | 运行测试 | 执行测试运行的主页。 | |
| 验证 Bug | 包含已修复的 Bug，测试人员可以快速访问并进行验证。 | ||
| 分析测试运行 | 显示所有测试运行（手动和自动化），但主要用于查看自动化测试运行并根据测试运行的结果采取适当的措施。 | ||
| 跟踪 | 查询 | 与 Team Explorer 中的相同；它允许你执行已保存的工作项查询或创建新查询。 | |
| 分配生成 | 允许测试人员将自动化生成分配给测试计划。 | ||
| 推荐测试 | 显示由于代码更改而受影响的所有测试的列表。 | ||
| 项目门户 | 提供指向项目门户的快速链接（在 Web 浏览器中打开）。 | ||
| 组织 | 测试计划管理器 | 列出当前团队项目中的所有测试计划。 | |
| 测试配置管理器 | 列出所有测试配置。 | ||
| 测试用例管理器 | 列出当前团队项目中的所有测试用例。 | ||
| 步骤管理器 | 列出当前团队项目中的所有共享步骤（可重用测试步骤）。 | ||
| 实验室 | 实验室 | 环境 | 包含为测试目的准备好的所有物理和虚拟环境。 |
| 测试设置 | 测试设置管理器 | 包含所有手动和自动化测试设置。 | |
| 库 | 环境 | 列出所有已准备好用于测试的环境，包括已部署的环境。 | |
| 虚拟机和模板 | 包含可用于组合成测试环境的所有虚拟机。 | ||
| 控制器 | 测试控制器管理器 | 包含所有测试控制器和与这些控制器相关联的所有代理的列表。 | |
| 与工具相关的工作项 | 文档 | 测试计划摘要 | 生成包含所选测试计划、相关测试套件、测试用例、测试步骤和相关工作项的文档。 |
| 测试运行摘要 | 生成包含所选测试运行结果的文档。 |
Test Scribe 和工具中心
安装 MTM 时，工具中心不存在。在 Visual Studio 2010 发布后，Microsoft 发布了一个 Test Scribe 工具（可在 http://visualstudiogallery.msdn.microsoft.com/en-us/e79e4a0f-f670-47c2-9b8a-3b6f664bf4ae. 找到）（或者你可以搜索“Test Scribe Visual Studio Gallery”，该链接会是第一个）。
此附加组件对大多数组织至关重要，应在安装 MTM 后立即安装。它生成的文档可以提供给用户或外部测试人员，作为一份优秀的详细文档，展示测试和测试运行。
当你第一次启动 MTM 时，系统会要求你连接到服务器（图 3-3），选择一个团队项目（图 3-4），然后选择一个测试计划（图 3-5）。
注意图 3-5 中的“复制 URL”选项。MTM 允许你提供特定计划的 URL，因此你可以将 URL 发送给某人，他们可以点击该 URL，MTM 将打开到正确的计划。此对话框仅显示活动的计划。你可以从“测试中心”、“组织”选项卡、“测试计划管理器”页面查看所有计划（活动和已关闭）。
MTM 允许你一次在一个团队项目中和一个计划中工作，尽管你可以根据需要更改计划和项目。第一次执行此操作后，MTM 会记住你上次的选择，因此 MTM 可以打开到上次选择的计划。
在开始练习之前，请参阅本书开头的“关于本书使用的应用程序”部分。这些练习假设你已按照该部分中的步骤进行操作。
测试计划
在使用测试工具之前，你需要了解所有各种工件如何组合在一起，因为这在你开始管理实际项目时很重要。图 3-6 显示了工件的容器视图。
图 3-6 显示，MTM 中的测试计划与特定的团队项目相关联。测试计划由一个或多个测试套件组成，每个测试套件由一个或多个测试用例组成。这是一个简单的结构，可以实现灵活的报告和轻松的测试计划管理。
练习 3-1
创建新的测试计划
此步骤假设你以前未使用过 MTM。如果你使用过，但想完成此练习，则需要选择屏幕左上角的“主页”按钮，然后选择“更改项目”。
- 打开 MTM。
- 选择“添加服务器”，或者如果列出了正确的服务器，请选择现有服务器。
- 选择 BlogEngine.NET 项目，然后单击“立即连接”。
- 在“测试中心”屏幕上，单击“添加”以创建新的测试计划。
- 输入名称为“Iteration 1”，然后单击“添加”。
- 突出显示计划，然后单击“选择计划”。
图 3-7 显示了 Iteration 1 测试计划。
属性
测试计划具有名称和描述。如果你同时使用多个测试计划，你需要给它们一个描述性的名称以及更详细的描述。所有者通常是测试经理，但也可能是测试主管，如果主管负责计划内发生的测试。状态可以是“活动”或“非活动”，取决于它当前是否正在使用，并且此状态不可自定义。非活动的测试计划可以是之前已完成的测试计划，也可以是尚未开始且仍在创建中的测试计划。新测试计划的默认状态为“活动”，但如果计划仍在设计中，你可能希望将其设置为“非活动”。
区域和迭代是标准的工作项分类方案。通常，测试计划应以某种方式与迭代相关（或开发团队用于生产软件的任何方案），因为测试遵循需求或代码，这些是任何方法论中都存在的不同阶段，无论它们是否被明确提及。
测试计划不是工作项，如需求、用户故事或任务。它们独立于工作项系统。这既是优点也是缺点。优点在于灵活性：测试计划包含比工作项更多的信息，并且更具动态性。另一方面，诸如开始日期和结束日期之类的项无法通过简单机制进行报告。你需要使用数据仓库（请参阅第 9 章，“报告和度量”）来报告测试计划。
运行设置
运行设置定义测试的执行位置以及实现的诊断数据适配器。图 3-7 显示了运行设置的两个类别：手动和自动化。手动运行设置与使用测试运行程序执行的任何测试相关（参见第 4 章，“执行手动测试”）。自动化运行设置与通过 MTM 执行任何自动化测试相关（参见第 6 章，“自动化测试用例”）。
立即更改测试设置
当测试设置设置为
要创建新的运行设置，请转到“实验室”中心、“测试设置”选项卡、“测试设置管理器”页面，然后复制现有设置或添加新设置。然后可以在“测试计划属性”页面中分配这些设置。图 3-8 显示了测试设置创建屏幕。
根据你创建的是自动化设置还是手动设置，选项会略有不同。图 3-8 显示了“数据和诊断”选项卡上的手动测试设置，其中包含诊断数据适配器。表 3-2 列出了你可以选择的默认诊断数据适配器。
| 收集器 | 描述 |
| 操作记录和操作日志 | 记录测试人员在手动测试运行期间在应用程序中执行的每个步骤。 |
| 除了此收集器外，还有 IntelliTrace 和测试影响收集器的 ASP.NET 客户端代理。 | 允许你在运行 ASP.NET 应用程序的测试期间捕获 IntelliTrace 和测试影响信息。注意：此设置实际上并不执行捕获；你必须除了此收集器外，还选中 IntelliTrace 和/或测试影响收集器。 |
| 事件日志 | 捕获测试运行期间写入事件日志的选定事件。 |
| IntelliTrace | 启用捕获调试日志。 |
| 网络仿真 | 根据指定设置限制网络性能。 |
| 系统信息 | 捕获测试执行系统上的系统配置信息。 |
| 测试影响 | 记录测试影响信息，用于计算受代码修改影响的测试用例。 |
| 视频记录器 | 记录测试运行期间屏幕上所有操作的视频。 |
诊断数据适配器使测试基础结构能够收集数据——任何你想要收集的特定数据。它们是完全可扩展的，易于创建和修改（字面意思是 20 行代码加上收集数据所需的任何代码）。
生成
如果你目前没有使用自动化生成，那么你应该使用。自动化生成是减少查找和修复 Bug 所需时间的最有效方法之一。这些自动化生成可以是持续集成生成（在签入时立即运行生成以确定签入是否破坏了任何内容的过程）或夜间生成，并且它们可以更快地发现生成中断，并且需要审查的代码行更少。它们对于手动测试也至关重要；虽然不是自动化测试所必需的，但它们肯定会使事情更容易。
生成使你能够指定要执行测试的生成。在选择要针对其执行测试用例的生成后，MTM 会为你提供与生成相关的信息。自动化生成有助于显示测试影响分析结果，并为测试团队提供自上次使用的生成以来代码中所有更改的列表。
生成过滤器使你能够按生成定义和生成质量进行过滤。第 5 章，“解决 Bug”，将讨论生成质量。
配置
一方面，配置在测试执行中起着重要作用；另一方面，它们只提供元数据。配置允许你指定测试用例中执行的各种信息。它们还会对你需要执行的测试数量以及如何计划测试套件产生实质性影响。例如，MTM 中的默认设置为 Windows 7 和 IE 8。如果你有一个包含 20 个测试用例的测试套件，你需要执行 20 个测试用例。对于添加到套件的每个配置，所有测试都需要针对其他配置进行执行。（默认情况下，但你可以更改此设置。）因此，如果你有三个需要测试的配置，你需要运行 60 个测试。配置对测试和报告的影响在本章后面的“分配测试配置”部分中进行了讨论。
显然，你不需要执行任何你不希望执行的测试用例，而且在许多情况下，由于可用时间，你无法执行所有测试用例。
“测试配置”部分涵盖了测试配置的详细信息。
测试计划状态
本节提供当前测试计划的状态。第一个饼图列出了成功测试、失败测试和尚未执行的测试的总数。按类型划分的失败饼图细分了每个失败的类别。表 3-3 显示了可用的类别。
| 类别 | 描述 |
| 无 | 如果测试失败不是问题，则使用此选项。 |
| 回归 | 之前的测试结果表明通过。 |
| 新问题 | 以前从未见过。 |
| 已知问题 | 可能是因为之前的运行发现了此 Bug，或者开发团队已通知测试团队生成已准备好进行测试，但他们知道此特定失败。 |
| 未知 | 发生了一个错误，但测试人员不确定该问题的分类。测试主管或经理应进一步检查未知问题。 |
你也可以在修复之前或之后为失败类型提供类别，但应在缺陷修复之前将其留空。表 3-4 列出了分析类别。
| 类别 | 描述 |
| 无 | 目前无解决方案。 |
| 需要调查 | 测试团队已决定进行进一步调查，因为它不确定原因。 |
| 测试问题 | 通常在测试用例有问题或测试设置不正确时设置。这可能引起担忧，因为如果测试用例错误，其基础需求也可能存在潜在的不准确性，需要进行调查。 |
| 产品问题 | 代码中发生了有效失败。 |
| 配置问题 | 通常是配置文件或测试部署所在机器出现故障。 |
故障和解决方案可扩展性
你可以通过进程模板或对象模型自定义解决方案类型；但是，你无法自定义故障类型。（通过编辑进程模板似乎可以做到，但由于技术原因实际上不起作用。）
这些图表会随着对测试计划的更改以及测试运行的完成和分析而更新。（出于性能原因，你可能需要单击“刷新”按钮才能看到最新数据。）这是一个很好的视图，可以快速让测试团队了解其在给定计划中的测试进度（如图 3-7 底部所示）。
目录
测试计划的“内容”部分包含有关将要测试的内容的信息；也就是说，它包含所有测试用例的列表，这些测试用例已分解为测试套件。图 3-9 显示了“计划”选项卡的“内容”页面。
有关项目之间关系的参考图 3-3。测试套件可以通过三种方式组成：基于需求的、基于查询的或使用静态套件自定义的，并且这三种都有很好的用途。测试套件的类型通过套件名称旁边的图标来区分（参见图 3-10）。
基于需求的套件
对于大多数开发业务线应用程序的团队来说，整个应用程序都围绕完成需求而构建；因此，测试人员应根据开发人员完成的需求进行测试是有意义的。换句话说，测试人员很少能对未完成的需求进行测试。他们也不能对应用程序的随机部分进行测试，因为通常情况下，功能和集成测试依赖于完整的功能。即使是边界测试也必须在需求的上下文中进行。
而且，客户大部分时间都想知道其需求的状态。它们是否接近完成？它们是否通过了测试？给定的需求有多少 Bug？无论使用哪种方法论，情况都是如此。按需求分组套件可以非常轻松地将此信息报告给客户。
要创建基于需求的套件，只需选择一个静态套件（根节点或其他静态套件）并单击“添加需求”；然后选择一个或多个需求。每个需求都成为自己的套件。已与该需求关联的任何测试用例都会自动添加到套件中。
需求和工作项类型
无论你使用的是 MSF for Agile 还是 CMMI 模板，都有一个需求工作项类型。对于 CMMI 模板，它是“Requirement”，对于 Agile 模板，它是“User Story”。从基于需求的套件的角度来看，决定需求的是它所属的类别。类别是 TFS 2010 新增的，并且是工作项类型的分类方案。MTM 操作于需求、测试用例和 Bug 类别。它操作于类别的原因是你可能创建一个自定义工作项类型，例如称为“Use Case”，如果它在需求类别中，它也会出现在 MTM 中。此外，你可能创建一个“Defect”工作项类型，该类型在提交 Bug 时生成。
基于查询的套件
这些是基于工作项查询结果创建的套件。你可能想要创建此类套件的一个示例是需要测试应用程序的特定区域，该区域可能涉及不同的功能。使用基于需求的套件，你无法做到这一点。此类套件的另一个原因是需要测试所有 Bug 修复，无论它们与哪个需求相关。基于查询的套件仅提供了更多灵活性，可以选择要测试的内容，并且允许你同时从多个团队项目或需求运行测试用例。
创建此类套件时，你仅限于查询结果，并且查询指定你只能查询“测试用例”类别中的工作项。因此，基于查询的套件特定于测试用例。由于此类套件基于查询结果，因此如果该查询的结果发生变化，你的测试套件也会发生变化。将此套件用于短期套件或你不介意其发生更改的套件。一个有效的示例是自动化回归测试。你可以创建一个查询，其中 Automation Status = Yes；当你执行套件时，所有自动化测试都会执行。
静态套件
静态套件是完全自定义的套件；你提供套件的标题，然后根据需要添加测试用例。静态套件的一个优点是可以嵌套套件。这对于其他两种套件类型是不可能的。使用此类型套件的原因可能有所不同；但是，一个示例可能包括最终应用程序测试，此时你可能只有时间测试来自各个区域和迭代的需求，并且你想将它们分解为子套件，以便你可以汇总结果。在 MTM 中，当你选择“新建”下拉列表以添加新套件时，你看到的唯一两个选项是“套件”和“基于查询的套件”。“套件”选项是静态套件。
将套件和测试用例添加到你的计划
使用“内容”窗口的机制非常直接，但提供了许多选项来帮助你控制测试人员开始测试时发生的情况。测试套件列表在左侧。图 3-6 显示了一系列测试套件，从根测试套件开始，该套件始终是测试计划的名称（此处为 Iteration 1）。根测试套件是静态套件，因此你可以直接将测试用例添加到根。带有红色复选标记的图标是基于需求的套件。另一种区分方式是查看右窗格中的测试用例列表上方；你可以单击“Requirement 1”链接以打开这些测试用例相关的需求。
图 3-6 中的“自动化回归测试套件”是一个基于查询的套件，你可以通过查看图标来识别。列表中最后一个套件“Custom”是一个静态套件，其中包含一个“Future Work”子套件，可让你轻松组合和管理测试套件。
你可以在此处更改所有测试用例的默认配置，或者仅更改单个测试的配置。（不建议这样做，因为很难跟踪哪个测试应该在哪个配置上运行。）你可以更改测试用例的分配对象——可以通过选择一个测试用例并单击“分配”按钮单独分配，或者通过右键单击左侧的测试套件并选择“为所有测试分配测试人员”（或任何测试人员到测试用例的组合）。
另外，请注意右上角显示“状态：进行中”。你可以将状态设置为三种状态之一：“计划中”、“进行中”或“已完成”。“进行中”是默认状态，对于“进行中”的测试套件中的测试可以执行。“计划中”的测试套件不会显示在“测试”选项卡上，因此无法执行这些测试。对于“已完成”的套件也是如此。
你还可以通过右键单击列标题来更改显示的测试用例列。你可以过滤某些列（任何具有离散列表的列）以限制显示内容。（例如，你可以过滤默认列列表中的“优先级”列。）
最后，你可以选择打开已添加到套件中的测试用例，添加套件中已存在的测试用例，或在 MTM 中创建新测试用例。任何创建或添加的测试用例都会自动与需求（或用户故事）链接，如果该套件是基于需求的套件并且链接类型为“Tested By”。反之亦然；如果你从基于需求的套件中移除一个测试用例，该测试用例将不再与该需求相关联。（“Tests/Tested By”链接将被删除，但测试用例本身不会被删除。）
练习 3-2
创建测试套件
此练习假设你已完成练习 3-1。
- 打开 MTM（如果尚未打开）。
- 选择“测试中心”、“测试计划”、“内容”选项卡。
- 选择 Iteration 1 套件，这是根套件，也是目前唯一存在的套件。
- 单击套件名称工具栏上的“添加需求”。
- 在“将现有需求添加到此计划”页面上，单击“运行”（参见图 3-11）。
- 选择“作为博客作者，我希望能够登录博客引擎”的需求，然后在右下角单击“将需求添加到计划”。
测试配置
测试配置是可配置的，并且可能影响需要执行的测试数量（前面已提到）。测试配置指定了确保你的软件针对用户机器上可能拥有的所有可能配置选项进行测试所需的任何特定信息。
在此版本中，测试配置严格是元数据。也就是说，它们不对测试运行产生任何影响，也不能用于指定实际执行测试的硬件或软件。
最典型的例子是使用不同的浏览器来确保渲染正确。在此基础上，可能还有这些浏览器运行的操作系统。两个默认的配置选项是“操作系统”和“浏览器”；除此之外，你还可以添加其他内容，例如 Silverlight 版本或特定硬件，例如网络摄像头。
使用测试配置的最大好处是报告结果。你所有的测试结果都可以按配置细分。此外，你只需要编写一次测试用例，但这带来了其他问题，例如在一个配置上执行的操作可能在另一个配置上无效。在某些情况下，差异可能如此之大，以至于使用相同的测试用例没有意义。在决定如何使用测试配置时，请考虑这些因素。
管理测试配置
你可以通过两种方式访问测试配置管理器。第一种方式是转到“测试中心”、“计划”、“属性”并选择配置旁边的下拉箭头；然后单击“管理”。更简单的方法是转到“测试中心”、“组织”、“测试配置管理器”。这将显示如图 3-12 所示的屏幕。
“管理配置变量”选项允许你创建新的配置类别。你也可以为现有配置变量添加新值。
练习 3-3
添加新的配置变量
要添加新的配置变量，请按照以下步骤操作：
- 单击“管理配置变量”。
- 单击“新配置变量”。
- 输入“Silverlight Version”作为名称。
- 输入“默认 Silverlight 版本”作为描述。
- 在“允许的值”中，输入以下内容（如图 3-13 所示）：1、2、3 和 4。
- 单击“保存配置变量”。
变量本身不能直接使用。你需要创建一个由一个或多个配置变量组成的实际配置。
练习 3-4
创建新的测试配置
要创建新的测试配置，请按照以下步骤操作：
- 在“测试配置管理器”中单击“新建”。
- 输入名称为“Vista, IE7, and Silverlight 2”。
- （可选）输入适当的描述。
- 选择“添加”按钮，并注意你可以从三个现有类别中添加配置变量。在给定的配置中，你只能从每个类别中添加一个变量。
- 单击“操作系统”，然后选择“Vista”作为值。
- 单击“添加”、“浏览器”，然后选择“Internet Explorer 7.0”作为值。
- 单击“添加”、“Silverlight 版本”，然后选择“2”作为值。
- 单击“保存并关闭”。
现在你有一个新的测试配置可以分配给计划。你也可以删除未使用的测试配置或之前未被测试计划使用的测试配置。如果你尝试删除正在使用的测试配置，系统会提示你将其设置为“非活动”而不是删除。
分配测试配置
要将配置分配给测试用例，你有几个选项。第一个是转到计划的“属性”页面并更改配置。这可以立即将更改应用于计划中包含的所有测试用例以及以后添加到计划中的任何测试用例。下一个选项是更改“计划内容”选项卡上的默认配置（参见图 3-9，在“测试套件详细信息”窗格的“测试套件名称”下方）。要在此处进行更改，请取消选中“使用父测试套件的配置”选项，然后选中任何其他你想要包含的测试配置。在此处所做的更改将应用于单个套件及其包含的任何套件。例如，查看图 3-9，如果你选择“Iteration 1”节点并更改默认配置，则新配置集将应用于“Iteration 1”中的所有测试套件。但是，如果你在“Test Suite 1 (log onto the blog engine)”处更改默认配置，则更改仅应用于此套件。在此处更改配置不会自动反映在“测试”选项卡上。为了说明这一点，在进行其中一个更改后，选择“测试”选项卡；注意要运行的测试数量与测试用例数量相同。你将在稍后看到如何更改此设置。
另一个选项是为现有测试用例分配套件级别的测试配置。为此，请右键单击“内容”选项卡左侧窗格中的套件，然后选择“为所有测试选择测试配置”。这将显示如图 3-14 所示的屏幕。
其中一个可用选项是“重置默认值”。如果你之前在套件级别更改了默认配置，并希望将其应用于所有现有测试用例，则选择“重置默认值”按钮将为你完成此操作。（如图 3-14 所示，按下此按钮会自动为所有列出的测试选择两个配置。）
在将一个或多个测试用例分配给不同的配置并应用更改后，你将返回到“计划内容”页面。一个明显的区别是“配置”列现在具有大于 1 的值。此列显示分配给给定测试用例的配置数量；你可能会看到测试用例的“测试人员”列显示为“多个”。（当讨论分配测试人员给测试用例时，你将重新审视这一点。）你会在选择“测试”选项卡时看到更改。你可以执行比测试用例数量多两个的测试；这些额外的测试具有不同的配置，如图 3-15 所示。
设置测试配置的另一个选项是选择一个或多个测试并单击“配置”按钮。这允许你仅为选定的特定测试设置配置。
到目前为止，你已经看到了如何为测试计划设置测试配置。可以在测试计划、套件和测试用例级别设置选项，并且通常它们会向下级联。下一步是在测试计划的上下文中分配和管理测试人员。
分配测试人员
与测试配置一样，你可以通过多种方式分配测试人员。第一种也是最明显的方式（也是报告起来最简单的方式）是简单地将测试用例工作项分配给测试人员。然后，该人员就是记录在案的“测试人员”。有许多场景，其中编写测试用例的人并不执行它。还有一些场景，如前所述，测试用例在不同的配置上执行，并且不同的测试人员负责这些不同的配置。
要将测试人员分配给测试用例，你可以在套件或测试用例级别进行操作。两者的屏幕相同；唯一的区别是显示的测试人员。右键单击测试套件或测试用例，然后单击“为选定的测试分配测试人员”或“为所有测试分配测试人员”，或者单击“套件详细信息”窗格中的“分配”按钮。这将带你到如图 3-16 所示的页面。
你可以为每个测试用例和配置单独或批量选择测试人员。要批量分配测试人员，请选择要分配的测试用例（使用 Control 或 Shift 键），然后更改任何测试用例的分配。此更改将复制到所有选定的测试用例。此时，计划选项卡上的一些测试用例显示“多个”在“测试人员”列中。请记住，“计划”选项卡有一个不同的测试用例列表，但由于为不同的配置分配了不同的测试人员，MTM 会将分配给测试用例的所有测试人员聚合为“多个”。你可以在“测试”选项卡上查看各个测试人员。
测试用例规划工作流
现在你已经了解了 MTM 中的“计划”选项卡，是时候谈谈可用性了。如何使用它来管理测试工作流？以任何特定方式管理它的后果是什么？它的使用如何转化为报告？在开始规划之前，先看一下粗略的总体软件开发过程。这个过程，如图 3-17 所示，并非特定于任何方法论。
展示的内容与你应该做的事情
不可能涵盖所有情况的场景。因此，大部分内容是泛化的，但对于无论使用哪种方法论都应该做的事情，都提出了一些强烈的意见。请保持怀疑！这里展示的内容可能不适用于你的特定情况。有很多情况必须抛弃常规做法。此外，理论与现实结合得不太好——这就是为什么会讨论理论，但总是会与实用性相平衡——例如你即将获得的一些关于创建测试计划的建议。
显而易见的是，无论你是在敏捷还是瀑布方法论中工作，你需要采取的基本步骤都是相同的——有人需要收集需求；有人需要编写测试用例；有人需要执行测试用例。例如，仅使用测试驱动开发不足以确保应用程序满足用户需求，因此即使在 TDD 中也需要进行功能测试。但是，执行方式和对功能测试的侧重点可能差异很大。因此，选择适合你组织的实践。
图 3-17 展示了一个基本开发过程，其中测试人员参与进来——并且在理想模型中，他们大致在何时参与。开发生命周期中测试人员工作的三个阶段是初始设计和构建、测试和维护。
敏捷中的阶段
在敏捷方法论中，分析、设计、构建和测试可以紧密压缩，并且不可见为独立的阶段。这是确定最适合你的方法的重要考虑因素。在图 3-17 中，测试并未作为独立阶段显示，因为测试应与开发同步进行。
分析和初始设计
在初始设计期间（对于那些涉及分析和设计阶段的计划），测试计划看起来与测试团队实际执行测试后的计划截然不同。这些阶段的测试用于验证应用程序的分析和设计。测试将主观的需求转化为对客户想要什么的客观理解。
这是一种常见的做法。形式化规格语言——最著名的一种是“Z”——允许你精确地陈述需求。（你可以在 http://formalmethods.wikia.com/wiki/Z 找到更多关于 Z 的信息。）
用形式化建模语言编写的规范遵循严格的数学理论，该理论通常不允许歧义。然而，阅读 Z 或其他形式语言可能很困难。精心构造的测试用例可能不符合形式建模语言的严谨性，但可以提供大致相同的益处，易于阅读，并且花费的时间少得多。一个好的测试用例是几乎（理想情况下）没有歧义，并且每次运行都提供相同结果的测试用例。
好的测试用例
一个好的测试用例的定义是它很可能找到 Bug。
目标
在初始设计阶段，测试用例的目标很简单：客观化并因此验证需求。以下是一个相对简单、常用的示例。考虑一个声明“访客应评论博客文章”的需求。这是一个直接的需求——还是不是？请记住，你现在是从可测试性的角度来看待这个需求。你不一定需要找出所有可能的测试（在任何小型系统中几乎不可能，在任何大型系统中绝对不可能），但你需要确保该需求是可测试的。一个可测试的需求不能有歧义，因为它不重复。在检查详细信息之前，请看表 3-5，这是一个更详细地记录此需求的用例。
需求陈述与需求详细信息
获得像刚才给出的需求陈述是可以接受的。这些应该是高层次的陈述，为用户提供一个缩小需求的容器。详细信息必须明确无误。
| ID | BE-1-1 |
| 标题 | 访客应评论博客文章。 |
| 描述 | 访客应评论博客文章。访客不需要注册即可评论文章，但只能评论允许评论的文章。 |
| 参与者 | 用户（未登录）、已登录用户、系统。 |
| 前置条件 | 必须已发布博客文章。 |
| 后置条件 | 博客文章附加了一条评论，并在查看博客文章时显示。 |
| 正常路径 |
|
| 替代路径 | [ID BE-1-1a：用户已登录] |
| 1a. 用户登录网站。（用户成为已登录用户。） [恢复到第 2 步。] 5a. 系统使用已登录用户的个人资料信息预填充字段。 [恢复到第 6 步。] |
|
| [ID BE-1-1b：用户之前访问过该网站。] | |
| [在第 5 步后分支。] | |
| 5a. 系统使用先前设置的 Cookie 预填充所有信息（只要 Cookie 未过期）。 | |
| [恢复到第 6 步。] | |
这个用例引发了一些问题。首先，在提取 Cookie 信息或个人资料信息时，优先级顺序是什么？换句话说，如果一个用户之前登录过系统并发表了评论（因此设置了 Cookie），而另一个从未发表过评论的用户正在使用该系统怎么办？系统是否会清除信息？它会使用 Cookie 信息吗？当一个用户（从同一台机器）在非登录用户发表评论后登录博客引擎时会怎样？使用哪个信息？“博客作者可以评论自己的文章吗？”这是另一个没有在用例中回答的好问题。
这些问题似乎很小，这只是一个小的例子，但它们可能会导致未解答的问题，从而导致 Bug。这也使得开发人员难以声称他们做对了。测试人员必须提出这些问题才能创建好的测试用例。其他模棱两可的项目也在这里出现——创建评论需要什么信息？我只需要评论，还是需要提供电子邮件地址？用户个人资料中实际包含哪些信息，仅仅因为在那里，我是否会使用它来填充任何可用字段？这些问题更重要，因为这里存在数据模型问题。这些字段必须保存在某个地方，所以你必须了解它们，否则你可能最终需要重写数据访问代码以从不同的地方提取数据。
看过这个用例后，你可以大致推断出有三个“子”需求：
- 访客可以向博客文章添加评论。
- 已登录用户可以向博客文章添加评论，并且他们的信息应从其个人资料中预填充。
- 如果用户之前发表过评论，他们的信息应从 Cookie 中预填充。
现在看一个简单的测试用例来验证需求（参见表 3-6）。
| 操作 | 预期结果 |
| 导航到博客引擎网站 | 显示 BlogEngine.NET 欢迎页面，你未登录。 |
| 单击一篇博客文章。 | 显示帖子详情页，帖子及其下方列出的所有评论。 |
| 单击“评论”链接。 | 页面显示输入姓名、电子邮件地址、网站和国籍的区域。 |
| 输入姓名 Joe。 | |
| 输入电子邮件地址为 joe@nowhere.com。 | |
| 输入评论“Test Comment”，然后单击“保存评论”。 | 评论显示在所有现有评论的上方，博客文章的下方。 |
这个简单的测试用例遵循正常路径。它还识别了一些之前没有的信息；用户可以提供姓名、电子邮件地址、网站和国籍。现在，它不明确说明字段是必需的，但它允许用户理解这就是开发人员正在编码的内容，如果他们想要其他字段，他们可以要求。
这个测试用例确实允许存在歧义——博客引擎网站是什么？应该点击哪个帖子？除了评论之外，还会显示什么信息？然而，在分析阶段，你可能没有什么具体的东西可以依靠，或者不需要那种程度的信息。
重要的是，用户现在确切地知道会发生什么。这在分析阶段已经足够了。用户可以说，“如果这个测试用例通过，系统就会做我想要它做的事情。”因此，在分析和设计阶段结束时，你可能有一系列标记为“设计中”（测试用例工作项类型的初始状态）的测试用例，它们在验证需求中发挥了作用，或者你可能选择将状态更改为“准备就绪”以表示它已完成，并且用户已根据需求验证了测试用例。大多数情况下，这将取决于你希望如何报告这些内容。然而，你可能最好将测试用例保留在“设计中”状态，这样在功能构建并准备好进行测试后，你几乎总会需要进行小的更新。这可能包括添加或删除步骤，并放置具体的控件（例如“从下拉列表中选择你的国籍”，与之前的场景不同，之前的场景规定只提供了输入国籍的区域；现在已知控件类型）。通常，一个“准备就绪”的测试用例处于最终执行状态。
自定义工作项
由于工作项系统的灵活性，添加额外的状态很容易，这是你还可以选择的另一个选项。通常，添加额外的状态不会破坏报告，但需要更新报告才能看到新状态。
然而，这确实引出了另一个观点：测试用例和迭代。使用以下方法：迭代 1 是分析迭代，因此在此迭代中不会进行任何测试，但会编写测试用例。将迭代 1 中的测试用例标记为“准备就绪”是完全可以接受的，只要它们符合迭代 1 的标准。
然后，当你开始迭代 2（这是构建迭代的开始）时，你可能想要复制测试用例并将它们重新分类到迭代 2。这还允许对测试用例进行粒度跟踪，并允许你说某个测试用例在一个迭代中是准备好的，但在另一个迭代中不是。同样，如何做到这一点取决于你以及你希望如何报告。 “场景”部分提供了更多细节。
构建
构建阶段测试用例的目标很简单；它们应该是可重复的，以便在用户之前找到 Bug 并测试应用程序的功能。第一项和最后一项是开放讨论的。探索性测试不一定可重复，除非你记录它。幸运的是，你可以使用 MTM 进行记录，因此这也不是太大问题。由于后端数据或流程，测试可能不可重复，但至少测试人员或开发人员可以在找到 Bug 时复制所采取的步骤。最后一项可能有点麻烦。
在完美的世界里，你可以通过功能测试实现 100% 的代码覆盖率。任何做过测试的人都可以告诉你，除非这是你的质量标准，通常只在生命安全应用中才如此，否则这是不可能的。所以假设这是不可能的。你测试什么？这回到了第二点；你应该首先运行用户可能会使用的测试（因此是找到 Bug 的地方）。为了更清楚一点，在大多数应用程序中，20% 的代码被使用 80% 的时间，而其他 80% 的代码用于处理替代或异常路径。令人惊讶的是，应用程序需要多少代码来处理这些异常情况。所以一个经验法则是，20% 的代码（100% 的正常路径需求）被测试 100%。所有其他代码都在时间允许的情况下进行测试。
会有例外吗？当然。总会有。使用这个指南可以帮助在用户发现 Bug 之前捕获大部分 Bug。如果时间允许，或者发现了与异常情况相关的 Bug，则应该对其他 80% 的代码进行测试。这并不是说不应该在这些区域进行任何测试，但通常保持为抽样测试，或者让单元测试涵盖这些条件。
用户验收测试
作为一个行业，往往缺乏关于客户软件验收的协议（服务级别协议 [SLA] 或其他协议）。这给开发团队带来了困难。想象一下完成了客户的软件，并在“最终演示”之后，客户说，“不行，这不是我想要的”，并要求你重做部分内容。谁来支付费用？谁搞砸了？重要吗？是的。即使开发团队看不到，也必须有人为返工付费，并且有人关心谁犯了错误。这就是问题所在：通常不是错误；这是由于需求变更或误解。这就是为什么看到这种接受协议的缺乏令人费解。
理想情况下，客户接受或拒绝软件的条件应记录在合同中。最好的基础是商定的测试用例集能够正确执行。如果是这种情况，客户将说这些测试用例充分演示了你应交付的系统功能。如果这些测试用例通过，则系统将按他们所要求的执行，并且他们可以验证你已向他们交付了该功能。
现在这会产生一些影响：客户必须在测试用例上签字。需求变更会导致测试用例变更，需要客户签字。超出商定测试用例范围的变更很容易被发现，因为测试用例是客观的而不是主观的，这允许存在歧义，因此导致无法发现的变更。最后一个好处是用户验收测试定义明确。当然，用户可以进行探索性测试（即玩弄系统以查看其是否有效）。但真正的核心是执行测试用例，这使得验收变得容易。原因是在最少的情况下，这些测试用例应该已经执行了两次：一次由开发人员执行，一次由测试人员执行。用户几乎不应该在 UAT 测试用例中发现问题。因此，你现在创建的这些测试用例在交付软件时也有益处。
良好的 UAT 选项
MTM 与 Visual Studio 分离的一个潜在好处是，对于执行 UAT 的用户，可以安装 MTM，用户可以通过测试运行程序进行探索性测试。通过这种方式，如果用户确实发现了一个 Bug，开发团队将拥有用户到达该 Bug 所采取的步骤的完整记录。（这确实需要最终用户拥有该软件的许可证。）
是否会使用 SLA？毕竟，遗憾的是，答案可能是否定的，因为总会有客户想要一些最后一刻的项目，这可能导致一些问题。保留一个流程，但要了解客户的需求。找到一种方法将流程和客户需求结合起来，可以让你掌握这里讨论的内容。即使你现在无法做到，也要现在开始考虑，这样当机会来临时，你就可以利用它。
常见场景
本节介绍了一些常见场景以及如何从规划和跟踪的角度来处理它们。
计划和跟踪测试用例的创建和执行
在团队中的每个人都急于编写功能和编写测试用例之前，你需要一个计划来管理和跟踪这项工作。开箱即用，你可以注意到测试用例工作项类型（无论你使用 MSF for Agile 还是 MSF for CMMI 模板）缺少“剩余工作”和“已完成工作”字段。这是有原因的。那将跟踪什么时间？是跟踪测试用例的创建还是测试用例的执行？还是两者都跟踪？很难说。
另一个需要考虑的项目是项目经理使用 Microsoft Project 来跟踪工作的项目。它使用工作分解结构 (WBS)，该结构使用工作项之间的父子关系来创建 WBS。测试用例工作项通过“Tests/Tested By”关系与需求相关联，因此测试用例不会显示在 WBS 中，项目经理也无法像调度任务那样对其进行调度。
图 3-18：工作项关系
此结构解决了许多问题。首先，项目经理可以将创建测试用例的任务分配给测试团队，这意味着该活动可以捕获在 Microsoft Project WBS 中。其次，项目经理可以选择分别调度测试用例的创建和执行。通过这种方式，在这种情况下，“分配给”字段将是创建它的人，在第二次执行它的人。除非在多个配置上进行测试，否则你不需要使用“分配给测试人员”功能。这使得项目经理能够单独跟踪每个活动的耗时；但是，你可能不想为执行测试用例分配任务。这对于测试人员来说很难现实地跟踪。任务将与测试用例相关联，而不是与测试运行相关联，这使得报告更加困难。
任务和测试用例之间的父子关系不是必需的。它提供了一些额外的结构，并允许测试用例显示在树查询中（而不是定向链接查询），但不会馈送任何报告。
特性驱动开发
图 3-19：典型的 FDD 源代码结构
在这种分支结构中，通常认为在将所有代码合并到主开发环境之前，在每个特性分支上执行全面的测试是一个最佳实践。作为此过程的一部分，测试用例需要“迁移”。例如，如果你为特性分支 F1 上的代码创建了一系列测试用例（测试 A、测试 B、测试 C），并且该代码被合并到 Dev，然后又合并回特性分支 F2，那么这些测试用例可能需要针对 F2 分支中的代码执行。如何跟踪它？
图 3-20：从另一个测试计划复制测试套件对话框
要进入此对话框，请在“计划”、“内容”页面上右键单击“测试套件”，然后选择“从另一个测试计划复制套件”。你可以复制整个套件（包括根节点），也可以复制单个套件。重要的是要注意，这不会创建测试用例的副本。它只是引用现有的测试用例，在这种情况下，这正是你想要的——在一个地方更改测试用例，它就会在所有地方更改。这样，多个测试计划可以与来自不同分支的不同代码相关联（因为每个测试计划都可以关联到自己的生成），但结果可以一起报告。
从一个迭代移动到另一个迭代
当你从一个迭代移动到另一个迭代时，你需要处理一系列问题。其中一些包括未完成的测试用例，而在另一些情况下，测试用例已完成但从未执行。你是简单地将它们从一个套件“复制”到另一个套件（这会创建引用），还是复制测试用例？这取决于你希望如何报告它们。
如果你有一个区域设置为“迭代 1”的测试用例，然后你将它所属的套件复制到另一个测试计划（正在测试“迭代 2”），那么你就会遇到问题。因为套件复制实际上是一个“引用”，测试用例会继续显示在“迭代 1”中，而不是“迭代 2”。这可能会根据你的报告方式严重扭曲你的报告。另一方面，创建测试用例的实际副本会增加测试用例的“数量”，即使这个数量没有改变。
你的选择是什么？第一种情况，“套件复制”是一种快速处理问题的方法。但对于这种情况的建议是再进一步。在执行了套件复制之后，更新所有复制的测试用例，使其与新计划所在的迭代相同。为了更清楚地说明，请考虑以下事项：你有一个计划（分析），该计划设置为迭代 1。计划中的所有测试用例也设置为迭代 1。分析阶段已完成，你进入下一个阶段，其中将更新这些测试用例。如果你打算对这些测试用例进行工作，请使用套件复制将它们添加到名为“Construction”的新测试计划中。复制完成后，更新所有测试用例，使其迭代设置为迭代 2（以匹配它们将被处理的迭代）。然后继续像平常一样处理它们。
第二种选择在很多方面都更具吸引力。创建测试用例的副本允许你保留已针对给定迭代中的代码执行的测试用例。例如，迭代 3 在发布给客户时结束。团队开始进行迭代 4 的工作，这将修改迭代 3 中的一些功能。（这是敏捷开发中每天都会发生的事情，但在瀑布开发中不太常见。）但是，在当前发布和下一个发布之间，这些测试用例可能需要针对生产代码重新执行。如果你正在积极更改这些测试用例，你需要回到测试用例工作项类型的历史记录中才能找到针对当前发布执行的测试用例。通过这种方式，它几乎充当了测试用例的分支机制，并允许你保留针对发布执行的测试用例。这对于审计目的可能很方便。
关于这个问题的建议是“这取决于你想做什么。”没有“最佳实践”，因为一切都取决于你的情况。只需了解各种场景中可能发生的情况，并在制定计划之前仔细考虑。
处理不同的测试配置
如前所述，你可以使用配置作为元数据进行报告，并减少你需要维护的测试用例数量。但这总是说得通吗？答案是否定的。没有工具可以轻松解决这个问题，所以需要一些规划。首先，你需要确定不同的配置是否需要不同的测试。如果需要，你的答案很简单：不要使用 MTM 测试配置来区分配置。在这种情况下，你需要创建单独的测试用例，并通过区域进行区分。此外，创建单独的测试计划会更好。为什么？如前所述，测试计划只有一个手动测试设置和一个自动化测试设置。可以假设对于不同的配置，你可能在不同的系统上或使用不同的设置进行测试，因此使用单独的测试计划更容易管理。如果你这样做，你就不需要使用区域来分解你的配置；MTM 可以为你工作。
这是绝对不能忽视的一点。如果必须在每次运行的基础上更改测试设置，那么测试设置的管理可能会很麻烦。将测试计划分组到不同的区域，然后在它们下面安排测试用例，这很容易做到。如果你需要将需要不同测试设置的测试用例分组在一起，这会给测试人员增加更多的工作，所以要在问题出现之前进行规划。
摘要
在本章中，您了解了测试计划的组成部分以及如何创建它们。您了解了所有不同测试容器之间的关系以及不同测试阶段（分析、构建和用户验收测试）的目标。本章还向您展示了如何创建不同的测试配置及其对测试用例的影响。您学会了如何通过为不同的测试用例和配置组合分配测试配置和测试人员来开始管理测试计划。最重要的是，您探索了许多不同的场景，这些场景要求您考虑测试环境的结构以及这些场景的常见问题。在下一章中，您将学习如何使用 Microsoft Test Manager 执行测试。