“重新激活”报表

在团队解决并关闭 Bug 后，您可以使用“重新激活”报告来确定团队修复 Bug 的效率。重新激活通常针对已解决或过早关闭后重新打开的 Bug。重新激活率也称为错误反馈比率。

您可以使用“重新激活”报告来显示已重新激活的 Bug 或用户情景。作为产品所有者，您可能需要与团队讨论可接受的重新激活率。根据团队的目标，可以接受较低重新激活率（例如，低于 5%）。不过，较高或不断增加的重新激活率说明团队需要诊断并修复系统性问题。

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

备注

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

主题内容

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

必需的权限

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

报表中的数据

“重新激活”报告显示一个区域图，用于表示处于已解决状态或已从关闭状态重新激活的 Bug 数或用户情景数。这些数据派生自数据仓库。该图显示基于指定的持续时间和筛选器的项数，如下图所示。

“重新激活”报表示例

可通过以下方法筛选“重新激活”报告：

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

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

若要了解当前迭代的重新激活率，报告的开始和结束日期必须是当前迭代周期的开始和结束日期。

可以预见，“重新激活”报告随您在产品开发周期中所处的阶段而异。在早期迭代中，重新激活量很小。在关闭 Bug 和用户情景后，您需要查看重新激活率。

可以使用“重新激活”报告显示的信息来检测团队是否正重新激活大量 Bug 或用户情景。重新激活率计算进行过修复但未能修复的 Bug 数。重新激活会造成不利的返工周期，从而影响计划任务的进展。

通过查看报告，可以回答以下问题：

在正常的“重新激活”报告版本中，可以看到解决和关闭 Bug 的进度是稳定的，如下图所示。工作项的总重新激活率最高为 5%，且在迭代期间不会增加。根据团队的目标，重新激活率可以接受较小的变动。重新激活率越低，团队取得的总体进展就越大。

“重新激活”报表的正常版本

下图演示了不正常的“重新激活”报告版本。

“重新激活”报表的不正常版本

除了提供一些要考虑的建议问题，下表还描述了该报告的不正常版本的特征。

特征	可能的问题
团队在重新激活大量 Bug。您应将重新激活率视为团队发现的 Bug 总数的百分比。较高的 Bug 重新激活率说明可能团队过早地关闭了 Bug。这是项目运行不良的警告征兆。重新激活会给产品周期引入额外工作，通常会使相应工作所需的总工作量加倍。	团队在解决 Bug 时是否执行了足够的单元测试？ Bug 说明是否有助于采取有效的 Bug 解决方案？即使基础问题尚未修复，是否也要解决 Bug？是否应将某些 Bug 设置为更低优先级，从而有效减少团队要处理的高优先级 Bug 的数量？测试实验室的管理是否有效？
团队在重新激活大量用户情景。您应将用户情景重新激活率视为团队要关闭的用户情景总数的百分比。较高的用户情景重新激活率说明可能有其他问题值得调查。	测试覆盖率是否满足用户方案的需要？
重新激活数不断增加。重新激活数增加时，不会修复已重新激活的 Bug 或用户情景。您可能需要重新评估团队优先级别以修复已重新激活的 Bug 或用户情景。	是否正确设置了团队的优先级别？重新激活是否还有其他根本问题？

团队在重新激活大量 Bug。您应将重新激活率视为团队发现的 Bug 总数的百分比。

较高的 Bug 重新激活率说明可能团队过早地关闭了 Bug。这是项目运行不良的警告征兆。重新激活会给产品周期引入额外工作，通常会使相应工作所需的总工作量加倍。