“Bug 状态”报表

项目
02/21/2013

团队开始查找和修复 Bug 后，可以通过查看“Bug 状态”报表来跟踪团队在解决和关闭 Bug 方面的进度。此报表基于 Bug 状态、优先级别和严重级别显示累计 Bug 计数。

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

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

主题内容

报表中的数据
设置迭代的持续时间
解读报表
筛选报表并更改显示

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

团队修复 Bug 的速度是否足够快，可以按时完成工作？
团队是否先修复高优先级别 Bug？
Bug 按优先级别和严重级别的分发情况如何？
为每个团队成员指派了多少 Bug？

所需权限

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

报表中的数据

“Bug 状态”报表中显示的数据派生自数据仓库。此报表显示如以下图和表所显示和描述的几组信息。

Bug 状态图表 “Bug 状态”报表的下半部分

信息	说明
Bug 数	所有 Bug 的累计计数的可视表示形式，按其状态分组。
活动 Bug (按优先级别/严重级别)[Active Bugs by Priority/Severity]	描述仍处于活动状态的 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。	测试覆盖率是否足够？是否有其他问题对团队发现 Bug 的能力造成了阻碍？
已解决或关闭的 Bug 的数量没有变化。如果正在解决或关闭的 Bug 的数量长时间保持不变，则表明团队成员可能无法解决或关闭 Bug。	是否正确设置了团队优先级别？是否在其他任务上过度分配了团队成员？团队成员是否正确跟踪了其 Bug 状态？
Bug 指派分布不平均。如果为一两个团队成员指派了大量 Bug，而为其他团队成员则只指派了少量 Bug，则团队可能要考虑重新指派工作。	团队是否需要通过重新指派 Bug 来平衡工作负荷？
活动高优先级别 Bug 的数量大于活动低优先级别 Bug 的数量。当高优先级别 Bug 的数量比低优先级别 Bug 的数量多很多时，可能会先致力于解决低优先级别的项。	团队是否按团队设置的优先级别顺序修复 Bug？是否有问题对团队修复高优先级别 Bug 的能力造成了阻碍？