通过

质量面板 (Agile)

  • 项目

您可以使用“质量”面板，获得与所开发软件的质量有关的测试、开发和生成环节目前的进展概况。 团队可以使用“质量”面板来了解产品质量，并做出有助于达到团队产品质量目标的决策。

通过使用此面板，您可以查看测试进度、生成状态、解决和关闭 Bug 的进度、Bug 重新激活比率、已测试代码所占的百分比，以及代码更改的趋势。 上述每个指标都是针对最近四周的情况绘制的。

可以通过团队项目门户网站访问面板。 仅当该门户网站已启用且配置为使用 SharePoint Server 企业版时，您才能访问“质量”面板。 有关详细信息，请参见面板。

主题内容

  • 面板中显示的数据

  • 跟踪质量所需的活动

  • 质量问题疑难解答

  • 自定义质量面板

此面板可用于回答以下问题：

  • 测试工作是否按部就班？

  • 团队是否正在测试适当的功能？

  • 团队的 Bug 修复是否具有高质量？

  • 测试是否已过时？

  • 团队是否有足够多的测试？

  • 是否出现了任何瓶颈？

需要的权限

若要查看面板，您必须被指派到某个组或属于某个组，而在 SharePoint 产品中，已为该组分配有对团队项目的**“读取”权限。 若要修改、复制或自定义面板，您必须被指派到某个组或属于某个组，而在 SharePoint 产品中，已为该组分配有对团队项目的“成员”**权限。 有关详细信息，请参见向团队项目添加用户。

若要在 Office Excel 中修改报表，您必须是 SQL Server Analysis Services 中**“TfsWarehouseDataReaders”安全角色的成员，并且必须指派到某个组或属于某个组，而在 SharePoint 产品中，已为该组分配有对团队项目的“成员”**权限。 有关详细信息，请参见授予对 Visual Studio ALM 数据仓库的数据库的访问权限。

若要查看工作项，您必须是**“Readers (访问者)”组的成员，或者您的“查看此节点中的工作项”权限必须设置为“允许”。 若要创建或修改工作项，您必须是“Contributors (参与者)”组的成员，或者您的“编辑此节点中的工作项”权限必须设置为“允许”**。

面板中显示的数据

团队成员可以使用“质量”面板来确定他们所开发产品的总体质量。 在理想情况下，测试通过率、Bug 数和代码改动将全部都显示相同的状况，但通常情况下不是如此。 在发现差异时，您必须更加仔细地检查相应的生成和数据系列。 “质量”面板将测试结果、测试中的代码覆盖率、代码改动和 Bug 结合在一起，可帮助您同时了解多个方面。

若要了解“质量”面板上显示的 Web 部件，请参见下图和下表。

“产品质量”面板

备注

只有当团队通过使用测试运行程序和 Microsoft 测试管理器创建测试计划和运行测试时，“测试计划进度”报表才可用。

当团队项目的数据仓库不可用时，进度、生成和代码图表、报表 步骤 1 至 步骤 6 不会出现。

若要了解有关如何解释、更新或自定义“质量”面板中显示的图表的更多信息，请参见下表中的主题。

Web 部件

显示的数据

相关主题
步骤 1

最近四周内所有测试用例的测试结果的堆积区域图，按它们的最新记录结果（“从不运行”、“受阻”、“未通过”或“通过”）分组。

Excel 格式的“测试计划进度”报表

“测试计划进度”报表
步骤 2

堆积柱形图，这些柱形显示最近四周内“未通过”或“成功”生成的计数。

生成状态报表

Excel 格式的“生成状态”报表
步骤 3

最近四周内所有 Bug 的累计计数的堆积区域图，按状态分组。

Bug 进度 Excel 报表

Excel 格式的“Bug 进度”报表
步骤 4

最近四周内团队从已解决或已关闭状态重新激活的 Bug 数的堆积区域图。

Excel 格式的“Bug 重新激活”报表

