“Bug 趋势”报表

项目
06/09/2015

您可以使用“Bug 趋势”报表来帮助跟踪团队发现和解决 Bug 的比率。此报表显示一段时间内报表、解决及关闭的 Bug 的滚动或移动平均值。当您管理大型团队或大量 Bug 时，可以每周监视“Bug 趋势”报表以深入探索团队发现、解决和关闭 Bug 的情况。

有关如何访问、刷新或管理报表的信息，请参见报告 (SQL Server Reporting Services)。

备注

此报表要求已使用 SQL Server Reporting Services 配置包含您的团队项目的团队项目集合。当打开团队资源管理器并展开您的团队项目节点时，如果未显示 “报告”，则此报表不可用。

主题内容

报表中的数据
设置迭代的持续时间
解释报表
筛选报表

此报表可用于回答以下问题：

团队每天报告、解决及关闭多少 Bug？
团队处理 Bug 的总体趋势如何？
Bug 激活率和解决率是否按预期随着临近迭代结束而逐渐降低？

需要的权限

若要查看报告，您必须被分配到或属于某个组，而该组已经在 SQL Server Reporting Services 中被赋予**“Browser”**角色。有关更多信息，请参见向团队项目添加用户或管理权限。

报表中的数据

“Bug 趋势”报表基于指定的筛选器，计算团队已打开、解决及关闭的 Bug 数的滚动平均值。滚动平均值以计算该值日期的前七天的数据为基础。也就是说，该报表计算该日期前七天中每一天的每种状态的 Bug 数平均值，然后将结果除以七。这些数据派生自数据仓库。

下图显示了一个“Bug 趋势”报表示例。

“Bug 趋势”报表示例

此报表最多可显示三个线图，其中每个图表示已激活、解决及关闭的 Bug 数的滚动平均值。

您可以按下列方式筛选报告：

更改报表的开始和结束日期。
通过指定迭代和区域路径或 Bug 状态、优先级别或严重级别，筛选计入报表中的 Bug。

有关更多信息，请参见此主题后面的筛选报告。

跟踪 Bug 所需的活动

为了使“Bug 趋势”报表有用且精确，团队必须执行以下活动：

定义 Bug，然后指定其**“迭代”和“区域”**路径。
随着每个 Bug 的修复、验证直至关闭，更新其**“状态”**。
在会审期间指定每个 Bug 的**“优先级别”和“严重级别”**。

可以使用会审工作簿快速更新 Bug 的迭代、区域、状态、优先级别和严重级别。有关详细信息，请参阅会审工作簿。

设置冲刺 (sprint) 或迭代的持续时间

若要了解当前迭代的 Bug 趋势，报表的开始和结束日期必须与当前迭代周期的开始和结束日期相匹配。

更改迭代的持续时间

在**“迭代开始(日期)”或“迭代结束(日期)”**旁，单击日历图标，然后单击一个日期。
单击**“查看报表”**。

解释报表

您应预计到 Bug 比率会因您在产品开发周期中所处的阶段而异。与晚期迭代相比，团队在早期迭代中发现的 Bug 应较少。在临近产品周期末尾的迭代中，团队应关闭大多数 Bug。

通过查看与所有当前团队项目活动相关的 Bug 以及“Bug 状态”和“重新激活”报表提供的其他指标，可以最好地解释 Bug 比率。例如，在编写拙劣的代码中、新集成的代码中、使用改进的测试时或是在特殊活动（如 Bug 大扫除）过程中，团队可能会特别迅速地发现 Bug。另一方面，在高质量产品中以及使用低效测试时会更加难以发现 Bug。可以使用代码覆盖率、代码改动及测试率的指标来帮助进一步评估 Bug 趋势的含义。

当产品随着临近产品周期的结束而趋于稳定时，团队应很少会发现 Bug。

“Bug 趋势”报表可能会显示一个或多个指示，在下表的左列中对这些指示进行了描述。可以查看区域右列中的问题，以更加详细地进行讨论。

特征	可能的问题
团队在连续时间段内发现的 Bug 数大致相同。如果团队在连续几周或连续几个迭代中发现的 Bug 数相同，则可能需要调查根本原因。在测试周期早期，测试可能不够严格或不够先进，因而无法发现许多 Bug。在早期迭代中，这种情况是正常的。但是，随着产品的逐渐成熟，测试应会运用更广泛的方案和集成。	测试用例是否足以测试所开发的用户情景？测试是否已过时或是否测试了错误的功能？测试团队是否严格测试了每个用户情景？
团队在每个时间段内发现的 Bug 都很多。在草率的代码中、新集成的代码中、使用有效测试时或是在特定活动（如 Bug 大扫除）过程中，团队可能会非常容易地发现 Bug。	代码覆盖率、代码改动或测试进度的指标是否指示代码或测试存在问题？
团队在每个时间段内发现的 Bug 都很少。团队可能尝试在高质量解决方案中发现 Bug 或使用低效测试。	代码覆盖率、代码改动或测试进度的指标是否指示代码或测试存在问题？
团队在每个时间段内解决的 Bug 都很多。较高的解决率通常指示团队取得了良好的进展。	已解决的 Bug 是否已立即关闭？关闭率应与解决率相似。在预期范围内是否仍存在 Bug 重新激活？
团队快速解决了 Bug，但未将其关闭。指派为验证 Bug 修复的团队成员可能过于分散，或不同的优先级别可能会使这些团队成员无法关闭已解决的 Bug。	测试资源是否过度分配？团队是否应重新查看测试优先级别？

正常的报表版本

正常的“Bug 趋势”报表会显示团队在开发周期开始时发现的 Bug 较多，而在临近发布结束时发现的 Bug 较少。随着临近项目结束，团队应解决和关闭更多 Bug。

如果团队解决 Bug 的速度超过发现 Bug 的速度，则活动 Bug 的数目将会开始减少。当团队开始发现较少的 Bug 时，产品将趋于稳定。

不正常的报表版本

不正常的“Bug 趋势”报表可能会显示随着发布日期的临近，团队发现 Bug 的速度加快，而解决 Bug 的速度则减慢。在这种情况下，因为 Bug 还没有得到修复，所以团队的 Bug 积压工作将不断增加，您可能需要调查原因。下图显示的报表表示某个团队发现了许多 Bug，而解决的 Bug 数低于发现的 Bug 数，关闭的 Bug 数又低于解决的 Bug 数。

“Bug 趋势”报表的不正常版本