一个基于VSTS 2010的Bug管理流程定义

   Bug的流程管理首先需要定义一个Bug的产生到终结这个过程的所有状态及相应动作。下图是Bug的生命周期示意图，对Bug的产生与动作进行了定义：

   黄色方框描述的是Bug的状态，从图中可以看出一个Bug只有三个状态：活跃的(Active)、解决的（Resolved）和关闭的(Closed)。绿色的终结状态是关闭后的自然产生状态，无需操作。蓝色方框表示的是在开发人员和测试人员对某个Bug观点不能达成一致时的处理方式，即召开Bug讨论会(Bug-scrub meeting)，参会人员应该包括：开发工程师（经理）、测试工程师（经理）、项目经理、产品经理以及售前与售后工程师。简言之，尽可能多地包括产品涉众。

   Bug的提交有两种情况：

   1.测试人员执行测试用例发现了Bug。

   2.构建产品过程中失败，持续构建系统自动提交Bug。在对这个失败进行分析后，可以给予更详细的更新。

   Bug的解决有两条路径：

   I.DEV直接解决。这里面包括四种原因

     1).问题修复了(Fixed)，文档或者程序进行了修改；

     2).重复的Bug（Duplicate），之前有过同一现象报告，或者同一根本原因(Root Cause)； 

     3).无法重现(Cannot Reproduce)；

     4).废弃的(Obsolete)，Bug所在模块被去除。

   II.DEV和Tester对某个Bug不能达成一致，比方说DEV认为是应有的行为，虽然需求文档没有定义，而Tester认为行为会影响用户体验。这时Dev可以把Bug所有人改为项目经理便于召开Bug-scrub meeting进行讨论。涉众们共同讨论确定对Bug的处理意见:

     1).不修复，同意是个Bug，但基于人力,时间或者对产品重新引入的风险考虑而选择放弃修复。

     2).不是Bug，涉众们讨论认为行为满足了用户需求，不是Bug，或者Tester发生误报（会前如果Tester认同，不需将此Bug列为讨论范围，由Tester自行关闭）。

     3).是Bug，而且需要得到解决。

   对于一个解决了的Bug，Tester需要对其进行验证。两种情况可能发生:

   1.Bug得到修复，Tester对其进行关闭

   2.Bug没有得到修复，Tester重新将Bug改为活跃状态，Bug持有人改为DEV。

   关闭的Bug可能在之后的某次测试重新发现或者经过分析发现仍会存在，将该关闭的Bug重新改回活跃状态报给相应DEV。

   注：这些状态和原因可以在VSTS中进行定制，不过需要安装TFS的Power Tools

   提交Bug时必须说明以下内容：

   1.标题：对Bug现象进行简明描述，一般不超过20个字

   2.状态及原因:状态改为活跃的(Active)，原因为测试失败或构件失败

   3.发现模块：Bug产生的代码模块或者在不清楚情况下先填发现的业务模块，以后进行更新。

   4.发现版本及时期：推荐填写Build号而不是Revision号。因为测试只能发生在一个可测试的build上。只有构建失败才可以填写最新的那个Revision号。所谓时期可能是迭代号或者Milestone名称，依据项目管理流程定义。

   5.优先级(Priority)与严重度(Severity)：一般两者成正相关，考虑项目资源或风险可能略有调整。优先度越高表明需要越早解决，严重度分为

     1).危险的(Critical):关键的或者主要的功能无法使用，没有规避方法。用户不会使用该产品。

     2).高危的(High)：关键功能或主要功能没法使用，但可能规避，用户可能因该Bug而放弃使用该产品。

     3).中等的(Medium)：产品功能有缺陷但不致命，用户可能使用，但影响公司信誉。

     4).低危的(Low)：产品缺陷不是很紧要，但最好给予修改。

   6.Bug所有人:一般此阶段是填写对应模块开发人员。不清楚情况下填写项目经理或者开发经理，由他们再另行分派。

   7.详细描述:这一内容的填写最能区分测试人员的素质与水平的高低，大抵该区域填写的内容要涵盖如下方面:

      1)发现的环境与操作步骤，记录Bug发生时你的环境和操作，可能它并不一定重现，但描述清楚可让涉众对问题有更形象的了解。

      2)发生的概率，Bug不一定必然重现，如果非确定发生的Bug最好描述发生的概率，便于确定Severity。

      3)个人的判断，高素质的具备较强开发能力的测试人员可能这时能够直接告诉DEV问题的原因或者问题代码所在。

   8.相应链接与附件:可以包括失败时的截图，Log文件或者参考的链接(要保证有效性)

   一个Bug报告给DEV后，或直接处理或Bug-Scrub会议讨论把活跃状态的Bug改为解决的状态，更改时需要填写:

   1.Bug所有人:需要验证关闭的Bug填写Tester，需要讨论的填写项目经理

   2.修改理由:参见第一部分关于Bug解决两条路径的说明。

   3.修改的版本号:填写修改代码或文档检入(Check-in)的Revision号，自动化系统最好在构建时自动改写为修复后最新可用Build号。这需要DEV在修复时关联代码和Bug。

   4.Bug的根本原因与修复方案说明：DEV需要填写该Bug发生的原因，便于涉众了解产品问题的症结，便于Tester针对修复和周边模块设计新的测试用例。

   经过解决的bug由Tester验证关闭，填写原因，状态改为关闭的；验证不通过的填写状态为Active以及理由，并加必要注释于历史记录中。这时的填写可以参看活跃状态的说明。

  VSTS中有功能非常强大的查询(Query)功能。一般Bug状态报告的数据可以由查询获得：

   1)发现有效Bug总和，需要剔除重复的和误报的bug:

   2)Bug分布:

   Team Project = @Project AND Work Item Type = Bug

    AND GROUP(GROUP (Resolved Reason <> “Not a Bug”

    AND Resolved Reason <> “Duplicate” AND State = “Closed”) OR  State <> “Closed”)

    ANDArea Path = “[Module Name]”

   3)未关闭Bug严重度分布:

    Team Project = @ProjectANDWork Item Type = BugANDState <> “Closed”

    ANDSeverity = “[Severity Level]”

   4)最近一周Bug发现数:

   Team Project = @ProjectANDWork Item Type = BugANDCreated Date > @Today – 7

AND GROUP( State <> “Closed” 

            OR GROUP(State = “Closed”AND  Resolved Reason <> “Duplicate”ANDResolved                  Reason <> “Not a Bug”))

   5)已关闭Bug严重度分布：

   Team Project = @ProjectANDWork Item Type = BugANDState = “Closed” 

        ANDSeverity = “[Severity Level]”

   6)Bug解决方案分布

   Team Project = @ProjectANDWork Item Type = BugANDResolved Reason = “[Solution             Type]”