Excel 格式的“Bug 重新激活”报表
步骤 5

折线图，该图显示最近四周通过版本验证测试 (BVT) 和其他测试所测试的代码的百分比。

“代码覆盖率”报表

Excel 格式的“代码覆盖率”报表
步骤 6

堆积区域图，该图显示最近四周内，团队在生成前的签入中添加、移除和更改的代码行数。

“代码改动”报表

Excel 格式的“代码改动”报表
步骤 7

即将到来的事件的列表。 此列表派生自 SharePoint Web 部件。

导入事件 Web 部件

不适用
步骤 8

活动工作项、已解决工作项和已关闭工作项的计数。 您可以通过选择每个数字来打开工作项列表。 此列表派生自 Team Web Access Web 部件。

“项目工作项”Web 部件

不适用
9

最近的生成及其状态的列表。 可以通过选择特定生成来查看更多详细信息。 此列表派生自 Team Web Access Web 部件。

“最近的生成”Web 部件

图例：

生成正在进行中：生成未启动

生成尚未开始：正在进行生成

生成成功：生成成功

生成失败：生成失败

生成已停止：生成停止

生成部分成功：生成部分成功

运行、监视和管理生成
10

最近的签入的列表。 可以通过选择特定签入来查看更多详细信息。 此列表派生自 Team Web Access Web 部件。

“最近的签入”Web 部件

开发代码和管理挂起的更改

监视质量所需的活动

为了使“质量”面板有用且精确，团队必须执行本节描述的活动。

跟踪测试计划进度所需的活动

为了使“测试计划进度”报表有用且精确，团队必须执行以下活动：

  • 定义测试用例和用户情景，并在测试用例和用户情景之间创建**“测试方”**链接。

  • 定义测试计划，并将测试用例分配给测试计划。

  • 对于手动测试，将测试用例中每个验证步骤的结果标记为通过或未通过。

    重要

    如果某个测试步骤是验证测试步骤，则测试人员必须使用某个状态对该步骤进行标记。测试用例的总体结果反映测试人员已标记的所有测试步骤的状态。因此，如果测试人员将任何测试步骤标记为未通过或未标记该步骤，则测试用例的状态将为未通过。

    对于自动测试，每个测试用例都会自动标记为通过或未通过。

  • （可选）若要支持筛选，请将**“迭代”和“区域”**路径分配给每个测试用例。

    备注

    有关如何定义区域和迭代路径的信息，请参见添加和修改区域和迭代路径。

跟踪 Bug 进度和 Bug 重新激活所需的活动

为了使“Bug 进度”和“Bug 重新激活”报表有用且精确，团队必须执行以下活动：

  • 定义 Bug。

  • 在团队修复、验证、关闭或重新激活每个 Bug 时，更新其**“状态”**。

  • （可选）指定每个 Bug 的**“迭代”和“区域”**路径（如果想要按这些字段进行筛选）。

跟踪生成状态、代码覆盖率和代码改动所需的活动

为了使“生成状态”、“代码覆盖率”和“代码改动”报表有用且精确，团队成员必须执行以下活动：

  • 配置生成系统。 若要使用 Team Foundation Build，必须设置生成系统。

    有关详细信息，请参见配置和管理生成系统。

  • 创建生成定义。 可以创建数个生成定义，然后运行其中每个生成定义，为不同的平台生成代码。 此外，还可以针对不同配置运行每个生成。

    有关详细信息，请参见定义生成过程。

  • 定义要随生成自动运行的测试。 在生成定义中，您可以定义随生成运行的测试，还可以将测试通过定义为生成成功的必要条件。

    有关详细信息，请参见对生成过程使用默认模板。

  • 配置测试，使其收集代码覆盖率数据。 为使代码覆盖率数据显示在报告中，团队成员必须对测试进行检测以收集相关数据。

    有关详细信息，请参见在生成过程中运行测试。

  • 定期运行生成。 您可以定期运行生成或在每次签入之后运行生成。 可以在使用计划触发器时创建定期生成。

    有关更多信息，请参见创建或编辑生成定义和运行、监视和管理生成。

    备注

    虽然团队成员可以使用生成资源管理器对生成进行手动分级，但此分级不会反映在“生成质量指示器”报告中。生成分级在“生成摘要”报告中显示。有关更多信息，请参见对已完成生成的质量进行评级和“生成摘要”报表。

