我写的bug管理的目的，大家给点意见

gisjuanzi

1        记录bug，解决所发现的问题
首先使用bugfree的第一个目的是管理好bug，只靠制度而没有良好的Bug管理软件，很难确保Bug管理的有效性。就像我们利用VSS管理源代码，确保每位程序员之间的不同版本源程序保持同步、不冲突。BugFree管理系统对所有人都是毫无保留的敞开大门，除了不能删除Bug，其它所有的操作都被忠实的纪录下来。
所有人都可以创建、指派和更改Bug的状态。这样就确保大家发现的所有bug都有一个统一的地方进行提交，根据需要随时查询和讨论提交过的问题，而不是各自记录，从而确保bug管理有序一致。
2        根据bug出现的原因，找出类似的bug
对于已经存在的Bug，当Bug原因找到后，应该由最理解这Bug的人来分析考量，会不会在系统别的地方也存在类似的问题，甚至对整个系统进行彻底清查。这样可以在比较短的时间内找到比较多的问题。在实际的工作中，这点对于编程人员比较有用，但是，在编程的时候，清楚地记录一个Bug的现象，要3~5分钟，但是程序员的本能反应是去找原因了，大致要2~10分钟能找到原因。如果强行在过程中详细的记录Bug的话，程序员的脑子要进行压栈动作，这是很费时，又不讨好的。我想，在编程过程中，发现Bug后，应该可以不用马上记，等找到原因后，再做记录；如果不能很快找到原因，还是应该记下Bug，防止测试发现的问题被忘却或不了了之。
3        统计分析
通过自定义的查询条件，可以得出bug的分布特征，来帮助项目管理者了解项目进度，发现当前所采用的软件过程的缺陷，评估版本的稳定性，等等。具体的说，比如：
3.1.1        查看每天的BUG状况
在测试阶段，项目负责人想查看每天的BUG状况。比如每天新增BUG数，每天解决的BUG，还有多少处于open状态，有多少是要延迟解决的，据此可以不定期的了解开发及测试情况。帮助预估发布时间，防止过早发布带来的质量和维护问题，降低发布风险。

   

3.1.2        明确下一步的工作重点
根据一段时期内的bug记录，可以明确下一步的工作重点，例如重新明确每个人头上的BUG以及了解每个BUG的状况，每位开发人员对此BUG将作何处理等，以此来了解开发中是否有碰到比较棘手的问题，促进问题解决。比如想知道目前系统中很严重的bug都指派给谁解决，可以用“严重等级”和“指派给谁”作为复合查询条件，得出bug记录列表。并且需要的话可以导入excel表格中。

3.1.3        了解缺陷密度和缺陷龄期
即每个模块的缺陷数量，从而确定每个模块的代码编写的质量；


和缺陷龄期：缺陷的打开和关闭状态持续的时间，确定代码修改的进度及质量


并且通过缺陷密度和缺陷龄期判断缺陷趋势：通过对缺陷的密度和龄期以及其他相关数据，用相应的预算方法对缺陷的趋势进行判断。
3.1.4        衡量评估测试人员和开发人员的工作


4        改善测试的有效性
详细记录bug，其他测试人员将知道如何发现类似的错误。除了分享测试知识和经验，bug分析过程可以促进开发更好的测试技术和工具，从而帮助发现类似的bug。这样，就算缺陷没有被完全预防，也能更容易被发现。
如果类似的bug都已经被预防而不容易产生，而且测试人员将有更充裕的时间来进行更深层次和更复杂的测试。
使用BugFree的目的不仅仅是记录和管理Bug，更重要的是通过使用这个工具分析出现问题的根源所在，改进以后的处理方法，预防更多bug的产生。预防的重要性不言而喻。如果第一次就把事情做对，那么后续工作就会少很多麻烦。
因为修正处于开发阶段的bug的工作量远远低于修正处于测试阶段的bug，而相对与修正已经发布的产品的bug，工作量更是小。原因就是当修正一个bug的时候，相当于把之前做的事情重做一次。因此，越晚修正bug，所重做的事情就越多。如果bug修正是在产品测试之前，那么重做的工作只有代码实现。如果bug修正是在测试阶段，那么重做的工作就包括代码实现和测试。预防意味着重做工作的减少。从另一层面来说，就意味着开发成本的减少。
如果在第一时间就避免bug，或者说bug可以被完全预防，那么在开发过程中就不会出现重复工作的情况。当然零缺陷是不切实际的。因为 “软件永远有bug”。特别是测试阶段，反而“期望”发现bug。但是可以预防，借鉴我们自己的经验，分析Bug产生的原因，把bug控制在较早的工作阶段。
首先，为了防止以后再发生类似的Bug，要对所有相关的人员，进行这个Bug的预防培训，还有对测试用例进行更新。有针对性的分析原因，使得知识在组织内的成员间共享。
而对于管理人员，可以总结一些实践经验。比如说，导致一个bug产生的原因可能是需求不够清楚。这样，通过bug分析得到的经验就可以在以后的项目中做一些工作，来预防需求不清楚。
分析过程是和bug的记录与讨论过程息息相关的。
看这个图：

[ 本帖最后由 gisjuanzi 于 2007-4-4 10:41 编辑 ]

gisjuanzi

还有图，贴不上。全是自己根据平时工作写的，感觉有点乱，给点意见sdlkfj2

gisjuanzi

这儿还有个流程图

null2

顶
已经很全面了

谢lz

gisjuanzi

提意见，提意见，过几天要推广，拿这个讲的～sdlkfj2

tongke

流程图不是很详细....如对待确认,不能重视,因技术未能解决等问题该如何处理?

gisjuanzi

之前根据处理办法不同也做过一个流程图，bugfree把处理办法分为7种：by design(就这么设计的) ,fixed（是个问题已经修改）,external（外部因素）,postpone（延迟解决）,won't fix（是个问题但不解决） ,no repro（不可重现）,duplicate（重复的问题）。但是这七种解决方案处理后的bug只有两种结果，一种是解决掉，一种是不解决。对于解决掉的问题又会出现重新激活的问题。所以对于处理方案这一块很难用流程图全面表达。

gisjuanzi

对于fixed（是个问题已经修改）,duplicate（重复的问题）的bug可以执行关闭操作，而不可重现的，可以找程序员重新确认以后再说。但是by design(就这么设计的)，postpone（延迟解决）,won't fix（是个问题但不解决）这类的bug不能草率执行关闭操作啊。
很难做～

wujp_652

提意见，提意见

gisjuanzi

提啊～怎么不提？

leeyupeng

原帖由 gisjuanzi 于 2007-4-5 09:44 发表
对于fixed（是个问题已经修改）,duplicate（重复的问题）的bug可以执行关闭操作，而不可重现的，可以找程序员重新确认以后再说。但是by design(就这么设计的)，postpone（延迟解决）,won't fix（是个问题但不解 ...

可以增加一个“bug三方会审”的流程，三方是开发人员、项目经理、测试人员，开发人员从技术角度，项目经理从需求角度，测试人员从用户角度来共同决定bug的“去留”问题～

gisjuanzi

气死我了，讲砸了，紧张的不得了，话都没说明白sdlkfj9

一丁

不错