使用Team Foundation Server(TFS)进行项目Bug管理

一、TFS的简单介绍

TFS中的ＢＵＧ管理为开发人员提供了BUG查询，BUG回复，及BUG review的功能。
1. BUG查询
在团队资源管理器中，BUG是作为工作项来管理，和项目中任务，场景等统一编号。在工作项中有两种工作项的查询方式。团队查询是在TFS Server端定义的工作项查询方式，我的查询是用户自定义的工作项查询。
开发人员可以定义一个查询所有指定给自己的BUG的查询项。

2.BUG回复
开发人员在指定给自己的Bug中可以按照测试人员提供的BUG描述重现，修改BUG。修改后可以将BUG的状态置为Resolved，反馈给测试人员，以便测试人员对BUG 的跟踪测试。

3.BUG Review
在BUG查询给出的列表中，可以自定义显示列，分组排列BUG,以便跟踪。或者新建查询。例如：建立一个查询所有制定给Ａ成员的所有状态是激活的BUG查询项。Ａ在Review自己的BUG时就可通过这个查询很方便的查出自己未解决的BUG。

 

二、Bug的优先级设置

在TFS中将将Bug的优先级分为3个等级。在项目中按照以下分级说明进行分类。开发人员应该按照优先级解决BUG。

1   Priority 1 致命的（Fatal）：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃，悬挂，死机，或者危机人身安全。（当天必须完成）
2   Priority 2 严重的（Critical）：系统的主要功能部分丧失，数据不能保存，系统地次要功能完全丧失，系统所提供的功能或服务受到明显的影响。（在回归测试前必须完成）
3   Priority 3 一般的（Major）：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差，文字排列不整齐，操作不方便等。（在回归测试前修改）

三、 Bug数据库管理

本系统的测试BUG跟踪采用微软TeamFoundationServer进行管理，由测试环境部署人员在SQL Server 2005中建立BUG管理数据库。
1    TeamFoundationServer  

2    Bug(Title) 标题
 Bug的标题格式可遵照以下格式：功能名：提出简短描述。
其中功能名指发现Bug的产品功能。提出的简短描述可尽可能解释发现的问题。这里举例为：“软件：中断执行IRM文件引起应用崩溃。”
3    Bug(Classification)分级
Area:指BUG产生的区域，例如：CMS
Iteration:指BUG产生的测试迭代，一般项目采用三次迭代。
4    Bug(Status) 状态

Assigned To ：指定负责解决该BUG的人员

Status：指bug现在的状态
        Active:激活状态
        Closed:关闭状态
        Resolved:解决状态
Triage：
        Approved:
        Investigate:

Rank：bug的等级

Reason：bug产生的原因
        Build Failure：编译失败
        New：新BUG
Bug解决的原因
       As Designed：系统设计如此
       Deferred：BUG延期解决
       Duplicate：已有相同bug
       Fixed：以解决的bug
       Obsolete：旧的BUG
       Unable to Reproduce：bug无法重现
Bug关闭的原因
      As Designed：系统设计如此
      Deferred：BUG延期解决
      Duplicate：已有相同bug
      Fixed：以解决的bug
      Obsolete：旧的BUG
      Unable to Reproduce：bug无法重现

Priority ： 解决Bug的优先级。用于决定各开发小组任务与工作计划。
1：Bug必须立即修改，否则下一步工作无法展开。
2：Bug可在发布前任意时间修改。
3：Bug是微不足道的，可在发布后解决。

5    Bug(Description)描述
Bug 的描述应描述发现的问题，以及在何种情况下能重现该问题，举例说明：“1：打开Edit菜单项，2：按下Edit按钮，3：按下 Delete按钮。希望：得到能进行编辑或删除操作。实际：应用中断崩溃”
6    Bug(History)历史
Bug历史栏是由TFS自动生成的，供bug跟踪人员查询。不能手动修改。
7    Bug(Link)连接
Bug链接栏可以添加链接，为描述不清楚地bug提供链接。
8    Bug(File Attachments)附件
Bug附件栏可以添加bug描述的附件。
9    Bug(Details)其他
Bug 其他可以添加Bug 的其他内容，主要由测试人员填写。包括BUG是否发布，发现的生成迭代，解决的编译迭代，等等。

四、防止 Bug 重复提交

为避免bug的重复提交可先查询VSTF数据库看该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 的作者确认该 Bug 与另一个 Bug 描述的是同一问题，则该 Bug 作为“重复”关闭。
已过时	如果 Bug 的作者的同意所描述的问题不再适用于该产品，则该 Bug 作为“已过时”关闭。
无法重现	如果 Bug 的作者无法生成该 Bug 的工作示例或提供更具体的说明以重现该 Bug，则该 Bug 作为“无法重现”关闭。

已解决 到 活动

解决方案被拒绝	如果解决方法不可接受，则该 Bug 返回到“活动”状态。提供有关解决方法被拒绝的原因的具体信息，以便帮助后面接手该 Bug 的人员能够适当地解决它。
错误修复	如果未正确修复，则该 Bug 返回到“活动”状态。提供有关修复 Bug 的方式和未正确修复 Bug 的原因的详细信息。
测试未通过	如果测试表明 Bug 仍然存在，则 Bug 恢复为“活动”状态。请提供有关哪个测试未通过以及在哪个版本中测试未通过的详细信息。

已关闭

已关闭的 Bug 表示对于当前产品版本不需要再做进一步的工作。Bug 在解决方法得到验证后关闭。

已关闭 到 活动