质量问题疑难解答

下表描述“质量”面板可帮助您监视并确定团队可以采取的措施的特定质量问题。

问题

要查看的报表

疑难解答注释

生成失败

生成状态

夜间生成是软件开发项目的核心所在。 当生成未成功完成或者未通过版本验证测试 (BVT) 时，团队必须立即修复问题。

测试失败

测试计划进度

代码改动

当失败测试和代码改动的比率都很高时，团队可能需要调查软件如此频繁失败的原因。 原因可能包括：开发行为不严谨或测试对于早期迭代周期太过严格。

测试通过但发现 Bug 的比率太高

测试计划进度

Bug 进度

如果多项测试通过，但同时发现了多个 Bug，则团队可能需要调查以下可能性：

  • 对于当前产品阶段，测试可能不够严格。 在早期迭代中，简单的测试没有问题。 但是，随着产品的逐渐成熟，测试应该演练更广泛的方案和集成。

  • 测试可能已过时或测试了错误的功能。

  • 不同的测试技术可能会提供更好的结果。

  • 报告了 Bug，但 Bug 不受测试的控制。 如果报告了 Bug，并且 Bug 未链接到测试用例，则 Bug 不受回归测试的控制。

测试已过时

测试计划进度

代码覆盖率

代码改动

当多项测试通过、大量代码发生更改且代码覆盖率降低时，团队可能没有运行演练新代码的测试。

由于开发测试的速度与代码更改的速度不同，因此测试覆盖率可能变小并且不足。

团队未测试、关闭或重新激活已解决的 Bug

Bug 进度

如果“Bug 进度”报表中已解决 Bug 的数量激增，则表明开发人员在不断地解决 Bug，但测试人员尚未验证和关闭这些 Bug。 团队应调查出现此模式的原因。

测试太少

测试计划进度

代码改动

当团队运行的测试很少、代码改动率很高且代码覆盖率低于预期目标时，团队可能需要为测试分配更多资源。 此外，团队应确保测试人员关注的功能与其他团员成员相同。

重新激活

Bug 重新激活

当团队重新激活的 Bug 的比率较高或不断增加时，则表明测试人员在频繁拒绝开发人员的修复。 团队必须解决这些问题以避免分配大量的资源来重新处理拒绝的修复。 可能的原因包括：Bug 报告过程较差、测试实验室管理不佳，或会审过于急进。

单元测试不足

代码覆盖率

代码改动

如果代码覆盖率降低与代码改动增加的情况同时出现，则开发人员可能在未对代码进行任何对应单元测试的情况下签入代码。

大多数情况下，如果团队实行测试驱动的开发或类似技术，则代码覆盖率应接近 100%。 如果以 BVT 的形式重新使用单元测试，则代码覆盖率应出现在对应的报表中。

自定义质量面板

可以通过下列方式来自定义“质量”面板：

  • 更改每个 Excel 报表的筛选器，以侧重显示特定产品区域或迭代。

  • 添加一个自定义查询 Web 部件，该部件显示查询找到的工作项的列表。 例如，您可以添加一个查询，该查询列出了所有未链接到测试用例的活动 Bug。 此查询将显示已报告但不是通过测试找到（因而不受回归测试控制）的 Bug 的数量。

  • 向面板中添加现有 Excel 报表，例如**“Bug 趋势”和“失败分析”**。

有关如何使用和自定义 Office Excel 中的报表的详细信息，请参见 Microsoft 网站上的以下页面：